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. Correct. But you would need to implement your own code to do directed advertising or to apply whitelist. You very often need to use resolvable random address for whitelist or directed advertising. This requires the IRK key. The IRK key is normally only distributed after pairing. So unless you have control over both sides of the connection, more likely you would need to do pairing/bonding.

2. Whitelisting or directed advertising are not security protection methods. They are more of "filter for less distraction" that they can block the communication from other devices not in the list to focus on the packets from devices in the list.  

[droberson]

From what I have read, most phones periodically change their MAC address. So if I were to use a whitelist and directed advertising on the Nordic MCU with a known phone BLE MAC, this wouldn't work due to the rotating MAC's, correct?

Is it possible to use and define a static private IRK (Identity Resolving Key) on the nRF52840 and custom phone application to mitigate this and not have to use native BLE pairing/bonding?

Thanks,

Derek

[Hung Bui]

Hi Derek, 

droberson said:

From what I have read, most phones periodically change their MAC address. So if I were to use a whitelist and directed advertising on the Nordic MCU with a known phone BLE MAC, this wouldn't work due to the rotating MAC's, correct?

Yes correct. That why I mentioned that in many case you need to have the IRK exchanged. 

droberson said:

Is it possible to use and define a static private IRK (Identity Resolving Key) on the nRF52840 and custom phone application to mitigate this and not have to use native BLE pairing/bonding?

I don't really get this. Could you please give more information on what you want to achieve ? a description on how your device work with the phone would be nice.

Note that the app on the phone can't control the address of the phone. It's handled by the operating system. 

[droberson]

Hey Hung,

I think you answered my question. I was hoping that I could connect a phone to my nRF52840 MCU without pairing / bonding and still use a whitelist and directed advertising on the nRF52840.

Is pairing the only way to exchange an IRK between the phone and nRF52840? Or can it be written to each device OOB (Out of band) somehow?

Edit:

Looks like an IRK can be pre-shared: devzone.nordicsemi.com/.../directed-advertising-with-pre-shared-irk

Maybe a better question is, can BLE pairing be done with a static pre-shared long term key (128-bit) that is written to MCU flash during manufacturing? I am trying to understand how to secure a BLE connection to a Peripheral device that has no user input and therefore has no way to clear bonds. The only way I know to secure such a device is to have a pre-shared static key. Is there a better way?

Thanks,

Derek

[Hung Bui]

Hi Derek, 

If you have control over both side of the connection (for example connection between two nRF52s, not with a phone) then it's possible to do pre-shared LTK or pre-shared IRK. However, I assume in your case you are connecting to a phone ? In that case the Operating System has control over pairing and addressing. So it's not possible to do pre-shared key. 

If you have NFC it should be possible to do OOB pairing with a phone. Otherwise you may need to think about doing your own encryption.

Either by doing application encryption on top of an open BLE connection, or you can think of doing encryption over advertising packet, and in that advertising packet you send the passkey you will use when doing normal BLE pairing in the next step. This way you can do a secure bonding without having display or keyboard. Of course the challenge is that you would need to have a common key between the device and the app on the phone (can be done using a serial number and the key on the cloud matches with the serial number).

[droberson]

Hey Hung,

My nRF52840 device supports connections from a phone and other nRF52840's.... So it looks like I have 2 options:

1. Implement my own AES encryption using an 'open' BLE connection.

2. Use native BLE pairing with a pre-shared key which will manage the AES encryption stuff for me. This would work for the nRF52840 links, but not the phone link. I may have a workaround for the phone but I will omit this for now as it will overcomplicate things as the system I am working on is complex.

Not sure I understand the benefit of "think of doing encryption over advertising packet, and in that advertising packet you send the passkey you will use when doing normal BLE pairing in the next step" or how this is secure?

With the answers to the questions below, hopefully I can figure out the rest.

Questions:

1. If I were to do my own encryption over an open BLE link, are there any examples that I could reference?

I see the AES examples in the SDK, but they require the use of a nonce or initialization vector and MAC. Managing these on my own seems problematic. I am a novice when it comes to security.

2. Are there any Nordic examples of using a pre-shared static 128-bit key with native BLE pairing? This could be BLE legacy (Using 128-bit TK) or LESC (Using 128-bit LTK).

3. Does using native BLE security increase the BLE packet size since a MAC (MIC) field is appended?

https://infocenter.nordicsemi.com/topic/ps_nrf52840/ccm.html?cp=5_0_0_5_3

My apologies for so many questions. Like I said before I am a novice when it comes to security and the system I am working on is complex.

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