ZigBee supports the 128-bit AES (Advanced Encryption Standard) encryption to encrypt data on a ZigBee network. Following are answers to frequently asked questions regarding encryption on ZigBee networks.
1) Are ZigBee/802.15.4 Sniffers able to decipher encrypted RF packets? If so, which bytes are encrypted and which are not?
Yes, depending on the vendor of the Sniffer, they are able to decipher encrypted RF packets. Information such as PAN ID and MAC-layer addresses are non-encryypted and visible to all, but payload is certainly encrypted. Some vendors provide packet sniffers that can decode encrypted RF packets if they have the right security key. Sniffers that do not support decryption, or that do not have the right security key, will display garbled data on the sniffing software.
2) Does encryption keep 2 adjacent coordinators from starting networks on the same channel/PAN ID?
No, that is automatically done. (The ZigBee feature of keeping 2 adjacent coordinators from starting networks on the same channel is still effective whether encryption is enabled or not.)
To further explain, when a coordinator starts up a network, it first has to choose a channel and PAN ID. To determine which values to choose it sends out a beacon request and does an energy scan on each channel to see if any existing networks are within range. All existing coordinators or routers that hear a beacon request are required to respond with a beacon. Beacons are not encrypted, so the coordinator receiving the beacon will be able to see the existing PAN ID and choose an appropriate PAN ID to operate on.
If the new coordinator is set for ID=0x0, it will choose a unique PAN ID to operate on. If it is set by the user to any other value and it receives a beacon that indicates that PAN ID is already taken, it will change channels and repeat the beacon request until it finds a channel that does not have that PAN ID yet.
3) Does encryption isolate non-encrypted nodes from joining an encrypted network? Does encryption keep nodes with different encryption keys from joining each others networks?
In order to understand encrypted/non-encrypted node joining, it is first necessary to understand the basics of joining a network. When a new node tries to join a network, it sends a beacon request to the broadcast PAN 0xFFFF. All routers and coordinators within range are required to respond with a beacon, which tells the joining node the PAN ID of the existing network on that channel. (If no beacon is heard, then the new node repeats this beacon request on the next channel, and so forth until it finds a valid network). After hearing a beacon from a valid network the joining node sends an association request to join the network. The router or coordinator within range transmits an association response, which tells the joining node it has been joined to the network and has been assigned a 16-bit network address (MY parameter). The new node sets its network address to this value and joining is complete. (Note: beacon requests and beacons are broadcast messages; association requests and responses are unicast messages.)
Now lets add encryption into all of this. Beacon requests and beacons are never encrypted. So any node, encrypted or not, can get a beacon from a router or coordinator, encrypted or not. However, joining the network requires encryption settings to be appropriate for both joining node and parent node in order for association requests and responses to be understood by each other.
An association request is encrypted if the joining node has encryption enabled (EE parameter) and is trying to join securely (EO=0, see EO parameter). If the encrypted joining node is configured to acquire the encryption key over the air (EO=1, unsecured joins), the association request is non-encrypted. An association response is encrypted only if the association request is encrypted.
So what happens when one has encryption (EE=1) and the other does not (EE=0)? It might be helpful to run through all 4 possible scenarios in the following table:
Joining node Encryption Enabled?
Parent Node Encryption Enabled?
Joining node will join the network with no problem, as described above. All frames are non-encrypted.
Joining node will join the network but it will not be able to communicate with any nodes; it will only see garbled, encrypted data. This is because during joining the parent node, in response to a non-encrypted association request, sends the non-encrypted association response over the air to the joining node. The joining node sets its network address appropriately and joins the network, but since it does not have encryption enabled it does not set an encryption key to be able to communicate with the network nodes.
Joining node will not join the network. If the joining node is not configured for acquiring an encryption key (unsecured joins) it sends an encrypted association request, which the non-encrypted parent node does not understand and does not respond to. If the joining node is configured for acquiring an encryption key, it sends a non-encrypted association request, which the non-encrypted parent node replies to with a non-encrypted association response. Even though the joining node receives the association response and knows the PAN ID and network address for joining the network, it did not receive an encryption key. The encrypted joining node considers this a failed association attempt and leaves the network.
4) Can the encryption key be read or detected in any way over the air?
It depends on what level of security is selected. If an encrypted router or coordinator is configured to allow unsecured joins to the network, the key will be sent over the air non-encryypted to the joining node.
If an encrypted router or coordinator is configured to allow secured joins only, the key will never be transmitted over the air. In this case each node in the network would need to be pre-configured with the encryption key. Also please know that encryption keys cannot be read via the serial port; they are write-only.