1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
March 11, 2009
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Security and Efficiency Enhancements]
Date Submitted: [March 11, 2009]
Source: [Rene Struik]
Company [Certicom Research]
Address [5520 Explorer Drive, Fourth Floor, Mississauga, ON, L4W 5L1, Canada]
Voice: [+1 (905) ], FAX: [+1 (905) ],
Re: [Security and Efficiency Enhancements for IEEE e ]
Abstract: [This document provides an overview of security and efficiency enhancements for e, based on the streamlined version of Clauses and 7.6 of IEEE ]
Purpose: [Security and efficiency enhancements of IEEE ]
Notice: This document has been prepared to assist the IEEE P 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
René Struik (Certicom Research)
<author>, <company>

2. Security and Efficiency Enhancements for IEEE 802.15.4e
<month year>
doc.: IEEE <doc#>
March 11, 2009
Security and Efficiency Enhancements for IEEE e
René Struik (Certicom Research)
René Struik (Certicom Research)
<author>, <company>

3. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
March 11, 2009 vs
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>

4. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
March 11, 2009
Further enhancements to
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>

5. #1 – Exploit notion of time if possible
<month year>
doc.: IEEE <doc#>
March 11, 2009
#1 – Exploit notion of time if possible
Problem: With 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>

6. #2 – Reduce (security) overhead if possible
<month year>
doc.: IEEE <doc#>
March 11, 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
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>

7. Details of frame protection (1)
<month year>
doc.: IEEE <doc#>
Details of frame protection (1)
March 11, 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>

8. Details of frame protection (2)
<month year>
doc.: IEEE <doc#>
Details of frame protection (2)
March 11, 2009
Security control field
Security control field ( e extension)
bits: 0-2
3-4
5-7
Security
Key
Level
Identifier
Reserved
Mode
Security Control Field
Compatible
with
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
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 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 frames
René Struik (Certicom Research)
<author>, <company>

9. Details of frame protection (3)
<month year>
doc.: IEEE <doc#>
Details of frame protection (3)
March 11, 2009
Security control field
( )
Security level identifier
SecBit1 in frame control field
( e 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
does not use SecLevel=0x00
Extended error detection (using fixed key, e.g., the all-zero string)
René Struik (Certicom Research)
<author>, <company>

10. Details of frame protection (4)
<month year>
doc.: IEEE <doc#>
March 11, 2009
Details of frame protection (4)
CCM* nonce field
CCM* nonce field ( e extension)
Security Field
Frame Counter
Source Address 1 4
Octets: 8
Security Level
Compatible with
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 address, but also from IP address, etc.
René Struik (Certicom Research)
<author>, <company>

11. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
March 11, 2009
#3 – Secured ACK
Problem: With 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>

12. Details of ACK protection
<month year>
doc.: IEEE <doc#>
March 11, 2009
Details of ACK protection
René Struik (Certicom Research)
<author>, <company>

13. #4 – Additional I/O parms and PIB attributes
<month year>
doc.: IEEE <doc#>
March 11, 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>

14. #5 – Set of security levels
<month year>
doc.: IEEE <doc#>
March 11, 2009
#5 – Set of security levels
Problem: Define a set of acceptable security levels, rather than the notion of minimum security level (such as 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>

15. #6 – Source address filtering
<month year>
doc.: IEEE <doc#>
March 11, 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 (§ 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>

16. #7 – Eliminate crypto overhead if possible
<month year>
doc.: IEEE <doc#>
March 11, 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>

17. Frame security dreams (1)
<month year>
doc.: IEEE <doc#>
March 11, 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>

18. Frame security dreams (2)
<month year>
doc.: IEEE <doc#>
March 11, 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 = 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
– Requires implementation of AES-128 block cipher in ‘forward’ and ‘inverse’ mode
Note: CCM* mode of operation does not require AES-128 in ‘inverse’ mode
{30% increase in HW implementation cost AES-128} (Not always necessary )
René Struik (Certicom Research)
<author>, <company>

19. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
March 11, 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]
#2a – Eliminate crypto overhead if possible [3]
Collateral documentation:
[1] e-Streamlined-Security-Clause pdf
[2] e-Security-and-Efficiency-Enhancements-Overview.doc
[3] private notes (to become available if I survive suggesting this radical approach)
René Struik (Certicom Research)
<author>, <company>