Zigbee
Low-power 802.15.4 mesh for the smart home: sniffable, with weak default key provisioning.
Zigbee is a low-power 802.15.4 mesh networking protocol for smart-home devices. It organises nodes into a self-healing mesh secured by a single shared network key, and it is one of the two dominant radios (alongside BLE and, increasingly, Thread) inside bulbs, sensors, plugs, and locks.
What it is
Zigbee sits on top of the IEEE 802.15.4 PHY/MAC, the same physical layer used by Thread and by early 6LoWPAN. In the 2.4GHz band it uses channels 11 to 26 (there are also sub-GHz PHYs, less common in consumer gear). Above the MAC, Zigbee adds a network layer (mesh routing), an application layer of clusters (On/Off, Level Control, Color Control, Door Lock, and so on) grouped into endpoints, and a security layer built on AES-128-CCM*. Every payload is authenticated and usually encrypted under the network key; some traffic is additionally protected by an application link key.
Why it matters
A whole home's automation can share one network key. The classic weakness is key provisioning: in Zigbee's original "standard security" join, the coordinator hands the network key to a joining device encrypted under a well-known default Trust Center link key (the famous ZigBeeAlliance09). Anyone sniffing the moment a device joins can therefore decrypt the network key and, from then on, read and forge every frame on the mesh. Even where a unique install-code link key is used, forcing a device to re-join (by power-cycling it or jamming) can create a fresh, capturable join.
How the mesh works
| Role | Function |
|---|---|
| Coordinator | forms the PAN, is the Trust Center, holds the network key |
| Router | mains-powered, relays traffic, extends range |
| End device | battery sensor/actuator, sleeps, talks to one parent |
| Channel | 11 to 26 in the 2.4GHz band |
See the diagram for how the roles nest. The PAN is identified by a 16-bit PAN ID (and a 64-bit extended PAN ID); each node also gets a short 16-bit network address.
How to attack it
Use a radio that speaks 802.15.4, such as an nRF52840 or a CC2531 flashed for sniffing:
# 1. Find the active channel and PAN by scanning 11..26.
zbstumbler # KillerBee: locate networks/beacons
# 2. Capture into a pcap (feed into Wireshark's Zigbee dissector).
zbdump -c 15 -w join.pcap # sniff channel 15
# 3. If a device joins during the capture, recover the network key
# when the default Trust Center link key was used.
zbdsniff join.pcap # extracts the transported NWK key
# 4. Decrypt in Wireshark (paste the NWK key), then replay/inject.
zbreplay -r command.pcap -c 15 # replay a captured frame
killerbee is the reference toolkit (zbstumbler, zbdump, zbdsniff, zbreplay, zbassocflood). With the network key in Wireshark you can read cluster commands directly, then forge an On/Off or Door Lock command from a spoofed source.
Pitfalls
- Zigbee is not BLE and not Wi-Fi; it needs a genuine 802.15.4 radio. A generic Bluetooth dongle will not capture it, even though both live at 2.4GHz.
- Newer stacks and Zigbee 3.0 push per-device install-code link keys, so the
ZigBeeAlliance09shortcut may not apply. Confirm before assuming an easy key recovery. - Channel overlap with Wi-Fi is real. If capture is noisy, the network may simply be on a different channel; scan the full 11 to 26 range.
- Recovering the key needs the join event. If every device joined long ago, you must trigger a re-join, not wait for one.