Understanding Security in IoT: WPAN Link Layer

In our last post of this security series we started to look at security in wireless networks. Specifically, we explored Wi-Fi link layer security and how much protection it offered our IoT products. In today’s post we are going to continue to look at security in wireless networks but this time we’ll be looking at WPANs (Wireless Personal Area Networks) such as Bluetooth and ZigBee. These technologies have a lot to offer IoT products as they provide much lower power wireless communications than Wi-Fi. But an important question that any developer must ask themselves is will my user’s data be secure if I use them?

Continuing with a theme from our previous post here is the tl;dr version – yes your user’s data can be secured if these technologies are used correctly. Let’s take a more in depth look to find out exactly how to do that.

Bluetooth – Including LE

Bluetooth is a hugely popular wireless technology that has seen use in a number of fields including wireless headsets, keyboards, mice as well as more recently in wearable fitness products such asFitbit. There are roughly speaking two variants, Classic Bluetooth (officially Bluetooth BR/EDR – basic rate/enhanced data rate) and Bluetooth LE – low energy. As the name suggests Bluetooth LE (or BLE) was intended for particularly low energy devices; for example those wearable fitness products we discussed earlier. From a security point of view there are some differences between how the two variants secure their data exchanges.

Classic Bluetooth

In Bluetooth the term pairing refers to the process of creating one or more of the shared keys that will be used to encrypt data exchanges. To ensure we have good security we need not only a good encryption mechanism but also a good pairing mechanism – otherwise a device’s shared keys could become compromised and a passive eavesdropper could collect and decode all your devices communications.

Depending on what version of Classic Bluetooth your device supports your security will fall into one of three categories Legacy Pairing, Secure Simple Pairing (SSP) or Secure Connections. Legacy Pairing involves a user entering a PIN on the two Bluetooth devices to be paired. The devices then independently create an initialisation key, exchange encrypted random values and derive a link key. As a final step in the two devices mutually authenticate one another to ensure they both have the same link key. While this may seem secure, if an attacker can eavesdrop on the pairing process they can mount an offline attack to recover the pin. Yaniv Shaked and Avishai Wool outlined such an attack in their paper Cracking the Bluetooth PIN.

In addition to this, Legacy Pairing also encrypts data using algorithms from the SAFER+ encryption suite. The National Institute of Standards and Technology’s Guide to Bluetooth Security notes that the suites E0 algorithm (which is used in the Legacy Pairing encryption phase) is not a Federal Information Processing Standards (FIPS) approved algorithm and has been questioned in terms of its strength.

Secure Simple Pairing

SSP was introduced in Bluetooth version 2.1 and utilizes FIPS-approved algorithms for key exchange. SSP mitigates against passive eavesdropping attacks by employing Elliptic Curve Diffie Hellman key exchange.

SSP also introduced the concept of association modes to Bluetooth pairing. Association modes are the means by which two Bluetooth devices are allowed to pair to each other. They include Numeric Comparison, Just Works, Out of Band and Passkey Entry. Numeric Comparison is used if both devices have display screens and can accept a yes/no input. Numeric values are displayed on both devices and if the match, the user should accept the pairing. Numeric Comparison offers protection against Man-In-The-Middle (MITM) attacks.

Just Works is used for pairings where one device has no input or display capabilities. In this case a user may be prompted to just accept the connection – assuming the second device has display and input capabilities. Just Works offers no MITM protection.

Out of Band (OOB) pairings include implementation dependent mechanisms for device discovery and key exchange. The mechanism should include security measures to ensure that the key exchange isn’t compromised. A properly implemented OOB pairing can provide protection from both passive eavesdropping and MITM attacks.

Passkey Entry pairing is primarily used where one device has input capabilities and the other has display capabilities. A six digit number is displayed on one device and then entered on the other. The values are compared to complete pairing. Passkey Entry provides protection against MITM attacks.

Secure Connections Only Mode

Secure Connections Mode (sometimes referred to as “FIPS Mode”) uses only FIPS approved algorithms. It modifies SSP slightly in that it uses the P-256 elliptic curve for key exchange – as opposed to the P-192 curve that is used in SSP. Additionally, Secure Connections uses AES-CCM encryption. If securing your data is more important than backwards compatibility Secure Connections Mode should be used.

Secure Connections retains all of the association modes introduced in SSP.

Bluetooth LE

Bluetooth LE has two pairing modes, LE Legacy and Secure Connections. LE Legacy pairing is similar to Classic Bluetooth SSP but with two important differences. There is no Numeric Comparison association mode and perhaps more importantly does not use ECDH key exchange.

Bluetooth LE also supports Secure Connections. LE Secure Connections supports and is functionally equivalent to all four association modes from Classic Secure Connections.

In both variants of Bluetooth LE pairing AES-CCM is used for encrypting data.

Clearly a serious drawback to LE Legacy pairing is the lack of passive eavesdropping protection during the pairing stage. In order to effectively protect users’ data developers should look at using LE Secure Connections or alternatively employing and OOB pairing mechanism that protects against eavesdroppers.

ZigBee

ZigBee is another low power wireless network technology that is gaining popularity within the IoT market. As with Bluetooth the first step in establishing secure communications between devices in your ZigBee network is key exchange. This exchange is generally done when a ZigBee device joins a new network. It can be carried out between a new and existing device or between a new device and a network Trust Centre if one is installed in the network. The ZigBee specification states that keying material will be obtained by key-transport, key-establishment or pre-installation.

Pre-installation of link and network keys is one way of ensuring that the keys aren’t compromised. However, key-transport and key-establishment depend on master keys to establish the link and network keys. The master keys can be pre-installed or exchanged using key-transport. Clearly, compromise of this master key is the first step towards compromising a ZigBee network.

Pre-installed master keys come with two issues. If you make your master keys specific to your product range you risk interoperability with other vendors. On the other hand if you use a common master key that is used by several vendors you leave yourself (more) exposed to a passive eavesdropping attack.

Master keys can be installed using an Out of Band method. Such methods may add the security that is required for an application.

Conclusion

The two avenues for attack on a Bluetooth or ZigBee network are attacking the encryption directly and compromising the keys. Attacking the encryption can be mitigated by only using implementations that employ stronger encryption – specifically AES-CCM. Key compromise can be a little trickier, however.

Key compromise can happen at generation time – this is advantageous to an attacker as it sometimes means keys or sufficient information to derive keys will be transmitted wirelessly. Or it can happen by accessing the device and reading the keys – this is less advantageous to an attacker as it often (but not always) requires physical access to the device.

With Bluetooth we saw that all implementations from SSP onwards employ ECDH key exchange. ECDH is very robust and should offer users protection against passively eavesdropping the key exchange step.

With ZigBee, link keys and network keys can be exchanged in an encrypted format. But as we saw this requires knowledge of a master key to the two devices exchanging keys. To ensure this master key isn’t compromised it should never be transmitted wirelessly – as such transmission would be unencrypted. Using pre-installed master keys can be effective but also has draw backs. An Out of Band exchange method, for example via a USB cable, should mitigate the threat from a passive eavesdropper.