As pointed in the previous article 802.15.4 vs Zigbee, the IEEE MAC layer implements several features which are used by the Zigbee protocol in the network and application layers. One of this features is the security services.
IEEE 802.15.4 sets the encryption algorithm to use when cyphering the data to transmit, however, the standard does not specify how the keys have to be managed or what kind of authentication policies have to be applied. These issues are treated in the upper layers which are managed by technologies such as ZigBee.
802.15.4 Security Global View:
The encryption algorithm used is AES (Advanced Encryption Standard) with a 128b key length (16 Bytes). It is really important to count with an unique kind of encryption method due to the fact that most of the 802.15.4/ZigBee transceivers have a specific hardware design to cope with this work at the electronic level (embedded low resources devices).
The AES algorithm is not only used to encrypt the information but to validate the data which is sent. This concept is called Data Integrity and it is achieved using a Message Integrity Code (MIC) also named as Message Authentication Code (MAC) which is appended to the message. This code ensures integrity of the MAC header and payload data attached. It is created encrypting parts of the IEEE MAC frame using the Key of the network, so if we receive a message from a non trusted node we will see that the MAC generated for the sent message does not correspond to the one what would be generated using the message with the current secret Key, so we can discard this message. The MAC can have different sizes: 32, 64, 128 bits, however it is always created using the 128b AES algorithm. Its size is just the bits length which is attached to each frame. The more large the more secure (although less payload the message can take). Data Security is performed encrypting the data payload field with the 128b Key.
802.15.4 Security Insights:
There are three fields in the IEEE 802.15.4 MAC frame which are related to security issues:
The Auxiliary Security Frame is only enabled if the Security Enabled subfield of the Frame Control Frame is turned on. This special header has 3 fields:
The Security Control is the place where our global Security Policy is set. Using the 2 first bits (Security Level field) we choose what we are going to encrypt and how long the Key is going to be:
|0x00 ||No security ||Data is not encrypted. Data authenticity is not validated.|
|0x01 ||AES-CBC-MAC-32||MIC-32||Data is not encrypted. Data authenticity is validated.|
|0x02||AES-CBC-MAC-64||MIC-64||Data is not encrypted. Data authenticity is validated.|
|0x03||AES-CBC-MAC-128 ||MIC-128||Data is not encrypted. Data authenticity is validated.|
|0x04||AES-CTR||ENC||Data is encrypted. Data authenticity is not validated.|
|0x05||AES-CCM-32||AES-CCM-32||Data is encrypted. Data authenticity is validated.|
|0x06||AES-CCM-64||AES-CCM-64||Data is encrypted. Data authenticity is validated.|
|0x07||AES-CCM-128 ||AES-CCM-128 ||Data is encrypted. Data authenticity is validated.|
The 0x00 value sets no encryption so nor the data is encrypted (no data confidentiality) or the data authenticity is validated. From the 0x01 to 0x03 the data is authenticated using the encrypted Message Authentication Code (MAC). The value 0x04 encrypts the payload ensuring Data Confidentiality. The 0x05 to 0x07 range ensures both data confidentiality and authenticity.
The Key Identifier Mode subfield sets the kind of key (implicit or explicit) which should be used by the sender and the receiver. Possible values are:
As pointed before, the Key Identifier field is set when the Key Identifier Mode subfield is not zero. The Key Source subfield specifies the group Key originator. The Key Index subfield helps to identify different Keys from an specific Key Source.
The Data Payload field can have three different configurations depending on the previously defined security fields:
We have successfully tried the AES-CTR mode on Waspmote sensor devices. The specific encryption hardware on the transceivers used let cypher the information without almost increasing the energy consumption. As pointed before is important to count with a transceiver which has specific hardware for the encryption process. The XBee modules integrated in Waspmote work this way.
The Access Control List:
Each 802.15.4 transceiver has to manage a list to control its "trusted brothers" along with the security policy . For this reason each node has to control its own Access Control List (ACL) which stores the following fields:
When a node wants to send a message to a specific node or receives a packet, it looks at the ACL to see if it is a trusted brother or not. In the case it is, the node uses de data inside the specific row apply the security measures. In the case the node is not in the list or its message is rejected or an authentication process starts.
ZigBee implements two extra security layers on top of the 802.15.4 one: the Network and Application security layers. All the security policies rely on the AES 128b encryption algorithm so the hardware architecture previously deployed for the link level (MAC layer) is still valid. There are three kind of Keys: master, link and network keys.
Each pair of devices can have set both Network and Link Keys. In this case the Link key is always used (more security although more memory is needed). There are two kinds of security policies which the Trust Center can follow:
We have been able to analyze both IEEE 802.15.4 and ZigBee security protocol stacks on the sensor platform Waspmote due to the fact they support two different "pin to pin" compatible transceivers. The XBee OEM 802.15.4 implements the IEEE protocol over the Freescale chipset platform. On the other hand the ZigBee stack has been studied using the XBee ZB transceiver which uses de Ember chipset solution.