Bluetooth Security

Bluetooth technology can be found in most smart devices today. Bluetooth can be used anywhere from cars to wireless mice to pass information between two or more devices. Since many Bluetooth connections are insecure, open and allow foreign devices to send and receive data or instructions from the local device, security is a large concern. Sensitive information, including financial, medical and phone calls, is commonly transmitted using Bluetooth, making the security of that communication vital. Bluetooth has security flaws which allow adversaries to read information being transmitted, trick devices into connecting to malicious devices and modify information sent between devices. This thesis will be overviewing the primary concerns with Bluetooth devices and current vulnerabilities, along with security recommendations.

ii ABSTRACT Bluetooth technology can be found in most smart devices today. Bluetooth can be used anywhere from cars to wireless mice to pass information between two or more devices. Since many Bluetooth connections are insecure, open and allow foreign devices to send and receive data or instructions from the local device, security is a large concern. Sensitive information, including financial, medical and phone calls, is commonly transmitted using Bluetooth, making the security of that communication vital. Bluetooth has security flaws which allow adversaries to read information being transmitted, trick devices into connecting to malicious devices and modify information sent between devices. This thesis will be overviewing the primary concerns with Bluetooth devices and current vulnerabilities, along with security recommendations. iii TABLE OF CONTENTS ABSTRACT ii INTRODUCTION 1 1 BLUETOOTH STRUCTURE 1 1.1 Overview 1 1.2 Hopping 2 2 SECURITY 3 2.1 Security Goals 3 2.2 Configuration 3 3 PAIRING 4 3.1 Keys 5 3.2 Pairing Procedures 7 3.3 Pairing Attacks 8 4 BLUETOOTH VERSIONS 10 5 EAVESDROPPING 11 5.1 Active Eavesdropping (Man in the Middle Attack) 12 5.2 Passive Eavesdropping (Offline Dictionary Attack) 13 6 ENCRYPTION 14 7 SNIFFING 15 CONCLUSION 16 WORKS CITED 18 INTRODUCTION Bluetooth technology can be found in most smart devices today. Bluetooth is a technique for devices to communicate in a short range. This may be the connection between a phone and a car or smart watch; or the connection from a device to wireless headphones, a mouse or keyboard. Bluetooth is designed to be simple and fast to use, making it more vulnerable than other technologies. Bluetooth connections are made through a pairing process. In this process, a secret key is created that can be used to hide data sent between devices. Several vulnerabilities allow attackers to gain this key. Additionally, adversaries may also be able to reset pairings between Bluetooth devices, allowing them to connect their own malicious device without detection. Since many Bluetooth connections are insecure, open and allow foreign devices to send and receive data or instructions from the local device, security is a large concern. With Bluetooth devices in charge of sending sensitive data, such as passwords, phone calls or even medical data, security in Bluetooth is becoming increasingly important. This paper will review the structure of Bluetooth involving how connections are made and maintained, security considerations and vulnerabilities. 1 - Bluetooth Structure 1.1 - Overview Bluetooth is used for shorter range communication and is designed “to operate in noisy frequency environments” (Choi 236). Bluetooth use the “unlicensed ISM … frequency band at 2.4GHz, and avoid interference from other signals by hopping to a new 2 frequency after transmitting or receiving a packet” (Choi 236). The 2.4GHz frequency band also contains “protocols like ZigBee and WiFi” (Jimblom). The “[s]ignals are frequency hopped over the 79 channels at a rate of 1600 hops per second” (Choi 237). Bluetooth networks are known as piconets and are constructed with a masterslave structure. The device with “the least computation and power constraints is usually selected as the master to manage communication” (Albazrqaoe 73). The master is the “device that initiates a connection” (Haataja 1). The MAC address of the master device is used as the “piconet address” (Albazrqaoe 73). The master device generates a clock signal, known as the piconet clock, with which all devices of the piconet are synchronized (Albazrqaoe 73). Each piconet has a “maximum of seven active slave devices and one master device” with all “communication within a piconet go[ing] through the piconet master” (Haataja 1). Each Bluetooth device has a “48-bit BD_ADDR [(Bluetooth Device Address) which] is unique and refers globally to only one individual Bluetooth device” (Haataja 2). This address contains “an organization unique identifier (OUI) which identifies the manufacturer” in addition to a manufacturer-unique portion (Jimblom). The BD_ADDR is used “for identity, authentication, and low-level communication” (Filizzola 2). 1.2 - Hopping The hopping protocol for Bluetooth Classic is “defined by a physical channel, which is characterized by pseudo-random hopping over 79 subchannels from 2.4 to 2.48 GHz” (Albazrqaoe 73). The frequency is “switched every 625 µs, [with] a maximum hopping rate of 1600 [hops per second]” (Albazrqaoe 73). There are two types of physical channels used for communication. A basic channel, where a “subchannel index 3 is calculated by H(A, c), where H(.) denotes the basic hop selection kernel specified, … A is the piconet address, and c is the piconet clock” (Albazrqaoe 73). Another channel type is the adapted channel. This is used when other wireless devices may share the frequency. Adaptive hopping occurs “where the basic channel is frequently modified to adapt spectrum use” (Albazrqaoe 73). For adaptive hopping a “remap function is called to compute a pseudo-random index i based on the piconet address and clock” (Albazrqaoe 73). When Bluetooth devices are paired, they use the piconet address, piconet clock and subchannel map to determine hopping behavior (Albazrqaoe 73). 2 - Security 2.1 - Security Goals The Bluetooth standard specifies five goals for security: authentication, confidentiality, authorization, message integrity and pairing (Filizzola 2). Authorization involves knowing other devices’ identities, which is done with a “unique Bluetooth address” (Filizzola 2). Confidentiality is protecting information from being read by anyone that is not the intended recipient. Authorization is “allow[ing] the control of resources by ensuring that a device is authorized to use a service first” (Filizzola 2). Preventing information from being changed in transit is message integrity. Finally, pairing devices involves creating shared secret keys for future communication (Filizzola 2). 2.2 - Configuration Bluetooth device security can be configured by users, allowing different connection and discovery options. There are three security levels: silent, private and 4 public (Haataja 2). When a device is silent, it “will never accept any connection” and only “monitors Bluetooth traffic” (Haataja 2). On private, the “device cannot be discovered” and connections are accepted “only if the BD_ADDR … of the device is known to the prospective master” (Haataja 2). A public device can be “discovered and connected to” (Haataja). Private devices are known as non-discoverable and public devices are known as discoverable. A Bluetooth device is set to indiscoverable mode to “hide key technical parameters,” such as those above used for hopping behavior, “from unpaired devices” (Albazrqaoe 73). By default, Bluetooth is “set as discoverable and nonsecure, meaning that an attacker can discover the BD_ADDR of it and perform various attacks” (Filizzola 4). Devices should be configured with the appropriate security level for their use. 3 - Pairing The pairing process between two Bluetooth devices is crucial to ensuring a secure authorized connection. Pairing is the primary source of concern for Bluetooth security. The pairing procedure involves the calculation of link keys and authorization of both devices. Figure 1 shows the basic message exchange between a master and slave device pairing. Random 128-bit values IN_RAND, LK_RANDs and AU_RANDs are generated by the sending side independently for each process run. Note that two keys are generated using this procedure: the initialization key (Kinit) and the link key (KAB). A description of how these keys are generated can be found in the next section, 3.1 “Keys”. After the keys are generated, each side is authenticated. 5 Figure 1: Bluetooth Pairing Process This authentication is done with a challenge-response. A “128-bit pseudorandom number AU_RAND is exchanged via air in unencrypted form” and the recipient “returns a 32-bit result (SRES, Signed Response)” (Haataja 3). The initializer is able to verify the SRES value is as expected, and if verified, both devices can calculate the same “96-bit result (ACO, Authenticated Ciphering Offset)” (Haataja 3). SRES can only be calculated if the link key is known, as shown in Figure 1’s calculation. Once two devices are paired, they can skip the key creation steps and begin a connection at the authentication stage. 3.1 - Keys Connecting Bluetooth devices involves several steps. First and second, the initialization and link keys are created. Then the devices are authenticated. Optionally, an encryption key can be created (Shaked 40). 6 Several keys are generated by Bluetooth devices for secure communication and pairing. When meeting for the first time, Bluetooth devices generate an initialization key used for “securing the generation of other more secure 128-bit keys” (Haataja 2). This initialization key is created using a “128-bit pseudorandom IN_RAND, an L-byte (1<L<16) PIN code, and a BD_ADDR” (Haataja 2). This key is used to establish a link key, which is the “common shared secret” that all “mutually trusted devices … share” (Gehrmann 2). Link keys can be either unit or combination keys. Unit keys are computed by individual Bluetooth devices. These should only be used by devices with “limited resources … because it provides only a low level of security” (Haataja 3). Two devices can create a combination key by a bitwise XOR between their two unit keys. The devices compute their unit keys and using the BD_ADDR of the other device in combination with exchanged pseudorandom numbers they can compute the other device’s unit key (Haataja 3). A single unit “uses the same unit key for all its connections” (Gehrmann 2). Unit keys are less secure than combination keys since the device must “share this key with all other units that it trusts” (Gehrmann 4). Meaning, “all trusted devices are able to eavesdrop on any traffic based on this key” (Gehrmann 4). This makes it easy for trusted devices to impersonate a device as well. Alternatively, it is recommended to use combination keys which are more secure. The other type of link key is a combination key. This key is “unique to a particular pair of devices” (Gehrmann). It is “only used to protect the communication between these two devices” (Gehrmann). This type of key is much more secure than a unit key, and is only useful in decrypting information sent between two devices. 7 The link key is created during the initial pairing process. This key is used to “protect the wireless link between two devices” (Gehrmann 2). After the key is established, the Bluetooth device stores it for future communication. The link key is stored alongside the related device address. The key can then be used to authenticate the device in future connections. 3.2 - Pairing Procedures To initialize communication between two Bluetooth devices, they must be paired. The protocol for pairing involves “creat[ing] and stor[ing] the link keys that will be used for later data encryption” (Filizzola 2). The process used for pairing is typically Secure Simple Pairing (SSP) for Bluetooth version 4.0 and LE Legacy Pairing for version 4.2 or BLE (Filizzola 2-3). There are several association models used to connect two Bluetooth devices. Bluetooth devices which have been paired will have the same PIN, a “code that is used for generating several 128-bit keys” (Haataja 2). Each pairing between a master and slave may “have a different PIN code for providing trusted relationship between devices” (Haataja 2). The PIN is significant in Bluetooth’s security, but “is often much too short” (Shaked 39). See Section 5.2 for more details on vulnerability with PIN length. Secure Simple Pairing has four different association models for the various abilities of devices. These models are Numeric Comparison, Passkey Entry, Just Works and Out of Band (OOB). LE Legacy Pairing also uses these models, with the exception of Numeric Comparison (Filizzola 3). 8 Numeric Comparison involves both devices having a display containing randomly generated numbers. Users can then confirm the numbers match, and once both users confirm the “pairing process is initialized” (Filizzola 3). The second association model, Passkey Entry, is “used in the cases when one device has input capability, but no screen that can display six digits” (Haataja 3). On the device that can only take inputs and has no output, the user is asked to input a six digit number that is displayed on the second device which has output capabilities. Devices may also be associated by both users “inputting the same six-digits PIN” (Filizzola 3). The Just Works model doesn’t take any user input and “the device may simple ask the user to accept the connection” (Haataja 3). For cases where at least one device cannot take “input nor output … and an OOB cannot be used, the Just Works association model is used” (Haataja 3). This model is convenient for the user, but is the least secure. Out of Band, or OOB, requires “both devices … to implement a different wireless communication technology such as Near Field Communication (NFC)” (Filizzola 3). This model is not common, as it requires special hardware. 3.3 - Pairing Attacks Bluetooth pairing doesn’t occur often in communication, as once devices are paired they skip to authentication. However, pairing is a primary source of vulnerability. However, there are attacks that can force devices to forget their established link keys and pair again. When devices must run the pairing process again, they are subject to the same pairing vulnerabilities. The link key is used to communicate between master and slave devices. Bluetooth allows devices to forget link keys, to which “the slave sends an LMP_not_accepted message” (Shaked 46). An adversary may inject a 9 LMP_not_accepted message, tricking the master that “the slave has lost the link key and pairing will be restarted” (Shaked 47). This restart makes the master discard the established link key, and “pairing must be done before the devices can authenticate again” (Shaked 47). There are several methods to accomplish this. A common method to trick a device that a link key is lost is simply replicating that case. Devices that have saved link keys will begin communication with authentication. The master sends an “AU_RAND [random number] message, and expects the SRES [verification]” (Shaked). Since “Bluetooth specifications allow a Bluetooth device to forget a link key,” in which case a slave will send a “LMP_not_accepted message” (Shaked 46). Adversaries can take advantage of this feature and inject a LMP_not_accepted message to restart the pairing procedure. This makes the “master discard the link key” and “assures pairing must be done before devices can authenticate again” (Shaked 47). This allows an adversary to then run their attack on the new pairing process. The next method involves injecting the first message required to establish a new link key. In the opposite direction, the slave may be convinced that the master device has forgotten the link key. An adversary can inject IN_RAND instead of AU_RAND convincing the slave “the master has lost the link key and pairing has restarted” (Shaked 47). This can cause the slave device to discard their link key and continue with this new pairing process. Another attack method is creating false failed login attempts. After the random numbers are exchanged, an adversary may also restart the pairing process by injecting an invalid SRES message. SRES is used to authenticate the slave device. After enough 10 “failed authentication attempts, the master device [declares] the authentication procedure has failed … and initiate pairing” (Shaked 47). This results in the same restart as the previous methods. Finally, another possible method is spoofing one of the devices. Suppose the slave device is spoofed, meaning a false connection is available at the same address, but, for this method, is using an invalid link key. In this case where a master is connecting to a slave device which is in the pairing mode, a re-pair attack is possible. Since a master “won’t connect to a device if link keys don’t match” (Filizzola 7), a spoofed connection with false keys can trick the master to forgetting the link key. Each of the above methods makes a device lose their link key, “assur[ing] the pairing process will occur during the next connection establishment” (Shaked 47). This allows an adversary to, for example, “eavesdrop on the entire process, and … crack the PIN” (Shaked 47). When the pairing process is restarted, the user will be asked for their PIN. This can indicate to the user that their device is under attack and can stop them from entering their PIN. 4 - Bluetooth Versions Bluetooth has several versions, with the current version at 5.0. Despite known security flaws in older versions, many devices still use them. There are “over 4 billion Bluetooth Low Energy (BLE) enabled devices in 2018 (using version 4.0 or 4.1)” (Filizzola 1). This prevalence of older devices “pos[es] a significant security vulnerability” (Filizzola 9). The various Bluetooth versions have different vulnerabilities. 11 Versions “up to 2.0+EDR” are “based exclusively on the fact that both devices share the same PIN code or passkey” (Haataja 3). Since “[t]he PIN is the only source of entropy for the shared secret. … the strength of the resulting keys is not enough for protection against passive eavesdropping on communication” (Haataja 3). This vulnerability will be discussed in detail in section 5.2. The “Bluetooth version 2.1+EDR adds a new specification for the pairing procedure … SSP [which] employs Elliptic Curve Diffie-Hellman public-key cryptography” (Haataja 3). This prevents passive eavesdropping, “as running an exhaustive search on a private key with approximately 95 bits of entropy is currently considered to be infeasible in short time” (Haataja 3). SSP also uses the Out-Of-Band (OOB) channel to protect against Man-in-the-Middle attacks (Haataja 3). This is discussed in Section 5.1. Bluetooth Low Energy (BLE), the Bluetooth 4.0 protocol, differs from Bluetooth. BLE has “low[er] power consumption … [meaning it] is a different protocol with different security goals, mechanisms and vulnerabilities” (Filizzola 2). Bluetooth version 4.2 improves on several vulnerabilities in BLE and 4.0 such as PIN brute-forcing. Many of the vulnerabilities discussed in this paper have been solved in the latest version of Bluetooth (5.0). However, they are still very relevant as there are so many Bluetooth devices of these older versions. 5 - Eavesdropping Since Bluetooth is a wireless technology, it is fairly simple for someone to capture and read information sent between devices. Eavesdroppers must be within range of the Bluetooth, and this range may be increased with range-extenders. Each packet sent with 12 the Bluetooth protocol contains an access code, header and payload. Only the payload is encrypted for transit. The information contained in the access code and header is enough for eavesdroppers to “figure out the authorization levels of the legitimate piconet devices” (Filizzola 3). Eavesdropping can be done in several ways. Eavesdropping can be either active or passive. With active eavesdropping, the adversary is able to inject, modify or intercept messages being sent between devices. This may involve tricking devices into creating predictable keys, or impersonating a device. Passive eavesdropping only involves reading messages passed between devices. However, passive eavesdropping can also result in an adversary learning established keys to decrypt messages or learning enough information to later impersonate a device. 5.1 - Active Eavesdropping (Man in the Middle Attack) A Man-in-the-Middle attack is when an adversary impersonates both ends of communication. This occurs when the adversary is able to perform active eavesdropping, meaning they can both read and modify messages as they are sent. The two victims are able to communicate without any interruption and may not detect the man in the middle. For example, suppose a master and slave device are paring then communicating. An adversary may intercept all messages between the master and slave and force each end to establish keys with the adversary. The adversary would forward messages to the intended recipient, potentially re-encrypting the information with the keys the adversary shares with each pair. This attack allows the adversary to read all messages between the victim devices, by impersonating both devices without either knowing. The Just Works method for Bluetooth does not protect against Man In the Middle attacks. Headphones, for example, use Just Works and are a “great target … [as they are 13 used] for private communication” (Filizzola 4). For headphones using Bluetooth version 4.2, when the headphones are set to pairing mode the master device can then discover it (Filizzola 5). The master device does this by sending inquiry requests “then scanning for a reply on some of these frequencies” (Filizzola 5). When a device is found, “the device broadcasts some information like the name, MAC, class and broadcasted profiles” (Filizzola 5). The MAC address “is used by the software to keep track of other devices” (Filizzola 5). An adversarial device could connect to both the headphones and master device and enact a Man In The Middle attack. 5.2 - Passive Eavesdropping (Offline Dictionary Attack) An Offline Dictionary attack is essentially another name for a brute-force attack. It involves guessing input, such as a PIN or password, until discovering the correct output. This is known as ‘Offline’ because it doesn’t require actively trying the inputs against a server, for example. To use this attack, an adversary must gain the encrypted or hashed output, and, knowing the method to encrypt or hash used, try every possible input to get that same output. Once the PIN or password is known, the adversary can then authenticate as their victim. This attack can be done through passive eavesdropping. Version 4.0 and 4.1 Bluetooth devices are vulnerable to passive eavesdropping. These protocols “encrypt data by using AES-CCM cryptography, [however] the key exchange protocols are still exploitable” (Filizzola 7). This vulnerability was fixed in versions 4.2 and up. In order to start an encrypted session, a LTK (Long Term Key) secret must be established (Filizzola 7). The devices start with a “TK (Temporary Key), which is a 128-bit value used as a key for AES encryption” (Filizzola 7). The value of this key varies by association model. 14 In Just Works the TK is zero, Passkey Entry TK is “a 6-digit PIN, given by the users of the devices,” and for OOB TK is “a 128-bit value exchanged out of bounds” (Filizzola 7). This temporary key is used to encrypt random numbers exchanged by the devices to produce another key that is used in exchanging a newly established LTK. This pairing process “LE Legacy pairing proves to be vulnerable for the association models JustWorks and Passkey Entry” (Filizzola 8). An eavesdropper could listen to the messages exchanged and “brute-force the 1,000,000 possible values of TK” (Filizzola 8). The protocol is secure for OOB since TK “takes a random 128-bit value” (Filizzola 8) yielding 2128 possible values. This protocol was secured in version 4.2 with “a ECDH key exchange protocol called LE Secure Connections” (Filizzola 8). However, in older versions the PIN could be brute-forced to be discovered by an adversary. An eavesdropper can take the messages from the pairing and authentication between two devices and use brute force to find the PIN. This is because the random numbers and BD_ADDR are sent unencrypted and the PIN can then be guessed until the session key is discovered by trying to decrypt authentication messages. A “4-digit PIN can be cracked in less than 0.3 sec[onds] on an old Pentium III 450MHz computer, and in 0.06 sec[onds] on a Pentium IV 3GHz HT computer” (Shaked 40). When the PIN is used as input to create link keys, the “PIN can be brute-forced and used for replication of the link keys by a passive eavesdropping attacker” (Filizzola 4). This attack is “only fully successful against PIN values of under 64 bits” (Shaked 43). Increasing the PIN length provides a stronger resistance against this attack. 5 - Encryption 15 Many Bluetooth devices are simple and may be unable to perform large computations or store larger values. For the Bluetooth encryption mechanism the “most significant weakness … is when 128-bit encryption cannot be used” (Filizzola 3). The length of encryption is limited to the weakest device. A key for encryption is created from “the ACO, the current link key, and a 128-bit pseudorandom number EN_RAND” (Haataja 3). This key is combined with the BD_ADDR of the master, and other attributes, to create a “keystream generator [for] symmetric encryption” (Haataja 3). “[O]nly the payload of the Bluetooth Baseband packet is encrypted” (Haataja 3). The header elements of the packet are sent unencrypted. Bluetooth Classic uses E0, “a two-level stream cipher based on 128-bit link key to encrypt packet payloads” (Albazrqaoe 72). This key is determined during pairing, in which devices “authenticate each other using a secret PIN” (Albazrqaoe 72). This key is “considerably weaker than what is originally intended” requiring only “227 online operations and 221.1 offline operations instead of 2128” (Albazrqaoe 72). “E0 uses 128-bit keys, [however] its effective security is no more than an 84-bit system” (Shaked 39). E0 was designed “specifically for Bluetooth,” and if it were used for other systems where it would be producing “several million bits, then … [it is] effectively a 39-bit system – which would make it much too weak for use” (Shaked 39). However, it has been accepted for some Bluetooth protocols. 7 - Sniffing Bluetooth sniffing is a tool for debugging and eavesdropping packets sent between devices. For Bluetooth packets to be sniffed, “the receiver needs to operate in 16 promiscuous mode, receiving all packets it can read without any regard of who it was intended for” (Filizzola 4). This hardware must be specialized (Filizzola 4). Sniffing Bluetooth is complex due to the nature of the communication. Bluetooth uses “frequency hopping spread spectrum, where carrier frequency is rapidly switched” in a random sequence (Albazrqaoe 71). Hopping occurs “between 79 channels, approximately 1600 times per second” (Filizzola 4). The hopping sequence is “hidden when Bluetooth is in indiscoverable mode” (Albazrqaoe 71). There are also many devices on the same frequency as Bluetooth, so Bluetooth employs “adaptive hopping, where the hopping sequence is frequently modified to adapt spectrum use” (Albazrqaoe 71). Additionally, “before transmission, both the header and the payload for each packet are scrambled with data whitening in order to randomize the data” (Filizzola 4). Despite the difficulty, there are “several proprietary and open source systems for sniffing Bluetooth traffic” (Albazrqaoe 72). Sniffing may be a tool for “circumventing Bluetooth encryption” (Albazrqaoe 72). For example, monitoring “the traffic pattern of popular fitness trackers is found to be strongly correlated with the user’s activity, making it possible to track user gait and identity” (Albazrqaoe 72). This can result in “a passive traffic sniffer [uncovering] important private information about the user, even without decrypting packet payloads” (Albazrqaoe 72). Even with strong encryption, information can still be vulnerable. CONCLUSION Bluetooth can be found nearly everywhere. “Passwords, phone calls and sensitive financial or medical data can be transmitted through Bluetooth devices, and users are 17 often not aware of the risk that this imposes” (Filizzola 9). Security is a concern for most, however it is not always clear what precautions must or can be taken. As a wireless technology, Bluetooth signals can easily be “leak[ed] outside the desired boundaries” (Shaked 47). This makes attacks such as eavesdropping less challenging, hence it is recommended “in the Bluetooth standard [to] refrain from entering the PIN into the Bluetooth device for pairing as much as possible” (Shaked 47). Each time the pairing process is started, it “increases the probability of an attacker eavesdropping” (Shaked 47). Users should take note of events, such as “many repeated failed authentication attempts,” which could indicate “an attacker is using [an] On-Line PIN Cracking attack to discover the secret PIN code” (Haataja 4-5). As with all technology, it is important for users to be aware of how they can configure their device’s security and be cautious of unusual behavior from that device. Users should also be aware that older Bluetooth versions are at higher risk than newer versions and should be more wary when using old versions. Bluetooth is a common technology that has some significant security vulnerabilities, however with more user awareness and upgrading to newer devices, Bluetooth usage can become more secure. 18 WORKS CITED Albazrqaoe, Wahhab et al. “A Practical Bluetooth Traffic Sniffing System: Design, Implementation, and Countermeasure.” IEEE/ACM Transactions on Networking, Volume 27, No. 1, February 2019. “Bluetooth Secure Simple pairing.” Honeywell, Revision 1.0, 24 November 2014, https://support.honeywellaidc.com/servlet/fileField?entityId=ka02K000000DlQy QAK&field=File_1__Body__s. Choi, Soo-Hwan et al. “An Implementation of Wireless Sensor Network For Security System using Bluetooth.” IEE Transactions on Consumer Electronics, Volume 50, No. 1., February 2004. Filizzola, Daniel et al. “Security Analysis of Bluetooth Technology.” https://courses.csail.mit.edu/6.857/2018/project/Filizzola-Fraser-SamsonauBluetooth.pdf. Gehrmann, Christian and Kaisa Nyberg. “Enhancements to Bluetooth Baseband Security.” 2007. Haataja, Keijo. “New Efficient Intrusion Detection and Prevention System for Bluetooth Networks.” Mobileware, Article No 16, February 2008. Jimblom. “Bluetooth Basics.” Sparkfun. Shaked, Yaniv and Avishai Wool. “Cracking the Bluetooth PIN.” MobiSys, June 2005.