IoT Security Using BLE Encryption

Bluetooth Low Energy (BLE) is suitable for battery-powered wireless IoT sensors that perform short data transfers. To function, the IoT sensor communicates with a gateway over a BLE wireless link. The gateway then may control the sensor or connect it to a controller in the network. BLE link-layer security is designed to protect information transferred over this wireless link. In this article, I'll review the strengths and weaknesses of BLE link-layer security.

The sensor and gateway must be “paired” with one another before they can perform any data transfer. The two main pairing methods in BLE are passkey entry and numeric comparison.

Passkey entry pairing

In this method, a sensor displays a 6-digit pairing code and the user enters it in the gateway or vice versa. Alternatively, if both devices have numeric keypads, the user can enter the same pairing code in them. Each device then verifies the code with the peer. The verification is performed by sending 20 wireless messages by each device. Each message carries cryptographic hash of a data block containing one bit of the pairing code (code is 20-bit binary number). BLE recommends using a fresh code for every new pairing. The probability of an attacker correctly guessing the code in any one attempt is one in a million, which just meets the mark for password security set by FIPS 140-2 standard. Thus, passkey entry pairing provides adequate mutual authentication security.

BLE Link Security Graphic.png

The BLE standard does not provide an authentication solution for sensors that have neither a display nor a keypad. These sensors use static pairing codes built into them and rely on users to maintain secrecy of the codes. However, even with code secrecy, this authentication method is susceptible to attack. An attacker only needs up to 20 pairing attempts to crack the static code, as he gets feedback on at least one bit of the code in each failed or succeeded pairing message. This makes such sensors vulnerable to phishing schemes: An attacker can make the sensor connect to a rogue gateway and control the sensor.

Sensors can add progressively increasing delays after failed pairing attempts to slow down this attack. However, pairing attempts can be spread over time or done from multiple devices to evade this delay mechanism. A better solution would be for the BLE standard to provide an option in the passkey entry pairing to send a hash of the entire 6-digit code in one message to the peer. Then, there will be only one in a million chance of the attacker correctly guessing the code in one pairing attempt.

For now, this attack can be avoided by limiting the time window when the sensor accepts pairing requests. The time window may be initiated by an administrator operating some control on the sensor. This countermeasure assumes that the attacker would not have physical access to the sensor. Operating the sensors in non-discoverable mode is another measure to make it harder for an attacker to locate the sensors.

Numeric comparison pairing

This method requires devices with displays and some means for the user to provide yes/no feedback. A pairing code is generated by each device using cryptographic techniques and displayed to the user. A user then compares the codes displayed on the two devices and provide yes/no feedback on whether they match. The numeric comparison model provides adequate mutual authentication security.

Sensors that do not have display and input capabilities commit “yes” to the pairing code generated without obtaining user confirmation. The BLE standard calls this a "Just Works" operation. Just Works operations provide no authentication and the pairing code becomes superfluous. Limited pairing time window and operating sensors in non-discoverable mode are measures to avoid phishing attacks on Just Works sensors.

Data encryption and integrity

BLE uses the AES-CCM cipher with 128-bit key length to provide data encryption and integrity over the wireless link. AES-CCM is a FIPS 140-2 approved cipher and is also used for security in other popular applications such as WiFi WPA2 and TLS 1.3. According to recommendation of NIST, 128-bit key length is considered secure until  2030.

The key is generated using Diffie-Hellman method with elliptic curve cryptography (ECC). Each device generates the same AES-CCM key at its end using the ECC public key received from the peer and its own secret ECC private key. ECC is a modern technique that provides strong security with small public-key sizes.

With these mechanisms, BLE has introduced state-of-the-art encryption and integrity protection at the link layer. Pairing methods provide adequate authentication between devices when executed as specified in the standard. However, when IoT sensors do not have requisite user input/output capabilities, they use static pairing codes or Just Works pairing. In these instances, additional security measures are needed to protect sensors from phishing attacks.