1. May 14, 2019
doc.: IEEE r0
November, 2002
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Security-and-Security-Architectural-Recommendations-for-the 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) ], FAX: [+1 (905) ],
Re: [Draft D17 of the emerging IEEE 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 Low-Rate WPAN.]
Purpose: [Assist sponsor ballot comment resolution process for the Draft D17 for the IEEE WPAN.]
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. René Struik, Certicom Research
November, 2002
Security and Security Architectural Recommendations for the IEEE Low-Rate WPAN
René Struik, Certicom Research
Rene Struik, Certicom Corp.

3. 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 /ZigBee interface
Representation anomalies
- Implementation cost of inconsistent representations
Other remarks
- more security concerns
- efficiency concerns
- more on IEEE /ZigBee interface
Rene Struik, Certicom Corp.

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

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

6. 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.

7. 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.

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

9. 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.

10. 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.

11. Security Suite Selection (3)
November, 2002
Security Suite Selection (3)
Impact of change on draft:
Existing format frame control field (as in draft D17, § ):
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.

12. 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 § ): 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.

13. 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: 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.

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

15. Other Remarks — Selection (2)
November, 2002
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
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 and a smooth interface between and external standards, such as ZigBee
Rene Struik, Certicom Corp.