Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

[mlyonupdesigns]

I am using SDK v15.3 and would like to modify the peripheral heart rate service example to require the Central to establish mode 1, level 3 security. I am undecided on whether it will be numeric comparison, passkey or OOB, but would like to evaluate each.

If there is another example I could reference to help with the changes to the heart rate service example, please advise.

[mlyonupdesigns]

Once I fixed the behavior of the ble_app_hrs example so it doesn't start the application timers (application_timers_start) at start-up, but rather waits for BLE_GAP_EVT_AUTH_STATUS event on the initial bonding or NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event on reconnection, then all worked as expected.

Also stopping the application timers on a disconnect was necessary so that repeated connect/disconnect operations would work.

So I think I'm all set. Thanks for your attention.

[mlyonupdesigns]

I did have a follow up question related to central and peripheral bonding data becoming of "lost". If the central has it's bonding information, but the peripheral no longer does.

From my BT capture I see that the central sends a LL_ENC_REQ and the peripheral responds with LL_ENC_RSP (which must have something in it that doesn't match. The peripheral then responds with LL_REJECT_IND. I don't see this handled in the SDK and wonder what is the correct action?

Similarly, if the central no longer has the bonding information, but the peripheral does what is the expected behavior?

[Emil Lenngren]

Why not require mode 1 level 4 instead? The difference to level 3 is that level 4 requires LE Secure Connections, which is much more secure than Legacy Pairing.

[Einar Thorsrud]

The default behavior is to reject pairing attempts from peers where there already exists a bond. This is for security reasons, as if you allow that, it means that an attacker can spoof the address of the peer you are bonded with, and replace that bond. It is however possible to allow re-pairing by BT_SMP_ALLOW_UNAUTH_OVERWRITE if you want to. Sometimes this may be required from a usability perspective, but it is important to be aware of the security implications.

[mlyonupdesigns]

The BT_SMP_ALLOW_UNAUTH_OVERWRITE doesn't pertain to SDK 15.3 I don't believe (at least I don't see any reference to that type of functionality).

Specifically, I purposely deleted the bonding information from the peripheral to see the behavior so I'm trying to understand what the correct procedure is for forcing a re-bonding if either the central or peripheral loses the non-volatile storage holding the bonding information. Obviously, in our app on the central side I can delete the peer information (e.g., pm_peers_delete) which should force a re-bonding. What can I do from the central side if I have lost the bonding information but the peripheral has not? I'm just trying to understand what the spec says should occur in these instances.