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

[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

[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