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, 

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