Understanding BLE Bonding & Whitelists

[droberson]

• SDK: 15.2
• SoftDevice: s140_nrf52_6.1.0
• FreeRTOS
• Hardware: nRF52840 (Custom boards)

Hello,

I am having difficulty finding clear and concise information regarding BLE bonding, even on YouTube. I am hoping someone can help me answer some questions. My high-level understanding is that bonding just saves the keys exchanged during the pairing process so that the pairing process doesn't need to occur each time the devices reconnect.

1. Can you limit the number of Central devices that can bond with a Peripheral? Ideally, I am looking to bond at most 2 Centrals to 1 Peripheral.
2. Can you enable bonding only on specific links or from specific devices? Ie, if we have Central1, Central2, and Peripheral1, can the link between Central1 and Peripheral1 be bonded, while the link between Central2 and Peripheral1 not be bonded?
3. Can you enable bonding for only certain BLE services or characteristics, but not all?
4. Once a Peripheral is bonded to a Central, and the maximum number of bonds have been reached (but bonded devices may not currently be connected), will the Peripheral automatically block connection requests from non-bonded devices, or does a whitelist need to be used?
5. Once two devices are bonded, but are disconnected, does the Peripheral still send discoverable advertising packets to allow a bonded Central to reconnect? If not, what does the connection process look like for bonded devices?
6. From the Peripheral side, can you clear bonds for specific devices only, or are you required to clear all bonds?
7. Do the encryption keys generated during the pairing process ever expire once bonded? Can the same keys be used for the life of the product?

If you have any documentation that covers the topics above in more detail, please feel free to link those here!

Thanks!

Derek

[Hung Bui]

Hi Derek, 
Most of the features in your list are application specific and not define in the spec. So it's up to the application to implement the features. 
In our SDK we provided the peer manager module that can do some of the features you mentioned but not all. The peer manager module is pretty generic and doesn't have some specific feature for example limit the max number of peer can bond to the device. We had to avoid making a too complex module that hard to use and requires more flash. 

Regarding your question: 

1.

Can you limit the number of Central devices that can bond with a Peripheral? Ideally, I am looking to bond at most 2 Centrals to 1 Peripheral.

No it's not supported by the peer_manager. The limit of number of peer can bond to the device is limited by the flash area allocated for peer_manager. You would need to call pm_peer_count() to know the current number of peers in the database and then call pm_conn_sec_params_reply() in PM_EVT_CONN_SEC_PARAMS_REQ event to reply with NULL for example to reject all bond and  pair from the new peer. Or you can allow pair but no bond. 

2.

Can you enable bonding only on specific links or from specific devices? Ie, if we have Central1, Central2, and Peripheral1, can the link between Central1 and Peripheral1 be bonded, while the link between Central2 and Peripheral1 not be bonded?

Yes, again with pm_conn_sec_params_reply in PM_EVT_CONN_SEC_PARAMS_REQ  event. 

3.

Can you enable bonding for only certain BLE services or characteristics, but not all?

There isn't a concept of bonding for service/characteristic. The concept is to set security level for service/characteristic. So a certain security level /encryption) is required to access an attribute (service/characteristic). It's more about pairing, not bonding. And yes you can set a characteristic to only require open connection, and other characteristics require encryption. 

4. 

Once a Peripheral is bonded to a Central, and the maximum number of bonds have been reached (but bonded devices may not currently be connected), will the Peripheral automatically block connection requests from non-bonded devices, or does a whitelist need to be used?

Yes if you do what described in 1. Or you can use whitelist, but then it blocks connection, not only bond/pair. 

5. 

Once two devices are bonded, but are disconnected, does the Peripheral still send discoverable advertising packets to allow a bonded Central to reconnect? If not, what does the connection process look like for bonded devices?

For connection establishment there is no different if the peripheral is connected to a bonded device or new device. It's the same process. Except if you do directed advertising. Then the address of the bonded central is in the advertising package. After you connect to a bonded device, the peers can recognize each other via the addresses and can use the stored bond information to re-encrypt the link. 

6.

From the Peripheral side, can you clear bonds for specific devices only, or are you required to clear all bonds?

Yes you can clear bond of a certain bond or all bonds. You use either pm_peer_delete() or pm_peers_delete()

7. 

Do the encryption keys generated during the pairing process ever expire once bonded? Can the same keys be used for the life of the product?

It depends on which type of pairing you are doing, Legacy pairing or LESC. Legacy pairing use STK (short term key) when you initially bond/pair. In bond process after pair, the LTK (Long term key ) is exchanged. The next connection they will use LTK if they have been bonded. In LESC, the LTK is generated in pairing process and the same key will be used for next connection. 
The LTK can be deleted from either of the peer. When that happen you would need to remove the key on the other peer and make a new bond hence new LTK. 

We have a Bluetooth LE Academy here that focuses on nRF Connect SDK but it has some Security theory part that might be relevant to you. 

[droberson]

Thanks for your responses! They have helped a lot.

I have continued my BLE security research and don't see what mechanism prevents replay attacks. What stops a malicious device from simply repeating an encrypted message? Is there a packet counter built into the BLE security protocol?

Thanks,

Derek

[Hung Bui]

Hi Derek, 

There isn't a packet/event counter in BLE packet. The peers have to count that on their own.
However, there is a 2-bit sequence number (SN and NESN) in each packet on link layer. 
A packet with the same sequence number will be ignored. This protects against replay attack. 
I discussed it a little in the following blog. It's a bit old but the information is still relevant. Please look for "Acknowledgement and Flow Control" section. 
Bluetooth Smart and the Nordic's Softdevices - Part 2 Connection