Part 2: Pairing Problems with BT

In part one of this series, I briefly discussed the fundamental protocols that work in conjunction with Bluetooth, like: LMP, L2CAP, SDP and RFCOMM.  I also touched up on  BD_ADDR, and NAP/UAP/LAP.  I went over other states BT devices within a piconet swap to, and hinted at the amount of enumeration we can glean from just OUI‘s and packets.  In this post, I will go a step further and cover the pairing process involved between devices and note some of the problematic areas associated with them.  By the end of this part of the series, we should start to get a clearer understanding of why Bluetooth has raised so many security concerns.  As mentioned in the first post, this topic was picked as a subject of interest by Pirate Moo readers and friends.

Let’s Make A Perfect Pair…
                                             …Or a Perfect Pear

Many of us pair BT devices together all the time without actually thinking about how the process works.  It seems to be a riddle of questions no one wants to bother with.  Well, we know the BD_ADDR is public and establishes communication with devices and that various protocols work to make this happen, but let’s dive a little deeper because it’s almost summer and I like to swim.  A BD_ADDR master device (utilized by different states) gets what’s called a DAC, or Device Access Code, and a CAC, or Channel Access Code, which works as an identifier used in FHSS (Frequency-Hopping Spread-Spectrum).  It’s also transmitted in clear text (oops).  We can actually analyze the different ADDR states by these varying identifiers as a result.

Anyway, pairing can be trusted or non-trusted.  This means security is partially reliant on the vendor or app being paired.  However, the key exchange used for authentication and encryption between devices uses EO, a 128-bit key stream cipher that is problematic.  E0 uses four shift registers and two internal states that update before bits are extracted, added and used with an algorithm to obtain a sum.  Research into E0 turned up numerous problems and they go as far back as the late 90’s.  Even if you’re not a cryptography expert, we can gather this seems lax.  This is essentially why it is one of BT’s weakest links.

If you create a building without a good foundation, how long will it stand?

Pairing is a three part process where the establishment/initialization of a key is temporarily made for encryption/decryption processes.  The first BT device generates a random number and transmits it to a second device’s BD_ADDR’s random number, which generates this key.  This key then acts as a shared PIN and once it’s generated, a challenge-response is formed.  If both match, you have successful verification.  It also makes you wonder if the process could be intercepted because the second device just spits the same information back.

Let’s not worry about my random thoughts however and let’s focus on link key generation a little here, since it’s an important part of the pairing process.  I don’t want to make this complicated when it doesn’t need to be.  There are actually two key generation process types and the one used depends on whether or not either of the devices are limited by memory resources.  This is most likely for compatibility, but it also seems like it could be an issue.

Why Problematic? 

Did you ask this? If you did awesome (if you didn’t, you’re just going to have to pear with me).  It’s problematic because the key generation process changes and creates an even greater lack of complexity if the resources aren’t there.  If there’s a memory constraint, a key is encrypted with a cipher text and transmitted to the other device to be decrypted/used as a key.  If not though, these devices go through the random number generation process described in the paragraph above.  So we essentially forgo this random number generation if a device lacks resources.  By now, hopefully you’re asking yourself a lot of questions and finding some of these processes slightly awkward.

Security Modes

Bluetooth also has three security modes, creatively labeled 1, 2, and 3.  Mode 1 is simply no security (hmm…why is it called a security mode then?).  Any authentication/encryption can be bypassed.  Basically devices are open and can connect with others.  Mode 2 doesn’t initiate security before establishment on L2CAP, and it allows for different policies with apps (which have different requirements).  A security manager maintains access controls/interfaces with other protocols, and authentication and authorization are supported.  Lucky Mode 3 devices initiate security procedures before links are setup with LMP.  It isn’t aware of application layer security however, even though encryption is supported and a shared secret key link is gained in pairing.

So, looking at the psychological profile of BT mentioned in Part 1 and combining it with our knowledge here, we can tell there are a lot of issues with BT.  It also gives us an understanding of why we see so many devices and attacks it could be hit with.