Update passkey after bonding

RE: Update passkey after bonding

Ulrich Myhre — Sun, 06 Aug 2017 17:44:37 GMT

Create a custom characteristic, and when a write is sent to it, filter out that write event. Do some sanity checking (must be only numbers, in ASCII, 6 characters), then write it to a flash page. Whenever you are about to start to advertise/connect, read the value from flash and call sd_ble_opt_set() just like you do now. To store to flash, you could just erase and write on your own through the flash API, or try to make use of the Pstorage module if you intend to store more data later.

The other points about the security still stands though. A static passkey adds very little security over non-MITM protected connections.

RE: Update passkey after bonding

Hung Bui — Fri, 04 Aug 2017 11:32:38 GMT

Hi Konova,

I assume what you plan to do is to have a default static passkey of "123456" initially. Then after the first bond, you have an option to change it to a new passkey, via a BLE command (a write from the phone to the device for example).

After that the new bond to other centrals should use the new passkey.

I don't see why this shouldn't work (but as Ulrich mentioned, this won't bring much security).

Note that there is nothing stored to flash when you call sd_ble_opt_set(). So you need to store the new passkey it in flash and then every time the chip boot up you should call sd_ble_opt_set() to set the passkey to the stored passkey.

RE: Update passkey after bonding

Corentin — Thu, 03 Aug 2017 22:09:29 GMT

Hello, Thank you for your reply. I have a device with no screen or keyboard so i set a défault static key "123456". My question is how i can changed this passkey after bonding. I create a characteristic to save the new passkey but i don't know how i can update with the new passkey for future bonding.

RE: Update passkey after bonding

Ulrich Myhre — Thu, 03 Aug 2017 20:17:39 GMT

Hi Konova,

I'm having trouble understanding what you really want to do. Why do you want to change the passkey? What are you actually trying to protect against? Depending on this, there are multiple answers to your question.

First of all, once a bond has been established, you should not need the passkey again until the bond is considered lost. If you ever want to connect to only one device, you can simply disallow bonding altogether once a bond exists, and allow the user to delete the bond through a physical operation (e.g. keypress).

Secondly, setting the passkey should be done before connection initiation. This can be solved by generating a random number and storing it in RAM or flash. You can also let the peer write to a special characteristic to change the default static passkey. To permanently store this, you need to store it in flash.

But if your concern is to protect against sniffing, you should not use legacy pairing at all - unless you are using the OOB mode. Best practice is to use LE Secure Connections, and to have some way to exchange data, like keyboard/display/NFC. When you use legacy pairing with "Just Works", the temporal key (used to derive the session key, which encrypts during bonding information exchange) is all zeros. If you use a passkey, it is all zeros except 6 ASCII codes at the end, all between 0-9. That doesn't take much computer power to brute-force, so if someone sniffs the bonding procedure they can trivially sniff future connections too. But if the bonding happens in secret or in a secure way, the long-term key used has high enough entropy to be secure.

To put it simple, adding a passkey makes little difference to a passive sniffer, when using legacy pairing. It does protect against accidental connections, if you make sure that all your devices have different passkeys. Best practice for security is to use LESC.