• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 21 replies
  • Subscribers 76 subscribers
  • Views 7108 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 239592
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • +1

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

  • 0 in reply to bjorn-spockeli

    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

  • 0 in reply to DevSec

    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.

  • 0 in reply to bjorn-spockeli

    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 

  • 0 in reply to DevSec

    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

     

     

  • 0 in reply to bjorn-spockeli

    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  

  • 0 in reply to DevSec

    Hi,

    Do you have any update on above queries?

    Regards,

    Yunus

Reply Children
Related
Terms of service