Bluetooth v2.1 – A New Security Infrastructure and New Vulnerabilities

1. Bluetooth v2.1 – A New Security Infrastructure and New Vulnerabilities Andrew Lindell Aladdin Knowledge Systems and Bar-Ilan University, Israel

2. Talk Outline • Background • Offline versus online dictionary attacks • Secure password-based authentication • Bluetooth v2.0 • Bluetooth v2.1 security infrastructure • The four pairing modes: description and basic analysis • Password leakage from BT2.1 passkey mode • Passive and adaptive attacks • Man-in-the-middle attacks • Applications of attacks • Devices with fixed passwords • Bluetooth smartcards and smartcard readers • Suggestions for BT SIG, manufacturers and users

3. How Did I Get to This? • Security review of Bluetooth for the purpose of constructing a Bluetooth-based smartcard • The smartcard should connect via Bluetooth only and should act like a regular smartcard • Can we rely on Bluetooth security? • To protect the communication line between the smartcard and PC • To prevent unauthorized access to the smartcard

4. background

5. Online vs Offline Dictionary Attacks • An online dictionary attack • Attacker interacts with the server/device and enters a password guess each time • Easily thwarted: retry counter, exponentially-increasing delays, CAPTCHA

6. Online vs Offline Dictionary Attacks • An offline dictionary attack • Attacker obtains a function of the password (e.g., a hash) • Attacker re-computes the function itself for “all” possible passwords • Examples: encryption with passwords, logon password file

7. Online vs Offline Dictionary Attacks • Password length • In order to prevent online dictionary attacks, short hard-to-guess passwords suffice • In order to prevent offline dictionary attacks, very long random passwords are needed • You need about 8 truly random characters (all types) • It is almost impossiblefor humans to remember such long truly-random passwords!

8. Secure Password Protocols • A password protocol is secure if: • After a successful execution, the authenticating parties share a high-quality cryptographic key that can be used to securely communicate • The best an adversary can do is to carry out an online dictionary attack on the protocol – even if it carries out an active man-in-the-middle attack • This is optimal (an online dictionary attack is always possible) • Secure password protocols exist • Most are covered by patents (here we should rant and rave) • But there are others as well…

9. Bluetooth v2.0 • Pairing in Bluetooth 2.0 (legacy pairing) • The initialization key Kinit is generated by applying a cryptographic function E22 to: • The BD_ADDR • The password and its length • A 128-bit random number that is transmitted in plaintext • Kinit is then used in the next stage (to generate link key) • Given BD_ADDR, the random number and the password, can predict the next stage • This means that an eavesdropper can guess the password and verify the guess – OFFLINE DICTIONARY ATTACK

10. Bluetooth v2.0 • The offline dictionary attack on the pairing protocol of BT2.0 yields • The password • The link key • This is devastating because the link key protects all communication • An attacker who eavesdrops can later derive the link key and decrypt all communication between the parties

11. Bluetooth v2.1 (BT2.1) • Many improvements – we focus only on security • Stated aim • Improve usability and improve security • Provide protection against man-in-the-middle attacks • My expectations that were not met • The password protocol is not secure • At least not in the way that we would expect • The password protocol is very easy to misuse • No explicit warnings are given anywhere • Many important devices are left without protection

12. Bluetooth v2.1 security infrastructure

13. BT2.1 Secure Simple Pairing • BT2.1 pairing has four different modes • Numeric comparison: used for devices that both have displays • User compares a number that appears on both displays and “accepts” if they are equal • Just works: the same as numeric comparison but no comparison is made • Only eavesdropping protection • No MITM protection nor protection against connections

14. BT2.1 Secure Simple Pairing • BT2.1 pairing modes (continued) • Out of band: used when an additional channel exists (e.g., if a physical connection can be used for pairing) • Passkey entry: used in the case that both devices have the same password • In order to properly understand the security provided (and not provided) by BT2.1, we describe the protocol in detail! • And analyze it…

15. Pairing Protocol Structure • All four modes follow the same structure • Phase 1: Public-key exchange • Phase 2: Authentication stage 1 • Phase 3: Authentication stage 2 • Phase 4: Link key calculation • Phase 5: LMP authentication and encryption • Involves generating actual communication keys from the link key (we’ll ignore this stage)

16. Phase 1: Public-Key Exchange • Diffie-Hellman key exchange over Elliptic curves • Parties exchange public keys PKa and PKb • PKa, PKb are obtained by multiplying the generator of an Elliptic curve group by a random element • Denote the generator by G, and the random elements by a and b (PKa= aG; PKb = bG) • Given PKa and b, can compute DHkey = bPKa = baG • Given PKb and a, can compute DHkey =aPKb = abG • The security of Diffie-Hellman over EC groups states that given PKa and PKb • The key DHkey looks completely random!

17. Let’s pair • PKb • PKa • DHkeyA = aPKb • DHkeyB = bPKa Diffie-Hellman Key Exchange Device A Device B • DHkeyA = aPKb = abG = baG = bPKa = DHkeyB

18. Phase 1: Public-Key Exchange • Eavesdropping security • After exchanging PKa and PKb, the parties can derive DHkey • No eavesdropping adversary knows anything about the key • Man-in-the-middle attacks • A MITM adversary can capture PKa sent by Device A and send its own key PKc to Device B • Likewise, it captures PKb sent by Device B and sends its own key PKc to Device A

19. Let’s pair • PKb • PKc • PKc • PKa • DHkeyA = aPKc • DHkeyB = bPKc • DHkeyA = cPKa • DHkeyB = cPKb MITM Attacks on Plain DH Device A Device B Important: the attacker must “inject” its own key in the exchange

20. Public-Key Exchange • Conclusion • Plain Diffie-Hellman key exchange is not secure against man-in-the-middle attacks • BT2.1 pairing protocol strategy • The aim of phase 2 of the pairing protocol is to ensure that both parties received the authentic public keys • This is common to all modes • If device A does not receive PKb or device B does not receive PKa, then they should reject

21. The Just Works Mode • Just works: security of plain Diffie-Hellman • A common mistake! • Claim: plain DH is secure against eavesdropping and MITM is hard to carry out, so it’s enough • Refutation: • In the Bluetooth world, MITM is not so hard • Just advertise yourself as the other device (using its “name” and hope the user chooses you) • MITM attacks are not the only problem, what about rogue connections (e.g., car whisperer)? • As soon as your BD_ADDR is known, anyone can connect to your device (depends on implementation)

22. Phase 2: Authentication 1 • The aim: • Use the numerical comparison, out-of-band communication or passkey to verify that device A received device B’s public-key and vice versa • We will briefly describe the idea behind numerical comparison and out-of-band communication, and will describe the passkey mode in detail • Background – commitments • A commitment to a value is a cryptographic function that provides hiding and binding • Conceptually: the digital analogue of an envelope

23. Numerical Comparison • Devices exchange commitments to the two public keys and random values • The devices display a function of the public keys and random values (6 digits) • Why does this prevent MITM attacks? • A MITM attacker must inject its own public key • In this case, the devices see different public keys and the result of the function determining the 6 digits will be different

24. Out-of-Band Communication • Essentially, use the out-of-band channel to exchange the public keys • Technically it works differently, but this is the general idea • A MITM attack is thwarted because the MITM attacker must inject its own public-key into the key exchange

25. A Digression – NFC • Another mode for pairing uses Near Field Communication • This mode follows the out-of-band protocol; the NFC is used to receive the out-of-band message

26. Passkey Entry Protocol

27. Passkey Entry Protocol - Analysis • The commitments Cai and Cbi are exchanged before Nai and Nbi are revealed • Cai and Cbi are commitments to the public keys and the ith bit of the password • This means that in order for a MITM attacker to pass the ith round, it must guess the ith bit of the password: • The commitment by the honest device reveals nothing about the bit (and doesn’t help the attacker) • The commitment by the attacker binds it to its value so it can’t change it afterwards • A MITM must use its own commitment because it has to put its own public-key inside

28. Passkey Entry Protocol - Analysis • Main observation • In order for a MITM adversary to successfully inject its public-key (as needed for a Diffie-Hellman MITM attack) it must successfully guess the password • Otherwise, the commitments will be incorrect in at least one round of the protocol

29. The Final Phases • Phase 3 – authentication 2 • Verify that the key exchange was successful • Phase 4 – link key calculation • Compute the link key that is used for all later communication • The key is derived from the Diffie-Hellman key exchange

30. Password leakage

31. Passkey Re-Use • Another look at the passkey entry protocol • In one execution, an eavesdropper obtains: • PKa, PKb • Ca1,…,Ca20 • Cb1,…,Cb20 • Na1,…,Na20 • Nb1,…,Nb20

32. Passkey Re-Use • Recall • Cai = f1(PKa,PKb,Nai,rai) • Cbi = f1(PKb,PKa,Nbi,rbi) • An eavesdropper knows PKa, PKb, Cai, Cbi, Nai, Nbi • The only information not known is rai and rbi • But these are just single bits • An eavesdropper can compute c = f1(Pka,PKb,Nai,0) • If it equals Cai, then it knows that rai = 0 • Else, it knows that rai = 1

33. Passkey Re-Use • Result • A passkey can be fully learned immediately after a single execution of the protocol • Passkey length? • The above is true even if a 128-bit truly random passkey is used • The attacker carries out one HMAC-SHA256 operation per bit of the passkey (so a 128-bit random passkey is derived with only 128 HMAC-SHA256 operations) • Conclusion: fixed passkeys cannot be used

34. Fixed or One-Time Passkeys • What does the specification say? Core V2.1 + EDR, volume 2, part H, section 7.2.3 This is fine: the devices force one-time passkeys Will users use different passkeys each time?

35. Fixed or One-Time Passkeys • What does the specification say? Core V2.1 + EDR, volume 3, part C, section 3.2.3 This is ambiguous because the pointer is to legacy pairing (backward compatibility), but that’s the only “hint”.

36. Common Bluetooth Wisdom Always a good idea Shown to not be too effective Not relevant any more: requires re-education

37. An Active Attack • A naïve understanding of the security model • If I use a (fixed) random password to protect pairing with my Bluetooth device, then if an attacker gains physical access to the device, it cannot access its internals • Scenario: • An attacker finds a PDA that is password protected • The Bluetooth channel is also protected with a fixed random password • Note: cannot eavesdrop to learn the password… • Protection should be afforded even if the device is in discoverable mode

38. An Active Attack • Run the following attack (playing Device A) • Guess ra1 = 0 and run the first iteration • If correct, Device B will continue to 2nd iteration • If incorrect, Device B will abort • Main observation: • In either case, attacker learns ra1 • Continue for every iteration • Expected # of interactions: k/2 • Not enough for retry counter or delays

39. Conclusion • Bluetooth pairing cannot be used to secure a device • Fair enough – the specification never stated that this is the aim • But, it’s a pity: this could easily have been achieved by using a secure password protocol • And, its prone to mistakes

40. Applications of attacks

41. Attack Scenarios • A remote keylogger • Sit outside your boss’ physically protected office • Eavesdrop on the pairing, learn the password, and cause a disconnect • Set up a man-in-the-middle connection when the boss carries out the pairing again

42. A Remote Keylogger • But, won’t a random passkey be used each time? • When the pairing is carried out between the PC and keyboard, this is possible • A random passkey must be generated on the PC and then entered into the keyboard • This isn’t as user friendly as “just works” • Will this be implemented by manufacturers? • Your guess is as good as mine • Hopefully, after understanding what can happen if not, there is a better chance that they will enforce the above

43. Bluetooth Hands-Free Car Kits

46. Not good enough anymore!

47. BMW Got it Right

48. An Attack on Password-Protected Hands-Free Car Kits • Sit outside the car while the user pairs • Or force a re-pairing (as shown by Shaked-Wool) • Learn the unique (random) passkey by eavesdropping • Given the passkey, pair directly with the device and set up a car whisperer • This can be prevented by forcing a button-press in order to pair (not just to go into discoverable mode) • But this is not so user-friendly • Furthermore, can be bypassed by forcing a re-pair (then the user will press the button for you) • It’s not always going to work • But it will sometimes, and there’s no reason why it ever should!

49. The Problem • Some devices don’t have the interface for displaying and entering one-time random passkeys, or for carrying out numerical comparison • They could use out-of-band communication • But will manufacturers do this (extra cost)?

50. Another Scenario • Pairing a PC and cellphone or PDA • There is no problem using a one-time random password here • The danger! • Manufacturers may not implement it because it means different modes for users • Sometimes a fixed password is entered (e.g., legacy devices or devices with no human interface) • There is no warning anywhere in the SPEC that user-entered passwords are dangerous (and it is even clearly mentioned as an option for simple pairing)