This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is NFC + static passkey bonding possible?

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(...).

Parents
  • 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.

  • 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.

Reply
  • 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.

Children
No Data
Related