1. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security and Efficiency Enhancements] Date Submitted: [November 13, 2008] 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.

2. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 2 Security and Efficiency Enhancements for IEEE 802.15.4e René Struik (Certicom Research)

3. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 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)

4. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 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.

5. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 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 10ms 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)

6. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 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

7. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 7 Details of frame protection (1) Aux Security Frame Header as extension of MHR

8. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 8 Details of frame protection (2) bits: 0-2 3-4 5-7 SecurityKey LevelIdentifierReserved Mode Security Control Field Security control field 802.15.4-2006 Security control field (802.15.4e extension) Counter ModeFrame counter size 0x004 octets 0x013 octets 0x022 octets 0x031 octet 0x040 octets 0x05-0x07Reserved 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

9. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 9 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 Extended error detection (using fixed key, e.g., the all-zero string) 802.15.4-2006 does not use SecLevel=0x00 bits: 0-2 3-4 5-7 SecurityKey LevelIdentifierReserved Mode Security Control Field

10. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 10 Details of frame protection (4) CCM* nonce field 802.15.4-2006 CCM* nonce field (802.15.4e extension) Security FieldFrame CounterSource Address 14Octets: 8 Security LevelFrame CounterSource Address 14Octets: 8 Notes: – Source address is extended IEEE address EUI-64 of originating device (obtained from received frame, possibly via address conversion 1 ) – 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. Compatible with 802.15.4-2006 nonce construction

11. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 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 a new command type)  Compress size of Secured ACK, using #1 and #2 PAR compliance: reduce energy consumption, reduce communication latency, improve throughput, improve robustness

12. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 12 #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

13. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 13 #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

14. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 14 #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

15. doc.: IEEE 802.15-04-0828-01-004e Submission November 13, 2008 René Struik (Certicom Research)Slide 15 Summary Suggested enhancementMore 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] 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