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

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 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-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

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 v2.0

• •

Pairing in Bluetooth 2.0 (legacy pairing)

– The initialization key

K

init cryptographic function

E

22 is generated by applying a to: • The BD_ADDR • The password and its length • • A 128-bit random number that is transmitted in plaintext

K

init 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 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

Andrew Lindell Aladdin Knowledge Systems

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

Andrew Lindell Aladdin Knowledge Systems

BLUETOOTH V2.1 SECURITY INFRASTRUCTURE

Andrew Lindell Aladdin Knowledge Systems

BT2.1 Secure Simple Pairing

•

BT2.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

BT2.1 Secure Simple Pairing

•

BT2.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 BT2.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

Elliptic curve group by a random element of an • 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

 Let’s pair Device A 

PKb



PKa

Device B 

DHkey A

= a 

PKb



DHkey B

= b 

PKa



DHkey A

= a  PKb = a 

b

 G = b 

a

 G = b  PKa = DHkey

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

 Let’s pair Device A 

PKc



PKa

 

PKb PKc

Device B 

DHkey A

= a 

PKc



DHkey A



DHkey B

= c 

PKa = c



PKb



DHkey B

= b 

PKc

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 •

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

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 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

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 before Nai and Nbi Cai and Cbi are revealed are exchanged

– Cai and Cbi are commitments to the public keys and the i bit of the password th – This means that in order for a MITM attacker to pass the i th round, it must guess the i th 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 – Ca1,…,Ca20 – Cb1,…,Cb20 – Na1,…,Na20 – Nb1,…,Nb20

Andrew Lindell Aladdin Knowledge Systems

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

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?

Andrew Lindell Aladdin Knowledge Systems

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”.

Andrew Lindell Aladdin Knowledge Systems

Common Bluetooth Wisdom

Always a good idea Shown to not be too effective

Not relevant any more: requires re education 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 ra1 = 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 ra1 – 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-the middle 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

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 BT2.0)

– Rather, we point to a potential attack on a BT2.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

BT2.1 Smartcard Reader

•

What will Blackberry do in BT2.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 BT2.1 or BT2.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 V2.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-of band)

•

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, eToken and eSafe 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