Department of Computer Science
Security Mechanisms of wireless Building Automation Systems
Summary
Security Goals
The security mechanisms of a BAS should support confidentiality of the messages (no need to publish if I am at home or not), integrity (if a window sensor announces OPEN, I do not want to receive a CLOSED), and authentication (a CLOSED message with my window's source address should really come from that window and not from an intruder's laptop). Finally, availability of the whole system is another concern, but typically handled on a different level than the former three.
Encryption Mechanisms
Most (not all) BAS technologies support some form of AES encryption. While this is highlighted in product descriptions, it can mean a lot of different things and is not a synonym for a secure communication. More specifically, different variants of AES encryptions provide confidentiality, authentification, and replay prevention and must be combined to provide a certain level of security. Furthermore, AES must actually be applied to the messages (which is not allways the case!) and the encryption keys must be secret, which also cannot be taken for granted.
ZigBee
ZigBee comes in three versions. The first version, ZigBee2004, is deprecated. Current hardware does not support it anymore, making different ZigBee components incompatible. BAS hardware usually supports ZigBee2007 Standard Security in backward compatibility mode (to ZigBee2006). The standard is split into various sub-standards such as Light Link (for electric switches and bulbs) and uses a single network key to encrypt all messages within a single network. This network key is provided by the ZigBee controller, transmission is encrypted by a ZigBee master key. The Light Link master key is available on the Internet. Since any component can request the key anytime (without user involvement) the whole security concept becomes obsolete.
EnOcean
EnOcean focus includes low-energy BAS, enabling devices to perform energy harvesting: pushing the button of a switch produces enough energy to transmit the signal. Solar cells or differences in temperature are other methods supported by EnOcean hardware. The energy concepts limit the communication and encryption capabilities of the systems.
The initial distribution of the encryption key is based on a pre-shared master-key or unencrypted. The key is identical for all components served by a single base-station. Since key-exchange requires physical access to the gateway, it is difficult for an intruder to initiate this key exchange in order to get access to the encryption key in the network.
After this initial distribution of the encryption key, EnOcean seems to be a rather secure BAS, supporting encryption, authentication and integrity.
Experiments with a second EnOcean component revealed another problem. A window handle uses EnOcean to inform the base-station about its current status (open or closed). While the messages themselves were encrypted, OPEN and CLOSED messages were of different length. So while it was not possible to decrypt the message itself, it was easy to determine the status from the message length.
Z-Wave
For our experiments we used the MT2600 Home Control Central Unit and a MT02646 Metering Plug from devolo. Installation of the controller required Internet connectivity and an account on the devolo website. During the mandatory registration process, private user data had to be provided to devolo in order to gain access to the controller. To include a new component in the home network, the controller needs to be brought in peering mode via the Internet connection. While the specifications of the metering plug state that the plug supports 128 Bit AES encryption, the web-interface does not provide any related information and does not offer a method to enable or disable these settings.
We used third-party components for unencrypted communication to the plug. FHEM open source software running on a Raspberry Pi used a USB stick from Z-Wave.Me to send unencrypted messages to the plug. The plug reacted immediately to our unencrypted messages and could be switched ON and OFF.
Similar to ZigBee, a network key should be provided by the controller and encrypted with a master-key. The master-key is stored in the Z-Wave hardware and has been revealed.
Homematic
This system developed by eq-3 is one of the dominating BAS for private houses in Germany. Some of the systems support AES encryption and are equipped with a default key that is identical in all HM components. In the instructions, eq-3 discourages its customers from changing this default key. The default key is publicly available on the Internet. Tapping HM messages reveals that even in secure mode messages are not encrypted. In fact, while HM markets its products as secure with AES support, all messages are transmitted as plaintext. Secure mode is implemented as a simple challenge-response procedure where the AES key is used to authenticate the sender of a message.
KNX-RF
While KNX has its main market share as a wired bus-based BAS, its RF-version supports wireless command and control. The standard failed to develop any security mechanisms for many years, and has just recently released initial security mechanisms based on AES. Since vendors have not started to implement them, to the knowledge of the authors all KNX sensors and actors use insecure communication and can be easily controlled by an offender.
FS20
FS20 does not implement any security mechanisms.
DECT
AVM, the dominant provider of private households Internet access gateways (the Fritz!Box) has started to market DECT-based components such as heating control and plug sockets. The convenient aspect is that the controller is already installed in many households, the drawback is that DECT uses security mechanisms that have been broken many years ago and must be considered as insecure.