10

I am investigating the types of security available in Bluetooth Low Energy (BLE) related to GATT. More specifically, what kind of operations are done when using gatttool with different security levels specified (low, med, high)? My understanding is that the Security Manager in BLE supports 4 different security properties:

  • no pairing
  • pairing with an association model that doesn't support man-in-the-middle (MitM) protections (JustWorks)
  • pairing with MitM protections (passkey entry, numeric comparison, OOB)
  • LE Secure Connections pairing.

Are these security properties related to the security levels specified with gatttool or is there some other security feature I missed while reading the Bluetooth Specification?

Edit: I would like to extend my question in order to clarify the issue. How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?

1nc1n3rat0r
  • 103
  • 1
  • 1
  • 5

3 Answers3

10

You are correct but you forget one main threat in BLE communication. Here are the three basic threats :

Man In The Middle (MITM) :

A MITM requires an attacker to have the ability to both monitor and alter or inject messages into a communication channel

Eavesdropping :

Passive Eavesdropping is secretly listening (by using a sniffing device) to the private communication of others without consent

Privacy/Identity tracking :

Since most of the Bluetooth LE advertisement and data packets have the source addresses of the devices that are sending the data, third-party devices could associate these addresses to the identity of a user and track the user by that address

The quotes come from developer.bluetooth.org.

You already mentioned the protections against MitM and Eavesdropping, however there is still the problem of identity tracking.

The protection against identity tracking is to use a MAC address that cannot be linked to the same device through time, i.e. a MAC address that changes (typically every 15 minutes). There are four types of MAC address :

  1. Public address : This address is unencrypted and contains your company unique ID and your device ID. It's unsafe since it does not change through time.
  2. Random static address : This address is random (and known as random thanks to flags inside) and unencrypted. Once it does change, you loose the ability to reconnect with the devices that already knows you, you've got to restart the connection from scratch.
  3. Random resolvable private address : This address can be resolved by the devices that know its IRK, a shared secret between the devices. As for the static random address it changes often but is always resolvable. It's the most common option since it preserves privacy and allow to restore a connection.
  4. Random non-resolvable private address : This address cannot be resolved. The Core Spec doesn't say that much about it and it seems not to be very common. The difference with the static address is that it is not stored since it's a private address (i.e. a device doesn't expect to be able to restore a connection with a private address device).

This is explained in BLE Core Spec 4.2 Vol. 3 Part C 15.1.1 Bluetooth Device Address Types.

Concerning the security level, I don't know gatttool but I will assume it's somehow similar to nRF Connect/Master Control Panel or LightBlue. What you see here is probably the security level associated with each attribute. There are four security levels and they can be different for each attribute :

Mode 1 Level 1 :

No encryption required. The attribute is accessible on a plain-text, non-encrypted connection.

Mode 1 Level 2 :

Unauthenticated encryption required. The connection must be encrypted to access this attribute, but the encryption keys do not need to be authenticated (although they can be).

Mode 1 Level 3 :

Authenticated encryption required. The connection must be encrypted with an authenticated key to access this attribute.

Mode 1 Level 4 :

Authenticated LE Secure Connections pairing with encryption. The connection must be encrypted using the Secure Connection Pairing, which was introduced in Bluetooth LE since version 4.2.

The definitions of modes 1 level 1-3 come from 'Getting Started with Bluetooth Low Energy' by Robert Davidson, Akiba, Carles Cufi, Kevin Townsend.

The device can also be in a mode called Secure Connection Only in which all its services, except the one in Mode 1 Level 1, can only be accessed in Mode 1 Level 4.

Tim
  • 1,853
  • 2
  • 24
  • 36
  • Thanks for all that information. Using your points about the LE Security Modes and Levels, I jumped into the Bluetooth specification to get a little more clarity. From my understanding the requirements for authentication are based on the association model used during pairing and whether the model provides MitM protection: **Mode 1 Level 1** = No pairing; **Mode 1 Level 2** = Pairing using JustWorks (at a minimum); **Mode 1 Level 3** = Pairing using Numeric Comparison, Passkey Entry, or OOB; **Mode 1 Level 4** = Pairing using Secure Connections; – 1nc1n3rat0r Aug 16 '16 at 15:46
  • @1nc1n3rat0r Yes that's it. When you're connected but not paired and you want to access a characteristic requiring more than Mode 1 Level 1, then the pairing is done. – Tim Aug 17 '16 at 04:22
  • @Tim I have curious question, how to read attribute with PERMISSION_READ_ENCRYPTED that was paired with Legacy Pairing ? Here is the question https://stackoverflow.com/questions/65816881/android-ble-reading-attribute-with-permission-read-encrypted – Denis Kotov Jan 21 '21 at 20:41
2

Yes it's correct but you should note that their are still exists security mode,LE security mode 1 and LE security mode 2, which is combined by different security levels. And before Bluetooth 4.2, LE is not secure i.e. you can sniffer the encrypt key at the just beginning of the LE connection.

Guo Xingmin
  • 1,013
  • 1
  • 7
  • 7
  • That's great information. As far as the pairing vulnerability in BLE <4.2, is this issue still present in BLE 4.2 when not using Secure Connections pairing? My understanding is that if Secure Connections pairing is not used, then LE Legacy pairing is used which is vulnerable to sniffing a STK cracking. – 1nc1n3rat0r Aug 16 '16 at 15:48
  • Well the vulnerabilities in BLE < 4.2 are only usable if you sniff the initial pairing process. You can't decrypt subsequent connections, unless you sniffed the initial pairing process. And yes if you use legacy pairing then it's vulnerable. – Emil Aug 16 '16 at 21:09
  • Thanks for the reply. I should rephrase my question to be a little more clear: If I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used? – 1nc1n3rat0r Aug 17 '16 at 00:01
2

How does the 4.2 Bluetooth stack determine whether to use legacy pairing or not? That is to say, if I have a packet capture of two BLE 4.2 devices pairing, how can I tell whether legacy pairing is being used vs pairing that uses ECDH? Does the Secure Connections flag indicate that legacy pairing should not be used or is it just its own mode that ensures FIPS approved algorithms are used?

During the pairing feature exchange stage, if the Secure Connections (SC) flag is set in the Pairing Request and Pairing Response PDUs, then LE SC is used. It indicates that both devices support LE SC and agree to use it.

If LE SC is used, the logs will show "Pairing Public Key" and the "Pairing DHKey Check" PDUs being exchanged. These are specific to LE SC.

Preeti
  • 336
  • 1
  • 7