Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security and Efficiency Enhancements] Date Submitted: [April 30, 2009] Source: [Rene Struik] Company [Certicom Research] Address [5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada] Voice: [+1 (905) 501-6083], FAX: [+1 (905) 507-4230], E-Mail: [rstruik@certicom.com] Re: [Security and Efficiency Enhancements for IEEE 802.15.4e] Abstract: [This document provides an overview of security and efficiency enhancements for 802.15.4e, based on the streamlined version of Clauses 7.5.8 and 7.6 of IEEE 802.15.4-2006.] Purpose: [Security and efficiency enhancements of IEEE 802.15.4-2006.] 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. René Struik (Certicom Research)

2. Security and Efficiency EnhancementsforIEEE 802.15.4e René Struik (Certicom Research) René Struik (Certicom Research)

3. 802.15.4-2006 vs. 802.15.4-2003 • Security provisions: • Confidentiality, data authenticity, replay protection (with old specification, not always replay protection or data authenticity) • Protection of broadcast and multicast frames possible (with old specification, this mechanism was broken) • Easier set-up of protection parameters possible (with old specification, one had to pre-install these parameters via ‘out-of-scope’ mechanism) • Possibility to vary protection per frame, using a single key (with old specification, protection was fixed and key was married to protection level) • Consideration of system lifecycle issues, e.g., allowing unsecured communications until higher layer sets up key (with old specification, this was ‘out-of-scope’) • Optimization of storage of keying material (with old specification, frame counter was function of device and key; with new specification, this is function of device only [thus, saving cost, e.g., when working with two versions of network key]) • Security policy checks per frame possible (with old specification, protection level fixed irrespective of frame type) • Key usage policy checks possible (with old specification, any key could be used with any frame) René Struik (Certicom Research)

4. Further enhancements to 802.15.4-2006 • Security provisions: • Strong delay protection rather than just replay protection (if clock available) • More refined security policy check (also prevents some DoS attacks) System lifecycle support: • Facility for smooth key updates network-wide keys • Refinement to facility for unsecured initial device enrolment (device-dependent rather than just frame type dependent) Implementation cost: • Reorganization of tables, to facilitate low-cost implementations • Additional status messages • Reduced storage cost of keying material (frame counters, device addresses, keys) Bandwidth utilization: • Do not send bytes over the air if these can be reconstructed at the recipient’s side. René Struik (Certicom Research)

5. #1 – Exploit notion of time if possible • Problem: With 802.15.4-2006 specification, one can only detect proper order of receipt of frames, not timely receipt (it allows only a “relative” notion of time”, due to the absence of a notion of time). Most devices, though, have access to relatively accurate clock (that is loosely synchronized between devices), though. Example: ISA SP100.11a, W/HART have clock with 1ms accuracy. • Proposal: Exploit notion of time to provide • Timeliness. Acceptance/rejection of frames based on whether these were purportedly sent relatively recently. • Security header compression. If part of the security overhead information, e.g., frame counters can be correlated with a system-wide loose time base, it may be possible to send these frame counters in compressed format and reconstruct faithfully at the recipient’s side. See also #2. • PAR compliance: reduce energy consumption, reduce communication latency, improve throughput, improve robustness, (reduce security tables and allow more active neighbors) René Struik (Certicom Research)

6. #2 – Reduce (security) overhead if possible Do not send information in full if this information can be reconstructed from info in the frame and locally maintained side information • Problem 1: security overhead is substantial (currently 5-14 bytes per secured frame). • Problem 2: MAC header overhead is also substantial. • Proposal 1: reduce frame counter overhead from 4 bytes to 0-4 per frame, depending on notion of time • Proposal 2: piggyback on DSN entry for reduction of frame counter size by 1 further octet See also 02/474r2 and 15-04-039-00 • Proposal 3: reduce other security overhead (up to 9 bytes) if information can be reconstructed based on side information Example: with ISA SP100.11a, much of this is in ContractId anyway • Proposal 4: reduce other MAC header overhead (e.g., addresses, PANId) if information can be reconstructed. Example: with ISA SP100.11a, much of this info is in ContractId anyway • PAR compliance: reduce energy consumption, reduce communication latency, improve throughput, improve robustness René Struik (Certicom Research)

7. 0, 1, 5, or 9 n 0-4 2 1 4 or 10 1 2 k m 0, 4, 8, or 16 2 Pending Beacon Security Control Field Explicit Key Identifier Frame Counter Frame Sequence Superframe Integrity code B1 Addressing fields GTS Fields Address Payload FCS Control Number Specification (encrypted) Fields (encrypted) MHR Auxiliary security frame header Non-payload fields Payload field Integrity code New MHR MAC payload MFR 0-4 n 2 1 4 to 20 1 0, 1, 5, or 9 0, 4, 8, or 16 2 Explicit Key Identifier Security Control Field Frame Counter Frame Sequence Integrity code D1 Data Payload (encrypted) Addressing fields FCS Control Number (encrypted) MHR Auxiliary security frame header Payload field Integrity code New MHR MAC payload MFR 0-4 2 1 4 to 20 1 1 n 0, 4, 8, or 16 2 0,1, 5, or 9 Command Explicit Key Identifier Security Control Field Frame Sequence Integrity code Frame Counter C1 Addressing fields Command Type Payload FCS Control Number (encrypted) (encrypted) MHR Auxiliary security frame header Non-payload field Payload field Integrity code New MHR MAC payload MFR Details of frame protection (1) Aux Security Frame Header as extension of MHR René Struik (Certicom Research)

8. bits: 0-2 3-4 5-7 Counter Mode Frame counter size Security Key 0x00 4 octets Level Identifier Reserved 0x01 3 octets Mode 0x02 2 octets Security Control Field 0x03 1 octet 0x04 0 octets 0x05-0x07 Reserved Details of frame protection (2) Security control field 802.15.4-2006 Security control field (802.15.4e extension) Compatible with 802.15.4-2006 frame counters • Notes (optimizations): • Moving 3-bit frame counter mode field towards reserved fields (bits 7-9) of frame control field of 802.15.4-2006 frame allows inclusion of timeliness info in unsecured frames, thus facilitating detection of stale frames in deployments without active attacks • Moving 1 octet of the frame counter field towards the Sequence Number Field of 802.15.4-2006 results in saving 1 octet of per-frame over-the-air communication. • Optimizations can be realized via use of revision number of frame control field of 802.15.4 frames René Struik (Certicom Research)

9. bits: 0-2 3-4 5-7 Security Key Level Identifier Reserved Mode Security Control Field Details of frame protection (3) Security control field 802.15.4-2006 (802.15.4-2006) Security level identifier SecBit1 in frame control field (802.15.4e extension) Note: This offers additional error detection beyond CRC-16 for unsecured data transport (if desired) and detection of delays 802.15.4-2006 does not use SecLevel=0x00 Extended error detection (using fixed key, e.g., the all-zero string) René Struik (Certicom Research)

10. Octets: 8 Octets: 8 4 4 1 1 Source Address Source Address Frame Counter Frame Counter Security Field Security Level Details of frame protection (4) CCM* nonce field 802.15.4-2006 CCM* nonce field (802.15.4e extension) Compatible with 802.15.4-2006 nonce construction • Notes: • Source address is extended IEEE address EUI-64 of originating device (obtained from received frame, possibly via address conversion1) • Frame counter is frame counter purportedly used by originating device (reconstructed from received frame using local side information) • Security level is security level purportedly used by originating device (obtained from received frame), represented in most significant-bit-first order 1 address conversion may include conversion from short IEEE 802.15.4-2006 address, but also from IP address, etc. René Struik (Certicom Research)

11. #3 – Secured ACK • Problem: With 802.15.4-2006 specification, ACK is communication ACK and does not offer security assurances. Some standards, though, wish to use the ACK to piggy-back status information from the recipient to the originator of a message, i.e., side effects do occur. Example: ISA SP100.11a, W/HART pass small corrections to timing information, so as to allow loose synchronization of clocks between devices. • Proposal: Offer a secured ACK, as follows:  Use existing security processing (define secured ACK frame format)  Compress size of Secured ACK, using #1 and #2 • PAR compliance: reduce energy consumption, reduce communication latency, improve throughput, improve robustness René Struik (Certicom Research)

12. Details of ACK protection (1) (Idealized case) René Struik (Certicom Research)

13. Details of short ACK protection (2) (Idealized case) Further savings: – FCS: 2 octets – Crypto: 1 octet1 Total: 3 octets 1 With incorporation of Enhancement #7 René Struik (Certicom Research)

14. #4 – Additional I/O parms and PIB attributes • Problem: The specification would benefit from passing a few more parameters up and down the stack, e.g., regarding ‘exact’ time of receipt of a frame (time stamping) and, e.g., device-wide availability of address conversion maps (short/long addresses). • Proposal: Implement this. • PAR compliance: improve robustness, increase flexibility René Struik (Certicom Research)

15. #5 – Set of security levels • Problem: Define a set of acceptable security levels, rather than the notion of minimum security level (such as 802.15.4-2006 currently has). As an example, if one wishes to allow data authenticity, but no encryption, as, e.g., may be the case due to regulatory constraints (no encryption allowed policies), this can currently not be expressed via the specification. As another example, one may wish to make the protection requirements dependent on the purported originator of the frame (currently, one cannot discriminate w.r.t. originator of the frame). The latter may help with the joining process, where one only allows unsecured communication from the joining node for a limited time window. • Proposal: Implement set of security levels, rather than minimum security level, and stream-line specification to allow discrimination based on originator of frame. • PAR compliance: improve robustness, increase flexibility René Struik (Certicom Research)

16. #6 – Source address filtering • Problem: The current specification does not allow to admit/reject traffic based on access control lists. This may limit flexibility of deployment in settings where, e.g., one routes traffic via multiple hops and does not wish to indiscriminately admit traffic from all devices (one could conceivably filter on who is in the “buddy” list of the recipient device). This may lead to increased storage cost, feeding broadcasts from a device back to itself (§7.5.62 does not filter on unprotected self-originated messages), etc. • Proposal: Implement source address filtering. • PAR compliance: improve robustness, increase flexibility René Struik (Certicom Research)

17. #7 – Eliminate crypto overhead if possible • Problem: cryptographic frame protection generally leads to data expansion, due to data authenticity tag (currently 0, 4, 8, or 16 bytes per secured frame). • Proposal: eliminate this data expansion, if possible • PAR compliance: reduce energy consumption, reduce communication latency, improve throughput René Struik (Certicom Research)

18. 0-4 0-4 0-4 n n n 2 2 2 1 1 1 4 to 20 4 to 20 4 to 20 1 1 1 0, 1, 5, or 9 0, 1, 5, or 9 0, 1, 5, or 9 0, 4, 8, or 16 0, 4, 8, or 16 0, 4, 8, or 16 2 2 2 Explicit Key Identifier Explicit Key Identifier Explicit Key Identifier Security Control Field Security Control Field Security Control Field Frame Counter Frame Counter Frame Counter Frame Frame Frame Sequence Sequence Sequence Integrity code Integrity code Integrity code D1 D1 D1 Data Payload (encrypted) Data Payload (encrypted) Data Payload (encrypted) Addressing fields Addressing fields Addressing fields FCS FCS FCS Control Control Control Number Number Number (encrypted) (encrypted) (encrypted) MHR MHR MHR Auxiliary security frame header Auxiliary security frame header Auxiliary security frame header Payload field Payload field Payload field Integrity code Integrity code Integrity code New MHR New MHR New MHR MAC payload MAC payload MAC payload MFR MFR MFR Frame security dreams (1) No crypto expansion No crypto expansion Reduce Security overhead Reduce MAC header overhead René Struik (Certicom Research)

19. Frame security dreams (2) Example: with ZigBee, one may have the following overhead across layers: (ZigBee does not use MAC layer security right now) NWK layer: 22 octets of security overhead APL layer: 12 octets of security overhead Total security overhead:34 = 22 + 12 octets (this excludes header overhead across layers!) With overhead reduction techniques: – Reduce security and crypto overhead to at most 8 octets in total only – Reduce header overhead significantly Potential gain: much more payload data left for application data (50% more) Caveat: This requires augmentation CCM* mode of operation by other construct – Short frames: reuse the AES-128 engine in ‘forward’ mode, as with the CCM* mode – Long frames: this may require implementation of AES-128 block cipher in ‘forward’ and the so-called ‘inverse’ mode, for performance reasons {30% increase HW implementation cost AES-128} René Struik (Certicom Research)

20. Summary Suggested enhancement More detailed description #1 – Exploit notion of time if possible [2] #2 – Reduce (security) overhead if possible [2] #3 – Secured ACK [2] #4 – Additional I/O parameters and PIB attributes [2] #5 – Security levels [1] #6 – Source address filtering [2] #7 – Eliminate crypto overhead if possible [3] Collateral documentation: [1] 15-08-0849-00-004e-Streamlined-Security-Clause-802.15.4-2006.pdf [2] 15-08-0848-00-004e-Security-and-Efficiency-Enhancements-Overview.doc [3] private communication (to become available if I survive suggesting this radical approach) René Struik (Certicom Research)

21. Summary of proposal elements • Example scenarios: • “dynamic” networks: changing network topologies, no strict scheduling (e.g., ZigBee) • “static” networks: relatively fixed topology, strict scheduling (e.g., W/HART) • Relative incremental benefits depend on addressable market network “types” René Struik (Certicom Research)