The Bluetooth specification is huge and quite complex. As a researcher, it helps when looking at the various Internet of Things (IoT) devices to understand what a vendor of an IoT device actually implemented. This is important when one has to deal with environments where older and less secure Bluetooth implementations on older IoT devices have to interact with the new IoT devices which are capable of better security, and you have to determine what security is actually being used.
In the past, I’ve run into roadblocks while trying to figure out what was going on during various Bluetooth communications such as pairing and encryption, so I’ve put together this blog post to help explain some of the security aspects, how these aspects are typically used, and how to easily spot a few of them during a research effort.
It should be noted that this entire blog post started because I needed to explain LE Privacy in a forthcoming blog post and the “appendix” kept growing until I simply split it off into its own thing.
History
Before we explain current Bluetooth security, we should go back in time a bit. Bluetooth was invented in 1989, but really came into use during the 2000s. There is no one Bluetooth protocol; it is a collection of different protocols grouped together under a single specification. Bluetooth is managed by the Bluetooth Special Interest Group, also referred to as Bluetooth SIG.
In an effort to explain a concept like LE Privacy, we must explain a chunk of the Bluetooth history of security implementations. The “LE” in LE Privacy stands for Low Energy, but it actually has nothing to do with power consumption nor does it mean to imply there is a higher energy consumption mode involving the “Privacy” part of LE Privacy. It is actually a holdover from when there was a “larger” implementation that used more energy (Bluetooth Classic), and a “smaller” implementation when battery life was critical and energy consumption needed to be curtailed (Bluetooth Low Energy, or LE or BLE or even BTLE).
Eventually, these were combined in Bluetooth 4.0, and Bluetooth SIG chose features from both Classic and LE, based upon what was better or when one had something the other didn’t. And that is where the “LE” in “LE Privacy” came from. Remember that comment about Bluetooth being complex? Well, the naming of things like this doesn’t help.
The current standard, as of this writing, is Bluetooth 5 (there is no 5.0, it is just 5), although most devices use (and are optimized for) 4.0–4.2. As we will see later on, a lot of IoT vendors try to support legacy authentication protocols dating back as far as Bluetooth 2.0, and these can affect the quality of security.
In the OSI Model, there are seven layers—yes I can hear you groaning—but I just need to reference a few of them quickly. In the TCP/IP world, TCP is at layer 4, the transport layer. Bluetooth’s layer 4 is Logical Link Control and Adaptation Protocol, or L2CAP.
Sitting on top of L2CAP, mainly in layer 5 - the session layer - is the Security Manager, doing the whole Security Manager Protocol. It is responsible for pairing, encryption and signing. So the application sitting at layer 7 doesn’t have any information about the security stuff, it just chugs along and cares not about the lower layers’ various processes so long as it can send and receive data.
Bluetooth Smart and Bluetooth Smart Ready
As mentioned earlier, with Bluetooth 4.0 came a new security model based upon previous and new work from Bluetooth SIG. In an effort to handle requirements for devices that run off of batteries or devices that might frequently unpair and pair, the terms “Bluetooth Smart” and “Bluetooth Smart Ready” were established. These are simply groupings of characteristics, but their nature affects the security aspect of various devices, so it helps to know the background.
Bluetooth Smart is implemented on peripheral devices like headphones, speakers, fitness trackers, medical devices and so on. These devices are battery-powered and often pair to devices that they may lose contact with for extended periods of time. They may only require periodic connection to their paired host, like during data transfer. Additionally, they can maintain a pairing despite long sleep periods between wake modes—even preventing a second device from pairing.
Bluetooth Smart Ready are devices that can talk to Bluetooth Smart and use all of the capabilities. Your smartphone or your laptop are good examples of Bluetooth Smart Ready devices. If you have an old Bluetooth 2.0 or 3.0 device, Bluetooth Smart Ready can still talk to it.
While I have rarely seen the “Bluetooth Smart” or “Bluetooth Smart Ready” stickers on products (or I have ignored them), they do help illustrate the need for various security elements. For example, how does one maintain pairing in a secure fashion between a computer and a fitness tracker that will periodically upload its data? How does one secure a device or ensure the privacy of the device’s owner when the device may spend most of its time in sleep mode?
Bluetooth Security Modes
There are two security modes: LE Security Mode 1 and LE Security Mode 2. There are also four security levels appropriately numbered 1 through 4, with 4 being the most secure. Yes you can mix levels and modes. To further complicate things, there are two additional security modes named Mixed Security Mode and Secure Connection Only Mode.
We’ll start with the security levels first:
- Security Level 1 supports communication without security at all, and applies to any Bluetooth communication, but think of it as applying to unpaired communications.
- Security Level 2 supports AES-CMAC encryption (aka AES-128 via RFC 4493, which is FIPS-compliant) during communications when the devices are unpaired.
- Security Level 3 supports encryption and requires pairing.
- Security Level 4 supports all the bells and whistles, and instead of AES-CMAC for encryption, ECDHE (aka Elliptic Curve Diffie-Hellman aka P-256, which is also FIPS-compliant) is used instead.
Then the security modes:
- Security Mode 1 is those levels without signing of data
- Security Mode 2 is those same levels with signing of data, including both paired and unpaired communications.
- Mixed Security Mode is when a device is required to support both Security Mode 1 and 2, i.e., it needs to support signed and unsigned data.
Secure Connection Only Mode is Secure Mode 1 with Security Level 4, meaning that all incoming and outgoing traffic in a Bluetooth device involve authenticated connections and encryption only. To complete the confusing complexity, you can run Secure Connection Only Mode with Secure Mode 2 instead of 1 to ensure all data is signed, but since the data is encrypted, and more math means more computing power, and more computing power means faster battery drain, Bluetooth SIG apparently felt encryption without signing was good enough for this particular mode.
Pairing
Now knowing what these modes and levels are, one can start to answer some of those questions about maintaining pairing despite sleep mode or enforcing privacy on a Bluetooth connection between devices that aren’t always talking to each other. But we need to discuss how they are implemented, starting with pairing.
The pairing process is pretty much where everything security-related takes place and is decided beforehand. Its purpose is to determine what the capabilities are on each end of the two devices getting ready to pair and then to get them actually talking to each other. The pairing process happens in three phases, and we will quickly outline each one.
Phase One
In phase one, the two devices let each other know what they are capable of doing. The values they are reading are Attribution Protocol (ATT) values. These live at layer 4 with L2CAP, and are typically not ever encrypted. They determine which pairing method is going to be used in phase two, and what the devices can do and what they expect. For example, ATT values will be different for a Bluetooth Smart vs a Bluetooth Smart Ready device.
Phase Two
In phase two, the purpose is to generate a Short Term Key (STK). This is done with the devices agreeing on a Temporary Key (TK) mixed with some random numbers which gives them the STK. The STK itself is never transmitted between devices. With STK, this is commonly known as LE legacy pairing. However, if the Secure Connection Only Mode is being used, a Long Term Key (LTK) is generated at this phase (instead of an STK), and this is known as LE Secure Connections.
Phase Three
In phase three, the key from phase two is used to distribute the rest of the keys needed for communications. If an LTK wasn’t generated in phase two, one is generated in phase three. Data like the Connection Signature Resolving Key (CSRK) for data signing and the Identity Resolving Key (IRK) for private MAC address generation and lookup are generated in this phase.
There are four different pairing methods:
- Numeric Comparison. Basically, both devices display the same six digit value on their respective screens or LCD displays, and you make sure they match and hit or click the appropriate button on each device. This is not to prevent a man-inthe-middle (MITM) attack, mainly because it doesn’t, but rather to identify the devices to each other.
- Just Works. Obviously, not all devices have a display, such as headphones or a speaker. Therefore, the Just Works method is probably the most popular one. Technically, it is the same as Numeric Comparison, but the six-digit value is set to all zeros. While Numeric Comparison requires some on-the-fly math if you are performing a MITM attack, there is no MITM protection with Just Works.
- Passkey Entry. With Passkey Entry, a six-digit value is displayed on one device, and this is entered into the other device.
- Out Of Band (OOB). A communication method outside of the Bluetooth communication channel is not used, but the information is still secured. The Apple Watch is a good example of this workflow. During the Apple Watch pairing method, a swirling display of dots is displayed on the watch face, and you point the pairing iPhone’s camera at the watch face while (according to Apple) bits of information are transmitted via this process. Another example is using Near Field Communication (NFC) between NFC-capable headphones and a pairing phone.
Determining Modes and Levels
As mentioned before, the Layer-7 application is not aware of the underlying Bluetooth security implementation. Therefore, reversing an app used for some Bluetooth-enabled device will not tell you the full story. Nevertheless, there are several steps you can take to determine the security modes and levels for a device.
Initiator or receiver. Determine if the device is an initiator or a receiver. In modern Bluetooth terms, it will fall into the rough categories of Bluetooth Smart or Bluetooth Smart Ready. Think of it this way: a device that initiates the Bluetooth connection during initial pairing is going to be the Bluetooth Smart Ready device. The device being paired to is going to be the Bluetooth Smart device. You will then have to prove if they are in fact Smart or Smart Ready, but knowing which is which will help determine what packets you will need to look at on a sniffer trace. Some tools will list this as Master or Slave, or some other set of terms denoting roles.
If the device you are exploring is a Bluetooth Smart receiver, you can possibly initiate the pairing from your Bluetooth Smart Ready laptop and sniff using the laptop’s Bluetooth interface as the source of your sniffing in Wireshark. See our blog post comparing hacking tools for more details.
Instructions for pairing. When you get your new Bluetooth-enabled device, it will typically include instructions for pairing. Obviously, if the devices have screens that can display a value and you can observe that Numeric Comparison or Passkey Entry is used, great. If OOB is used, even better as this is the most secure pairing method. In these cases, you know modern implementations of Bluetooth security are at least supported. If you see pairing instructions that include something like “if asked for a passcode, use xxxx” where xxxx is a four digit value, then you know Bluetooth 2.0 legacy authentication is supported, and virtually all other modern security elements are most likely not implemented.
However, most pairing involves Just Works, simply because there is no screen on many devices in the Bluetooth Smart category. If Bluetooth 2.0 legacy authentication is not supported, it does not mean additional security elements are implemented, but it helps steer further exploration.
Scanning and probing. Scanning a device with a Bluetooth scanner can help determine security levels. Any information you can get from the scans, including information on the chipset involved will help greatly. If you can determine the chipset in use, you can look up what the chipset is capable of (e.g., “it can handle up to eight connections and has AES-128 support onboard”). If the chipset “supports the latest features of Bluetooth 3.0,” then you know advanced security is not a part of the equation.
Note the MAC address. If the address is a public address and the OUI is in database with the IoT vendor’s name associated with it, they are not using LE Privacy - they are using a constant for the MAC address at all times. You can verify this over time via further scans and probes as the MAC address will remain the same.
If you can connect to the device for probing but any action seems to kick you right back out, most likely Secure Connection Only Mode is in place.
Sniffing the pairing. Detecting the implementation of security elements via a Bluetooth sniffer might seem extremely hard, but once you understand what the different security modes are and how they are used, you can easily determine what has been implemented - assuming you get a successful sniffer trace.
Ideally, you want to capture a sniffer trace of the pairing process. If you are examining the initiator or Bluetooth Smart Ready device, you want the Pairing Request packet. Conversely, if you are examining the receiver or Bluetooth Smart device, you want the Pairing Reply packet.
The opcode will be 0x01 for a Pairing Request and 0x02 for a Pairing Reply. I/O capacity will be one of the following:
- 0x00 Display Only
- 0x01 Display Yes/No (both a display and a way to designate yes or no)
- 0x02 Keyboard Only
- 0x03 No Input/No Output (e.g. headphones)
- 0x04 Keyboard Display (both a keyboard and a display screen)
- 0x05-0xFF Reserved
OOB Data Flag will be 0x00 for no OOB data or 0x01 for OOB data present. Max Encryption Key Size tells the size of the encryption key in octets, and both the Initiator and Responder Key Distribution bytes convey with flags what keys will be distributed.
The Auth Request byte consists of five fields, and uses the various bits as flags. From least significant bit to most significant bit, here are the fields:
- Bonding flags, two bits, either 0 or 1 for the very least bit, the other bit is reserved. As such, 0 is for no bonding, the 1 is for bonding. If bonding is used, an LTK will be exchanged, which means two devices can be paired, and a reboot or sleep mode will not unpair the devices. If encryption is supported, this will happen separately after pairing.
- MITM flag, one bit, 0 is that MITM protection is not requested, and 1 is that MITM protection is requested.
- Secure connection, one bit. If this is set to 1, the device is requesting to do Secure Connection Only Mode, otherwise it is set to 0.
- Keypress flag, one bit. If set to 1 it means Passkey Entry needs to be used, otherwise it is ignored.
- The last three bits are reserved.
Remember though, always check your tools and do not rely on what they tell you - get multiple examples of the same process to help ensure you are sniffing the data accurately. And don’t expect every manufacturer to follow the rules as you might interpret them. Here is a Pairing Reply packet during a pairing of an Apple Watch with an iPhone using the Passkey Entry process that illustrates this perfectly:
Figure 2. Wireshark interpretation of an Apple Watch pairing reply packet. Note the AuthReq section doesn’t match the raw data.
In Figure 2, the main issue is that byte 24’s (offset 0x17) value is 0x0d. Under the Wireshark interpretation, only the bits for Bonding and MITM are set, while the value of 0x0d suggests the Secure Connection bit is also set. At the time of the sniffer trace, the Passkey Entry method was chosen, but in this case, not only does the Wireshark interpretation not show it’s set, the raw data also suggests it is not set.
It should be noted that using Secure Connection Only Mode implies using either Passkey Entry or OOB as the pairing method. Since OOB is not explicitly set, the default would be Passkey Entry. This is in spite of the fact that the Keypress bit is not set.
This means either two things: 1) Since Secure Connection Only Mode was being used, Apple felt there was no reason to set the Keypress bit since it would be implied, or 2) there will be no pressing of a key on the Apple Watch side, since during Apple’s implementation of Passkey Entry no keypress is needed from the watch. My guess is the latter. During its Pairing Request packet, the iPhone did say that it can do 0x04 (Display Screen and Keyboard for input), so when you consider everything the two devices are claiming they can do in the conversation, they can handle Passkey Entry.
Overall though, during the pairing process the Apple Watch is claiming its I/O Capability is 0x00 which is Display Only, despite the fact that the Apple Watch can do a Display Screen and Keyboard input. It is specifically limiting itself during the pairing process to match what is being requested by the user, who is controlling the pairing choice. There is nothing in the specification about adjusting things to user preference or settings, although it makes sense, especially from a security perspective, to limit the amount of exposure.
This is the level of scrutiny one needs when looking at Bluetooth to either prove or disprove an action or setting. In a report or blog post on the Apple Watch, I might have simply worded this as “the Apple Watch follows the Bluetooth specification for 4.2 during the pairing process” instead of showing this level of detail. But at least you can make the statement firmly.
LE Privacy
Whenever a Bluetooth device needs to transmit, it enters an advertising mode where it announces to the world it is there. Depending upon the nature of the device, it could do this only periodically, or it could be doing this constantly. It uses a MAC address during advertising so that other devices can potentially talk back to it.
One of the issues with this scenario is that a nefarious person could track an individual’s movements by tracking where that MAC address pops up. Therefore, it makes sense that a device trying to protect its owner from tracking would periodically change its MAC address. Naturally, this creates other problems. How will the paired devices know what they are paired to if the address keeps changing? How can I limit the knowledge of my MAC address to only devices I trust, while still protecting myself from being tracked?
This is where LE Privacy comes in. This solution was introduced with the creation of Bluetooth Smart (the 4.0 standard), and it is an efficient solution for the problem. During the pairing process in phase three (as outlined above), the devices exchange a variety of keys. One of those keys is the Identity Resolution Key (IRK). This key allows for the creation and resolution of random MAC addresses to be used in advertising packets.
Basically, the real MAC address of the device isn’t really changed, just what is reported via the advertising packet is. By providing an IRK to a device’s paired partner, you are telling that partner how to “resolve” a MAC address to recognize the device later based off of its random advertising address. To help ensure the devices reconnect, the LE Privacy device will create an advertising packet with the destination MAC address of its paired partner and the random MAC address as the source - the paired partner knows to resolve the MAC address quickly to determine who it is, as it might be paired to multiple devices that use LE Privacy.
This provides a nice way for two devices to remain paired even with interruptions due to sleep mode, power cycling, or physical distance between the devices being greater than the Bluetooth range - and it still helps ensure user privacy by preventing tracking by MAC address.
LE Privacy is extremely easy to spot in a lab environment: you simply scan for MAC addresses and track them over time. By performing actions on the device with LE Privacy that will generate traffic, it will make it easier to spot. The time delay will vary and it is entirely up to the manufacturer to decide the intervals between cycles. I’ve personally seen anywhere from 15 to 30 minutes, and most devices that implement LE Privacy also use a fresh MAC address after every power cycle.
Where’s the Code?
As mentioned, this type of exploration isn’t your typical “APK decompile to get to the code that controls the Bluetooth choices” workflow, since the code for the Bluetooth stack is located in the device’s firmware or in a device driver. If it is in firmware, this can be quite complex to get to, as we’ve seen before.
Bluetooth security can be complex, but once you do a bit of sniffing and poking around in a device’s security settings (if they exist) you can learn a lot. Even by simply studying behavior, documents, and how devices interact, you can usually figure out not only what a device is capable of from a security perspective, but how much security has actually been turned on.
