Bluetooth Low Energy encryption and data safety

Question

I need to send some sensitive data over a Bluetooth Low Energy (BLE) data connection between a smartphone (iOS & Android) and an embedded device (CC2540 chip).

Since I don't consider the app-code on the phones to be safe from hacking, I need to rely on BLE safety to get my encrypted package delivered from the server to the device once and once only (I must assume that any second attempt to deliver the package, must be from an attacker).

I have been browsing the net a few days now, to find out if my data is safe, and under which conditions. Unfortunately I haven't been able to come up with a simple answer to my questions.

1. Is my data safe if I pair the phone to the device? - I suppose so, though I understand that the pairing process itself is flawed, so it is theoretically possible for some man-in-the-middle (MITM) to sniff the encryption keys during the pairing process and thus compromise the connection.

2. I need each device to be paired to several phones (but only communicating to one at a time). What's the maximum number of pairings pr. device? - unfortunately I need to pair a rather large number of phones to my device(s).

3. Can I perhaps get the pairing data (Long term keys etc.) from the device and store it on some external memory, to increase this limit.

4. Can I make a safe data connection to the device without pairing, or maybe by re-pairing when I need to do so? - How safe is this procedure with regards to MITM attacks?

I can't seem to find any documents that answer these questions unambiguously. Any ideas or pointers will be most welcome.

Answer 1

here's my two cents:

1. AFAIK, BLE pairing/encryption process is not flawed. There are however three levels of MITM protection available with encryption:

   • None, this uses a known key == 0, so if an eavesdropper catches all your packets in the pairing process, he can follow your encrypted connection.
   • Low MITM protection, this is when you use a user input pass key for pairing, with key < 1.000.000. Here the eavesdropper would only need to try a million keys.
   • High MITM protection, using an out-of-band key. This would give a full 128-bit strength for your encryption, and an eavesdropper would need to know the key to follow the conversation even if catching the whole pairing process. As there is no key-exchange method in BLE (yet, at least), the weakest point here would be the key distribution, but that would be the same problem as when having an additional layer of encryption at the application level.

2. This is implementation dependant. Your device doesn't have to bond, i.e. establish a permanent relationship with the host. If the devices don't bond, there is no state telling about earlier connections (other than exchanged data, but that is application domain, not BLE stack). If the devices are not bonded, they would have to pair again the next time they connect to exchange protected data. If the devices are bonded, the encrypted connection can be continued without app/user interaction, with the same security level as earlier. For one-time-connect devices, bonding doesn't make sense, so you can have a stateless implementation with no restrictions on number of connected devices. For multiple-times-connect, you could also have a stateless implementation, depending on how you distribute/store the key(s) which is then independent of BLE. The availability of the different options here depends on the device/BLE stack implementation you are using, though, but the spec allows all this.

3. If you bond and thus exchange long term keys etc, these can, dependent on the BLE implementation you're building on, be stored however you like.

4. As I said under 2., you can establish a secure (encrypted) connection without bonding. The devices then need to pair again the next time they want to establish a secure connection. If you don't want to/aren't able to pair for some reason, then you can have only plaintext communication.

Answer 2

I'll take a stab at this one.

1) My understanding of the pairing process is the same. If the data were sensitive enough, I would add an independent layer of encryption of my own in my application...

2) For connections, the BLE protocol is limited to one host per device at the same time, even when the connection is not bonded/paired. The only way for a single device to establish a connection to more than one host at the same time is if the device somehow 'pretends' to be multiple devices. Whether or not this can be done will be hardware dependent and it is definitely not one of the standard ways to use a device. Even if you can trick the hardware into doing that, you may run into unavoidable problems such as the occurrence of (nearly) overlapping connection intervals, which may cause you to lose data and eventually even established connections.

Another way for a device to communicate with multiple hosts is to regularly disconnect and let another host establish connection. AFAIK, there is no special protocol support for this technique, so beyond perhaps using directed advertising you may not have much control over which host connects next and when it does so.

See also Section 4.1.2 in Volume 1, Part A of the 'Core_V4.0' bluetooth spec (e.g. from here https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 )

3) Most likely yes, the details will vary by vendor, but with the limitations mentioned above.

4) You can establish a connection without bonding/pairing. That connection will allow communication, but it will be plaintext without any security. AFAICS, the only way to do this right is to use you own data protection at the application level.

Answer 3

I assume the CC2450 device uses the TI stack. A good documentation on the CC2540 stack behavior is in the CC2540 Development Kit User Guide. It's probably the best documentation after the the 4.0 specs from bluetooth.org

1. The 6 digit pin used in the paring process potects against MITM - there's a 30 second window for the PIN entry.

2. The TI stack limits the number of paired devices to 8 or so. It's due to the CPU and encryption performance/resources needed to reestablish connections.

3. Moving encryption keys off the BT device is a risk to security. Overall, key management is the achilles heel of all encryption.

4. You will not have encrypted characteristic read/write without bonding. Refer to 4.6.1 of the TI user guide - it's in line with the Bluetooth 4.0 specs.