Securing a BLE connection

Since 2017, security experts have identified numerous flaws in Bluetooth software that affected several operating systems, including Microsoft Windows, Google’s Android, Apple iOS, and Linux. Some of these flaws ( which were collectively called “BlueBorne” ) could allow an attacker to access BLE systems or devices without authentication, thereby gaining access of the entire device. Even though, BLE 5 has largely addressed this problem by implementing bit-level security and the 128-bit key authentication, it still remains a concern for most BLE-based solutions - especially medical devices.

A BLE connection happens between 2 devices - a Central device ( which is the client ) and the Peripheral device ( which is the server ). Typically, a peripheral device is a gadget / IoT device with a defined purpose, like a smart watch, smart lock, or smart light. If our smartphone can offer services / send data to other devices, it may occasionally function as a peripheral. A peripheral can broadcast its presence. The central device scans for available peripherals, and in response to the advertisement, it sends a scan request and subsequently establishes a connection.

Securing a connection can start with Pairing. During the pairing process, devices exchange information required for authentication and this normally consists of two to three steps. Gadgets essentially identify themselves and describe what they are (a health band, a keyboard, a headset, etc.) and what they can do. The communication is not encrypted.

Key generation and exchange take place during the second pairing phase. BLE connections can be vulnerable at this time. Attackers may be able to take control of devices and the data they communicate if the connection is not secured. BLE developers often work very hard to secure the second phase because it is the most vulnerable stage in connections.

The third step is optional and only occurs if the devices are going to bond. During the bonding procedure, devices save the authentication information they traded during the initial steps in order to remember each other as a known ( or secure ) device when reconnecting later.

Privacy for BLE devices

In BLE, enabling privacy prevents other untrusted devices from tracking a particular peripheral device. The peripheral can prevent other central devices from decoding its address and thus maintain anonymity. In such cases, the two devices communicate using a private key known as the Identity Resolving Key (IRK). The peer device that keeps the IRK generates a random address that can only be resolved by that specific peer device.

Normally, every bluetooth device will be assigned a 48-bit Bluetooth device address, or BD_ADDR. These addresses fall into two categories: random device addresses and public device addresses. The public device address is composed of two 24-bit integers, known as a business ID and a company-assigned ID.

On the other hand, the address for the random device is generated randomly and can be either a static random address or a private random address. The static random address remains the same even after rebooting / powering down the device. But the private random address changes in each power cycle. The two subcategories of private random addresses are non-resolvable private addresses and resolvable private addresses (RPA ).

The Resolvable Private Address (RPA) is the backbone for privacy in BLE devices. An RPA is an address that's generated using a random number and the secret Identity Resolving Key (IRK).