Passkey Protection for device connection

[Aftab]

Hello,

Using this link (https://devzone.nordicsemi.com/f/nordic-q-a/35675/how-to-use-static-passkey-for-a-no-display-no-output-peripheral) I'm able to add passkey protection to any characteristic by changing:

BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);

to
BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.read_perm);
BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.write_perm);

What happens that if I try to read/write this characteristic, a popup comes out asking for passkey. When I enter the static key, the characteristic becomes accessible. But I want the same functionality when any central device wants to connect with this peripheral device. So that no device be able to connect to this peripheral unless passkey process is completed successfully. I searched the forums and am unable what should be changed to achieve this.

I'm using nRF52840, SDK16.0.0, SD7.0.1.

Regards.

[Hung Bui]

Hi Aftab, 

Such feature was not defined in the bluetooth spec. You would need to implement that on your own. 
What you need to do is to have a timer that starts when there is a connection. If after X seconds there is no write command to write a passkey the device will terminate the connection. Until there is a correct passkey entered, you would need to disable all application feature ( use read/write with authorization for example)

For better security, you can have a challenge-response mechanism : https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication . So that the same key (which can be sniffed) won't be used for future connection. 

[Aftab]

In standard procedure mentioned in the last post, the problem was that a user can face DDoS atatck b/c an intruder can keep connected to the device. The method you have mention does not prevent DDoS either. The attacker can make success attempts to connect with the device. Even in challenge response mechanism it's the same. The problem is any authentication can be performed AFTER the device is connected.

[Hung Bui]

In this case, it's the best to use whitelist. By having a whitelist, you only allow those in the list to be able to connect to the device. Any device that's outside of the list will be ignored when sending a connect request. This would require bonding between the peripheral and the central. Or at least the identity of the peripheral need to be stored on the central. 

But anyway, if an attacker want to flood the RF network, it's very easy to simply send a lot of packets on the 3 advertising channels. This should be enough to block your device from establishing any connection.