doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

Security and Efficiency Enhancements for IEEE 802.15.4e <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 Security and Efficiency Enhancements for IEEE 802.15.4e René Struik (Certicom Research) René Struik (Certicom Research) <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

#1 – Exploit notion of time if possible <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

#2 – Reduce (security) overhead if possible <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

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

Details of frame protection (2) <month year> doc.: IEEE 802.15-<doc#> Details of frame protection (2) April 30, 2009 Security control field 802.15.4-2006 Security control field (802.15.4e extension) bits: 0-2 3-4 5-7 Security Key Level Identifier Reserved Mode Security Control Field Compatible with 802.15.4-2006 frame counters Counter Mode Frame counter size 0x00 4 octets 0x01 3 octets 0x02 2 octets 0x03 1 octet 0x04 0 octets 0x05-0x07 Reserved 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) <author>, <company>

Details of frame protection (3) <month year> doc.: IEEE 802.15-<doc#> Details of frame protection (3) April 30, 2009 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 bits: 0-2 3-4 5-7 Security Key Level Identifier Reserved Mode Security Control Field 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) <author>, <company>

Details of frame protection (4) <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 Details of frame protection (4) CCM* nonce field 802.15.4-2006 CCM* nonce field (802.15.4e extension) Security Field Frame Counter Source Address 1 4 Octets: 8 Security Level 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) <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

Details of ACK protection (1) <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 Details of ACK protection (1) (Idealized case) René Struik (Certicom Research) <author>, <company>

Details of short ACK protection (2) <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

#4 – Additional I/O parms and PIB attributes <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

#5 – Set of security levels <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

#6 – Source address filtering <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

#7 – Eliminate crypto overhead if possible <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 #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) <author>, <company>

Frame security dreams (1) <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 Frame security dreams (1) 2 1 4 to 20 0, 1, 5, or 9 0-4 0, 4, 8, or 16 D1 Frame Control Sequence Number Addressing fields Security Field Explicit Key Identifier Counter Integrity code (encrypted) FCS MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header No crypto expansion 2 1 4 to 20 0, 1, 5, or 9 0-4 0, 4, 8, or 16 D1 Frame Control Sequence Number Addressing fields Security Field Explicit Key Identifier Counter Integrity code (encrypted) FCS MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header No crypto expansion 2 1 4 to 20 0, 1, 5, or 9 0-4 0, 4, 8, or 16 D1 Frame Control Sequence Number Addressing fields Security Field Explicit Key Identifier Counter Integrity code (encrypted) FCS MFR Payload field MAC payload New MHR MHR n Data Payload (encrypted) Auxiliary security frame header Reduce Security overhead Reduce MAC header overhead René Struik (Certicom Research) <author>, <company>

Frame security dreams (2) <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

doc.: IEEE 802.15-<doc#> <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>

Summary of proposal elements <month year> doc.: IEEE 802.15-<doc#> April 30, 2009 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) <author>, <company>