1 / 75

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

Bluetooth v2.1 – A New Security Infrastructure and New Vulnerabilities. Andrew Lindell Aladdin Knowledge Systems and Bar-Ilan University, Israel. Talk Outline. Background Offline versus online dictionary attacks Secure password-based authentication Bluetooth v2.0

uriel
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  44. Not good enough anymore!

  45. BMW Got it Right

  46. 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!

  47. 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)?

  48. 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)

More Related