IRK Whitelisting Central and Peripheral

[aparker]

I'm using two nRF52840 DKs with SDK 16.0 with one as a central, the other as a peripheral. I'd like to setup an IRK whitelist on the peripheral. I've taken a look at the hid keyboard and mouse examples for whitelisting but I haven't been able to discern how to setup the whitelist for an IRK, let alone how to configure the central to send the correct information for the peripheral. Is there an example I'm missing or can I get some advice on how to configure each end?

[Kenneth]

Hi,

I believe the \examples\ble_peripheral\ble_app_hrs and \examples\ble_central\ble_app_hrs_c are good starting points, since both support bonding. To bond you can call pm_conn_secure() on the central.

The only thing needed now to re-connect is on the peripheral side, which should use whitelist to ensure only the bonded peer can re-connect. This is typically handled by handling BLE_ADV_EVT_WHITELIST_REQUEST in adv_evt(), this is shown in \examples\ble_peripheral\ble_app_hids_keyboard

Note that the default address type of nRF products are random static, which doesn't use/require an IRK. So the whitelist likely is populated with whitelist_addrs in this case, but if you for instance bond with a phone then you will typically see that the whitelist is populated with whitelist_irks.

Best regards,
Kenneth

[aparker]

So the peer manager will handle bonding even with the whitelist? If I have a central and peripheral, both of which haven't bonded before, pm_conn_secure() will handle the initial bond with the peripheral when it has an empty whitelist up? I understand that the BLE_ADV_EVT_WHITELIST_REQUEST will handle and reply on the peripheral side, I just don't understand how to set up the central to be an approved device for the peripheral on startup. How would this prevent someone to sniff the UUID/Mac address and connect?

[Kenneth]

When you have connected two devices you want to bond you call pm_conn_secure() yes. To make them connect you will need to disable whitelist on the peripheral for a short period of time to allow a new central to connect.

It is technically possible for a third party to spoof the address and possible connect, however if you always re-establish encryption after connection, then any third party attacker will not be able to successfully encrypt the link, and you may disconnect in such case where encryption fails.

Best regards,
Kenneth