Download this article in PDF format.
One of the biggest challenges while designing Internet of Things (IoT) applications is security. IoT devices talk over the air and can potentially expose all control and status information, as well as private user data. Instead of making lives easier, unsecured IoT devices potentially put human life and assets at risk. Imagine someone hacking into a home lighting control system to track when users are home and then breaking into the house. Or imagine someone trying to forge your identity and use to it to open your smart lock.
Three things must be implemented to secure IoT devices:
Mechanism to hide device's identity from unauthorized devices: Identity protection is essential to safeguard users from someone tracking their physical location. Without sufficient protection, IoT devices put users at risk of a privacy breach and possible physical or financial threat. It’s similar to someone following you based on your car's registration number.
Protection against passive eavesdropping: Passive eavesdropping is the process of listening to private communications between two devices. A passive eavesdropper quietly listens to communications and doesn’t alter the data. One such example is shown in Figure 1. Here, Pushek and Sachin are trying to have a private communication and a passive eavesdropper, Ashish, is listening to the communication without their knowledge.
1. A passive eavesdropper listens to communications but doesn’t modify data.
Protection against man-in-the-middle attacks: Man-in-the-middle (MITM) attacks are the most serious among all security threats. In this case, a third device called the MITM attacker not only listens to the private communication between two devices, but can mimic either device and alter the data. Figure 2 shows one such example.
2. Man-in-the-middle (MITM) attacks are among the most serious of security threats.
Hiding Device Identity from Unauthorized Devices
Bluetooth Low Energy (BLE) devices use a 48-bit address. If this address can be decoded by another device, that device can track the presence of the device. BLE makes it difficult for an un-trusted device to track by address by frequently changing the address. This is done using an Identity Resolving Key (IRK) that’s available only to trusted devices. An IRK is shared between trusted devices during the pairing process after the link is encrypted. It’s then stored internally as part of the bonding process. Such an address is called a Resolvable Private Address (RPA).
An RPA has two components: 24-bit hash and 24-bit prand (Fig. 3). The hash is a function of the IRK and prand consists of a 22-bit random number and two fixed most significant bits (MSBs).
3. A Resolvable Private Address (RPA) has two components: a 24-bit hash and 24-bit prand.
The 22 bits of prand are randomly generated with the condition that all bits cannot be either “1” or “0”. Then, the hash is calculated using encryption function “e” with IRK and prand as inputs:
Hash = e(IRK, prand), truncated to 24-bits
The device's IRK is a 128-bit number. To make the prand's size the same as the IRK, it’s concatenated with 104 bits of padding, with padding bits set to “0”. The least significant bit (LSB) of the original prand remains the LSB of the prand after padding. Once the hash is generated, it’s concatenated with the prand to generate the RPA.
To resolve an RPA, a local Hash is generated using the prand received in the advertising packet and IRK received during the pairing process. This local Hash is then compared with the hash part of address. If it’s a match, the address is resolved. Because a device may store IRKs from several devices, the local Hash is calculated one by one using each of the stored IRKs until there’s a match.
BLE v4.2 (and later) allows this address to be changed as quickly as once per second with a maximum period of 11.5 hours. This is known as the RPA timeout. The more frequently the RPA is changed, the more difficult it is to track the device.
Protection Against Passive Eavesdropping
Consider what happens when two people in a meeting suddenly switch to their native tongue that others around the table don’t understand. In effect, they’re protecting this particular part of the conversation from passive eavesdroppers. Similarly, BLE devices use a shared secret to encrypt the link. Thus, the conversation can’t be understood by devices that don’t have that secret. The strength of protection depends on the strength of the key—how easy or difficult it is to obtain or guess the key.
BLE (v4.2 or later) uses the Federal Information Processing Standard (FIPS)-compliant Elliptic Curve Diffie-Hellman (ECDH) algorithm to generate and exchange keys. These keys are then used to generate other keys, also referred to as the Shared Key of the DHKey. This can subsequently be used to encrypt the link or generate another set of keys for encrypting the link.
In BLE devices, the foundation of this secure communication is laid during the pairing process. Pairing is a three-phase process (Fig. 4).
4. With BLE, the foundation of this secure communication is established during pairing, a three-part process.
During phase 1, the two devices involved in the pairing process send the pairing request and response along with the pairing parameters, which include the devices' capabilities and security requirements. After this, both devices choose the pairing method based on values from the parameters exchanged.
Phase 2 deals with device authentication and link encryption. This phase establishes an environment that guarantees security from passive eavesdropping and MITM attacks.
As mentioned earlier, for protection against passive eavesdropping, BLE uses the FIPS-compliant ECDH algorithm. It enables devices to establish a shared key over an unsecured channel and later use it or its derivative to encrypt the link.
5. BLE uses the FIPS-compliant ECDH algorithm for protection against passive eavesdropping.
To understand how the ECDH algorithm works, consider the classic Alice and Bob example (Fig. 5). Alice and Bob want to establish a secure communication link, but the channel over which they’re communicating is being eavesdropped by a third party, Eve:
- Alice and Bob generate their own private and public keys, where private key, d, is a random number from [1 to n-1], and public key Q is obtained by multiplying d with G, dG. Assume Alice’s private and public keys are dA and QA = dAG, and Bob’s private and public keys are dB and QB = dBG, respectively.
- Alice and Bob share their public keys, QA and QB, with each other over the unsecured channel, which is being eavesdropped by Eve. Eve can intercept QA and QB but she cannot determine the private keys.
- Alice calculates a shared key using her own private key, QBdA, and so does Bob, using QAdB. Note, both the shared keys are the same as: S = QBdA = (dBG)dA = (dAQ)dB = QAdB.
- Now, Alice and Bob can secure their communication using this shared key or use this shared key to generate another key. Eve can’t calculate this key as she only knows QA and QB.
The above example assumes that both Alice and Bob are using the same domain parameters. In the case of an LE Secure connection, both devices follow the FIPS-compliant P-256 ECDH mechanism by default.
Once the two BLE devices have successfully generated the shared keys, they generate the Long Term Key (LTK) and the MAC key. The MAC Key is used to confirm that the keys generated are correct. On a successful confirmation, both the devices utilize the LTK to encrypt the link. Note, this LTK is never shared over the air; thus, the passive eavesdropper can’t calculate the LTK, nor can the eavesdropper intercept the information exchanged between the two devices.
While ECDH does provide protection against passive eavesdropping, it doesn’t prevent MITM attacks. For protection against MITM attacks, BLE uses authentication as part of Phase 2 of the pairing process. This is based on the I/O capabilities of the devices.
