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.

[Drew]

@hungbui:

Very funny ;) I could make sure each user's key is randomly generated, too, though, and my solution would remain in spec.

When used with Android and iOS, is there any method for the nRF51822 to create a bond that isn't vulnerable to MITM?

[Hung Bui]

@Drew: The issue with your approach of having flexibile passkeys is that by spec the passkey (or the TK) must be defined before the 2 devices exchange Mconfirm and Sconfirm to be able to generate the STK. There is actually no exchange of the passkey between 2 devices. So it's not possible for the initiating device to know in advance which passkey will be enterred to be able to generate the Mconfirm accordingly. In short, by spec, phase 2 of bonding only possible if both of the devices know the correct single passkey in advance before the process starts.

• To avoid MITM, there currently only 2 options: passkey and OOB (e.g NFC), some of the Android phones does have NFC. New iPhone has NFC but I think it's restricted to Apple Pay, for now.

[Drew]

@hungwui:

Thank you so much for that explanation. I appreciate it.

Unfortunately, neither Android nor iOS allow the use of NFC for an out-of-band LTK exchange.