Secure Design for Low Energy Bluetooth (BLE) Applications

Low Energy Bluetooth (BLE) is widely used in various smart devices and IoT scenarios as a low-power, short-range wireless communication technology. However, due to the characteristics of BLE, it is susceptible to various security threats. Therefore, when designing and developing BLE applications, it is crucial to focus on security issues and implement appropriate security measures to protect communication data and user privacy.

Firstly, Security Measures for Bluetooth Pairing

In the pairing process between BLE devices, it is essential to use FIPS-approved algorithms such as AES-CMAC and P-256 elliptic curve to ensure the security of pairing information. Pairing information should be stored in a secure storage location on the device to prevent malicious attackers from stealing it.
For authentication and encryption, FIPS-approved algorithms should also be used to ensure the confidentiality and integrity of communication data. For example, the use of AES-CCM algorithm can encrypt and protect data transmission, while also ensuring the integrity of messages. In healthcare devices, such as a health wristband communicating with a smartphone, the use of AES-CCM algorithm encrypts the user's health data to ensure its confidentiality.
To prevent passive eavesdropping and man-in-the-middle attacks, user-assisted secure simple pairing methods can be used. For instance, using the ECDHE algorithm for Simple Secure Pairing (SSP) to prevent passive eavesdropping attacks, and employing the user-assisted digital method Passkey Entry to prevent man-in-the-middle attacks.
Here is the description of the Bluetooth Simple Secure Pairing (SSP) implementation example:
Device Preparation
• Device A (Initiator): a Bluetooth device, such as a smartphone.
• Device B (Responder): a Bluetooth device, such as a Bluetooth speaker.
Pairing Steps
1. Device A and Device B both support Bluetooth 2.1 or higher and SSP.
2. Device A and Device B are both in discoverable mode, ready to pair.
3. Device A sends a pairing request to Device B, and Device B starts the pairing process upon receiving the request.
Pairing Process
1. Device B generates a random number (Nonce) and sends it to Device A.
2. Device A receives the random number and generates its own random number (Nonce), which is sent to Device B.
3. Device A and Device B both use their own random numbers and the other's random number to calculate a shared secret key (Shared Secret).
4. Device A and Device B both use the shared secret key to calculate a pairing key (Pairing Key).
5. Device A and Device B both use the pairing key to encrypt their identity information (Identity Information) and send it to each other.
6. Device A and Device B both verify each other's identity information, and if the verification is successful, the pairing is complete.
Verification Steps
1. Device A and Device B both compare the other's identity information with their own, and if they match, the verification is successful.
2. Device A and Device B both store the pairing key in their devices for future connections.

Secondly, Security Measures for Bluetooth Privacy

To protect the privacy of BLE devices, address randomization can enhance device security. By frequently changing the Bluetooth device address, it reduces the difficulty for attackers to track BLE devices over a long period. Furthermore, to reconnect known devices, the device's private address must be resolvable by other devices, which requires using the device identity resolution key exchanged during pairing to generate the private address. For example, in a retail store's iBeacon system, changing the iBeacon device's Bluetooth address frequently can prevent malicious tracking of user behavior, thus protecting user privacy.
Here is the implementation example:
Device A (BLE Device)
• Hardware: BLE microcontroller with a random number generator (RNG)
• Software: BLE stack with address randomization and pairing process implementation
Device B (Central Device)
• Hardware: BLE microcontroller with a random number generator (RNG)
• Software: BLE stack with pairing process implementation and device identity resolution key storage
Address Randomization Process
1. Device A generates a new random address (RA) using its RNG.
2. Device A sets the new RA as its Bluetooth address.
3. Device A stores the RA and a corresponding index (e.g., a counter) in its memory.
Pairing Process
1. Device A and Device B initiate a pairing process using a standard BLE pairing protocol (e.g., SMP).
2. During the pairing process, Device A and Device B exchange their respective public keys (PK_A and PK_B).
3. Device A and Device B use their public keys to generate a shared secret key (SSK) using a key agreement protocol (e.g., ECDH).
4. Device A and Device B use the SSK to generate a device identity resolution key (DIRK).
5. Device A and Device B store the DIRK in their respective memories.
Private Address Generation
1. Device A uses its RNG to generate a new private address (PA) based on the RA and the DIRK.
2. Device A sets the PA as its new Bluetooth address.
Reconnection Process
1. When Device B wants to reconnect to Device A, it uses the DIRK to generate the PA.
2. Device B sends a connection request to the PA.
3. Device A receives the connection request and verifies the PA using the DIRK.
4. If the verification is successful, Device A accepts the connection request and the two devices reconnect.
Security Benefits
• The frequent change of the Bluetooth address (RA) makes it difficult for an attacker to track the device for an extended period.
• The use of the DIRK to generate the PA ensures that only authorized devices can resolve the private address and reconnect to the device.
• The private address (PA) is not publicly visible, protecting the device's privacy.
This implementation example demonstrates how address randomization and private address generation using a device identity resolution key can enhance the security and privacy of BLE devices.

Thirdly, Security Measures for Bluetooth Denial of Service Attacks

A common form of Bluetooth denial of service attack involves attackers continuously maliciously connecting or pairing with Bluetooth devices, causing the Bluetooth channel to be occupied and therefore unusable. To prevent denial of service attacks, a Bluetooth firewall mechanism can be used. When faced with denial of service attacks, enabling a whitelist mechanism and gradually increasing the delay time for new pairing can prevent continuous brute-force attacks by malicious devices. During the delay period, only devices within the whitelist are allowed to connect, ensuring the availability of Bluetooth services.

For example, the following is an example of the protection measures inspired by iPhone 6S unlocking attacks prevention using increasing delay times to prevent continuous brute-force attacks that render Bluetooth services unavailable. The attempt number resets after a successful connection or pairing.

Fourthly, Security Measures for Bluetooth Relay Attacks

Relay attacks are a common Bluetooth security threat where attackers use a relay device to pass communication data between communication parties, aiming to steal sensitive information or execute malicious operations. Limiting the communication distance between BLE devices can effectively prevent relay attacks. By controlling the transmission power of BLE devices or using location technologies, the distance between communication parties can be kept within a controllable range, reducing the likelihood of relay attacks.
Implementation Example:
Device A (BLE Device)
• Hardware: BLE microcontroller with a power amplifier and a distance measurement unit (e.g., RSSI or TOF)
• Software: BLE stack with transmit power control and distance measurement implementation
Device B (BLE Device)
• Hardware: BLE microcontroller with a power amplifier and a distance measurement unit (e.g., RSSI or TOF)
• Software: BLE stack with transmit power control and distance measurement implementation
Distance-based Relay Attack Prevention
1. Device A and Device B are configured to operate at a minimum transmit power level to ensure a maximum communication distance of a given meter.
2. When Device A and Device B are paired, they exchange their respective transmit power levels and distance measurement parameters.
3. During communication, Device A and Device B continuously measure the received signal strength (RSSI) or time of flight (TOF) to estimate the distance between them.
4. If the estimated distance exceeds a predefined threshold (e.g., 2 meters), Device A and Device B will reduce their transmit power levels to minimize the communication distance.
5. If the estimated distance continues to exceed the threshold, Device A and Device B will terminate the connection to prevent a potential relay attack.

In conclusion, the application of secure design for low energy Bluetooth (BLE) needs to comprehensively consider security mechanisms such as pairing, binding, authentication, encryption, message integrity, relay protection, Bluetooth privacy, and firewall to ensure the security and reliability of BLE communication. Only by fully considering security during product design and development can potential security threats be effectively mitigated, safeguarding the security of user data and privacy.