KNOB Attack for BLE (nRF52840)

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Mon, 01 Mar 2021 07:24:04 GMT

robla: Apologies for the very late reply.

I see that I didnt complete the sentence fully. YOu are correct that 7 bytes is equivalent to a 56-bit key. I should have written the following:

Simply set the SEC_PARAM_MIN_KEY_SIZE to 16 and you will remove the possibility of reducing the encryption key size from 16 to 7. However, a minimum key size of 7 bytes will ensure that the device is not affected by the KNOB attack where the key size is set to 1. With a key size of 16, you will ensure that only a 128-bit encryption key is used, which would take 2.158⋅10^12 years , i.e. 2,158,000,000,000 years to bruteforce.

RE: KNOB Attack for BLE (nRF52840)

robla — Thu, 10 Sep 2020 12:59:25 GMT

Hi bjorn-spockeli,

I have the same challenges and questions as the original poster. I am trying to decide what the minimum key length should be for our device.

In one of your answers you state that "a minimum key size of 7 bytes will ensure that a 128-bit encryption key is used".
Can you explain the details of that? Isn't 7 bytes equal to 56 bits key length?

Regards,

Robert

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Mon, 02 Mar 2020 10:14:06 GMT

Bluetooth Low Energy uses AES-128 encryption with a minimum key size of 7 bytes.

The link is encrypted when you receive the BLE_GAP_EVT_CONN_SEC_UPDATE and BLE_GAP_EVT_AUTH_STATUS, see Bonding: Numeric Comparison.

All data sent after these events will be encrypted with AES-128.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Mon, 02 Mar 2020 09:39:41 GMT

Hi Bjorn,

What is the default encryption mode used to transfer data from BLE to mobile app?

How we can verify that the data is encrypted before sending it to Mobile app?

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Wed, 22 Jan 2020 12:36:53 GMT

The integration folder contains our legacy driver .c and .h files, all which have a Nordic 5-clause license.

The modules folder contain the new nrfx HAL and driver files ( Nordic 5-clause license)in addition to chip specific start up files(Apache 2 liscence). There are no GPL references there.

Lastly the external folder, there is a single reference to GPL in \external\fatfs\doc\en\appnote.html, but other than that there is no references to GPL.

You will have to go through your application and see which of these external modules you are using and then evaluate each individual license. Segger RTT is used for logging or CLI communication.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Wed, 22 Jan 2020 12:11:31 GMT

It is showing for all the files inside the integration, modules & segger_rtt directories.

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Wed, 22 Jan 2020 11:56:06 GMT

Which files does the Black Duck scan software consider high risk w.r.t. licensing?

RE: KNOB Attack for BLE (nRF52840)

DevSec — Wed, 22 Jan 2020 11:52:24 GMT

Hi Bjorn,

We are getting License Risk after running the Bluetooth firmware in the Black Duck scan software. There are other security risk & operational risk we identified in scan but License risk is critical for us & need your help/direction to resolve this License Risk.

Its GPL-2.0+ License Risk which is high risk in the application firmware. How we can resolve this risk?

Please is the screen short for the same.

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Thu, 02 Jan 2020 08:04:04 GMT

Hi Yunus,

Apologize for the late reply.

If you're only using the nRF52840 in a Bluetooth Low Energy application, then you can remove the unused SoftDevice hex files, the unused libraries and drivers as well as examples from the SDK directory. Note: If there are files in the SDK directory that are not referenced in your applications project, then it will not be linked in to the final binary, so you do not delete the unused files in the SDK directory.

You should be able to see which files that linked into your application by looking at the .map file that is generated when you compile the application.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Mon, 23 Dec 2019 10:45:12 GMT

Hi,

Do you have any update on above queries?

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

DevSec — Thu, 19 Dec 2019 11:02:34 GMT

Hi Bjorn,

Appreciate your continues support.

We are almost done with our application development. Now we are working on code cleanup & testing, so need some clarification.

Can we have rights to modify or delete the nRF52840 libraries, softdevice files, components etc. those are not used in our Bluetooth application?

Some of the components are useless for us like ant, iot, nfc 802_15_4 etc.

Some of the softdevice files we are not using, so can we delete that?

Can you suggest minimum files/components/modules/libraries required for Bluetooth application development?

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Thu, 12 Dec 2019 13:55:09 GMT

Hi Yunus,

[quote user="DevSec"]Making SEC_PARAM_MIN_KEY_SIZE to 16 byte will affect on BLE performance? [/quote]

the AES encryption is accelerated by dedicated hardware so you should not see any noticeable effect of the increase key size on the achievable throughput of the BLE link.

[quote user="DevSec"]Do we need to take care from the mobile side as well?[/quote]

No, this will be handled automatically by the central device. If the peripheral states that the minimum key size is 16, then the central must use this.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Thu, 12 Dec 2019 06:23:46 GMT

Hi,

I changed SEC_PARAM_MIN_KEY_SIZE to 16 & I am able to pair the BLE with Android mobile app (Yet to test on other other android & iPhone).

Making SEC_PARAM_MIN_KEY_SIZE to 16 byte will affect on BLE performance? Do we need to take care from the mobile side as well?

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Wed, 04 Dec 2019 05:03:41 GMT

Hi Yunus,

[quote user="DevSec"]- What all default security features implemented in BMD-340, please point me the portion of the code.[/quote]

We set the minimum and maximum key size used for security procedures when intializing the peer manager module in our examples and the min and max size is set to 7 and 16 respectively, see below.

#define SEC_PARAM_MIN_KEY_SIZE              7                                          /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE              16                                         /**< Maximum encryption key size. */

static void peer_manager_init(void)
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
    sec_param.bond           = SEC_PARAM_BOND;
    sec_param.mitm           = SEC_PARAM_MITM;
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;
    sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
    sec_param.oob            = SEC_PARAM_OOB;
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    sec_param.kdist_own.enc  = 1;
    sec_param.kdist_own.id   = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id  = 1;

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

[quote user="DevSec"]- Do we need to take care of an extra security features in the application development?[/quote]

The countermeasures stated in the research article are as follows:

A non legacy compliant countermeasure is to secure the encryption key negotiation using the link key (KL). The link key is a shared, and possibly authenticated, secret that should be always available before starting the entropy negotiation protocol. As the attacker should not be able to modify the victims’ entropy proposals, the new encryption key negotiation protocol must provide message integrity and optional message confidentiality generating fresh keys from the link key. Preferably, the specification should get rid of the entropy negotiation protocol, and always use encryption keys with a fixed amount of entropy, e.g., 16 bytes. The implementation of these countermeasures only requires the modification of the Bluetooth controller component.

Hence, this is why we are stating that this vulnerability is only practically exploitable for BR/EDR devices where the minimum encryption key size can be set below 7 bytes.

[quote user="DevSec"]- Do you have security compliance certificate where you are making sure that KNOB attack will not be possible? [/quote]

Ref. my comment above, the minimum encryption key used is a 128-bit AES key, which is generally regarded as the “
gold standard” for encrypting data.

RE: KNOB Attack for BLE (nRF52840)

DevSec — Wed, 04 Dec 2019 04:28:35 GMT

Hi Bjorn,

This KNOB attack document explain about BLE KNOB attack even though the minimum key length >=7 bytes.

Our team needs more clarity from the security front. Can you please clarify on below points,

- What all default security features implemented in BMD-340, please point me the portion of the code.

- Do we need to take care of an extra security features in the application development?

- Do you have security compliance certificate where you are making sure that KNOB attack will not be possible?

Appreciate your support.

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Tue, 19 Nov 2019 12:36:35 GMT

DevSec See the S140 SoftDevice section on Infocenter for the SoftDevice Specification and the SoftDevice API reference.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Tue, 19 Nov 2019 12:34:24 GMT

Do we have API document which will explain the BLE stack architecture & API calls.

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

DevSec — Tue, 19 Nov 2019 12:25:41 GMT

Thanks for clarification.

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Tue, 19 Nov 2019 12:24:13 GMT

Yes, that is correct.

Best regards

Bjørn

RE: KNOB Attack for BLE (nRF52840)

DevSec — Tue, 19 Nov 2019 12:01:28 GMT

Hi Bjorn,

Thanks for quick reply.

Did you mean that nRF52840 supports minimum key lengths >=7 bytes & maximum length is 16 bytes?

Regards,

Yunus

RE: KNOB Attack for BLE (nRF52840)

bjorn-spockeli — Tue, 19 Nov 2019 09:04:20 GMT

-- Nordic devices and Software are not affected by the Bluetooth "KNOB" security vulnerability disclosed 14 August 2019 --

The Bluetooth "KNOB" security vulnerability in Bluetooth BR/EDR was published in the following research paper, https://www.usenix.org/system/files/sec19-antonioli.pdf, and the Bluetooth SIG has released a corresponding notice on this attack, see https://www.bluetooth.com/security/statement-key-negotiation-of-bluetooth/

This issue only affects BR/EDR. Bluetooth Low Energy has minimum key lengths >=7 bytes enforced and BLE is not referred to in the paper or SIG notice at all.

Our Bluetooth protocol stack team has confirmed this does not affect our products.

Best regards

Bjørn