1
Dynamic Trust and Reputation Model for Secure Communications Utilizing Bluetooth Service
Discovery Protocol
Mantie N. Reid
Seidenberg School of Computer Science and Information Systems, Pace University
Pleasantville, NY 10570, USA
Email: [email protected]
Abstract—Bluetooth technology has become the standard
for wireless equipment connection. The technology has evolved and improved over the years and it has gain widespread acceptance which leads to the technology been found in many aspects of our lives. As the widespread use and acceptance of Bluetooth continues, concerns are been raised related to security vulnerabilities and privacy issues inherit in the use of the technology. Inadequate devices resources and lack of user awareness has compounded the issue where the emphasis on design constraints, functionality and ease of use sometimes outweigh security concerns. Bluetooth technology offers much convenience and ease of use, but it lacks a central security infrastructure. Due to this, it has very serious security vulnerabilities and the need for awareness of the security risks are increasing as the applications of the technology continues to grow exponentially. It can be found in speakers, headsets, printers, keyboards, toys, vehicles, medical devices, as well as many other types of devices. This paper presents an overview of the Bluetooth Technology and a proposed research to analyze the Bluetooth Service Discovery Protocol (SDP) as specified by the Service Industry Group (SIG) for vulnerabilities and to develop an improve trust & Reputation protocol to address these security vulnerabilities.
Index Terms—Bluetooth, Trust & Reputation, SIG, Bluetooth Vulnerabilities, Bluetooth Security, Frequency-hopping spread spectrum (FHSS), Service discovery Protocol (SDP), Special Interest Group (SIG), Trust and Reputation.
I. Introduction
Bluetooth is a short-range wireless communication
technology that was developed, to replaced hard-wired
equipment connections, for the home, office and mobile
Personal Digital Assistances (PDAs) [1]. Bluetooth technology
was invented in 1994 at Ericsson, a telecommunications
company in Sweden. The technology was designed 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, becomes available in
stores. Approximately two years later, the Bluetooth
technology was ratified by IEEE for 802.15.1 [2].
Bluetooth technology is increasingly ubiquitous today. All
smartphones, for example, are Bluetooth-enabled devices [7]
and Bluetooth low energy technology is an increasingly
common technology used to support the introduction of an
impressively wide array of devices to the Internet of Things
(IoT) [15]. Bluetooth has become one of the most widely used
technologies in use today, and it is the standard for short-
range wireless communication that allow devices to connect
and exchange information [3]. Because it can potentially
provide security, privacy, and high-quality wireless
communication [5], this technology will likely only continue to
grow in its application as the Internet of Things spreads to
encompass an ever-growing list of devices from smartphones
to appliances to automobiles [27] or even to locks [21].
Bluetooth has also seen applications in the medical field,
where Bluetooth-enabled wireless sensors may serve to
reduce the cognitive load on emergency room doctors [13] or
provide essential telemetry data to assist in patient treatment
[33]. Given this astoundingly wide array of applications for the
technology—many of which include handling very sensitive or
private data—one would imagine that security would be
perhaps the foremost issue in Bluetooth application and a
problem long-since solved.
Unfortunately, this is not the case, Bluetooth technology
has a checkered security history; in previous versions,
something as innocuous as leaving a Bluetooth-enabled device
turned on while not in use could allow a malicious attacker to
gain complete control of it [1]. Recent versions of Bluetooth,
up to and including Bluetooth version 4.1, have sought to
address many of the security vulnerabilities that have long
plagued the technology [9]. However, many challenges
remain; for example, while Bluetooth can offer security and
privacy, it cannot offer both at once, with random address
assignment—a privacy feature—contributing significantly to a
lack of security because it prevents true device identification
2
and allows for deceptive attacks [5]. In addition, although
national standards suggest that all Bluetooth devices should
be run in their highest security mode [28], these high security
modes are rarely enabled by default. More troublingly, the
users of these devices, whose data is at risk from security
vulnerabilities, are often ambivalent or ignorant regarding
Bluetooth security practices [20].
The remaining parts of this paper are organized as follows:
Section 2 reviews the Bluetooth technology, the Bluetooth
Protocol Stack, Security and modes along with trust modes.
Bluetooth Service Discovery Protocol (SDP), Discoverability in
devices, and Built-in-security features are in Section 3 and
Bluetooth taxonomy of attacks is in section 4. Section 5
describes the proposed Eigentrust Trust and Reputation
solution approach. Finally, section 6 concludes the paper with
a brief summery and directions for future work.
2. Overview of Bluetooth
Bluetooth operates in the unlicensed Industrial, Scientific,
and Medical (ISM) radio frequency (RF) 2.4 GHZ spectrum and
have a range from between 0.5-1 m to 100 m. Bluetooth
enables low power communication between devices that are
in proximity of each other. There are three classes of devices
offering three (3) connectivity ranges. Class 1 devices transmit
at 100mW and offer a range of 100 meters – 300 feet. Class 2
devices (the most common) transmit at 2.5mW and have a
range of 10 meters – 30 feet. Class 3 devices transmit at 1 mW
and have a range of approximately 1 meter – 3 feet. A key
advantage of Bluetooth is that it can transmit both voice and
data simultaneously. It supports asynchronous (data) links and
synchronous (audio) links and error handling is provided for
through re-transmission of packets. One of the disadvantages
of Bluetooth technology is that it shares the 2.4 Ghz radio
frequency spectrum with many consumer appliances, i.e.
microwaves, baby monitors, toys, and cordless phones. This
creates the possibilities of interferences with those devices
when they are in use [1, 2, 3].
Presently, the Bluetooth technology comes in various
designs and upgraded versions. Bluetooth 1.1 and, the later
improved version of Bluetooth technology, Bluetooth 1.2 are
known as Basic Rate (BR). These allow transmission speeds of
up to 1 Mbps. Bluetooth version 2.0, known as Enhanced Data
Rate ( EDR), allows transmission speeds of up to 3 Mbps.
Bluetooth version 3.0, which is known as Bluetooth High Speed
(HS), provides data speeds of up to 24 Mbps. Bluetooth version
4.0, known as Bluetooth Low Energy (BLE) and is simple more
efficient, offers 1 Mbps and achieves lower power
consumption for use in medical devices. The most updated
version of the Bluetooth technology is Bluetooth 4.1 and 4.2
[2].
Bluetooth 5 has been announced as the next upgraded
version of the Bluetooth technology and will be known for its
low energy mode [3, 6]. Bluetooth BLE can use minimum
power while facilitating data exchanges; this leads to the
preferred equipment connection between IoT devices and
could positively affect IoT technology by giving devices the
ability to exists and successfully function in a wide variety of
application scenarios [2].
When two or more Bluetooth devices communicate
together, it is called a piconet. It can be used to connect almost
any two Bluetooth-enabled devices together. The connection
between a cell phone and a wireless headset is an example of
a Bluetooth piconet. Connectivity in a piconet is spontaneous
in an ad hoc manner. One device is designated as a master and
the other is known as slave. Most Bluetooth devices can
operate as either a master or slave. The master is the one that
initiates the piconet by first searching for devices within the
range that are in discoverable mode, at 1.28 seconds intervals.
When it finds a device that wants to join the piconet, the
master will send an invite to that device. Devices can belong to
one or more piconet, and the combination of two or more
piconets forms a scatternet. While a device can be a master in
one piconet, it can be a slave in another piconet. Each active
slave is assigned a unique active member address, AM_ADDR,
by the master. It is possible to have to have more than 7 slaves
registered by the master, but a maximum of 7 can be active at
one time. The exception is Bluetooth LE which can have an
unlimited number. The other devices will be parked and may
be invited by the master to become active later [3].
A piconet utilizes a unique frequency-hopping spread
spectrum (FHSS) technique moving through 1600 channels per
second to create a frequency hopping pattern. Each channel is
used for only 625 microseconds before hopping to the next
channel. Once connected, a slave will synchronize with the
master’s clock to get the correct frequency hopping pattern.
The slave will be assigned a unique timeslot (channel) for
transmitting. This prevents collisions with other devices in the
same piconet. In addition, since it hops over 79 frequency
channels, the likelihood of interference with another piconet
is low. Each hop is a timeslot where data packets can be
transferred. Since a packet can span up to 5 hops, the
frequency will remain constant for that transfer. The master
initiates regular transmissions to keep the piconet
synchronized, while the slave listen to the master time slots.
The master sends transmissions on even numbered slots, and
the slaves transmit on odd numbered slots. A slave will only
transmit after it has received a transmission from the master
[2,3]
Figure 1 below provides an illustration of a basic Bluetooth
piconet.
3
Figure 1. Bluetooth Piconet
2.1. Bluetooth Protocol Stack
Figure 2 below illustrates the Bluetooth protocol stack for
Bluetooth design 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 (LMP) Radio Frequency Communication (RFCOMM)
protocol, and the Service Discovery Protocol (SDP) [2].
Figure 2. Bluetooth Protocol Stack (Bluetooth 1, 2, & 3)
A host controller Interface (HCI), reflected in 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
[1,2]. The stack consists of three layers namely: The Control
Layer, the Host Layer and the Apps Layer. Each of the layers
incorporate different protocols. The Control Layer
incorporates the Physical Layer, Direct Test Mode, Link Layer
and Host Controller Interface [1]. The Host Layer incorporates
the Link Logical Control and Adaptation Protocol, Attribution
Protocol , Security Manager, Generic Attribute Profile, and
Generic Access Profile. The App Layer incorporates the
Applications.
Figure 3. Bluetooth Protocol Stack (Bluetooth 4).
The L2CAP passes data packets to the higher levels. The Link
Management protocol establishes and control the links
between devices. The Radio Frequency Communications
Protocols provides serial communications that are widely used
and manage as many as 60 simultaneous active connections
between two devices. The Service Discovery Protocol (SDP)
allows devices to advertise the services that they offer, and it
also offers a way for devices to find one another [3].
2.2. 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 [2].
2.3. Bluetooth Security Modes
All Bluetooth devices operate in 1 of 4 defined access
security modes: Security Mode 1 (nonsecure); 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
4
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].
2.4. 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.
Authentication: verification of the identities of the of the
Bluetooth devices. User authentication is not provided.
Confidentiality: ensuring that only authorized devices can
access transmitted data.
Authorization: allowing only authorized devices to access
services.
Security services that are not included in the Bluetooth
standard include audit, integrity and non-repudiation [3].
3. Bluetooth Service Discovery Protocol
The Bluetooth Service Discovery Protocol (SDP) enables
network devices, applications, and services to seek out and
find other complementary network devices, applications, and
services needed to properly complete specified tasks. SDP
provides a means for applications to discover which services
are available and to determine the characteristics of those
services available.
In Bluetooth environment, the set of services available
changes dynamically based on the radio frequency (RF)
proximity of devices of devices in motion. This is quantitatively
different from traditional service discovery protocols in
networks-based environments. Bluetooth SDP does not
provide a mechanism for notifying clients when service
records are added or removed from an SDP server. Thus, a
service record acquired from a server shall remain valid unless
the service it represents is removed. SDP provides the
capability for a client on one device to discover a service on
another device without consulting a third device and is
suitable for use on devices of limited complexity.
Figure 4 – Bluetooth SDP Client - Server Architecture
SDP defines how a Bluetooth client’s application shell acts to
discover available Bluetooth servers’ services and their
characteristics. The protocol defines how client can search for
a service based on specific attributes without the client
knowing anything of the available services. The SDP provides
means for discovery of new services upon becoming available
when the client enters an area where a Bluetooth server is
operating. It also provides functionality for detecting when a
service is no longer available [1].
SDP is a simple protocol with minimal requirements on the
underlying transport. It can function over a reliable packet
transport (or even unreliable, if the client implements
timeouts and repeats requests as necessary). SDP uses a
request/response model – as reflected in Figure 4 - where each
transaction consists of one request protocol data unit (PDU)
and one response PDU. However, the requests may potentially
be pipelined, and responses may potentially be returned out
of order. In the specific case where SDP utilizes Bluetooth logic
link control and adaptation protocol (L2CAP) transport
protocol, multiple SDP PDUs may be sent in a single L2CAP
packet, but only one L2CAP packet per connection to a given
SDP server may be outstanding at a given instant. Limiting SDP
to sending one unacknowledged packet provides a simple
form of flow control.
Every SDP PDU consists of a PDU header followed by PDU-
specific parameters. The header contains three fields: - PDU ID
field identifies the type of PDU. I.e. its meaning and the specific
parameters (1-byte length). - TransactionID field uniquely
identifies request PDUs and is used to match response PDUs to
request PDUs (2-byte length). - ParameterLength field
specifies the length (in bytes) of all parameters contained in
the PDU (2-byte length). Parameters may include a
continuation state parameter, described below; PDU-specific
5
parameters for each PDU type are described later in separate
PDU descriptions.
Some SDP requests may require responses that are larger
than can fit in a single response PDU. In this case, the SDP
server will generate a partial response along with a
continuation state parameter. The continuation state
parameter can be supplied by the client in a subsequent
request to retrieve the next portion of the complete response.
It has only two fields InfoLenght (1 byte) and Continuation
Information (InfoLenght bytes)
Each transaction consists of a request and a response PDU.
Generally, each type of request PDU has a corresponding type
of response PDU. However, if the server determines that a
request is improperly formatted or for any reason the server
cannot respond with the appropriate PDU type, it will respond
with an error PDU (SDP_ErrorResponse) .
The goal of Bluetooth SDP is to allow Bluetooth devices to
discover what other Bluetooth devices can offer – what other
services – and SDP allows this in various means. Searching
means look for specific service while browsing mean look to
see what services is been offered. This is the process of
discoverability.
3.1. 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
Bluetooth device address - 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].
3.2. Discoverability in Devices
The first time two devices attempted to connect, a trusted
relationship needs to be established through an
authentication process. 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]. 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.1andlater) use SSP
for the pairing process, which utilizes public key cryptography
instead of a PIN.
Authorization first begins by determine whether the device
had previously been authorized as a trusted device. If the
device database lists it as a trusted device, then access to
service is granted. If the device is not listed as a trusted device,
trust must first be established before it is authorized.
Confidentiality is achieved through encryption using E0
stream cypher. A link key and the BD_ADDR of the device re
used to develop a key stream that when combined with plain
achieves a cyphered text. Attacks on cryptanalysis attempts on
E0 have proven that the stream cipher is vulnerable to attacks.
3.3 Built-in Security Features
Bluetooth technology has certain built-in features that help
secure the technology. They include:
a) Adoptive 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.
b) E0 Cipher Suit: The cipher generally has a key length of
128 bits and uses stream ciphering.
c) Undiscoverability: This prevents devices from
responding to scanning attempts. A device 48-bit
BD_ADDR address is also concealed.
d) Pairing: Pairing enables devices to communicate. A
device BD_ADDR must be known for a pairing request
to be made. The DB_ADDR is identified from knowledge
of previous pairing or scanning.
4. Bluetooth Taxonomy of Attacks
The Bluetooth threat Taxonomy illustrated below in
Figure 5, 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].
6
Figure 5 – Bluetooth Threat Taxonomy
,
The Bluetooth threat Taxonomy outlined in figure 5, outlines
and classifies Bluetooth based threats. The classification
system can help to determine the severity of threats, presents
precautionary methods and presents reactionary strategies.
The pairing process, or the process of connecting one device
to another, is a main contributor to security issues found in
Bluetooth. Attacks can be performed during different stages of
the pairing process including before the pairing process has
completed and after devices are paired. Attackers may be able
to carry out Man-in-the-Middle attacks based on information
they collected after pairing. Thus, these are some of the more
common attacks:
a) MAC Spoofing Attack:
The attack is performed before encryption is established and
during the formation of the piconet when link keys are been
generated [8]. Devices can authenticate each other by
generating link-keys. During the attack, attackers can imitate
another user [8]. Attackers also have the ability to terminate
connections or intercept/modify data with the use of special
tools [8]. Figure 6 below demonstrates a MAC spoofing attack.
Adversary is the malicious node
Figure 6 – MAC Spoofing attack
b) Man-in-the-Middle Attack:
Man-in-the-Middle Attacks, or the impersonation of
another device, occur when one attempted to pair.
During the attack, messages are relay 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].
Figure 7 – Man-In-the-Middle Attacks
As illustrated in figure 7, the legitimate user sends a
connection request to a printer but there is the intruder
in the middle known as MITM who send random signals
to disrupt the physical layer of initiating and non-
initiating devices. The physical or signaling layer is
7
disrupted due to continuous random signals. When this
layer is disrupted, the initiating device is not able to
connect with the printer, so it has to delete all link keys
that they have exchanged before.
After deleting all link keys, they will send a connection
request to each other but the intruder attack on them
and exchange all link keys with both devices. They do
not have the information that there is an unauthorized
device between them and send their secret information
to the intruder. They continue the communication
without knowing the information about the intruder
which is MITM.
To solve this problem many researches have already
been done but there is no approach which provide a
reliable solution to the problem. By considering the
same problem, this article proposed an approach which
will provide a reliable security in most of the security
vulnerabilities cases.
5. Related Work In 2015, Dubey et.el published their review of Bluetooth Security Vulnerabilities and proposed a prototype model for enhanced security against MITM attack [9]. The current pairing mechanism for Bluetooth can be described as follows:
Figure 8 – Bluetooth Pairing Procedures First, initialization key is generated using the three parameters: Bluetooth Address, Random Number, and Pin. This results in a key that is used to generate key Kab and is demonstrated in figure 8 above.
The final process of the pairing mechanism is to authenticate the Bluetooth devices which is done by using the combination link key Kab. This process is a challenge response scheme. Each device calculates the response key using the LINK KEY, BD_ADDR, and AU_RAND. If the link key value for both devices match each other then the two devices are paired [9]. The researchers identified a problem that the Bluetooth mechanism is totally dependent on some random numbers and the Bluetooth address and pin. They realized that the pin can be guessed or can be captured from the air. A simple MITM attack can be enough to reveal the secret keys. To enhance the security of Bluetooth, they used the concept of Dual Shared Secret Key. Instead of using a single secret key, as it is now, the researchers use another shared secret parameter which is called Blu_Secret (128 bit). This uses the E22 algorithm to generate the initialization key . This key is a shared parameter which can be exchanged between two devices using the Diffie Helman Key exchange method. This key exchange method is has been accepted by the Bluetooth SIG as a method to exchange keys [9]. With this novel approach, the two devices will be updated with an additional key
6. Proposed Eigentrust Trust & Reputation Approach
Figure 8 – Proposed Trust & Reputation Approach
8
Figure 8 shows the main steps in the in the Trust and Reputation algorithm starting from accepting a client request for a certain message through the user interface. The request would be handled by the Bluetooth SDP where the message trust value is calculated based on the Eigentrust Trust and Reputation Algorithm. The message is flagged accordingly as trust or untrusted. Untrustworthy messages would cause the Bluetooth pair to deny the transaction while trustworthy messages would be accepted directly . unknown message would require checking the peer trust value based on the Eigentrust Algorithm. If the peer is untrusted, the transaction is denied. Otherwise, access is accepted. In all cases, the local trust values related to the source message and peer will be updated and the new values are shared with friendly peers. The purpose of this research is to analyze the Bluetooth SDP as specified by SIG for vulnerabilities and develop and develop a framework to implement the Eigentrust trust and reputation protocol to address and prevent these vulnerabilities. Many common forms of Bluetooth-enabled devices, such as cars or smart watches, are already vulnerable to malicious attacks that can compromise personal information, and the number of devices using this technology is expanding rapidly [7]. Although the vulnerabilities inherent in the Bluetooth SDP do not explicitly allow attackers to access the system, they do provide access to a significant amount of valuable data, such as information about all Bluetooth devices and services that are available. This could potentially enable attackers to then use other methods to target those services [7,2,4]. Moreover, to gain access to these data, the attacker need only obtain access to the key generated by the application layer protocol L2CAP. Therefore, this study will attempt to fully analyze this problem and develop a solution in the form of a trust protocol to plug this SDP vulnerability.
7. Conclusions
The problem is that, although the security of Bluetooth
technology has improved with the implementation of
Bluetooth 4.1 and 4.2 [14], many applications of the
technology, such as in automobiles, tend to lag the state-of-
the art [6]. Moreover, even up-to-date Bluetooth devices may
be significantly vulnerable to “man-in-the-middle” attacks and
other security exploits, with attackers able to steal data or
even take control of the device entirely [25]. This is a serious
problem because Bluetooth devices are used in a number of
extremely important contexts, such as medical monitoring
devices for the elderly [23] or even tactical communication in
the military [19]. Many common Bluetooth applications, such
as mobile watches, can also be compromised to steal a
significant amount of personal data, exposing users to identity
theft [11]. The Bluetooth SDP represents the source of at least
one such continuing vulnerability [22].
REFERENCES
[1] Alfaiate, J., & Fonseca, J. (2012, June). Bluetooth security analysis for mobile phones. In Information Systems and Technologies (CISTI), 2012 7th Iberian Conference on (pp. 1-6). IEEE.
[2] Bluetooth SIG, Specification of the Bluetooth System – Core, Version 1.0B volume1,1999.PartE. http://www.bluetooth.com/link/spec/bluetooth_e. pdf
[3] 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 13
April 2019).
[4] Bello, G. (2017). Bluetooth Low Energy: Secure or Unsecure? (Master’s thesis, Columbus State University).
[5] Cha, S. C., Yeh, K. H., & Chen, J. F. (2017). Toward a Robust Security Paradigm for Bluetooth Low Energy-Based Smart Objects in the Internet-of-Things. Sensors, 17(10), 2348. doi: 10.3390/s17102348
[6] Cheah, M., Bryans, J., Fowler, D. S., & Shaikh, S. A. (2017, June). Threat Intelligence for Bluetooth-Enabled Systems with Automotive Applications: An Empirical Study. In Dependable Systems and Networks Workshop (DSN-W), 2017 47th Annual IEEE/IFIP International Conference on (pp. 36-43). IEEE. doi: 10.1109/DSN-W.2017.22
[7] Ching, K. W., & Singh, M. M. (2016). Wearable technology devices security and privacy vulnerability analysis. International Journal of Network Security and Its Applications, 8(3), 19-30.
[8] Clarke, V., & Braun, V. (2013). Teaching thematic analysis: Overcoming challenges and developing strategies for effective learning. The psychologist, 26(2), 120-123.
[9] Cope, P., Campbell, J., & Hayajneh, T. (2017, January). An investigation of Bluetooth security vulnerabilities. In Computing and Communication Workshop and Conference (CCWC), 2017 IEEE 7th Annual (pp. 1-7). IEEE. doi: 10.1109/CCWC.2017.7868416
[10] Das, S. (2015). Link Management Security in Bluetooth (Doctoral dissertation).
[11] Do, Q., Martini, B., & Choo, K. K. R. (2017). Is the data on your wearable device secure? An Android Wear smartwatch case study. Software: Practice and Experience, 47(3), 391-403. doi: 10.1002/spe.2414
[12] Faragher, R., & Harle, R. (2015). Location fingerprinting with bluetooth low energy beacons. IEEE journal on Selected Areas in Communications, 33(11), 2418-2428. doi: 10.1109/JSAC.2015.2430281
[13] Frisby, J., Smith, V., Traub, S., & Patel, V. L. (2017). Contextual Computing: A Bluetooth based approach for tracking healthcare providers in the emergency room. Journal of biomedical informatics, 65, 97-104. doi: 10.1016/j.jbi.2016.11.008
[14] Gajbhiye, S., Karmakar, S., Sharma, M., & Sharma, S. (2018). Two-party secure connection in Bluetooth-enabled devices. Information Security Journal: A Global Perspective, 27(1), 42-56. doi: 10.1080/19393555.2018.1423714
[15] Grabovica, M., Popić, S., Pezer, D., & Knežević, V. (2016, June). Provided security measures of enabling technologies in Internet of Things (IoT): A survey. In Zooming Innovation in Consumer Electronics International Conference (ZINC), 2016(pp. 28-31). IEEE. doi: 10.1109/ZINC.2016.7513647
[16] Han, T., & Ding, L. (2017, August). Design and implementation of Bluetooth beacon in mobile payment system. In AIP Conference Proceedings (Vol. 1864, No. 1, p. 020019). AIP Publishing. doi: 10.1063/1.4992836
9
[17] Hassan, S. S., Bibon, S. D., Hossain, M. S., & Atiquzzaman, M. (2017). Security threats in Bluetooth technology. Computers & Security, 74, 308-322. doi: 10.1016/j.cose.2017.03.008
[18] Hasan, R., Zawoad, S., Noor, S., Haque, M. M., & Burke, D. (2016, June). How secure is the healthcare network from insider attacks? An audit guideline for vulnerability analysis. In Computer Software and Applications Conference (COMPSAC), 2016 IEEE 40th Annual (Vol. 1, pp. 417-422). IEEE. doi:
[19] Hortelano, D., Olivares, T., Ruiz, M. C., Garrido-Hidalgo, C., & López, V. (2017). From sensor networks to internet of things. Bluetooth low energy, a standard for this evolution. Sensors, 17(2), 372. doi: 10.3390/s17020372
[20] Imgraben, J., Engelbrecht, A., & Choo, K. K. R. (2014). Always connected, but are smart mobile users getting more security savvy? A survey of smart mobile device users. Behaviour & Information Technology, 33(12), 1347-1360. doi: 10.1080/0144929X.2014.934286
[21] Jeong, H. D. J., Lee, W., Lim, J., & Hyun, W. (2015). Utilizing a Bluetooth remote lock system for a smartphone. Pervasive and Mobile Computing, 24, 150-165. doi: 10.1016/j.pmcj.2015.07.010
[22] Kaushik, S., Poonia, R. C., & Khatri, S. K. (2017). Comparative study of various protocols of DDS. Journal of Statistics and Management Systems, 20(4), 647-658. doi: 10.1080/09720510.2017.1395184
[23] Kumar, M. (2014, December). Security issues and privacy concerns in the implementation of wireless body area network. In Information Technology (ICIT), 2014 International Conference on (pp. 58-62). IEEE. doi: 10.1109/ICIT.2014.73
[24] Ledbetter, W. B. (2017). Analyzing inherent vulnerabilities and associated risks in Bluetooth technology. University of South Alabama.
[25] Melamed, T. (2018). An active man-in-the-middle attack on Bluetooth smart devices. International Journal of Safety and Security Engineering, 8(2), 200-211. doi: 10.2495/SAFE-V8-N2-200-211
[26] Nair, K. K., Helberg, A., & Van Der Merwe, J. (2015). Intrusion detection in Bluetooth enabled mobile phones (pp. 1-8). IEEE. doi: 10.1109/ISSA.2015.7335048
[27] Noor, N. M., Kamardin, K., Daud, S. M., Sjarif, N. A., Ahmad, N. A., Azmi, A., & Sam, S. M. (2018). External attacks on automotive system through wireless communication channels. Journal of Fundamental and Applied Sciences, 10(2S), 11-23. doi: 10.4314/jfas.v10i2s.2
[28] Padgette, J. (2017). Guide to bluetooth security. NIST Special Publication, 800, 1-67. doi: 10.6028/NIST.SP.800-121r2
[29] Qu, Y., & Chan, P. (2016, April). Assessing Vulnerabilities in Bluetooth Low Energy (BLE) Wireless Network Based IoT Systems. In Big Data Security on Cloud (BigDataSecurity), IEEE International Conference on High Performance and Smart Computing (HPSC), and IEEE International Conference on Intelligent Data and Security (IDS), 2016 IEEE 2nd International Conference on (pp. 42-48). IEEE. doi: 10.1109/BigDataSecurity-HPSC-IDS.2016.63
[31] Thompson, B., Morris-King, J., & Harang, R. (2016, November). Slowing the spread of Bluetooth-based malware in mobile tactical networks. In Military Communications Conference, MILCOM 2016-2016 IEEE (pp. 485-490). IEEE. doi: 10.1109/MILCOM.2016.7795374
[32] Vaishnavi, V. K., & Kuechler, W. (2015). Design science research methods and patterns: innovating information and communication technology. Crc Press.
[33] Zegeye, W. K. (2015, October). Exploiting Bluetooth low energy pairing vulnerability in telemedicine. In International Telemetering Conference Proceedings. International Foundation for Telemetering.
[34] Zou, Y., Zhu, J., Wang, X., & Hanzo, L. (2016). A survey on wireless security: Technical challenges, recent advances, and future trends. Proceedings of the IEEE, 104(9), 1727-1765. doi: 10.1109/JPROC.2016.2558521
