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? 

[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