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, 

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

[bjorn-spockeli]

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

[DevSec]

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

[bjorn-spockeli]

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