Enabling Crypto Hardware backend feature on nRF52840

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Tue, 10 Dec 2019 10:48:17 GMT

Thank you Einar.

RE: Enabling Crypto Hardware backend feature on nRF52840

Einar Thorsrud — Tue, 10 Dec 2019 10:27:43 GMT

Hi Vishnu,

Thanks for the feedback. I agree the documentation could state that installing micro-ecc is not necessary if using nRF52840. I will forward your request.

Br,

Einar

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Sun, 08 Dec 2019 13:00:26 GMT

Hello Einar,

Even I request to mentioned about NRF_CRYPTO_BACKEND_CC310_BL_ENABLED in below link rather than micro-ecc. For new person who starts working on DFU, this creates lot of confusion and which is not required, as S140 is for nRF52840. Even the same for Secure DFU over uart.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Fble_sdk_app_dfu_bootloader.html&cp=6_1_4_4_0

Thanks & Regards

Vishnu Beema

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Thu, 05 Dec 2019 09:28:07 GMT

Thank you Einar. I got your point. I am fine with Default configuration and it is working fine.

RE: Enabling Crypto Hardware backend feature on nRF52840

Einar Thorsrud — Thu, 05 Dec 2019 08:56:55 GMT

Hi Vishnu,

The documentation you linked to in the last post is nrf_crypto documentation. This library (nrf_crypto) is used in the bootloader, but can also be used for whatever you want in the application. That is why it is not marked as specific for the bootloader. But if you don't intend to use some special crypto operations in your application, then you do not need to think about it. The key here is that the libraries are generic. So reading library documentation (nrf_crypto) does not tell you exclusively what is needed in a specific use case (DFU bootloader), it also tells you much more which may not be relevant for you.

If you are happy with the default configuration you do not need to touch the NRF_CRYPTO... configuration macros at all, since the default configuration in the bootloader example is the most sensible.

Br,

Einar

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Thu, 05 Dec 2019 08:36:21 GMT

Thanks a lot for understanding and clarifying my last query.

1) For your below comment, only bootloader to be changed but not application. Even this is same for all other crypt (For micro-ecc) (Just gave micro-ecc example though I will be going to use NRF_CRYPTO_BACKEND_CC310_BL_ENABLED)?

a) Initially even I was in same understanding as application is not required to modify. But I got confused with snapshot in below link where library is added in application "ble_app_gls" of SES (Which is not required). Please correct me if I am wrong.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_crypto_backend_micro_ecc.html&cp=6_1_3_11_16_2_3&anchor=nrf_crypto_default_backends_micro_ecc

"For DFU, the only thing that is relevant is the crypto support in the bootloader. So what you have enabled for the application is irrelevant in this regard."

Thanks & Regards

Vishnu Beema

RE: Enabling Crypto Hardware backend feature on nRF52840

Einar Thorsrud — Thu, 05 Dec 2019 08:24:13 GMT

Hi Vishnu,

Both DFU and crypto are complex issues, so I understand you need time to grasp it all. Please note that you can use an unmodified bootloader example project form the SDK (examples\dfu\secure_bootloader\pca10056_s140_ble), since that has all the relevant configuration for you (though you will need to change the public key, and potentially adopt a few things to your custom HW).

[quote user="beemavishnu"]My last query on above point '2a' is, without NRF_CRYPTO_BACKEND_CC310_BL_ENABLED enabled (But already enabled in secure ble bootloader), I generated ble_app_blinky package and able to do DFU over BLE secure Bluetooth. Even I enabled "Static Pass key" and tested the feature without enabling NRF_CRYPTO_BACKEND_CC310_BL_ENABLED macro. Sorry I may be confusing you.[/quote]

I think you are missing several concepts here. For DFU, the only thing that is relevant is the crypto support in the bootloader. So what you have enabled for the application is irrelevant in this regard. Also, you mention "Static Pass Key". This is relevant for the BLE pairing process, but is not relevant with regards to DFU, and is not related to crypto in DFU context (signature verification).

Br,

Einar

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Wed, 04 Dec 2019 09:40:22 GMT

Hi Einar,

Thank a lot for your inputs and confirmation. This is what I am expecting.

In Infocenter, nowhere they specify to use NRF_CRYPTO_BACKEND_CC310_BL_ENABLED and not to use NRF_CRYPTO_BACKEND_CC310_ENABLED as size will increase.

Below link only mentions on how to use micro-ecc and cannot relate to nRF52840.

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader

I posted other queries in parallel. Sometimes I feel, there is lot of info in infocenter. But difficult to get necessary info (Sorry to say this).

Struggled a lot for bringing up DFU over “BLE secure bootloader”.

1) Issues in compiling micro-ecc library itself.

https://devzone.nordicsemi.com/support/240266

2) Issues in compiling BLE Secure bootloader by enable micro-ecc

https://devzone.nordicsemi.com/support/240393

3) Finally I realized that micro-ecc is not required with your mail.

https://devzone.nordicsemi.com/support/240436

Once again, thanks a lot for your inputs.

My last query on above point '2a' is, without NRF_CRYPTO_BACKEND_CC310_BL_ENABLED enabled (But already enabled in secure ble bootloader), I generated ble_app_blinky package and able to do DFU over BLE secure Bluetooth. Even I enabled "Static Pass key" and tested the feature without enabling NRF_CRYPTO_BACKEND_CC310_BL_ENABLED macro. Sorry I may be confusing you.

Thanks & Regards

Vishnu Beema

RE: Enabling Crypto Hardware backend feature on nRF52840

Einar Thorsrud — Wed, 04 Dec 2019 08:21:56 GMT

Hi Vishnu,

1a). No, you can use CryptoCell (CC310) in the bootloader, but you need to use the CC310_BL backend for size reasons. This only supports the operations that are needed for the bootloader. So in the bootloader, you should set NRF_CRYPTO_BACKEND_CC310_ENABLED to 0 and NRF_CRYPTO_BACKEND_CC310_BL_ENABLED to 1. If you use the "normal" (non-BL) variant in the bootloader, you will get problems fitting it unless you increase the bootloader size.

1b) No. The only difference is that the library is stripped down to only provide what is needed by the bootloader. There is no impact on current consumption. (Also, the crypto operations in the bootloder normally only happen during DFU, which is not performed often, so even if it was different with regards to current consumption - which it is not - it would not matter much.

2) Why do you want to use micro-ecc on the nRF52840 when you have CC310? I do not see a good reason for it, unless in some very specific corner cases. I suggest you set NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED to 0 in both the application and bootloader. This is also the default in SDK example projects for nRF52840 (those targeting pca10056). Note that for DFU, you just need ECC support (via CC310 I recomend) in the bootloader. Unless you have other use for it in the application you kan disable it. But there is no need to change if you do not want since it will anyway be removed from the linker since it is not used.

2a) I don't understand the problem? If you do not need eliptic curve cryptography in your application, it is not relevant there. And if you need it in the bootloader, you should use CC310_BL. So the best is to just forget about micro-ecc.

Br,

Einar

RE: Enabling Crypto Hardware backend feature on nRF52840

beemavishnu — Tue, 03 Dec 2019 13:24:56 GMT

Thanks a lot. Now I am getting better understanding and confidence.

1) As per below link, I enabled NRF_CRYPTO_BACKEND_CC310_ENABLED and disabled NRF_CRYPTO_BACKEND_CC310_BL_ENABLED. As mentioned in point 4 “The bootloader does not use the "normal" CC310 library for size reasons” I got error.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Flib_crypto_config.html

a) In this case we can never enable “ARM Cryptocell” in Secure BLE blootloader. Is my understanding correct ?

b) Will this impact any current consumption as we are using “nrf_cc310_bl backend” which is reduced variant of the “nrf_cc310 backend” ?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_crypto_ecc.html&anchor=lib_crypto_ecc_backend

2) For better clarity about the statement “you need to configure this separately for the bootloader and the application for two reasons”, assume in case of micro-ecc, we need to enable NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED, add library “micro_ecc_lib_nrf52.a” into project, including supporting file and path and then compile.

Whereas in application (Ex: ble_app_blink) no need to enable NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED and add “micro_ecc_lib_nrf52.a”. To my understanding, I can take the application as is and build a package (with private key added) without any modifications. Is my understanding correct ?

a) I got confused with the snapshot in below link, where library is included in application. Without this I generated package and able to uploaded.

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_crypto_backend_micro_ecc.html&cp=6_1_3_11_16_2_3&anchor=nrf_crypto_default_backends_micro_ecc

Thanks & Regards

Vishnu Beema

RE: Enabling Crypto Hardware backend feature on nRF52840

Einar Thorsrud — Tue, 03 Dec 2019 12:50:30 GMT

Hi Vishnu,

1) The HW backend enabling in sdk_config.h is hierarchical. If NRF_CRYPTO_BACKEND_CC310_BL_ENABLED is the only backend enable that is set to 1, then you know that it is used. If you have multiple backends, you need to make sure that the backend itself is enabled (e.g. NRF_CRYPTO_BACKEND_CC310_BL_ENABLED) and that the specific algorithm within that backend is enabled (e.g. NRF_CRYPTO_BACKEND_CC310_ECC_SECP256R1_ENABLED if you will use the secp256r1 elliptic curve support in the CC310 backend). (You will get a preprocessor error if multiple backends are enabled for the same algorithm.)

2) Yes, you can set NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED to 0 in that case.

2a)There is no need to include the uECC library if NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED is set to 0 (but it does not matter much, since it is anyway not included by the linker when it is not used).

3) NRF_CRYPTO_ENABLED must be enabled to use nRF Crypto. You should remember that this is a hierarchy. It is easier to visualize this using a GUI tool, such as for instance CMSIS Configuration Wizard or Keil (you can use the evaluation version of Keil if you just use it to edit sdk_config.h in a graphical way and don't need it for building).

3a) Yes

4) I did not understand the question. Can you explain more? However, you should remember that you need to configure this separately for the bootloader and the application for two reasons: 1. The bootloader and application use separate sdk_config.h files. 2. The bootloader does not use the "normal" CC310 library for size reasons, rather it uses the CC310_bl library. So in the bootloader, you should enable the NRF_CRYPTO_BACKEND_CC310_BL_ENABLED. Note that this is the default for example bootloader projects targeting the nRF52840 DK.

5) The project with debug includes RTT logging, which is very useful when debugging DFU issues etc. It it also built with the public key that is needed to use the exmaple DFU images distributed with the SDK (but you can easily replace it with your own public key, in the same way you will in the non-debug bootloader. The down-side of the debug bootloader is that it is larger in size, which is why the default configuration does not use RTT logging.

6) The system with backend and frontends are there to give you the same high-level crypto API regardless of which actual library of HW is used. So the SDK libraries and examples only has to support the nRF Crypto API, and this will be the same on the nRF52840 (with HW acceleration) and other nRF5 devices. It is described here. (This is the same concept used in other areas of the SDK as well. For instance, the fstorage library has two backends - one for direct flash access and one via the SoftDevice -, but as a user you do not need to care about it, since the API you see is always the same.)

Br,

Einar