If you want to create a Bluetooth-connected device, chances are you’ve considered using Bluetooth Low Energy (BLE) and have heard about BLE security issues. Lemberg has experience creating BLE-enabled IoT devices, and based on this experience we want to shine some light on how attackers can exploit your connected devices and how you can protect them.
Let’s start by explaining the basics of Bluetooth Low Energy technology.
Article content
When is a Bluetooth Low Energy connection vulnerable?
Major threats to Bluetooth Low Energy security
What is BLE?
There are two different types of Bluetooth technology: Bluetooth Classic and Bluetooth Low Energy.
Bluetooth Classic is the technology you’ve probably interacted with the most. It’s used for continuous transmission of vast amounts of data across relatively short distances. Think of wireless speakers, keyboards, and headsets: these devices make use of Bluetooth Classic technology.
Bluetooth Low Energy, on the other hand, is used for periodic transmission of smaller data packages. Periodic is the key word: BLE remains in sleep mode at all times except when participating in a data exchange, which reduces overall energy consumption. This alteration to the original Bluetooth specification has allowed manufacturers to create a plethora of small wearable devices that can run for up to several years on a small battery. Good examples of BLE-enabled devices are fitness trackers, iBeacons, blood pressure monitors, and industrial sensors.
There is a specific topology of Bluetooth Low Energy networks: devices can either be central or peripheral.
- Central devices — smartphones, tablets, computers, etc. — have greater processing capabilities and are responsible for controlling peripheral devices. Central devices usually run software created specifically to interact with peripheral devices.
- Peripheral devices serve as sensors that collect data and send it to central devices for processing. These peripheral sensors can be anything from wearable medical monitors to industrial thermostats: the key is that they do not process data; they only collect it.
When is a Bluetooth Low Energy connection vulnerable?
It’s almost impossible to hack BLE modules in devices that have already verified a connection. However, in order to connect, devices need to pair first, and this is where the main vulnerability of BLE-enabled systems resides.
The pairing process happens in two to three phases, during which devices exchange data necessary for authentication, such as keys and input/output capabilities. We say two to three phases because the third phase is optional and happens only if the devices are going to bond.
Bonding is a process during which devices store the authentication data they exchanged during the first pairing, which allows them to remember each other as secure when reconnecting in the future. Let’s look at the pairing phases in more detail, as they’ll help us understand the vulnerability of BLE.
As we’ve mentioned, during the first phase of pairing, devices exchange basic information about their capabilities in order to figure out how to proceed with the connection. Basically, devices identify themselves on the network and explain what they are (a Fitbit, a keyboard, a headset, etc.) and what they can do. This exchange is not encrypted.
The second pairing phase is dedicated to generating and exchanging keys. It’s at this point that BLE connections can be tampered with: If the connection is not secured properly, attackers can take control of devices and the data they transmit.
Because the second phase is such a vulnerable point in BLE connections, creators of the technology have put a lot of effort into securing it. We can differentiate two types of BLE connections — Legacy and Secure — which BLE module programmers can choose between:
- Legacy connections can be implemented for BLE versions 4.0, 4.1, and 4.2. The process is simple: Devices exchange a value called a Temporary Key (TK) and use it to generate a Short Term Key (STK), which is then used to authorize the connection. BLE Legacy connections are insecure by default but can be protected with the appropriate pairing method.
- Secure connections were introduced with BLE 4.2 and are not compatible with older versions of BLE. They implement the Elliptic-curve Diffie–Hellman algorithm for key generation and introduce a more complex process of key authentication. This provides default protection from passive eavesdropping and allows the device to be secured even further with an appropriate pairing method.
Attackers can do a lot of damage to both a device and its users if software developers don’t pay enough attention to security during the second phase of pairing. A recent example of this is the Bluetooth vulnerability discovered in Xiaomi M365 e-scooters. Reporters found a vulnerability that allows attackers to immediately stop or accelerate a scooter at any given point, posing a danger to both the rider and those in the vicinity. Anyone with programming skills can take control of one of these scooters through the mobile application.
This vulnerability existed because the password used to log in to the mobile app was not verified by the scooter. In other words, users could log in to the application with their password and then connect to any Xiaomi M365 from the app.
"Very likely this happened because the password system was implemented incorrectly. While passwords are usually used to generate hashes or keys, which can then be exchanged between the scooter and the smartphone to establish a secure encrypted connection, in this case, it looks like no hashes were exchanged. The mistake could be either on the side of BLE module programmers or those who developed the mobile application used to interact with the e-scooter" — Vitalii Bilan, IoT engineer at Lemberg.
Finally, during the optional third phase of pairing, devices generate sets of keys to verify each other’s identity for future connections. These could be, for instance, a pair of Connection Signature Resolving Keys, which are used for data signing, or Identity Resolving Keys, which are used to generate private MAC addresses and lookups.
Now let’s take a closer look at the types of attacks hackers can use to exploit a poorly protected IoT device.
Major threats to Bluetooth Low Energy security
There are two types of cyber attacks commonly associated with hacking Bluetooth Low Energy modules: passive eavesdropping and man-in-the-middle.
Passive eavesdropping is an attack that allows an alien device to tap into data transmitted between devices on a BLE network. For instance, an attacker can listen to the data that industrial peripheral sensors send to a central unit and then use it to figure out other security vulnerabilities in the system. BLE modules that implement BLE Secure connections are protected from passive eavesdropping by default.
A man-in-the-middle attack involves an alien device that pretends to be both central and peripheral at the same time and tricks other devices on the network into connecting to it. This could become an issue in large manufacturing complexes, since an alien device could inject false data into the stream and cause entire production chains to malfunction.
While BLE Secure connections offer protection from passive eavesdropping, man-in-the-middle attacks can be averted only with an appropriate pairing method.
Choosing the right BLE pairing method
Because Bluetooth manufacturers know about the issues plaguing the Bluetooth Low Energy communication protocol, they’ve invented a number of secure pairing methods that protect the keys that devices exchange.
Keep in mind that although BLE 4.2 devices are backwards compatible with BLE 4.0 and 4.1 devices, older module versions can’t make use of BLE Secure connections, and hence provide less security than what you could expect from a more recent BLE module.
Just Works pairing method
Just Works is the default pairing method for most BLE networks. In BLE Legacy connections, the Temporary Key value that devices exchange during the second phase of pairing is set to 0, and devices generate the Short Term Key value based on that. It’s clear that such a pairing method is highly insecure and offers no means of protection, only a way of establishing a connection.
With BLE Legacy connections, however, Just Works can be turned into a complex and reliable method of ensuring basic security:
- Using ECDH cryptography, both devices generate a public/private key pair and exchange the public keys.
- The device receiving the connection request generates a random value and then uses it to generate a confirmation value. It then sends both of these values to the device initiating the connection.
- The initiating device generates its own confirmation value with the random value it has received from the device to which it is trying to connect. It then compares this confirmation value to the confirmation value generated by the target device. Since the same random value is used, the confirmation values should also be identical.
- If the confirmation values match, the devices establish a connection.
Although Just Works provides security against passive eavesdropping in BLE Secure Connections, it’s not a reliable method of protection against man-in-the-middle attacks. Ideally, Just Works should be used in cases where no real security is required. For instance, it would be a good fit for fitness trackers, BLE-enabled jewelry, devices used to track pet behavior, and other technologies that do not deal with sensitive information such as credit card or health-related data.
We have experience implementing the Just Works pairing method in one of our projects, a connected wearable device that creates a soothing rhythmic pulsation to help its users remain calm and focused. Since the device doesn’t collect or store any sensitive data, Just Works does a perfect job at keeping it securely connected with the user’s smartphone.
Out of band pairing method
Out of band (OOB) pairing allows for some data packages to be transferred through a different wireless protocol. OOB pairing can be implemented both during the second phase of pairing, so that keys exchanged between devices are not transferred through the less secure BLE protocol, and when a device transfers sensitive data.
For instance, if you have a mobile application that tracks user behavior through a wearable device and also has e-wallet features, you could transmit the behavior data through BLE and delegate transmission of credit card data to a different communication protocol such as near-field communication (NFC).
The end security of OOB pairing depends on the protocol you use as a substitute for BLE. An appropriate communication protocol can offer protection from both passive eavesdropping and man-in-the-middle attacks.
Passkey pairing method
Passkey pairing makes users part of the security. There are various ways to implement it, here are the examples we’ve come up with:
- One of the devices can generate a six-digit passcode (this would typically be the central unit, since they’re usually more advanced than peripheral devices), which the user then enters on the other device.
- Alternatively, the passcode can be shipped together with the devices (on paper or as part of an online purchase), and the user should then manually input it to each separate device.
Because each device is manually verified by the user, passkey pairing eliminates the possibility of man-in-the-middle attacks. However, the major drawback is that devices require some sort of input/output capabilities (such as keyboards or touchscreens), which is difficult to implement on small wearable devices.
We implemented passkey pairing on one of our recent projects, an industrial thermostat, for which we added the entire BLE connection module. Absolute connection security was necessary because the thermostat would operate in industrial settings. We wanted to make sure that potential attackers wouldn’t be able to add their devices to the network or access the settings of legitimate devices.
Numeric comparison pairing method
Available for BLE Secure Connections only, numeric comparison is another pairing method that involves user participation. Having automatically verified their confirmation values at the second phase of pairing, with numeric comparison, devices use the random value they previously exchanged to generate another six-digit value, which a user then has to manually compare on both devices.
An example of where this might be used is a BLE-enabled industrial complex, where machines and sensors collect and store information vital to the manufacturing process. Given that devices have an output method, such as a screen, they can go through all stages of numeric comparison and output the final six-digit numbers. Then a factory worker can manually verify that both the central and peripheral units are showing the same number.
The numeric comparison method provides protection from man-in-the-middle attacks because no device can connect to the network without manual verification.
To summarize
Bluetooth Low Energy is a secure wireless communication protocol, but only if you implement it properly. The only serious vulnerability it has is during the second phase of pairing, but you can always secure this phase with an appropriate pairing method.
There are two ways in which hackers can exploit a BLE network: they can passively listen to the data transmitted on the network, which is known as passive eavesdropping, or they can add malicious alien devices to gain control over the entire network, which is known as a man-in-the-middle attack.
You should always go with BLE Secure Connections (modules 4.2+), as they offer default protection from passive eavesdropping and add secure pairing methods — a passkey or numeric comparison — to protect devices from man-in-the-middle attacks. You can also choose OOB pairing to avoid transmitting sensitive data over BLE altogether.
Establish BLE connections with Lemberg
With years of professional software development experience and numerous successful projects behind our back, Lemberg Solutions is a reliable partner in creating complex IoT development systems and devices.
If you have an idea you’d like to discuss, just contact us. We’d love to chat and hear what you have to say.
