May 14, 2019 doc.: IEEE 802.15-02030r0 November, 2002 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Security-and-Security-Architectural-Recommendations-for-the-802.15.4-Low-Rate-WPAN Date Submitted: [November 14, 2002] Source: [Rene 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: [Draft D17 of the emerging IEEE 802.15.4 Low-Rate WPAN standard.] Abstract: [This document gives some security and security architectural recommendations to assist in improving the security and flexibility of the Draft D17 for IEEE 802.15.4 Low-Rate WPAN.] Purpose: [Assist sponsor ballot comment resolution process for the Draft D17 for the IEEE 802.15.4 WPAN.] 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.

René Struik, Certicom Research November, 2002 Security and Security Architectural Recommendations for the IEEE 802.15.4 Low-Rate WPAN René Struik, Certicom Research Rene Struik, Certicom Corp.

Security Suite Specification - Implementation cost - Security concerns November, 2002 Outline: Security Suite Specification - Implementation cost - Security concerns - Solution Security Suite Selection and Usage - Effectiveness and efficiency - Impact on IEEE 802.15.4/ZigBee interface Representation anomalies - Implementation cost of inconsistent representations Other remarks - more security concerns - efficiency concerns - more on IEEE 802.15.4/ZigBee interface Rene Struik, Certicom Corp.

Security Suite Specification (1) November, 2002 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. All the security suites re-use the same key (see §7.6.1.8) Consequences: - Need to implement 3 security mechanisms, to allow for flexibility (thus, impact on code size) - Security mechanisms re-use the same key, which may render the combined usage of the security suites insecure (see also next slides) Rene Struik, Certicom Corp.

Security Suite Specification (2) November, 2002 Security Suite Specification (2) Security mechanisms underlying security suite specification 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. All the security suites re-use the same key (see §7.6.1.8) Security of individual security mechanisms CBC-MAC mode: provably secure for messages of fixed length; believed secure for arbitrary messages, if length-pre-pended (Bellare, Kilian, Rogaway, 2000) AES-CTR mode: provably secure, provided counters are never re-used over life-time of key (Mihir Bellare et al, 1997-1999) AES-CCM mode: provably* secure, provided counters are never re-used over life-time of key (Jakob Jonsson, 2002) Security of individual security suites in this standard The AES-CBC-MAC specification (§7.6.4) is vulnerable to replay attacks, since it does not provide for ‘freshness’ guarantees *: Partial security proof presented at SAC 2002 (Aug 2002). Modified security proof submitted to NIST Modes of Operation (Sep 2002) Rene Struik, Certicom Corp.

Security Suite Specification (3) November, 2002 Security Suite Specification (3) Security of combined usage of security mechanisms Re-use of same key for the 3 security mechanisms renders the combined usage hereof insecure, due to interplay between these mechanisms An adversary can fabricate authentic messages that he has not observed before, without knowledge of the key, based on combining previously observed outputs of the AES-CTR mode and the AES-CCM mode, thus rendering the CBC-MAC mechanism insecure in this context Attack ingredients: - CBC-MAC on messages of variable length is insecure if not length-pre-pended (Bellare, Kilian, Rogaway, 2000) - CBC-MAC with length pre-pending is insecure if first block can be encrypted, with disrespect to the length information (since, one can then fabricate a ‘fresh’ authentic message using standard cryptanalytic techniques) - The AES-CTR mode and the AES-CCM mode allow such encryption of the first block (provided these mechanisms re-use the same data key) Workload: 1 AES-CTR/AES-CCM ops.; 1 CBC-MAC on message of ‘suitable’ size Security of combined usage of security mechanisms in this standard Rene Struik, Certicom Corp.

Security Suite Specification (4) November, 2002 Security Suite Specification (4) Security of combined usage of security mechanisms in this standard Adversary can fabricate authentic messages that he has not observed before, without knowledge of the key, based on combining previously observed outputs of the AES-CTR mode and the AES-CCM mode, thus rendering the CBC-MAC mechanism insecure This attack works for sure if the message consists of L octets, where L=1 or 130, and may very well work for messages of lengths L=65, 129, or 193. Other values not Investigated (yet). Note: The current draft specification does only allow frames of length L  aMAXPHYPacketSize, including frame overhead. Currently, one has aMAXPHYPacketSize:=127 (Table 19, §6.4.1). Therefore, this preliminary attack only works for a limited set of messages. Since this is only a preliminary attack, prudence dictates to treat the present combination of security mechanisms with extreme suspicion. Rene Struik, Certicom Corp.

Security Suite Specification (5) November, 2002 Security Suite Specification (5) Current security suite specification (as in Draft D17): Specification of security suites is 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. All the security suites re-use the same key (see §7.6.1.8) Proposed security suite specification: 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: - Need to implement only 1 security mechanism (thus, favorable for code size) - AES-CCM* mode has same security properties as the AES-CCM mode specification in Annex B *: AES-CCM* is a slight extension of the AES-CCM specification from Annex B.1, with a slightly more refined counter specification Rene Struik, Certicom Corp.

Security Suite Selection (1) November, 2002 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 D17) 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) November, 2002 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) Rene Struik, Certicom Corp.

Security Suite Selection (3) November, 2002 Security Suite Selection (3) Impact of change on draft: Existing format frame control field (as in draft D17, §7.2.1.1): Proposed format frame control field: Algorithm Id info: 3 bits, specifying (a) Encryption on/off; (b) Data integrity level: #bits {L0, L1, L2, L3}, where {L0, L1, L2, L3}={0,32,64,128} Further impact: - Allows reduction of #security suites from 8 to 1 (in §7.6) - Saves storage in MACPIB tables (Table 71, Table 72, §7.5) Bits: 0-2 3 4 5 6-9 10-11 12-13 14-15 Frame type Security Enabled (SEC) pending ACK request Reserved Destination addressing field Source addressing mode Bits: 0-2 3-5 6 7 8-9 10-11 12-13 14-15 Frame type Security Algorithm Id (SEC) pending ACK request Reserved Destination addressing field Source addressing mode Rene Struik, Certicom Corp.

Representation Anomalies November, 2002 Representation Anomalies Representation of integers N (0  N  Bk) as string of symbols w.r.t. basis B: N:=Mk-1Bk-1 + Mk-2Bk-2 + … + M1 B1+ M0 , where 0  Mi  B small/big endian: N  (Mk-1|| Mk-2|| …|| M1|| M0) vs. N  (M0|| M1|| …|| Mk-2|| Mk-1) Representation of binary polynomial p(x) (with deg p(x)  k) as binary string: p(x):=ak-1 xk-1 + ak-2 xk-2 + … + a1 x1+ a0 , where ai  {0,1} Small/big endian: p(x)  (ak-1|| ak-2|| …|| a1|| a0) vs. p(x)  (a0|| a1|| …|| ak-2|| ak-1) Existing representation (as in Draft D17) — inconsistent non-security: low-endian representation everywhere (e.g., polynomial vs. binary string; integer as octet string; integer vs. binary string and octet as integer) security (see §7.6.1.3): big-endian representation octet as integer; low-endian representation integer vs. octet string; mixture representation integer vs. binary string Consequences: costly dual integer arithmetic routines required; error-prone Proposed representation — consistent everywhere (NO exceptions): low-endian representation (e.g., polynomial vs. binary string, integer vs. octet string, integer vs. binary string) Rene Struik, Certicom Corp.

Removal of 5 bytes of Status Information in Security (1) November, 2002 Removal of 5 bytes of Status Information in Security (1) Existing AES-CCM payload field (as in draft D17, §7.6.3): Octets: 4 1 Variable Frame counter Key sequence counter Encrypted payload Proposed AES-CCM payload field: - Send Frame Counter and Key Sequence Counter only when Synchronization is lost Indication of uncompressed/compressed mode: Options: Use indicator bit in Frame Control Field (explicit) Send long version if NO ACK received (implicit) Send long version after specific time-out period (implicit) Rene Struik, Certicom Corp.

Other Remarks — Selection (1) November, 2002 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) Efficiency The current specification of the security suites causes unnecessary data expansion of 5 bytes for each data frame. This could be eliminated in virtually all cases, except when a loss of synchronization occurs. This would present a tremendous saving in bandwidth for small commands and, thus present battery savings 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) November, 2002 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 More comments have been submitted. 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.