By John Chinnick | Jan 3, 2018
Wearables often communicate using radio protocols such as Bluetooth Low Energy (BLE), Zigbee, WiFi, Z-Wave, Cellular, or LoRa, among others. These protocols provide solutions that meet a spectrum of needs related to range, bandwidth, interoperability and power requirements.
BLE is a popular choice for wearables because of its balance of low power, relatively low range, sufficient bandwidth, and the abundant availability of Bluetooth-enabled phones and tablets to provide interoperability.
Let's consider what it takes to achieve privacy over BLE. Achieving true anonymity over BLE is not trivial.
Peripheral vs. Central Roles
Bluetooth devices have two primary roles: peripheral and central. Devices can operate in one or both of these roles simultaneously. However, each role impacts the resources required by the device, including power, bandwidth, code space, and RAM.
Peripherals advertise their presence using advertising packets. The advertising packets provide information about the peripherals to devices that are listening, such as the type of services the device provides, whether it is looking for a connection, some identity information and possibly some application state information. Peripherals do not get any feedback about whether another device is listening unless the device makes a connection request or requests extra advertising data.
Centrals listen for advertising packets and can choose to connect to devices that advertise using connectable advertising packets. There is no way for a central to connect to or send information to a peripheral except through responding to a connectable advertising packet with a connection request.
Transporting Data
BLE provides link-level encryption for transporting data over the link. The link encryption is setup through a pairing process to allow exchanging of secrets. But this pairing process is not very robust and successful attacks have been demonstrated for third-party devices to intercept the shared secrets.[i] Some improvements to the pairing process have been made with Bluetooth 4.2, however, these changes are not widely available yet.
The BLE protocol includes a privacy mode which uses random addresses to help achieve anonymity, but this is just one piece of the puzzle and is not enough for most applications. Random addresses can be resolvable, requiring bonding, or they can be non-resolvable.
After devices have formed a connection, device addresses are not used. The devices maintain connection through an agreed-upon channel hopping scheme. As long as the data in the communication does not use unique numbers that can be associated with the device, it will be difficult for third parties to determine which specific devices are talking. Eavesdroppers may still be able to monitor the exchange of messages between any two devices.
Designers that care about privacy need to take additional steps to protect the privacy of data within the system.
To Bond or Not to Bond
Bluetooth provides facilities to allow users to bond peripheral devices to central devices. This requires user action to initiate the bonding process. Bonded devices share long-term secret information with one another to enable them to use the built-in privacy modes in the Bluetooth protocol. Bonded devices may also store additional state information.
Most Bluetooth devices have limits to the number of bonded devices that they can support. Some users find the bonding process confusing and do not necessarily understand the security implications related to bonding devices.
One of the secrets that can be stored during bonding is the Identity Resolving Keys (IRKs). These IRKs allow the central device to recognize the peripheral that chooses to use resolvable random addressing mode. When using this mode the peripheral device can periodically change its advertising address so third parties that do not have the IRK cannot distinguish between devices that are using this mode.
Bonding is stored at the operating system layer on iOS and Android mobile devices. This means that other applications on the mobile device can use the same bonding information to recognize and connect to the peripheral. Bonding does not provide application-level protection for the device communications.
When application level protection is required, you can implement privacy features similar to the built-in Bluetooth privacy features without requiring pairing or bonding.
Application-Level Privacy
For any application, consider which device should be the central and which device should be the peripheral. The choice may have significant implications on device power consumption, complexity, and what information may be leaked about the user(s) of the system.
For effective application-level privacy, the device cannot expose unique identifiers that could be used by third parties to recognize the device. Device names, addresses, message sequence numbers, or any other information that may be static or follow logical sequences unique to this device could be used to track the device by third parties that eavesdrop on the device communications.
Unfortunately, one piece of information that a peripheral must disclose is at least one service identifier that recognizes what type of device is advertising. This is required to allow central devices to wake up when they see advertising packets with this service identifier present. Therefore, the third-party central will be able to see that there is at least one of these devices in the area when it is advertising. However, if the following steps are taken, it should not be able to identify which particular device it is.
Steps to Ensure Privacy
- For application level privacy to work, the system needs to share secrets between the device and the application. One mechanism could be to establish unique device names with private public key pairs that are provisioned in the factory. At a later date, a particular device could be associated with a specific user account through a device name.
- At any time, the device can perform a key exchange with the application to establish session keys and authenticate its identity using its private key to sign the request. The device should also be provisioned with at least one public key of the application so it can verify that it is talking to the authorized application as part of the key exchange. If this key exchange is done using ephemeral keys, then even the key exchange can be performed without revealing the identity of the device requesting the key exchange to any third party monitoring the exchange.
- One of these keys established during the key exchange could be an IRK similar to the Bluetooth IRK. The device could then advertise using the Bluetooth non-resolvable random address, but include a data field in the advertising packet with a randomized device address, which could be resolved with an application IRK by application nodes that have the corresponding IRK.
- Other keys in the exchange could be encryption keys used by the device to encrypt messages to the application or vice versa. Note the application may be the mobile device or it may be a backend service accessed through Internet connectivity from the mobile device.
- If it is the backend service receiving the message, then for efficiency reasons a different mechanism from the IRK method may be required to identify which device key should be used on the backend, i.e. rotating device ID or similar.
- Standard Bluetooth profiles will need to be examined to determine whether they can fit within an application that is concerned about privacy information. Any service that exposes unique numbers or sequential data that could be tracked back to the particular device should be avoided.
Using these methods, the peripheral and central can exchange information securely and privately using basic Bluetooth communication with or without bonding or link encryption enabled.
