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:
- Frame Control (located in the MAC Header)
- Auxiliary Security Control (in the MAC Header)
- Data Payload (in the MAC Payload field)
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:
- Security Control (1B) specifies which kind of protection is used (see below).
- Frame Counter (4B) is a counter given by the source of the current frame in order to protect the message from replaying protection. For this reason each message has a unique sequence ID represented by this field.
- Key Identifier (0-9B) specifies the information needed to know what key we are using with the node we are communicating with.
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:
- 0 – the key id is known implicitly by the sender and the receiver (its is not specified in the message)
- 1– the key id is determined explicitly by the 1Byte Key Index from the Key Identifier Field and the macDefaultKeySource.
- 2 – the key id is determined explicitly by the 1Byte Key Index and the 4Byte Key Source both subfields from the Key Identifier Field.
- 3 – the key id is determined explicitly by the 1Byte Key Index and the 8Byte Key Source both subfields from the Key Identifier Field.
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:
- AES-CTR: all the data is encrypted using the defined 128b key and the AES algorithm. The Frame Counter sets the unique message ID ,and the Key Counter (Key Control subfield) is used by the application layer if the Frame Counter max value is reached.
- AES-CBC-MAC: The Message Authenticity Code (MAC) is attached to the end of the data payload. Its length depends on the level of security specified in the Security Policy field. The MAC is created encrypting information from the 802.15.4 MAC header and the data payload.
- AES-CCM: It is the mixture of the previously defined methods. The subfields correspond with the AES-CTR mode plus the extra AEX-CBC-MAC subfield encrypted.
We have successfully tried the AES-CTR mode on both Waspmote and SquidBee 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 and SquidBee 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:
- Address: of the node we want to communicate with
- Security Suite: the security police which is being used (AEC-CTR, AES-CCM-64, AES-CCM-128,,…)
- Key: the 128b key used in the AES algorithm
- Last Initial Vector (IV) and Replay Counter: both are the same field. The Last IV is used by the source and the Replay Counter by the destination as a message ID in order to avoid reply attacks.
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 Security:
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.
- Master Keys: They are pre-installed in each node. Their function is to keep confidencial the Link Keys exchange between two nodes in the Key Establishment Procedure (SKKE).
- Link Keys: They are unique between each pair of nodes. These keys are managed by the Application level. The are used to encrypt all the information between each two devices, for this reason more memory resources are needed in each device (in the “real world” this key is not use to be used).
- Network key: It is a unique 128b key shared among all the devices in the network. It is generated by the Trust Center and regenerated at different intervals. Each node has to get the Network Key in order to join the network. Once the trust center decides to change the Network Key, the new one is spread through the network using the old Network Key (see image above about “ZigBee Residential Mode”). Once this new key is updated in a device, its Frame Counter (see in the previous sections) is initialized to zero. This Trust Center is normally the Coordinador, however, it can be a dedicated device. It has to authenticate and validate each device which attempts to join the network.
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:
- Commercial mode: the Trust Center share Master and Link Keys with any of the devices in the network (see image below about the “ZigBee Commercial mode”). This mode requires high memory resources. This mode offers a complete centralized model for the Key Security control.
- Residential mode: the Trust Center shares just the Network Key (it is the ideal mode when embedded devices have to cope with this task due to the low resources they have). This is the mode normally chosen for the Wireless Sensor Network model (see image above about the “ZigBee Residential mode”).
We have been able to analyze both IEEE 802.15.4 and ZigBee security protocol stacks on the sensor platforms Waspmote and SquidBee 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.
