Notes on Securing Unbonded BLE Interactions
Authors: Adam Incera and Hari Nair
At Latch, we care very deeply about the unlock experience of access products. In a world that’s becoming increasingly mobile, our mobile phones are at the epicenter of our daily workflows. We believe that access shouldn’t be any different. Today, we can perform bank transactions, book flights and order ride shares all from our mobile devices. Shouldn’t our phones also be able to provide us access into our homes without having to carry a physical key? Since our inception, Latch has worked towards making this idea a reality. As we built our first product, Bluetooth Low Energy (BLE) became the medium that would allow us to do that. In this blog post, we’ll share some of the challenges and key learnings that we faced along the way.
Bluetooth Low Energy or Bluetooth 4.0 is a wireless communication standard that’s particularly useful for short distance communication for low power applications. The communication happens over short distance ultra high frequency (UHF) radio waves at 2.400 to 2.485 GHz. BLE primarily works in two different modes: bonded and unbonded.
Bonded vs. Unbonded Connections
Traditionally, BLE is used for P2P communication for personal applications. For most use cases, this means that two devices pair with each other and exchange data. “Pairing” enables these devices to have a layer of security for the data transfer. One of the devices in this system takes up the role of the client, while the other takes up the role of the server. The client and server go through a negotiation process where they exchange information, such as I/O capabilities and security keys, and decide upon a mutually acceptable configuration. Once this process is complete, the devices are considered to be paired. This is especially useful if the pairing happens between devices that are not part of a shared proprietary system. Once the devices are paired, the protocol secures the connection, allowing products from multiple vendors to work together cohesively.
Security keys that are exchanged over the encrypted channel can then be stored in each of the devices to be used for encrypting any future data exchange. This process is called “bonding.” However, there’s only a finite number of devices that can be bonded to a device. The devices operating in a bonded infrastructure also need to be paired, which increases the amount of time it takes to connect to a device.
As we designed our BLE infrastructure, this presented a problem. We wanted our access management systems to support a large number of users. Pursuing the bonding route would mean every user would have to pair with the lock and bond with it for them to be able to interact with it. This would make for a slow and poor user experience.
The alternative was to use “unbonded” connections. This enabled us to unlock faster and support a larger number of devices. However, now our device was discoverable and connectable by any BLE device capable of scanning for BLE advertisements, and the data transfer between the two devices was unencrypted. We solved the unsecure data transfer problem by devising a proprietary encryption scheme, but that’s a different story for another day.
The realization that any BLE device can connect to our hardware presented a larger security problem. Any arbitrary device with malicious intent could potentially connect to our lock and hold onto the connection. This would then restrict a valid user from being able to connect to the lock. We realized that this challenge was similar to a very popular problem in the realm of network security. A popular cyber attack is a similar approach where an attacker tries to overload a server by creating fake requests and restricting valid requests from being serviced. This form of an attack is called a Denial-of-Service attack. As a result, we decided to call our attack scenario a BLE Denial-of-Service (BDOS) attack.
In the case of network DOS attacks, there are no elegant solutions, but developers can take measures to mitigate the impact of such an attack. In networking, this would mean deploying strategies such as load balancing, blackholing, or sinkholing. However, those are strategies that require large-scale resources, while we were working with low power, resource-constrained embedded systems. We decided to go back to the drawing board and consider a fresh approach. We decided that our solution should focus on the following:
- Detection
- Mitigation
Detecting a BDoS Attack
Once a client connects to a Latch device, the device waits for the client to send authentication data. In order to detect a BDoS attack, we track the number of BLE connections that fail without being authenticated. This can happen in two ways:
- Authentication is attempted, but the credentials are not valid.
- Authentication is never attempted, and the connection times out.
We’ll refer to either of these scenarios as a dropped connection. The device’s BDoS protections activate once it detects several dropped connections in a row. The dropped connection counter resets whenever a BLE client authenticates successfully. See the code snippet below for a sample implementation:
if (bleConnectionTerminated == true)
{
if (clientAuthenticated == true)
{
dosCounter = 0;
}
else
{
dosCounter++;
if (dosCounter > dosThreshold)
{
enterDosMode();
}
}
}Mitigating a DoS Attack
As we explored ways to mitigate such an attack, we decided that the solution needed to serve the following purposes:
- Stop the attacker from further tampering with the door.
- Alert a genuine user that the door isn’t accessible because someone had tried tampering with the lock.
The solution was to change advertising modes. BLE devices can advertise data in two different modes: connectable and non-connectable. While most BLE applications involve bidirectional communication between connected devices, a use case for one-way communication has emerged in the IoT space. These devices are called beacons.
A beacon doesn’t receive data from other devices or accept incoming connections, but simply broadcasts its advertising data. The advertising packets broadcast by a beacon contain data identifying the advertisement as non-connectable. This allows us to meet both of our criteria: by only allowing one-way communication, we prevent any further tampering while maintaining the ability to alert the user that something is amiss.
When an attack is detected, the device sets a flag denoting that it’s now in “BDoS Mode,” and alerts the BLE chip to begin non-connectable advertising. The Latch App detects this change in state, notifies the resident or property manager that someone might be tampering with the device, and suggests that they use a door code or NFC card to authenticate. The device remains in this state until a user successfully authenticates using either an NFC card or a passcode.
The following diagrams illustrate the advertising modes of a device in BDoS mode as opposed to a device in normal operation mode:
In summary, our solution uses core bluetooth capabilities to detect when a malicious attacker attempts a BDoS attack on our devices. Once detected, our device shifts to a BDOS mode and notifies users about the attack, while also providing them with an avenue to successfully authenticate and unlock their door.
Latch has applied for patent protection for this implementation. We believe that as IoT products mature, unbonded BLE connections will continue to be more common than they are today, and developers can benefit from implementing something similar in their products. Taking this into account, we plan to freely license any resulting patent related to this technology upon issuance.
