How can I handle passkey verification myself?

[Drew]

I understand that it is possible to set a static passkey on the nRF51822.

However, what I would like to do is handle the verification of the user-entered passkey myself.

Essentially, I'd like to have multiple passkeys stored and associated with bonding data, so that each passkey can have one bond. Then, if a user loses their central (phone), they can buy a new one and replace the bond by entering their specific passkey.

In this way, users are prevented from stomping on the toes of another user.

Additionally, if a ne'er-do-well finds the user's lost phone, the stored bonding key will have become useless once the user paired with a new device.

[Hung Bui]

@Drew: passkey is used as Short Term Key and by default it's not to be used as the index for stored bonding data (the Long Term Key). I assume that you want to give the flexibility that the user can have one specific passkey and can use it when bonding. The nRF51 will recorgnize the passkey and match it with the bond data base and update bond information if the user has been bonded before.

This is not what supported in the stack or by Bluetooth Spec.

If you want to implement smth like this, I would suggest you to implement one extra layer of verification in the application. Let say after you're connected and bonded, you can send an extra passkey to activate, or to update bonding.

So for example you have the code 1234 and you lost your phone. When you have a new phone, you can connect bond as a new central. However you can send the code 1234 to tell the phone that you want to remove the old bonding information and update it with the current bond.

[Drew]

@hungbui:

Thank you for your prompt response.

If I were to do passkey handling as an additional layer, I would lose MITM protection. Additionally, I would have to write custom UI code for every central for inputting a PIN. This is an extremely inferior way of doing things.

How can I modify the SoftDevice to allow me to handle passkey verification?

[Hung Bui]

@Drew: What I meant was to leave the current (randome) passkey as it is now. And use another passkey for the extra verification layer after you bond.

The softdevice is provided as a pre-compiled stack and is not possible to modify. Moreover, any change that's outsite of the spec, will make the stack non-compliant with Bluetooth spec => not compaible with off the shelf phones.

[Drew]

@hungbui:

My device doesn't have a display or keyboard, so using a random passkey is out of the question. I could set a static passkey and have that distributed to users of each device, but that will cause the user to have to go through multiple passkey entry screens and will likely be jarring and confusing.

Static passkeys are outside of the Bluetooth spec, too: why has Nordic implemented that feature?

[Hung Bui]

Well, it's followed the spec as long as the passkey is randomly generated. So it's up to the application to make sure the key(s) is generated randomly :)

What else you can do is to have your layer of verification before the BLE bonding. So that you would reject any bonding request as long as the correct key hasn't been entered. After that you can use JustWork for bonding. This way the end customer only have to type passcode once.

It's true that the link is not encrypted when you type the passkey, but the BLE Passkey MITM mechanism is also vulnerable to eavesdropping as well.