Keep Calm and Implement ZigBee Security
May 24th, 2016
At the end of last year, a group of researchers from Cognosec presented their “ZigBee exploited” report at the BlackHat conference in the USA. They demonstrated a tool that allows an intruder to open your doors, shut up motion sensors off and even turn the lights off in your bedroom, of course only if these devices are controlled via ZigBee. IT and for the most part non-IT sources repeated the news many times with excessive drama effect and as a result, we had got a categorical accusation of lack of security in ZigBee and even the entire IoT. Based on the forecast that there will be 29 billion of IoT devices in the not so far 2020, “experts” convinced their readers that it is not the problem of the future but the present and that all devices are vulnerable. Now when the panic has calmed down, let’s see what happened in terms of ZigBee.
First, let’s talk about silent motion detectors. Motion detection in the system that was hacked works the following way: when a sensor detects a movement it sends a ZigBee message to a gateway (you may call it smart hub, ZigBee hub, etc.), which uses TCP/IP to deliver this message to the user. Cognosec researchers used a jammer to break the ZigBee link between the sensor and the gateway. Even when the jammer had been turned off, the motion alarm was not retransmitted because the retransmit attempts were over or the sensor decided that the link was lost (we can only guess). Samsung, whose hub was attacked during the research, has already given the proper comment and we agree with it 100%: ZigBee Motion sensors are not designed to be a professional, highly secure alarm system. We wonder if anybody has already seen a professional alarm based on a wireless protocol. Although the jammer attack is not specially a weakness of ZigBee, it may be useful for those customers, who want to get an alarm but do not want to pay a high cost.
Moving on, now we are going to discuss the weakness that was introduced as a supermassive hole in the ZigBee security, but it is actually not ZigBee specification’s fault. The reality is that a large number of ZigBee devices available on the market use the default Trust center link key to encrypt active network key transport. This key is open and there is not much difference for security in sending the network key as plain text or encrypted by the default key. ZigBee specification warns developers about such threat and recommends out of band or not-by-the-air methods to deliver an initial master key to both the trust center and the device. Researchers criticize this recommendation because it is not a requirement when the required by the specification default trust center link key in its turn breaks the security. But why shouldn’t the not in-band key delivery be a part of wireless protocol specification? Moreover, as anybody, even researchers, agree, unsecured key transport is ideally performed only once, during an association and most likely is not a threat, of course unless a maniac with an enabled ZigBee sniffer is spying on your house 24/7. And here the thing that everyone is talking about comes to the surface. Assuming that a quick, low-power, unsecured key transmission is performed once, hackers enable their jammer again to force link loss. When the link is lost, there are two ways to get the key:
- A “typical” user triggers association one more time when an intruder’s sniffer is enabled;
- Device tries an unsecured rejoin (that is allowed by the specification).
Respectively, there are two ways to dispute:
- Strictly saying a “typical” user will most likely reset the device, reset doesn’t mean a factory reset, just power off/on. The reset will trigger a rejoin process and now we move on to the second point;
- Although ZigBee allows unsecured rejoin, secured one is not forbidden; it’s just a policy, an option that can be configured by the manufacturers. The problem wouldn’t exist if the devices under the test implemented secured rejoin. There also wouldn’t be any problem, if there weren’t high security requests to the devices that implement unsecured rejoin.
The main conclusion from our dispute is that the found exploit is not a “ZigBee” one, it’s “Current ZigBee implementation exploit.” It will not be superfluous to say that researchers from Cognosec are ZigBee users too and they pointed out that ZigBee specification provides all the good recommendations to build a secure system. But dramatic headlines and maybe mass hysteria turned the device problem into the core standard one. There won’t be any panic, if anybody interested in IoT (or ZigBee), based their opinion on the original source: