How can I handle passkey verification myself?

RE: How can I handle passkey verification myself?

Drew — Fri, 29 May 2015 15:21:34 GMT

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

RE: How can I handle passkey verification myself?

Hung Bui — Fri, 29 May 2015 14:37:40 GMT

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

RE: How can I handle passkey verification myself?

Drew — Thu, 28 May 2015 16:05:35 GMT

@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?

RE: How can I handle passkey verification myself?

Hung Bui — Thu, 28 May 2015 15:54:31 GMT

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.

RE: How can I handle passkey verification myself?

Drew — Thu, 28 May 2015 15:09:53 GMT

@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?

RE: How can I handle passkey verification myself?

Hung Bui — Thu, 28 May 2015 14:46:00 GMT

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

RE: How can I handle passkey verification myself?

Drew — Thu, 28 May 2015 14:40:56 GMT

@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?

RE: How can I handle passkey verification myself?

Hung Bui — Thu, 28 May 2015 14:12:39 GMT

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