nRF52840 SDK16 sd140 - Pairing and Bonding general questions

RE: nRF52840 SDK16 sd140 - Pairing and Bonding general questions

ovrebekk — Tue, 26 Apr 2022 12:26:52 GMT

Hi Nikos

[quote user="Nikosant03"]I suppose this is how most of the commercial products work, right?[/quote]

Correct. I believe Apple describe something similar in their guidelines, in order to make Bluetooth devices that integrate well with iOS devices.

[quote user="Nikosant03"]Is there any example in SDK16 implementing these steps with Just Works pairing mode?[/quote]

Any example using the peer_manager should support this procedure.

As an example you can use the ble_app_hrs sample, which by default is set up to use LESC and not use authentication (which means you revert to just works):

// Excerpt from the main.c file of the ble_app_hrs example:

#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 0 /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC 1 /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS 0 /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_NONE /**< No I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size. */

Best regards
Torbjørn

RE: nRF52840 SDK16 sd140 - Pairing and Bonding general questions

Nikosant03 — Mon, 25 Apr 2022 16:36:00 GMT

Thank you for your detailed answer ovrebekk

[quote userid="2116" url="~/f/nordic-q-a/87254/nrf52840-sdk16-sd140---pairing-and-bonding-general-questions/364704#364704"]The normal procedure for a client to access a protected characteristic is as follows[/quote]

I suppose this is how most of the commercial products work, right?

Is there any example in SDK16 implementing these steps with Just Works pairing mode?

RE: nRF52840 SDK16 sd140 - Pairing and Bonding general questions

ovrebekk — Mon, 25 Apr 2022 12:04:17 GMT

Hi Nikos

[quote user=""]A secure communication link provides data encryption through AES-CCM cryptography, right?[/quote]

That is correct.

BLE encryption is based on a traditional symmetric AES-CCM encryption algorithm, with a standard key size of 128 bits.

The AES key used for the AES-CCM cipher (also referred to as the Long Term Key) is exchanged during the pairing phase, which in the case of LE secure pairing is using an asymmetric ECDH scheme to avoid someone sniffing the pairing procedure to be able to get hold of the AES key.

[quote user=""]Does this mean that all the data exchanged after pairing through characteristics are encrypted? e.g the value of the sensors, battery level, etc?[/quote]

Correct, encryption in BLE is all or nothing. Once encryption is enabled all the attribute data will be encrypted, even for attributes that don't require it.

[quote user=""]

Also, after testing the heart rate example, I see that I have access to all characteristics without previously having paired the devices. This doesn't make sense to me. I mean it would make sense for the central to have access to the GATT server after the pairing process. For example, when I connect my wireless headphones with the smartphone, I have to pair the device before start hear music.

So this is something that should but doesn't be demonstrated in the hrs example or do I miss something?

[/quote]

The Bluetooth specification doesn't require you to pair and enable encryption before you do service discovery, and normally the initial service discovery is done without encryption enabled.

Still, you can configure a characteristic to require encryption enabled in order for the client to read and/or write to it, which means you will not be able to access the characteristic data before pairing is done.

This is why you can see all the services and characteristics from the nRF Connect app, even if some of them might require encryption to be accessed.

The normal procedure for a client to access a protected characteristic is as follows:

1) The two devices connect.

2) The client performs service discovery, and gets a list of all the services and characteristics in the server.

3) The client tries to access the protected characteristic

4) The server responds with an 'insufficient authentication' error, letting the client know that this characteristic requires encryption in order to be accessed.

5) The client start the pairing procedure.

6) Once pairing is completed, the client can access the characteristic.

Best regards
Torbjørn