Using write characteristic as passkey

[thoric_fish]

I noticed that passkey entry for BLE pairing is usually implemented by the device operating system outside the nrf_connect app. Is it possible to do passkey entry inside a mobile application's own GUI and have the mobile app software send the passkey back to the Nordic peripheral device? Or can the passkey only be handled by the phone's operating system?

Another possible method I was wondering about was whether it is possible to use a custom characteristic as a passkey? For example, after you pair with a device you have to write the passkey value to a custom characteristic. If the written value is the correct passkey, then other services are now discoverable or the read/write property of other characteristics are now active, etc. A vulnerability with this method could be sniffing if MITM protection was not active. But I also have an implementation question: Is it possible to change a custom characteristic's read or write properties after the characteristic is initialized? 

[Marjeris Romero]

Hi,

You can take a look at the Glucose application example, which implements LESC pairing with passkey entry as specified in the Bluetooth specification (random passkey). You can start the connection process via the nRF Connect app but as you said the passkey entry default UI will pop-up by your phone Bluetooth Settings application (OS).

There is an API for providing the passkey entry, but it does not dismiss the default pop-up for entering the key from the OS. This API have only been tested for older versions of Android so you will need to test it throughly if you want to go down that road:

https://github.com/NordicSemiconductor/Android-BLE-Library/blob/5e0e2f08c309a6de2376d9b8705c83f9e9a80d56/ble/src/main/java/no/nordicsemi/android/ble/BleManager.java#L385

There is a broadcast receiver for pairing requests, which calls onPairingRequestReceived method in line 411 which can do the trick, but it will not dismiss the default dialog pop-up from the OS so your application user may still try to type the passkey there.

I am not really sure why handling the passkey entry through your phone Bluetooth Settings application should be a concern really. The majority of people just rely on this default UI. 

Another possible method I was wondering about was whether it is possible to use a custom characteristic as a passkey? For example, after you pair with a device you have to write the passkey value to a custom characteristic. If the written value is the correct passkey, then other services are now discoverable or the read/write property of other characteristics are now active, etc.

It's possible but it will not be secure. It will be easy for anyone with a sniffer to get your passkey. It will not give you more security than the "Just works" method.

But I also have an implementation question: Is it possible to change a custom characteristic's read or write properties after the characteristic is initialized? 

Not really. You configure the properties when you add the characteristic using sd_ble_gatts_characteristic_add() and can't change them after that as far as I know.

Best regards,

Marjeris

[thoric_fish]

HI Marjeris,

1. Is the random passkey for the LESC pairing in the Glucose application example supposed to be used for security purposes or is it just supposed to be used for initial pairing? I am confused as to whether the random key is related to the long term key exchanged during bonding in LESC pairing. 

2. Can't the random passkey be sniffed like static passkey even with MITM protection? Or does the random passkey change after new device is bonded to it?

3. If the passkey is random like in the Glucose application example, is it suitable for production? Because the random passkey has to be obtained through UART, which normal user probably can't do. The alternative is the manufacturer (us) knowing the device's random passkey and we provide the random passkey to the user so the user can pair with the device.

[Marjeris Romero]

Hi,

1.The 6-digit passkey is use to authenticate the connection before long term key exchange. If the passkey between the two devices does not match the pairing aborts. I recommend reading this post which explains a lot about different LESC connections pairing methods.

2. The passkey is not shared over the air, that's why it's use to protect from MITM attacks. The reason static passkey is not secure is because, as mentioned in the referenced post, it will be easier for an attacker trying to "log in" to your device to succeed in a few attempts since for every failed attempt, it will reveal the next bit that was incorrect. 

3. Both devices need IO capabilities to be able to use passkey entry method.

Best regards,

Marjeris

[thoric_fish]

Marjeris Romero said:

2. The passkey is not shared over the air, that's why it's use to protect from MITM attacks. The reason static passkey is not secure is because, as mentioned in the referenced post, it will be easier for an attacker trying to "log in" to your device to succeed in a few attempts since for every failed attempt, it will reveal the next bit that was incorrect. 

If I understand LESC pairing correctly, both devices should have display capability so for example the user reads the passkey from the peripheral's display and then enters the passkey on the phone. But wouldn't the passkey still be shared over the air between the central and peripheral devices? Or is the passkey entered on the phone not sent back to the peripheral device?

From this post they say "In LESC passkey pairing, the pairing is safe from MITM attacks, as long as the MITM doesn't know the passkey, assuming the passkey is random for every attempt." 

If we use a method where the two devices store a list of one-time use passwords for all future pairing, is that as secure as random passkey? That way if other devices try to sniff the password they will only get the old and expired password.

But this method is not secure against attackers that impersonate the peripheral device. 

https://devzone.nordicsemi.com/f/nordic-q-a/35856/questions-about-lesc-mitm-and-passkey/138216#138216

[Marjeris Romero]

Hi,

See explanation of LESC passkey method in here. The passkey is not sent over the air, but use in Authentication stage 1 in this message sequence chart. You can read the details about how the LESC passkey authentication protocol looks like in the Bluetooth Core specification v5.0 section 3.H.2.3.5.6.3.

thoric_fish said:

If we use a method where the two devices store a list of one-time use passwords for all future pairing, is that as secure as random passkey? That way if other devices try to sniff the password they will only get the old and expired password.

I am not sure I understand what you mean here, but it seems maybe you were confusing LESC passkey entry with legacy passkey entry so maybe you can re-write your question again after taking a look at how the authentication for LESC passkey looks like.

But yes, for MITM protection during the pairing process you need to have some IO capabilities in your device, or have at least a method for displaying the passkey, but it does not need to be through UART.

Maybe if you let us know what kind of device you are planning to make and what are you securities concerns we can help you better to choose the best security level for your application. You can also open a private ticket for this if you prefer to not give this information in public.

Best regards,

Marjeris