Resolution of security issues

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Security Resolutions Date Submitted November
18, 2004 Source Rene Struik Company
Certicom Research Address 5520 Explorer Drive,
Fourth Floor, Mississauga, ON, L4W 5L1,
Canada Voice905 501-6083, FAX 905
507-4230, E-Mailrstruik_at_certicom.com Re
Abstract This document proposes resolutions
to a set of issues relating to the security suite
in IEEE 802.15.4-2003 Purpose This document is
submitted for consideration for revisions to the
802.15.4-2003 specification. Notice This
document has been prepared to assist the IEEE
P802.15. It is offered as a basis for discussion
and is not binding on the contributing
individual(s) or organization(s). The material in
this document is subject to change in form and
content after further study. The contributor(s)
reserve(s) the right to add, amend or withdraw
material contained herein. Release The
contributor acknowledges and accepts that this
contribution becomes the property of IEEE and may
be made publicly available by P802.15.
2
Security Resolutions 802.15.4

• Rene Struik (Certicom Research)
• New items/updates in blue

3
Compatibility issues

• 802.15.4-2003 is unclear about how to interpret
  reserved fields.
• Interpretation 1
• Reserved fields may be ignored upon reception
  (dont care approach)
• Consequence Reserved fields cannot be given
  meaningful value, since
• this would break existing implementations.
• Interpretation 2
• Reserved fields shall be set to zero. The
  receiver shall inspect these fields and, if
• found to be nonzero, it shall discard the frame
  with no indication to higher layers.
• Consequence Reserved fields can be given
  meaningful value, without breaking
• existing implementations.
• Subsequent interpretations still unclear
• - Minutes Berlin meeting (04-0509-00-004b)
• - Document Phil Beecher (04-0521-01-004b)
• Proposal Adopt interpretation 2, since it
  allows use of reserved fields for updates
• to 802.15.4-2003.

4
14, 45 CCM

• Description The current 15.4 security suite is
  composed of three components AES-CCM (for
  encryption and authentication), CBC-MAC (for
  authentication only), and AES-CTR (encryption
  only).
• Problem 1 These three separate components
  require a larger implementation (counted in gates
  or code) than the unified CCM implementation.
• Problem 2 Switching between these modes
  compromises security unless you keep separate
  keys, which requires additional storage.
• Problem 3 CBC-MAC doesnt provide freshness and
  is subject to replay attacks.
• Proposal Replace security suite with CCM as
  described in 15-04-0537-00 (replaces 02-469r0).
  (Note on backward compatibility current
  specification allows devices to negotiate
  security, falling back to no security as
  required.)
• PAR Compliance remove inflexible security use

5
30 What fields are authenticated?

• Problem The IEEE 802.15.4-2003 spec is ambiguous
  or unclear as to what components of a packet are
  subject to authentication.
• Proposal Authenticate MAC header and MAC
  payload, i.e. everything except the FCS. (Refer
  to figure 34 in 15.4-2003).
• PAR Compliance Resolving ambiguities.
• Guiding principle
• - contiguous frame portions are authenticated,
  resp. encrypted

6
Details of frame protection (1)

• Option 1 Aux Security Frame Header as extension
  of MHR
• a?
• b?

7
Details of frame protection (2)

• Option 2 Aux Security Frame Header right ahead
  of Payload field

8
Details of frame protection (3)
9
Details of frame protection (4)

• Proposal Adopt frame protection, Option 1b.
• PAR Compliance Resolving ambiguities.

10
Eliminate Key Sequence Counter

• Problem In practice, Key Sequence Counter serves
  no useful function (is always fixed at 0), and
  generates one byte overhead in each
  security-enabled frame.
• Proposal Eliminate Key Sequence Counter. This
  increases over the air efficiency, reduces the
  size of the ACL tables, simplifies processing in
  CCM. (Note on backward compatibility If this
  change is introduced as part of CCM update,
  there will be no backward compatibility issue.)
• PAR compliance Removing unnecessary complexity,
  reduce MAC overhead, MAC header compression.

11
44 Security Endianess Clarification

• Problem The definition of Least Significant Bit
  and Most Significant Bit is inconsistent between
  Section 7.6 and Annex B.
• Solution Integers that are communicated over the
  air are represented as octet strings, in
  lowest-octet-first order and lowest-bit-first
  order.
• PAR compliance Resolve ambiguities.

12
Broadcast Encryption

• Problem Broadcast encryption does not provide
  freshness when using the default (broadcast) key,
  making the system subject to replay attacks.
• Proposal Implement fix as described in document
  15-04-0539-00. Receiver keeps track of the frame
  counter for each device sending to it using
  default key, similar to what is currently done
  for peer-to-peer traffic (which uses peer-to-peer
  keys).
• PAR Compliance remove inflexible key usage, fix
  security holes, remove ambiguities
• The frame counter element and the explicit key
  identification part of
• the proposal are covered by 13, resp. 17

13
Which Key to use for Peer to Peer

• Problem Node A may have a shared key to use with
  Node B. If node B lacks that shared key, it will
  try to use the default key (aka broadcast key)
  when receiving a packet from Node A, resulting in
  a decryption failure. Higher level code cannot
  determine why the decryption failed.
• Proposal Explicitly identify key in a Key
  Identification Field in the Security Control
  field, if the key is not a function of source and
  destination device.
• PAR compliance remove inflexible key usage,
  remove ambiguities, reduce complexities

14
Dynamic protection levels

• Problem Nodes can only derive applicable
  security/protection level from statically
  maintained information, thus leading to
  unworkable broadcast encryption (if recipients
  have different security expectations) and
  high-cost system set-up
• Proposal 1 Differentiate applicable protection
  level on frame-by-frame basis
• Proposal 2 Allow acceptance of incoming frames
  depending on minimum required protection level
  (this may depend on frame type and command type)
• Proposal 3 Allow the communication of expected
  protection levels between devices, by
  incorporating this in the Security Control Field
  (this level will be passed to higher layer, who
  may act on this)
• PAR compliance remove inflexible key usage,
  reduce complexities, reduce cost, reduce latency

15
Group keying and multicast

• Problem secure broadcast is not possible, if
  devices would change key over lifetime secure
  multicast is also not possible
• Proposal 1 Incorporate secure broadcast over
  networks lifetime
• Proposal 2 incorporate secure multicast (and
  unsecured multicast)
• See also 15-04-0539-00
• PAR compliance remove inflexible key usage,
  reduce complexities, reduce key storage cost,
  reduce latency, incorporate multicast
• See also 15-03-0320-02-004b, Slides 6-8

16
Compress security overhead if possible

• Problem security overhead is substantial
  (currently 5 bytes per secured frame).
• Proposal 1 reduce frame counter overhead from 4
  to 2 bytes per frame
• Proposal 2 piggyback on DSN entry for reduction
  of frame counter size by 1 further octet (thus
  reducing this to 1)
• Proposal 3 allow automatic resynchronization
• See also 02/474r2 and 15-04-0539-00 (slight
  impact on frame receipt)
• PAR compliance remove security overhead, reduce
  battery usage at no computational cost (1 integer
  increment only), eliminate risk of Denial of
  Service attack by insiders (!)

17
Centralized frame counters

• Problem frame counters depend on device and key,
  thus invoking quite a big key storage cost
  (Example 16 RFD talk with coordinator using n
  versions of broadcast key ? 16 X n X 464 n bytes
  for frame counters)
• Proposal centralize frame counters, such as to
  have these depend on device only (this requires
  stored frame counter devices sending)
• PAR compliance reduce storage requirements
  keying material