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?