On Secure Simple Pairing In Bluetooth Standard V5.0-Part .

Sensors 2019, 19, 32593 of 231.2. Related WorkThe privacy of the Bluetooth LE form has been widely studied. Gomez et al. [8] described that theLE 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 privacyenhancement protocol over the advertising channels of the LE form. Raza et al. [11] introduced theenhanced privacy feature of the LE form in Bluetooth standard v4.2 and implemented it in the IoTdevices. Fawaz et al. [12] investigated the privacy threats from the Bluetooth LE devices and proposeda 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 inBluetooth standards v4.1 and v4.2. Hassan et al. [14] investigated some security and privacy threatsin the LE form and the BR/EDR form, such as the pin theft attack, the eavesdropping attack, and thevictim device cloning attack. The privacy in the applications of the Bluetooth LE form has also beenfocused on. Mare et al. [15] proposed a hide-n-sense privacy system, which uses the LE form asa crucial component of the wireless access. Cyr et al. [16] showed that the Fitbit Flex ecosystem providesa reasonable level of privacy for user data, when the adversary observes the LE traffic between theFitbit devices. Das et al. [17] studied the possible privacy leakage from Bluetooth LE communicationsbetween the fitness tracker and the smartphone, i.e., tracking the user location via unchanged BluetoothLE address and inferring user’s current activity through Bluetooth LE traffic analysis. Korolovaet al. [18] investigated the possibilities of cross-app tracking using nearby Bluetooth LE devices onAndroid and iOS. Sivakumaran et al. [19] showed how unauthorized co-located Android applicationscan access pairing-protected LE data and presented the results of a large-scale static analysis over18,900 LE Android applications. Cha et al. [20] deployed a privacy framework where the smartphonesaccess the nearby IoT devices via the LE channel. Despite the increasing interest in the investigation ofthe LESSP security [21–24], previous work did not focus on the LESSP privacy. We examine the LESSPprivacy under all possible means of privacy infringement, because the adversary must be expected toexploit any available privacy defects existing in the Bluetooth service.Moreover, we note that the privacy of the Radio Frequency Identification (RFID) protocols hasbeen 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 ofthe RFID protocols. In light of the applicability of RFID-based privacy solutions, Kostakos [27] exploredBluetooth privacy implications. In fact, as the state-of-the-art pairing protocols [28–30], the lack of theformal treatment inspires us to formally analyze the privacy of the LESSP protocol.1.3. Our ContributionThe LESSP protocol is responsible for the negotiation of the authenticated secret keys between thepairing devices, which usually relate to the specially appointed users. The privacy protection requiresthat the targeted device’s runs of the LESSP protocol be not linked by the adversary. We address thisprivacy problem on the LESSP protocol. Our main contributions are threefold: (1) We demonstrate thatthe LESSP protocol suffers from privacy vulnerability, that is, an adversary without any secret key canidentify the targeted device, when the targeted device runs the LESSP protocol. (2) An improvement istherefore proposed to repair the existing privacy vulnerability in the LESSP protocol. (3) A formal privacymodel is developed to evaluate the privacy of the LESSP protocol and its improved versions. We furtherprove 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–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 modelis also presented to define the privacy feature for the LESSP protocol. It needs to be pointed out thatthe substantial contribution in this part is not only a privacy enhancement on the LESSP protocol butalso a privacy model which can be reused to evaluate the privacy of the follow-up LESSP protocols

Sensors 2019, 19, 32594 of 23in the future Bluetooth standards. Although the LESSP protocol and the SSP protocol have a slightdifference, these two formal models are suitable to evaluate both of them.1.4. NotationIn Table 1, we list the notations used throughout the rest of the paper. Other notations will bedefined where they are first used.Table 1. Description of notation.TermDefinitionΠ*Π0Π”(Π0 , Π”)ΠΠA,BXIOcapX(SKx, PKx)DHKeyMacKeyLESSP protocolModified LESSP protocolAggressive LESSP protocolOur improvement on Π*One of Π*, (Π0 , Π”), and other LESSP-type protocolBluetooth device A’s any Π instance run with Bluetooth device BBluetooth address of Bluetooth device XIO capabilities of Bluetooth device XECDH private-public key pair of Bluetooth device XDiffie-Hellman key128-bit key of message authentication code128-bit long term key used to generate the contributory session key for an encryptedconnectionNonce (unique random value) generated by Bluetooth device XCheck value from Bluetooth device XValue from Bluetooth device XECDH algorithm used to compute DHKeyFunction used to compute MacKey and LTKFunction used to generate ExProbability of event E occurringConditional probability of event E0 given event E”, which measures probability of event E0occurring, given that event E” has occurredLTKNxExrxP256()f 5()f 6()Prob(E)Prob(E0 E”)2. LESSP Protocol2.1. OverviewΠ* aims to establish the authenticated LTK between the pairing Bluetooth devices. LTK issubsequently used in the authentication process and the sensitive data transmission process. As shownin 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 thethree association models, i.e., the NC, OOB, or PE model. This phase also outputs the randomnonces for the next phase.Phase 3: Authentication stage 2. Both devices in this phase confirm that they have generated MacKeyand LTK and successfully completed the run of Π*.2.2. Detailed DescriptionInitially, each device generates its own ECDH private-public key pair. That is, the device A andthe device B generate (SKa, PKa) and (SKb, PKb) respectively. Bluetooth standard v5.0 [3], p. 2318 statesthat: “This key pair needs to be generated only once per device and may be computed in advance ofpairing. A device may, at any time, choose to discard its public-private key pair and generate a newone, although there is not a requirement to do so.” Π* is illustrated in Figure 3 and we further describeit as follows.

SensorsFOR PEER REVIEWSensors2019,2019,19,19,x32595 5ofof2423BeginPhase 1: Public key exchangePhase 2: Authentication stage 1Phase 3: Authentication stage 2EndSensors 2019, 19, x FOR PEER REVIEW6 of 24Figure 2. Flowchart of LESSP protocol.Figure 2. Flowchart of LESSP protocol.Initiating Device ANon-initiating Device B2.2. Detailed Description1a. PKaInitially, each device generates its own ECDH private-public key pair.PublicThat is,thedevice A andKeyExchange1b. PKbthe device B generate (SKa, PKa) and (SKb, PKb) respectively. Bluetooth standard v5.0 [3],1c. Computep. 2318 states that: “Thiskey pair needs to be generated only1d.onceper device and may be computedComputeDHKey P256(SKa,PKb)DHKey P256(SKb,PKa)in advance of pairing. A device may, at any time, choose to discard its public-private key pair andgenerate a new one, although there is not a requirement to do so.” Π* is illustrated in Figure 3 andwe further describe it as follows.Association modelAuthentication Stage 12a. Select random Na2b. Select random Nb3. Na4. Nb5a. ComputeMacKey LTK f5(DHKey,Na,Nb,A,B)5b. ComputeMacKey LTK f5(DHKey,Na,Nb,A,B)6a. ComputeEa f6(MacKey,Na,Nb,rb,IOcapA,A,B)6b. ComputeEb f6(MacKey,Nb,Na,ra,IOcapB,B,A)7. Ea7a. Check ifEa f6(MacKey,Na,Nb,rb,IOcapA,A,B).If it fails, abort8. Eb8a. Check ifEb f6(MacKey,Nb,Na,ra,IOcapB,B,A).If it fails, abortAuthentication Stage 2:LTK CalculationFigure 3. LESSP protocol Π*.2.2.1. Phase 1. Public Key Exchange Figure 3. LESSP protocol Π*.initiatingdeviceA starts a run of Π* and sends its PKa to the responding device B (step 1a).2.2.1.ThePhase1. PublicKey ExchangeThe responding device B replies with its PKb (step 1b). The device A and the device B compute theirThe initiating device A starts a run of Π* and sends its PKa to the responding device B (step 1a).shared DHKey (step 1c and step 1d).The responding device B replies with its PKb (step 1b). The device A and the device B compute theirshared DHKey (step 1c and step 1d).2.2.2. Phase 2. Authentication Stage 1This 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 thisauthentication process. The JW model is the same as the NC model, except that the JW model does

Sensors 2019, 19, 32596 of 232.2.2. Phase 2. Authentication Stage 1This 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 thisauthentication process. The JW model is the same as the NC model, except that the JW model doesnot require the user to confirm the commitment checks in both devices. Hence, the JW model cannotprevent MITM attacks. We omit the review of the details of the association models, because the privacyproblem in these models will not be discussed. No matter what the association model is used, thedevice A and the device B respectively generate the random nonce Na and the random nonce Nb, andthen 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 to0 in the NC and JW models, that both devices generate and exchange the random ra and rb in the OOBmodel, and that the user in the PE model enter the same ra and rb into the devices.2.2.3. Phase 3. Authentication Stage 2Each device computes MacKey and LTK using the shared DHKey and the previously exchangedvalues (step 5a and step 5b). Here, denotes the bit string concatenation and A and B are secretlyexchanged before. Then the device A and the device B respectively compute Ea and Eb by usingthe newly shared MacKey (step 6a and step 6b). Here, IOCapA and IOCapB are negotiated by thedevices 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’sauthenticity and the pairing run must be aborted by the device B (step 7a). The device B then transmitsits Eb to the device A (step 8). A failure check also means that the device B has not confirmed thepairing run’s authenticity and the pairing run should be aborted by the device A (step 8a).3. Privacy Vulnerability on LESSP ProtocolThe Bluetooth LE specifications provide some privacy features. For example, the Bluetooth LEsolution supports the random resolvable private address (RPA) concept, when the devices need theprivacy 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 addressor the static address of the device, instead of transmitting the identity address directly. All devicesmaintain a list of the peer device’s identity addresses, the local IRK used to calculate its own randomRPA, and the peer device’s IRK used to resolve the peer device’s random RPA. Due to the randomRPA, the adversary is not easy to track the device by its identity address. However, we find that thedevice can be tracked by exploiting the runs of Π*.3.1. Privacy AttacksEach pairing device must transmit its own ECDH public key over the LE channel during everyrun of Π*. The Bluetooth LE specification allows that the ECDH private-public key pair is generatedonly 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 thecorresponding runs with a certain device. In detail, the adversary can perform the following steps totrack a device X via the runs of Π*:Step 1. The adversary marks the targeted device X. In the device X’s run of Π*, the adversaryeavesdrops 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 publickey exchange phase. And then, the adversary checks whether the current public key is equalto his local PKx stored in step 1. If so, the adversary knows the device X takes part in thecorresponding run and records the counterpart device.

Sensors 2019, 19, 32597 of 23Figure 4 shows how to create the device X’s communication profile by using the above privacyattack. This profile potentially discloses the Bluetooth activities of the device X until the change ofits PKx. A sophisticated adversary can build up a communication constellation for multiple devices byextending the above privacy attack as follows.Step 1. The adversary marks the multiple targeted devices, and then collects and stores thecorresponding 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 thesubsequent runs of Π* and instead compares them with each of the collected public keysin step1. REVIEWSensors 2019, 19, x FORPEER8 of 24Figure 4. An example of the tracked device X’s communication profile.Figure 4. An example of the tracked device X’s communication profile.Figure 5 gives an example of the extended privacy attack. This extension helps the adversarytheadversaryuser’s behaviorcharacteristicsand themultipledevices,users relationshipvia collectsa great dealof theStepto1.inferThemarksthe multipletargetedand thenandstores thetrackeddevices.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 inthe subsequent runs of Π* and instead compares them with each of the collectedpublic keys in step 1.Figure 5 gives an example of the extended privacy attack. This extension helps the adversary toinfer the user’s behavior characteristics and the multiple users relationship via a great deal of thetracked devices.Device Y1Device Y5

Step 2. In step 2 of the above privacy attack, the adversary eavesdrops on the public keys inthe subsequent runs of Π* and instead compares them with each of the collectedpublic keys in step 1.Figure 5 gives an example of the extended privacy attack. This extension helps the adversary tocharacteristics and the multiple users relationship via a great deal of8 ofthe23tracked devices.infer theSensors2019,user’s19, 3259behaviorDevice Y1Device Y5Device Y2Device Y6Device XDevice Y3Device Y7Device Y4Device Y8Device Y9Device Y10Device Y11Sensors 2019, 19, x FOR PEER REVIEW9 of 24(a)Device Y1Device Y5Device Y2Device Y6Device XDevice Y3Device Y7Device Y4Device Y8Device Y9Device Y10Device Y11(b)Figure 5. An example of the extended privacy attack: (a) The communication activities of multipleFigure 5. An example of the extended privacy attack: (a) The communication activities of multipletracked devices; (b) The tracked devices’ communication constellation derived from Figure 5a.tracked devices; (b) The tracked devices’ communication constellation derived from Figure 5a.3.2. Technical Remarks and Experimental Confirmation3.2. Technical Remarks and Experimental ConfirmationThe proposed privacy attacks are practical due to the following technical factors: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 run1. To defend itself against the proposed attacks, the device may update its public key in each runof Π*. We argue that the device tends to reuse the public key during the multiple runs of Π*.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 ECDHThe device needs to expend more system resources, especially more device energy, if theprivate-public key pair is frequently updated. However, the device energy cost is just the criticalECDH private-public key pair is frequently updated. However, the device energy cost is justfactor in the LE form.the critical factor in the LE form.2.The proposed attacks merely exploit the vulnerability in the public key exchange phase of Π*.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 JWWe know that the public key exchange phase is the same no matter what the NC, OOB, PE, ormodel is selected. Hence, the proposed attacks are regarded as the broad-spectrum tracking ways.JW model is selected. Hence, the proposed attacks are regarded as the broad-spectrum tracking3.The proposed attacks can be performed in the off-the-shelf Bluetooth tools without the needways.for any hardware retrofit, because they only eavesdrop on the transmitted messages over the3. The proposed attacks can be performed in the off-the-shelf Bluetooth tools without the needLE channel.for any hardware retrofit, because they only eavesdrop on the transmitted messages over theLEchannel.as shown in Figure 6, we build an experiment platform to verify the proposed attacks.Moreover,We usea commerciallyavailablesnifferOneexperimentUSB dongleplatformunder the14.04.1in theMoreover,as shownin Figure6, Ubertoothwe build anto Ubuntuverify s. We use a commercially available sniffer Ubertooth One USB dongle under the Ubuntu14.04.1 in the Oracle VM VirtualBox and test the LESSP protocol implemented by the LightBlueapps of iOS devices. Figure 7 shows the pairing public key packets sniffed by Ubertooth One USBdongle 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 needfor any hardware retrofit, because they only eavesdrop on the transmitted messages over theLE channel.SensorsMoreover,2019, 19, 3259asshown in Figure 6, we build an experiment platform to verify the proposed9 of 23attacks. We use a commercially available sniffer Ubertooth One USB dongle under the Ubuntu14.04.1 in the Oracle VM VirtualBox and test the LESSP protocol implemented by the LightBlueFigureof7 iOSshowsthe pairingkey thepacketssniffedby UbertoothOneUSB dongleduring Onetwo runsappsdevices.Figurepublic7 showspairingpublickey packetssniffedby eviceX.dongle during two runs of the LESSP protocol. Here, we can track the device X.Sensors 2019, 19, x FOR PEER REVIEW10 of 24Figure 6. Privacy experiment platform for LE Bluetooth devices.(a)(b)Figure 7. (a) Test 1 and its corresponding pairing public key packet (public key X: 1c768cbcaeb496eFigure7. (a) Test 1 and its corresponding pairing public key packet (public key X: d017175e50b4a5, public key Y: 0eb2f4e08fbba7b481bd8 0b4a5,key Y: 8c15510a37d5ba); (b) Test 2 andpublicits correspondingpairing public key pack

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 pairin