Is NFC + static passkey bonding possible?

[Fanis]

Hi, i'm currently working on a low power sensor device based on nrf52832. I want to transfer data only to bonded central devices. Priority is using static passkey, but my hardware can deal with NFC as well. I'm a little confused with all pairing options. Both methods work well separately: predefined PIN (6 ascii numbers) request with sd_ble_opt_set(...) function inside gap_params_init, and NFC pairing with authorisation key (7-16 hex bytes) and whitelist stuff as shown in experimental NFC bonding examples. But when i try to combine them, it all goes crazy. What i'm looking for is preserve PIN authentification, but in case of smartphone with NFC support, perform pairing and bonding by a "touch" without entering digits. As far as i understand SEC_PARAM_OOB macros forces you to make a decision between the two inside peer_manager_init(...). It's also unclear to me that i can use BLE_GAP_AUTH_KEY_TYPE_PASSKEY instead of BLE_GAP_AUTH_KEY_TYPE_OOB when performing err_code = sd_ble_gap_auth_key_reply(...).

[Petter Myhre]

I'm assuming you are making a peripheral device.

When the central sends a pairing request the Peer Manager must know if it is going to tell the central if OOB is supported or not. If OOB is supported by both sides, this is what shall be used, per spec. If OOB isn't supported by either side, IO capabilities will be checked to see if passkey entry can be performed.

You can tell the Peer Manager if OOB is supported or not by using pm_sec_params_set(). This can be called several times to set/unset OOB support.

[Fanis]

Thanks. It seems to work fine to readjust pm_sec_params_set() on the fly (while no connect) without reinitializing all the rest BLE stuff. But what i mentioned now is that actually when i switch for a short period to NFC connection mode with OOB=1, MITM=1 and BOND=1 parameters, it works more like Just works bonding. For example anyone can connect to the nrf peripheral and bond without password over BLE. Only use of NFC this way is only limited by quick popping up of pairing dialog without managing it manually.

[Petter Myhre]

I'm having difficulties understand what you meant by your last comment. Is there still a problem?

[Fanis]

I've just expected OOB and MITM options Turned on will give me more security when i switch to bonding mode with NFC (my application initializes static passkey bonding, but on button press i run pm_sec_params_set() with oob features to switch to bonding over NFC setup). For some reason in this state bonding doesn't use OOB_AUTH_KEY transmitted through NFC. Yes pairing request pops up when attaching Android phone, but actually any one else can pair to the device using it's BLE and with no password (similar to Just Works).

[Petter Myhre]

You may end up with Just Works even though you have set OOB and MITM. If both peers have set OOB it will be used, if one of them have not, IO capabilities will be used to determine if passkey entry can be done, if it can't, Just Works will be used. If this isn't acceptable you can reject the peer during pairing, or you can disconnect the link after pairing is done. I think this might be of help to you.

Even though pairing is complete, this doesn't necessarily mean that peer can access all your attributes, it depends on what security level you have set on them. Just works will result in security level 2, and if you have set security level 3 (Passkey entry or OOB) on your attributes the peer will still not be able to access them.