Bluetooth v2 1 a new security infrastructure and new vulnerabilities l.jpg
Advertisement
This presentation is the property of its rightful owner.
1 / 75

Bluetooth v2.1 – A New Security Infrastructure and New Vulnerabilities PowerPoint PPT Presentation

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

Related searches for Bluetooth v2.1 – A New Security Infrastructure and New Vulnerabilities

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Bluetooth v2 1 a new security infrastructure and new vulnerabilities l.jpg

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

Andrew Lindell

Aladdin Knowledge Systems

and

Bar-Ilan University, Israel


Talk outline l.jpg

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


How did i get to this l.jpg

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


Background l.jpg

background


Online vs offline dictionary attacks l.jpg

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


Online vs offline dictionary attacks6 l.jpg

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


Online vs offline dictionary attacks7 l.jpg

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!


Secure password protocols l.jpg

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…


Bluetooth v2 0 l.jpg

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


Bluetooth v2 010 l.jpg

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


Bluetooth v2 1 bt2 1 l.jpg

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


Bluetooth v2 1 security infrastructure l.jpg

Bluetooth v2.1 security infrastructure


Bt2 1 secure simple pairing l.jpg

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


Bt2 1 secure simple pairing14 l.jpg

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…


Pairing protocol structure l.jpg

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)


Phase 1 public key exchange l.jpg

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!


Diffie hellman key exchange l.jpg

  • 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


Phase 1 public key exchange18 l.jpg

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


Mitm attacks on plain dh l.jpg

  • 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


Public key exchange l.jpg

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


The just works mode l.jpg

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)


Phase 2 authentication 1 l.jpg

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


Numerical comparison l.jpg

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


Out of band communication l.jpg

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


A digression nfc l.jpg

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


Passkey entry protocol l.jpg

Passkey Entry Protocol


Passkey entry protocol analysis l.jpg

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


Passkey entry protocol analysis28 l.jpg

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


The final phases l.jpg

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


Password leakage l.jpg

Password leakage


Passkey re use l.jpg

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


Passkey re use32 l.jpg

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


Passkey re use33 l.jpg

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


Fixed or one time passkeys l.jpg

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?


Fixed or one time passkeys35 l.jpg

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


Common bluetooth wisdom l.jpg

Common Bluetooth Wisdom

Always a good idea

Shown to not be too effective

Not relevant any more: requires re-education


An active attack l.jpg

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


An active attack38 l.jpg

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


  • Conclusion l.jpg

    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


    Applications of attacks l.jpg

    Applications of attacks


    Attack scenarios l.jpg

    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


    A remote keylogger l.jpg

    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


    Bluetooth hands free car kits l.jpg

    Bluetooth Hands-Free Car Kits


    Slide46 l.jpg

    Not good enough anymore!


    Bmw got it right l.jpg

    BMW Got it Right


    An attack on password protected hands free car kits l.jpg

    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!


    The problem l.jpg

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


    Another scenario l.jpg

    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)


    An attack l.jpg

    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)


    Wireless smartcards l.jpg

    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


    Wireless smartcards53 l.jpg

    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


    Bluetooth smartcards l.jpg

    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


    Blackberry smartcard reader l.jpg

    Blackberry Smartcard Reader


    Blackberry smartcard reader56 l.jpg

    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…


    Bt2 1 smartcard reader l.jpg

    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)


    Other security issues l.jpg

    Other security issues


    Other issues l.jpg

    Other Issues

    • MITM attacks based on

      • Support of multiple authentication methods

      • Backward compatibility

    • NFC security


    Mitm attacks l.jpg

    MITM Attacks

    • The first step of the pairing protocol


    Mitm attacks62 l.jpg

    MITM Attacks

    • The IO capabilities determine which pairing protocol is used

      • Numerical comparison

      • Just works

      • Out of band

      • Passkey entry

      • Legacy pairing


    Mitm attacks63 l.jpg

    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


    Mitm attacks64 l.jpg

    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


    Preventing the attacks l.jpg

    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…


    Nfc security l.jpg

    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…


    Suggestions for securing bluetooth v2 1 l.jpg

    Suggestions for securing bluetooth v2.1


    Fixing the protocol l.jpg

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

      • 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


    Fixing the protocol better l.jpg

    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


    Manufacturers l.jpg

    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


    Manufacturers71 l.jpg

    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?


    End users l.jpg

    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!


    For all l.jpg

    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


    Final words l.jpg

    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)


    Slide75 l.jpg

    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.


  • Login