1. December 7, 2018
doc.: IEEE r0
July, 2003
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Suggestions for Improvement of the IEEE WPAN Standard]
Date Submitted: [July 23, 2003]
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 (Draft D18).]
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 (Draft D18).]
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 WPAN Standard
July, 2003
Suggestions for Improvement of the IEEE WPAN Standard
René Struik, Certicom Research
Rene Struik, Certicom Corp.

3. Security Suite Specification - Implementation cost
July, 2003
Outline:
Multicasting
Security Suite Specification
- Implementation cost
Security Suite Selection and Usage
- Effectiveness and efficiency
Security Status Information overhead
- Reduction of bandwidth cost
Other remarks
- more security and efficiency concerns
- more on IEEE /ZigBee interface
Rene Struik, Certicom Corp.

4. Multicasting Support (1)
July, 2003
Multicasting Support (1)
Current draft specification does not support multicasting
Consequences:
- No advantage taken of broadcast character PAN communications (without relay)
- Need to retransmit same data to different devices in a group
* bandwidth and energy inefficient
* latency issues
Proposed encoding of multicast info:
Destination address allows differentiation between multicast address, peer-to-
peer address, and broadcast address)
- Multicast indicator: 1-bit value in MAC Header (e.g., in Frame Control Field)
- Group address (components):
* group creator address:
address of the device that originated (=created) the group: with mode options
* group sequence number:
1-octet field, to allow up to 256 groups per originating device: in same spot as key sequence counter
Rene Struik, Certicom Corp.

5. Multicasting Support (2)
July, 2003
Multicasting Support (2)
Property of group address format:
- No confusion between group addresses created by different devices (due to
partitioning address space according to group originator)
A receiving device (§ ) accepts group address if the group address
(DestAddress, KeySeqNo) indicates the group of which it is a member
Notes:
Frame filtering implementation:
- hardware-based: peer-to-peer, unsecured broadcast traffic
- software-based: multicast, secured broadcast traffic
Group membership test:
To be implemented at higher layer
GroupId  G={group members}
Rene Struik, Certicom Corp.

6. Multicasting Support (3)
July, 2003
Multicasting Support (3)
MAC Header
MAC Payload
MAC Footer
Frame
Control
Sequence
Counter
Addressing
Fields
Frame Payload
Frame
Control Sequence
Status Info
Data
Data
Unprotected frame
(peer-to-peer, broadcast)
MAC Header
Frame
Control
Addressing
Fields
Sequence
Counter
Frame Payload
Control Sequence
MAC Payload
MAC Footer
Status Info
Group
Data
Unprotected frame
(multicast)
MAC Header
Frame
Control
Addressing
Fields
Sequence
Counter
Frame Payload
Control Sequence
MAC Payload
MAC Footer
Security Status Info
Key
Data
Secured
Frame Counter
Protected frame
(peer-to-peer, broadcast, multicast)
Key Counter not necessary
for peer-to-peer!
Rene Struik, Certicom Corp.

7. Security Suite Specification (1)
July, 2003
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.

8. Security Suite Specification (2)
July, 2003
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)
Rene Struik, Certicom Corp.

9. Security Suite Selection (1)
July, 2003
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.

10. Security Suite Selection (2)
July, 2003
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.

11. Reducing Security Status Information Overhead (1)
July, 2003
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.

12. Other Remarks — Selection (1)
July, 2003
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.

13. Other Remarks — Selection (2)
July, 2003
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.
More comments have been submitted (for an indication, see IEEE doc 03/284r0).
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.