I was reading an article in the MIT technology review, titled "Hacking the Smart Grid", which is typical of many articles I have seen regarding Smart Grid security. They all seem to draw the same conclusions, which are basically:
- Vulnerabilities discovered in early implementations of devices and software could lead to the whole Smart Grid being hacked
- The technology these meters is based on is hopelessly insecure.
To be fair to this article, it does state that the threats are theoretical and concludes that much has and is being done by the utilities to ensure security.
However, I do want to focus on some of the allegations focused at ZigBee in the article.
The statement "Most of the wireless meters are subject to the same vulnerabilities that we saw [in Wi-Fi devices] 10 years ago." is an unsubstantiated comment comes from someone who seems to be a colleague of Josh Wright’s. WiFi (802.11) encryption started with WEP, which was broken from the get-go. ZigBee is based (and always has been) on AES-CCM, the same encryption and integrity checking protection (CCMP) used in 802.11i/WPA2, which is NIST special publication SP 800-38C based on NIST standard FIPS-197. The key management used for ZigBee Smart Energy devices is based on ECC public key cryptography using certificates; this technology is not used in WiFi.
However, in a lot of respects, you can’t really compare the two as a meter has functionality embedded into it all the way up the stack from the physical communication medium it uses for its network (usually wireless or BPL) to the application layer. WiFi devices stop at the MAC layer. In other words, they are used in conjunction with other devices, such as PCs, which would, for example, provide the public key technology for TLS used for secure web site transactions.
The article then mentions the IOActive ‘meter worm’. This was regarding a specific meter on an AMI network, the network the utility uses, not the home area network. So whilst this type of vulnerability certainly needs to be discovered and fixed, it is nothing to do with ZigBee, which the article mainly seems to focus on.
The ZigBee stack specification itself provides a general toolkit of functionality in all areas, including security. This makes it as flexible as possible with regard to the wide range of applications ZigBee can be used in. Actual implementations using the ZigBee stack are tightened down in two ways. Firstly, the platform can use two feature sets (profiles) of the ZigBee stack specification, namely ZigBee and ZigBee PRO. These mandate certain optional features in the stack specification and provide a platform specification to which platform vendors (e.g. chip and toolset vendors such as Atmel, Ember, Freescale, Jennic and TI and module vendors such as Digi) can implement and test against. These platforms still leave certain options open. Beyond that, there are the specific application profiles, including the ZigBee Smart Energy Profile (SEP), which provide even tighter specification for the ZigBee stack specification beyond those in ZigBee and ZigBee PRO feature sets and also provide the application specification itself.
Regarding the KillerBee application and its accompanying presentation Josh Wright gave at ToorCon:
Attack 1: OTA key delivery
As mentioned, the ZigBee specification provides a general toolkit of security mechanisms which can be used together to build systems of varying level of security. This includes one where a key can be sent OTA (over-the-air) in the clear. The very mention of this seems to cause many to throw their hands up in horror and claim “ZigBee is insecure”. However, it is important to be able to do this. A simple example is for commissioning; for cost reasons and simply because they don't need them, ZigBee devices may have no other interface than the radio itself. When devices come off the factory floor, they are “vanilla”, i.e. have no configuration for their intended operation. One simple way to configure devices which may only have a radio interface, is to use the radio to program keys in. This is done in a factory environment, often in a shielded room, and/or with low power transmitters. Once the keys are in there, the device can be used operationally in a secure way where keys are never sent OTA in the clear. If the device can be commissioned in other ways, then keys can be programmed in other ways. So while Josh Wright’s presentation highlights the ability to do this, it doesn’t mean that every ZigBee system does it this way.
Specifically, the ZigBee Smart Energy Profile does not allow this, so this attack cannot be used against ZigBee Smart Energy implementations. These use public key-based (ECC) certificates which are cryptographically bound to the device, which are used to negotiate a shared key, which is never communicated OTA in the clear. This is then used to provide further security for transporting other keys as required in the ZigBee system. Note here that packets carrying critical information are secured twice; at the network layer and at the application layer. This is the same principle as using 802.11 WPA2 encryption for the wireless, then TLS on top of that.
Attack 2: Replay attack
He claims 802.15.4 has ‘no replay protection’. As one of the MAC/security technical editors for the 802.15.4 specification, I can assure him this is not the case and would like to point him to the 802.15.4-2006 specification (e.g Table 93).
He then says ZigBee has ‘meager’ replay protection. It is a subjective adjective, so I am not sure what he means exactly. But again, ZigBee has frame counters and freshness checking built into the specification, which is mandated for ZigBee PRO and all application profiles built on ZigBee PRO, which includes ZigBee Smart Energy. So it is very slightly possible that he may find some arcane (likely private profile) ZigBee implementation which doesn’t implement freshness checking but I doubt very much it will be one with a ZigBee Smart Energy certified meter in it.
Attack 3: Hardware is the new Software
This is one area where I agree with Josh Wright, Travis Goodspeed and others. Given the cost sensitive nature of 802.15.4-based implementations and the relatively early stage of their deployment, it is likely that vulnerabilities will be found in these early embedded systems and it does present a difficult challenge. Easily extracting keys used for encryption should be preventable so the onus is on the chip, software and OEM vendors to ensure that their respective platforms provide the basis for secure systems going forward. To some extent, it could be argued that any device can be hacked, given the time and the inclination, which is why critical devices tend to be much more securely implemented, using mechanisms such as tamper-proof switches which erase all persistent records and render the device useless if broken open. Systems must also be designed with risk mitigation in mind so that compromising one device (especially such as an in-home consumer device) cannot possibly affect the rest of the system. Smart Grid security is looked at in this way; the NISTIR 7628 goes into great detail on the Smart Grid system and its subcomponents and their logical interfaces and security requirements.
Thoughts on ZigBee
The statement “ZigBee has problems with CCMP as a stream cipher and IV reuse (known plaintext recovery)” doesn’t have any substance to it. Any stream cipher has potential IV reuse issues, no matter where it is used and ZigBee and 802.15.4 implement a frame counter to ensure this doesn’t happen, whereby a key cannot be used if the frame counter expires.
To conclude, there is absolutely no doubt that the security of the Smart Grid is of paramount importance and is being taken very seriously by the utilities and manufacturers. I, for one, value the efforts of Josh Wright, Travis Goodspeed and others to find vulnerabilities in protocols and implementations as this will only lead to more secure systems. As the article suggests, the fact that "it is getting really, really difficult to find these holes now" underlines the importance the utilities put on security and considering we are still at the very beginning of this hugely important roll-out, that is a significant achievement.
