Bluetooth Secure Simple Pairing with enhanced security level

Journal of Information Security and Applications 44 (2019) 170–183

Contents lists available at ScienceDirect

Journal of Information Security and Applications journal homepage: www.elsevier.com/locate/jisa

Bluetooth Secure Simple Pairing with enhanced security level Samta Gajbhiye a,∗, Sanjeev Karmakar b, Monisha Sharma c, Sanjay Sharma d a

Department of Computer Science & Engineering, SSGI, SSTC, Bhilai, Chhattisgarh, India Department of Master of Computer Application BIT, Durg, Chhattisgarh, India c Department of Electronics & Telecommunication, SSGI, SSTC, Bhilai, Chhattisgarh, India d Department of Mathematics, BIT, Durg, Chhattisgarh, India b

a r t i c l e

i n f o

Article history:

Keywords: Secure Simple Pairing Input-Output capability Elliptic curve Diffie–lliptic Curve Diffie-Hellman Numeric Comparison HMAC-SHA256 AES-CCM authentication-encryption

a b s t r a c t Bluetooth version 5.0 introduced flexibility in SSP pairing protocol. It introduced P-192 elliptic curve for devices that support all versions before 4.0 and P-256 elliptic curve for devices that support 4.0, 4.1, 4.2, and 5.0 versions. Despite enhanced security level, there is a possibility of capturing the Input-Output capability and public keys during the initial phase of pairing and thus impersonating them. This paper introduces enhanced Bluetooth Secure Simple Pairing protocol by augmenting two new security levels. The protocol commits for public keys and IO capability. This ensures that the information reaches to the legitimate pairing devices. Thereby attempts to reduce Man-In-The-Middle attack in the initial phase and strengthen the link/session key. © 2018 Elsevier Ltd. All rights reserved.

1. Introduction Even though the Special Interest Group (SIG) worked on security issues of Secure Simple Pairing (SSP), Man-In-The-Middle (MITM) can still find its way from an unencrypted and unsafe channel in Bluetooth enabled devices to generate link/session key either through passive off-line guessing or through active on-line guessing. The Input-Output (IO) capability of the pairing devices is exchanged in unencrypted form during the first phase of pairing [23]. Therefore, MITM find a way to seize the IO capability and all other related information amid pairing and forces the legitimate devices to adopt the association model as per his demand [21,22,24,25]. This paper therefore aims to remove this drawback by suspending its relay until required. The SSP employs Elliptic Curve Diffie–Hellman key exchange algorithm. Amid pairing, ECDH key exchange follows the transmission of public keys through an insecure and unencrypted channel [11]. It, therefore, becomes easy for the intruder to creep in the course of pairing, capturing the unsecured public keys, stops its transmission further. Thus, impersonates the legitimate devices, by putting in his own material like public keys and IO-capability. For ∗

Corresponding author at: SSGI, SSTC, Junwani Road, Smriti Nagar, Bhilai, Chhattisgarh 490020, India. E-mail addresses: [email protected] (S. Gajbhiye), dr.karmakars@gmail. com (S. Karmakar), [email protected] (M. Sharma), [email protected] (S. Sharma). https://doi.org/10.1016/j.jisa.2018.11.009 2214-2126/© 2018 Elsevier Ltd. All rights reserved.

this, MITM uses two Bluetooth devices to connect with the two legitimate devices. Thus, the objective of the paper is to reduce the MITM attack by getting rid of the flaws in SSP, as described above. Thereby enhancing the security of the existing SSP protocol. In the end, comparative security analysis of SSP and proposed protocol SSP-APKE-DECE (Secure Simple Pairing with Authenticated Public Key Exchange and Delayed Encrypted Capability Exchange) is discussed. The experimental results show that the runtime of the enhanced SSP-APKE-DECE is more as compared to SSP in Bluetooth current version. However, the increased security level in SSP-APKEDECE dominates the increased pairing time. The paper is constructed with various sections. Section 2 discusses MITM attacks on SSP and contribution by various researchers for improvement of security in Bluetooth pairing. Section 3 describes the hardware and software interface required for implementing SSP and SSP-APKE-DECE. Section 4 discusses the working and security analysis of SSP. Section 5 is all about the proposed protocol SSP-APKE-DECE followed by performance analysis of SSP-APKE-DECE in Section 6. Finally, the paper ends with the conclusion in Section 7. 2. Literature review on SSP 2.1. Attacks on SSP Bluetooth is the wireless media where conversation between two or more devices in the piconet can be captured and altered

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

by the intruder. Due to the weakness in Bluetooth various attacks were discovered. This section discusses various attacks during the pairing process in Bluetooth enabled devices. The first MITM attack called as “Off-Line PIN crunching attack” on Bluetooth 1.0 was devised by Jakobsson and Wetzel. They could capture the link key by passive eavesdropping the key establishment protocol [28]. Off-Line PIN crunching attack worked up to Bluetooth 2.0 + EDR (Enhanced Data Rate). In 2001, Kugler and Dennis worked over “Off-Line PIN crunching attack” and manipulated clock setting. Hence, managed to force the connecting Bluetooth devices to follow same channel sequence with a different clock. Thus succeeded the attack during pairing procedure [29]. Another attack devised by Levi et al. implemented the reflection attack challenging the challenge-response authentication system by impersonating the legitimate devices [30]. In no time, Shaked and Wool could retrieve the PIN by observing the pairing process [42]. Researchers also focused on the strength of E0 algorithm (Key Stream generator). The first attack on E0 algorithm was made by Fluhrer and Lucks. They could retrieve the cipher key from the given amount of known keystream. In addition, they proved that the security level of E0 is between 73–84 bits [18]. Later in 2002, by capturing the Bluetooth stream cipher, Bagini et al. managed to retrieve the 128-bit secret key [9]. Similarly, Lu and Vaudenay designed the decoding algorithm of E0 and applied it to retrieve the closest code word for any liner code [31]. These attacked worked until the release of Bluetooth 2.1 + EDR. The analysis on Bluetooth weakness made by Aissi et al. in 2004 made them propose the use of Elliptic Curve for Diffie Hellman key exchange mechanism over the standard Diffie-Hellman, so as to secure the link key [1]. Also, suggested increasing the size of 4-digit PIN to 6-digit PIN. Bluetooth version 2.1 + EDR released in 2007 brought revolutionary changes in the Bluetooth security [11]. It introduced user-friendly Secure Simple Pairing (SSP) protocol with the countermeasures to protect against Man-In-The-Middle (MITM). SSP utilized Elliptic Curve technique for Diffie Hellman (DH) Key exchange protocol. In spite of enhancing security, MITM attacks are still possible. The major contribution on Bluetooth attack and its countermeasures was done by Haataja. During his Ph.D. tenure, he devised many attacks on Bluetooth SSP 2.1 + EDR. The attacks are BT-SSP-Printer-attack SSP [23], BT-SSP-OOB-MITM attack [24], BT-SSP-HS/HFMITM attack and BT-Nino-MITM attack on Bluetooth-3.0 [26]. In all these attacks, he revealed the fact that attacker captures the Input-Output capability of the devices and alters it and forces the legitimate devices to adopt the Just Work association mode, which is one of the unsafe association models. Andrew, Lindell, and Barnickel mounted the attack in passkey entry mode and succeeded in breaking the password [7,8]. The proposed protocol is therefore implemented in Numeric Comparison mode, as passkey entry mode and Just Work association mode is found to be insecure [7,8,26]. SSP continued until version 5.0 which is the recent version of Bluetooth [16]. It incorporates NIST approved P-192 or P-256 bit elliptic curve in Bluetooth devices. SSP is computationally secure against the passive attacker. Nonetheless, still, attacks are possible on SSP. From the comprehensive study, it is observed that active MITM succeeds in capturing the IO capabilities during the first phase of pairing and forces the devices to adopt the association model as per his wish. Consequently, still, there is a scope of enhancing the security of Bluetooth pairing protocol. Therefore, through this paper a new pairing protocol is proposed wherein to overcome the flaw, the transmission of IO capability is delayed. Unlike SSP, the encrypted IO capability is transmitted after the ECDH key exchange.

171

2.2. Review on various proposed pairing protocol for bluetooth Researchers contributed towards the enhancement of pairing protocol since 1999. Several methods have been introduced that targeted on ensuring the security of Bluetooth devices during pairing. This section presents a comprehensive review of various Bluetooth pairing protocol proposed by researchers to minimize the MITM attacks and connection time as well. The first enhanced pairing protocol was devised by Gehrmann and Nyberg in 2001. They addressed the problem identified by Jakobsson and Wetzel [28] and developed countermeasures. Also, introduced the new anonymity mode for improved privacy to avoid location tracking. In addition, they devised a method to verify the authenticity of the link key after it is established. For this, they suggested to compute cryptographic hash values of secret key and display them to the users to compare and verify over the human link [20]. Later, Welsh et al. worked to decrease the connection time so as to improve the Bluetooth performance. Authors suggested modifications in the Bluetooth 1.0 [10] specification. They advised to decrease the random backoff delay in INQUIRY SCAN, suggested for single frequency train rather than two during INQUIRY and combining the two. In addition, proved that these schemes drastically improves the connection setup by decreasing the number of failures due to collisions [41]. Another proposed protocol worked for the key agreement protocol using elliptic curve. Hence, made the security of keys independent of the PIN (Personal Identification Number). The improved pairing protocol uses an extra secure communication channel with Elliptic Curve Cryptography, uses a temporary random address and manual authentication protocols. The pairing protocol could manage to avoid location tracking by the intruder that uses the temporary random address. In addition, to avoid the repetitive authentication attempts the author used blacklist [43]. Alam and Khan proposed an improved SSP by encrypting the commitment value computed by the slave with the ECDH key computed during the key exchange process. Also suggested ‘Vernam Cipher’ encryption algorithm instead of DES or AES algorithm [2]. Xu and Yu designed and implemented LUC based key agreement protocol. In addition, they introduced Bluetooth address and piconet clock in authentication part-1 of Stage-III of SSP. They successfully proved that the improved protocol can resist impersonation, replay attack and MITM attack [44]. Mishra improved the security of SSP by encrypting the public key of connecting devices using the known cryptographic function and then transmitting to the other party. Also suggested using a trusted Certificate Authority (CA) to verify the digital signature, keys, and certificates [33]. Diallo et al. applied double encryption to authenticate the slave and proved that the protocols avert passive and active attacks [17]. In [3] through his Ph.D. thesis managed to improve the security of SSP by authenticating the connecting devices twice. For second time authentication, it uses the HMACSHA256 algorithm. Here all the slaves in the piconet are registered by assigning a password and public keys to the connecting devices in the piconet. It updated the database of master whenever the new public keys are computed for the already registered devices. Thus averts the active and passive attacks. The runtime complexity is found to be linear [3]. Albahar et al. in his research proposed three different solutions to improve the security of Bluetooth devices and hence to reduce the MITM attacks. Continuing the research on enhancing the security, a countermeasure for MITM on Just Work association model was proposed. Researchers used fixed value computed on the basis of received IO capabilities in Stage-I. Further, a random number consisting of fixed value is exchanged and matched. If the values match, then the connection will be successfully established. The approach considerably improved the security of the JW model [4].

172

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Next, Albahar proposed another completely different pairing structure from the existing SSP. Their pairing structure is based on the virtual channel that integrated extra channel during pairing. Thus enhanced the security by double checking the values exchanged between the connecting devices and averted the risk of MITM attack [5]. To counteract the MITM, Albahar proposed a novel and improved pairing method based on stenography. The secret key was generated from the received stego cover image which embedded message and public key. He submitted his Ph.D. in 2017 thesis by providing the three solutions to counteract MITM as mentioned above [6]. Moon et al. used signal intervals, totally different approach to enhance SSP. The nonce that is to be transmitted is first converted to the corresponding signal interval. Further quantization level used to interpret physical signal intervals is renewed in every step of nonce transmission. The difficult part of this approach is to determine the quantization level by the eavesdropper. In addition, the approach removed the exchange of passkeys. Hence devices are secure even if it uses fixed PIN [34]. Gajbhiye et al. proposed the modified SSP-DECE protocol, a modified version of SSP. The modified protocol considers the issue of capturing IO capability and therefore delays the transmission of IO capability until required in Stage-IV. From the broad review on various counteract MITM measures, it is found that other than the idea of Elliptic Curve cryptography, none of the methods were adopted in Bluetooth specification 2.1 to 5.0 [11–16]. Despite all these countermeasures, still, MITM attacks were discovered ranging from data and identity theft to capturing and altering the information. 3. Experimental setup for simulating SSP and SSP-APKE-DECE To develop and simulate SSP and SSP-APKE-DECE protocol followings are utilized: 3.1. Hardware interface Ubuntu 14.04 in 32-bit mode with hardware configuration as Intel® CoreTM 2 DUO CPU, T6570@ 2.10 GHz having 36 bits physical and 48 bits virtual address size, cache size 2048 KB and RAM 2.00 GB. 3.2. Software interface The open source network simulator NS-2.29 with ucbt-0.9.9.20 Bluetooth protocol stack patch has been used to simulate the protocols. The SAGEMATH software is used to create the modules of SSP and SSP-APKE-DECE, in the form of various ∗ .sage files. The ∗ .sage files are then plugged-in in ucbt-0.9.9.20 Bluetooth protocol stack implemented in ‘C’, so as to include the protocol SSP and proposed protocol SSP-APKE-DECE. Thus, ucbt-0.9.9.20 is extended to handle the transmissions between two pairing devices. PyGTK JGP JAVA GNU plot GUI Ver. 0.1.2 is used for GUI design and for representing the flow pictorially and XML is used for configuring ∗ .sage files. The protocol employs AES-CCM [35] encryption–authentication algorithm for encryption-decryption as it provides authenticity and confidentiality both, the P-256 elliptic curve for ECDH public key exchange, one-way hash function HMAC-SHA256 [37] for computing commitments, confirmation values, and link key. The analysis of SSP and SSP-APKE-DECE for two pairing devices in Numeric Comparison is carried out with respect to the computation and communication time of following parameters: the public key, the secret key, the nonce, the commitment value, confirmation value, the link key, and the encryption key. Notations used in equations are described in Table 1. All the equations in the manuscript

are represented with respect to Master (Alice, Initiating device) and the suffix ‘A’ or ‘B’ represents Alice (Master/Initiating Device) or Bob (Slave/Responding Device) respectively. A Module of StageIII of SSP-APKE-DECE of is shown in Appendix A. 4. Analysis of simple pairing protocol (SSP) 4.1. Working of SSP To make pairing process secure and user-friendly, SIG introduced SSP in version 2.1 + EDR (Enhanced Data Rate) [11] with four new association modes as per Input-Output (IO) capability of devices. For the devices having keyboards and displays, Numeric Comparison mode is used. To continue the pairing, the users have to confirm by comparing the two six-digit numbers displayed on devices. Out-of-Band mode brought the concept of Near Field Communication (NFC) and provides a reliable channel for connection. The Numeric comparison can also be used as Out-of-Band (OOB) channel. The passkey entry mode is applicable if one of the connecting devices have the only keyboard, but no display or if both the connecting devices have the keyboard but no output. Finally yet importantly, Just Work mode is applicable for the situation when at least one of the devices neither have keyboard nor display. The user does not have any option other than to welcome the connection. Depending upon the version of Bluetooth, SSP uses NISTRecommended approved P-192 or P-256 bit elliptic curve [36] for ECDH public-private key exchange. It operates in six different stages in sequence [16]: 4.1.1. Stage-I: IO capability exchange After the inquiry scan, the Bluetooth enabled devices knows the device address of each other. To adopt the right association mode as per IO capability of the devices they exchange their IO capability as illustrated in Fig. 1. Herein, the connecting devices may downgrade their security level to match the security level of the pairing device. 4.1.2. Stage-II: public key exchange Both the devices then compute ECDH shared secret key after the exchange of public keys and is illustrated in Fig. 1. The computation of the public key and the secret key by Alice is demonstrated through Eqs. (4.1) and (4.2) respectively.

P KA = P rA × ECGenarator

(4.1)

SKAB = P256 (P rA , P KB )

(4.2)

4.1.3. Stage-III: authentication part-1 Depending upon the association model selected in Stage-I, this stage of authentication has three different protocol for Numeric Comparison, Passkey Entry, and Just Work mode. Our work simulates the protocol for Numeric comparison mode, as this is the safest mode with the highest security level for exchanging sensitive information and is illustrated in Fig. 1. After the exchange of public keys, slave (Responding device) commits to the public keys and its nonce as illustrated in Eq. (4.3) where all arguments are concatenated to generate the hash code except the ECDH the shared secret key (SKAB ) generated in Stage-II. Master (Initiating device) and slave then exchange their nonce respectively. Master then verifies the slave’s commit by computing commits and verifying it with the received one. The last step of verification is done with the 6-digit checksums displayed on both the connecting devices and is shown in Eq. (4.4) that computes digest by concatenating all the arguments using the HMACSHA256 hash function.

CB = HMAC2SHA56 (SKAB , P KB , P KA , NB )

(4.3)

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

173

Table 1 Description of notations used in equations and figures. S.No.

Parameter

Description

1.

ECGenerator

Base point of selected elliptic curve

2.

SK

ECDH Secret Key.

3.

Pr

Private key.

4. 5

PK P256

Public key. DH key exchange Algorithm.

6.

C

Commitment value computed for integrity of information.

7.

V

Checksums displayed on both the connecting devices.

8.

N

Nonce of master

9.

HMACSHA256

HMAC-SHA256 is the one way cryptographic function that results a code of 256 bit.

10. 11.

IO BD

Input Output capability of devices Bluetooth address of devices

12.

CV

Confirmation Value used to substantiate exchanged information.

13.

LK

Session/Link key computed individually by master and slave.

14.

CC

Cipher Code computes using AES-CCM algorithm

15. 16.

EncryptIO DecryptIO

Encrypted Input-Output Capability Decrypted Input-Output Capability

17.

MAC

Message Authentication Code.

18. 19.

SK1 SK2

ECDH Shared secret key computed in Stage-II. ECDH Shared secret key computed in Stage-VI.

20.

PT

Message that is to be encrypted

21.

CT

Encrypted message

VA = HMACSHA256 (SKAB , P KA , P KB , NA , NB )

(4.4)

4.1.4. Stage-IV: authentication part-2 Stage-IV is another stage of authentication where master and slave both verifies that all previous public values have been exchanged successfully. The computation of confirmation values and its verification is illustrated in Eq. (4.5) with the key as SKAB (ECDH secret key). Rest of all the parameters are concatenated to generate the message digest. The sequence of exchanges between master and slave is represented through Fig. 2.

CVA = HMACSHA256 (SKAB , NA , NB , IOA , BDA , BDB )

(4.5)

4.1.5. Stage-V: link key calculation Lastly, the devices then generate link key using the HMACSHA256 hash function from the ECDH secret key, nonces, and Bluetooth address. The generation of link key is represented by

Eq. (4.6) with the key as SKAB (ECDH secret key). The message is computed by concatenating all the remaining parameters. The Stage-V of SSP is illustrated through a sequence diagram in Fig. 2.

LKAB = HMACSHA256 (SKAB , NA , NB , BDA , BDB )

(4.6)

4.1.6. Stage-VI: LMP authentication and encryption This stage is optional and when chosen it uses link key, nonce and MAC (Message Authentication Code) to encode plain text to cipher text and is represented through Eqs. (4.7) to (4.10) with the key as LKAB (Link key). The SSP uses Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) mode, which supports authentication and encryption as well. The authentication and encryption process is represented in Fig. 2 with the key as LKAB (Link key). The python code of the process is shown in the Appendix A.

CCA = AE SCC M (LKAB , NA2 )

(4.7)

174

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Fig. 1. Stage-I, Stage-II, and Stage-III of SSP.

Fig. 2. Stage-IV, Stage-V, and Stage-VI of SSP.

C TA = AE SCC M (P TA )

(4.8)

MACA = AE SCC M (C TA )

(4.9)

P TA = AE SCC M (C TA )

(4.10)

4.2. Security analysis of SSP The detailed study of SSP is discussed within the context of pairing time complexity, its strength, and its weakness.

4.2.1. A. Run time complexity The experimental result of the successful execution of SSP is represented in Table 2. It is observed that ECDH public key exchange utilizes 75% of the pairing time for computing public key and further transmitting it. The computation of ECDH key exchange is based on the number of multiplication M in the algorithm for the N-bit shared secret key. Thus, the execution time to compute the public keys and the secret key is determined as the function of M and N i.e f(M,N). Furthermore, as per the NIST report, HMAC-SHA256 computes one-way hash code after performing 24-rounds of compression on each 1088-bits block size [37]. In SSP it is applied ten times in three stages. Thus, it performs 24∗ 10 rounds of compression.

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

175

Table 2 Pairing time of SSP. S. No

Secure Simple Parameters type

Size in bits (for P-256)

1. Bluetooth device Address (BD) 48 2. ECDH Public key (PK) 256 3. ECDH Secret Key (SK) 256 4. Random Number-Nonce (N) 128 5. Commitment value (C) 256 6. Validation Value (V) 256 7. Confirmation Value (CV) 256 8. Verification value (Verify CV) 256 9. Link Key (LK) 256 10. RandNum for encryption (N) 128 11. EncryptedMess (CT) 256 Total computation and communication time (s) Pairing time (s)

Likewise, SSP uses AES-CCM, an authenticated encryption algorithm that provides authentication and confidentiality of the message. As per NIST report computation capacity of AES-CCM is assessed as the number of cycles on a 128-bit block size [35]. As claimed by Crypto++ benchmarks, AES CCM requires 28.6 cycles per byte on an Intel Core 2 processor in 32-bit mode [39]. As reported, AES in CCM mode needs 60 clock cycles on each block of 128-bit. So, for a -bit message, it needs (60∗ /128) clock cycles. From the Table 2 pairing time of SSP is 1.578773405335530 s. As observed 75% of the pairing time is used by the public key exchange. Hence, ignoring communication time of all the other parameters, communication time complexity of SSP is represented as [P-bit size of the finite field of elliptic curve]. Overall, the runtime complexity of SSP is evaluated from computation and communication time. In general, the runtime complexity is represented as [2 × f(M,N) for ECDH key exchange + 24∗ 10 rounds of compression for hash function + (60∗ /128) clock cycles for AES CCM] + [P-bit size of the finite field of elliptic curve]. 4.2.2. B. Strength In case if the protocol is aborted and reinitiated, it may be executed without a new public-private key pair. However, for each initialization of SSP protocol, new nonce guarantee the freshness of link key. These nonce let us defend the replay attack. In addition, commitment and confirmation values computed in authentication Stage-I and authentication Stage-II averts the Man-In-The-Middle (MITM) to modify these values later. The attacker may attempt to match the 6-digit display values on both the connecting devices. Regardless of attack, the sequence of transmission of nonce and commitments values between master and slave foil the attack. Means, if the intruder first commits to his nonce with the master, then he should be fast enough to commit to the nonce that it will use with the slave before seeing the nonce from the slave. Likewise, If the intruder first commits to his nonce with the slave, then he should be able to commit to the nonce that it will use with the master before seeing the nonce from the master. In each of these situations, the attacker must commit to at least the second of its nonce before knowing the second nonce from the legitimate device. Padgette et al. in 2017 reported that if active MITM was not present during the initial phase of pairing, then the link key is computationally secure from the passive eavesdropper. However, the numeric comparison model is still insecure from an active MITM attack [38]. Nevertheless, as per the current scenario, highend configuration systems with large memory and fast computation are available. The computation power of systems may break the link key even if it is considered computationally secure. Thus for an intruder using a high-end system, computing the Discrete

Computation time (in s)

Communication time (in s)

– 0.40326620733655 0.08154943415 0.0 0 01862887 0.0 0 0 06557773543 0.0 0 0 052767362134 0.0 0 0235037127558 0.0 0 02250360 07464 0.0 0 02120 0 0416392 0.0 0 01771764 0.0 0 02626051 0.486232130335528 1.578773405335530

0.026223 0.813018 – 0.065815 0.041115142 – 0.061025133 – – 0.085345 1.0925412750 0 0 0

logarithm from the captured elliptic curve public keys will then not be a hard problem. 4.2.3. C. Weakness analysis From the analysis of SSP protocol and various attacks on pairing protocol, it is observed that the active MITM could capture the IO capability and public keys of devices during the initial phase of pairing. The reason behind this is: • These IO capabilities are transmitted without encrypting through the insecure channel. Moreover, IO capability is required from Stage-III onwards, yet it is exchanged in Stage-I. • Devices are not authenticated at its initial phase of pairing. Instead, authentication starts from Stage-III (Authentication Stage-I). Before this stage, the IO capability and public keys are exchanged in plaintext. • The devices do not commit for public keys. It is because of these loopholes that MITM gets the chance to capture the public keys and IO capability and insert its own IO capability and public keys. Thus, forces the devices to adopt the Just Work association model, which is unsafe especially for sensitive and confidential information. The successful active MITM impersonating the legitimate devices and acquiring the Link key is shown through Fig. 3. 5. Proposed protocol: Secure Simple Pairing with authenticated public key exchange and delayed-encrypted capability exchange (SSP-APKE-DECE) A Bluetooth enabled devices periodically enter into page scan state. Communication between two Bluetooth enabled devices starts when one of the devices listens to page messages that contain Device Access Code (DAC) of the device that it is aiming to page it. Consequently, the devices know the Bluetooth address of each other during page scans. SSP-APKE-DECE is the extension of one of my proposed protocol SSP-DECE [19] wherein in Stage-II and Stage-VI named as ‘ECDH Key Exchange with the commitment to public keys part-1/2 , the public keys are authenticated. For authenticating the public keys, commitment values are computed by both the devices using the SHA256 function. It guarantees detection of tampering the public keys by MITM in this Stage only. SSP-APKE-DECE operates in eight stages with two newly added stages. The pairing procedure proceeds as follows: 5.1. Stage-I: bluetooth address exchange Unlike SSP, in this stage, the pairing devices only exchange their Bluetooth address but not the IO capability.

176

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Fig. 3. Successful active MITM attack [22].

5.2. Stage -II: ECDH key exchange with commitment to public keys part-1 Following Stage-I, initiating and responding device then generates the nonce and calculate public key. Calculation of public keys is represented through Eq. (5.1) [27]. At first instance, initiating device transmits commitment value to the slave as computed by Eq. (5.2) using SHA256 cryptography technique. Next, responder and initiator exchange their nonce and public key. Slave verifies master’s commitment and is demonstrated through Eq. (5.2). On successful verification, slave commits to its nonce and public keys and sends to master. Master then verifies the commitment value. If verification succeeds, subsequently both the connecting devices compute ECDH shared secret key of size 256-bits as is given by Eq. (5.3). Thus, this stage performs data integrity by committing public keys that use the SHA256 hash algorithm to compute the hash. The ECDH key exchange phase is shown through the sequence diagram in Fig. 4.

P KA = P rA × ECGenarator

(5.1)

CA = SH A256 (BDA , BDB , P KA , NA1 )

(5.2)

SKAB = P256 (P rA , P KB )

(5.3)

5.3. Stage-III: encrypted capability exchange In continuation to Stage-II, connecting devices first encrypt IO capability using AES-CCM authentication and encryption algorithm. For this, master and slave generate the fresh nonce, uses ECDH key to encrypt the IO capability and generates Message Authentication Code (MAC) for authentication of devices. Here, the computing parameters are shown with respect to the responding device. The key

used for encrypting the IO capability is SKAB , ECDH Secret key generated in Stage-II. Initially, responding device sends encrypted IO, nonce, and MAC to initiating device as computed by Eqs. (5.4) to (5.6). The ECDH shared secret key (SKAB ) is used encrypt the IO capability. If the information is received without alteration then master could decode the IO as in Eq. (5.7) and verify the device through received MAC code. Further, the initiating device follows the same process and authenticates the slave. The process continues only and only if authentication is successful at both the ends. The exchange of IO capability is represented in Fig. 5. The use of the AES-CCM algorithm is shown in Appendix A.

CCB = AE SCC M (SKAB , NB2 )

(5.4)

E ncryptIOB = AE SCC M (IOB )

(5.5)

MACB = AE SCC M (EncryptIOB )

(5.6)

DE cryptIOB = AE SCC M (E ncryptIOB )

(5.7)

At this stage, depending upon the IO capability the Bluetooth devices support, the right association model is adopted. The devices having high-security level downgrades its security level to the security level of connecting device. However, our protocol simulates for Numeric Comparison mode with keyboard and display on both the connecting devices. 5.4. Stage-IV: authentication part-3 and Stage-V: authentication part-4 Stage-IV (Authentication part-3) and Stage-V (Authentication part-4) of SSP-APKE-DECE is exactly similar to Stage-III (Authenti-

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

177

Fig. 4. ECDH Public key Exchange with commitments to Public Key.

Fig. 5. Stage-III, IO capability exchange using AES in CCM mode.

cation part-1) and Stage-IV (Authentication part-2) of SSP. Computing parameters i.e Commitments values and checksums of StageIV are represented through Eqs. (5.8) and (5.9) respectively using SKAB1 ECDH secret key generated in Stage-II. The exchange between Alice and nonce during Stage-IV and Stage-V is illustrated in Figs. 6 and 7 respectively. Confirmation values computed by initiating device using HMACSHA256 with SKAB1 ECDH secret key, nonce generated until this stage, IO capability and Bluetooth device address as arguments of the function is illustrated in Eq. (5.10). Other than secret key rest all parameters are concatenated to compute the 256 hash code The same equation is used by responding device to verify and hence authenticate the master device.

CB2 = HMACSHA256 (SKAB1 , P KB , P KA , NB3 )

(5.8)

VB = HMACSHA256 (SKAB1 , P KA , P KB , NA3 , NB3 )

(5.9)

CVA = HMACSHA256 (SKAB1 , NA1 , NA2 , NA3 , NB1 , NB2 , NB3 , IOA , BDA , BDB )

(5.10)

5.5. Stage-VI: ECDH key exchange with commitment to public keys part-2 This stage is same as Stage-II of SSP-APKE-DECE with the newly generated nonce and public keys and the shared secret key as illustrated through Eqs. (5.1) to (5.3).

5.6. Stage VII: link key calculation From all the publicly exchanged values like the nonce, the Bluetooth addresses and the two shared secret key computed from Stage-II and Stage-VI, master and slave generate the link/Session key. The computation of the Link key is represented in Eq. (5.11) by concatenating SKAB1 (ECDH Secret key generated in Stage-II) and SKAB2 (ECDH Secret key generated in Stage-VI) and using it as key. All the other parameters are concatenated to generate the message and compute its hash code. LKA = HMACSHA256 (SKAB1 , SKAB2 , NA1 , NA2 , NA3 , NB1 , NB2 , NB3 , BDA , BDB )

(5.11)

178

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Fig. 6. Stage-IV Authentication part-3 in SSP-APKE-DECE.

Fig. 7. Stage-V Authentication part-4 in SSP-APKE-DECE.

5.7. Stage-VIII: LMP authentication and encryption Unlike SSP, this Stage is mandatory and uses the AES-CCM authentication-encryption algorithm for authenticating the devices and encrypting and decrypting the message. Master or slave, either a claimant or a verifier, generate the nonce, compute the Cipher Code and cipher-text using Link key as key given in Eqs. (5.13) and (5.14). In addition to this claimant or the verifier also compute MAC code for authenticating the device as in Eq. (5.15). On receiving the encrypted data, the verifier decrypts the message as in Eq. (5.16) and authenticates the claimant by verifying the MAC code. If the verifier fails to decrypt or fails to verify, then it indicates the presence of MITM or error in transmission. Here, the calculation is shown with respect to the initiating device. The diagrammatic representation of Stage-VII and Stage-VIII are shown through Fig. 8.

CCA = AE SCC M (LKAB , NA5 )

(5.13)

C TA = AE SCC M (P TA )

(5.14)

MACA = AE SCC M (C TA )

(5.15)

P TA = AE SCC M (C TA )

(5.16)

6. Performance analysis of SSP-APKE-DECE Security analysis of SSP-APKE-DECE is carried out for two devices, with respect to context discussed herein: A. Runtime complexity: Simulation results show that the runtime of SSP-APKE-DECE for the 256-bit elliptic curve is 3.117608740261700 sec. Moreover, it is observed from Table 3, that communication time and computation time for the public key are very exhaustive as it captures 80% of the total pairing time. In general, the runtime complexity of the ECDH key exchange is the same as SSP i.e. it is the function of M and N where M is the number of multiplication in algorithm and N is the shared secret key. Similarly, SSP-APKE-DECE employs AES in CCM mode twice: one for IO encryption in Stage-III and one for message encryption in Stage-VIII. Thus, it requires 6∗ (60∗ /128) i.e total 2.81∗  clock cycles for a -bit message. Moreover, it employs HMACSHA256 [37] one-way hash function eighteen times from StageII to Stage-VII. Performance of HMAC-SHA256 is measured in

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

179

Fig. 8. Stage-VII (Link Key Calculation) and Stage-VIII (LMP Authentication and Encryption) of SSP-APKE-DECE. Table 3 Pairing time of SSP-APKE-DECE. S.No

Secure Simple with Delayed-Encrypted exchange Parameters type

1. Bluetooth device Address 2. Commitment value (Stage-II) 3. Verification Value (Stage-II) 4. Nonce (Stage-II) 5. ECDH Public key (Stage II & VI) 6. ECDH Secret Key (Stage II & VI) 7. Nonce (Stage-3) 8. Encrypted/ Decrypted IO (Stage-III) 9. Nonce (Stage-IV) 10. Commitment value (Stage-IV) 11. Validation Value (Stage-IV) 12. Confirmation Value (Stage-V) 13. Verification value (Stage-V) 14. Link Key (Stage-VII) 15. Nonce (Stage-VIII) 16. Encrypted Message (Stage-VIII) Total computation and communication time Pairing time (s)

Size in bits (for P-256)

Computation time (in s)

Communication time (in s)

48 256 256 128 256 (Each Stage) 256 (Each Stage) 128 256 128 256 256 256 256 256 128 128 (s)

– 0.0 0 0124237017557 0.0 0 0123126128658 0.0 0 016708880 0 0 0 0 0.806432224676100 0.16311766830 0 0 0 0 0.0 0 015728770 0 0 0 0 0.0 0 0173727610 0 0 0 0.0 0 017618980 0 0 0 0 0.0 0 0 056656836420 0.0 0 0 050965361234 0.0 0 0135137007546 0.0 0 0136137017587 0.0 0 0112010406595 0.0 0 018727860 0 0 0 0 0.0 0 0124237017557 0.971149735261697 3.117608740261700

0.026225 0.061325035 – 0.0673130 1.6253560 – 0.058876887 0.068876887 0.068624 0.032035052 – 0.060225144 – – 0.077602 0.026225 2.146459005

terms of the number of compressions. For one use, HMAC performs 24 rounds of compression on 1088-bit block size. Thus in total 24∗ 18 rounds of compression are performed. The overall complexity of the proposed protocol is evaluated as COMPUTATION TIME [4 × f(N,M) + 2.81∗  clock cycles + 24 × 18 rounds of compression] plus COMMUNICATION TIME [P-bit (P256 bit) size of the finite field of elliptic curve]. B. Strength analysis: Security analysis of the proposed protocol SSP-APKE-DECE is done based on strength of authentication, encryption, and MITM attack. I. In SSP-APKE-DECE, the first stage of authentication and commitment to the public keys is performed in Stage-II for ECDH public key exchange. If commitment fails at this stage, the protocol is killed and starts with the fresh nonce. Whereas SSP does not commit for public keys and in SSP commitments are performed in Stage-IV after the public key exchange. The DH key exchange algorithm with the commitment of public keys is shown in Fig. 4, Stage-II of Section 5.

II. Unlike SSP, the proposed protocol delays the transmission of IO capability. It transmits the encrypted IO capability in Stage-III, after the public key exchange. The ECDH key is used to encrypt the IO capability and AES-CCM algorithm for authenticated encryption as well. If intruder tampers the encrypted IO capability during transmission, the receiver will not be able to decrypt the IO capability. Even if intruder captures the encrypted IO capability, to decrypt he has to compute the secret key from the publically exchanged public keys of the legitimate devices. To compute private key of each device, the attacker must have the public key of that device. Once the attacker is able to generate the private key of both the devices, he could compute the ECDH shared secret key. But, for the P-256 elliptic curve, finding the Discrete Logarithm of the elliptic curve from the public key is still the hard problem [32]. Pollard Rho attack has been employed to compute the private key from the public key, one of the best technique until the date for computing

180

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Fig. 9. Start time of Pollard Rho Attack on ECDH elliptic Curve at 10.28 pm of 16th Jul’18.

the Discrete Logarithm for Elliptic Curve [40]. The computation started on 16th Jul’18 as shown in Fig. 9 and forcibly stopped on 17th Jul’18 at 10.23 a.m. as shown in Fig. 10. The system could not compute one private key even after 12 hours of computation time. The failure of computing the link key for the P-256 elliptic curve is shown in Table 4. III. The protocol again utilizes the AES-CCM authenticatedencryption algorithm for encrypting messages in Stage-VIII. In all, protocol performs six stages of authentication. For each authentication, new nonce are generated for commitments. The freshness of nonce guarantees fresh link key. In this way, prevents from modifying these nonce in future and thereby prevents replay attacks. Moreover, in an event of an attack to impersonate the legitimate devices, in each of the authentication stages, an attacker has to manage and follow the sequence of exchange of nonce and commitments values. The active attacker fails to impersonate the legitimate devices. Thus, SSP-APKE-DECE protocol thwarts the attack. IV. For an attacker to retrieve the link, he must know all the nonce that has been exchanged previously, must have the Bluetooth address of the pairing devices, and must be able to compute the two ECDH shared secret key. To compute these secret keys, he must have the public keys of master and slave, exchanged as plaintext in Stage-II and Stage-VI. For an attacker to synchronize with the legitimate devices,

capturing of public keys and nonce is the difficult process and thus SSP-APKE-DECE protocol ruins the attack. V. The Pollard’s Rho attack [40] is applied to retrieve the ECDH secret key and hence the link key for two different elliptic curve domain parameters. The attack succeeded for small domain parameters but went out of memory for the P-256 elliptic curve. The experimental results for two different parameters of elliptic curve E: y2 = x3 + ax + b over the prime field Fp of order n is shown in Table 4. along with retrieving time. √ The runtime complexity of Pollard’s Rho attack is O( n) (Pollard, 1975) for the curve of order n. Hence to com√ pute two secret keys the complexity is 4 × (O( n)). Thus to break the link key, the overall time complexity of the √ proposed protocol SSP-APKE-DECE is 4∗ (O ( n) + (15∗ /16) clock cycles to break the IO capability + 24 rounds of compression to finally compute the link key. VI. Finally, yet importantly, the SSP-APKE-DECE stores all the related information of devices after a successful pairing. Later, if the devices wish to pair again, the stored information is matched with the information exchanged during active pairing. Thus reduces the chances of MITM attack as the MITM is now not in the position to forge the IO capability and cannot force the devices to adopt the Just Work association model. The unsuccessful attack for already paired devices is illustrated through sequence diagram in Fig. 11. As shown

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

181

Fig. 10. Progress of Pollard Rho attack on 17th Jul18 at 10.23 a.m. Table 4 Breaking the Link/Session key with Pollard Rho attack. Elliptic Curve ‘E’ for small domain parameters a b p n Crack time

Elliptic curve ‘E’ for P-256 a b p n Crack time

4 20 20 37 Stage-II: Retrieving time of Master’s Private key:0.00273817283962 s Stage-VI: Retrieving time of Master’s Private key:0.00291917475863 s Decrypting time of Master’s IO:−0.0 0 01738171 s Retrieving time of link key:0.0 0 0113010406494 s

Stage-II: Retrieving time of Slave’s Private key:0.00281907485871 s Stage-VI: Retrieving time of Slave’s Private key:0.00282907485962 s Decrypting time of Slave’s IO:−0.0 0 01738171 s

Total crack time = 0.011766141923074 s

115792089210356248762697446949407573530086143415290314195533631308867097853948 41058363725152142129326129780047268409114441015993725554835256314039467401291 115792089210356248762697446949407573530086143415290314195533631308867097853951 115792089210356248762697446949407573529996955224135760342422259061068512044369 Indefinite time.

in Fig. 11 the attacker fails to force the legitimate devices to downgrade the security level to Just Work association mode in Stage-III i.e Encrypted capability Exchange. C. Comparison with existing methods: In Section 2.2, various existing methods are discussed along with its findings. The various proposed methods clearly showed that most of the ap-

proach employed to counteract MITM are somewhat ineffective and has not been incorporated in Bluetooth specification. From the suggestion given by various authors, Bluetooth specification utilized Elliptic Curve cryptography in pairing protocol. Integrating SSP-APKE-DECE method into Bluetooth specification

182

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

Fig. 11. Unsuccessful attack for already paired devices in SSP-APKE-DECE.

would strengthen the security of Bluetooth technology to avert any risk of intrusion.

Appendix-A A. Code for AES-CCM mode in python

7. Conclusion In most of the pairing cases, one of the connecting devices lowers its security level to match the security level of the least powerful device. Majority of the attacks are based on these issues. Therefore, researchers are still working on a protocol that provides high security to sensitive and confidential information. The SSP-APKE-DECE is executed successfully with the enhancement of two more security layers in the existing SSP. The protocol provides perfect forward secrecy, as for each pairing session the new nonce are generated. Consequently, always the fresh session /link key is generated. Moreover, the protocol prevents from reflection attack, as the sequence of exchange of nonce and the commitment values don’t let the attacker synchronize his device with the legitimate devices. Due to the added security layers, the pairing time of SSP-APKEDECE is more as compared to SSP. Nonetheless, enhanced security of the proposed protocol compensates the overhead of increased pairing time.

Conflict of interest The authors declare that they have no conflicts of interest.

def AESCCM(): hdr = b‘To your eyes only’ IOCapPTAlice = b‘1100110 0 01’ # Input-OutpuCapability ECDHKeyA = b‘1516061618089534’ #ECDH SecretKey of Alice NonceAlice = get_random_bytes(16) # Nonce of Alice print ‘\nhdr:’, hdr print ‘\nIOCapPTAlice:’, IOCapPTAlice print ‘\nECDHKeyA:’, ECDHKeyA print ‘\nNonceAlice’, NonceAlice cipher = AES.new(ECDHKeyAB, AES.MODE_CCM, NonceAlice) cipher.update(hdr) MessageFromAlice = NonceAlice, Alice), cipher.digest()

hdr,

cipher.encrypt(IOCapPT

# We assume that the tuple MessageFromAlice is transmitted to the receiver: NonceFromAlice, MessageFromAlice

hdr,

EncryptedIOAlice,

MessAuthCode =

ECDHKeyB = b‘1516061618089534’ cipher = AES.new(ECDHKeyB, AES.MODE_CFB, NonceFromAlice) cipher.update(hdr) DecryptedIOAlice = cipher.decrypt(EncryptedIOAlice)

Supplementary material

try: cipher.verify(MessAuthCode)

Supplementary material associated with this article can be found, in the online version, at doi:10.1016/j.jisa.2018.11.009.

S. Gajbhiye, S. Karmakar and M. Sharma et al. / Journal of Information Security and Applications 44 (2019) 170–183

print “The message is authentic: hdr = %s, pt = %s” % (hdr, DecryptedIOAlice) except ValueError: print “Key incorrect or message corrupted” ###################### References [1] Aissi S, Gehrmann C, Nyberg K. Proposal for enhancing Bluetooth security using an improved pairing mechanism. In: Presented to the Bluetooth architecture review board at the Bluetooth all-hands meeting; 2004. p. 19–23. April 2004. [2] Alam A, Khan I. Security enhancement of pairing and authentication process of Bluetooth. IJCSNS 2010;10(6):243–9. [3] Alhassane D. Enhancement of Bluetooth security authentication using hashbased message authentication code (HMAC) algorithm Ph.D Thesis; 2015. [4] Albahar MA, Haataja K, Toivane P. Towards enhancing just works Bluetooth pairing. Int J Inf Technol Secur 2016;8(4):67–82. [5] Albahar MA, Haataja K, Toivane P. Virtual channel based pairing: a new novel solution structure for Bluetooth pairing. Int J Inf Technol Secur 2016;8(4):51–65. [6] Albahar MA, Olawum O, Haataja K, Toivane P. A novel method for Bluetooth pairing using steganography. Int J Inf Technol Secur 2017;9(1):53–66. [7] Andrew Y, Lindell W. Attacks on the pairing protocol of Bluetooth v2.1. Las Vegas, NV, USA: Blackhat; 2008. p. 1–10. [8] Barnickel J, Wang J, Meyer U. Implementing an attack on Bluetooth 2.1+ secure simple pairing in passkey entry mode. In: 11th international conference on trust, security and privacy in computing and communications (TrustCom). IEEE; 2012. p. 17–24. June 2012. [9] Bagini V, Golic J, Morgari G. Linear cryptanalysis of Bluetooth stream cipher. In: Advances in cryptology – EUROCRYPT, vol. 2332. Springer- Verlag; 2002. p. 238–55. LNCS. [10] BT-SIG, Bluetooth SIG. “Bluetooth specification 1.0”, Bluetooth SIG, technical specification; 1999 http://www.bluetooth.com Browsing Date: 15.01.12. [11] BT-SIG, Bluetooth SIG. “Bluetooth specification 2.1+ EDR”, Bluetooth SIG, technical specification; 2007 http://www.bluetooth.com Browsing Date: 15.01.12. [12] BT-SIG, Bluetooth SIG. “Bluetooth specification 3.0+ HS”, Bluetooth SIG, technical specification; 2009 http://www.bluetooth.com Browsing Date: 15.01.12. [13] BT-SIG, Bluetooth SIG. “Bluetooth specification 4.0”, Bluetooth SIG, technical specification; 2010. June 2010 http://www.bluetooth.com Browsing Date: 15.01.12. [14] BT-SIG, Bluetooth SIG. “Bluetooth specification 4.1”, Bluetooth SIG, technical specification; 2013 http://www.bluetooth.com Browsing Date: 01.01.16. [15] BT-SIG, Bluetooth SIG. “Bluetooth specification 4.2”, Bluetooth SIG, technical specification; 2014 http://www.bluetooth.com Browsing Date: 01.01.16. [16] BT-SIG, Bluetooth SIG. “Bluetooth specification 5.0”, Bluetooth SIG, technical specification; 2016 http://www.bluetooth.com Browsing Date: 05.02.17. [17] Diallo AS, Wajdi A, Olanrewaju RF, Sado F. A secure authentication scheme for Bluetooth connection. In: Proceedings of the 2014 international conference on computer and communication engineering; 2014. p. 60–3. [18] Fluhrer S, Lucks S. Analysis of the E0 encryption system; 2001. Retrieved October 15 2015 from http://theinformatik.uni-mannheim.de/People/Lucks/papers/ e0.ps.gz, a gnu-zipped Postscript file. [19] Gajbhiye S, Karmakar S, Sharma M, Sharma S. Two-party secure connection in Bluetooth-enabled devices. Inf Secur J 2018;27(1):43–56.

183

[20] Gehrmann C, Nyberg K. Enhancements to Bluetooth baseband security. In: Proceedings of Nordsec 2001, Copenhagen, Denmark; November 2001. [21] Haataja K. Bluetooth network vulnerability to Disclosure. Integrity and Denial-of-Service attacks. Finnish data processing week 2005 (FDPW’05), vol. 17; 2005. [22] Hyppönen K, Haataja K. Nino man-in-the-middle attack on Bluetooth secure simple pairing. In: Proceedings of the IEEE third international conference in central Asia on internet. The next generation of mobile, wireless and optical communications networks (ICI’2007), Tashkent, Uzbekistan; 2007. [23] Haataja K, Toivanen P. Practical man-in-the-middle attacks against Bluetooth secure simple pairing. In: 4th International conference on wireless communications, networking and mobile computing; 2008. p. 1–5. [24] Haataja K, Hypponen K. Man-in-the-middle attacks on Bluetooth: a comparative analysis, a novel attack, and countermeasures. ISCCSP 20 08; 20 08. Malta. [25] K. Haataja, New efficient intrusion detection and prevention system for Bluetooth networks. In Proceedings of the 1st international conference on MOBILe Wireless MiddleWARE, Operating Systems, and Applications (MOBILWARE ’08), ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), Brussels, Belgium, Belgium, 16-21. [26] Haataja K, Toivanen P. Two practical man-in-the-middle attacks on Bluetooth secure simple pairing and countermeasures. Wirel Commun IEEE Trans 2010;9(1):384–92. [27] Hankerson D, Menezes A, Vanstone S. Guide to elliptic curve cryptography. New York: Springer-Verlag; 2004. p. 76–86. [28] Jakobsson M, Wetzel S. Security weaknesses in Bluetooth. In: Naccache D, editor. Topics in cryptology, CT-RSA 2001. LNCS, 2020. Berlin, Heidelberg: Springer; 2001. p. 176–91. [29] Kugler, Dennis. Man-In-The-middle attacks on Bluetooth. In: Financial cryptography. In: LNCS, vol. 2742. Berlin/Heidelberg: Springer; 2003. p. 149–61. [30] Levi A, Cetintas E, Aydos M, Koc C, Caglayan M. Relay attacks on Bluetooth authentication and solutions. In: Aykanat C, Dayar T, Korpeoglu I, editors. Computer and information sciences - ISCIS 2004. LNCS, vol. 3280. Berlin,Heidelberg: Springer; 2004. p. 278–88. [31] Lu Yi, Vaudenay S. Faster correlation attack on Bluetooth keystream generator E0. In: Advances in cryptology - CRYPTO’04. In: LNCS, vol. 3152. Springer-Verlag; 2004. p. 407–25. [32] Miller V. Use of elliptic curve in cryptography. In: Advances in cryptology Crypto’85. In: LNCS, vol. 218. Springer-Verlag; 1985. p. 417–26. [33] Mishra P. Analysis of MITM attack in secure simple pairing. J Global Res Comput Sci 2013;4(February(2)):42–5. [34] Moon J, Jung Im Y, Yoo J. Sensors, vol. 17. Basel; 2017. p. 1–16. pii: E752. [35] NIST. FIPS PUB 800-38C: recommendation for block cipher modes of operation: the ccm mode for authentication and confidentiality; May 2004. Browsing Date: 20/12/2015. [36] NIST. FIPS PUB 186-4: digital signal standard; 2013 https://nvlpubs.nist.gov/ nistpubs/FIPS/NIST.FIPS.186-4.pdf Browsing Date: 6/09/14. [37] NIST. FIPS PUB 180-4: secure hash standards; 2015 https://csrc.nist.gov/csrc/ media/publications/fips/180/4/final/documents/fips180- 4- draft- aug2014.pdf Browsing Date: 10/07/18. [38] Padgette J, Bahr J, Batra M, Holtmann M, Smithbey R, Chen L, Scarfone K. Guide to Bluetooth security. NIST Special Publication 800-121 Revision 2, Under Secretary of Commerce for Standards and Technology and Director; 2017. Retrieved December 14 2017, http://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-121r2.pdf. [39] Crypto++ 5.6.0. Benchmarks; 2009 https://www.cryptopp.com/release560. html Browsing Date: 13/05/2015. [40] Pollard JM. A Monte Carlo method for factorization. BIT Numer Math 1975;15(3):331–4. [41] Welsh E, Murphy P, Frantz P. Improving connection times for Bluetooth devices in mobile environments. International conference on fundamentals of electronics, communications and computer sciences (ICFS) Tokyo, Japan; 2002. [42] Shaked Y, Wool A. Cracking the Bluetooth PIN. In: MobiSys ’05: The third international conference on mobile systems, applications, and services,. USENIX Association; 2005. p. 39–50. [43] Singelee D, Preneel B. Improved pairing protocol for Bluetooth. In: Proceedings of the 5th international conference on ad-hoc mobile and wireless networks (ADHOC-NOW ’06); 2006. p. 252–65. [44] Xu G, Yu B. .Security enhanced design of the Bluetooth simple pairing protocol. In: International conference on computer science and network technology; 2011. p. 292–6.