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? 

[johnny]

if you need hi security , you can use LESC , this is better~ 

about custom passkey & security  you can see the thread :

https://devzone.nordicsemi.com/f/nordic-q-a/39870/about-ble-security-and-static-pass-key/155751#155751

[thoric_fish]

Hi johnny, 

From what I read in the thread it seems like LESC with static passkey for authorization is not effective. I think using static passkey for user's initial (first-time) pairing with the peripheral device then using bonding & LESC long-term keys is more effective for security. 

[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