RE: Secure BLE pairing - is it possible?

Hung Bui — Fri, 17 Jun 2016 10:08:30 GMT

@Tim: as I mentioned, BluetoothSIG is the best to answer questions regarding the spec. Please send requests and questions in their portal. You can join the SIG as an adopted member, it's free.

RE: Secure BLE pairing - is it possible?

Tim — Thu, 16 Jun 2016 11:40:16 GMT

This still doesn't really answer the question of why they kept a protocol that is so fatally flawed (and could be fixed!). A fixed pin could be secure if the protocol were different.

RE: Secure BLE pairing - is it possible?

Hung Bui — Thu, 16 Jun 2016 10:56:48 GMT

Hi Tim,

Your questions should be best fit for BluetoothSIG, as we are not the sole party who define BLE spec.

Here is my opinion on your questions:

As in the article your cited, the risk happens only when you use same passkey for multiple pairing processes. This is not suggested by the spec as it mentioned that the passkey should be randomly generated when pairing.

I understand that in many applications, the devices don't have IO capability, and have to use static passkey such as a number printed on the device/package. If the attacker has physical access to the device, then this pairing can be compare to the same level as JustWork.

If the attacker doesn't have physical access to the device to get the passkey he need to do brute force or eavesdrop the pairing process of the authenticated device.

For brute force, since 4.2, we introduced the repeated request-confirm for each bit of the passkey, the attacker need to try 2^20 times, and each time he uses the wrong bit the pairing process will be terminated. So you can implement a check on the device to refuse pairing after let's say 3 consecutive fails for example.

For eavesdropping, since we use ECDH keys, the public and private pair are required, and I don't think it's easy to inject the attacker Public key based on a recorded session of the pairing process earlier.

Anyway, using static passkey is not recommended and for sure will reduce the authentication level of the process.

2.You can implement another encrypting layer on application, but this require you to find a secure way to exchange the keys, or hardcode and secure the keys on both peers. We don't have an example/suggestion for this.

3.We can't comment on specifications that are not adopted.