KNOB Attack for BLE (nRF52840)

[DevSec]

Hi Experts,

We are developing application on nRF52840 based BLE 5.0 module i.e. BMD-340, in short we are integrating the BLE in one of our existing product & upcoming new products.

We have found information about KNOB attack on BLE. 

Does Nordic have implemented the features to avoid the KNOB attack? If yes, please provide details. 

Regards,

Yunus

[bjorn-spockeli]

-- 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

[DevSec]

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

[bjorn-spockeli]

Hi Yunus, 

DevSec said:

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

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);
}

DevSec said:

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

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.

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. 

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.

DevSec said:

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

 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.

[DevSec]

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 

[bjorn-spockeli]

Hi Yunus,

DevSec said:

Making SEC_PARAM_MIN_KEY_SIZE to 16 byte will affect on BLE performance?

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. 

DevSec said:

Do we need to take care from the mobile side as well?

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

 

 

[DevSec]

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  

[DevSec]

Hi,

Do you have any update on above queries?

Regards,

Yunus

[bjorn-spockeli]

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

[DevSec]

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