Module rubble::security[−][src]

Expand description

The LE Security Manager protocol.

The Security Manager is a mandatory part of BLE and is connected to L2CAP channel 0x0006 when the Link-Layer connection is established.

BLE Security

As is tradition, BLE security is a complexity nightmare. This section hopes to clear up a few things and tries to define terms used throughout the code and specficiation.

Pairing and Bonding

Pairing is the process of generating and exchanging connection-specific keys in order to accomplish an encrypted Link-Layer connection.

This is done by having the Security Managers of the devices talk to each other to perform the key exchange, and then using LL Control PDUs to enable the negotiated encryption parameters.
Bonding means permanently storing the shared keys derived by Pairing in order to reuse them for later connections.

The way keys are stored is inherently platform- and application-dependent, we just have to provide interfaces to export and import key sets.

Most times, when talking about pairing, the bonding part is implied. If it were not, you would constantly have to re-pair devices when reconnecting them.

LE Legacy Pairing vs. LE Secure Connections

Bluetooth’s security track record is an actual record in that it is so atrociously bad that this protocol should have never seen the light of the day. Alas, here we are.

LE security is generally able to utilize AES-128-CCM for encryption, which isn’t broken by itself (unlike the “export-grade” encryption used by earlier Bluetooth versions). However, the way the AES key is exchanged differs between LE Legacy Pairing and LE Secure Connections pairing, which hugely impacts actual security.

LE Legacy Pairing

For BLE 4.0 and 4.1, only the LE Legacy Pairing (as it is now known as) was available. Like every awfully designed protocol, they’ve rolled their own crypto and use their own key exchange procedure (with the usual catastrophic consequences). First, a shared 128-bit Temporary Key (TK) is obtained, which is then used to generate the 128-bit Short-Term Key (STK) that is used to initially encrypt the connection while other keys are exchanged.

The STK is generated from the TK by mixing in random values from master (Mrand) and slave (Srand), which are exchanged in plain text. If a passive eavesdropper manages to obtain TK, they only need to listen for the Mrand and Srand value and can then compute the STK and decrypt the connection.

There are 3 methods of determining the TK:

“Just Works”: TK=0
Passkey Entry: A 6-digit number is displayed on one device and input on the other device. The number is directly used as the TK (after zero-padding it to 128 bits).
Out-of-Band (OOB): The 128-bit TK is provided by an external mechanism (eg. NFC).

“Just Works” obviously is broken without any effort other than listening for the exchanged Mrand and Srand values.

The Passkey Entry method only allows 1000000 different TKs (equivalent to using 20-bit keys) and does not do any key derivation. This makes it trivial to brute-force the TK by running the STK derivation up to a million times.

The only way to perform LE Legacy Pairing with meaningful protection against passive eavesdropping is by using a secure Out-of-Band channel for agreeing on the TK.

LE Secure Connections pairing

Added with BLE 4.2, this finally uses established cryptography to do everything. It uses ECDH on the P-256 curve (aka “secp256r1” or “prime256v1”).

Using ECDH immediately protects against passive eavesdropping. MITM-protection works similarly to what LE Legacy Pairing attempted to do, but is actually relevant here since the base key exchange isn’t broken to begin with. There are several user confirmation processes that can offer MITM-protection:

“Just Works”: No MITM-protection. Uses the Numeric Comparison protocol internally, with automatic confirmation.
Numeric Comparison: Both devices display a 6-digit confirmation value and the user is required to compare them and confirm on each device if they’re equal.
Passkey Entry: Either a generated passkey is displayed on one device and input on the other, or the user inputs the same passkey into both devices.
Out-of-Band (OOB): An Out-of-Band mechanism is used to exchange random nonces and confirm values. The mechanism has to be secure against MITM.

LE Privacy

BLE devices are normally extremely easy to track. Since many people use BLE devices, and device addresses are device-unique, they can be very easily used to identify and track people just by recording BLE advertisements.

The LE privacy feature can prevent this by changing the device address over time. Bonded devices can still resolve this address by using a shared Identity Resolving Key (IRK).

This feature is not related to encryption or authentication of connections.