On Secure Simple Pairing in Bluetooth Standard v5.0-Part II: Privacy Analysis and Enhancement for Low Energy

Bluetooth low energy devices are very popular in wireless personal area networks. According to the Bluetooth standard specifications, the low energy secure simple pairing (LESSP) protocol is the process by which the pairing devices negotiate the authenticated secret key. To violate the user privacy, the adversary can perhaps link the runs of the LESSP protocol to the targeted device, which usually relates to the specially appointed user. Hence, we investigate deep into the privacy of the LESSP protocol. Our main contributions are threefold: (1) We demonstrate that the LESSP protocol suffers from privacy vulnerability. That is, an adversary without any secret key is able to identify the targeted device by the LESSP protocol. (2) An improvement is therefore proposed to repair the privacy vulnerability in the LESSP protocol. (3) We develop a formal privacy model to evaluate the privacy vulnerabilities in the LESSP protocol and its improved versions. We further prove that our improvement on the LESSP protocol is private under the privacy model. In addition, the performance evaluation shows that our improvement is as efficient as the LESSP protocol. Our research results are beneficial to the privacy enhancement of Bluetooth systems in wireless personal area networks.


Introduction
Due to the development of ubiquitous computing, more and more people carry networking devices, e.g., laptops, smartphones, tablets, and smart watches. These devices are always interconnected via wireless short-range radio frequency communications such as Bluetooth and Wi-Fi. In ubiquitous computing environments, low energy (LE) is an important but challenging requirement for wireless and mobile devices. As the crucial innovation of Bluetooth, the LE form aims to provide low-power and low-cost wireless communications. The LE form was first introduced in Bluetooth standard v4.0 [1] and improved later in Bluetooth standard v4.2 [2]. Bluetooth standard v5.0 [3] further enhances Bluetooth standard 4.2's LE form with up to 4× the range, 2× the speed, and 8× the broadcasting message capacity [4]. Therefore, the LE form in Bluetooth standard v5.0 is treated as an ideal solution of the Internet of Things (IoT) and has been widely deployed in personal or commercial applications, compared with its basic rate/enhanced data rate (BR/EDR) form. The very recent Bluetooth standard v5.1 [5] still maintains the same LE design as Bluetooth standard v5.0.
Bluetooth LE devices have flourished in various person-related fields such as wireless personal area networks. However, these devices may incur severe privacy threats to the users, that is, the adversary

Bluetooth LE Security and Privacy
The pairing is the core design to realize the security services in the LE form. In detail, the pairing establishes the secret keys between two Bluetooth devices, and then encrypts a link of the Bluetooth devices and authenticates the Bluetooth devices by using these keys. The pairing method in Bluetooth standards v4.0 and v4.1 [1,6] is referred to as LE legacy pairing. The subsequent Bluetooth standards [2,3,5] adopt LE secure connections pairing as an enhanced version. LE secure connections pairing can be treated as LE secure simple pairing (LESSP). The pairing procedure consists of three phases as follows: • Phase 1: Pairing feature exchange. • Phase 2: LESSP protocol or LE legacy pairing protocol. • Phase 3: Transport specific key distribution (optional).
The pairing feature exchanged in phase 1 determines which of two pairing methods shall be used in phase 2. By default, a LESSP protocol is run in phase 2. A LE legacy pairing protocol is also executable if necessary. Meanwhile, when the LESSP protocol is used, phase 1 needs to choose one of the association models according to the input, output, and display capability. The available association models are the numeric comparison (NC) model, the out of band (OOB) model, the passkey entry (PE) model, and the just works (JW) model. Optionally, phase 3 may be performed to distribute transport specific keys, for example, the identity resolving key (IRK) value.
We can outline the security features of the pairing methods. Since LE legacy pairing has no NC model and does not use the elliptic curve Diffie-Hellman (ECDH) algorithm, it cannot prevent passive eavesdropping except when the OOB model is used. Comparatively, LESSP employs not only the ECDH algorithm to protect from the passive eavesdropping but also the NC, OOB, and PE models to prevent man-in-the-middle (MITM) attacks. Hence, the National Institute of Standards and Technology (NIST) [7] recommends LESSP. However, LESSP should further provide the privacy protection due to the fast development of the personal Bluetooth applications. It is meaningful to ensure that the adversary is unable to identify, track, and associate the targeted

Bluetooth LE Security and Privacy
The pairing is the core design to realize the security services in the LE form. In detail, the pairing establishes the secret keys between two Bluetooth devices, and then encrypts a link of the Bluetooth devices and authenticates the Bluetooth devices by using these keys. The pairing method in Bluetooth standards v4.0 and v4.1 [1,6] is referred to as LE legacy pairing. The subsequent Bluetooth standards [2,3,5] adopt LE secure connections pairing as an enhanced version. LE secure connections pairing can be treated as LE secure simple pairing (LESSP). The pairing procedure consists of three phases as follows: • Phase 1: Pairing feature exchange. • Phase 2: LESSP protocol or LE legacy pairing protocol. • Phase 3: Transport specific key distribution (optional).
The pairing feature exchanged in phase 1 determines which of two pairing methods shall be used in phase 2. By default, a LESSP protocol is run in phase 2. A LE legacy pairing protocol is also executable if necessary. Meanwhile, when the LESSP protocol is used, phase 1 needs to choose one of the association models according to the input, output, and display capability. The available association models are the numeric comparison (NC) model, the out of band (OOB) model, the passkey entry (PE) model, and the just works (JW) model. Optionally, phase 3 may be performed to distribute transport specific keys, for example, the identity resolving key (IRK) value.
We can outline the security features of the pairing methods. Since LE legacy pairing has no NC model and does not use the elliptic curve Diffie-Hellman (ECDH) algorithm, it cannot prevent passive eavesdropping except when the OOB model is used. Comparatively, LESSP employs not only the ECDH algorithm to protect from the passive eavesdropping but also the NC, OOB, and PE models to prevent man-in-the-middle (MITM) attacks. Hence, the National Institute of Standards and Technology (NIST) [7] recommends LESSP. However, LESSP should further provide the privacy protection due to the fast development of the personal Bluetooth applications. It is meaningful to ensure that the adversary is unable to identify, track, and associate the targeted devices by exploiting the runs of the pairing protocol. Hence, we will investigate the privacy of LESSP according to Bluetooth standards v5.0 and v5.1 [3,5].

Related Work
The privacy of the Bluetooth LE form has been widely studied. Gomez et al. [8] described that the LE form offers privacy feature and mitigates the risk that the devices will be tracked by an adversary. Gibbs [9] presented a technical guide to the basis of Bluetooth LE privacy. Wang [10] realized a privacy enhancement protocol over the advertising channels of the LE form. Raza et al. [11] introduced the enhanced privacy feature of the LE form in Bluetooth standard v4.2 and implemented it in the IoT devices. Fawaz et al. [12] investigated the privacy threats from the Bluetooth LE devices and proposed a guardian system to protect the privacy of the users equipped with these devices. AN99209 [13] provided a privacy overview of the link layer of the LE form and compared the privacy features in Bluetooth standards v4.1 and v4.2. Hassan et al. [14] investigated some security and privacy threats in the LE form and the BR/EDR form, such as the pin theft attack, the eavesdropping attack, and the victim device cloning attack. The privacy in the applications of the Bluetooth LE form has also been focused on. Mare et al. [15] proposed a hide-n-sense privacy system, which uses the LE form as a crucial component of the wireless access. Cyr et al. [16] showed that the Fitbit Flex ecosystem provides a reasonable level of privacy for user data, when the adversary observes the LE traffic between the Fitbit devices. Das et al. [17] studied the possible privacy leakage from Bluetooth LE communications between the fitness tracker and the smartphone, i.e., tracking the user location via unchanged Bluetooth LE address and inferring user's current activity through Bluetooth LE traffic analysis. Korolova et al. [18] investigated the possibilities of cross-app tracking using nearby Bluetooth LE devices on Android and iOS. Sivakumaran et al. [19] showed how unauthorized co-located Android applications can access pairing-protected LE data and presented the results of a large-scale static analysis over 18,900 LE Android applications. Cha et al. [20] deployed a privacy framework where the smartphones access the nearby IoT devices via the LE channel. Despite the increasing interest in the investigation of the LESSP security [21][22][23][24], previous work did not focus on the LESSP privacy. We examine the LESSP privacy under all possible means of privacy infringement, because the adversary must be expected to exploit any available privacy defects existing in the Bluetooth service.
Moreover, we note that the privacy of the Radio Frequency Identification (RFID) protocols has been well addressed under the formal method. For example, Ha et al. [25] and Juels and Weis [26] proposed formal privacy definitions for the RFID protocols and used them to evaluate the privacy of the RFID protocols. In light of the applicability of RFID-based privacy solutions, Kostakos [27] explored Bluetooth privacy implications. In fact, as the state-of-the-art pairing protocols [28][29][30], the lack of the formal treatment inspires us to formally analyze the privacy of the LESSP protocol.

Our Contribution
The LESSP protocol is responsible for the negotiation of the authenticated secret keys between the pairing devices, which usually relate to the specially appointed users. The privacy protection requires that the targeted device's runs of the LESSP protocol be not linked by the adversary. We address this privacy problem on the LESSP protocol. Our main contributions are threefold: (1) We demonstrate that the LESSP protocol suffers from privacy vulnerability, that is, an adversary without any secret key can identify the targeted device, when the targeted device runs the LESSP protocol. (2) An improvement is therefore proposed to repair the existing privacy vulnerability in the LESSP protocol. (3) A formal privacy model is developed to evaluate the privacy of the LESSP protocol and its improved versions. We further prove that our improvement on the LESSP protocol is private under our privacy model. In addition, the performance evaluation shows that our improvement is as efficient as the LESSP protocol.
To the best of our knowledge, previous work [22,[28][29][30] seldom involves the formal model, which can evaluate the security and privacy of the SSP protocol and the LESSP protocol. In Part I [31], we therefore propose a formal security model for the SSP protocol. In this part, a formal privacy model is also presented to define the privacy feature for the LESSP protocol. It needs to be pointed out that the substantial contribution in this part is not only a privacy enhancement on the LESSP protocol but also a privacy model which can be reused to evaluate the privacy of the follow-up LESSP protocols in the future Bluetooth standards. Although the LESSP protocol and the SSP protocol have a slight difference, these two formal models are suitable to evaluate both of them.

Notation
In Table 1, we list the notations used throughout the rest of the paper. Other notations will be defined where they are first used.

Overview
Π* aims to establish the authenticated LTK between the pairing Bluetooth devices. LTK is subsequently used in the authentication process and the sensitive data transmission process. As shown in Figure 2, Π* consists of three consecutive phases: Phase 1: Public key exchange. In this phase, both devices exchange their public keys. Phase 2: Authentication stage 1. This phase is used to prevent MITM attacks by running one of the three association models, i.e., the NC, OOB, or PE model. This phase also outputs the random nonces for the next phase. Phase 3: Authentication stage 2. Both devices in this phase confirm that they have generated MacKey and LTK and successfully completed the run of Π*.

Detailed Description
Initially, each device generates its own ECDH private-public key pair. That is, the device A and the device B generate (SKa, PKa) and (SKb, PKb) respectively. Bluetooth standard v5.0 [3], p. 2318 states that: "This key pair needs to be generated only once per device and may be computed in advance of pairing. A device may, at any time, choose to discard its public-private key pair and generate a new one, although there is not a requirement to do so." Π* is illustrated in Figure 3 and we further describe it as follows.

Detailed Description
Initially, each device generates its own ECDH private-public key pair. That is, the device A and the device B generate (SKa, PKa) and (SKb, PKb) respectively. Bluetooth standard v5.0 [3], p. 2318 states that: "This key pair needs to be generated only once per device and may be computed in advance of pairing. A device may, at any time, choose to discard its public-private key pair and generate a new one, although there is not a requirement to do so." Π* is illustrated in Figure 3 and we further describe it as follows.

Phase 1. Public Key Exchange
The initiating device A starts a run of Π* and sends its PKa to the responding device B (step 1a). The responding device B replies with its PKb (step 1b). The device A and the device B compute their shared DHKey (step 1c and step 1d). If it fails, abort

Phase 1. Public Key Exchange
The initiating device A starts a run of Π* and sends its PKa to the responding device B (step 1a). The responding device B replies with its PKb (step 1b). The device A and the device B compute their shared DHKey (step 1c and step 1d).

Phase 2. Authentication Stage 1
This phase implements one of the four association models, i.e., the NC, OOB, PE, or JW model. To prevent MITM attacks, the NC, OOB, and PE models require that the user take part in this authentication process. The JW model is the same as the NC model, except that the JW model does not require the user to confirm the commitment checks in both devices. Hence, the JW model cannot prevent MITM attacks. We omit the review of the details of the association models, because the privacy problem in these models will not be discussed. No matter what the association model is used, the device A and the device B respectively generate the random nonce Na and the random nonce Nb, and then exchange Na and Nb for the next phase. Hence, we separate these processes (step 2a, step 2b, step 3, and step 4) from the association models. In addition, Π* requires that both ra and rb be all set to 0 in the NC and JW models, that both devices generate and exchange the random ra and rb in the OOB model, and that the user in the PE model enter the same ra and rb into the devices.

Phase 3. Authentication Stage 2
Each device computes MacKey and LTK using the shared DHKey and the previously exchanged values (step 5a and step 5b). Here, || denotes the bit string concatenation and A and B are secretly exchanged before. Then the device A and the device B respectively compute Ea and Eb by using the newly shared MacKey (step 6a and step 6b). Here, IOCapA and IOCapB are negotiated by the devices during phase 1 of the pairing procedure. The device A then transmits its Ea to the device B (step 7). If the device B's check fails, it indicates that the device A has not confirmed the pairing run's authenticity and the pairing run must be aborted by the device B (step 7a). The device B then transmits its Eb to the device A (step 8). A failure check also means that the device B has not confirmed the pairing run's authenticity and the pairing run should be aborted by the device A (step 8a).

Privacy Vulnerability on LESSP Protocol
The Bluetooth LE specifications provide some privacy features. For example, the Bluetooth LE solution supports the random resolvable private address (RPA) concept, when the devices need the privacy protection services. The random RPA is generated using IRK and updated after a given interval. And the trusted peer devices resolve the random RPA to an identity address such as the public address or the static address of the device, instead of transmitting the identity address directly. All devices maintain a list of the peer device's identity addresses, the local IRK used to calculate its own random RPA, and the peer device's IRK used to resolve the peer device's random RPA. Due to the random RPA, the adversary is not easy to track the device by its identity address. However, we find that the device can be tracked by exploiting the runs of Π*.

Privacy Attacks
Each pairing device must transmit its own ECDH public key over the LE channel during every run of Π*. The Bluetooth LE specification allows that the ECDH private-public key pair is generated only once per device and is reused in the multiple runs of Π*. Hence, in order to track the device, the adversary is able to collect these public keys transmitted in each run of Π* and further identify the corresponding runs with a certain device. In detail, the adversary can perform the following steps to track a device X via the runs of Π*: Step 1. The adversary marks the targeted device X. In the device X's run of Π*, the adversary eavesdrops on its PKx during the public key exchange phase and stores it.
Step 2. In the follow-up runs of Π*, the adversary eavesdrops on each public key during the public key exchange phase. And then, the adversary checks whether the current public key is equal to his local PKx stored in step 1. If so, the adversary knows the device X takes part in the corresponding run and records the counterpart device. Figure 4 shows how to create the device X's communication profile by using the above privacy attack. This profile potentially discloses the Bluetooth activities of the device X until the change of its PKx. A sophisticated adversary can build up a communication constellation for multiple devices by extending the above privacy attack as follows.
Step 1. The adversary marks the multiple targeted devices, and then collects and stores the corresponding public keys in step 1 of the above privacy attack.
Step 2. In step 2 of the above privacy attack, the adversary eavesdrops on the public keys in the subsequent runs of Π* and instead compares them with each of the collected public keys in step 1.  Step 1. The adversary marks the multiple targeted devices, and then collects and stores the corresponding public keys in step 1 of the above privacy attack.
Step 2. In step 2 of the above privacy attack, the adversary eavesdrops on the public keys in the subsequent runs of Π* and instead compares them with each of the collected public keys in step 1. Figure 5 gives an example of the extended privacy attack. This extension helps the adversary to infer the user's behavior characteristics and the multiple users relationship via a great deal of the tracked devices.  Figure 5 gives an example of the extended privacy attack. This extension helps the adversary to infer the user's behavior characteristics and the multiple users relationship via a great deal of the tracked devices.
Step 2. In step 2 of the above privacy attack, the adversary eavesdrops on the public keys in the subsequent runs of Π* and instead compares them with each of the collected public keys in step 1. Figure 5 gives an example of the extended privacy attack. This extension helps the adversary to infer the user's behavior characteristics and the multiple users relationship via a great deal of the tracked devices.

Technical Remarks and Experimental Confirmation
The proposed privacy attacks are practical due to the following technical factors: 1. To defend itself against the proposed attacks, the device may update its public key in each run of Π*. We argue that the device tends to reuse the public key during the multiple runs of Π*.
The device needs to expend more system resources, especially more device energy, if the ECDH private-public key pair is frequently updated. However, the device energy cost is just the critical factor in the LE form. 2. The proposed attacks merely exploit the vulnerability in the public key exchange phase of Π*.
We know that the public key exchange phase is the same no matter what the NC, OOB, PE, or JW model is selected. Hence, the proposed attacks are regarded as the broad-spectrum tracking ways. 3. The proposed attacks can be performed in the off-the-shelf Bluetooth tools without the need for any hardware retrofit, because they only eavesdrop on the transmitted messages over the LE channel.
Moreover, as shown in Figure 6, we build an experiment platform to verify the proposed attacks. We use a commercially available sniffer Ubertooth One USB dongle under the Ubuntu 14.04.1 in the Oracle VM VirtualBox and test the LESSP protocol implemented by the LightBlue apps of iOS devices. Figure 7 shows the pairing public key packets sniffed by Ubertooth One USB dongle during two runs of the LESSP protocol. Here, we can track the device X.

Technical Remarks and Experimental Confirmation
The proposed privacy attacks are practical due to the following technical factors:

1.
To defend itself against the proposed attacks, the device may update its public key in each run of Π*. We argue that the device tends to reuse the public key during the multiple runs of Π*.
The device needs to expend more system resources, especially more device energy, if the ECDH private-public key pair is frequently updated. However, the device energy cost is just the critical factor in the LE form.

2.
The proposed attacks merely exploit the vulnerability in the public key exchange phase of Π*. We know that the public key exchange phase is the same no matter what the NC, OOB, PE, or JW model is selected. Hence, the proposed attacks are regarded as the broad-spectrum tracking ways.

3.
The proposed attacks can be performed in the off-the-shelf Bluetooth tools without the need for any hardware retrofit, because they only eavesdrop on the transmitted messages over the LE channel.
Moreover, as shown in Figure 6, we build an experiment platform to verify the proposed attacks. We use a commercially available sniffer Ubertooth One USB dongle under the Ubuntu 14.04.1 in the Oracle VM VirtualBox and test the LESSP protocol implemented by the LightBlue apps of iOS devices. Figure 7 shows the pairing public key packets sniffed by Ubertooth One USB dongle during two runs of the LESSP protocol. Here, we can track the device X.
3. The proposed attacks can be performed in the off-the-shelf Bluetooth tools without the need for any hardware retrofit, because they only eavesdrop on the transmitted messages over the LE channel.
Moreover, as shown in Figure 6, we build an experiment platform to verify the proposed attacks. We use a commercially available sniffer Ubertooth One USB dongle under the Ubuntu 14.04.1 in the Oracle VM VirtualBox and test the LESSP protocol implemented by the LightBlue apps of iOS devices. Figure 7 shows the pairing public key packets sniffed by Ubertooth One USB dongle during two runs of the LESSP protocol. Here, we can track the device X.

Design Frame
Informally, the adversary fails to track the device X by implementing the proposed attacks, if the device X randomly generates a new private-public key pair (SKx, PKx) for every run of Π*. However, this update operation is inefficient. To securely reuse the key pair, our idea is to create a pairing information table, that is, each device X secretly maintains a table for its previous pairing runs. As shown in Figure 8, we require that each device X's table store its previous pairing information with the devices Y1, Y2, …, and Ym. Each record in the table needs to contain the device address and the corresponding DHKey. Once any a record compromises or expires, the device X can remove it from its table. Certainly, the device X should first choose the information of the frequently paired devices into the table.

Design Frame
Informally, the adversary fails to track the device X by implementing the proposed attacks, if the device X randomly generates a new private-public key pair (SKx, PKx) for every run of Π*. However, this update operation is inefficient. To securely reuse the key pair, our idea is to create a pairing information table, that is, each device X secretly maintains a table for its previous pairing runs. As shown in Figure 8, we require that each device X's table store its previous pairing information with the devices Y 1 , Y 2 , . . . , and Y m . Each record in the table needs to contain the device address and the corresponding DHKey. Once any a record compromises or expires, the device X can remove it from its table. Certainly, the device X should first choose the information of the frequently paired devices into the table.
runs. As shown in Figure 8, we require that each device X's table store its previous pairing information with the devices Y1, Y2, …, and Ym. Each record in the table needs to contain the device address and the corresponding DHKey. Once any a record compromises or expires, the device X can remove it from its table. Certainly, the device X should first choose the information of the frequently paired devices into the table. When any two devices X and Y begin to pair, they first search their pairing information tables indexed the device address. If both devices find the other one in their pairing information tables, then they implement an aggressive LESSP protocol Π''; else they implement a modified LESSP protocol Π', where Π' and Π'' are respectively proposed in the following two subsections. Figure 9 describes the process flow of (Π', Π''). Here, similar to Π*, both Π' and Π'' should implement the association model to verify the public keys. However, for simplicity, we omit it, because the privacy of the association model is not considered. When any two devices X and Y begin to pair, they first search their pairing information tables indexed the device address. If both devices find the other one in their pairing information tables, then they implement an aggressive LESSP protocol Π"; else they implement a modified LESSP protocol Π , where Π and Π" are respectively proposed in the following two subsections. Figure 9 describes the process flow of (Π , Π"). Here, similar to Π*, both Π and Π" should implement the association model to verify the public keys. However, for simplicity, we omit it, because the privacy of the association model is not considered.

Modified LESSP Protocol
As shown in Figure 10, Π' is almost the same as Π* in Figure 3. The different points of two protocols are as follows: (1) Π' mandatorily requires that the device A and the device B randomly generate the new private-public key pairs.

Modified LESSP Protocol
As shown in Figure 10, Π is almost the same as Π* in Figure 3. The different points of two protocols are as follows: (1) Π mandatorily requires that the device A and the device B randomly generate the new private-public key pairs. (2) In the table update phase of Π , the device A and the device B may store new data into their pairing information tables.

Aggressive LESSP Protocol
As shown in Figure 11, Π'' can be treated as a simplified version of Π* in Figure 3. In Π'', although the device A and the device B reuse the shared DHKey in their pairing information tables, they still need to randomly generate PKa and PKb and then exchange them during the public key exchange phase. Note that PKa and PKb are directly selected from the defined elliptic curve [3,5] but are not computed from SKa and SKb as in Π* and Π'. The authentication stage in Π'' is similar to the authentication stage 2 in Π*. The only difference from the authentication stage is that the device A and the device B generate Na and Nb respectively and then exchange them (step 2a, step 2b, step 3, and step 4), that is, these steps appeared in the authentication stage 1 in Π*.

Aggressive LESSP Protocol
As shown in Figure 11, Π" can be treated as a simplified version of Π* in Figure 3. In Π", although the device A and the device B reuse the shared DHKey in their pairing information tables, they still need to randomly generate PKa and PKb and then exchange them during the public key exchange phase. Note that PKa and PKb are directly selected from the defined elliptic curve [3,5] but are not computed from SKa and SKb as in Π* and Π . The authentication stage in Π" is similar to the authentication stage 2 in Π*. The only difference from the authentication stage is that the device A and the device B generate Na and Nb respectively and then exchange them (step 2a, step 2b, step 3, and step 4), that is, these steps appeared in the authentication stage 1 in Π*. Sensors 2019, 19, x FOR PEER REVIEW 13 of 24 Figure 11. Aggressive LESSP protocol Π''.

Threats
Π's messages are transmitted over the wireless LE channel and therefore are easily tapped by the adversary. Moreover, the possibility of the message loss over the LE channel is higher than that over the wired channel due to mobile system malfunction or wireless communication errors. Hence, we assume that the devices and their LE channel can be controlled by the adversary. In detail, we classify two types of adversaries as follows: • Passive adversary (PA). A PA eavesdrops on all messages generated by the run of Π. The PA tries to find out LTK or other useful information of the targeted devices. However, the PA cannot tamper with any message during the run of Π.

•
Active adversary (AA). Besides acting as a PA, an AA can additionally inject, modify, and block the messages transmitted by the devices. When the devices run Π, the AA may impersonate a device by sending his fabricated messages.
According to the security and privacy requirements [1-3,5,6], we summarize that Π should be particularly able to defeat against the following attacks: If it fails, abort

Threats
Π s messages are transmitted over the wireless LE channel and therefore are easily tapped by the adversary. Moreover, the possibility of the message loss over the LE channel is higher than that over the wired channel due to mobile system malfunction or wireless communication errors. Hence, we assume that the devices and their LE channel can be controlled by the adversary. In detail, we classify two types of adversaries as follows: • Passive adversary (PA). A PA eavesdrops on all messages generated by the run of Π. The PA tries to find out LTK or other useful information of the targeted devices. However, the PA cannot tamper with any message during the run of Π. • Active adversary (AA). Besides acting as a PA, an AA can additionally inject, modify, and block the messages transmitted by the devices. When the devices run Π, the AA may impersonate a device by sending his fabricated messages.
According to the security and privacy requirements [1-3,5,6], we summarize that Π should be particularly able to defeat against the following attacks: 1.
Eavesdropping attack. During the run of Π, the PA or AA eavesdrops on the devices' messages over the LE channel and tries to derive LTK. When LTK is revealed, the PA can decrypt the encrypted data from the devices and the AA may perform other enhanced attacks, such as the replay attack and the spoofing attack. 2.
MITM attack. The MITM attack occurs, when a user wants to connect two devices but instead of connecting directly with each other they unknowingly connect to the AA's device that plays the role of the device they are attempting to pair with. To achieve the MITM attack, the AA may replay the message(s) in the previous run of Π or forge the message(s) for the current run of Π.

3.
Message loss. When the AA blocks the LE service by jamming, the messages transmitted by the devices can be interrupted. During the run of Π, the message loss may cause the data de-synchronization in the pairing information tables. We call it as the de-synchronization attack.

4.
Tracking. The PA or AA may track the devices by observing their protocol interactions. For perfect untraceability, Π must ensure that the messages emitted by the targeted device should not be distinguishable from the messages emitted by other devices.
The LESSP protocol makes use of the association models and the ECDH algorithm to prevent the eavesdropping attack and the MITM attack. In Part I [31], we show that the SSP protocols can withstand the eavesdropping attack and the MITM attack under the formal security model. In fact, with the similar security model, (Π , Π") described in Section 4 can be proved secure against the eavesdropping attack and the MITM attack. For simplicity, we do not discuss this security feature of (Π , Π"), because it can be similarly analyzed but nevertheless with a lot of background knowledge of our security model [31]. Next, we propose a formal privacy model to address the de-synchronization attack and the tracking attack.

Privacy Model
Let k or 1 k be the security parameter. A real-valued function f : N → [0, 1] is negligible if for every polynomial pl() there exists an integer N such that for every k > N, f (k) < 1/pl(k) holds. In the following, we denote an arbitrary negligible function by negl. For the sake of readability, we concentrate on asymptotic complexities and privacy, although all our results can be written with more precise bounds. The Bluetooth pairing system includes a polynomial number of the devices named as 1, 2, . . . , and n. Each device is a probabilistic interactive Turing machine with an independent source of randomness and unlimited internal storage. Any different devices A, B ∈ {1, 2, . . . , n} are allowed to run a Π multiple times with the polynomial bound. The goal of the PA and AA is to identify the targeted device by exploiting the runs of Π among the devices. Our formal privacy model generally simulates the pairing process of the devices controlled by the adversary and excludes the potential attacks using the privacy definition. Our model can be slightly adjusted to fit any particular deployment model of the Bluetooth pairing system.

Modeling Adversarial Power
To compromise the privacy of Π, the adversary is able to access the Π s instances run by the devices. This adversarial behavior is formalized by allowing the adversary to interact freely with a group of oracles. The oracles provided for the adversary are defined as follows:  A, B) to the adversary; else the Test oracle itself generates a random transcript of Π and returns it to the adversary. Here, we demand that the random transcript of Π has the same bit length with that of the output of Execute (A, B). The adversary is required to guess the random bit b according to the output of Test (A, B). For (Π , Π"), the Test oracle is specifically implemented as follows.
When b = 0, the Test oracle calls Execute (A, B). To be specific, the device A and the device B respectively search their own pairing information tables. If the other device addresses exist in their tables, then Π" is run and the complete series of the corresponding transmitted messages is output. Otherwise, the complete series of the corresponding transmitted messages is output through the run of Π .
When b = 1, the Test oracle generates SKa, PKa, SKb, PKb, Na, Nb, Ea, and Eb according to the specification of Π and returns PKa, PKb, Na, Nb, Ea, and Eb to the adversary.

Defining Privacy
In our privacy model, violating the privacy of Π informally means that the adversary distinguishes a transcript of Π generated by a device from a random transcript without any relation to the device. It is reminiscent of the polynomially indistinguishable chosen-plaintext attack [32] in a cryptosystem security game.
Let A denote the adversary. As shown in Table 2, we present a privacy game PG A,Π [n, k], where n is the number of the devices in the Bluetooth pairing system and k is the security parameter of Π. The Bluetooth pairing system is set up in the system setup phase. Each device in the Bluetooth pairing system uses Π to pair with each other. During the learning phase, A is allowed to invoke the Init, Send, Execute, Result, Reveal, and Corrupt oracles defined in Section 5.2.1. Here, assume that A has the polynomial limits of its computational power and the polynomial bounds of the number of oracles calls. In the challenge phase, A arbitrarily chooses two devices, i.e., A and B, without the compromise of their shared DHKey, and then calls Test (A, B). The task of A is to guess the random bit b according to the output of Test (A, B). A should determine b by distinguishing the transcript of Π, i.e., the output of Execute (A, B), from a random transcript generated by the Test oracle. Let A[n, k] denote A with n and k. Π is defined to be private if no A[n, k] has a non-negligible advantage in successfully guessing the random bit b in the Test oracle. Now, the privacy of Π can be defined as follows.

5.
A calls the oracle Test (A, B).

Definition 1 (k-Privacy). Π is k-privacy if for any probabilistic polynomial time
We show that the LESSP protocol fails to pass the privacy evaluation under the above privacy game. Consider PG A,Π* [n, k]. During the learning phase, the adversary A is able to select any two different devices A, B ∈ {1, 2, . . . , n}, call the oracle Execute (A, B), and obtain its output, i.e., PKa, PKb, Na, Nb, Ea, and Eb. During the challenge phase, A continues to select two uncorrupted devices A and B, and then calls the oracle Test (A, B). The oracle Test (A, B) returns PKa, PKb, Na, Nb, Ea, and Eb to A. If the previous PKa in the learning phase is equal to the current PKa, A determines b = 0 in step 6 of PG A,Π* [n, k]; else A guesses b = 1 in step 6 of PG A,Π* [n, k]. Assume that p * is the probability of reusing (SKa, PKa) in the device A's next run of Π*. We have: (2) Because p * is not negligible, we conclude that Π* violates the privacy requirement in Definition 1.

Privacy Result of Our Improvement and Its Proof
The adversary may initiate the de-synchronization attack on the device and further observe the abnormal run of Π to track this device. In (Π , Π"), the only way for the attack to be successful is to de-synchronize the data of the pairing information tables between the pairing devices. However, in Figure 9, we see that the devices should implement Π , if a device fails to share DHKey in the previous run. Clearly, (Π , Π") can prevent the adversary from guessing the random bit b by the de-synchronization attack, because it does not make the device enter the abnormal run. Hence, we do not consider the de-synchronization attack in the following discussion. We need two well-known cryptographic assumptions to prove the privacy result of (Π , Π"). For the reader's convenience, we rewrite them as follows: Definition 3 in [31]). Let gen(1 k ) be a parameter generation algorithm that outputs the description of a group G, its generator P ∈ G, and its order q. We say the Decisional Diffie-Hellman (DDH) problem is hard relative to G if for all probabilistic polynomial time algorithms D there exists a negligible function negl such that: |Prob(D (gen (1 k ), a·P, b·P, ab·P) = 1) − Prob (D (gen(1 k ), a·P, b·P, c·P) = 1)| < negl(k), where a, b, and c are randomly chosen in {1, . . . , q}.

Definition 3.
Let gen(1 k ) be a parameter generation algorithm that outputs the description of a group G, its generator P ∈ G, and its order q. Let H 0 () be a key derivation function. Let H 1 (H 0 (ab·P, ), ) be a keyed pseudorandom function using the Diffie-Hellman key derivation function if for every probabilistic polynomial time distinguisher D* there exists a negligible function negl such that |Prob(D*(gen(1 k ), a·P, b·P, H 1 (H 0 (ab·P, ), )) = 1) − Prob(D*(gen(1 k ), a·P, b·P, R()) = 1)| < negl(k), where a and b are randomly chosen in {1, . . . , q} and R() is a truly random function.
Definition 3 is almost the same as Definition 4 in [31]. However, we replace the Diffie-Hellman key ab·P with a key derivation function H 0 (ab·P, ). We have MacKey || LTK = f 5(DHKey, Na, Nb, A, B) in step 5a and step 5b of Π*, Π , and Π". Hence, we define MacKey = [f 5(DHKey, Na, Nb, A, B)] Mac . To reduce our privacy results, the following lemma is required. Proof of Lemma 1. As shown in Figure 10, we know (SKa, PKa) and (SKb, PKb) are updated in each run of Π and any (SKx, PKx) in Π is independent from each other. Hence, during the learning phase of the privacy game PG A,Π , A learns no knowledge of the bit b by calling the Reveal and Corrupt oracles. It means that we can exclude the Reveal and Corrupt oracles in PG A,Π .
In the learning phase of PG A,Π , A can call the Init, Send, Execute, and Result oracles to any different pairing devices i, j ∈ {1, 2, . . . , n} and then receive the corresponding responses. Next, A enters into the challenge phase of PG A,Π . He selects a challenge device A ∈ {1, 2, . . . , n} and any other device B ∈ {1, 2, . . . , n} and calls the oracle Test (A, B). We know that Test oracle acts as follows.
When b = 0, it calls Execute (A, B) and returns its output PKa, PKb, Na, Nb, Ea, and Eb to A. Here, according to the specification of Π , PKa, PKb, Na, Nb, Ea, and Eb are respectively generated by the device A and the device B.
When b = 1, the Test oracle directly generates its PKa, PKb, Na, Nb, Ea, and Eb according to the specification of Π and returns them to A.
Whether the random bit b is 0 or 1, A always receives a uniform transcript of Π , i.e., PKa, PKb, Na, Nb, Ea, and Eb. Hence, we have: This completes the proof.
Theorem 1. Assume that P256() in both Π and Π" satisfies the DDH assumption as in Definition 2. Assume that [f5()] Mac and f6() in Π and Π" are respectively the key derivation function and the keyed pseudorandom function using the Diffie-Hellman key derivation function as in Definition 3. Assume that the device always keeps its pairing information table secret. Then, (Π , Π") is private according to Definition 1.
Proof of Theorem 1. We know that the Corrupt oracle cannot help A to guess the random bit b in the Test oracle of the privacy game PG A,(Π ,Π") , because all DHKeys generated by Π are random and independent, the pairing information table is kept secret, and the oracles Corrupt (Π A,B ) and Corrupt (Π B,A ) are not allowed if the corresponding DHKey is used during the challenge phase of PG A,(Π ,Π") . Therefore, we exclude the Corrupt oracle in the following discussions.
To violate the privacy of (Π , Π"), A completely relies on the correct guess of the random bit b after the Test oracle is called during the challenge phase. When the Test oracle calls Execute (A, B), two devices A and B run either Π or Π" if b = 0. There are therefore two cases to consider: Case 1: Π is run in the Test oracle when b = 0. This case means that both the device A and the device B do not maintain the shared DHKey in their pairing information tables. When b = 0, the Test oracle calls Execute (A, B) and returns the output of Execute (A, B) to A. Here, Execute (A, B) outputs a newly exchanged transcript of Π . When b = 1, the Test oracle also simulates Π and returns its random transcript of Π to A. Let E 1 be the event that PG A,(Π ,Π") [n, k] succeeds in guessing b, if Π is run in the Test oracle when b = 0. By Lemma 1, we have Prob(E 1 ) = Prob( PG A,Π [n, k] succeeds in guessing b) = 1 2 . Case 2: Π" is run in the Test oracle when b = 0. This case means that both the device A and the device B maintain the shared DHKey in their pairing information tables. During the learning phase of PG A,(Π ,Π") , A can collect and verify the transcripts of (Π , Π"), send the fabricated messages, and disclose the secret keys by calling the Execute, Result, Init, Send, and Reveal oracles. Certainly, A can implement these operations for the device A and the device B. And then, during the challenge phase of PG A,(Π ,Π") , A must strictly depend on correctly guessing the random bit b in the oracle Test (A, B). Let E 2 be the event that PG A,(Π ,Π") [n, k] succeeds in guessing b, if Π" is run in the Test oracle when b = 0. If (Π , Π") is private under PG A,(Π ,Π") [n, k], we know that: Let δ 1 (k) be a function such that We demonstrate that δ 1 (k) is negligible by presenting a DDH problem distinguisher D 1 with the same advantage δ 1 (k). The distinguisher D 1 receives (a·P, b·P, K) and attempts to determine whether K = ab·P or K is a random element in the group G. The distinguisher D 1 simulates the learning phase and the challenge phase of PG A,(Π ,Π") in the following: Simulation of the learning phase. When A calls the Execute, Result, Init, Send, and Reveal oracles, the distinguisher D 1 also invokes these oracles to the corresponding devices and returns the outputs of these oracles to A.
Simulation of the challenge phase. When A selects the device A and the device B and calls the oracle Test (A, B), the distinguisher D 1 simulates the Test oracle as follows: The distinguisher D 1 flips a fair random coin b. If b = 0, the distinguisher D 1 calls Execute (A, B). It means that a complete run between the partnered instances Π" A,B and Π" B,A is performed. The output of the Execute oracle is the complete series of messages exchanged by the partnered instances Π" A,B and Π" B,A , i.e., PKa, PKb, Na, Nb, Ea, and Eb. Note that both the device A and the device B obtain the shared DHKey in their pairing information tables and the shared DHKey has no relation with PKa and PKb. The distinguisher D 1 returns PKa, PKb, Na, Nb, Ea, and Eb to A.
After the query of the Test oracle, the distinguisher D 1 outputs 1 when A outputs his guessing b = b in PG A,(Π ,Π") . In the view of A, the above simulation by the distinguisher D 1 is exactly PG A,(Π ,Π") when K = ab·P. Hence, we know: When K is a random element in the group G, MacKey is computed by using the random element K instead of DHKey = ab·P and Ea and Eb are further calculated by using MacKey. We know that A cannot guess the random bit b from PKa and PKb, because the device A, the device B, and the distinguisher D 1 all does not use PKa and PKb to generate DHKey in this situation. Let δ 2 (k) be a function such that A outputs b = b with probability 1 2 + δ 2 (k), where δ 2 (k) is the advantage by exploiting MacKey, Ea, and Eb. We show that δ 2 (k) is a negligible function by contradiction. Assume that δ 2 (k) is a non-negligible function. We assume that Ea and Eb are generated by the truly random function R() if the random element K is replaced with DHKey. We directly construct the distinguisher D 2 to tell the keyed pseudorandom function f 6([f 5(DHKey, )] Mac , ) from the truly random function R(). And the distinguisher D 2 outputs a correct guess with probability 1 2 + δ 2 (k) by the same reason as the distinguisher D 1 does in the case where the random element K exists. However, the advantage of the distinguisher D 2 is a non-negligible function δ 2 (k), which is contradiction against Definition 3. Hence, δ 2 (k) is a negligible function. We further have: By Definition 2, we know that δ 1 (k) is a negligible function due to the negligible function δ 2 (k). Assume that p denotes the probability of E 1 occurring and p" denotes the probability of E 2 occurring. Clearly, it follows that p + p" = 1. We further have: Thus, we conclude that (Π , Π") is private by Definition 1.

Performance Evaluation
In this section, we discuss the implementation efficiency of our improvement due to its LE applications. Our performance evaluation has two levels, i.e., the basic protocol analysis and the Bluetooth pairing system analysis. We know that it is not easy to measure the costs of the human operations in the association models. Hence, we omit the costs of these models in all pairing protocols. As shown in Figures 3, 10 and 11, the costs of both pairing devices are all the same in these protocols, if we do not consider the association models. Therefore, we always calculate the costs on one device. The experiments are executed on the following platform: (1) Experiment environment: The basic cryptographic algorithms are executed on Windows 10 64 bits, Intel(R) Core(TM) i7-8700 CPU @3.20 GHz 3.19GHz, and 8.00 GB RAM. (2) Cryptographic tool: Python 3.6.6 cryptography toolkit PyCryptodemo. Table 3 shows the computation costs of the LESSP protocol and our improved one. The LESSP protocol is further divided into two cases, i.e., the key pair reuse and the key pair update. The experiment results of these pairing protocols are shown in Figure 12. We can see that the computation efficiency of the aggressive LESSP protocol is significantly higher than other protocols. experiment results of these pairing protocols are shown in Figure 12. We can see that the computation efficiency of the aggressive LESSP protocol is significantly higher than other protocols. Table 3. Computation efficiency of pairing protocols.

Communication Cost and Storage Cost
As shown in Table 4, we calculate the communication costs of the transmitted messages during the runs of the pairing protocols. And for the storage cost, we merely calculate the long-term parameters, i.e., the reused key pair and the values stored in the pairing information table.

Energy Cost Concern
The energy cost of our improvement is the same as or less than the LESSP protocol, if the cost of searching the pairing information table is free. The reason is that our aggressive LESSP protocol does not need to generate the ECDH private-public key pair and compute the Diffie-Hellman key and other computation and communication costs of both our improvement and the LESSP protocol are the same.

Bluetooth Pairing System Analysis
We consider the computation costs of a device, which probably pairs with a set of other n* devices in the Bluetooth pairing system. Let P be the total number of the pairing run and m be the number of the records of the Bluetooth device's pairing information tables in our improvement. Let W be the probability distribution of the devices' pairing runs, where W = [p1, p2, …, pn*] and p1 ≤ i ≤ n* denotes the probability of the event that the device pairs with the device i in the Bluetooth pairing

Communication Cost and Storage Cost
As shown in Table 4, we calculate the communication costs of the transmitted messages during the runs of the pairing protocols. And for the storage cost, we merely calculate the long-term parameters, i.e., the reused key pair and the values stored in the pairing information table.

Energy Cost Concern
The energy cost of our improvement is the same as or less than the LESSP protocol, if the cost of searching the pairing information table is free. The reason is that our aggressive LESSP protocol does not need to generate the ECDH private-public key pair and compute the Diffie-Hellman key and other computation and communication costs of both our improvement and the LESSP protocol are the same.

Bluetooth Pairing System Analysis
We consider the computation costs of a device, which probably pairs with a set of other n* devices in the Bluetooth pairing system. Let P be the total number of the pairing run and m be the number of the records of the Bluetooth device's pairing information tables in our improvement. Let W be the probability distribution of the devices' pairing runs, where W = [p 1 , p 2 , . . . , p n* ] and p 1≤i≤n* denotes the probability of the event that the device pairs with the device i in the Bluetooth pairing system. We know that p 1 + p 2 + . . . + p n* = 1.

Number of Devices
We set P = 10,000 and m = 5 and assume p 1 + p 2 + p 3 + p 4 + p 5 = 0.8 and p 6 + p 7 + . . . + p n* = 0.2. We evaluate the computation costs of the LESSP protocol and our improvement, when the number of devices n* = 10, 15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95, and 100, respectively. Figure 13 shows the experimental results of the device's computation time costs. Our improvement yields about 100-400% time reduction against the LESSP protocol with the key pair reuse and the LESSP protocol with the key pair update.  Figure 13 shows the experimental results of the device's computation time costs. Our improvement yields about 100% -400% time reduction against the LESSP protocol with the key pair reuse and the LESSP protocol with the key pair update.

Number of Records
We set n* = 50 and P = 10,000 and assume p1 + p2 + p3 + p4 + p5 = 0.8 and p6 + p7 + … + p50 = 0.2. We evaluate the computation costs of the LESSP protocol and our improvement, when the number of records m ranges from 5 to 20. Figure 14 shows the experimental results of the device's computation time costs. In Figure 14, we can observe that the time saving of our improvement is similar to the case of the variable number of devices in Section 6.2.1.

Number of Records
We set n* = 50 and P = 10,000 and assume p 1 + p 2 + p 3 + p 4 + p 5 = 0.8 and p 6 + p 7 + . . . + p 50 = 0.2. We evaluate the computation costs of the LESSP protocol and our improvement, when the number of records m ranges from 5 to 20. Figure 14 shows the experimental results of the device's computation time costs. In Figure 14, we can observe that the time saving of our improvement is similar to the case of the variable number of devices in Section 6.2.1.  Figure 13 shows the experimental results of the device's computation time costs. Our improvement yields about 100% -400% time reduction against the LESSP protocol with the key pair reuse and the LESSP protocol with the key pair update.

Number of Records
We set n* = 50 and P = 10,000 and assume p1 + p2 + p3 + p4 + p5 = 0.8 and p6 + p7 + … + p50 = 0.2. We evaluate the computation costs of the LESSP protocol and our improvement, when the number of records m ranges from 5 to 20. Figure 14 shows the experimental results of the device's computation time costs. In Figure 14, we can observe that the time saving of our improvement is similar to the case of the variable number of devices in Section 6.2.1.

Probability Distribution
We set n* = 50, P = 10,000, and m = 5. We evaluate the computation costs of the LESSP protocol and our improvement, when the probability distribution W = [p 1 , p 2 , . . . , p 50 ] varies in our improvement. The value range of p 1 + p 2 + p 3 + p 4 + p 5 changes from 0.1 to 0.9. Figure 15 shows the device's experimental time costs. When the value of p 1 + p 2 + p 3 + p 4 + p 5 increases, the time cost of our improvement significantly reduces. In fact, in wireless personal area networks, it is common for a few devices to have very high pairing probabilities.

Probability Distribution
We set n* = 50, P = 10,000, and m = 5. We evaluate the computation costs of the LESSP protocol and our improvement, when the probability distribution W = [p1, p2, …, p50] varies in our improvement. The value range of p1 + p2 + p3 + p4 + p5 changes from 0.1 to 0.9. Figure 15 shows the device's experimental time costs. When the value of p1 + p2 + p3 + p4 + p5 increases, the time cost of our improvement significantly reduces. In fact, in wireless personal area networks, it is common for a few devices to have very high pairing probabilities. We believe that the execution performance of both our improvement and the LESSP protocol should be similar as that observed in Figures 13, 14, and 15, when they are realized on commercial-off-the-shelf (COTS) LE Bluetooth devices. That is to say, although COTS Bluetooth LE devices may have different processing power, the execution performance is dominated by the corresponding parameters in Section 6.2.1, Section 6.2.2, and Section 6.2.3, whereas COTS Bluetooth LE devices merely determine the detailed values of the computation costs.

Conclusions and Future Work
When the LESSP protocol is deployed in the Bluetooth system, an adversary can track the targeted device by its reuse of the private-public key pair. In fact, the SSP protocol has a similar privacy weakness. Our improvement on the LESSP protocol is proven to be able to overcome the privacy weakness under the proposed privacy model. Moreover, the experimental results show that our improvement is as efficient as the LESSP protocol.
It needs to be pointed out that our improvement has not been evaluated with open-source software stacks and software-defined radios. Therefore, our future work is to use the Universal Software Radio Peripheral (USRP) [33] to implement the LESSP protocol and our improvement. Based on it, we can obtain the energy cost and the more accurate efficiency results for these protocols. We conclude with two interesting open problems for the privacy of the LESSP protocol. Firstly, our work has not dealt with the privacy of the association models in the LESSP protocol. In fact, the adversary may violate the privacy of the LESSP protocol by intercepting the communications during the run of the association models. Secondly, we have not investigated the forward/backward privacy of the LESSP protocol. Backward privacy means that, if the adversary reveals the secret of a Bluetooth device A at time τ , the adversary is not able to tell whether a run of the protocol before time τ involves the device A. Forward privacy deals with the adversary who, even with the knowledge of the secret of the device A at time τ, cannot determine whether the same device was involved in a run of the protocol that occurred at time τ + τ' (for some τ' > 0). To solve these two privacy problems, we need a new privacy model and a redesigned LESSP protocol.  We believe that the execution performance of both our improvement and the LESSP protocol should be similar as that observed in Figures 13-15, when they are realized on commercial-off-the-shelf (COTS) LE Bluetooth devices. That is to say, although COTS Bluetooth LE devices may have different processing power, the execution performance is dominated by the corresponding parameters in Sections 6.2.1-6.2.3, whereas COTS Bluetooth LE devices merely determine the detailed values of the computation costs.

Conclusions and Future Work
When the LESSP protocol is deployed in the Bluetooth system, an adversary can track the targeted device by its reuse of the private-public key pair. In fact, the SSP protocol has a similar privacy weakness. Our improvement on the LESSP protocol is proven to be able to overcome the privacy weakness under the proposed privacy model. Moreover, the experimental results show that our improvement is as efficient as the LESSP protocol.
It needs to be pointed out that our improvement has not been evaluated with open-source software stacks and software-defined radios. Therefore, our future work is to use the Universal Software Radio Peripheral (USRP) [33] to implement the LESSP protocol and our improvement. Based on it, we can obtain the energy cost and the more accurate efficiency results for these protocols. We conclude with two interesting open problems for the privacy of the LESSP protocol. Firstly, our work has not dealt with the privacy of the association models in the LESSP protocol. In fact, the adversary may violate the privacy of the LESSP protocol by intercepting the communications during the run of the association models. Secondly, we have not investigated the forward/backward privacy of the LESSP protocol. Backward privacy means that, if the adversary reveals the secret of a Bluetooth device A at time τ, the adversary is not able to tell whether a run of the protocol before time τ involves the device A. Forward privacy deals with the adversary who, even with the knowledge of the secret of the device A at time τ, cannot determine whether the same device was involved in a run of the protocol that occurred at time τ + τ (for some τ > 0). To solve these two privacy problems, we need a new privacy model and a redesigned LESSP protocol.