December 7, 2018 doc.: IEEE 802.15-02030r0 July, 2003 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Suggestions for Improvement of the IEEE 802.15.4 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) 501-6083], FAX: [+1 (905) 507-4230], E-Mail:[rstruik@certicom.com] Re: [Current IEEE 802.15.4 Low-Rate WPAN standard (Draft D18).] Abstract: [This document gives some recommendations to assist in improving the security and flexibility of the IEEE 802.15.4 Low-Rate WPAN standard.] Purpose: [Assist in improving the IEEE 802.15.4 WPAN standard (Draft D18).] 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. Rene Struik, Certicom Corp. Rene Struik, Certicom Corp.

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

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 802.15.4/ZigBee interface Rene Struik, Certicom Corp.

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.

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 (§7.5.6.2) 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.

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.

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 §7.6.1.8), 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.

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.

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.

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.

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.

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 §7.5.9.4) 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.

Other Remarks — Selection (2) July, 2003 Other Remarks — Selection (2) Efficiency, Trade-offs IEEE802.15.4/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 (§7.6.1.8) 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 802.15.4 and a smooth interface between 802.15.4 and external standards, such as ZigBee Rene Struik, Certicom Corp.