Despite built-in safe-guards, Bluetooth Low Energy IoT devices are vulnerable to hacks when they communicate over the air. Here are the basics of the problem.
Leland Teschler, Executive Editor
If you eyeball internet-of-things items ranging from smart ac plugs to motion sensors you typically find connectivity via the Bluetooth Low Energy (BLE) standard. A lot of IoT devices use BLE because the protocol is well suited for transferring small amounts of data while consuming little power. But though BLE incorporates several security measures, vulnerabilities in the protocol have emerged over time.
For example, BLE communications can be hacked via man-in-the-middle (MITM) attacks where an attacker secretly alters messages between parties who think they are communicating with each other. BLE credentials can also be sniffed using a sniffing device that examines data sent on the advertising channels used to let BLE devices find each other. In BLE spoofing, an attacker mimics the MAC address of a BLE device as a means of impersonation. Denial-of-service attacks are also possible because peripheral BLE IoT devices are usually designed to connect with only one master at a time. Bombarding the BLE device with connection requests in response to advertising packets can prevent legitimate users from connecting. In addition, unauthorized co-located apps can also hijack the connection between legitimate mobile apps and BLE devices.
Many vulnerabilities pertain to the process of pairing devices, verifying and authenticating the identity of BLE nodes wishing to connect up. Part of the problem is that there are several ways of pairing devices, and not all of them have a high level of security. Ditto for BLE traffic encryption. Data encryption is used to prevent MITM eavesdropping attacks on BLE links by making data unintelligible to all but the BLE master and slave devices forming the link. Earlier versions of BLE had communication modes that didn’t incorporate a public key exchange for encryption/decryption, probably because more computing power (and a faster battery drain) was involved in running encryption/decryption algorithms.
Recent versions of the BLE standard incorporate modes where users must enter credentials to connect with IoT devices. Unfortunately, researchers have found that many BLE IoT devices don’t implement app-level credentialing properly.

It is useful to examine the pairing process to understand the vulnerabilities. All BLE pairing processes take place in three phases. In phase one, the two devices let each other know what pairing method is going to be used and what the BLE devices can do and expect. In phase two, a Short Term Key (STK) gets generated. The generation process consists of having the two devices agree on a Temporary Key (TK) that gets mixed with some random numbers to yield the STK. The STK itself is never transmitted between devices. In phase three, the key from phase two is used to distribute other keys needed for communications.
There are four different pairing methods. What may be the most secure of them is called OutOfBand, OOB, so called because it involves authentication outside the BLE communication channel. The Apple Watch is a good example. For pairing, a swirling pattern of dots displays on the watch face. The user points the camera of the iPhone to be paired at the watch face to link the two.
Another strong pairing method is called Passkey Entry. Here a six-digit value displays on one device and is entered manually into the other.
The two other pairing methods have more problematic security. With Numeric Comparison pairing, devices to be paired both display the same six-digit value. Pairing generally involves just hitting “OK” on both devices. The main purpose of Numeric Comparison is to identify devices to be paired rather than to thwart bad actors. MITM attacks are possible. The last pairing method, called Just Works, is said to be the most widely used. It was intended for devices that lack a display. As in Numeric Comparison, a six-digit value gets passed, but the six digits are all zeros. Thus any nearby BLE device sending out a Just Works connection request can pair up with those nearby that use the same pairing scheme.

The Just Works method has come into wide use because it consumes less power than the other pairing methods. BLE schemes that employ Just Works pairing may build-in other security measures that are less power intensive, typically at the app level. For instance, the app can ask users to enter credentials and deliver them (through encryption) to the IoT devices to authenticate the connection.
Nevertheless, security researchers say vulnerabilities during pairing constitute a severe security risk. For example, researchers at The Ohio State University recently developed an automated app analysis tool and used it to identify 1,757 vulnerable free BLE apps in Google Play store. They also performed a field test in which 7.4% of 5,822 BLE devices were vulnerable to unauthorized access.
Fingerprinting
The Ohio State researchers also said their field test uncovered 5,509 BLE devices that were “finger printable” by attackers. The fingerprinting involves the universally unique identifier (UUID) from the advertisement packets broadcast by the BLE devices. UUIDs are typically 128-bit hexadecimal strings. The point of broadcasting UUIDs is so a BLE peripheral can advertise what services it provides, such as measuring a heart rate. Thus some of the information in the UUID– i.e. that defining the predefined services– is universal. Nearby mobile apps must know what the UUID means to discover the device sending it out. Also, UUID packets are not encrypted– all other kinds of BLE packets are.

Ohio State researchers say this use of UUIDs is a design flaw. UUIDs can be obtained from not only the BLE traffic but also from the IoT companion mobile apps. Attackers can use UUID information to fingerprint a BLE device this way: Attackers bent on mischief would first scan all mobile apps in an app store, such as Google Play, to find all possible UUIDs, allowing them to use the device’s UUID list as an identifier, or fingerprint.
This UUID list by itself isn’t enough to pinpoint specific devices. It is likely that multiple apps use the same scheme-specific BLE chip or UUID configuration, preventing any nearby attackers from precisely knowing which device the victim is using. To further narrow things down, attackers can inspect the next layer UUIDs (because BLE devices often organize UUIDs in a hierarchical structure) and use the structure of the UUIDs to fingerprint a specific BLE device. With the fingerprinted UUID information, they can sniff all advertising packets nearby (e.g., in a metropolitan area such as New York City) to locate these devices. If mobile apps also tell them Just Works or weak pairing is in use, attackers can directly exploit these BLE devices.
In tests, the researchers discovered 168,093 UUIDs, 13,566 of which were unique, when they analyzed free BLE apps in Google Play. They also point out that there are special receivers available that can be used to sniff BLE signals up to 1 km away, though BLE signals typically travel only up to 100 m. To prove their point, the OSU researchers built their own BLE sniffing device using not much more than a Raspberry Pi and a BLE antenna. This DIY sniffer identified 431 vulnerable devices, including 369 units where the researchers could eavesdrop on conversations, within an area of just 1.28 square-miles.
Work by the OSU researchers shows what steps attackers must take when trying to decipher UUIDs. Sometimes UUIDs are directly hardcoded in the app. In this case, they may be extracted simply by looking for regular strings of characters (grepping) in the decompiled app code.
UUIDs associated with an IoT device also typically have a hierarchical structure. A service UUID can have “children” UUIDs derived from its characteristics. Such a UUID hierarchy could provide information useful for determining which IoT app maps to a particular BLE device. One complicating factor is that no structural rules define relationships between parent and children UUIDs, so some educated guessing may be involved.
OSU researchers also explain the general approach attackers would likely take in figuring out whether an app itself is insecure. The only way a nearby attacker can sniff vulnerable IoT devices paired via Just Works is to figure out whether the app involved uses flawed or insecure authentication. To implement proper authentication, the app must use cryptography to prevent a relay attack either by encrypting the authentication token with nounces (arbitrary numbers used only once to ensure communications can’t be reused) or by using an additional layer of encryption of the traffic atop BLE link-layer encryption. Thus, to check the app for security, the approach is to look at the disassembled app code for any use of cryptography. If there’s no cryptography, the conclusion is that the channel is not secure, and both passive/active sniffing and unauthorized access can be successful.
Even in apps employing cryptography, flawed authentication can rear its ugly head. One such flaw is the hardcoding of all credentials in the app, potentially discernible by disassembling the code. However, OSU researchers say it can be challenging to identify authentication flaws because there is no specific code pattern for implementing app authentication. Thus there’s no documented APIs to identify for extraction of the hardcoded credentials.
It turns out that flawed authentication involving hardcoded credentials can be identified systematically. The key insight is that to securely authenticate a mobile app to a BLE device, the app must provide a credential that comes from the external input, such as letting the user enter a password. OSU researchers say this opens up the possibility of using a data flow analysis algorithm to identify such apps. This approach, if used for nefarious purposes, implies an extremely determined attacker: The technique would likely involve creating data-flow equations for each node of the app’s control flow graph and solving them by repeatedly calculating the output from the input locally at each node.
In particular, researchers say data sent out to BLE peripheral must go through low-level APIs, allowing use of program slicing–basically looking at a subset of program statements that affect a variable of interest–to trace back to the source of the data. If none of the data sources are external inputs (e.g., received from the BLE network or user inputs), then the app has used hardcoded commands including possible passwords to interact with the BLE devices
Researchers also note that further intelligence may be gained by knowing where the UUIDs are used (i.e., the execution context). There are seven documented APIs defined by the Android BLE framework that carry the UUIDs as parameters, to generate the instances for accessing the related service, characteristic and descriptor in the paired BLE devices. While an app could have multiple UUIDs, their usage may have dependencies that can be exploited.
Countermeasures
To head off vulnerabilities, researchers say the app should encrypt the data sent with no hard-coding of any factors involved in the encryption. Developers should also hide the authentication credentials in the cloud or let users enter them in the app.
The root vulnerability that enables UUID fingerprinting is that BLE devices must broadcast advertised packets to inform nearby apps. The UUID can be sniffed either from the advertisement packets or by browsing for services after the connection has happened. In addition, UUIDs are fixed values and do not change over time.
The fingerprinting attack relies on mobile app analysis to reveal the UUIDs and their hierarchies. So anything that discourages this sort of analysis can be helpful.
Researchers also say that although protection methods in the app-level are seemingly plausible, they can’t fundamentally prevent the UUIDs from being reverse engineered from mobile apps. Obfuscation and encryption can only make it more difficult for attackers to retrieve UUIDs because the app will work with plain-text UUID somewhere along the line. Storing UUIDs outside the mobile app can prevent the UUIDs from being statically reverse engineered, but attackers can still obtain the plain-text UUIDs at run-time.
Researchers additionally advocate the piecing out of UUIDs as they get transmitted in the BLE RF channel. In this way, attackers can only see segments of UUIDs instead of continuous signals, The downside is that this approach probably entails use of additional hardware.
Another fundamental countermeasure would be to construct one-time dynamic UUIDs. The OSU researchers claim this scheme only requires an update of both the app and device firmware. Because multiple users can access one BLE device, they suggest using the cloud can help synchronize the UUIDs among users. Then once an app has successfully connected with an IoT device for the first time, it negotiates a dynamic UUID for future communication. To prove this scheme actually works, the OSU team says they implemented a prototype using a real BLE chip in a software development board which provides programming interfaces to configure UUIDs for advertisement packets, services, characteristics, and descriptors.
Clearly it would take a determined hacker willing to spend time parsing through disassembled app code to exploit some of the vulnerabilities the OSU researchers uncovered. That’s probably beyond the capabilities of casual mischief makers, but not out of the question for state-sponsored hackers and criminals.
Lots to comment on here. First, let’s clarify the pairing process and security levels. BT 4.2 added new security features:
– elliptic curve key generation
– Diffie Hellman key distribution
– Numeric Comparison pairing
Pre BT 4.2, there were three pairing methods: JustWorks, Passkey Entry and OOB. BT 4.2 adds Numeric Comparison as a fourth method. Numeric Comparison is a stronger form of security than Passkey Entry. Passkey Entry uses the input key as a seed into the key generation algorithm so a bad actor looking over your shoulder could, potentially, use that information in an attack vector. Numeric Comparison does not use the displayed code in the key generation algorithm so a bad actor would gain no useful information from looking over your shoulder.
OOB is stated as being the strongest form of pairing methods. Be careful. OOB pairing is as secure as the chosen OOB method and is not dependent on BT technology. The given example of an Apple Watch is an example of a very secure implementation of OOB. But sloppy implementations are also possible. A QR code stuck onto you computer screen would be an example of an insecure OOB implementation.
Of importance, is to consider the level of security that is chosen by the device or app designer within the context of the use case. Some use cases are perfectly fine with JustWorks pairing; some are not. One of my designs – an audio amplifier – uses JustWorks and it is not a security risk. If anyone bothered to hack that and turn the amplifier volume up or down, the very worst thing that would happen is that I would go over and punch the person on the nose and throw him/her out the door. The point is, because some devices/apps use JustWorks, you can’t broadly declare BT as insecure.
The table of UUIDs shown in the article raised my eyebrows – there is something amiss with that. All of the UUIDs listed with the exception of the Smart VFD device are Bluetooth organisation reserved UUIDs. As an example, the Car Dongle, second in the list, that UUID is the reserved UUID for the BT Running and Cadence Service. The next one down, Key Finder is the reserved UUID for Transmit Power Service. And so on. I don’t doubt lazy developers keen on getting cheap products onto the market as quickly as possible would ignore the BT specification but I suspect that the issue more likely lies with the data analysis and mapping.
The article focusses on the security of the pairing process itself but does not mention other mechanisms available for sensitive use cases:
– Directed Advertising wherein advertisements are targeted to a single known device and cannot be discovered by sniffers or explorer applications such as LightBlue
– Whitelists wherein either Central or Peripheral can block activity from devices not on its whitelist
– Bonding, an optional step on top of pairing that stores the long-term keys (LTK) in permanent storage on the device. Subsequent connection attempts recover the keys from storage; there is no recalculation of keys and, importantly, no on-air transmission of credentials. This limits any potential security risk to the very first time two devices connect.
Directed Advertising and whitelists are not possible with iOS (not sure about Android). Apple requires that you implement bonding for any application that goes on the AppStore.
In closing, I guess I’m confused about the commentary that putting a globally unique identifier for a service, in this case a UUID, into the advertising packet is a “root vulnerability”. Also confused about the ongoing commentary on being able to discover other services and characteristics after connecting being a vulnerability. Being able to do these things is the whole point. You want to be able to do this.