Multiple security passkeys for bonding/peering to a single BLE peripheral from multiple BLE centrals.

[ccasebeer]

Currently I have a 52840 peripheral running peer manager. We bond/peer with it using a passkey system from an mobile phone central. It works great.

SDK is 1702 nrf5.

What I'd like to know, is it possible to have a second bond/peer relationship establish from a second central device using a different passkey from the first one. Basically allow the peer_manager to accept two different passkeys for elevation to peered/bonding status. Either central would then have access to characteristics which are behind secured access attributes (including DFU)

Basically have two centrals....each with their own passkey allowing peered/bonded status.  Basically I'm after a two passkey system. Is this possible? Can peer_manager be setup to accept two different passkeys?

[Kenneth]

Hello,

Normally the passkey is generated on the fly, meaning that each time you bond with passkey, then one peer show the passkey on a display, and the other peer have a keyboard where you input the passkey.

If you don't have a display on your device, you can use what is called static passkey, where you set the passkey to a pre-defined value. This can be done when you are idle, before starting to advertise. The api you use to set a pre-defined passkey is for instance:

    // static passkey
    ble_opt_t ble_opt;
    uint8_t passkey[] = "123456";

    ble_opt.gap_opt.passkey.p_passkey = passkey;
    err_code = sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &ble_opt);
    APP_ERROR_CHECK(err_code);

Best regards,
Kenneth

[ccasebeer]

Yep. This is what we are currently doing.

Can I accept two different static passkeys at the same time? Where either one is valid.

Or can you think of some scheme which would allow this? Or something totally different which would allow two authentications?

Well, it looks like the way is to:

https://devzone.nordicsemi.com/f/nordic-q-a/80693/ble-man-in-the-middle-protection-multiple-passkeys/334905#334905

call

sd_ble_opt_set() with the Nth key upon the Nth failed connection/callback()

Upon a security elevation run through all key sets before finally declaring failed connection? Does that sound reasonable?

I suppose I can do this. It'd be cool to have the peer-manger just check an array of keys,  but I suppose this is exactly what I'm programming in.

Think that'll work?

Can I ask just for curiosity sake what the next most secure method of doing this is versus static passkeys?

Our peripheral has no communication out of any kind, so we went with a default passkey which the user can then set/store through a write only characteristic out of factory default.

[Kenneth]

ccasebeer said:

Can I accept two different static passkeys at the same time? Where either one is valid.

Each time you use the wrong passkey the link will be terminated due to MIC failure. So I think it will be difficult to effectively use many passkeys, but if you control both sides of the link (e.g. both are nRF devices), you might be able to re-connect several times testing various passkeys without the user noticing, but this will not be possible with for instance android/ios/windows etc, in that case the user will prompted each time to input passkey.

Kenneth

[ccasebeer]

Darn. This sounds like this won't work. I was hopeful.

Any other ideas?

Another scheme I'm missing besides static passkey?

[Kenneth]

I am not sure what the goal is, if you are making a proprietary application, then you may have some handshaking/encryption on the application layer instead of the link layer. 

Best regards,
Kenneth

[ccasebeer]

Application is IOS/Android with a passkey settable by user and then used.

Then a hard coded passkey that only a second nrf52840 based device knows.

We can certainly elevate to app level handshake. We might have too.

Thoughts?