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.