Security Considerations for IEEE 802'15'4 Networks

1
Security Considerations forIEEE 802.15.4 Networks

• Naveen Sastry, David Wagner
• ACM WiSe 2004
• 2005/9/8
• Junbeom Hur

2
Overview

• IEEE 802.15.4 overview
• Protocol description
• Security problems
• Recommendation
• conclusion

3
IEEE 802.15.4 Overview

• Physical MAC layer of a low-rate WPAN (Wireless
  Personal Area Network)
• WSN, home networking, home security,
• Security service overview
• Access control
• Prevent unauthorized parties from participating
  in the network
• Message integrity
• Detect the tampering of a message by a MAC
• Confidentiality
• Keep even partial information secret from
  unauthorized parties by encryption
• ? Semantic security
• Replay protection
• Prevent a replay attack by a sequence number

4
Protocol Description - 802.15.4

• Addressing
• 64-bit node identifier 16-bit network
  identifier
• Packet type
• Data packet
• Acknowledge packet

Figure 1. Data and acknowledgement packet formats
5
Protocol Description - Security

• An application must explicitly enable security
• handled at the media access control layer
• Security suites
• Null
• AES-CTR confidentiality
• AES block cipher with counter mode
• ci pi Ek(xi) , where xi is a nonce or IV
• Nonce non repeating value that protects
  confidentiality
• monotonically increasing counter
  that prevents replay attack
• AES-CBC-MAC (32/64/128 bit MAC) integrity
• AES-CCM (Encryption and 32/64/128 bit MAC)
• CBC mode for encryption and authentication

Figure 2. The format of the xi to the block
cipher for the AES-CTR and AES-CCM suits
6
Protocol Description - Security
Replay counter Prevent nonce reuse
Figure 3. The formatting of the data field
7
Protocol Description - Security

• Sender
• If an application enable security
• MAC layer looks up the destination address in its
  Access Control List (ACL) table
• uses the matched ACL entry to encrypt and
  authenticate the packet
• sets the flags field on outgoing packet
• Receiver
• If the flags field is set
• MAC layer uses a similar process
• Optionally enable replay protection (AES-CTR,
  AES-CCM)

Figure 4. Format of an ACL entry
8
Keying Models

• Network shared keying
• A single network-wide shared key
• Pairwise keying
• Each pair of nodes share a different key
• Greater robustness overhead for key
  management
• Group keying
• A single key is shared among a set of nodes
• Hybrid approaches

9
802.15.4 Problems IV Management

• Same key in multiple ACL entries
• It is highly likely that the sender will
  accidentally reuse the nonce
• e.g., same key for different message m1, m2 to
  different recipients
• m1 Ek(x1) m2 Ek(x1) m1 m2
• confidentiality violation !!
• Loss of ACL state due to power interruptions
• Power failure
• Low powered operation
• Nonces will be reused, compromising security

10
802.15.4 Problems Key Management

• No support for group keying
• Appear to be functional but actually compromise
  security
• Same key for multiple ACL entries
• A single ACL entry for the same key
• Modify destination address every time a
  packet is sent
• Network shared keying incompatible with replay
  protection
• No way to protect against replay attacks
• Recipient cannot update the replay counter
  properly
• Pairwise keying inadequately supported
• Significant limit to scalability
• Radio chip with n ACL entries limit to the
  networks of n nodes

11
802.15.4 Problems ACL Structure

• Overloading the nonce to serve both as an IV and
  a replay counter
• IV
• Protect confidentiality
• Should be strongly bound to the key
• Replay counter
• Protect against replay attack
• Should be strongly bound to the senders address

12
802.15.4 Problems Insufficient Integrity
Protection

• Unauthenticated encryption modes
• AES-CTR suite
• Encryption without a MAC
• Failures of integrity can affect confidentiality
  as well
• Denial-of-service attacks on AES-CTR
• AES-CTR suite with replay protection enabled
• When an adversary sends a forged packet with
• Key counter 0xFF, frame counter 0xFFFFFFFF, and
  any payload whatsover
• Already maximum value
• Any subsequent packet will appear to be replayed
  and rejected
• No integrity on acknowledgement packets
• Adversary can forge the sequence number in
  acknowledgement packets
• Targeted jamming fooling the sender into thinking
  that the packet has been received
• Ack might be legitimate or forged

13
Recommendations

• Application designers
• Dont use AES-CTR security suite
• Dont rely on Acknowledgements
• If necessary, use application level
  acknowledgement with integrity control
• and not use the acknowledgement of 802.15.4
• Hardware designer
• Include support for 255 ACL entries
• To properly support pairwise keying demands many
  ACL entries
• Retain ACL list even in low power mode
• Expose nonce (replay counter) for each received
  packet
• To support application level replay detection
• ? allows the recipient to implement replay
  protection even when using group keying
• Eliminate support for the AES-CTR security suite

14
Recommendations

• Specification writers
• Warn application against dangerous ACL
  configurations
• Two ACL entries with the same address
• Two different addresses with the same key
• Better support for keying models
• Decouple nonce storage (for sending packets) from
  replay counters (to receive packets)
• Remove support for the AES-CTR suite
• Support authenticated acknowledgement
• Only generate by a node that shares a
  cryptographic key with the sender
• Eliminate difference between key and frame
  counter
• No functionality is lost
• Specification and use of the security package can
  be simplified

15
Conclusion

• 802.15.4
• Well designed security features
• Step forward for embedded device wireless
  security
• Possibility of security vulnerabilities in
  deployed applications
• Proper use of the security API can lead to
  secure applications!