This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

How can I handle passkey verification myself?

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.

Parents
  • @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: 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.

Reply
  • @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.

Children
No Data
Related