Bluetooth v 2 1 A New Security

Bluetooth v 2. 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 v 2. 0 • Bluetooth v 2. 1 security infrastructure – The four pairing modes: description and basic analysis • Password leakage from BT 2. 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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

BACKGROUND Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

Online vs Offline Dictionary Attacks • Password length – In order to prevent online dictionary attacks, short hard-toguess 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 impossible for humans to remember such long truly-random passwords! Andrew Lindell Aladdin Knowledge Systems

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… Andrew Lindell Aladdin Knowledge Systems

Bluetooth v 2. 0 • Pairing in Bluetooth 2. 0 (legacy pairing) – The initialization key Kinit is generated by applying a cryptographic function E 22 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 Andrew Lindell Aladdin Knowledge Systems

Bluetooth v 2. 0 • The offline dictionary attack on the pairing protocol of BT 2. 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 Andrew Lindell Aladdin Knowledge Systems

Bluetooth v 2. 1 (BT 2. 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 Andrew Lindell Aladdin Knowledge Systems

BLUETOOTH V 2. 1 SECURITY INFRASTRUCTURE Andrew Lindell Aladdin Knowledge Systems

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

BT 2. 1 Secure Simple Pairing • BT 2. 1 pairing modes (continued) 3. Out of band: used when an additional channel exists (e. g. , if a physical connection can be used for pairing) 4. 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 BT 2. 1, we describe the protocol in detail! – And analyze it… Andrew Lindell Aladdin Knowledge Systems

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) Andrew Lindell Aladdin Knowledge Systems

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! Andrew Lindell Aladdin Knowledge Systems

Diffie-Hellman Key Exchange n. Let’s pair n. PKb Device A n. DHkey = a PKb A Device B n. PKa n. DHkey = b PKa B n. DHkey = a PKb = a b G = b a G = b PKa = DHkey A B Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

MITM Attacks on Plain DH n. Let’s pair n. PKc Device A n. DHkey = a PKc A n. PKb n. PKa n. PKc n. DHkey = c PKa A n. DHkey = c PKb B Device B n. DHkey = b PKc B Important: the attacker must “inject” its own key in the exchange Andrew Lindell Aladdin Knowledge Systems

Public-Key Exchange • Conclusion – Plain Diffie-Hellman key exchange is not secure against man -in-the-middle attacks • BT 2. 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 Andrew Lindell Aladdin Knowledge Systems

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) Andrew Lindell Aladdin Knowledge Systems

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 publickey 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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

Passkey Entry Protocol Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

PASSWORD LEAKAGE Andrew Lindell Aladdin Knowledge Systems

Passkey Re-Use • Another look at the passkey entry protocol • In one execution, an eavesdropper obtains: – PKa, PKb – Ca 1, …, Ca 20 – Cb 1, …, Cb 20 – Na 1, …, Na 20 – Nb 1, …, Nb 20 Andrew Lindell Aladdin Knowledge Systems

Passkey Re-Use • Recall – Cai = f 1(PKa, PKb, Nai, rai) – Cbi = f 1(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 = f 1(Pka, PKb, Nai, 0) • If it equals Cai, then it knows that rai = 0 • Else, it knows that rai = 1 Andrew Lindell Aladdin Knowledge Systems

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-SHA 256 operation per bit of the passkey (so a 128 -bit random passkey is derived with only 128 HMAC-SHA 256 operations) • Conclusion: fixed passkeys cannot be used Andrew Lindell Aladdin Knowledge Systems

Fixed or One-Time Passkeys • What does the specification say? Core V 2. 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? Andrew Lindell Aladdin Knowledge Systems

Fixed or One-Time Passkeys • What does the specification say? Core V 2. 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”. Andrew Lindell Aladdin Knowledge Systems

Common Bluetooth Wisdom Always a good idea Shown to not be too effective Not relevant any more: requires reeducation Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

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

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 Andrew Lindell Aladdin Knowledge Systems

APPLICATIONS OF ATTACKS Andrew Lindell Aladdin Knowledge Systems

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-themiddle connection when the boss carries out the pairing again Andrew Lindell Aladdin Knowledge Systems

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 Andrew Lindell Aladdin Knowledge Systems

Bluetooth Hands-Free Car Kits Andrew Lindell Aladdin Knowledge Systems

Andrew Lindell Aladdin Knowledge Systems

Not good enough anymore! Andrew Lindell Aladdin Knowledge Systems

BMW Got it Right Andrew Lindell Aladdin Knowledge Systems

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! Andrew Lindell Aladdin Knowledge Systems

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)? Andrew Lindell Aladdin Knowledge Systems

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) Andrew Lindell Aladdin Knowledge Systems

An Attack • Eavesdrop on a pairing between a PC and PDA where user enters password – Extract the passkey as we have shown • Immediately force a repairing (as in Wool-Shaked) • Assume that the same passkey is entered by the user again and either – Pair with the target device yourself, or – Play MITM to eavesdrop on the legitimate connection • Main observation – Users are likely to enter the same password here (assume malfunction and not attack) Andrew Lindell Aladdin Knowledge Systems

Wireless Smartcards • Save smartcard readers or necessity to plug smartcard into USB • Background – Smartcards have the property that cryptographic keys are never released – If used on an unprotected machine or accessed by an attacker, then the damage is limited – But, some private information is often stored, and the ability to sign/decrypt can be very damaging • Smartcards are password-protected to prevent such access if a smartcard is stolen or lost Andrew Lindell Aladdin Knowledge Systems

Wireless Smartcards • Smartcard protection – Passwords prevent access by attackers who steal a smartcard (or “borrow” it for a few minutes) – Prudent users should never physically connect their smartcard into a machine that is not trusted • The danger with wireless smartcards – One cannot rely on the lack of physical connection – The smartcard password can be learned by eavesdropping on the wireless connection • At best, smartcard logon is via challenge/response which is vulnerable to offline dictionary attacks Andrew Lindell Aladdin Knowledge Systems

Bluetooth Smartcards • If the smartcard password is also the pairing password then this is a disaster • If not, how is pairing protected? – Smartcards have no interface for numerical comparison – In principle, out-of-band communication is possible by using a traditional reader or USB • But this partially defeats the purpose… • Conclusion – Bluetooth pairing security cannot be relied upon here Andrew Lindell Aladdin Knowledge Systems

Blackberry Smartcard Reader Andrew Lindell Aladdin Knowledge Systems

Blackberry Smartcard Reader • Note 1: there is no attack on the Blackberry smartcard reader (it uses BT 2. 0) – Rather, we point to a potential attack on a BT 2. 1 version of this type of product • Note 2: the danger is regarding access to the smartcard – Access to the Blackberry itself should be protected because to pair, the user needs to enter a password to the device • This requires social engineering… Andrew Lindell Aladdin Knowledge Systems

BT 2. 1 Smartcard Reader • What will Blackberry do in BT 2. 1? – They could use out-of-band communication and force pairing to use a physical connection the first time • This is quite annoying for users… – They could use a secure password protocol on top of the Bluetooth one (and use their own driver to enable it) Andrew Lindell Aladdin Knowledge Systems

OTHER SECURITY ISSUES Andrew Lindell Aladdin Knowledge Systems

Other Issues • MITM attacks based on – Support of multiple authentication methods – Backward compatibility • NFC security Andrew Lindell Aladdin Knowledge Systems

MITM Attacks • The first step of the pairing protocol Andrew Lindell Aladdin Knowledge Systems

Andrew Lindell Aladdin Knowledge Systems

MITM Attacks • The IO capabilities determine which pairing protocol is used – Numerical comparison – Just works – Out of band – Passkey entry – Legacy pairing Andrew Lindell Aladdin Knowledge Systems

MITM Attacks • Note: if a PC or cellphone is to be compatible with devices that use just works (because they have no human interface and no NFC), then MITM protection must be set to not required – Otherwise, pairing won’t work • Likewise, all devices must be willing to use legacy pairing in order to preserve backward compatibility Andrew Lindell Aladdin Knowledge Systems

MITM Attacks • An attacker can intercept and modify the IO_capability_req and IO_capability_res messages and modify them – Make devices understand that they are interacting with a device that uses a weaker type of pairing • Legacy pairing • Just works* * Already observed in: J. Suomalainen, J. Valkonen and N. Asokan. Security Associations in Personal Networks: A Comparative Analysis. In ESAS 2007, pages 43 -57 Andrew Lindell Aladdin Knowledge Systems

Preventing the Attacks • Solution 1: the device is not willing to work in “just works” mode – This won’t help with legacy pairing (backward compatibility is a must) – This also limits use so is unlikely to be adopted • Solution 2: the user must distinguish the cases – The user manually inputs what the type of the other device is (PC, PDA, cellphone etc. ) – The user manually states if the other device is BT 2. 1 or BT 2. 0 – Not very user friendly, but at least feasible… Andrew Lindell Aladdin Knowledge Systems

NFC Security • NFC = Near Field Communication – This works as an Out-of-Band communication channel – Device A reads OOB communication using NFC • In many cases, this will be a tag that is provided with the device (e. g. , in the manual/box) – Security here holds as long as the NFC tag is kept secret • Otherwise, anyone can pair with the device • Is this a reasonable assumption? – I guess that we’ll wait and see… Andrew Lindell Aladdin Knowledge Systems

SUGGESTIONS FOR SECURING BLUETOOTH V 2. 1 Andrew Lindell Aladdin Knowledge Systems

Fixing the Protocol • It is trivial to prevent eavesdropping attacks – Encrypt the authentication phase 1 messages with the DHkey derived from the exchanged public keys – An eavesdropper will now not learn the Cai, Cbi, Nai, Nbi values – This has been used in some wireless standards • This gives a clear security model – Full MITM protection when one-time random passwords are used – Protection against eavesdropping attackers when fixed random passwords are used Andrew Lindell Aladdin Knowledge Systems

Fixing the Protocol (better) • Use a secure password protocol, guaranteeing: – Security against MITM and eavesdropping attacks – A single password guess for every MITM interaction • Even if a short password is used, this suffices for preventing the attack using delays etc. • Such protocols exist (not patented) – Example: • J. Katz, R. Ostrovsky and M. Yung. Efficient Password. Authenticated Key Exchange Using Human-Memorable Passwords. In EUROCRYPT 2001, pages 475 -494. http: //www. cs. umd. edu/~jkatz/papers/password. pdf Andrew Lindell Aladdin Knowledge Systems

Manufacturers • Only use one-time random passwords generated by the device (or numerical comparison/out-ofband) • Make sure that the user interface prevents the use of legacy pairing or “just works” unless required – Preferably, don’t allow “just works” at all, unless absolutely necessary Andrew Lindell Aladdin Knowledge Systems

Manufacturers • How realistic is this? – User: choose the type of device you are pairing with • Must assume what method the other device will use… • Cannot ask the user what pairing procedure to use – User: enter the Bluetooth version supported by other device • Hmmm, I’m not sure that this will go over well at all • Will this be implemented? Andrew Lindell Aladdin Knowledge Systems

End Users • Check the pairing procedure of a device before you buy it – Make sure it follows recommended procedures – If it has no human interface for entering and displaying, make sure that it uses NFC (and not “just works”) • If the pairing procedure doesn’t work at first, or the mode works in an unexpected way – be suspicious! Andrew Lindell Aladdin Knowledge Systems

For All • Speak to the BT SIG – Work to change the passkey-entry protocol to one that is secure • It is far too easy to get an insecure implementation today • Devices without interfaces are “in trouble” • Important! – This would also enable devices to refuse “just works” because all devices can at least work with a fixed password Andrew Lindell Aladdin Knowledge Systems

Final Words • There are many potential pitfalls with the new pairing procedure – Passkey entry is very problematic • Completely broken for fixed passkeys • Highly problematic for user-entered passkeys – Devices with no human interface for entering/displaying data can only use NFC (may be too expensive for headsets) – A MITM attacker can cause devices to pair based on “just works” or to use legacy pairing • This can be prevented but comes at a price! • Manufacturers can do a good job (but it’s very difficult) Andrew Lindell Aladdin Knowledge Systems

Legal Notice © Copyright 2008 Aladdin Knowledge Systems Ltd. All rights reserved. Aladdin, Aladdin Knowledge Systems, the Aladdin Knowledge Systems logo, e. Token and e. Safe are trademarks of Aladdin Knowledge Systems Ltd. covered by patents www. aladdin. com/patents; other patents pending. You may not copy, reproduce (or the like), or use in any other way whatsoever, whether directly or indirectly, any of the materials represented and/or disclosed herein without the express written consent of Aladdin. Some of the information contained herein may be proprietary information of Aladdin or third parties and all text, images, graphics, trademarks, service marks, logos, trade names and other materials which are part of this communication are subject to intellectual property rights of Aladdin or third parties. The information herein is provided “as is” without any warranty, express or implied (by statute or otherwise), of any kind whatsoever. Aladdin does not undertake any obligation to update the information herein and it does not assume responsibility for errors or omissions. Andrew Lindell Aladdin Knowledge Systems