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.

[Martin Lesund]

To add on what is mentioned in the blog: Why TrustZone Matters for IoT 

I asked internally and got a extensive reply from an expert for this technology.

GJSea said:

 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?

•  What can we guard against with Trustzone-M?

Based on what is portioned into secure firmware, the contents of the secure firmware are guarded against tamper and access from the non-secure side of unauthorized application/services.

The unauthorized access may be from a remote service on the network, or malicious access through peripherals if the peripherals have been marked to be non-secure.

Some functions of the secure firmware, by design, are made available to the non-secure side, for example, the crypto APIs.

If correctly designed, the APIs can protect the assets (Long Term and Short Term keys), while making the operations of confidentiality, authentication, and integrity made available to the user of these APIs.

Ensuring the availability of these services, is also a matter of design, remember that the interrupts and interrupt priorities are shared between the secure and non-secure applications. Hence, the availability of certain functionalities is critical, then, this must be catered for.

---

Coming to the reflashing of the firmware, the download of malicious firmware may be hard to prevent, however, the use of malicious firmware can be prevented, and this applies both for the secure and non-secure partitions of the firmware.

The bootloader can verify the signature and integrity of the firmware before booting it.

The asset to be guarded here is the public key or its hash against tamper.

The firmware signature and integrity checks are performed only on boot, hence, if an adversary managed to inject code and execute it from RAM, then, the bootloader can neither detect or prevent this. The usual guards of making the RAM non-executable apply here.

---

To summarize:
Trustzone-M facilitates additional privilege levels in the system apart from the conventional privileged and unprivileged modes.

Another contribution if the ability to guard against peripherals that have the ability to DMA into any part of the memory overriding the MPU configurations.

A Non-secure application can no longer access memory marked as secure.

Its is up to the system designer to consider the assets and threats and to identify the privilege or access rights of each component in the system given the toolbox of:

1.  The four privilege levels in the system (secure - privilege, secure unprivileged, non-secure privileged, non-secure unprivileged)
2. The MPU configurations in secure and non-secure domains. Note that there are opportunities to lock the MPU configurations if desired to protect against change, however, this may or may not be useful based on user threads in the OS.
3. The read, write, execute permissions on SRAM and FLASH.

I hope this answered your question.