How to ensure the security of BLE connections in IoT applications?

To ensure the security of IoT devices, the following three deployments are required:

Mechanisms to hide device identity from unauthorized devices - Identity protection is critical to protect users from bad actors tracking their physical location. Without adequate protection, IoT devices can expose users to privacy breaches and potential threats to life or property. This scenario is similar to someone tracking you based on your car registration number.

Protection against passive eavesdropping - Passive eavesdropping is the process of listening to private communications between two devices. A passive eavesdropper listens to the communications quietly but does not alter the data.

Protection against Man-in-the-Middle Attacks - One of the most serious security threats is a Man-in-the-Middle (MITM) attack, in which a third device, called a MITM attacker, can not only listen to the private communications between two devices, but can also impersonate either device and change the data.

Hide device identity from unauthorized devices

BLE devices use a 48-bit address that can be tracked in real time by another device if it can be decoded by the other device. BLE makes it difficult for untrusted devices to be tracked by frequently changing addresses. This is achieved by using an Identity Resolution Key (IRK) that is only available to trusted devices. After the link is encrypted, the IRK can be shared between trusted devices during the pairing process. It is then stored internally as part of the bonding process. This type of address is called a Resolvable Private Address (RPA).

A resolvable private address consists of two components - a 24-bit hash and a 24-bit prand. The hash is a function of the IRK, and the prand consists of a 22-bit random number and two fixed MSBs (most significant bits).

The randomly generated 22-bit prand cannot have all bits as '1' or '0'. After that, the hash is calculated using the IRK and prand as input variables of the encryption function 'e'.

Hash = e(IRK, prand), truncated to 24 bits

The device IRK is a 128-bit number. It is concatenated with 104 bits of padding, where the padding bits are set to '0', so that the size of prand is consistent with the IRK. The LSB (least significant bit) of the original prand remains the LSB of prand after padding. The generated hash is concatenated with prand to generate RPA.

To resolve the RPA, a local hash is generated using the prand received in the advertising packet and the IRK received during the pairing process. This local hash is then compared to the hash in the address. If they match, the address can be resolved. Since a device can store IRKs from multiple devices, the local hash value can be calculated one by one using each stored IRK until a match is found.

BLE 4.2 and later versions allow this address to change as fast as once per second, with a maximum change interval of 11.5 hours, which is called the RPA timeout. The more frequently the RPA changes, the more difficult it is to track the device.

Preventing Passive Eavesdropping

Imagine that in a conference, two people in a conversation suddenly switch to their native language, which is difficult for the rest of the meeting to understand. What happens? In this way, they actually protect this part of the conversation from passive eavesdropping. Similarly, BLE devices encrypt the link using a shared key. Therefore, devices without the secret key will not be able to understand the conversation between the devices after the link is encrypted. The strength of the protection depends on the strength of the key - that is, how easy it is to obtain or guess the key.

BLE (version 4.2 or later) uses the Elliptic Curve Diffie-Hellman (ECDH) algorithm that complies with the US Federal Information Processing Standard (FIPS) to generate and exchange keys. These keys are then used to generate other keys, also known as DHKey shared keys. The DHKey shared keys can then be used to encrypt the link or generate another set of keys to encrypt the link.

In BLE devices, the foundation for this secure communication is established during the pairing process. The pairing process is divided into three stages:

In Phase 1, the two devices involved in the pairing process send pairing requests and responses along with pairing parameters, which include the capabilities and security requirements of the devices. After this, the two devices will choose a pairing method based on the values ​​of the exchanged parameters.

Phase 2 involves device authentication and link encryption. This phase establishes a security environment that ensures that the device is immune to passive eavesdropping and MITM attacks.

As mentioned earlier, to prevent passive eavesdropping, BLE uses the FIPS-compliant ECDH algorithm, which enables devices to establish a shared secret key over an insecure channel and then use that key or a derivative of it to encrypt the link.

To understand how the ECDH algorithm works, we give a very classic example of Alice and Bob (see Figure 5). Alice and Bob want to establish a secure communication link, but the channel they are communicating on is being eavesdropped by a third party, Eve.

1. Alice and Bob generate their own private and public keys, where the private key d is a random number from [1 to n-1], and the public key Q is obtained by multiplying d by G, dG.

Assume that Alice's private key and public key are dA and QA = dAG, and Bob's private key and public key are dB and QB = dBG respectively.

2. Alice and Bob share their public keys QA and QB with each other on an insecure channel that is being eavesdropped on by Eve. Eve can intercept QA and QB, but she cannot determine the private key.

3. Alice uses her private key QBdA to calculate the shared key, and Bob uses QAdB to calculate the shared key. Note that the shared key is the same.

S = QBdA = (dBG)dA = (dAQ)dB = QAdB

4. Now, Alice and Bob can use this shared key to protect their communication or use it to generate another key. Eve cannot calculate this key because she only knows QA and QB.

The above example assumes that both Alice and Bob use the same domain parameters. In the case of an LE Secure connection, the two devices follow the FIPS-compliant P-256 ECDH mechanism by default.

Once two BLE devices have successfully generated a shared key, they generate a long-term key (LTK) and a MAC (Media Access Control) key. The MAC key is used to confirm that the generated key is correct. After successful confirmation, both devices will use the LTK to encrypt the link. Note that this LTK is never shared over the air, so a passive eavesdropper will not be able to calculate the LTK, and an eavesdropper will not be able to intercept the information exchanged between the two devices.

While ECDH provides security protection against passive eavesdropping, it does not protect devices from MITM attacks. To prevent MITM attacks, BLE uses authentication as part of Phase 2 of the pairing process based on the I/O capabilities of the device.

About the author:

Pushek Madaan is currently working at Cypress Semiconductor India as a Senior Application Engineer. He is primarily designing embedded system applications for analog and digital circuits using C and Assembly languages, and developing GUIs (Graphical User Interfaces) using C#.

Sachin Gupta is currently working as a senior product marketing engineer in the IoT business unit at Cypress Semiconductor. He holds a bachelor’s degree in electronics and communications from Guru Gobind Singh Indraprastha University, Delhi. Sachin has 9 years of experience in SoC application development and product marketing.

Produced by Global IoT Observer

Please indicate the source

Everyone is watching:

Revealed! List of Huawei's core mobile phone suppliers

Shortage and price increase, the "battle" in the CMOS image sensor industry!

Facebook joins the game, and the AI ​​chip war breaks out!

Advertising | Government investment | Industry report

Investment and Financing | Expert Consulting | Talent Services | Forum Planning

↓For cooperation needs, please click "Read original text" to contact us