Bluetooth Low Energy (BLE) is a widely adopted wireless communication technology and is broadly adopted in IoT such as medical applications including blood pressure monitoring and X-ray imaging as well as wearable technologies. . BLE has two salient features: low energy consumption to increase the lifetime of battery-powered BLE devices and a development framework - GATT (Generic Attribute Profile) to allow mobile, tablet and PC applications for arbitrary data transmission to peer BLE devices.
BLE relies on a pairing protocol to ensure the communication security. Two pairing devices authenticate each other and negotiate a secret key to encrypt the communication channel. To achieve this goal, latest versions of the specification including Bluetooth 4.2  and 5.x [20, 21] offer four pairing protocols: Just Works, Passkey Entry, Numeric Comparison and Out Of Band (OOB). Just Works is not secure and OOB is rarely used due to the extra hardware cost. Therefore, we denote Passkey Entry and Numeric Comparison as practical secure pairing protocols and will focus on the security analysis of these two pairing protocols.
The latest BLE 4.2  and 5.x  add the new Secure Connections Only mode for BLE enabled devices to address vulnerabilities found in previous Bluetooth pairing protocols [69, 46, 47, 32, 39, 64, 42, 49, 70, 48, 25, 53, 51, 55, 35, 34]. Man-in-the-middle (MITM) attacks in [35, 34] work against Bluetooth Secure Simple Pairing (SSP) of Bluetooth Classic 2.1 and 3.0, in which two Bluetooth devices under SSP use only I/O capabilities (such as display and keyboard) to determine the pairing protocol. An attacker can falsely declare their I/O capabilities and conduct an MITM attack [33, 5, 12]. With BLE 4.2 and 5.x, if the Secure Connections Only mode is enabled in a BLE device, the BLE device is forced to authenticate the user/mobile device with secure pairing protocols. It is expected that the Secure Connections Only mode will enforce secure pairing to defeat the MITM attack.
However, BLE does not explicitly specify such a Secure Connections Only mode for a connection initiator such as a mobile device (more details are available in Section 2.4). Without the Secure Connections Only mode being enforced at the initiator side, the initiator, e.g., a mobile, is not required to authenticate the BLE device. We find such vulnerabilities exist in both Android and iOS systems and believe that this problems is a protocol level issue. That is, all BLE systems following the BLE specification will have this problem. In this paper, however, we will focus on the Android system with brief discussion on the iOS system due to the page limit.
After examining the initiation, status management, error handling and bond management throughout the life cycle of a pairing process in the Android programming framework, we identify four design flaws which, if not properly addressed, cannot enforce the Secure Connections Only mode.
An Android app cannot specify any pairing protocol even if it knows its peer BLE device’s capable pairing protocols;
An Android app cannot cancel an insecure pairing process until the pairing process is completed;
A fake device may poke an Android device and intentionally create pairing errors. Android mishandles those pairing errors without notifying the app and the user;
Even if an app knows insecure pairing is used, Android does not provide a mechanism to remove the previously generated key or start a new secure pairing process with the specific peer BLE device.
The four Android BLE design flaws cause serious security issues. For example, if an Android mobile was paired with a peer BLE device through secure pairing protocols, then a fake/spoofing device can downgrade the pairing protocol, pair with an Android mobile using insecure pairing protocol (i.e., Just Works) or even communicate in plaintext and inject data into the Android device and the corresponding BLE app. Note that the Identity Resolving Key (IRK) is designed to prevent a mobile from leaking its MAC address and thus being tracked. With these security flaws, a fake device can pair with the victim mobile using Just Works and obtain the mobile’s IRK and MAC address to track the mobile device. Even worse, the fact that Android cannot enforce secure pairing causes damages beyond the mobile itself. A BLE device may implement a whitelist that allows only previously paired mobile devices to connect or to access services. An attacker can now collect the mobile device’s MAC address and IRK to bypass the whitelist-based filtering.
To solve these security issues, we believe that the Android system shall be able to enforce the Secure Connections Only mode such that a BLE app can specify and enforce a secure pairing protocol. If secure pairing is enforced on Android, a mobile device user has to see pairing BLE devices and make the decision physically to disable/proceed with the pairing process. If the pairing device is a fake device, the fake device will be identified by the user and any following attacks shall fail. The secure connections only mode at the app side will not create any conflict with peer devices. Practically, the app and its peer device know each other’s capabilities and shall be able to enforce the secure connections only mode if secure pairing is desired and their I/O capabilities support it. We advocate the option of the secure connections only mode for the app so that the app can defeat various attacks. If the option is not used, BLE shall run compatibly.
Our major contributions are summarized as follows.
For the first time, we find that BLE does not require the Secure Connections Only mode for a pairing initiator such as a mobile phone. The lack of mutual authentication with Secure Connections Only mode at both the mobile and its peer device in the BLE specification causes security vulnerabilities.
Based on our finding on BLE specification security flaws, we tested and proved that both Android and iOS do not provide a programming framework for BLE apps to enforce security pairing. Specifically, four design flaws were identified in Android leading to security vulnerabilities on Android mobiles and peer BLE devices.
Thorough experimentation was performed on BLE apps running on the latest versions of Android and 18 commercial BLE devices. Not surprisingly, all 3501 BLE apps from Androzoo  are subject to downgrading and MITM attacks. In our experiments, the line-of-sight attacking distance can reach 76 meters.
Security defenses and solutions are proposed and prototyped to enhance the Secure Connections Only mode for Android by enforcing secure pairing protocols through the Android Open Source Project (AOSP) . Our case study on BLE keyboards further prove that the Numerical Comparison protocol is more secure than the Passkey Entry protocol even if both the mobile and the peer device enforce secure pairing. Therefore, for mission critical BLE apps and devices, we suggest that Numerical Comparison will be used on the mobile and on BLE devices to provide higher security assurance.
Responsible Disclosures: We have reported our findings to Bluetooth Special Interest Group (SIG), Google Android Security Team, Apple, and Texas Instruments (TI) Product Security Incident Response Team (PSIRT). The Bluetooth SIG acknowledged our findings and is currently working with Google to address the issues. The Google Android Security Team also acknowledged the four design flaws and rated the identified Android vulnerabilities as High severity . They are actively working with us to patch Android. TI’s PSIRT has released a patched SDK to “Update authentication parameters when transitioning between authenticated/non-authenticated pairing” based on the reported vulnerabilities of TI’s BLE stack [3, 2].
Roadmap: The rest of the paper is organized as follows. We introduce BLE in Section 2 and present the BLE pairing process flaws in Section 3. Section 4 presents the downgrading attacks exploiting the design flaws. Case studies are presented in Section 5. Section 6 discusses various countermeasures including the enforced secure paring in Android. Section 7 evaluates the attacks and countermeasures. Section 8 discusses securing pairing on iOS and other potential solutions to BLE security. Related work is presented in Section 9 and we conclude the paper in Section 10.
In this section, we will first present an overview of BLE, and then introduce the connection setup process, the pairing process, and the Secure Connections Only mode. We will also introduce the Attribute Protocol (ATT).
2.1 BLE Overview
BLE is a short-range communications technology. Figure LABEL:fig:overview shows its protocol stack where a blood pressure monitor is used as exemplary BLE device. In this example, the application on the blood pressure monitor measures blood pressure. The blood pressure monitor application and the mobile app use the BLE core system for communication. BLE’s core system consists of two building blocks, LE controller and host. The LE controller uses the link layer and physical layer to create a connection for sending/receiving data. BLE’s physical layer uses frequency hopping for communication, where data is exchanged over a sequence of hopping frequencies. The frequency hopping sequence is negotiated between two devices. The host implements multiple protocols including the Security Manager Protocol (SMP) and ATT for secure communication over the connection. ATT is used to format the transmitted data. SMP uses pairing protocols to negotiate cryptographic keys for data encryption, integrity and other purposes. The Host Controller Interface (HCI) moves the data, e.g., blood pressure measurements or SMP control commands, from the host to the LE controller through a physical interface, a function call or other venues depending on specific implementations.
2.2 Connection Setup
Steps 1 to 4 in Figure 2 illustrate a typical BLE connection setup process. Exact information exchanged at each step varies based on different applications. In Step 1, the blood pressure monitor broadcasts advertising packets indicating its availability. When a mobile app is launched, the app utilizes the Host and receives the advertisements. In Step 2, the mobile app sends a scan request to the monitor. In Step 3, the blood pressure monitor responds with a scan response packet. The mobile app uses advertising and scanning to collect information about the blood pressure monitor such as the monitor’s name, the MAC address and primary services. In Step 4, the mobile app can now decide if the device is the one of interest and send the connection request to build the connection. The frequency hopping increment is included in the connection request which determines the frequency hopping sequence that the mobile and the blood pressure monitor will follow in the communication. Here the mobile is called the master/initiator for its role in initiating the connection. The peer BLE device, the blood pressure monitor in this case, is called the slave/responder.
2.3 Pairing Process
After two BLE devices build a connection, if no device explicitly requests pairing, the communication continues in plaintext. The two devices need to explicitly start the pairing process to negotiate keys and encrypt the communication. Steps 5 to 9 in Figure 2 illustrate a typical pairing process. A mobile app can initiate the pairing process through SMP (see Figure LABEL:fig:overview). The end-user can also use the system setting app to start the pairing process.
2.3.1 Phase 1 - Pairing feature exchange
Step 5 - Security request (optional). As a slave device, the blood pressure monitor can send a security request and ask the mobile (master) to initiate the pairing process.
Step 6 - Pairing feature exchange. The mobile app sends out a pairing request and the blood pressure monitor returns a pairing response. The two devices then announce their Input/Output (I/O) capabilities such as keyboard and display, authentication requirements and the BLE version so that a suitable common pairing protocol can be negotiated. (i) The authentication requirements can be bonding and MITM protection. Bonding means that the keys generated during the pairing process will be saved for later use to reduce delay caused by the future pairing process. If a device wants to defend against the MITM attack, the MITM flag  must be specified so that the Passkey Entry protocol or the Numeric Comparison protocol will be adopted. The exchanged I/O capabilities will help select communication protocol since different pairing protocols require different I/O capabilities. For example, Numeric Comparison requires a display on both devices. If authentication requirements are requested but I/O features cannot support the specified secure pairing, according to the BLE specification, the communication shall be terminated and the user will be notified. (ii) If the two devices explicitly set the MITM flag as false, Just Works is selected and Just Works cannot defend against the MITM attack. (iii) The BLE version is indicated in the Secure Connections (SC) bit. If the mobile and peer device set the SC bit, BLE 4.2 and above will be adopted. Otherwise, the BLE legacy pairing method is used. We focus on only BLE 4.2 and above in this paper.
2.3.2 Phase 2 - Key exchange and authentication
Step 7 - Public key exchange. The Elliptic-curve Diffie–Hellman (ECDH) key exchange protocol is performed so that master and slave devices obtain each other’s public key and generate a symmetric key, DHKey.
Step 8 - Authentication stage 1 (a critical step to BLE security). In this step, authentication related information is exchanged between the two devices. A pin is entered if Passkey Entry is used. A 6-digit number is displayed at the two devices if Numeric Comparison is used. A verification procedure will also run to make sure the public keys exchanged in Step 7 are from the intended devices.
Step 9 - Authentication stage 2 and LTK calculation. The previously exchanged authentication information including DHKey is used to generate the MacKey and Long Term Key (LTK) at the two pairing devices. MacKey is used in a process to ensure both devices generate the same LTK. If bonding is required in Step 6, LTK is saved for future session key generation and link encryption. BLE defines two types of keys, unauthenticated-and-no-MITM-protection keys for Just Works and authenticated-and-MITM-protection keys for Passkey Entry, Numeric Comparison and OOB.
To help readers better understand these communication protocols, we briefly introduce them below with more details in .
Passkey Entry: During the pairing process, one device such as a mobile needs to display a 6-digit pin, and the user inputs the pin on the other device using a keypad/keyboard. The authentication stage 1 in Step 8 will fail if the attacker does not know the pin.
Numeric Comparison (BLE 4.2 and beyond): Numeric Comparison is applicable when both devices have displays and confirmation buttons. After the ECDH key exchange, the two BLE devices exchange a pair of nonces in Step 8. A function is then used to convert the exchanged public keys and nonces into a six-digit number. Each device displays the number . The user confirms that the two displayed numbers are the same by pressing the “Yes” button on each device’s display to proceed the pairing process. The fact that the two displayed numbers are the same ensures that the exchanged two pubic keys are from the two intended pairing devices, other than from an an attacker.
Out of Band (OOB): In OOB, a secret is shared with an out-of-band venue such as near-field communication (NFC) and the LTK is derived from this secret. If the OOB venue is secure, the MITM attack can be defeated.
Just Works: It is designed for devices without I/O capabilities  and is subject to MITM attacks. Just Works has almost the same pairing process as Numeric Comparison except that the generated number is not displayed and the user has cannot ensure the exchanged pubic keys are the same.
2.3.3 Phase 3 - Key distribution
The communication after Phase 2 will be encrypted with a SessionKey generated from LTK. BLE Encryption uses AES-CCM (Counter with CBC-MAC) and one SessionKey provides authentication and confidentiality.
In Phase 3, the master and slave can exchange keys including the Identity Resolving Key (IRK) for device identity and privacy. BLE devices such as mobiles can be tracked if the MAC address is used in advertisement and in later communication. BLE addresses this privacy issue by IRK and a suite of protocols. IRK is used to generate resolvable private addresses in advertisement and communication. Only a device with privacy requirements needs to distribute its IRK and its real MAC address to its peer device. For example, if a mobile needs to protect its MAC address, it distributes its IRK and real MAC address to its peer device first. Then, the mobile uses this IRK to generate a resolvable private address for its packets and the peer device uses the mobile’s IRK to resolve the private address. If the peer device needs to protect its MAC address, it sends its own IRK and MAC address to the device for private address generation and resolution although such it is rarely used in practice.
2.4 Secure Connections Only Mode
For a slave device that provide services, the BLE specification defines the Secure Connections Only mode. This mode provides the highest BLE security level (Mode 1, Level 4 ), in which only the three secure pairing protocols, Passkey Entry, Numeric Comparison and secure OOB, can be used and the BLE Legacy is not allowed. In this mode, if secure pairing is not used, the device shall send the Pairing Failed packet with the error code “Authentication Requirements”.
According to the BLE specification , when a device is in the Secure Connections Only mode, “The device shall only accept new outgoing and incoming service level connections for services that require Security Mode 1, Level 4 when the remote device supports LE Secure Connections and authenticated pairing is used.” Here the service level connection refers to the application layer connection. It can be observed that BLE specifies the use of the Secure Connections Only mode for a slave that provides services, e.g. the blood pressure monitor in Figure 2. However, the BLE specification does not explicitly define (or require) the Secure Connections Only mode for a master, e.g. the mobile in Figure 2.
2.5 ATT Protocol
The Attribute Protocol (ATT) is a server/client protocol with one BLE device as the server and the peer BLE device as the client. For example, the app on the mobile device is a client and the blood pressure monitor is a server in Figure 2. A server maintains services in the format of attributes . The client requests data from the server.
An attribute has four properties: an attribute handle, a universally unique identifier (UUID), a value, and a set of permissions. The attribute handle is used to uniquely identify and access the attribute. If a client wants to read an attribute from a server, it issues a read request to the server with the handle. The UUID refers to the data type. The permission protects attributes on a device and specifies the security levels required in order to access attributes. The permissions include read/write, encrypted read/write, authenticated read/write, and authorized read/write. A read/write attribute can be accessed with no restrictions. An encrypted read/write attribute can only be accessed when pairing is applied and the link is encrypted. An authenticated read/write attribute can only be accessed when the link is encrypted with an authenticated-and-MITM-protection keyAn attribute with the authorized read/write permission can be accessed after authorization111The BLE specification does not explain its usage in detail.. It can be observed that the permission type is related to the pairing protocol type. If the attribute such as the keyboard input is sensitive, a high security level like authenticated read/write shall be used so that secure pairing protocols are used to counter eavesdropping and MITM attacks, and prevent keystroke leaking.
A Bluetooth profile specifies functionalities and features of each layer shown in Figure LABEL:fig:overview for a particular class of applications. A BLE device can implement the Generic Attribute Profile (GATT), which is built upon the ATT protocol, to exchange arbitrary data in the format of attributes with its peer devices. GATT assigns attributes into services and more details can be found in Appendix A.
3 Design Flaws in Android BLE Programming Framework
As we mentioned earlier, the BLE specification defines the Secure Connections Only mode to ensure high security levels. With the Secure Connections Only mode enabled in a BLE device, the device will require secure pairing protocols to authenticate the initiator. But this mode is not enforced for the pairing initiator, e.g., a mobile, so the mobile is not required to authenticate the device. The lack of the mutual authentication with Secure Connections Only mode at both the device is in fact the cause of identified BLE security vulnerabilities.
Interestingly, this insecure practice is strictly followed by modern BLE designs. Our analysis on the Android BLE programming framework proves that Android does not apply the Secure Connections Only mode. We examined the initiation, status management, error handling and bond management throughout the life cycle of a pairing process and identified four design flaws in Android as shown in Table 1.
|Pairing stage||Design flaw|
|Initiation||No mechanism to specify a pairing protocol|
|Status management||No mechanism to timely obtain the negotiated pairing protocol|
|Error handling||Mishandling pairing errors|
|Bond management||No mechanism to remove a suspicious bond and start a new secure pairing process with a bonded device|
Design Flaw 1 - No mechanisms to specify a pairing protocol. The function createBond() in Listing 1 is the only function an Android app can use to start the pairing process with a peer BLE device. It does not accept any input parameter and the Android app cannot specify any pairing protocol even if it knows its peer BLE device’s I/O capabilities. The return value of this function, true or false, indicates if the pairing process has been successfully started. It can be observed from Listing 1 that createBond() checks if the mobile device has an LTK in the device. If an LTK is available, createBond() returns false and will not re-pair with the peer device since the mobile device was paired with the device. It can also be observed that createBond() is an asynchronous call and does not wait for the pairing process to complete. Since Android OS services handle the pairing process, an Android app cannot pause or cancel the pairing process until the pairing is finished.
Design Flaw 2 - No mechanisms to obtain the negotiated pairing protocol on time. Android provides asynchronous mechanisms for an app to know the status of a pairing process after pairing is completed. Through the intent ACTION_BOND_STATE_CHANGED, the app knows pairing status including pairing in progress (BOND_BONDING, pairing failure (BOND_NONE), or pairing succeeded (BOND_BONDED). Through the intent ACTION_PAIRING_REQUEST, the app knows either Passkey Entry or Numeric Comparison is adopted. By registering both intents ACTION_BOND_STATE_CHANGED and ACTION_PAIRING_REQUEST (see more in Listing 2 in Appendix B), an app knows the adopted pairing protocol, Passkey Entry, Numeric Comparison, Just Works or plaintext communication only after the pairing process is completed.
The fact that an Android app knows the negotiated pairing protocol only after the pairing is completed breeds a security vulnerability of stealing a mobile’s MAC address and IRK through the pairing process as shown in Section 4.3. To defeat such attacks, we need to be able to tear down the connection at the time the pairing strategy is determined by exchanged I/O capabilities and before the MAC address and IRK are exchanged during the pairing process, rather than after the pairing process is completed.
Design Flaw 3 - Android mishandles pairing errors. The Android Bluetooth service and stack do not memorize a negotiated pairing protocol. Further, Android does not provide APIs for apps to process pairing errors properly. Two possible pairing related errors in Android are introduced below.
Pin or Key Missing (0x06): When an Android mobile and its peer BLE device are paired, their communication link is encrypted with the negotiated keys including the LTK. If a peer BLE device’s LTK is intentionally removed, the device will send an error code 0x06 to the Android mobile during the connection process. But the Android mobile will not notify the user of this error. Instead, it will automatically communicate with the peer device in plaintext. Moreover, there are no APIs or mechanisms for an Android App to know the 0x06 error ever occurred.
The incorrect processing of the 0x06 error also creates a conflict between the bonding state and the link encryption state. When the 0x06 error occurs, Android does not remove the corresponding LTK, which is supposed to encrypt the communication. The communication will be in plaintext while an Android app may use the Android reflection technique  to call a system level function isEncrypted() in order to check if the communication is in plaintext. However, the reflection technique is not allowed in the newer API since “Using such methods or fields has a high risk of breaking your app” .
Insufficient Authentication (0x05): When an Android mobile tries to access an attribute with the encrypted read/write or authenticated read/write permission at the peer BLE device, the device will check whether the link is encrypted or a secure pairing protocol is used. If not, the peer device sends an error code 0x05, Insufficient Authentication, to the Android mobile. After receiving the error code 0x05, the Android mobile’s Bluetooth service starts a pairing process automatically for the app. The app can learn if the error occurs by checking the attribute access state code via a callback function onCharacteristicRead. The state code is GATT_INSUFFICIENT_AUTHENTICATION when the above error occurs. However, the app cannot stop the pairing process in this callback function. An attacker may spoof a paired device and utilize this 0x05 error to start a pairing process with an Android mobile. This design flaw can be exploited to get the Android mobile’s MAC address and IRK.
Design Flaw 4 - No mechanisms to remove a suspicious bond and to start a new secure pairing process with a bonded device. A third-party Android app cannot remove a bond from the mobile’s list of bonded devices although the user can manually remove the bond with the system settings app. The function removeBond() can delete an LTK associated with the previously connected BLE device, it is a system level API and is not accessible by third party apps. Assuming that an Android app finds the insecure pairing Just Works is used, the app is able to break the connection. However, breaking the connection does not remove the bond, nor are the generated keys removed. The app can not start a new secure pairing process with a bonded device using createBond(.) either.
4 Downgrade Attacks
This section presents the threat model, attack overview, concrete attacks against mobiles and beyond mobiles.
4.1 Threat Model
Our attacks against Android mobiles take the following assumptions. We believe that the assumptions can be easily fulfilled. (i) An attacker can obtain the same type of a victim device to explore its apps and communication protocols. For example, the attacker can purchase the same blood pressure monitor. (ii) The attacker cannot physically access and unlock the mobile. (iii) Our attacks do not need malicious apps installed on the mobile, one difference to many other attacks which require malicious apps for Bluetooth exploitation [48, 59, 69]. (iv) Before the attack, the Android mobile and its peer device are paired using secure pairing protocols such as the Passkey Entry and Numerical Comparison. (v) The Android app is created using the official Android BLE programming framework.
4.2 Attack Overview
Our attacks involve four parties, the sniffer, the blocker, a fake BLE device and a fake mobile. The Adafruit Bluefruit LE Sniffer  is used to sniff BLE communication and collect basic information such as the device MAC address and the name from advertising packets and scan response packets. We use Texas Instruments (TI) CC2640  development boards to simulate the blocker, the fake BLE device and the fake mobile.
A blocker can launch a Denial of Service (DoS) attack and block a victim BLE device from connecting to a victim mobile so that a fake/spoofing device can connect to the victim mobile. We consider the following approaches. (i) A jammer can be used to block the service of a victim device (not applied in this paper). (ii) A mobile acting as a master initiates a connection to its peer BLE device which acts as a slave. The number of connections to a slave is often limited. BLE 4.2 and above allow multiple connections while the number of connections is up to the implementation [16, 18]. For example, BLE 4.2 devices in our experiments allow one or three connections to the slave. In case a slave allows multiple masters, multiple blockers can be used to connect to the victim BLE device and perform the DoS. Please note that connecting is different from pairing. A blocker can always connect to a victim peer device if no other smart device is connected to the victim device and even if the peer device requires secure pairing. Once enough blockers are connected to the victim device, no other smart device can connect to it. (iii) A fake BLE device may increases its advertising frequency and connects to the victim mobile so that the victim device with the same MAC address cannot connect to the victim mobile. Our experiments in Section 7.3 have validated this approach and no blockers are needed.
The fake BLE device and fake mobile are full-fledged BLE devices and are also denoted as spoofing device and spoofing mobile. The BLE attack can be performed in the following steps. First, a fake device emulates a victim device. The attacker can use a sniffer to obtain the MAC address and name of a BLE device. A fake device is then configured to have the same MAC address and name as the victim BLE device. It can forge advertising and scan response packets that contain the same device name and service description as those of the victim device. The fake device can implement the same attributes of the victim device and manipulate the permissions of these attributes. Second, a fake mobile emulates a victim mobile. This requires that the fake mobile know the victim mobile’s MAC address and IRK which is proved possible and will be demonstrated shortly.
During an attack, the four parties will coordinate by the attacker to achieve a particular goal. For example, a blocker can be used to block a victim device so that the victim mobile will connect to the fake device. When the fake device is connected to the mobile, the attacker can change parameters of the BLE protocol such as the I/O capabilities. She can also intentionally create errors to poke the mobile. When the fake device is connected to the victim mobile, the fake mobile can then connect to the victim device to perform a MITM attack, in which the fake device and fake mobile simulated by TI CC2640 can communicate through a UART port.
4.3 Downgrade Attacks against Mobiles
We now show how an attacker can weaponize the design flaws in Section 3, downgrade the pairing protocol established between a victim mobile and peer device, and perform more complicated attacks.
False data injection via Design Flaw 3: To launch this attack, the fake device intentionally creates an error code 0x06. The communication between the Android mobile and the fake device is downgraded to plaintext as discussed in Design Flaw 3. We configure the permission of the attributes of the fake device as read/write so that the access to the attributes does not require any pairing. The fake device can then inject false data to the mobile. This attack cannot be easily detected since the Android mobile does not delete the original LTK. Therefore, even if the user checks the list of bonded devices at the Android mobile’s system settings, the list will not show any aberrations.
In the case of blood pressure monitoring, the false data injection attack may inject false blood pressure readings and misguide the doctors or nurses. Please note here we assume a scenario where BLE is adopted to connect medical equipment such as blood pressure monitors or x-ray imaging tools to data collecting equipment such as the tablet of a doctor or nurse. The purpose is to illustrate the potential threats of design flaws of Android.
Spoofing attack on sensitive information via Design Flaw 3: In addition to the false data injection attack, the attacker can also utilize Design Flaw 3 and perform traffic analysis of the Android mobile. Through the use of Design Flaw 3, the attacker downgrades the communication to plaintext and the fake device can communicate with the Android mobile. Therefore, the fake device is positioned to receive any sensitive information from the Android mobile. We find that many IoT applications implement an application layer password mechanism for the user verification. When an authorized user inputs the password, the fake device can collect this password.
Stealing Android mobile’s IRK and MAC address via Design Flaws 1, 2 and 3: To protect the MAC address from leakage, an Android mobile with API 23 or above uses IRK introduced in Section 2.3.3 by default . According to our experiments, the IRK is generated when the Android device is configured for the first time from the factory settings. It will not change until the device is reset to the factory settings. Any peer BLE device paired with the Android device will receive the same IRK and obtain the mobile’s real MAC address.
To obtain the IRK and MAC address of a victim Android mobile, the fake device needs to intentionally create a 0x06 error message. The communication between the Android mobile and the fake device is then downgraded to plaintext. The attacker also configures the permission of the attributes on the fake device as encrypted read/write. When the Android app tries to access these attributes, the fake device sends a “0x05” error message to the Android mobile, which starts a pairing process accordingly because of the Design Flaw 3. The fake device is configured to have no I/O capabilities so that the Android Mobile and the fake device pair with Just Works (See Design Flaws 1 and 2). Through the Step 10 in Figure 2, the Android mobile distributes the IRK and MAC address to the attacker. With the IRK, the attacker can perform the private address resolution and trace the identity of the Android Mobile every time the mobile uses BLE. We have confirmed this attack in our experiments. This attack defeats the purpose of IRK, which is used to prevent an Android mobile from being tracked.
Denial of Service (DoS) via Design Flaws 1,2,3 and 4: The goal of this DoS attack is to disrupt the communication between a victim mobile and its peer BLE device. According to the IRK stealing attack above, an attacker can first pair a fake device with a victim Android device using Just Works. This pairing process creates a new LTK for the mobile. The attacker then turns off the fake device. The mobile then tries to communicate with the victim device. However, since the LTK on the mobile and the LTK on the victim device are now different, we find that Android cannot detect the two LTKs are different and the communication enters into a deadlock. As we mentioned in Design Flaw 4, there is no public API for an app to remove a bond on the mobile. The app cannot remove the bond or restart the pairing process. The deadlock can only be resolved by manually removing the bond in the Android system setting.
4.4 Attacks Beyond Mobiles
We have introduced attacks against Android mobiles. It is intuitive that those attacks will affect the peer BLE devices paired with the mobiles. We now discuss the attacks beyond mobiles. The threat model for the attacks against peer BLE devices is different from the threat model for attacks against mobiles. In attacks against mobiles, we assume that the attacker cannot touch or unlock the victim mobiles. This is a reasonable assumption because people intend to tend their mobiles carefully. However, the attacker may have physical access to BLE devices in various scenarios. For example, IoT products such as smart lights may be placed outside. Few people physically lock away their BLE keyboards and attackers may press keys of those BLE keyboards. Therefore, we consider the following two attack scenarios against peer BLE devices of mobiles.
Case 1. The attacker can physically access the victim BLE device. Given a mobile cannot enforce secure pairing, an attacker with physical access to the peer BLE device can always launch an MITM attack even if the victim peer device uses the Secure Connections Only mode enforcing secure pairing. To deploy the MITM attack, a fake device connects to the victim mobile using the scheme in the false data injection attack. Since an attacker can touch and play with a victim peer device, she can always pair a fake mobile with the victim device, which may use any pairing protocol, even if the victim device enforces the Secure Connections Only mode. We show later even if the attackers can have physical access to peer BLE devices, once the secure connections only mode is enforced at both the Android device and peer device, our defense can still defeat those attackers.
Case 2. The attacker cannot physically access the device. We also assume that before the attack, the Android mobile and its peer device are paired using secure pairing protocols such as Passkey Entry and Numerical Comparison. Section 2 shows that two secure measures can be adopted to protect sensitive data on a device, namely pairing and attribute permissions. Secure pairing protects the communication and attribute permissions limit access to attributes based on adopted pairing protocols. We find that attribute permissions are often misused and the misused permissions will cause security issues.
Passive eavesdropping attack. This attack works when the victim device has only read/write attributes. We assume that before the attack, the mobile pairs with the peer device that uses the Secure Connections Only mode. To launch this attack, the attacker first blocks the victim device. A fake device is then used to perform the 0x06 error attack so that the communication between the fake device and the victim mobile is downgraded to plaintext. The fake device then goes offline and the blocker is turned off. We find that the victim mobile then communicates with the victim peer BLE device in plaintext and will be able to access the the peer device’s read/write attributes. Since the communication is in plaintext, the attacker can eavesdrop on the communication and retrieve sensitive information using a sniffer. Similar to the false data injection attack, even if the user checks the bonded devices list at the mobile’s system settings, no abnormalities will be observed.
Bypassing the whitelist. A BLE device may use a whitelist of MAC address and IRK to allow connections only from an already paired mobile. As discussed above, an attacker can steal a victim mobile’s MAC address and IRK. Therefore a fake mobile with the same MAC address and IRK can bypass the whitelist mechanism and will be allowed to connect to the victim peer BLE device. Even if the victim BLE device uses the Secure Connections Only mode, the fake mobile can still access read/write attributes of the BLE device after bypassing the whitelist. If the permission of the attributes of the BLE device is encrypted read/write or authenticated read/write, the fake mobile has to pair with the peer device to access the attributes. If the BLE device enforces the Secure Connections Only mode or the attribute permission is authenticated read/write, the fake mobile has to perform secure pairing with the peer BLE device and may not be able to perform the attack. Recall that an authenticated read/write attribute requires secure pairing from the mobile. The attack in Section 5 presents a case study showing bypassing the whitelist leads to end-to-end MITM attacks against BLE keyboards .
5 Case Studies
In this section, we present case studies to demonstrate our attacks against Android and actual BLE products including BLE blood pressure monitors, smart lights, keyboards. Figure 7 in Appendix C shows 18 popular BLE products from various vendors that we have tested, including Logitech’s K380 and K780 Keyboards , Microsoft’s Designer Keyboard , two blood pressure (BP) monitors from iHealth , and QardioArm blood pressure monitor , TNG’s Blood glucose meter , Flux light , Magic Hue light , Magic Light , and MPOW light. Because of the page limit, please refer to Appendix C on the case study of blood pressure monitors demonstrating (i) the false data injection attack by exploiting Android mobiles (ii) passive eavesdropping attack against blood pressure monitors; the case study of smart lights demonstrating the spoofing attack stealing passwords with a fake light; the case study of popular Texas Instruments (TI)’s CC26XX development boards demonstrating the IRK and MAC address stealing attack and how we utilize it to control any BLE device using CC26XX, which implements the Secure Connections Only mode. All the attacks are launched without physical access to the Android Mobile and peer device. We focus on the case study of BLE Keyboards in this section.
In this BLE Keyboard case study, we exploit a BLE keyboard paired with an Android tablet to demonstrate (i) the attack to steal an Android mobile’s IRK and MAC address and (ii) the attack to bypass the whitelist of the keyboard. Based on these two attacks, we also deploy the MITM attack against a victim keyboard. We have implemented the MITM attack against the BLE keyboard with two TI CC2640 development boards in a case as shown in Figure 3. One board works as a fake tablet connecting to the victim BLE keyboard and the other as the fake BLE keyboard connecting to the victim tablet.
To steal the tablet’s IRK and MAC address, we create a fake keyboard, which has the same MAC address and name as the victim keyboard. The fake keyboard has a higher advertising frequency so that it has better chance to connect to the victim tablet instead of the victim keyboard. We do not use a blocker here to block the victim BLE keyboard because a BLE keyboard often implements the whitelist mechanism and accepts only a previously paired mobile. The fake keyboard leverages the attack in Section 4.3 to obtain the IRK and MAC address of the victim tablet.
The fake tablet with the stolen IRK and MAC address can bypass the whitelist mechanism of the victim keyboard. Since the current BLE Human Interface Device (HID) profile  does not enforce the Secure Connections Only mode and requires only encrypted (not authenticated) read/write permission for keyboard services, the fake tablet can remotely pair with the keyboard with Just Works. The fake tablet and fake keyboard can then deploy a MITM attack.
In this section, we try to address the design flaws discussed in Section 3 and present solutions on how to enforce secure pairing within Android. The Secure Connections Only mode shall be implemented as a configurable option for apps to defeat the presented attacks. We have implemented a prototype on Android 8 through the Android Open Source Project (AOSP) . Please note co-located attacks through malwares are addressed in [48, 59, 69] and are out of the scope of this work.
For a mission critical application, the app knows the peer device’s I/O capabilities, which should support secure pairing. With the Secure Connections Only mode enabled at the mobile, the user has to physically authenticate a BLE device. If the negotiated pairing protocol between the mobile and its peer device is not the specified one, the communication shall be rejected and a critical security warning shall be directed to the user. Extra cost of a display or a keyboard and the usability issue of implementing secure pairing protocols may be associated with the proposed solutions.
6.2 Enforcing Secure Pairing
Addressing Design Flaws 1 and 2: specifying a secure pairing protocol. An Android mobile can enforce a secure pairing protocol after the mobile and peer device have determined the pairing protocol through the exchanged I/O capabilities, i.e., after Step 6 and before Step 7 in Figure 2. If the negotiated pairing protocol is not the specified secure pairing protocol, Android should reject further actions and gives the user a security warning. The Android BLE service and stack shall cache the specified secure pairing protocol in memory and save it in a configuration file on its nonvolatile storage if bonding is requested.
To address Design Flaw 1, an app can use our function specifyPairing(.) to store the specified pairing protocol in a configuration file scm.conf through the Java Native Interface (JNI). specifyPairing(.) is a system API. It can programmatically obtain the app’s package name. scm.conf is in the system folder /data/misc/bluedroid/ and stores the app’s package name and metadata including the specified pairing protocol. An app cannot manipulate metadata of another app. When the pairing process starts, Android uses the system function smp_proc_pair_cmd() to exchange the pairing features with the peer device. The bits in an integer peer_io_caps are used to indicate the peer device’s I/O capabilities. Therefore, smp_proc_pair_cmd() can know the negotiated pairing protocol through announced I/O capabilities. In smp_proc_pair_cmd(), we read the configuration file scm.conf and obtain the app’s specified pairing protocol. If the specified pairing protocol and negotiated pairing protocol do not match, smp_proc_pair_cmd() sends the error code SMP_PAIR_AUTH_FAIL to the peer BLE device, halts the pairing process, breaks the connection and sends warning messages to the user.
Note that smp_proc_pair_cmd() can obtain the negotiated pairing protocol at the earliest possible time. This also addresses Design Flaw 2. An app knows its specified pairing protocol will be enforced. If it cannot be enforced, the user will receive a security warning. Multiple apps on one mobile device could request pairing with the same BLE device although we did not find such use. If those apps require different pairing protocols, the one of the highest security shall be used.
Addressing Design Flaw 3: enforcing the specified paring protocol when errors occur. The 0x06 error occurs because the fake device does not have the LTK. The 0x05 error occurs because the BLE connection does not have the permission to access the attributes on the fake device. Android does not notify the user these errors and starts its own (vulnerable) pairing protocol. We address the design flaw as follows. If there is any such pairing related error, the Android BLE service shall notify the user and ask the user whether to pair with the peer device. If the BLE connection has a specified pairing protocol and the user chooses to pair with the peer device, Android will enforce the specified pairing protocol and give the user a security warning if it cannot be enforced.
Addressing Design Flaw 4: removing suspicious bond and starting a new secure pairing. An app shall be able to remove its own bonded devices whenever needed. We make the system API removeBond() available to applications. removeBond() is redesigned so that an app can only remove its own bond, not bonds of other apps. Therefore, a bond shall maintain metadata including the app’s package name. removeBond() will obtain the calling app’s package name and can remove only its own bond. To deal with the rare case that multiple apps use the same device, we can use a mechanism similar to the Linux hard link . A counter is used to record the number of paired apps.
6.3 Security Analysis
We now discuss BLE pairing security if Android addresses the design flaws and enforces secure pairing, and the peer BLE device also enforces secure pairing. Under the assumption that an attacker cannot physically access the mobile or peer BLE device, the attacks in Section 4 will fail since secure pairing requires the attacker (fake mobile) see the victim device and the mobile see the attacker (fake device).
As discussed in Section 4.4, the assumption of no physical access is not always true. Although we can assume the attacker cannot physically access a mobile, we cannot assume the attacker cannot always access a BLE device such as a BLE keyboard. if an attacker can physically touch a BLE keyboard that uses the Passkey Entry pairing protocol, even if both the keyboard and mobile enforces passkey entry, the attacker can still perform the MITM attack as follows. The Passkey Entry pairing protocol is secure only if the attacker cannot obtain the passkey. However, the BLE keyboard is a human input device, which sends whatever keystrokes to a mobile device as long as the mobile device is paired with the keyboards. As shown in Figure 4, if the attacker can physically access the keyboard, she can pair the fake mobile with the keyboard by entering a chosen passkey when the user is away from the device. The fake keyboard later pretends to be the real one and starts a pairing process with the user’s victim mobile. The victim mobile enforces Passkey Entry and requires the user enter a passkey displayed on the victim mobile. However, when the user enters the passkey on the victim keyboard, the fake mobile receives the user entered passkey. The fake mobile then sends the passkey to the fake keyboard, which can then use the passkey to connect to the victim mobile. The attacker can now perform the MITM attack.
The MITM attack above will fail when the victim mobile and keyboard enforce the Numeric Comparison pairing protocol even under the assumption that the attacker can physically access the keyboard. To implement Numerical Comparison, the keyboard must have a display. The attacker’s fake mobile can still be paired with the victim keyboard because of the assumption of physical access. However, when the user pairs the victim keyboard with the victim mobile, the user has to compare the two numbers displayed on the victim keyboard and the victim mobile. With the underlying Numerical Comparison protocol, if the attacker performs the MITM attack with a fake mobile and a fake keyboard in the middle, the two numbers on the victim keyboard and the victim mobile will be different. The MITM attack will be detected and fail.
Based on the analysis above, it can be observed that under the assumption that the attacker can physically access the keyboard, Numerical Comparison is more secure than Passkey Entry. When we enforce secure pairing, Numerical Comparison provides the strongest pairing security. The BLE specification treats Passkey Entry and Numeric Comparison equally and these two secure pairing protocols have the same security level - authenticated-and-MITM-protection. In the specification, if either of the two protocols is applied, the connection is considered as authenticated. This term is not accurate based on our analyses.
7 Attack and Defense Evaluations
In this section, we first evaluate our attacks, and then evaluate our defense measures and its feasibility.
7.1 Android OSes
We tested all design flaws on the mainstream Android versions, from 7.0 to 9.0 and find that all our attacks can be performed with no adjustments (see Table 2). Recall that a fake device may use the 0x05 error in Section 3 to stealthily pair with the victim mobile through Just Works. This approach works under all versions of Android we tested. On Android 7.0, a fake device can also send a security request as introduced in Section 2.3.1 to stealthily pair with the victim mobile while the security request on higher versions of Android will raise a pairing request dialog window asking the user for permission. Such a dialog Window may alert the user.
|Samsung Galaxy S8+||Samsung Official Android 7.0|
|Google Pixel 2||AOSP Android 8.0|
|Samsung Tablet||Samsung Official Android 8.1|
|Samsung Note 8||Samsung Official Android 8.1|
|Google Pixel 2||AOSP Android 9.0|
|BLE apps using createBond()||176|
|BLE Apps using intents for pairing status||29|
7.2 BLE App Security
To evaluate the security of BLE apps, we collected 3501 Android apps from the Androzoo database , which actively collects apps from all major Android app stores including Google Play. All 3501 BLE apps we evaluated are subject to our downgrade attacks. Specifically, we build a tool based on the public framework soot  to scan Android apps and examine how they perform pairing related functionalities. Androzoo provides a set of RESTful APIs  to query apps of interest. To find BLE related apps, we set the query condition as apps that use connectGatt(), which a BLE app must use to connect to a peer BLE device. Among the collected 3501 BLE apps, only 176 apps use the createBond() to explicitly start a pairing process and 29 apps use the intent mechanism (see Table 3).
We manually analyze the 29 apps that use the intent ACTION_BOND_STATE_CHANGED or ACTION_PAIRING_REQUEST. These intents are used for various reasons. Some apps register the intents to determine if the mobile is bonded with the intended device so that it can transmit data. This cannot deter our downgrade attacks since the victim mobile and the victim peer device are bonded under our attacks. We also find that many apps using the programming frameworks in a faulty way. Some apps use ACTION_PAIRING_REQUEST to determine if Passkey Entry or Numeric Comparison is used with the consideration of usability rather than security. These apps automatically input a fixed passkey for the Passkey Entry pairing protocol or “click” the confirmation button for Numeric Comparison when its peer device adopts Numeric Comparison. These strategies make Passkey Entry and Numeric Comparison useless since the user is not involved.
7.3 Keyboard Connection Competition
As discussed in Section 5, when both the victim keyboard and a fake keyboard try to connect to the victim mobile, the one with a higher advertising frequency has a better chance. We now present the impact of the advertising frequency on the success rate of the fake keyboard connecting to the victim mobile. In our experiments, the victim keyboard is put close to an Android mobile as in a normal use scenario, while the fake keyboard is 10 meters away from the keyboard. For each advertising frequency, we perform the connection competition game 20 times. The success rate is the number of successful connections by our fake keyboard over 20. Figure 5 shows the success rate versus the advertising frequency. The success rate is 50% when the advertising frequency of the fake keyboard is 30HZ. The BLE specification sets the highest advertising frequency as 50 HZ, at which the success rate by the fake keyboard is 75%. We use CC2640 for the fake keyboard, which does not work when the advertising frequency is beyond 50HZ.
7.4 Countermeasure Evaluations
We have implemented our defense techniques on a Google Pixel 2 mobile through the AOSP. We launched all our attacks and confirmed that they failed under the patched Android system. For example, in the case of the BLE keyboard, when Numerical Comparison is enforced, the user finds that the two numbers displayed on the victim mobile and keyboard (emulated by a CC2640) are different when the MITM attack is deployed. The user shall reject the pairing and investigate the possibility of attacks.
We also evaluate the performance of our secure pairing strategy, i.e. the overhead caused by the query of the configuration file scm.conf for a specific app’s metadata such as the specified pairing protocol. We tested three cases: 10, 20 and 30 BLE apps using our defense mechanisms on the security enhanced Android mobile. The app of interest is always set as the last one in scm.conf. That is, we consider the worst case of time needed to find the metadata of the app of interest. We run the test for each case 10 times and derive the average time. As shown in Figure 6, the average delay is from 550.6s to 892.5s and is feasible for typical use of BLE apps in a mobile .
8.1 Securing Pairing on iOS
According to the iOS developer guidelines , iOS does not provide a way of enforcing secure pairing protocols either. We also performed all developed attacks against iOS. The false data injection and spoofing attack for sensitive information are the same against iOS. That is, when the 0x06 error occurs, the iOS will not notify the app and user and run the vulnerable protocols similar to Android. The downgrade attack stealing the IRK and mobile’s address does not work since iOS does not respond to the 0x05 error and does not notify the user the error either. This could be a problem of iOS since it misses the error processing. An attacker may steal the IRK and MAC address in another way. We find some apps try to pair with any device of the same model and manufacturer automatically. Since iOS cannot enforce secure pairing, a fake device emulating a device of the same model and manufacturer can use Just Works to pair with iOS. In this case, iOS displays an innocuous dialog box and shows a message such as “Device X would like to pair with your iPhone”, where Device X is the peer device’s name. If the user clicks the “Pair” button, the attacker obtains the IRK and MAC address of the iPhone. The DoS attack does not work against iOS since iOS does not respond to the 0x05 error.
8.2 Other Solutions to BLE Security
There are other ways to secure BLE communication. Many chips such as TI’s CC3220  now support crypto accelerators or can be equipped with a low-cost co-processor such as ATECC608A which only costs ($0.55) . Each device is equipped with a pair of (public key, private key). The private key is stored in the secure storage while the public key is published, for example, as a tamper resistant QR code label on the device’s exterior. A mobile can now get the device’s public key and use public key cryptography such as Elliptic-curve cryptography (ECC) to implement a SSL/TLS-like protocol at the application layer to secure its communication with the peer device, using BLE as only a wireless media. The disadvantage of this approach is it requires extra hardware support.
Another approach is we assume there is no attack the first time the user configures the mobile and device, which can share a secret to protect later communication. The disadvantage of this approach is the assumption may not be true. Our solution of enforcing secure pairing at both the mobile and device can address these issues while defeating other attacks such as co-located attacks requires extra remedies and is addressed in [48, 59].
9 Related Work
Vulnerabilities in Bluetooth: Bluetooth before the Simple Secure Pairing (SSP) is not secure [13, 60, 57, 43, 41] and is out of scope of this paper. The Simple Secure Pairing is also vulnerable. For example, Haataja et al. [35, 36] proposed MITM attacks against SSP of Bluetooth Classic (versions 2.1 and 3.0) in 2010. They assumed that the victim devices use only I/O capabilities to determine the pairing strategy and the attacking devices can pair with victim devices using Just Works. The latest BLE introduces the Secure Connections Only mode in order to defeat those attacks. Our work focuses on the Secure Connections Only mode in Android.
Mike Ryan  built a BLE sniffer over Ubertooth and demonstrated that the Passkey Entry pairing protocol for LE legacy connections is not secure. His tool crackle can crack such connections and target BLE 4.0 and 4.1. Our paper addresses the latest BLE 4.2 and 5.x, which are considered secure against his attacks. The work by Rosa  is similar to Mike Ryan’s work. Working in the area of telemedicine, Zegeye et al. cracked the BLE temporary key used in the pairing process by using a brute-force attack , which also extends the attack in . Dazhi Sun et al.  proposed a method that can break Passkey Entry when the passkey is reused. The similar problem was also discussed in . However, reusing a passkey is not recommended in BLE, which requires a random passkey shall be used in each pairing session with Passkey Entry. We assume a random passkey in this paper.
Bluetooth attacks on mobiles: Jasek et al.  studied possible attacks between a Bluetooth smart device and its mobile app. However, they study BLE 4.0 and 4.1, which do not have the Secure Connections Only mode for BLE. They attacked Passkey Entry with Mike Ryan’s approach . Many works reverse engineer particular products [23, 25, 71, 24, 26] and exploit the faulty app protocols while we focus on the operating system level and programming framework issues. For example, Britt Cyr et al. performed a security analysis of wearable fitness devices . They reverse engineered the devices, BLE communication traffic, and app, and used Mike Ryan’s attacks against pairing. Zhang et al. analyzed the commands from four popular smart wristbands by sniffing packets without reverse engineering the apps , and presented replay and MITM attacks against those particular wristbands. Brian Cusack et al. investigated vulnerabilities of BLE in mainstream wearable devices , and showed that most of the wearables are subject to privacy disclosure. BlueBorne  explored faulty BLE implementations. our attacks are not based on those issues. William et al.  and Melamed et al.  studied the spoofing attack and MITM attack between a Bluetooth smart device and its mobile app. They presented the software based and hardware based attacks, but did not address how to attack two paired devices with a secure pairing protocol. Fawaz et al.  collected and analyzed the advertisement packets from 214 BLE devices. They found that the poor design and implementation of BLE advertisements may lead to privacy leaks. We address pairing security in this paper. Muhammad Naveed et al. , Xu et al.  and Sivakumaran et al.  also addressed Bluetooth security but not on the pairing process.
BLE 4.2 and 5.x have a Secure Connections Only mode to enforce secure pairing such as Passkey Entry and Numerical Comparison for BLE devices. However, the BLE specification does not explicitly require an initiating device such as a mobile to support the Secure Connections Only mode. This creates potential security vulnerabilities against both mobiles and their peer BLE devices. In this paper, we systematically investigate Android’s BLE programming framework and present four design flaws of its pairing protocol. We then present a suite of downgrade attacks and case studies exploiting these design flaws against Android mobiles and peer BLE devices. To defend against these attacks, we patch the discovered design flaws and enforce secure pairing of Android. We have also performed extensive evaluations to validate the discovered attacks and proposed defense mechanisms. In our future work, we will implement and evaluate hardware-supported solutions for BLE security. We will also explore application layer security solutions for BLE devices.
-  Adafruit sniffer. Note: https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-sniffer/introduction Cited by: §4.2.
-  Change logs. Note: http://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/3.20.00.68/exports/changelog.html Cited by: §1, Appendix C - Case Studies.
-  SIMPLELINK-cc13x2-26x2-sdk. Note: http://www.ti.com/tool/download/SIMPLELINK-CC13X2-26X2-SDK Cited by: §1, Appendix C - Case Studies.
-  (2016) Androzoo: collecting millions of android apps for the research community. In Mining Software Repositories (MSR), 2016 IEEE/ACM 13th Working Conference on, pp. 468–471. Cited by: 3rd item, §7.2.
-  (2011) Secure public key exchange against man-in-the-middle attacks during secure simple pairing (ssp) in bluetooth. World Applied Sciences Journal 13 (4), pp. 769–780. Cited by: §1.
-  QardioArm bp monitor. Note: https://www.amazon.com/QardioArm-Wireless-Blood-Pressure-Monitor/dp/B00QU5OCMQ/ Cited by: §5.
-  Flux-bluetooth-smart-light. Note: https://www.amazon.com/Flux-Bluetooth-Smart-Light-Bulb/dp/B016NVSI7G/ref=sr_1_5?ie=UTF8&qid=1529973427&sr=8-5&keywords=bluetooth+light Cited by: §5.
-  Logitech k780. Note: https://www.amazon.com/Logitech-Multi-Device-Wireless-Certified-Refurbished/dp/B079F68RPZ/ref=sr_1_4?ie=UTF8&qid=1548777608&sr=8-4&keywords=k780+keyboard Cited by: §5.
-  Microsoft designer keyboard. Note: https://www.amazon.com/Microsoft-7N9-00009-Designer-Bluetooth-Desktop/dp/B011KRNVQG/ref=sr_1_5?ie=UTF8&qid=1548777781&sr=8-5&keywords=microsoft+designer+keyboard Cited by: §5.
-  TN’g blood-glucose-meter. Note: https://www.amazon.com/FORA-Blood-Glucose-Meter-Bluetooth-Bluetooth/dp/B00I0KTGDE/ref=sr_1_3_a_it?ie=UTF8&qid=1548777894&sr=8-3&keywords=TNG+glucose+meter Cited by: §5.
-  IOBluetoothDevicePair(pairing api). Note: https://developer.apple.com/documentation/iobluetooth/iobluetoothdevicepair Cited by: §8.1.
-  (2016) Staying secure and unprepared: understanding and mitigating the security risks of apple zeroconf. In 2016 IEEE Symposium on Security and Privacy (SP), pp. 655–674. Cited by: §1.
-  (2007) Bluetooth security & hacks. Ruhr-Universität Bochum. Cited by: §9.
The attack vector “blueborne” exposes almost every connected device. Note: https://armis.com/blueborne/ Cited by: §9.
-  (2019) Bluetooth market update 2018. Note: https://www.bluetooth.com/markets/market-report Cited by: §1.
-  (2011) Bluetooth core specification version 4.1. Specification of the Bluetooth System. Cited by: §4.2.
-  (2014) Bluetooth core specification version 4.2, vol 3, part c, page 373, section 10.2.4. Specification of the Bluetooth System. Cited by: §2.4.
-  (2014) Bluetooth core specification version 4.2. Specification of the Bluetooth System. Cited by: §1, §1, §2.3.2, §2.3.2, §4.2.
-  (2016) Bluetooth core specification version 5.0- secure connections only mode, vol 3, part c (2065). Specification of the Bluetooth System. Cited by: §2.4.
-  (2016) Bluetooth core specification version 5.0. Specification of the Bluetooth System. Cited by: §1, §1.
-  (2019) Bluetooth core specification version 5.1. Specification of the Bluetooth System. Cited by: §1.
-  (2010) Bluetooth core specification version 4.0. Specification of the Bluetooth System. Cited by: §2.5.
-  (2008) Bluetooth security in wearable computing applications. In 2008 international symposium on high capacity optical networks and enabling technologies, pp. 182–186. Cited by: §9.
-  (2017) Assessment of security vulnerabilities in wearable devices. Cited by: §9.
-  (2014) Security analysis of wearable fitness devices (fitbit). Massachusets Institute of Technology, pp. 1. Cited by: §1, §9.
-  (2016) Uncovering privacy leakage in ble network traffic of wearable fitness trackers. In Proceedings of the 17th International Workshop on Mobile Computing Systems and Applications, pp. 99–104. Cited by: §9.
-  Restrictions on non-sdk interfaces. Note: https://developer.android.com/about/versions/pie/restrictions-non-sdk-interfaces Cited by: §3.
-  (2016) Protecting privacy of ble device users. In 25th USENIX Security Symposium ( USENIX Security 16), pp. 1205–1221. Cited by: §9.
-  Android open source project. Note: https://source.android.com/ Cited by: 4th item, §6.
-  Severity ranking. Note: https://source.android.com/security/overview/updates-resources Cited by: §1.
-  (2016) Android 6.0 changes. Note: https://developer.android.com/about/versions/marshmallow/android-6.0-changesbehavior-hardware-id Cited by: §4.3.
-  (2016) Inside bluetooth low energy. Artech House. Cited by: §1.
-  (2011) Ten years of bluetooth security attacks: lessons learned. Computer Science I Like 45. Cited by: §1.
-  (2008) Practical man-in-the-middle attacks against bluetooth secure simple pairing. In Wireless Communications, Networking and Mobile Computing, 2008. WiCOM’08. 4th International Conference on, pp. 1–5. Cited by: §1.
-  (2010) Two practical man-in-the-middle attacks on bluetooth secure simple pairing and countermeasures. IEEE Transactions on Wireless Communications 9 (1). Cited by: §1, §9.
-  (2007) “Nino” man-in-the-middle attack on bluetooth secure simple pairing. In 2007 3rd IEEE/IFIP International Conference in Central Asia on Internet, pp. 1–5. Cited by: §9.
-  IHealth webpage. Note: https://ihealthlabs.com/ Cited by: §5.
-  ATECC608A. Note: https://www.microchip.com/wwwproducts/en/ATECC608A Cited by: §8.2.
-  (2016) Gattacking bluetooth smart devices. In Black Hat USA Conference, Cited by: §1, §9.
-  Bluetooth pairing part 4: le secure connections - numeric comparison. Note: https://blog.bluetooth.com/bluetooth-pairing-part-4 Cited by: §2.3.2.
-  (2003) “Man in the middle” attacks on bluetooth. In International Conference on Financial Cryptography, pp. 149–161. Cited by: §9.
-  (2016) Bluetooth low energy security vulnerability and improvement method. In Consumer Electronics-Asia (ICCE-Asia), IEEE International Conference on, pp. 1–4. Cited by: §1.
-  (2004) Relay attacks on bluetooth authentication and solutions. In International Symposium on Computer and Information Sciences, pp. 278–288. Cited by: §9.
-  (2016) Reflection-aware static analysis of android apps. In Automated Software Engineering (ASE), 2016 31st IEEE/ACM International Conference on, pp. 756–761. Cited by: §3.
-  What happens when you delete a hard link?. Note: https://unix.stackexchange.com/questions/50179/what-happens-when-you-delete-a-hard-link Cited by: §6.2.
-  (2018) Security vulnerabilities in bluetooth technology as used in iot. Journal of Sensor and Actuator Networks 7 (3), pp. 28. Cited by: §1.
-  (2018) An active man-in-the-middle attack on bluetooth smart devices. Safety and Security Studies, pp. 15. Cited by: §1, §9.
-  (2014) Inside job: understanding and mitigating the threat of external device mis-binding on android. In 21st Annual Network and Distributed System Security Symposium, NDSS 2014, San Diego, California, USA, February 23-26, 2014, Cited by: §1, §4.1, §6, §8.2, §9.
-  (2015) Security vulnerabilities of bluetooth low energy technology (ble). Tufts University. Cited by: §1.
-  (2017) Evaluating the impact of malicious spoofing attacks on bluetooth low energy based occupancy detection systems. In Software Engineering Research, Management and Applications (SERA), 2017 IEEE 15th International Conference on, pp. 379–385. Cited by: §9.
-  (2013) Bypassing passkey authentication in bluetooth low energy.. IACR Cryptology ePrint Archive 2013, pp. 309. Cited by: §1, §9.
-  RESTful api. Note: https://searchmicroservices.techtarget.com/definition/RESTful-API Cited by: §7.2.
-  (2013) Bluetooth: with low energy comes low security. In Proceedings of the 7th USENIX Conference on Offensive Technologies, WOOT’13, Berkeley, CA, USA, pp. 4–4. External Links: Cited by: §1, §9, §9.
-  BLE v4.2: creating faster, more secure, power-efficient designs—part 3. Note: http://www.electronicdesign.com/communications/ble-v42-creating-faster-more-secure-power-efficient-designs-part-3 Cited by: §2.3.1.
-  (2012) Analysis of bluetooth threats and v4. 0 security features. In 2012 International Conference on Computing, Communication and Applications, pp. 1–4. Cited by: §1.
-  How many mobile apps are actually used?. Note: https://www.apptentive.com/blog/2017/06/22/how-many-mobile-apps-are-actually-used/ Cited by: §7.4.
-  (2005) Cracking the bluetooth pin. In Proceedings of the 3rd international conference on Mobile systems, applications, and services, pp. 39–50. Cited by: §9.
-  (2018) A low energy profile: analysing characteristic security on ble peripherals. In Proceedings of the Eighth ACM Conference on Data and Application Security and Privacy, pp. 152–154. Cited by: §9.
-  (2018) Attacks against ble devices by co-located mobile applications. arXiv preprint arXiv:1808.03778. Cited by: §4.1, §6, §8.2, §9.
-  (2007) BlueSniff: eve meets alice and bluetooth.. WOOT 7, pp. 1–10. Cited by: §9.
-  (2018) Man-in-the-middle attacks on secure simple pairing in bluetooth standard v5. 0 and its countermeasure. Personal and Ubiquitous Computing 22 (1), pp. 55–67. Cited by: §9.
-  CC3x20, cc3x35 simplelink wi-fi and internet of things network processor programmer’s guide. Note: http://www.ti.com/lit/ug/swru455h/swru455h.pdf Cited by: §8.2.
-  SimpleLink bluetooth low energy cc2640r2f wireless mcu launchpad development kit. Note: http://www.ti.com/tool/LAUNCHXL-CC2640R2 Cited by: §4.2.
-  (2016) Denial of sleep attacks in bluetooth low energy wireless sensor networks. In MILCOM 2016-2016 IEEE Military Communications Conference, pp. 1231–1236. Cited by: §1.
-  (2000) Optimizing java bytecode using the soot framework: is it feasible?. In International conference on compiler construction, pp. 18–34. Cited by: §7.2.
-  Magic light. Note: https://www.amazon.com/dp/B073S1KV4F/ Cited by: §5.
-  Magic-hue-bluetooth-smart-light. Note: https://www.amazon.com/Magic-Hue-Bluetooth-Smart-Light/dp/B06XKNC78J/ Cited by: §5.
-  (2011) HID service specification 1.0. Cited by: §5.
-  (2019) BadBluetooth: breaking android security mechanisms via malicious bluetooth peripherals. In Proceedings of the 26th Annual Network and Distributed System Security Symposium (NDSS’19), San Diego, CA, Cited by: §1, §4.1, §6, §9.
-  (2015) Exploiting bluetooth low energy pairing vulnerability in telemedicine. In International Telemetering Conference Proceedings, Cited by: §1, §9.
-  (2017) Security analysis of bluetooth low energy based smart wristbands. In Frontiers of Sensors Technologies (ICFST), 2017 2nd International Conference on, pp. 421–425. Cited by: §9.
Appendix A - BLE Profiles
A Bluetooth profile specifies functionalities and features of all layers in Figure LABEL:fig:overview for a particular class of applications. A profile can be considered as a specific application. For example, the Human Interface Device Profile (HID) defines rules that allow a HID device, such as a keyboard, using Bluetooth to accept inputs from humans and shows the output to humans. A profile may contain other profiles and protocols as its building blocks to implement functionalities. The Generic Access Profile (GAP) defines the basic requirements of a Bluetooth device and all Bluetooth devices implement GAP. For example, GAP performs advertising and scanning.
A smart device can implement the Generic Attribute Profile (GATT), which is built upon the ATT protocol, to exchange arbitrary data in the format of attributes with its peer devices. GATT organizes attributes into services. A service contains zero or more characteristics, which are also attributes and user data containers. A characteristic contains zero or more descriptors, which provide more metadata. A primary service provides the primary functionality of the device. A secondary service can work as a building block and should be included in the primary service.
Appendix B - Using Current Android Mechanisms to Detect Pairing protocol
Appendix C - Case Studies
Blood Pressure Monitors: In this case study, we demonstrate that (i) the false data injection attack by exploiting Android mobiles; and (ii) passive eavesdropping attack against blood pressure monitors. Blood pressure monitors in our experiments may use a secure pairing method to pair with an Android mobile. For example, the iBalance Blood pressure monitor has a display and a button, and uses the Passkey Entry to pair with a mobile. The app collects readings from the monitor. To attack Blood Pressure monitors, we reverse engineered the app to understand its application layer protocol. We are able to deploy the downgrade attack against the mobile for false data injection. Particularly, a fake monitor is created using a TI CC2640 development board, which sends false blood pressure measurements to the mobile. The attributes of all the blood pressure monitors in our experiments are configured as read/write. Therefore, they are subject to our passive eavesdropping attack.
Smart Lights: In this case study, we demonstrate that (i) the spoofing attack stealing passwords by a fake light; and (ii) DoS attack. Recall that a BLE app may use passwords to implement authorization and limit who can use the devices. In our experiments, we find the Flux smart light uses the Passkey Entry pairing protocol. We assume the app uses secure pairing to securely set up the password on the light. To steal the password, an attacker can use a blocker to block the service of the light. A fake light can then be positioned to connect to the Android mobile when the user opens the app to use the light. The app will send the password to the fake light controlled by the attacker, who can then control the BLE light.
To deploy the DoS attack, the fake light with the victim light’s MAC address uses Just Works and pairs with the victim mobile so that a new LTK will be generated for the victim mobile. The fake light then goes offline. The communication between the mobile and the real light then fails since the LTKs on the two sides are different. As discussed in Section 4.3, the mobile can not access the service provided by the real light until the user manually removes the bond with the Android system setting app.
CC26XX Development Boards from Texas Instruments: We now use the case study to demonstrate the impact of leaking a mobile’s MAC address on BLE devices using TI chips. TI is a leading BLE chip manufacturer, which implements multiple security levels for its widely used BLE chips. We find two critical vulnerabilities in TI’s BLE SDK.
First, the TI’s BLE SDK incorrectly implements the Secure Connections Only mode. TI’s SDK allows an application to set a Secure Connections Only mode flag as true or false. However, the related code only checks if the incoming pairing request enables the Secure Connections (SC) bit and does not check if the negotiated pairing protocol is the Passkey Entry or Numerical Comparison protocol. The SC bit only refers to if a mobile or its peer BLE device supports BLE 4.2 and 5.x.
Second, the TI’s BLE stack caches and reuses the LTK’s property for a bonded mobile. A LTK can be an unauthenticated-and-no-MITM-protection key created by Just Works or an authenticated-and-MITM-protection key created by Passkey Entry, Numeric Comparison or OOB. Assume that a victim mobile uses secure pairing to pair with a victim BLE device based on TI chips and generate an authenticated-and-MITM-protection LTK. If a fake mobile with the victim mobile’s MAC address uses Just Works and pairs with the victim device, the generated LTK still has the property of authenticated-and-MITM-protection. Therefore, the fake mobile can access attributes with the authenticated read/write permission. We have tested and proved the vulnerabilities on TI’s CC2640, CC2640R2F, and CC2650, and reported the identified vulnerabilities to TI and a patched SDK was released recently [3, 2].