Next Article in Journal
Trajectory-Assisted Municipal Agent Mobility: A Sensor-Driven Smart Waste Management System
Next Article in Special Issue
Model Mediation to Overcome Light Limitations—Toward a Secure Tactile Internet System
Previous Article in Journal
Priority-Based Machine-To-Machine Overlay Network over LTE for a Smart City
Article Menu

Export Article

J. Sens. Actuator Netw. 2018, 7(3), 28; https://doi.org/10.3390/jsan7030028

Review
Security Vulnerabilities in Bluetooth Technology as Used in IoT
1
Fordham Center for Cybersecurity, Fordham University, New York, NY 10023, USA
2
Computer Science Department, New York Institute of Technology, Old Westbury, NY 11568, USA
3
Computer Engineering Department, Hashemite University, Zarqa 13133, Jordan
*
Author to whom correspondence should be addressed.
Received: 24 April 2018 / Accepted: 12 July 2018 / Published: 19 July 2018

Abstract

:
Bluetooth technology is a key component of wireless communications. It provides a low-energy and low-cost solution for short-range radio transmissions. Bluetooth, more specifically Bluetooth Low Energy (BLE) has become the predominant technology for connecting IoT (Internet of Things). It can be found in cell phones, headsets, speakers, printers, keyboards, automobiles, children’s toys, and medical devices, as well as many other devices. The technology can also be found in automated smart homes, to provide monitors and controls for lights, thermostats, door locks, appliances, security systems, and cameras. Bluetooth offers convenience and ease of use, but it lacks a centralized security infrastructure. As a result, it has serious security vulnerabilities, and the need for awareness of the security risks are increasing as the technology becomes more widespread. This paper presents an overview of Bluetooth technology in IoT including its security, vulnerabilities, threats, and risk mitigation solutions, as well as real-life examples of exploits. Our study highlights the importance of understanding attack risks and mitigation techniques involved with using Bluetooth technology on our devices. Real-life examples of recent Bluetooth exploits are presented. Several recommended security measures are discussed to secure Bluetooth communication.
Keywords:
Bluetooth; Bluetooth hacking; Bluetooth attacks; Bluetooth countermeasures; Bluetooth security; IoT; BlueBugging; BlueJacking; BlueBorne; Bluetooth vulnerabilities

1. Introduction

Bluetooth was invented in 1994 at Ericsson, a telecommunications company in Sweden, and was introduced to create ad hoc, short-range wireless networks that allowed devices to connect with one another. In 1998, Ericsson joined with IBM, Intel, Nokia, and Toshiba to create a Special Interest Group (SIG), which developed and promoted the open industry standard for Bluetooth technology. In 2000, the first Bluetooth-enabled device, a headset, arrived in stores, and two years later, in March 2002, Bluetooth technology was ratified by IEEE for 802.15.1 [1,2].
Bluetooth 1.1 and, the later improved version of Bluetooth, Bluetooth 1.2 are known as Basic Rate (BR). They allow transmission speeds up to 1 Mbps. Bluetooth version 2.0, known as Enhanced Data Rate (EDR), allows transmission speeds up to 3 Mbps. Bluetooth version 3.0, known as High Speed (HS), provides data rates up to 24 Mbps. Bluetooth version 4.0, known as Low Energy (BLE), is simple and more efficient; offers 1 Mbps and achieves lower power consumption for use in medical devices [3]. Bluetooth 4.1 and 4.2 are the most updated versions. The technology, developed for coin cell battery-powered devices (e.g., medical devices), provides both Low Energy and BR/EDR/HS [4]. Bluetooth 4.1 offers speeds in range of 1–3 Mbps, while Bluetooth 4.2 offers 1 Mbps using Gaussian frequency shift keying (GFSK) [4]. GFSK is a method of modulation used for digital communication and is one method used in Bluetooth technology [5]. It is able to send information by shifting carrier frequencies by Gaussian filtering square-wave signals and by increasing or decreasing the duration of carrier frequencies based on symbols (i.e., decreasing the frequency for 0 and increasing the frequency for 1) [5].
Bluetooth 5 has been announced as the next version of Bluetooth. It will also be known for Low Energy mode [6].
Bluetooth, specifically BLE, has become the preferred technology for IoT devices. This is mainly because of its ability to use minimum power while facilitating data exchanges. The technology is also able to maintain the standard communication range during the exchange. This low energy version of Bluetooth could positively affect IoT technology, by giving devices the ability to exist and successfully function in a wide variety of application scenarios [7].
The objectives of this paper are to:
  • Present an overview of Bluetooth technology with a focus on its security, vulnerabilities, threats, and risk mitigation solutions.
  • Provide real-life examples of recent Bluetooth exploits.
  • Discuss several recommended measures to secure Bluetooth communication.
The remainder of this paper is organized as follows. Section 2 presents related work. A brief overview of Bluetooth technology is presented in Section 3, followed by Bluetooth security in Section 4. Section 5 discusses Bluetooth vulnerabilities, as well as threats and their descriptions. In Section 6, Bluetooth risk mitigation and countermeasures are presented. Bluetooth commercial examples with security flaws are discussed in Section 7. Section 8 discusses recommended measures for securing Bluetooth communication. Finally, Section 9 provides a conclusion for the paper.

2. Related Work

As Bluetooth technology continues to evolve and improve, security experts continue their research with the goal of obtaining information on the newest version of the technology to gain insight, enhance security, and develop updated versions.
In “Bluetooth Security Threats and Solutions: A Survey”, the authors presented reports of Bluetooth threats since the technology’s inception up until 2007 [8]. There have been additional attacks recorded, as well as an increase in the range of devices that have been targeted. This comes as a result of the increase in IoT devices in the market. This is further discussed in our work.
In “A Survey on Security Threats and Vulnerability attacks on Bluetooth Communication”, the authors discuss different Bluetooth vulnerabilities [9]. These vulnerabilities are further discussed, and a Bluetooth attack taxonomy is introduced in our work.
In “Security Threats in Bluetooth Technology”, the authors provide an overview of Bluetooth technology, including its background and architecture, as well as different types of attacks and prevention methods [10]. Our work introduces Bluetooth 4, addresses Bluetooth’s relationship to IoT, and provides real-life examples of exploits.
In “Bluetooth Low Energy Mesh Networks: A Survey”, the authors provide an in-depth overview of BLE Mesh Networks and briefly touch on security in IoT networks [11]. Our work further expands on this by discussing specific Bluetooth vulnerabilities and threats.
In “A Survey on Wireless Security: Technical Challenges, Recent Advances, and Future Trends”, the authors provide information on wireless security and physical layer-based attacks [12]. Our work focuses in on Bluetooth technology and provides real-life examples of Bluetooth exploits.
In addition to the works cited above, more research on Bluetooth technology has been done and several other papers have been published that exceed the scope of our work. Our paper provides updated information on types of Bluetooth attacks, as well as discusses real-life exploits.

3. Overview of Bluetooth Technology

In this section, we provide an overview of Bluetooth technology, which is used for short-range wireless communication. The technology enables data communication in computers, mobile phones, medical devices, and many other wireless devices. Below, we discuss Bluetooth frequency and connectivity ranges, including the three device classes of connectivity, the potential for interference, and how Bluetooth prevents such interferences; the Bluetooth piconet, which describes and illustrates device connectivity formation; and the Bluetooth protocol stack for Bluetooth 1, 2, and 3 and another for Bluetooth 4, which describe and illustrate Bluetooth protocol architecture. We also describe potential attacks and security failures in the different layers.

3.1. Bluetooth Frequency and Connectivity Ranges

Bluetooth enables, low power communication between devices that are in close proximity of each other. It operates in the unlicensed Industrial, Scientific, and Medical (ISM) radio frequency (RF) 2.4 GHz spectrum and has a range from between 0.5–1 m to 100 m [2].
The technology has three classes of devices, which offer three different connectivity ranges. Class 1 devices offer a range of 100 m and transmit at 100 mW [2]. Class 2 devices, the most common devices, have a range of 10 m and transmit at 2.5 mW [2]. Class 3 devices have a range of about 1 m and transmit at 1 mW [2].
One main advantage of the technology is its ability to transmit both voice and data simultaneously; however, the 2.4 GHz radio frequency spectrum is shared with many consumer appliances (i.e., microwaves, baby monitors, and cordless phones), which could cause interference [2,13]. According to research, coexistence in wireless technologies resulted in Bluetooth signals being harmed significantly by other wireless technologies [13]. For this reason, Bluetooth technology uses hops in the Bluetooth frequency at 1600 hops per second and a technology called spread spectrum to avoid interference.

3.2. Bluetooth Piconet

Bluetooth technology can be used to connect almost any two Bluetooth-enabled devices. The devices can communicate by the formation of a Bluetooth network, known as a piconet. A piconet is a spontaneous, ad hoc network that enables two or more Bluetooth devices to communicate with one another [2,14]. In the network, one device is designated as the master, while all other devices are designated as slaves [2]. There can only be one master device, which serves as the controlling device in the piconet. There can be up to seven active slave devices. These devices are able to request and transmit data to the master device. The connection between a cell phone (master) and a smartwatch (slave) is an example of a simple Bluetooth piconet. Figure 1 below provides an illustration of a sample Bluetooth piconet.

3.3. Bluetooth Protocol Stack

Figure 2 below illustrates the Bluetooth protocol stack for Bluetooth versions 1, 2, and 3. The stack consists of a variety of Bluetooth protocols, including the Logical Link Control Adaptation Protocol (L2CAP), Link Management Protocol, Radio Frequency Communications (RFCOMM) protocol, and the Service Discovery Protocol (SDP) [15,16]. While all of the protocols in the stack are illustrated below, there are cases when only a small vertical piece of the stack is needed.
A Host Controller Interface (HCI) which is also seen in the illustration (Figure 2) above, is the command interface, which incorporates a baseband controller and link manager. This interface enables both hardware access and register control.
Figure 3 below illustrates the protocol stack for Bluetooth 4 [17]. The stack consists of three layers, the Controller Layer, the Host Layer, and the App Layer [17]. Each of the layers incorporate different protocols. The Controller Layer incorporates the Physical Layer, Direct Test Mode, Link Layer, and Host Controller Interface [17]. The Host Layer incorporates the Logical Link Control and Adaptation Protocol, Attribute Protocol, Security Manager, Generic Attribute Profile, and Generic Access Profile [17]. The App Layer incorporates Applications [17].

4. Bluetooth Security

In this section, we discuss Bluetooth security. There are two guides and standards for Bluetooth protocols and security, NIST 800-121-R1 and IEEE 802.15.1. NIST 800-121-R1 details the recommended Bluetooth security processes. These recommendations include the authentication and verification of the sender, confidentiality regarding information, and authorization in regard to who has control over access to the information. IEEE 802.15.1 is the standard for Bluetooth Wireless Technology. It discusses Bluetooth security in addition to the protocols surrounding Bluetooth technology.
A. Bluetooth Security Modes
All Bluetooth devices operate in 1 of 4 defined access security modes: Security Mode 1 (non-secure); Security Mode 2 (service level enforced security); Security Mode 3 (link level enforced security); and Security Mode 4 (service level enforced security with encrypted key exchange).
The Security Mode determines available service security levels. Security Modes 1 and 3 do not specify service security levels. Security Mode 2 can enforce any combination of the following basic security services: authentication, confidentiality, and authorization. Security Mode 4 specifies five levels of service security [3]. In this mode SHA-256 is used for hashing and AES CCM is used for encryption. It also uses Secure Simple Pairing (SSP) for key generation. Mode 4 is listed as the mandatory mode for Bluetooth versions 2.1 + EDR and newer versions [18].
B. Bluetooth Trust Modes
In addition to the security modes discussed above, there are two levels of trust for Bluetooth devices, trusted and untrusted. They are described as follows:
(1)
Trusted—A trusted device has established a fixed relationship with another device and has unrestricted access to all services.
(2)
Untrusted—An untrusted device only has access to a restricted set of services. Although the device has passed authentication successfully, it does not have a fixed relationship with another device.
C. Discoverability in Devices
Discoverability modes of Bluetooth devices also affect the device’s security. Devices in discoverable mode are more vulnerable, as they can be recognized. The device name, class, list of services, and technical information are all exchanged in discoverable Bluetooth devices that are in range (approximately 10 m). In addition, every Bluetooth device has a unique 48-bit address used for identification, known as the BD_ADDR [2]. This address is similar to a MAC address, which is a manufacturer assigned address for hardware that serves as a unique identification number [2]. The BD_ADDR, like a MAC address, is assigned by the manufacturer [2].
D. Bluetooth Security Services
The first time that two devices attempt a connection, a trusted relationship needs to be established through authentication [2]. Authentication is performed by using challenge-response, based on BD_ADDR and a link key [2]. The link keys, once established, are kept by both devices to be used for future pairing [2]. In older versions of Bluetooth (v2.0 and earlier), common secret PIN codes, which are passkeys required for first time Bluetooth connections, are used [2]. The PINs are used by both devices and consist of between 4 and 16 characters [2]. These codes are specifically used for link-key generation [2]. This is illustrated in Figure 4 below [8,19]. In some cases, once the PIN is set, it cannot be changed [2]. It is also important to note that two devices cannot communicate or be paired if the devices have fixed PINs [20]. Newer versions of Bluetooth (v2.1 and later) use SSP for the pairing process, which utilizes public key cryptography instead of a PIN [2,19]. This protocol is illustrated in Figure 5 below [19].
Authorization begins by first determining whether the device had previously been authorized as a trusted device [2]. If the device database lists it as a trusted device, then access to services is granted [2]. If the device is not listed as a trusted device, trust must first be established before it can be authorized [2].
Confidentiality is achieved through encryption, more specifically the use of the E0 stream cypher [2]. A link key and the BD_ADDR of the device are used to develop a keystream that when combined with plaintext achieves a cyphered text [2,12]. Attacks and cryptanalysis attempts on E0 have proven that the stream cipher is vulnerable to attacks.
E. Built-in Security Features
Bluetooth technology has certain built-in features that help secure the technology. They include:
(1)
Adaptive Frequency Hopping: Frequency hopping in Bluetooth uses a 2.4 GHz ISM band with 79 channels to enable hops at 1600 hops per second. During the hopping, existing frequencies are excluded. The ability to frequency hop reduces both jamming and interference.
(2)
E0 Cipher Suite: The cipher generally has a key length of 128 bits and uses stream ciphering.
(3)
Undiscoverability: This prevents devices from responding to scanning attempts. A device’s 48-bit BD_ADDR address is also concealed.
(4)
Pairing: Pairing enables devices to communicate. A device’s BD_ADDR must be known for a pairing request to be made. The BD_ADDR, which is discussed in the previous two sections, is identified from knowledge of previous pairing or by scanning.

5. Bluetooth Vulnerabilities and Threats

In this section, we discuss the vulnerabilities in different versions of Bluetooth. We then discuss Bluetooth attacks, which are a result of vulnerabilities in the technology. Finally, we introduce the Bluetooth threat taxonomy and discuss common Bluetooth attacks.

5.1. Vulnerabilities in Bluetooth Versions

The version of Bluetooth that is being used, and the security of communications between devices, which is only as strong as the weakest link (i.e., the device with the oldest (weakest) version) is important when discussing Bluetooth vulnerabilities [2]. Since many older devices are still being used today, the vulnerabilities in the older versions of Bluetooth continue to be present [2].
(1)
Versions before Bluetooth 1.2: Link keys, which are based on static unit keys, are used for pairing and can be reused [2]. If the key is retrieved, malicious devices can eavesdrop on the original devices, as well as spoof the original device and/or connected devices [2].
(2)
Versions before Bluetooth 2.1 + EDR: Codes that consist of short PINs are permitted [2]. These PINs are easy for attackers to guess due to their short length [2]. These versions are lacking in PIN management, which is a desirable security capability at an enterprise level [2]. In addition, the keystreams in these early versions become vulnerable after being connected for 23.3 h [2]. This is the time period at which the keystream repeats [2]. This increases an adversary’s ability to decrypt messages [2].
(3)
Versions 2.1 and 3.0: If Security Mode 4 devices are connecting to devices that do not support Security Mode 4, earlier security modes are used in the connection [2]. For example, it is possible that Security Mode 1, which offers no security, will be used [2]. This rollback in security modes makes versions 2.1 and 3.0 more vulnerable to attacks [2]. In addition, SSP static keys are used in versions 2.1 and 3.0, which increases the device’s vulnerability to Man-in-the-Middle attacks [2].
(4)
Versions before Bluetooth 4.0: There is an unlimited number of authentication challenge requests, which enables adversaries to obtain information on many challenge responses [2]. This allows them to gain insight on secret link keys [2]. In addition, the stream cipher E0 function, which is used in early versions, is considered weak [2].
(5)
All versions of Bluetooth: Adversaries can view and potentially modify link keys if they are stored improperly [2]. In addition, encryption key lengths may be small, which can make them vulnerable to attackers [2]. It is possible that encryption keys can be as small as 1 byte [2]. Regarding authentication, there is no user authentication [2]. The Bluetooth standard only includes device authentication [2]. It is important to note that a device can remain in discoverable/connectable mode for an indefinite period of time [2,3].

5.2. Bluetooth Taxonomy of Attacks

The Bluetooth threat Taxonomy illustrated below in Figure 6, outlines, and classifies Bluetooth-based threats [21]. This classification system can help determine the severity of threats, provides precautionary methods, and presents reactionary strategies [21]. Some threats may display characteristics of several classifications; however, they are classified based on their predominant characteristic [21].

5.3. Common Bluetooth Attacks

The pairing process is a main contributor to security issues found in Bluetooth [2]. Attacks can be performed during different stages of the pairing process including before the pairing process has completed and after devices are paired [2]. For example, attackers may be able to carry out Man-in-the-Middle attacks based on information they collected after pairing [2]. Some of the more common attacks on Bluetooth are described below:
A. MAC Spoofing Attack
The attack is performed before encryption is established and during the formation of the piconet when link keys are being generated [8]. Devices are able to authenticate each other by generating link-keys [3,22]. During the attack, attackers can imitate another user [8]. They also have the ability to terminate connections or intercept/modify data with the use of special tools [8]. Figure 7 below illustrates a MAC Spoofing attack [23].
B. PIN Cracking Attack
The attack occurs during the device pairing and authentication process. An attacker uses a frequency sniffer tool to collect the RAND and the BD_ADDR of the targeted device. A brute-force algorithm (E22 algorithm) is then used to test all possible permutations of the PIN with the data previously collected until the correct PIN is found [8]. Figure 8 below illustrates the PIN cracking attack structure [24].
C. Man-in-the-Middle Attack
Man-in-the-Middle Attacks such as the one illustrated in Figure 9 below occur when devices are attempting to pair [25]. During the attack, messages are relayed unknowingly between the devices [9]. This enables authentication without the shared secret keys [9]. In a successful attack, the user believes the pairing was successful; however, this is not the case, as the two devices are paired to the attacker [8,9].
D. BlueJacking Attack
During a BlueJacking attack, the attacker sends unsolicited messages to a device to trick the user into using an access code [8]. This enables the adversary to access files on the targeted device. The devices involved in the attack and the exact source of the message received need to be within a specific range, 10 m, for the attack to be successful [8]. This attack is commonly used in crowded areas (e.g., airports, shopping malls, and train stations) [8]. While it does not usually involve the alteration of data, it could make devices susceptible to other attacks [8].
E. BlueSnarfing Attack
The attack involves hacking into a mobile phone and stealing any of the data stored in the phone’s memory, such as contacts, calendar entries, images, etc. [8]. During the attack, the attacker connects by exploiting the OBEX File Transfer Protocol, a file transfer program used in Bluetooth [26]. This enables the attacker to pair with the user’s device. Figure 10 below illustrates a BlueSnarfing attack [27].
F. BlueBugging Attack
The attack occurs in the RFCOMM protocol [28]. Physical connections are made via L2CAP + base band and it emulates serial RS-232 connections [28]. During the attack, the attacker connects to the target device without the knowledge of the owner [8]. The attacker then takes over the device by gaining access to the device’s set of “AT” commands, which are attention commands that send instructions to the module [8]. This enables the attacker to execute commands as if he was the device owner [8]. The attacker can also steal information and access the phone’s services and settings [8].
G. BlueBump Attack
The attack occurs when there is a weakness in the handling of link keys [29,30]. During the attack a business card is sent between the attacker and user [30]. By forcing the user to accept the card, a trusted and authenticated connection is made [30]. After the pairing, the user then has the ability to delete the link key; however, the user unknowingly still has an active connection to the attacker [30]. The attacker is then able to pair with the device later without authenticating by simply requesting link-key regenerations [30]. The attacker can continue to pair with the target device if the key is not deleted [30].
H. BlueDump Attack
During the attack, the attacker spoofs the BD_ADDR of one of the devices to connect with the other [31]. During pairing, the target device sends an authentication request [31]. The attacker responds with ‘HCI_Link_Key_Request_Negative_Reply [31]. This is a result of the attacker not having a link key. In some cases, the device targeted deletes its link key [31]. It then goes into pairing mode [31].
I. BluePrinting Attack
The attack is carried out by combining the information that is revealed about a device to gain additional information, such as the manufacturer, device model, and firmware version [8,32]. This attack can only be performed when the BD_ADDR of the device is known [8].
J. Blueover Attack
Blueover and its successor Blueover II are auditing tools that are used to determine if a Bluetooth device is vulnerable, but they can also be used to initiate a BlueBugging attack [8].
K. BlueBorne Attack
The attack is conducted by exploiting a stack buffer overflow flaw [33]. By targeting the processing of pending client L2CAP configuration responses, the attacker is able to hijack Bluetooth connections [33]. This enables them to control a targeted device’s embedded content and functions. For the attack to be successful, only MAC and Bluetooth addresses are needed [34].
L. Fuzzing Attack
The attack occurs when the adversary attempts to cause a device to behave abnormally by sending malformed data packets and non-standard data to a device’s Bluetooth radio [3,35]. The attacker then watches how the device reacts to the data packets being sent [3]. If the device’s operations become sluggish or stop during these attacks, the attacker could infer that the protocol stack has vulnerabilities [3].
M. Off-Line PIN Recovery Attack
During the attack, the attacker tries to intercept the IN_RAND value, LK_RAND values, AU_RAND value, and SRES (signed response) value [9]. The SRES value is a matching variable needed for authentication [9]. The attacker then uses brute-force to obtain a PIN that could be used to determine the correct SRES value, which is equal to the intercepted SRES value [9].
N. Brute-Force BD_ADDR Attack
This attack is a scanning attack on the last three bytes of the BD_ADDR of a device [8]. It is important to note that the first three bytes, which are known publicly, can be set as fixed [8,9].
O. Reflection/Relay Attack
The attack occurs when the adversary impersonates a device [8]. The attacker is not looking for any undisclosed information during the attack [9]. It simply authenticates the connection by reflecting/relaying device information [8].
P. Backdoor Attack
The attack occurs when establishing a trusted relationship during pairing [8]. During the attack, the adversary does not appear in the register of paired devices on the target device [8]. After a relationship is established, the attacker has access to the devices services and resources [8]. This access is unbeknownst to the device owner [8]. The BD_ADDR of the target device needs to be known for a backdoor attack to be successful [9]. It also needs to be determined that the device targeted by the attacker is vulnerable to the attack [8].
Q. Denial of Service Attacks
DDoS (Distributed Denial of Service) and ordinary DoS are two types of Denial of Service attacks [36]. For ordinary DoS attacks, the attacker tries to crash the network or restart the system by sending packets to the targeted system [36]. DDoS attacks can be done by a single attacker [36]. These attacks can disable a network [36]. They also can restrict a networks accessibility to a larger network [36]. The attacks target the Physical Layer in the protocol stack or those above the Physical Layer. Some typical Denial of Service (DoS) attacks are BD_ADDR duplication, BlueSmack, BlueChop, L2CAP guaranteed service, battery exhaustion, and Big NAK (Negative Acknowledgement), which is an attack using a continuous retransmission loop [37].
R. Worm Attacks
The attacks occur when a malicious software or Trojan file sends itself to available Bluetooth devices. Examples of these attacks are:
(1)
Cabir Worm: A malicious software that targets Bluetooth technology. Mobile phones that use the Symbian series 60 interface platform are vulnerable to the attacks [8]. For the attacks to be successful, the user must accept the worm [8]. This causes the malware to install on the device [8]. The worms are usually disguised in applications, which results in users unknowingly accepting them [8]. Once installed, the software is the able to use the compromised device to search for and send itself to other available devices [38]. The Mabir worm is a form of the Cabir worm [8]. This worm replicates by using Multimedia Messaging Service messages and Bluetooth [8].
(2)
Skulls Worm: The Skulls Worm, a malicious SIS (Symbian Installation System) trojan file, targets Symbian mobile phones with the Series 60 platform [8]. The worm poses as a Macromedia Flash player [8]. The user must open and install the SIS file for the worm to become active [8]. It then searches for additional devices to infect and the process repeats itself [8,38].
(3)
Lasco Worm: The Lasco worm, is a combination of a Bluetooth worm and SIS file [8]. It targets and infects Symbian mobile phones that support the Series 60 platform [8]. The user must open and install the velasco.sis file [8]. This prompts the activation of the worm [8]. It can then begin searching for additional devices to infect and the process repeats itself [8,38].
S. Bluesmack Attack
The attack is a DoS attack on Bluetooth devices and is similar to the “Ping of Death” attacks that are carried out on IP-based devices, which are networked devices [39]. It is done by sending pings that are approximately 600 bytes, as well as L2CAP echo requests to Bluetooth devices [19]. This results in the input buffer to overflow and the targeted device to be knocked out.
T. MultiBlue Attack
The attack occurs when an attacker has access to the device they wish to hack [40]. The MultiBlue dongle, a bluetooth capable 4 GB thumb, is used to gain access to and take over the targeted device [40]. The attacker then uses the MultiBlue application to see all discoverable devices within range and send pairing requests [40]. The targeted device then presents a code, a pre-shared key, which needs to be entered into the MultiBlue application [40]. This key is needed for authentication and encryption [40]. The attacker then has control of the device [40].
U. HeloMoto Attack
The attack is a mix of the previously mentioned BlueSnarfing and BlueBugging attacks [28]. A vulnerability caused by the erroneous implementation of “trusted devices” on Motorola devices is exploited during the attack [28]. When exploited, the adversary’s device is stored as a trusted device on the target device’s trusted list [28]. After connecting to the OBEX push profile, the attacker tries sending a vcard [28]. The adversary is then able to elude authentication and connect to the target device’s headset profile [41]. BlueBugging is also used to take control of the device [41].
V. Bluecasing/War Nibbling Attack
The attack occurs when a phreaker, a telephone network hacker, uses laptops or PCs with high gain antennas and special software to discover and exploit vulnerabilities in Bluetooth phones to obtain access [35].
The ability to identify and describe these different attacks enable us to better understand the threats surrounding IoT Bluetooth devices. In addition, by classifying the threats, we can determine the severity of the various Bluetooth attacks. Next, we discuss ways to mitigate the risks and identify potential countermeasures used in response to these threats.

6. Bluetooth Risk Mitigation and Countermeasures

The attacks that are described in the previous section discuss Bluetooth flaws that result in vulnerabilities, which can be exploited by an attacker to steal data, send messages, make phone calls, and connect to the Internet using the compromised device [2]. We now discuss risk mitigation techniques and countermeasures.

6.1. Mitigation Techniques

Mitigating Bluetooth vulnerabilities differ significantly from mitigating vulnerabilities in a computer system. While application software patches are used to resolve vulnerabilities in computer systems, Bluetooth devices require upgrades in device firmware [2]. These upgrades cannot be developed by the general public and/or user community [2]. Therefore, Bluetooth devices will continue to be vulnerable to attacks even if mitigation solutions become available [2,29].
While all attacks cannot be prevented, and security is not guaranteed, there are countermeasures that can be used to secure Bluetooth communications [2]. Some of those mitigation techniques are described below:
  • Enhancement of Bluetooth user awareness: it is necessary to educate Bluetooth users to ensure they have knowledge of the proper Bluetooth security practices [2]. These security practices include:
    (1)
    Default settings should be updated to achieve optimal standards [2].
    (2)
    Ensuring devices are in and remain in a secure range. This is done by setting devices to the lowest power level [2].
    (3)
    Using long and random PIN codes, which make the codes less susceptible to brute-force attacks [2].
    (4)
    Changing the default PIN for devices and frequently updating this PIN (i.e., once every other month).
    (5)
    Setting devices to undiscoverable mode by default, except as needed for pairing [2]. Most active discovery tools require that devices be in discoverable mode to be identified. Devices set to undiscoverable mode will not be visible to other Bluetooth devices. Devices previously configured, better known as trusted devices, will be able to connect and communicate while in this hidden mode.
    (6)
    Turning off a device’s Bluetooth when not needed or in use, especially while in certain public areas such as shopping malls, coffee shops, public transportation, clubs, bars, etc [2]. This can prevent users from receiving advertisements from other Bluejackers.
    (7)
    Refraining from entering passkeys or PINs when unexpectedly prompted to do so.
    (8)
    Frequently updating software and drivers to have the most recent product improvements and security fixes.
    (9)
    It is recommended that users refrain from using non-supported or not secure Bluetooth-enabled devices or modules. This includes Bluetooth versions 1.0 and 1.2.
    (10)
    Pairing devices as needed [2]. Users need to maintain that any pairing should take place in a secure non-public setting [2]. This will help prevent attackers from intercepting pairing messages [2]. As previously mentioned, a crucial part of Bluetooth security is pairing, so users should have knowledge regarding eavesdropping [2].
    (11)
    Users should use SSP instead of legacy PIN authentication for the pairing exchange process when it is possible. This will help mitigate PIN cracking attacks.
    (12)
    All lost or stolen Bluetooth devices should be unpaired from devices they had previously been paired with [2]. Unpairing will prevent an attacker from accessing the users other devices through the Bluetooth pairing [2].
    (13)
    Users should never accept transmissions from unknown or suspicious devices [2]. Content should only be accepted from trusted devices [2,8].
    (14)
    All devices that are paired should be removed immediately after use.
    (15)
    Devices should be monitored and kept at close range.
  • Instead of basing link keys on unit keys, they should be based on combination keys [2]. This will prevent Man-in-the-Middle attacks [2].
  • Use link encryption for all data transmissions to prevent any eavesdropping, including passive eavesdropping [2]. Use of the HID boot mode mechanism, a connectionless human interface device, should be avoided, as it sends traffic in plaintext.
  • Users should ensure all links are encryption-enabled when using multi-hop communication [2]. Failure to do so could result in the entire communication chain being compromised [2].
  • Require mutual authentication for network connected devices [2]. This will provide confirmation that the network connections are legitimate [2].
  • Lower the risk of broadcast interceptions by encrypting the broadcasts [2].
  • The maximum encryption key size should be used [2]. In addition, a minimum key size should also be set—128 bits is recommended [2]. The utilization of these minimum and maximum keys will protect devices from brute-force attacks [2].
  • To provide the highest level of security, Security Mode 3 is highly recommended [2]. This mode of security, which is implemented at the link level, is one of the highest levels of Bluetooth security [2].

6.2. Applications for Protecting Bluetooth Devices

(1)
Bluetooth firewall: The Firewall application protects devices, specifically Android devices, from all Bluetooth related attacks [42]. Users are alerted upon any Bluetooth activity [42]. The application also enables you to see Bluetooth capabilities on devices or specific apps [42].
(2)
Bluetooth file transfer: This application only enables authorized devices to be connected [40].

7. Commercial Product Examples

In this section, we discuss a few Bluetooth IoT commercial products and applications. We highlight examples of real-life exploitations, as well as explore how to apply the Bluetooth risk mitigations discussed in the previous section.

7.1. Bluetooth Automotive Hacks

Bluetooth comes standard in most automobiles and supports hands-free calling and music streaming from a user’s smartphone. If the vulnerabilities in the technology are exploited, the driver, passengers, and other individuals on the road may be in danger. Below we describe two different automobile attacks, one using a smartphone and the other using Car Whisperer technology.
A. Automobile Hack Using a Smartphone
Researchers from the University of Washington were able to attack a car’s Bluetooth system; the one which allows a driver to make hands-free cell phone calls [43]. A vulnerability in the system’s implementation was discovered by researchers [43]. During the exploit, a trusted device was used or researchers were able to elude authentication to authorize a new connection [43]. They then called the vehicle and executed a malicious code to take control of the car [43,44]. This enabled the attackers to send commands and override several of the vehicles controls [44]. The target of the attack was a 2009 mass-production sedan [43]. Researchers confirmed that they were able to gain full control of the car’s internal computer systems [43]. This was a result of a vulnerability in the Link Manager Protocol/Link Layer Protocol.
B. Automobile Hack Using Car Whisperer
Car Whisperer software is used to trick automobile Bluetooth systems into connecting with a Linux computer. European wireless security experts, the Trifinite Group, developed the technology in order to demonstrate the limitations of Bluetooth systems [45]. Their specific focus was on the vulnerabilities resulting from the use of standard passkeys [45]. The Car Whisperer software is used to exploit the very short four-digit security key assigned by car manufacturers [45]. It is important to note that the same code is often used for the keys (i.e., 1234 or 0000) [45]. This key grants access to the system [45].
During the hack, continuous device inquiries for visible Bluetooth devices are conducted by running cw_scanner script [45]. The attackers are specifically looking for devices that are not only visible, but share the same device class [45]. Once these devices are identified, carwhisperer binary is executed by the cw_scanner [45]. This connects the device and cw_pin.pl script provides the pass key required for connecting the devices [45]. A control connection is made to the SCO links, synchronous connection-oriented radio links used to connect a slave and a master in a piconet to transmit voice and data [45,46]. Audio can then be sent to or recorded from the targeted device by using the carwhisperer binary [45]. Attackers also have the ability to inject audio into the car and/or eavesdrop [45].
The Trifinite Group was able to conduct an attack using the software [47]. By using a special directional antenna, they were able to extend the Bluetooth connection to about a mile [47]. They then utilized the software to connect to the vehicle’s Bluetooth [48]. Upon connecting, the researchers were able to listen in on and send audio to about ten cars [47]. The attack was conducted over a one-hour period [47].
These attacks exploit vulnerabilities in the Link Manager Protocol/Link Layer Protocol. To prevent the type of attacks discussed above, manufacturers need to build security in to the vehicle’s firmware. In addition, drivers should be sure they are running the latest software updates on their vehicles.

7.2. Bluetooth Medical Hacks

Bluetooth technology has become the preferred communication method used in medical devices [49]. This wireless way of communication along with the device’s corresponding apps are set to change the face of the healthcare industry. Some Bluetooth-enabled devices include blood glucose monitors, oximeters, asthma inhalers, as well as other devices that are used to diagnose injuries, administer medication, and securely transmit information from patients to providers [50]. The vulnerabilities in these devices present new life-threatening security challenges. Possible exploitations of a defibrillator and an insulin pump along with its connected app are illustrated below.
A. Bluetooth Hacks on Defibrillators
According to a recent report in WIRED, security experts who studied at the Midwestern medical facility chain, over the course of two years found critical security vulnerabilities in medical devices [51]. One finding allowed Bluetooth-enabled defibrillators to be manipulated to deliver random shocks to a patient’s heart or prevent a medically needed shock from occurring [51].
Specific product brands and their vulnerabilities were not identified by the researchers; however, they announced that a wide variety of devices shared common security vulnerabilities, resulting in the lack of authentication needed to access or manipulate the equipment [51]. They also identified the use of weak passwords or default and hardcoded passwords such as “admin” or “1234”, which were assigned by the device vendor [51]. These vulnerabilities are in the Link Manager Protocol/Link Layer Protocol. To mitigate these vulnerabilities, the defibrillator’s software and hardware would most likely need to be updated.
B. Bluetooth Hacks on Insulin Pumps and Companion App
Bluetooth technology has given diabetes patients a more efficient and effective way to manage their diabetes by providing them with the ability to easily monitor their blood glucose levels [52]. Glucose monitors can be connected to companion smart apps on smartphones, which not only capture data, but also send alerts to patients [52]. The technology can be hacked by individuals in close range and Man-in-the-Middle and eavesdropping attacks can be executed. During the attacks, data being communicated between the devices could be intercepted, decrypted, and captured [52]. This attack targets vulnerabilities in Bluetooth’s Host Security protocols. To mitigate these vulnerabilities, the software and hardware of the glucose monitor would most likely need to be updated [52].

7.3. Bluetooth Smartwatch/Smart Bracelet Hacks

We are seeing a rapid growth of smartwatches and smart bracelets, including Fitbits and iWatches in the market. These devices use Bluetooth communication channels and mechanisms, which make them vulnerable to Bluetooth attacks.
Below we discuss Bluetooth hacks that were conducted to exploit vulnerabilities on a Samsung Gear Live watch using Bitdefender and a Dax-Hub Sw-28 smart bracelet using GATTacker.
A. Bitdefender Hack on Samsung Gear Live
A proof-of-concept hack was executed by experts at Bitdefender [53]. The attack targeted a Samsung Gear Live smartwatch that was paired with a Google Nexus 4 smartphone [53]. The smartphone was running the very secure, Android L (Preview Version) [53]. The use of sniffing tools enabled researchers to uncover the PIN used to protect the smartwatch and smartphone connection [53]. This showed that an attacker may be able to decode a user’s data, including Google Hangout messages, as well as Facebook conversations [53].
The six digit PIN code that secures Bluetooth communication between most smartwatches and Android devices was exploited during the attack [53]. The attacker can easily perform a brute-force attack on the PIN, as the “key space” is composed of only 1 million possible key combinations [53].
The vulnerability is in the Link Manager Protocol/Link Layer Protocol and can be remediated by the manufacturer by requiring a password for Bluetooth pairing, as well as implementing encryption for the data communication.
B. Man-in-the-Middle Attack on Dax-Hub SW-28 Smart Bracelet
According to WIT (Wessex Institute of Technology) Press, a researcher at Tech Leader, AppSec Labs conducted research with the objective of conducting a Man-in-the-Middle attack on a Bluetooth smart mobile app and smart bracelet [54]. The smart bracelet selected for the attack was a Dax-Hub SW-28 smart bracelet, which is a bracelet that captures information on an individual’s sports activities, as well as other health-related data. All data captured from the bracelet is synced with the PowerSensor app, which is the app designated for the smart bracelet [54].
The attack was carried out by running GATTacker central (ws-slave) on a virtual machine (VM) and running and configuring GATTacker peripheral to the IP address of the ws-slave [54]. A scan was conducted to detect the MAC address of the smart bracelet, which then enabled the researcher to discover advertisements and services that identified with the MAC address [54]. These advertisements and services were utilized to simulate a fake device [54]. The fake device then used GATTacker to advertise the target’s name to get the victim to connect to the fake device [54]. In this case, when the mobile app scanned for devices, the fake advertisement was located, and the app and bracelet were connected through a Man-in-the-Middle attack [54]. If the devices were previously paired, the fake device and mobile app would immediately connect [54]. This is provided that MAC spoofing was used to present the MAC address of the real smart device [54].
Once the app and smart bracelet were connected, the researcher was able to view all the communication data between the two devices [54]. In addition, each time a request was sent from the bracelet to the app, the researcher was able to modify the data [54]. The modification was done by adding a hook to the notification event identifier that was used to execute a code, which would update the data being communicated automatically [54]. GATTacker hooking technology was used to create the hook [54].
In the end, the hack enabled the researcher to modify and exaggerate the distance walked on a treadmill [54]. In addition, because the target smart bracelet had mobile camera and music capabilities, the researcher was able to exploit these capabilities as well by using BtleJuice’s replay attack [54]. By replaying previous requests between the bracelet and mobile app, the attacker was able to use his computer to take pictures and play music on the victim’s mobile device [54].
This type of hack exploits vulnerabilities in the Link Manager Protocol/Link Layer Protocol. It is preventable by implementing updated and additional security controls [54]. These controls include data encryption and signature, as well as a strong authorization and authentication processes [54].

7.4. Bluetooth Smartphone Hacks

According to Pew Research Center’s survey in 2011, 77% of Americans own a smartphone [55]. Most of these devices are Bluetooth-enabled, which makes them vulnerable to attacks. Below we discuss Bluetooth hacks that can target smartphones.
Researchers conducted an experiment with the goal of learning how many devices they could infect with viruses in a public place using Bluetooth.
For the experiment, the researchers visited public places with a suitcase consisting of a computer that was equip with a Bluetooth sniffing program [56]. While 10 m is the average range a mobile phone can communicate via Bluetooth, an antenna can be used to increase the attack range [56]. During the experiment, the researchers were able to detect more than 1400 devices in less than 23 h [56].
In a similar experiment, researchers attacked Bluetooth-enabled devices and obtained over 300 address books [56]. This attack was conducted from the 11th floor of a Las Vegas hotel on targets that were on the ground in a taxi stand [56]. It is important to note that similar attacks can be carried out on tablets that are Bluetooth-enabled.
These attacks exploit vulnerabilities in the Link Manager Protocol/Link Layer Protocol. To mitigate these types of attacks, users should disable their Bluetooth when it is not in use.

7.5. Bluetooth Smarthome Hacks

According to CNBC and HIS Markit, in 2016 there were 80 million smarthome devices delivered around the world [57]. This was a significant increase, 64%, from 2015 [57]. Many of these devices are Bluetooth-enabled, which makes them vulnerable to attacks. Below we discuss exploited vulnerabilities in Nest and Dropcam cameras, smartlocks, speakers, personal assistants, as well as in an interconnected smarthome.
A. Bluetooth Camera Hack
In 2017, a mobile security and IoT hacker, Jason Doyle, identified three different vulnerabilities in Nest Cam Indoor, Nest Cam Outdoor, Dropcam Pro, and Dropcam security cameras that caused the camera’s feed to cut out [58]. Each of the vulnerabilities were found in a specific firmware, which was version 5.2.1 [58].
The first two vulnerabilities involve sending parameters to the camera via Bluetooth [58]. They consist of either Wi-Fi password parameters or Wi-Fi SSID parameters, also known as service set identifier parameters [58]. SSID is a 32 character ID used for wireless networks. When these vulnerabilities are exploited, they cause a buffer overflow and result in the camera crashing and rebooting [59]. The third vulnerability that was found enables a camera to be completely disconnected [58]. This vulnerability is exploited by using Bluetooth to send new, non-existent Wi-Fi SSID parameters [58].
These L2CAP vulnerabilities were exploited by attackers within Bluetooth range of the cameras. Alphabet, Nest’s parent company, noted it was working on a fix to mitigate the vulnerabilities [58]. Users should make sure they are updating their devices and running the latest updates to mitigate these types of vulnerabilities.
B. Smarthome Hack to Gain Physical Access
Yossi Atias, the General Manager of IoT Security at BullGuard demonstrated how vulnerable some smarthome devices are to cyberattacks, which are intentional attacks to exploit computer systems, networks, and/or enterprises that are technology dependent [60,61]. In his demonstration, he constructed a fictional, secure smarthome that consisted of devices normally found in today’s homes, including a smart alarm, IP camera, smart lock, and Amazon Echo [60]. He then conducted a live hack on these IoT connected devices [60]. His ability to exploit the smarthome devices enabled him to gain physical entry into the fictional smarthome [60].
One way to prevent these attacks on smarthome devices is for manufacturers to build security in from the device’s hardware up [60].
C. Bluetooth Hacks on Personal Assistants
BlueBorne attacks, which exploit vulnerabilities in the L2CAP, were conducted on the Amazon Echo and Google Home to demonstrate the vulnerabilities on these smarthome Bluetooth devices [62]. The Amazon Echo had a remote code execution vulnerability in the Linux Kernal and information disclosure flaw in the SDP server [62]. The specific vulnerability was dependent on the variant’s operating system [62]. The vulnerability discovered in Google Home was in Android’s Bluetooth stack and was identified as an information disclosure vulnerability [62]. If exposed, the Google Home vulnerability can cause DoS [62].
It is important to note that Bluetooth cannot be disabled on these devices which, before the patches and automatic updates, left them vulnerable to these attacks [62]. The type of attacks illustrated above could be performed by any attacker who is in range of the personal assistant devices [62]. Users should always ensure they are running the most recent update on these devices [62]. Amazon and Google released patches for these vulnerabilities [62].
D. Bluetooth Smartlock Hacks
According to Tom’s Guide, researchers Anthony Rose and Ben Ramsey tested 16 Bluetooth smart locks [63]. Of the 16 locks, they were able to wirelessly hack and open 12 of them [63]. They noted that the locks used BLE; however, the issues were not specifically with the BLE protocol [63]. The vulnerabilities were due to the way manufacturers implemented the lock’s Bluetooth data communication with the corresponding smartphone app [63].
The researchers found that there were several different types of vulnerabilities that could be exploited on the smartlocks. These vulnerabilities were in the Link Manager Protocol/Link Layer Protocol. In some cases, passwords were sent in plaintext giving anyone with Bluetooth sniffing capabilities the ability to capture the passwords [63]. In other cases, passwords were sent twice giving attackers the ability to change the intercepted passwords and lock out the legitimate user [63]. The researchers also found that some lock manufacturers encrypt the passwords during the Bluetooth transmission; however, the locks could be unlocked with passwords that were still encrypted [63]. They did not need to decrypt the passwords to open the lock [63]. They were also able to stage Man-in-the-Middle attacks between the lock and the connected app or put the lock into an error state which opened the lock by changing a byte in a proprietary encryption [63].
The researchers noted that the locks they were not able to hack used two-factor authentication, encryption, and did not have hardcoded passwords in the software [63]. These security measures can be implemented to prevent smarthome locks from being hacked.
E. Bluetooth Speaker Hacks
Bluetooth speakers are becoming increasingly popular. According to Smart Industry, Bluetooth speakers that connect to wireless networks can be exploited to gain unauthorized access to a network [64].
Vulnerabilities can be found in the Link Manager Protocol/Link Layer Protocol. Risk can be mitigated by either turning the Bluetooth off while the speaker is not in use or by the manufacturer updating the hardware.

7.6. Bluetooth Hacks on Children’s Toys

Children’s connected toys are on the rise. Some of these toys contain cameras, speakers, GPS capabilities, microphones, and data storage among many other things. The influx of these Wi-Fi and Bluetooth-connected toys coming to the market pose serious threats, specifically to children’s safety. Below we discuss how vulnerabilities were exploited on a teddy bear along with other connected children’s toys.
A. Bluetooth Hack on a Teddy Bear
An 11-year-old boy, Reuben Paul, attended a cybersecurity conference at the World Forum in The Hague and performed a live hack exploiting vulnerabilities in his cloud-connected teddy bear [65]. Vulnerabilities in the Link Manager Protocol/Link Layer Protocol enabled the attack.
The exploit was performed by connecting the bear to Wi-Fi and Bluetooth, which enables the bear to transmit and receive messages [65]. Reuben used a Raspberry Pi that was connected to his computer to scan for Bluetooth-connected devices [65]. Through the scan, he was able to download many device numbers, some of which belonged to devices of important executives attending the conference [65]. By utilizing one of the numbers and the Python programming language, Paul was able to turn on the bear, turn on the bear’s lights, and even record a message from the audience [65].
Building security into the hardware of these toys and the issuing of patches could mitigate these types of Bluetooth vulnerabilities and exploits.
B. Additional Hacks on Children’s Toys
In addition to the teddy bear discussed above, there have been additional children’s connected toys identified that have Link Manager Protocol/Link Layer Protocol vulnerabilities. According to the Guardian, these toys include Furby Connect, i-Que Intelligent Robot, Toy-Fi Teddy, and CloudPets. Researchers determined that no passwords, pins, or any other authentication was needed to gain access to the toys [66]. The researchers reported the following findings: Furby Connect was able to connect with any device in Bluetooth range [66]. The app for i-Que Intelligent Robot was able to be downloaded by anyone [66]. This gave individuals the ability to find the i-Que when in Bluetooth range and connect with the robot’s voice via text field [66]. Toy-Fi Teddy’s lack of authentication enabled hackers to not only send messages, but receive voice messages from children [66]. Cloud pets, which allow messages to be sent to children from friends was also able to be hacked because the Bluetooth connection was unsecure [66].
Building security into the hardware of these toys could prevent these types of Bluetooth exploits.

7.7. Issues with Vulnerabilities in Commercial Products

Bluetooth devices are not easily upgradable, specifically the hands-free systems used in vehicles. Therefore, devices with older versions of Bluetooth are left vulnerable to attacks.
It is also worth mentioning, that while security experts advocate that one should turn off Bluetooth when not in use, some companies’ processes (e.g., Apple) are contradictory to this. Updates pushed out to Apple devices result in Bluetooth being turned on by default. The devices affected by the updates include iPods, iPhones, and iPads. With the number of Apple device users, Apple could possibly and unnecessarily be exposing its customers to Bluetooth attackers.

8. Recommendations to Secure Bluetooth Communications

While not all attacks can be prevented, it is important to take the necessary steps to secure Bluetooth communications.
A. Recommendations for Users
Users should educate themselves on Bluetooth technology and proper security practices. Before purchasing IoT devices, users should do their due diligence on the device’s security features and capabilities. Device owners should frequently visit the device manufacturer’s website to be cognizant of firmware updates or patches that have been issued [67].
B. Recommendations for Manufacturers and Product Engineers
Engineers should identify security principles and apply them throughout the development of a product [67]. Developing threat models and applying knowledge learned from previous attacks could help prevent repeat attacks, as well as new foreseeable threats [67]. They should be aware of present vulnerabilities and update firmware and issue patches as necessary. Manufacturers should be sure to inform users of these updates via their website or email for registered users. They should also ensure devices have the most recent version of Bluetooth. Finally, they should develop documentation for users to help increase their awareness on how to secure their devices.

9. Conclusions

Bluetooth has gained acceptance worldwide and has become a common feature in our everyday wireless devices. The technology has been available for about 15 years and has become the go-to, as well as a convenient, solution for connecting devices, including phones, cameras, televisions, speakers, headphones, smartwatches, medical devices, as well as personal assistants. The ability to utilize the technology’s capabilities for voice and data transmission over short distances has contributed to its popularity.
In this article, we reviewed Bluetooth security including security services and features. We then discussed vulnerabilities in various versions of Bluetooth, as well as numerous Bluetooth threats, which are largely due to the process of pairing. We also examined Bluetooth risk mitigation and countermeasures. Finally, we presented real-life exploitations and risk mitigations of Bluetooth commercial products, as well as provided recommendations on how to secure Bluetooth communications.
There are currently a wide variety of security vulnerabilities that are affecting Bluetooth technology, as well as Bluetooth-connected devices. For this reason, it is important for users to understand the risks involved with using Bluetooth technology on their devices, as well as the mitigation techniques that can be used to protect their devices and information from attackers. Implementing the recommended security measures above will help to mitigate any Bluetooth related risks. Every individual should be responsible for securing their Bluetooth communications, as there is not one trusted, central party taking the necessary action.
Future work should consider extending the above analysis to other wireless technology standards such as Wi-Fi and ZigBee. Also, future research could potentially focus on power attacks on BLE, as it is targeted for low-energy applications.

Funding

This research was funded by Fordham University, Faculty Research Program.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Bisikian, C. An overview of the Bluetooth wireless technology. IEEE Commun. Mag. 2001, 39, 86–94. [Google Scholar] [CrossRef][Green Version]
  2. Cope, P.; Campbell, J.; Hayajneh, T. An Investigation of Bluetooth Security Vulnerabilities. In Proceedings of the 7th IEEE Annual Computing and Communication Workshop and Conference (IEEE CCWC 2017), Las Vegas, NV, USA, 9–11 January 2017. [Google Scholar]
  3. National Institute of Standards and Technology. Guide to Bluetooth Security: Recommendations of the National Institute of Standards and Technology; Special Publication 800-121 Revision 1; National Institute of Standards and Technology: Maryland, MD, USA, 2008.
  4. NIST Special Publication 800-121 Revision 2: Guide to Bluetooth Security. Available online: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-121r2.pdf (accessed on 6 June 2018).
  5. Gerez, S. Implementation of Digital Signal Processing: Some Background on GFSK Modulation. Available online: http://wwwhome.ewi.utwente.nl/~gerezsh/sendfile/sendfile.php/gfsk-intro.pdf?sendfile=gfsk-intro.pdf (accessed on 14 July 2018).
  6. Bluetooth 5 FAQ: Everything You Need to Know. Available online: https://www.macworld.com/article/3262664/hardware/bluetooth-5-faq-everything-you-need-to-know.html (accessed on 6 June 2018).
  7. Harris, A., III; Khanna, V.; Tuncay, G.; Want, R.; Kravets, R. Bluetooth low energy in dense IoT environments. IEEE Commun. Mag. 2016, 54, 30–36. [Google Scholar] [CrossRef]
  8. Nateq Be-Nazir Ibn, M.; Tarique, M. Bluetooth security threats and solutions: A survey. Int. J. Distrib. Parallel Syst. 2012, 3, 127. [Google Scholar]
  9. Panse, T.; Panse, P. A Survey on Security Threats and Vulnerability attacks on Bluetooth Communication. Int. J. Comput. Sci. Inf. Technol. 2013, 4, 741–746. [Google Scholar]
  10. Hassan, S.S.; Bibon, S.D.; Hossain, M.S.; Atiquzzzaman, M. Security Threats in Bluetooth Technology. Comput. Secur. 2017, 74, 308–322. [Google Scholar] [CrossRef]
  11. Darroudi, S.M.; Gomez, C. Bluetooth low energy mesh networks: A survey. Sensors 2017, 17, 1467. [Google Scholar] [CrossRef] [PubMed]
  12. Zou, Y.; Wang, X.; Hanzo, L. A survey on wireless security: Technical challenges, recent advances and future trends. arXiv, 2015; arXiv:1505.07919. [Google Scholar]
  13. Hayajneh, T.; Almashaqbeh, G.; Ullah, S.; Vasilakos, A.V. A survey of wireless technologies coexistence in WBAN: Analysis and open research issues. Wirel. Netw. 2014, 20, 2165–2199. [Google Scholar] [CrossRef]
  14. Sairam, K.; Gunasekaran, N.; Reddy, S.R. Bluetooth in wireless communication. IEEE Commun. Mag. 2002, 40, 90–96. [Google Scholar] [CrossRef]
  15. Jordan, R.; Abdallah, C.T. Wireless communications and networking: An overview. IEEE Antennas Propag. Mag. 2002, 44, 185–193. [Google Scholar] [CrossRef]
  16. Ferro, E.; Potorti, F. Bluetooth and Wi-Fi wireless protocols: A survey and a comparison. IEEE Wirel. Commun. 2005, 12, 12–26. [Google Scholar] [CrossRef]
  17. Bluetooth Versions Walkthrough and Bluetooth 4.0 Low Energy Development Resources. Available online: https://www.cnx-software.com/2013/06/05/bluetooth-versions-walkthrough-and-bluetooth-4-0-low-e (accessed on 6 June 2018).
  18. Shrivastava, M. Analysis of security risks in Bluetooth. Int. J. Comput. Acad. Res. 2012, 1, 88–95. [Google Scholar]
  19. National Institute of Standards and Technology. Guide to Bluetooth Security; NIST 800-121-Rev 1; NIST: Gaithersburg, MD, USA, 2016.
  20. Mitchell, A. The Car Whisperer: Eavesdrop Onand Take Part in Nearby Bluetooth Conversations. 2005. Available online: https://www.theinternetpatrol.com/the-car-whisperer-eavesdrop-on-and-take-part-in-nearby-bluetooth-conversations/ (accessed on 1 May 2016).
  21. Dunning, J.P. Bluetooth Threat Taxonomy. Available online: https://vtechworks.lib.vt.edu/bitstream/handle/10919/76883/etd-10242010-163002_Dunning_JP_T_2010.pdf?sequence =1&isAllowed=y) (accessed on 13 April 2018).
  22. Bluetooth Security. Available online: https://cs.stanford.edu/people/eroberts/courses/soco/projects/2003-04/wireless-computing/sec_bluetooth.shtml (accessed on 6 June 2018).
  23. Sen, J. Security and Privacy Challenges in Cognitive Wireless Sensor Networks. In Cognitive Radio Technology Applications for Wireless and Mobile Ad hoc Networks; Meghanathan, N., Reddy, Y.B., Eds.; IGI-Global: Hershey, PA, USA, 2013. [Google Scholar]
  24. Shaked, Y.; Wool, A. Cracking Bluetooth PIN. Available online: http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/ (accessed on 6 June 2018).
  25. Saravanan, K.; Vijayanand, L.; Negesh, R.K. A Novel Bluetooth Man-In-The-Middle Attack Based on SSP using OOB Association model. arXiv, 2012; arXiv:1203.4649. [Google Scholar]
  26. Moreno, A.; Okamoto, E. BlueSnarf Revisted: OBEX FTP Service Directory Traversal. Available online: https://link.springer.com/content/pdf/10.1007%2F978-3-642-23041-7_16.pdf (accessed on 6 June 2018).
  27. Ahmed, M.; Musleh, A.; Marouf, A.; Mahmoud, A.; Abu-Amara, M. Bluetooth Security. Available online: https://www.slideshare.net/ram_ari/bluetooth-security (accessed on 7 June 2018).
  28. Becker, A. Bluetooth Security & Hacks; Seminar ITS Ruhr-Universitat Bochum SS2007; Ruhr University of Bochum: Bochum, Germany, 2007; Available online: https://gsyc.urjc.es/~anto/ubicuos2/bluetooth_security_and_hacks.pdf (accessed on 11 April 2018).
  29. Carettoni, L.; Merloni, C.; Zanero, S. Studying bluetooth malware propagation: The BlueBag project. IEEE Secur. Priv. 2007, 5, 17–25. [Google Scholar] [CrossRef]
  30. Trifinite: BlueBump. Available online: https://trifinite.org/trifinite_stuff_bluebump.html (accessed on 6 June 2018).
  31. BlueDump. Available online: https://trifinite.org/trifinite_stuff_bluedump.html (accessed on 6 June 2018).
  32. Trifinite: BluePrinting. Available online: https://trifinite.org/trifinite_stuff_blueprinting.html (accessed on 6 June 2018).
  33. Red Hat CVE-2017-1000251. Available online: https://access.redhat.com/security/cve/cve-2017-1000251 (accessed on 6 June 2018).
  34. The Attack Vector “BlueBorne” Exposes Almost Every Connected Device. Available online: https://www.armis.com/blueborne/ (accessed on 6 June 2018).
  35. Tsira, V.; Nandi, G. Bluetooth technology: Security issues and its prevention. Int. J. Comput. Appl. Technol. 2014, 5, 1833–1837. [Google Scholar]
  36. Nawir, M.; Amir, A.; Yaakob, N.; Lynn, O. Internet of Things (IoT): Taxonomy of Security Attacks. In Proceedings of the 2016 3rd International Conference on Electronic Design (ICED), Phuket, Thailand, 11–12 August 2016. [Google Scholar]
  37. Haataja, K. Security Threats and Countermeasures in Bluetooth-Enabled Systems. Kuopio University Publications H. Business and Information Technology 13. 2009. Page 75. Available online: http://epublications.uef.fi/pub/urn_isbn_978-951-27-0111-7/urn_isbn_978-951-27-0111-7.pdf (accessed on 14 July 2018).
  38. Chatterjee, A.; Arora, A.; Pandey, A.; Thakkar, H. Analysis and elicitation of Bluetooth versions and Bluetooth attacks. Int. J. Mod. Comput. Sci. 2017, 5, 3–17. [Google Scholar]
  39. Trifinite: BluePrinting. Available online: https://trifinite.org/trifinite_stuff_bluesmack.html (accessed on 7 June 2018).
  40. Using MultiBlue to Control Any Mobile Device. Available online: https://null-byte.wonderhowto.com/how-to/hack-bluetooth-part-2-using-multiblue-control-any-mobile-device-0164377/ (accessed on 6 June 2018).
  41. Trifinite Group. Available online: https://trifinite.org/trifinite_stuff_helomoto.html (accessed on 1 April 2018).
  42. Pandey, T.; Khara, P. Bluetooth Hacking and its Prevention. L & T Technology Services. Available online: http://www.larsentoubro.com/media/27618/bluetooth-hacking-and-its-prevention-2014.pdf (accessed on 1 April 2016).
  43. Naone, E. Taking Control of Cars from Afar. 14 March 2011. Available online: https://www.technologyreview.com/s/ 423292/taking-control-of-cars-from-afar/ (accessed on 11 April 2016).
  44. Markoff, J. Researchers Show How a Car’s Electronics Can Be Taken over Remotely. Available online: https://www.nytimes.com/2011/03/10/business/10hack.html (accessed on 7 June 2018).
  45. Trifinite: BluePrinting. Available online: https://trifinite.org/trifinite_stuff_carwhisperer.html (accessed on 7 June 2018).
  46. IGI Global: Disseminator of Knowledge. Available online: https://www.igi-global.com/dictionary/synchronous-connection-oriented-sco-link/28975 (accessed on 14 July 2018).
  47. Car Whisperer’ Puts Hackers in the Drivers Seat. Available online: https://www.pcworld.com/article/122077/article.html (accessed on 7 June 2018).
  48. Wright, J. I Can Hear You Now. Available online: http://www.willhackforsushi.com/presentations/icanhearyounow-sansns2007.pdf (accessed on 7 June 2018).
  49. Orthogonal. Available online: http://orthogonal.io/articles/developing-bluetooth-enabled-medical-devices/ (accessed on 11 April 2018).
  50. Bluetooth. Available online: https://www.bluetooth.com /markets/connected-device (accessed on 13 April 2018).
  51. Zetter, K. It’s Insanely Easy to Hack Hospital Equipment. 25 April 2014. Available online: https://www.wired.com/2014/ 04/hospital-equipment-vulnerable/ (accessed on 10 April 2016).
  52. Kijewski, M. The Medical Devices Most Vulnerable to Hackers. Available online: https://www.medtechintelligence.com/feature_article/medical-devices-vulnerable-hackers/ (accessed on 10 April 2018).
  53. Paganini, P. Smartwatch Hacked, How to Access Data Exchanged with Smartphone. 11 December 2014. Available online: http://securityaffairs.co/wordpress/31007/intelligence/smartwatch-hacked.html (accessed on 5 April 2016).
  54. Melamed, T. An Active Man-in-the-Middle Attack on Bluetooth Smart Devices. Int. J. Saf. Secur. Eng. 2018, 8, 200–211. [Google Scholar] [CrossRef]
  55. Mobile Fact Sheet. Available online: http://www.pewinternet.org/fact-sheet/mobile/ (accessed on 13 April 2018).
  56. Loo, A. Security threats of smart phones and Bluetooth. Commun. ACM 2009, 52, 150–152. [Google Scholar] [CrossRef]
  57. Olick, D. Why 2017 Will Finally be the Year of the Smart Home: Consumers Figure it Out. Available online: https://www.cnbc.com/2017/01/04/why-2017-will-finally-be-the-year-of-the-smart-home-consumers-figure-it-out.html (accessed on 13 April 2018).
  58. Estes, A.C. This Nest Security Flaw is Remarkably Dumb. Available online: https://gizmodo.com/this-nest-security-flaw-is-remarkably-dumb-1793524264 (accessed on 13 April 2018).
  59. Google-Nest-Cam-Bug-Disclosures. Available online: https://github.com/jasondoyle/Google-Nest-Cam-Bug-Disclosures/blob/master/README.md (accessed on 7 June 2018).
  60. Kite-Powell, J. This Company Staged a Hack with Multiple Devices to Show Your Home’s Vulnerability. Available online: https://www.forbes.com/sites/jenniferhicks/2017/09/19/this-company-staged-a-hack-with-multiple-devices-to-show-your-homes-vulnerablity/#654ac4565322 (accessed on 13 April 2018).
  61. Techopedia. Available online: https://www.techopedia.com/definition/24748/cyberattack (accessed on 13 April 2018).
  62. Khandelwal, A. Bluetooth Hack Affects 20 Million Amazon Echo and Google Home Devices. Available online: https://thehackernews.com/2017/11/amazon-alexa-hacking-bluetooth.html (accessed on 13 April 2018).
  63. Wagenseil, P. 75 Percent of Bluetooth Smart Locks Can Be Hacked. Available online: https://www.tomsguide.com/us/bluetooth-lock-hacks-defcon2016,news-23129.html (accessed on 13 April 2018).
  64. Dibrov, Y. IoT Devices Compromising Your Business Today. Available online: https://www.smartindustry.com/blog/smart-industry-connect/six-iot-devices-compromising-your-business-today/ (accessed on 13 April 2018).
  65. Samuels, M. With Teddy Bear Bluetooth Hack, 11-Year-Old Proves IoT Security is No Child’s Play. Available online: https://securityintelligence.com/news/with-teddy-bear-bluetooth-hack-11-year-old-proves-iot-security-is-no-childs-play/ (accessed on 13 April 2018).
  66. Smithers, R. Strangers Can Talk to Your Child through Connected Toys, Investigation Finds. Available online: https://www.theguardian.com/technology/2017/nov/14/retailers-urged-to-withdraw-toys-that-allow-hackers-to-talk-to-children (accessed on 13 April 2018).
  67. Rakic-Skokovic, M. Guidelines for Overcoming some IoT Security Issues. In Proceedings of the XVII International Scientific Conference on Industrial Systems (IS’17), Novi Sad, Serbia, 4–6 October 2017. [Google Scholar]
Figure 1. Bluetooth Piconet.
Figure 1. Bluetooth Piconet.
Jsan 07 00028 g001
Figure 2. Bluetooth Protocol Stack (Bluetooth 1, 2, and 3).
Figure 2. Bluetooth Protocol Stack (Bluetooth 1, 2, and 3).
Jsan 07 00028 g002
Figure 3. Bluetooth Protocol Stack (Bluetooth 4).
Figure 3. Bluetooth Protocol Stack (Bluetooth 4).
Jsan 07 00028 g003
Figure 4. Link-Key Generation with PIN.
Figure 4. Link-Key Generation with PIN.
Jsan 07 00028 g004
Figure 5. Link-Key Establishment for SSP.
Figure 5. Link-Key Establishment for SSP.
Jsan 07 00028 g005
Figure 6. Bluetooth Threat Taxonomy.
Figure 6. Bluetooth Threat Taxonomy.
Jsan 07 00028 g006
Figure 7. MAC Spoofing Attack.
Figure 7. MAC Spoofing Attack.
Jsan 07 00028 g007
Figure 8. PIN Cracking Attack.
Figure 8. PIN Cracking Attack.
Jsan 07 00028 g008
Figure 9. Man-in-the-Middle Attack.
Figure 9. Man-in-the-Middle Attack.
Jsan 07 00028 g009
Figure 10. BlueSnarfing Attack.
Figure 10. BlueSnarfing Attack.
Jsan 07 00028 g010

© 2018 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
J. Sens. Actuator Netw. EISSN 2224-2708 Published by MDPI AG, Basel, Switzerland RSS E-Mail Table of Contents Alert
Back to Top