Suggestions for Improvement of the IEEE 802.15.4 WPAN Standard

1
Project IEEE P802.15 Working Group for Wireless
Personal Area Networks (WPANs) Submission Title
Suggestions for Improvement of the IEEE
802.15.4-2003 WPAN Standard Date Submitted
July 15, 2004 Source René Struik Company
Certicom Corp. Address 5520 Explorer Drive,
4th Floor, Mississauga, ON Canada L4W
5L1 Voice1 [phone], FAX 1 (905)
507-4230, E-Mailrstruik_at_certicom.com Re
Current IEEE 802.15.4-2003 Low-Rate WPAN
standard. Abstract This document gives some
recommendations to assist in improving the
security and flexibility of the IEEE
802.15.4-2003 Low-Rate WPAN standard. Purpose A
ssist in improving the IEEE 802.15.4-2003 WPAN
standard. 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.
2
Suggestions for Improvement of the IEEE
802.15.4-2003 WPAN Standard

• René Struik, Certicom Research

3
MAC Security vs. Security Architectural Framework
4
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

5
MAC Security (2)

• Variations
• A ? B xSECk, NA k f(A,B) unicast
  message
• A ? G xSECk, NA k f(A,G) multicast with
  multicast key
• A ? G IdG xSECk, NA kkG, G ?
  Gmulticast 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

6
MAC Security (3)
Adequate security level SEC ? SEC0(A,G, x)
SEC0
Frame/Command Type
Ordinary data Beacon Acknowledgement Command
Associate Command Disassociate Special data
ENC-MIC-64 MIC-64 None None MIC-64 None
7
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 5. Group keying Facilitate
secure broadcast, secure multicast (would
necessitate group addressing as well) 4. 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)
8
MAC Security (5)
or, according to Robert Poors 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.
9
Some backup slides
10
Fine-Grained Security Support Description
Grammar
Security fields ltSECgt ltencryption flaggt
ltauthentication flaggt ltencryption flaggt On,
OFF ltauthentication flaggt none, low, medium,
high i.e., 0, 4, 8, 16 bytes options
indicated by 3-bit protection level
indicator ltKey Idgt ltImplKeyIdgt
ltExplKeyIdgt option indicated by 1-bit
bastardized use of group key indicator ltImplKey
Idgt emptyset ltExplKeyIdgt ltkey sourcegtltKey
Idgt ltKeySourcegt ltphysical addressgt ltKey Idgt
ltgroup countergt Freshness fields (in-order
receipt indicator) ltFrameCountergt ltcompressed
countergt ltlong frame countergt option
indicated by 1-bit reduced nonce
indicator Atoms (end symbols in
grammar) ltcompressed countergt 1-octet field
ltlong frame countergt 4-octet field ltgroup
countergt 1-octet field this allows 256
groups with same group source
11
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)

12
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 http//csrc.nist.gov/CryptoToolki
  t/modes/comments/index.html

13
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 recipients 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)
• Consequences
• 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)

14
Reducing Security Status Information Overhead (2)
I. Reduction of security status info overhead by
1 byte per protected frame
15
Reducing Security Status Information Overhead (3)

• I. Reduction of security status info overhead by
  1 byte per protected frame (contd)
• - 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 minN? 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).

16
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
802.15.4 standard using multicasting, whether
secured or not.
17
Reducing Security Status Information Overhead (5)

• II. Removing of security status info overhead per
  protected frame altogether (contd)
• - 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 minN? 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 recipients value of N satisfies N? NA?
  N256, then N0 NA and decryption
• proceeds exactly the same as in the current
  D17 draft.
• If the recipients value of N0 satisfies NA? N
  or NA ? NA256, 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)

18
Reducing Security Status Information Overhead (6)
Security fields (in-order receipt
indicator) ltFrameCountergt ltcompressed
countergt ltlong frame countergt option
indicated by 1-bit reduced nonce
indicator Atoms (end symbols in
grammar) ltcompressed countergt 1-octet field
ltlong frame countergt 4-octet field
19
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 ACKed frame only)

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
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)

24
Reducing Security Status Information Overhead (9)

• Impact of change on draft (contd)
• 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 7.5.6.2) 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.5.9.4, 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.5.6.5,
  7.5.9.4, 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)

25
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
  
  
  
  

26
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
• SECEncr ? Auth, where EncrON, OFF and where
  Auth0,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)

27
Security Suite Selection (3)
Security fields ltSECgt ltencryption flaggt
ltauthentication flaggt ltencryption flaggt On,
OFF ltauthentication flaggt none, low, medium,
high corresponds to 0, 4, 8, 16
bytes security options indicated by 3-bit
protection level indicator
28
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).
• 
  
  
  

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