Enabling Crypto Hardware backend feature on nRF52840

Question

Hello, 
 
 I am using nRF52840, SDK_16.0.0, S140 SoftDevice and Segger 4.16 for flashing the image. I am using ‘ble_app_blinky’. 
 I have queries on enabling HW crpto accelerator and back end mode. 
 
 1) If I want to enable HW crypto accelerator then do I need to enable NRF_CRYPTO_BACKEND_CC310_ENABLED or already taken care by NRF_CRYPTO_BACKEND_CC310_BL_ENABLED ? 
 https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_crypto_config.html 
 
 2) If I enable NRF_CRYPTO_BACKEND_CC310_ENABLED, whether there is no need of micro-ecc and can I disable NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED ? 
 a) Even whether there is no need to compile and include micro_ecc_lib_nrf52.a if HW crypto accelerator is enabled. 
 Whether my above assumptions are correct ? 
 
 3) If I want to enable backend crypto, then whether do I need to disable NRF_CRYPTO_ENABLED. 
 a) As per below statement for frontend still needs backend functionality. But if I want backend functionality, still do I need front end by enabling NRF_CRYPTO_ENABLED. 
 “Keep in mind that at least one of the nrf_crypto backends is required to use the API functions” 
 https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v16.0.0%2Flib_crypto_config.html&anchor=lib_crypto_config_automatic_defines_usage 
 
 4) Whether all above macros changes to be enabled only in "Secure BLE bootloader" or even at application (Ex: ble_app_blinky). 
 
 5) What is the difference between “pca10056_s140_ble_debug” and “pca10056_s140_ble” (With and without _debug). 
 
 6) What is the difference between cryptography library with backend and frontend 
 a) (Is backend mean crypto runs in hardware and frontend mean crypto runs is in software. Then in that case what is “software backend” and “hardware backend”. Bit confusion about the terminology. 
 
 Thanks & Regards 
 Vishnu Beema

Einar Thorsrud · Accepted Answer

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

Einar Thorsrud · Answer

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

Einar Thorsrud · Answer

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). 
 beemavishnu said: 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. 
 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

Enabling Crypto Hardware backend feature on nRF52840

Top Replies