Question about passkey, bonding, and pairing

RE: Question about passkey, bonding, and pairing

Ulrich Myhre — Mon, 14 Mar 2016 00:28:14 GMT

To clarify my statement again, static passkey is a way to pretend to have a display. It is only relevant in the pairing scenario, and has no effect on connection establishment. There is no mechanism in Bluetooth Low Energy that lets you require a password or pin code to connect to a device, although the passkey is often confused as such. The only type of access control (for connect requests and scan requests) is white-listing, with addresses and/or identity resolving keys (IRK).

Once you are connected, you can start the pairing procedure however. And it is during the pairing procedure that the static passkey may be used - in the very specific scenario mentioned above. If the peer does not support security, or doesn't react to the initiated pairing attempt, it can freely read and write to characteristics that does not require a security mode above "OPEN".

For your last question, I am not 100% sure, but I believe that you do not need to disable the SoftDevice to change the static passkey. You should avoid changing the static passkey while a pairing is in progress though.

RE: Question about passkey, bonding, and pairing

MANGO — Sun, 13 Mar 2016 06:11:49 GMT

Thanks for pointing my misconception.

However, what do you mean by Static passkey is NOT a form for password protection for the devices. ?

Do you mean that, even the passkey value is 123456, any centrals can connect with the peripheral by

typing the wrong passkey value (like 000000)? Or is it about encryption?

Also, I check this link and this is quite similar to question 4.

Implementing similar thing in the link, do I have to call sd_softdevice_disable when changing modes?

RE: Question about passkey, bonding, and pairing

Ulrich Myhre — Sun, 13 Mar 2016 00:06:14 GMT

First things first; you might be aware of this, but I'm writing it because it's a common misconception. The example you are referring to is a static passkey example, used for devices that want to pretend that they have a display by having a static code instead. It offers basically no extra security over normal pairing with BLE_GAP_IO_CAPS_NONE, but it can be used to make sure that you are pairing with the correct device (out of many).

Static passkey is NOT a form for password protection for the devices.

1) Does passkey always require bonding?

It doesn't require bonding specifically, but it does require pairing, since Passkey Exchange is a special step that only may happen during the pairing process. Bonding only adds the exchange of keys, so it only adds an extra step after the pairing procedure has completed successfully.

2) does the passkey has to be numbers (ASCII 0, 0x30 ~ 9, 0x39)?

Yes, the specification mandates this.

3) Will a device be able to connect once the key changes?

The static passkey has nothing to do with connection. It will only occur during a pairing/bonding attempt, and only if at least one side requires MITM, you have display IO caps and the peer has keyboard IO caps. If you meant to ask if it would encrypt successfully, then the answer is yes, but only if the devices bonded. The static passkey is only involved in calculating the session temporal key, which is only used during the very first encryption after pairing. In future pairings, the devices can use the long-term key, but this is only exchanged during bonding. Without bonding, you would have to enter the pin again every time, and no history of the previous pin should remain - because you did not bond.