Bonding without passkey is possible using nRF51822?

RE: Bonding without passkey is possible using nRF51822?

Mo A — Fri, 13 Jun 2014 05:23:25 GMT

Hi Leo, I am doing this using 'just works' (as mentioned) . I haven't tried with the static key. I too was waiting for a reply to my last comment on the answer below.

RE: Bonding without passkey is possible using nRF51822?

Leo Fu — Thu, 15 May 2014 04:21:20 GMT

Hi Mo, have you confirmed that it is possible or not to add a different static key like 123456 on both sides in bonding?

RE: Bonding without passkey is possible using nRF51822?

Mo A — Tue, 15 Apr 2014 06:36:37 GMT

Thanks again Ulrich,

So it is like the key is entered automatically, there is no provision for the developer to add a different static key like 123456 ( also say the phone app developer that I am using this key)? Am I right?

I wanted to test the 'Bonding' in nRF51822. I used the 'ble_app_hrs' for this. I made the macro SEC_PARAM_BOND as 0 from 1. When I downloaded the code, It was showing in the Master Control Panel and I was able to click 'Bond' there, and It was bonding to the device (I guess) as when I pressed bond next time it was showing bond already exists. Why is this so ? Any other way to test bonding and storing of the peripheral keys? (Here the app nrf utility(in phone) is not able to connect to the device)

Once the bonding is done can my nRF51822 peripheral be connected to the respective Phone/master whenever they comes in range?

(Sorry for asking more questions, A newbie)

RE: Bonding without passkey is possible using nRF51822?

Ulrich Myhre — Mon, 14 Apr 2014 21:08:13 GMT

When using S110, the zeroed key will be entered automatically, but some phone vendors will (erroneously) make you enter a PIN with only zeros, so it's something to just keep in mind.

Bluetooth LE is not very secure when using PIN authentication, because the number of possible codes is pretty low. To reiterate: OOB pairing is quite secure, PIN authentication is slightly more secure than JustWorks, and JustWorks is not very secure at all. The danger is someone sniffing the traffic the moment where the keys are exchanged. If you are able to reduce TX power and hold the devices close to eachother (and/or shield them from other devices), this will be much harder to do.

RE: Bonding without passkey is possible using nRF51822?

Mo A — Mon, 14 Apr 2014 11:34:11 GMT

Thanks a lot Ulrich for the reply,

The passkey you have mentioned '000000' which both devices will agree, Is this automatic or should we provide this in the code in both devices? Where can be the proper place in code" (Or this is done indirectly by setting MITM to 0 and IO capabilities to "BLE_GAP_IO_CAPS_NONE" )
In the second para , you have mentioned "If this is not available, passkey authentication can be made more secure by reducing the transmitting power during the bonding." But I am afraid it is again using a passkey.

regards, Mo

RE: Bonding without passkey is possible using nRF51822?

Ulrich Myhre — Sun, 13 Apr 2014 03:41:43 GMT

Yes, you can bond two devices without inputting any out-of-band keys. In that scenario, both the devices will agree to use a passkey equal to 000000. This can be done if you set the MITM bit to 0 (and preferably IO capabilities to "BLE_GAP_IO_CAPS_NONE" ). This is what the Bluetooth Spec calls "Just Works" as you already found out.

When you pair without man-in-the-middle protection, you risk that someone might be able to listen to the session and save the negotiated keys used for future encryption. This allows an attacker to decrypt future communications easily. It's recommended to use OOB data for pairing if possible. If this is not available, passkey authentication can be made more secure by reducing the transmitting power during the bonding.

There are multiple keys that can be exchanged, and I recommend reading either the Bluetooth Spec or external sources to better understand how these are used. The important ones are the:

Encryption Information, which contains the Long Term Key the central will use together with ediv/rand to encrypt connections in the future.
Identity Information, used for resolvable addresses and privacy.

For some inspiration on how to accomplish this, you could take a look at the Bond Manager provided by the SDK.