Cybersecurity features for NRF52 chips

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Tue, 23 Jul 2019 14:21:02 GMT

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

RE: Cybersecurity features for NRF52 chips

Garrett — Wed, 17 Jul 2019 18:58:53 GMT

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

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Mon, 23 Jul 2018 07:41:27 GMT

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

RE: Cybersecurity features for NRF52 chips

jm_laird — Tue, 17 Jul 2018 08:02:04 GMT

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

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Fri, 06 Jul 2018 10:48:25 GMT

Happy to help :)

RE: Cybersecurity features for NRF52 chips

bdjukic — Fri, 06 Jul 2018 09:33:54 GMT

Hi Bjørn,

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

Have a great weekend,

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Fri, 06 Jul 2018 08:43:57 GMT

bdjukic: We have exposed the CryptoCell registers for storing the Device Root Key within the CryptoCell, see CRYPTOCELL — ARM TrustZone CryptoCell 310, which is then used by the CryptoCells AES HW. This Device Root Key can then be used by the secure boot code that you can put in the bootloader and then protect using the ACL peripheral, see ACL — Access control lists.

Best regards

Bjørn

RE: Cybersecurity features for NRF52 chips

bdjukic — Thu, 05 Jul 2018 14:27:28 GMT

Any update on the CryptoCell Root-of-Trust API?

Thanks!

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Wed, 02 Aug 2017 09:14:50 GMT

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.

RE: Cybersecurity features for NRF52 chips

endnode — Wed, 02 Aug 2017 09:05:29 GMT

Interesting! Any resource to learn how exactly this Secure Boot works (= what HW features are on nRF52840 except crypto acceleration itself)? Is there any execute lock register/module? What can be run and from what "code" before executing single instruction stored in flash?

RE: Cybersecurity features for NRF52 chips

bjorn-spockeli — Wed, 02 Aug 2017 08:52:17 GMT

@endnode: You are correct that the ARM CryptoCell-310 on the NRF52840 allows you to do Secure Boot, and that this has not been implemented into our Secure Bootloaders yet, i.e. we only allow updates from trusted sources, but we do not verify that the code that is about to be executed against some key/signature/checksum.

RE: Cybersecurity features for NRF52 chips

endnode — Tue, 01 Aug 2017 12:24:23 GMT

From what I see in nRF52840 Product Specification (Objective = preliminary) it looks like CryptoCell is just HW accelerator for certain algorithms (= functions) which has dedicated RAM but all the code is executed through library which is loaded in standard user-space (flash). No sign of "Secure Boot" (these diagrams are probably generic ARM CryptoCell-310 block diagrams where Secure Boot is with dashed lines so probably optional and implementation dependent), almost looks like TrustZone is only TM/Copyright technology to give you better feeling (don't want to be mean, it has nice features and in any form - even just this bare HW crypto accelerator - it helps, but it's not uncommon in this "cybersecurity" space to sell just buzzwords and trademarks...)

RE: Cybersecurity features for NRF52 chips

endnode — Tue, 01 Aug 2017 12:18:05 GMT

You are right, there seems to be this phrase however there were no resources to that when I was trying to evaluate back in winter during release time of preview DK. All what I see in nRF5 SDk V13.1.0 is Secure bootloader for Nordic Device Firmware Upgrade, no real secure boot (= attestation of memory and other HW components before any custom SW is run on MCU) as far as I cn see... but I would very much like to learn the details if I'm wrong!

RE: Cybersecurity features for NRF52 chips

Ildar — Tue, 01 Aug 2017 12:13:52 GMT

Thank you very much! Your answers are very helpful!

I also read that nRF52840 has ARM Crypto Cell with secure boot support www.nordicsemi.com/.../ARM-CryptoCell-310

Also there are few examples in SDK v13 named Secure Boot, I will try to understand them. It is better than nothing :)

RE: Cybersecurity features for NRF52 chips

endnode — Tue, 01 Aug 2017 11:50:21 GMT

Oh yes, TrustZone, it looks so secure on these colorful boxes, doesn't it?:) From my point of view you are putting hope into things which sound better on paper then in the lab during penetration tests. Anyway back to nRF52: no, it doesn't provide any HW routines to verify some memory against some key/signature/checksum. As I said, you could implement something like that in your APP FW but that won't be the first code running on the MCU. To be as close to start-up as possible you could develop your stack which would reside at the beginning of flash (normally there is Nordic stack with their MBR segment) and write this in early code (typically in ASM). But still there are doubts how much is such SW protection valid when the HW itself isn't protected against things like glitch/fault attacks, EM eavesdropping etc...

RE: Cybersecurity features for NRF52 chips

Ildar — Tue, 01 Aug 2017 11:44:04 GMT

Oh that's ok! Many thanks to you.

And how about support something like ARM TrustZone? www.arm.com/.../trustzone

I need to prevent any unauthorized or maliciously modified software from running.

Does nRF52832 or nRF52840 support something like this? infocenter.arm.com/.../index.jsp

RE: Cybersecurity features for NRF52 chips

endnode — Tue, 01 Aug 2017 11:18:57 GMT

(oh lord, CS buzzword;)

Hi,

Yes, read about that in the product specification.
Yes, see the link above and this.
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.