Cybersecurity features for NRF52 chips

[Ildar]

Good day!

I'm interesting in ability to support of some required Cybersecurity features by NRF52832 or/and NRF52840:

1. Is it possible to fully disable JTAG and/or SWD?
2. Is it possible to implement Flash protection (from rewriting/erasing/readaback)?
3. Is it possible to implement secure boot? (encrypted bootloader with CRC checking of flash area)

Thanks in advance!

Regards

[endnode]

(oh lord, CS buzzword;)

Hi,

1. Yes, read about that in the product specification.
2. Yes, see the link above and this.
3. What do you mean by that? Neither nRF52832 nor nRF52840 has any HW security feature to protect tempering with the processor/memory/inputs during the run-time so how you would achieve any security during the boot? The only thing you could use is ARM CryptoCell features for HW accelerated crypto in nRF52840 but that won't guarantee that FW you are going to execute is "genuine". You can indeed implement it in your app code (e.g. store some checksum in one-time programmable UICR registers and then as first action verify that flash content - or at least content of some flash pages - matches that). But without any HW protection you cannot be sure that someone haven't hacked flash read/write protection so it has very limited effect...

Edit 2-july-2017:

Thanks to Bjørn's confirmation there actually IS Secure Boot possibility with ARM CryptoCell Root-of-Trust feature on nRF52840, more resources on that to be released;) Still to be seen how really temper-resistant this mechanism is.

[bjorn-spockeli]

No, we do not have any resources showing how to use the Cryptocell for Root-of-Thrust yet. The current SDK examples, found here, only shows how to use it for hardware-accelerated cryptography. We need some time to add the ARM CryptoCell libraries into our SDK, but rest assured, the support will come.

[bdjukic]

Hi Bjørn,

Thanks for the prompt response and detailed answer! This is exactly what I was looking for.

Have a great weekend,

B.

[bjorn-spockeli]

Happy to help :)

[jm_laird]

Hi Bjørn,

Are you able to give any example code of how to use this functionality and explain it's restrictions e.g. if only the normal CC310 library can use it or if others can?

Thank you

[bjorn-spockeli]

Hi Jamie, 

I am afraid that we do not yet have an example showing a Secure Boot implementation with the features mentioned in my previous comment. The ACL peripheral should be straightforward to use, but the CC310 library part is a bit more complex and we do not have a lot of examples or a lot of documentation.

It should be possible to implement secure boot without using the CC310, i.e. using SW based crypto libaries instead of HW crypto accelerators and using the ACL to restrict access to the Root Key and the CC310 register. 

Bjørn

[Garrett]

bjorn-spockeli

We don't mind digging through documents, have an NDA with Nordic, and are nearing completion of a product we we are hoping to implement secure boot for.

I would like to get ahold of any and all info regarding the CC310 implementation and options for secure boot in NRF52840.

https://www.mbed.com/built-with-mbed/multisensor-industrial-asset-monitor

[bjorn-spockeli]

Hi Garret, 

I apologize for the late reply. 

The ARM Cortex M4 on nRF52840 does not have any trusted execution environment like the M33 on the nRF9160. Hence, we have focused on implementing a secure boot chain for the nRF9160 in the nRF Connect SDK based on MCUBoot, see http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/index.html. 

We do therefore still  not have any sample code showing how to use the CC310 in a "secure boot-like" configuration, i.e. use the root key to verify the application prior to pasing execution to this. 

The bootloader from the nRF5 SDK already uses the ACL to protect the bootloader upon boot and verifies the CRC of the application before passing execution to the application. Modifying this to use the CC310 should not be too much effort. Note the bootloader will have to write the Root key to the CC310 registers so the root key will then either have to be stored in flash or in an external secure element and then retreived by the bootloader upon boot. 

Best regards

Bjørn