NRF9160 Secure Access Token storage, Non-Secure vs Secure Boot, Key Management Unit etc

[GJSea]

Hi,

I'm looking for some design guidance on how to properly secure the device, code, access tokens etc.

- Does secure boot protect the device from being re-flashed and used for another purpose?
- Does secure boot prevent an acquired device from being debugged using JTAG, can a hacker view running code and variables in memory?

- In addition to the typical CA certificates which nrf_inbuilt + sec_tag accomodates for TLS, we have our own Secure Access Tokens to access our cloud service.
What is the best way to store these so they can be formatted into a connection string using sprintf (that goes over TLS)? Clearly string formatting will
require these to be brought into SRAM. Would the KMU be the best approach to store these assuming it is available for Secure Boot? There don't appear to be any working C examples of
this being used, are there any? As they're being brought into SRAM and potentially viewed using a debugger is the only benefit of using KMU to prevent casual browsing
of the flash storage for secrets? Any other recommendations?

- As nrf_inbuilt requires the BSD_LIBRARY is the provisioning approach to get prepared for a final Secure Boot deployment, to run the Non-Secure version of the firmware to do
the provisioning from the CERTIFICATES_FILE, and then switch over the Secure?

- Any things to watch for to support FOTA updates and a Secure Boot firmware image.

Thanks!

[Martin Lesund]

Hello GJSea,
Just for your information, what was once known as "Secure Boot" is now called "Secure Partition Manager" to comply with the ARM specification, so I will refer to this as SPM in this post.

---

- Does SPM protect the device from being re-flashed and used for another purpose?

- Does SPM prevent an acquired device from being debugged using JTAG, can a hacker view running code and variables in memory?

The SPM does not protect the device from being re-flashed.

The SPMs task is to configure the permissions and resources of the non-secure app and then booting it.

For additional information about this please check the "secure vs. non-secure" section in the NCS tutorial.

How to actually prevent anyone from re-flashing the device can be done by enabling APPROTECT.

This will block debuggers to have read/write access to all CPU registers and memory-mapped addresses.

(Non-volatile memory controller Documentation)

---

One option you can use is to store keys/credentials, is in the modem flash as we have done with the nRF Cloud Certificates to be able to connect to the nrfcloud.com (aws_server).

(The samples e.g. the Asset_tracker/LTE sensor Getaway uses these credentials to connect to the cloud)

To provision credentials to the modem flash, you can use the utilize the use the nrf_inbuilt_key APIs (see the nrf_inbuilt_key.h file in the nrfxlib repository).

• Please check this code snippet on how you can do this.

The provisioned credentials cannot be read out from the application side once it's in the modem flash, so they are safe.

You also have some other ways of keeping your data/keys secure:

- CRYPTOCELL — ARM TrustZone CryptoCell 310

- KMU — Key management unit

---

The BSD library has to run in the non-secure area as seen in the figure above.

---

With regard to the last question I would recommend checking out the AWS FOTA documentation as well as the "multiple-images builds" documentation.

(AWS FOTA sample)

I hope I've understood your questions correctly. If something is unclear please let me know.

Best regards,

Martin L.

[GJSea]

Thanks Martin, I was wondering if you could expand on the kinds of attacks that a secure application would protect against, if I'm interpreting correctly an attack done remotely over the network interface in order to reflash it for another purpose, and/or an exploit it to steal secrets from memory?

It seems that APPPROTECT would prevent physical hacking/reverse engineering of the device, so secrets couldn't be stolen or anything reverse engineered over SWD. Clearly possession of the device and a complete flash erase gets it back to a zero-firmware state in which case it is useless bar its physical $$ value.

Do you have any C examples using KMU functionality?

Thx!

[Martin Lesund]

Hi GJsea,

I will have to come back to you on some parts of your questions to give you a good answer.

 But I would recommend checking out this Blog: Why TrustZone Matters for IoT which include some good information about the Secure/non-secure domain.

---

GJSea said:

It seems that APPPROTECT would prevent physical hacking/reverse engineering of the device, so secrets couldn't be stolen or anything reverse engineered over SWD. Clearly possession of the device and a complete flash erase gets it back to a zero-firmware state in which case it is useless bar its physical $$ value.

 That is true, but if you enable ERASEPROTECT before APPROTECT you should be covered in that case as well. (ref. https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf9160%2Fchapters%2Fdif%2Fctrl-ap.html&cp=2_0_0_8_1_3&anchor=ctrlap_unlocking)

I do not think we have an official sample using KMU, but I will see we have something that can be of assistance.

Best regards,
Martin L.