Ensuring 16 Byte of entropy in Security Mode 1v4

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

TobiasM — Tue, 14 Jan 2020 07:03:49 GMT

Hi Bjørn,

thank you for the additional information. Following your code example, I've noticed that setting security_req_t to SEC_SIGNED will call the macro BLE_GAP_CONN_SEC_MODE_SET_SIGNED_NO_MITM(ptr) which corresponds to setting security mode 2 level 1. In my case I would need to call BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM(ptr) which seems not to be part of the set_security_req function and needs to be added.

Nevertheless, this will answer my question and I will move from using the nRF Connect BLE App to programming my server setup directly, as I'll have better insight and control over the settings.

Best regards

Tobias

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

bjorn-spockeli — Mon, 13 Jan 2020 15:09:38 GMT

HI Tobias,

setting the security_req_t for reading or writing to characteristic value to SEC_MITM, will set the security level to mode 1 level 3

Lets take the Battery Level Characteristic as an example. In bas_init() we see that

  // Require LESC with MITM (Numeric Comparison)
    bas_init_struct.bl_cccd_wr_sec   = SEC_MITM;
    bas_init_struct.bl_report_rd_sec = SEC_MITM;

and that the characteristic is added by calling battery_level_char_add(), which in turn calls characteristic_add(), which in turn calls set_security_req().

static inline void set_security_req(security_req_t level, ble_gap_conn_sec_mode_t * p_perm)
{
    BLE_GAP_CONN_SEC_MODE_SET_NO_ACCESS(p_perm);
    switch (level)
    {
        case SEC_NO_ACCESS:
            BLE_GAP_CONN_SEC_MODE_SET_NO_ACCESS(p_perm);
        break;
        case SEC_OPEN:
            BLE_GAP_CONN_SEC_MODE_SET_OPEN(p_perm);
        break;
        case SEC_JUST_WORKS:
            BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(p_perm);
        break;
        case SEC_MITM:
            BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(p_perm);
        break;
        case SEC_SIGNED:
            BLE_GAP_CONN_SEC_MODE_SET_SIGNED_NO_MITM(p_perm);
        break;
        case SEC_SIGNED_MITM:
            BLE_GAP_CONN_SEC_MODE_SET_SIGNED_WITH_MITM(p_perm);
        break;
    }
    return;
}

The macros used in expands to the following:

/**@defgroup BLE_GAP_CONN_SEC_MODE_SET_MACROS GAP attribute security requirement setters
 *
 * See @ref ble_gap_conn_sec_mode_t.
 * @{ */
/**@brief Set sec_mode pointed to by ptr to have no access rights.*/
#define BLE_GAP_CONN_SEC_MODE_SET_NO_ACCESS(ptr)          do {(ptr)->sm = 0; (ptr)->lv = 0;} while(0)
/**@brief Set sec_mode pointed to by ptr to require no protection, open link.*/
#define BLE_GAP_CONN_SEC_MODE_SET_OPEN(ptr)               do {(ptr)->sm = 1; (ptr)->lv = 1;} while(0)
/**@brief Set sec_mode pointed to by ptr to require encryption, but no MITM protection.*/
#define BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(ptr)        do {(ptr)->sm = 1; (ptr)->lv = 2;} while(0)
/**@brief Set sec_mode pointed to by ptr to require encryption and MITM protection.*/
#define BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(ptr)      do {(ptr)->sm = 1; (ptr)->lv = 3;} while(0)
/**@brief Set sec_mode pointed to by ptr to require LESC encryption and MITM protection.*/
#define BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM(ptr) do {(ptr)->sm = 1; (ptr)->lv = 4;} while(0)
/**@brief Set sec_mode pointed to by ptr to require signing or encryption, no MITM protection needed.*/
#define BLE_GAP_CONN_SEC_MODE_SET_SIGNED_NO_MITM(ptr)     do {(ptr)->sm = 2; (ptr)->lv = 1;} while(0)
/**@brief Set sec_mode pointed to by ptr to require signing or encryption with MITM protection.*/
#define BLE_GAP_CONN_SEC_MODE_SET_SIGNED_WITH_MITM(ptr)   do {(ptr)->sm = 2; (ptr)->lv = 2;} while(0)
/**@} */

So if you want the security of a characteristic set to mode 1 level 4, then you need to set the security_req_t to SEC_SIGNED

Best regards

Bjørn

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

TobiasM — Thu, 09 Jan 2020 07:35:57 GMT

Hi Bjørn,

I was using the app found in "SDK16.0.0 Folder"\examples\ble_central_and_peripheral\experimental\ble_app_interactive\ for the nRF52840DK (PCA10056). I've just made some minor changes, s.t. the security levels will be printed to check which levels are active and in sdk_config.h I've changed the BLE_SEC_PARAM_MAX_KEY_SIZE value to 7, as the smallest number exchanged between both devices will be used as encryption key size according to the spec.

On server side I've used nRF Connect running on the nRF52DK. I've added a new service and a characteristic with read permission "LESC encryption with MITM required" which should be level 4 as I understand it. Therefore the first option is used.

I did double check the exchange of the parameters using a sniffer. The Log file of the nRF Connect states "Security updated, mode: 1, level: 4" and I'm able to read the characteristic with the Interactive App which shows only security level 3 in that case.

Best regards

Tobias

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

bjorn-spockeli — Tue, 07 Jan 2020 14:37:02 GMT

Hi Tobias,

which interactive application from SDK v16.0.0 did you use? Please provide the name of the example or the path inside the SDK v16.0.0 folder.

Did this example set the security mode of the characteristic using BLE_GAP_CONN_SEC_MODE_SET_LESC_ENC_WITH_MITM or with BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM?

Best regards

Bjørn

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

Marjeris Romero — Tue, 24 Dec 2019 11:01:22 GMT

Hi Tobias,

Just wanted to let you know that Bjørn is out on vacation until the 2nd week of January. He will come back to you then.

Best regards,

Marjeris

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

TobiasM — Wed, 18 Dec 2019 10:54:36 GMT

Thank you for the clarification. Unfortunately after testing my setup I ran into problems.

In case of pairing both devices with lower encryption key size than 16 byte I shouldn't be in security mode 1 level 4. After testing my nRF52840 DK and nRF52 DK with interactive app running on both devices I could confirm this behaviour by intentionally reducing the max encryption key size. After trying the same thing using nRF Connect on one device and the interactive app on the other, I encountered that nRF Connect assumes I have security mode 1 level 4 even if the key size was reduced. The interactive app shows security mode 1 level 3 in this case, which seems to be more reasonable to me.

Therefore I was able to read characteristics from nRF Connect which should be only readable for security mode 1 level 4. Is this a bug? I was using nRF Connect v3.3.0 with BLE App v2.3.2 and the interactive app from the SDK16.0.0. I've used Numeric Comparison as pairing method.

Best regards,

Tobias

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

bjorn-spockeli — Wed, 18 Dec 2019 08:45:53 GMT

My understanding is that the vulnerability is for the key negotiation process, i.e. pairing process. For Bluetooth Low Energy device and then both the central and peripheral device will store the negotiated key in internal memory and then use this key for all subsequent communication. So the "Keysize too small" error will be generated if the central device or an attacker tries to use a lower key size than SEC_PARAM_MIN_KEY_SIZE during the pairing process.

So if you attempt to read or write to a characteristic that has a its security level requirement set to Security Mode 1 level 4, but the link securit level is not high enough, then you will get an error message stating Insufficient Authorization, see BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part F page 2335.

Best regards

Bjørn

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

TobiasM — Tue, 17 Dec 2019 19:02:25 GMT

Hi Bjørn,

[quote userid="7571" url="~/f/nordic-q-a/55727/ensuring-16-byte-of-entropy-in-security-mode-1v4/225890"]Our SoftDevices for the nRF52 series will reject the pairing request if the key size is below the minimum set in the application, see GAP Failed Pairing: Keysize too small. [/quote]

if I understand correctly, in case of trying to read a characteristic with Security Mode 1 level 4 in the setup of two paired devices which have been paired let's say by Numeric Comparison, I would get a "Keysize too small" error if the entropy for the encryption key is lower than 16 bytes. Is this correct?

Best regards,

Tobias

RE: Ensuring 16 Byte of entropy in Security Mode 1v4

bjorn-spockeli — Tue, 17 Dec 2019 13:14:41 GMT

HI Tobias,

[quote user=""]I could set the min key length to 16 bytes for both devices, but I just want to use the full key length for specific services.[/quote]

it is possible to set the security requirement for individual attributes in the GATT table, i.e. a characterisistic can only be read or written to if the Security level is high enough, e.g. Security Mode 1 level 4

[quote user=""]In the paper eprint.iacr.org/.../933.pdf on page 11 it is specifically mentioned that "even if a device using security mode 1 with level 4, the LTK's entropy can still be downgraded to 7 bytes". Am I missing something or this a bug of the tested devices? Is it possible to downgrade the nRF52840 or nRF52832 to use 7 bytes of entropy in Security Mode 1v4?[/quote]

Our SoftDevices for the nRF52 series will reject the pairing request if the key size is below the minimum set in the application, see GAP Failed Pairing: Keysize too small.

Best regards

Bjørn