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]

Hung Bui 

Hopefully these will be my last questions:

1. From what I understand, whitelists and directed advertising can be used without pairing or using the Peer Manager, correct?

2. What is the point of whitelisting and directed advertising if a malicious device can spoof it's MAC address and bypass both of these tools?

Thanks,

Derek

[Hung Bui]

Hi Derek, 

1. I don't have further suggestion than the crypto samples we have : https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/crypto_examples_nrf_crypto.html?cp=9_1_4_3_0 
My suggestion is to study the AES CBC : https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/lib_crypto_aes.html#sub_aes_cbc

2. Not really. You would need to look at how we handle bonded connection and from there see how the LTK has been used to re-encrypt the link. It's not possible to input the TK. The stack will only ask for the LTK not the TK. The TK is generated automatically by the stack in the pairing process. 

3. Yes. 

I think the easiest path for you, considering you don't want to dig too deep into cryptography and security is to find away to secure the connection via normal Bluetooth pairing without having a display or keyboard on the device. My suggestion was to use the advertising packet to embed the passkey in the advertising packet. 
It's what I meant by "encrypting the passkey into the advertising packet". The scenario will be like this: when the device start, it will generate a new random passkey for bluetooth pairing, for example "123321".

You then put "abccba" in the advertising packet. You advertise with the data "abccba". It's a very simple way of encrypting the number "123321". Any phone can read the data "abccba" in the advertising packet.
 On the phone when you scan and find abccba, in your application you know how to decrypt it back to 123321. Only your app can do this. 

You then can tell the end user to input 123321 into the pairing popup that Android/iOS will display when you pair. 

After that you should be able to pair with random passkey and it's consider secured. 

Of course you will not do this simple encryption of converting 1 to a , 2 to b etc. You can to something more advanced, for example AES or any other type of encrypting data that you can decrypt on the app on the phone. 
In my opinion, this is the easiest approach, you don't have to handle the encryption of the data communication. That's handled by Bluetooth encryption. You only handle the path where you can send the random passkey from the device to the phone in a secure way (encrypting it in advertising data.)

[droberson]

Hey Hung,

If I encrypt the passkey in the advertising packet, is the truly secure? Using AES CBC as an example to encrypt the passkey, it expects a 16 byte initialization vector (IV). My understanding is that the IV should not be the same for each message encrypted, otherwise you get the same ciphertext output given the same plaintext and key.

1. Is it possible for someone to decrypt the passkey with this approach if the IV is constant but secret? If so, how do you recommend to encrypt the passkey in the advertising packet?

2. If native BLE pairing increases the packet size, does this limit your maximum payload size below 244 bytes? My project uses the Nordic UART Service with a max payload size of 244 bytes.

"the payload is limited to 251 bytes, and when sending data through ATT you lose 4 bytes for the link layer header and 3 bytes for the ATT header, leaving you with 244 bytes maximum for attribute data"

Source:  RE: Increasing MTU ATT to 1020 bytes generates a CMake error 

Thanks,

Derek

[Hung Bui]

Hi Derek, 

1. Disclaimer: we are not fulltime security expert so we can only give you suggestion, but the actual implementation is up to you. From my point of view you don't need to use CBC. ECB is good enough. The reason is that the passkey is randomly generate for each connection. So you don't have to worry that the encryption can be discerned. Note that you can have different cipher key for different device, by having a serial number of each device and the app need to input the serial number to get the key from cloud. 

2. MIC is outside of the ATT layer (it's on the Link layer). As you can find in the answer by Torbjørn here: 

The length field has the range 0 to 255 octets. The Payload shall be
less than or equal to 251 octets in length. The MIC is 4 octets in length.

In other words the payload is limited to 251 bytes, and when sending data through ATT you lose 4 bytes for the link layer header and 3 bytes for the ATT header, leaving you with 244 bytes maximum for attribute data. 

MIC 4 bytes already counted in the Link layer ( max 255 bytes):  251 bytes is left on the link layer payload. And for ATT you have max 244 bytes. 

[droberson]

Hey Hung,

Got it, thanks! I have been studying AES (CBC / ECB).

Since AES requires the plaintext to be a multiple of the block size (16 bytes), how does BLE handle the case where the plaintext is the maximum payload size (lets say 244 bytes)? Since 244 is not a multiple of 16, this would require 12 bytes of padding (16 - (244 mod 16)) which exceeds the BLE PDU spec. The same applies if the plaintext is of length 240 bytes which is an exact multiple of the block size. This would require 16 bytes of padding which again exceeds the BLE PDU spec.

How are these padded bytes transmitted and handled?

Thanks,

Derek

[Hung Bui]

Hi Derek, 

I'm afraid you will need to look into the Bluetooth Specification to find those information as you are getting deeper into how Bluetooth works. 
My understanding on this matter is that Bluetooth use AES CCM to do encryption. CCM supports variable length. 
There is a short list of what used in Bluetooth security here: https://support.apple.com/lv-lv/guide/security/sec82597d97e/web

If you want to look into Bluetooth specification, please take a look at Vol 6 Part E : Low Energy Link Layer Security in Bluetooth specification v5.4

[droberson]

Hey Hung,

You were correct. Some resources lead me to believe that all versions of AES require the plaintext to be padded to 16 bytes, This is not true for AES CCM and AES CTR (And maybe some others).

I have implemented a solution based on the information above that seems to work well for the moment. Thanks!

I have a few more questions in regard to whitelists and directed advertising. If I need to open a new ticket for this, let me know.

1. Can a Peripheral device use both a whitelist and directed advertising at the same time?

I have enabled both on my device with a static BLE MAC (No peer manager, just using the ble_advertising.c module with BLE_ADV_EVT_WHITELIST_REQUEST and BLE_ADV_EVT_PEER_ADDR_REQUEST respectively). Upon doing so, I notice that only BLE_ADV_EVT_DIRECTED is received and ADV_DIRECT_IND packets are received by my BLE wireshark sniffer capture. When I disable directed advertising, I see that BLE_ADV_EVT_FAST_WHITELIST is received and ADV_IND is received in the wireshark capture. This leads me to believe that the answer to this question is no.

2. If whitelisting and directed advertising cannot be used at the same time, and assuming directed advertising takes priority, does directed advertising essentially function as a whitelist and thus block connection and scan requests from all devices except the one being directly advertised to?

Thanks,

Derek

[droberson]

Hung Bui  Should I create a new ticket for my questions above?

Thanks!

Derek

[droberson]

I am guessing Hung may be OOO so I have created a new ticket here:  Whitelisting and Directed Advertising Simultaneously