November 18 2004 doc IEEE 802 15 04

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Project: IEEE P 802. 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, L 4 W 5 L 1, Canada] Voice: [905 501 -6083], FAX: [905 507 -4230], E-Mail: [rstruik@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 P 802. 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 P 802. 15. Submission 1 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Security Resolutions 802. 15. 4 Rene Struik (Certicom Research) New items/updates in blue Submission 2 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Compatibility issues • 802. 15. 4 -2003 is unclear about how to interpret reserved fields. Interpretation 1 Reserved fields may be ignored upon reception (don’t 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 -004 b) - Document Phil Beecher (04 -0521 -01 -004 b) • Proposal: Adopt interpretation 2, since it allows use of reserved fields for updates to 802. 15. 4 -2003. Submission 3 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 #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 doesn’t provide freshness and is subject to replay attacks. Proposal: Replace security suite with CCM* as described in 15 -04 -0537 -00 (replaces 02 -469 r 0). (Note on backward compatibility: current specification allows devices to negotiate security, falling back to ‘no security’ as required. ) PAR Compliance: “remove inflexible security use” Submission 4 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 #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 Submission 5 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Details of frame protection (1) Option 1: Aux Security Frame Header as extension of MHR a b Submission 6 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Details of frame protection (2) Option 2: Aux Security Frame Header right ahead of Payload field Submission 7 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Details of frame protection (3) Attribute Security: Encrypt Bcn Pending Address Field Processing: Availability security material required for decryption Option 1 Option 2 YES NO Early, since on Late, since just prior MHR boundary to frame payload (maximizes (allows minimal decryption delays) Processing: Avoidance frame type discrimination YES NO Processing: Similarity to handling MHR 802. 15. 4 YES NO Processing: Similarity to security handling 802. 15. 4 For Data Frames For all frame types Esthetics: Beauty pageant Less appealing Submission 8 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Details of frame protection (4) • Proposal: Adopt frame protection, Option 1 b. • PAR Compliance: Resolving ambiguities. Submission 9 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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. Submission 10 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 #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 lowestbit-first order. • PAR compliance: Resolve ambiguities. Submission 11 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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 -053900. 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 Submission 12 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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 Submission 13 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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-byframe 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 Submission 14 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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 network’s 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 -004 b, Slides 6 -8 Submission 15 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 Compress security overhead if possible • Problem: security overhead is substantial (currently 5 bytes per secured frame). • Proposal 1: reduce over-the-air frame counter overhead by 2 octets, by never communicating the most significant 2 bytes in the MHR (thus saving 2 bytes total per secured frame) For details, see 02/474 r 2 • 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 (!) Submission 16 Poor & Struik / Ember & Certicom

November 18, 2004 doc. : IEEE 802. 15 -04 -0540 -07 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 4=64 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 Submission 17 Poor & Struik / Ember & Certicom