1. April 4, 2019
doc.: IEEE r0
July, 2004
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Suggestions for Improvement of the IEEE WPAN Standard]
Date Submitted: [July 15, 2004]
Source: [René Struik] Company [Certicom Corp.]
Address [5520 Explorer Drive, 4th Floor, Mississauga, ON Canada L4W 5L1]
Voice:[+1 (905) ], FAX: [+1 (905) ],
Re: [Current IEEE Low-Rate WPAN standard.]
Abstract: [This document gives some recommendations to assist in improving the security and flexibility of the IEEE Low-Rate WPAN standard.]
Purpose: [Assist in improving the IEEE WPAN standard.]
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
Rene Struik, Certicom Corp.
Rene Struik, Certicom Corp.

2. Suggestions for Improvement of the IEEE 802.15.4-2003 WPAN Standard
July, 2004
Suggestions for Improvement of the IEEE WPAN Standard
René Struik, Certicom Research
Rene Struik, Certicom Corp.

3. MAC Security vs. Security Architectural Framework
July, 2004
MAC Security vs. Security Architectural Framework
key distribution A B
Data key
repository
maintenance
Wrapped
data key info
ACL
Maintenance
initialization
Authentication,
key establishment
Wrapped public
key info
Extracted public
Public key
verification
CA key
Certificate
(Link key, A, B)
data transfer
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Upper layers
Network and down
Rene Struik, Certicom Corp.

4. MAC Security (1) Security objectives
July, 2004
MAC Security (1)
Security objectives
Confidentiality (Encryption: ON/OFF)
Data authenticity (Integrity: No/Low/Medium/High {i.e., 0, 32, 64, 128-bit})
Weak freshness (Relative ordering in time: Enabled/disabled {via FrameCounter})
Security non-objectives
Strong freshness (Absolute ordering in time: not provided)
Required info
Algorithm Id: specifies the particular crypto primitive used
Key Id: prevents use of improper data keys
Sequence number: prevents undetected reordering (or replay) of message frames
Data key
repository
data transfer A B
Wrapped data
Encryptor/
decryptor
data
Data
key
Key
info
Rene Struik, Certicom Corp.

5. MAC Security (2) Variations
July, 2004
MAC Security (2)
Variations
A  B: : [x]SECk, NA {k= f(A,B)} {unicast message}
A  G: : [x]SECk, NA {k= f(A,G)} {multicast with multicast key}
A  G: IdG’ : [x]SECk, NA {k=kG’, G  G’}{multicast with key of bigger group}
Sender A:
Determine adequate security level: SEC  SEC0(A,G, x)
Determine key Key to be used for A  G
Determine frame counter NA
Perform crypto operations using (k, NA) and protection level SEC
Update info
Recipient B (B  G):
(1) Check adequacy of purported security level: SEC  SEC0(A,G, x)
(2) Retrieve key Key that was purportedly used
(3) Retrieve frame counter NA that was purportedly used
(4) Check freshness: NA  N0A {NA {used nonces}}
(5) Determine long address AddressA of sending device
(6) Perform crypto operations using (k, NA) and protection level SEC
(7) Update info
Rene Struik, Certicom Corp.

6. MAC Security (3) Adequate security level SEC  SEC0(A,G, x)
July, 2004
MAC Security (3)
Adequate security level
SEC  SEC0(A,G, x)
Frame/Command Type
SEC0
Ordinary data
Beacon
Acknowledgement
Command Associate
Command Disassociate
Special data
ENC-MIC-64
MIC-64
None
Rene Struik, Certicom Corp.

7. MAC Security (4) Some areas where changes would be beneficial:
July, 2004
MAC Security (4)
Some areas where changes would be beneficial:
1. Crypto primitives:
Add CCM* mode (lower implementation cost, re-use key for different protection levels)
2. Protection levels:
- Differentiate applied protection level: include dynamic SEC field in MAC frames
- Differentiate expected minimum protection level (e.g., to facilitate key agreement
authentication with ‘unsecured’ SEC0 field)
3. Bastardized key usage:
- Facilitate use of group key for peer-to-peer traffic (save storage)
- Remove ambiguities in key identification
4. Group keying:
Facilitate secure broadcast, secure multicast (would necessitate group addressing as well)
5. Clean up useless stuff:
Remove key sequence counter (bandwidth reduction)
6. Security overhead:
Allow compression of frame counter (bandwidth reduction)
7. Other (not necessarily security-related):
Allow 1-octet short addresses (bandwidth reduction for small networks)
Rene Struik, Certicom Corp.

8. July, 2004
MAC Security (5)
… or, according to Robert Poor’s summary (see 04/0272r0):
1. There's no way for a node to join a secured network unless it a-priori holds a key.
2. A node cannot broadcast a secured packet (since sender ID needs to be part of a
secured packet, and broadcast packets don't include sender ID)
3. There's no mechanism to notify a receiving node that a sending node has changed its
key.
4. Different keys are required for different levels of security
- CCM and CBC-MAC can be folded into one (both addressed by CCM* proposal)
5. Any packet that includes security incurs a 5-byte overhead. This can be compressed
down to approximately one byte.
6. Security suite (a.k.a. level of security) must agree exactly in sender and receiver –
when sending to multiple recipients, optimizations are possible by allowing a sender
to ‘meet or exceed’ the security level required of the recipients.
- Security is static, contained in the MIB of the sender and receiver.
7. The ‘key sequence counter’ is a vestige of an unused designed and can be eliminated
to shorten packet overhead.
Rene Struik, Certicom Corp.

9. July, 2004
Some backup slides…
Rene Struik, Certicom Corp.

10. Fine-Grained Security Support – Description Grammar
July, 2004
Fine-Grained Security Support – Description Grammar
Security fields:
<SEC> ::= <encryption flag> <authentication flag>
<encryption flag>:= On, OFF
<authentication flag> ::= none, low, medium, high {i.e., 0, 4, 8, 16 bytes}
{options indicated by 3-bit protection level indicator}
<Key Id> ::= <ImplKeyId> | <ExplKeyId>
{option indicated by 1-bit ‘bastardized’ use of group key indicator}
<ImplKeyId> ::= emptyset
<ExplKeyId> ::= <key source><Key Id>
<KeySource> ::= <physical address>
<Key Id> ::= <group counter>
Freshness fields (in-order receipt indicator)
<FrameCounter> ::= <compressed counter> | <long frame counter>
{option indicated by 1-bit reduced nonce indicator}
“Atoms” (end symbols in grammar):
<compressed counter> ::= 1-octet field
<long frame counter> ::= 4-octet field
<group counter> ::= 1-octet field {this allows 256 groups with same group source}
Rene Struik, Certicom Corp.

11. Security Suite Specification (1)
July, 2004
Security Suite Specification (1)
Current draft specification distinguishes 8 security suites, depending on combination
of encryption and data authentication used:
Encryption: ON/OFF
Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128}
Current security suite specifications are based on 3 security mechanisms:
CBC-MAC mode, to provide for data authentication only;
AES-CTR mode, to provide data confidentiality only;
AES-CCM mode, to provide both data confidentiality and data authenticity.
Problems:
- Different security suites have to use different keys (see § ), for security concerns
- The AES-CBC-MAC specification (§7.6.4) is vulnerable to replay attacks, since it
does not provide for ‘freshness’ guarantees
Consequences:
- Need to implement 3 security mechanisms, to allow for flexibility (thus, impact on
code size)
- Higher layer mechanisms cannot re-use MAC keying material, because of security
concerns (thus, impact on key storage size)
Rene Struik, Certicom Corp.

12. Security Suite Specification (2)
July, 2004
Security Suite Specification (2)
Proposed security suite specification - secure
Specification of security suites is based on 1 security mechanism:
AES-CCM* mode, to provide data confidentiality only, data authenticity only, or both data confidentiality and data authenticity/integrity
Consequences:
- AES-CCM* mode has same security properties as the AES-CCM mode specification
in Annex B
- AES-CCM* mode allows secure re-use of same key, both in MAC and higher layers
- AES-CCM* mode has same format as AES-CCM mode specification for NIST
- Data authenticity-only mode (‘CBC-MAC’) not vulnerable to replay attack any more
- Need to implement only 1 security mechanism (thus, favorable for code size)
CCM* vs. CCM:
- CCM* allows the length M of the authentication field to be zero (‘encryption-only’);
- CCM* imposes restriction on nonce if different authentication tag lengths used
(this prevents attack on CCM with variable tags [Rogaway, David Wagner, 2003])
For details, see
Rene Struik, Certicom Corp.

13. Reducing Security Status Information Overhead (1)
July, 2004
Reducing Security Status Information Overhead (1)
Current draft specification adds 5 bytes of security status info overhead to protected
frames providing confidentiality (see §7.6.2 for AES-CTR and §7.6.3 for AES-CCM)
Consequences:
Large fixed overhead of 5 bytes per secured frame, whether security status info is
already reliably available at recipient’s side or not
Proposed encoding of security status information:
Security status information is represented more efficiently, exploiting side information
Sending device may decide for itself whether to send all security status info
completely (uncompressed) or only partially (compressed)
Sending device has way of determining whether receiving device might have lost
synchronization of security status info (e.g., via slightly modified ACK mechanism)
Security status info only sent when required, due to loss of synchronization
Expected bandwidth saving per protected frame: (almost) 4 bytes
Bandwidth saving range per protected frame: from 1 byte (uncompressed) to 4 bytes
(compressed)
Rene Struik, Certicom Corp.

14. Reducing Security Status Information Overhead (2)
July, 2004
Reducing Security Status Information Overhead (2)
I. Reduction of security status info overhead by 1 byte per protected frame
MAC Header
Frame
Control
Addressing
Fields
Sequence
Counter
Frame Payload
Control Sequence
MAC Payload
MAC Footer
Security Status Info
Key
Data
Secured
Frame Counter
New Frame Counter
Seq.
No.
New Security Status Info
Existing protected frame format
Proposed uncompressed
protected frame format
(note the removal of the
duplicate string)
Illustration of how to save 1 byte security
status information overhead, by exploiting
side information on the sequence counter
Rene Struik, Certicom Corp.

15. Reducing Security Status Information Overhead (3)
July, 2004
Reducing Security Status Information Overhead (3)
I. Reduction of security status info overhead by 1 byte per protected frame (cont’d)
- Frame Counter N: 32-bit non-repeating value, used for providing security
Sequence Counter DSN: 8-bit integer value, used for loose synchronization between
sent messages and ACK hereon. Incremented by 1 (mod 256) per sent frame
Proposed method (lazy updates by sender)
Frame counter N: initialized at any value; when used, updated from N to value N0 N
such that N0 :=min{N’ N | N’  DSN (mod 256)}. (Here, DSN is current value of
Sequence Counter in frame to be sent)
Outgoing frames that require ACK are re-encrypted in exactly the same way till ACK
received or till retries exhausted
Corollary:
The property N  DSN (mod 256) is invariant at each time instance N is used
Note: It is easy to compute N0 from N (hint: compare N (mod 256) and DSN).
Rene Struik, Certicom Corp.

16. Reducing Security Status Information Overhead (4)
July, 2004
Reducing Security Status Information Overhead (4)
II. Removing security status info overhead per protected frame altogether†
†: the KeySeqCtr is always sent for robustness reasons: it allows smooth ZigBee key updates and facilitates easy future extensions of the
standard using multicasting, whether secured or not.
MAC Header
Frame
Control
Addressing
Fields
Sequence
Counter
Frame Payload
Control Sequence
MAC Payload
MAC Footer
New Frame Counter
New Security Status Info
Key
Data
Secured
Proposed uncompressed
protected frame format
Proposed compressed
Illustration of how to save 3 bytes security
status information overhead, by exploiting the
re-synch capabilities of the sequence counter
Compr. Security Status Info
Rene Struik, Certicom Corp.

17. Reducing Security Status Information Overhead (5)
July, 2004
Reducing Security Status Information Overhead (5)
II. Removing of security status info overhead per protected frame altogether (cont’d)
- Frame Counter N: 32-bit non-repeating value, used for providing security
Sequence Counter DSN: 8-bit integer value, used for loose synchronization between
sent messages and ACK hereon. Incremented by 1 (mod 256) per sent frame
Proposed method (lazy updates by recipient)
Frame counter N: initialized at value 0; when used, updated from N to value N0 N
such that N0 :=min{N’ N | N’  DSN (mod 256)}. (Here, DSN is current value of
Sequence Counter in received frame)
Corollary:
Let NA be the value of the frame counter used by sender.
If the recipient’s value of N satisfies N NA N+256, then N0 = NA and decryption
proceeds exactly the same as in the current D17 draft.
If the recipient’s value of N0 satisfies NA N or NA  NA+256, then N0  NA
and decryption proceeds incorrectly* (same effect as active change of
Frame Counter in uncompressed scenario). This is so-called loss of synchronization.
*: of course, this can only be detected if the protected frame provides for authenticity (as an encryption-only
mechanism does not provide for authenticity)
Rene Struik, Certicom Corp.

18. Reducing Security Status Information Overhead (6)
July, 2004
Reducing Security Status Information Overhead (6)
Security fields (in-order receipt indicator):
<FrameCounter> ::= <compressed counter> | <long frame counter>
{option indicated by 1-bit reduced nonce indicator}
“Atoms” (end symbols in grammar):
<compressed counter> ::= 1-octet field
<long frame counter> ::= 4-octet field
Rene Struik, Certicom Corp.

19. Reducing Security Status Information Overhead (7)
July, 2004
Reducing Security Status Information Overhead (7)
III. Reduction of security status info overhead – what if re-synchronization needed?
Proposed error-handling (3 cases):
Feedback channel always on (always ACKs):
Rules: Frame transmitted in uncompressed format, if no ACK received (and in
compressed format otherwise) {Note: no change to ACK necessary}
Loss-of-synchronization NEVER occurs, so behavior exactly as in current draft.
Feedback channel never on (no ACKs at all):
Rules: Avoid error-handling altogether by sending uncompressed frames regularly
This always works if receiving device is awake at least once in every 256-frame
counter interval; in that case, exactly the same behavior as in draft
Feedback channel sometimes on (ACKs sometimes):
Rules:
- Recipient: If decryption on compressed frame rejected, do not send ACK next time
- Sender: If no ACK received, next frame sent in uncompressed form
(this makes sure that re-synch is achieved with a delay of 1 ACK’ed frame only)
Rene Struik, Certicom Corp.

20. Reducing Security Status Information Overhead (7a)
July, 2004
Reducing Security Status Information Overhead (7a)
III. Reduction of security status info overhead – re-synchronization examples
Feedback channel always on (always ACKs):
Loss-of-synchronization NEVER occurs, so behavior exactly as in current draft
(including number of retries afforded) – Remark: if decryption fails long enough,
[hacker] recipient runs out-of-synch still (Note: this can be fixed as on next slide (6b))
msg1
ACK 7
msg2 2
258
msg3
NAK 33
289
Message flow
Frame
Counter
uncompressed
compressed
msg4 34
290
Rene Struik, Certicom Corp.

21. Reducing Security Status Information Overhead (7b)
July, 2004
Reducing Security Status Information Overhead (7b)
III. Reduction of security status info overhead – re-synchronization examples
Feedback channel sometimes on (ACKs sometimes):
Loss-of-synchronization might occur, but is solved with a delay of 1 ACK’ed frame
msg1
ACK 7
msg2
loss 2
258
msg3 32
288
msg4 33
289
Message flow
Frame
Counter
uncompressed
compressed
msg5
NAK (due
to error-flag) 34
290
Enable error-flag:
decryption error
reject (due
Disable error-flag:
frame counter OK
Message sent with
ACK request
Rene Struik, Certicom Corp.

22. Reducing Security Status Information Overhead (7c)
July, 2004
Reducing Security Status Information Overhead (7c)
III. Reduction of security status info overhead – re-synchronization examples
Feedback channel never on (no ACKs at all):
Loss-of-synchronization might occur, but is solved with next received uncompressed
frame
msg1 7
msg2
loss 2
258
msg3
288
msg4 33
289
Message flow
Frame
Counter
uncompressed
compressed
msg5
547
805
msg6 89
601
msg7
Rene Struik, Certicom Corp.

23. Reducing Security Status Information Overhead (8)
July, 2004
Reducing Security Status Information Overhead (8)
IV. Reduction of security status info overhead – distinguishing (un)compressed formats
Proposed encoding of compressed vs. uncompressed protected frame formats:
Indicate compressed/uncompressed mode option in Frame Control Field. (This does not
cost anything, since one can simply use 1 of the 6 reserved bits for this).
Other potential options:
- Indicate compressed/uncompressed mode option in Frame Field (This does cost 8 bits,
since there are currently no reserved bits available to encode this information.)
Do not indicate compressed/uncompressed mode option (This is instable (!!!), since
it causes instability of the system and might necessitate 2 decryption executions, to
determine which one of the compressed or uncompressed modes was actually used)
Rene Struik, Certicom Corp.

24. Reducing Security Status Information Overhead (9)
July, 2004
Reducing Security Status Information Overhead (9)
Impact of change on draft (cont’d):
Changes to Clause 7.6:
- (Re)construct Full Frame Counter from Sequence Counter and stored Frame Counter
- Add to the acceptance rules for incoming frames (in § ) the following text:
‘If the Compression Error Flag is set, the received frame shall be in
uncompressed format, i.e, the Compression Enabled field in the Frame Control
Field shall be disabled’.
- During the secure processing of incoming frames (in § , §7.6.3), set the
Compression Error Flag if the received frame was sent in compressed format and
decryption fails; disable a set Compression Error Flag if the received frame was sent
in uncompressed format and decryption succeeds.
- If a message is sent with the ACK field set and no ACK is received, the message
shall be resent in uncompressed format, i.e., with the Compression Enabled field in
the Frame Control Field enabled (in § , § , §7.6.3).
- Incoming and outgoing secured messages shall be processed as if these are in
uncompressed format (thus, making re-encryption and retransmission unnecessary)
- Adapt notational conventions in Clauses : remove lines 19-29, Page 165
- Change the format of the AES-CCM MAC Payload (Figure 67, § ) as
follows:
Have options for the length of the Frame Counter field: 0 or 3 octets,
depending upon the
(see document 02/468r1)
Rene Struik, Certicom Corp.

25. Security Suite Selection (1)
July, 2004
Security Suite Selection (1)
Current specification distinguishes 8 security suites, depending on combination
of encryption and data authentication used:
Encryption: ON/OFF
Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128}
Existing security suite selection and usage (as in Draft D18)
SEC field indicates whether data is secured or not
Security services (data encryption/authentication) statically depend on security suite
negotiated between devices, irrespective of frame type
Mechanism for negotiation of security suite not defined in current standard
Consequences:
Out-of-scope mechanism needed for authentic exchange of info on what security
suite to use. Need to re-negotiate every time security properties communication change
Communication to multiple recipients with different security suites requires data
protection using each of these mechanisms, thus causing extra bandwidth overhead
and extra processing (up to 8 times as much)
Inflexible, since security services cannot be tailored towards protection requirements
for individual frame types
Rene Struik, Certicom Corp.

26. Security Suite Selection (2)
July, 2004
Security Suite Selection (2)
Current specification distinguishes 8 security suites, depending on combination
of encryption and data authentication used:
Encryption: ON/OFF
Data authentication/integrity: #integrity bits {L0, L1, L2, L3}= {0,32,64,128}
Proposed security suite selection:
SEC field indicates the security services (data encryption/authenticity) that are provided over frame type (beacon, ACK, command, data frame).
- Communicating device may decide for itself on how to protect frames it sends:
SEC=Encr  Auth, where Encr={ON, OFF} and where Auth={0,32-bit,64-bit,128-bit}
Consequences:
Inside-scope mechanism for determining what security suite to use
Communication to multiple recipients requires protection using only 1 mechanism*,
thus eliminating previously necessary extra bandwidth overhead and processing
- Flexible, since security services can be tailored towards protection requirements
for individual frame types (e.g., authenticity for beacons, something else for others)
Allows reduction of #security suites, effectively from 8 to 1 (in §7.6)
Rene Struik, Certicom Corp.

27. Security Suite Selection (3)
July, 2004
Security Suite Selection (3)
Security fields:
<SEC> ::= <encryption flag> <authentication flag>
<encryption flag>:= On, OFF
<authentication flag> ::= none, low, medium, high {corresponds to 0, 4, 8, 16 bytes}
{security options indicated by 3-bit protection level indicator}
Rene Struik, Certicom Corp.

28. Other Remarks — Selection (1)
July, 2004
Other Remarks — Selection (1)
Security concerns
Message protection is currently a function of the recipient, whereas it should be a
function of the sender (for his information is at stake). This is extremely bad security
practice
If devices do not yet share a key, they automatically use the default key. This creates a
false sense of security. As a minimum, an attempt must be made to derive a shared key
The ACL mode is not defined if encryption is enabled (see § )
Broadcast encryption (i.e., use of the default key) is insecure, since it does not provide
for freshness guarantees
Efficiency
Each recipient can only share 1 key with each sender. This unnecessarily complicates
secure communications (e.g., it means that if A B, and A  B,C, then the latter
communications initiated by A towards B and C cannot use the same key for B and
C).
Rene Struik, Certicom Corp.

29. Other Remarks — Selection (2)
July, 2004
Other Remarks — Selection (2)
Efficiency, Trade-offs IEEE /ZigBee
There is no mechanism that enables one to distinguish keys from one another. This is
bad practice, since key updates might be necessary. Moreover, it makes the definition
of Key Management at the ZigBee level unnecessarily hard
Solution:
Change the definition of the Key Sequence Counter (§ ) as follows:
‘The key sequence counter is a counter that is fixed by the higher layer. This
value may be used by the higher layers to facilitate key management: the
value of the key sequence counter identifies the key that is shared by devices
that are engaged in a security relationship.
I would be happy to work with the editors to get the comments incorporated in the standard, to allow a more secure operation of and a smooth interface between and external standards, such as ZigBee
Rene Struik, Certicom Corp.