This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

TLS credentials secure storing to nrf52840-dk

Hello everybody, I am using Zephyr with the nrf52840-dk device. I would like to store the DTLS credentials with a secure way. I don't want to be part of the code and thus to be written raw in flash. Any proposals?

  • Hi,

    The nRF52840 does not have secure flash or a KMU, so you have to store your key in normal flash. You could potentially protect the data using ACL so that it can only be accessed by code running in a specific region (typically in a bootloader, though I am not sure if that makes sense in your use case). You should also protect the flash using APPROTECT so that it cannot be read using a debugger, but then you should be aware of IN-133. Another alternative if you have very high security requirements is to use an external secure element that holds your credentials and handles any crypto operations involving it. That would obviously increase your BOM, though.

  • I can not have an external secure element. Is there any example on how use ACL? I am using zephyr but I can not find something relative. Thus, I have to find something from the nrf SDK or nrf5 SDK and then to integrate in Zephyr. Correct? For this reason a need an example and/or a guideline. Also, could I have two specific region which can have access? (with the bootloader logic I have somehow to "announce" the credentials to the APP partition). Finally, what difference has the ACL with the APPROTECT register? Is there any example using the APPROTECT?

    Thank you for the detailed answer

  • Hi,

    Nikos Karamolegkos said:
    Is there any example on how use ACL? I am using zephyr but I can not find something relative

    You can use the fprotect_area() function. There are a few examples where it is used in nRF Connect SDK.

    Nikos Karamolegkos said:
    Also, could I have two specific region which can have access? (with the bootloader logic I have somehow to "announce" the credentials to the APP partition).

    Yes, you can have multiple regions. But this does not work as I suspect you hope. The ACL will effectively block reading (if that is how it is configured) from the specified region after it is enabled. See ACL for details about how ACL itself works.

    Nikos Karamolegkos said:
    Finally, what difference has the ACL with the APPROTECT register?

    ACL blocks access to parts of the memory from the CPU. APPROTECT blocks debugger access. So they are quite different, though both are features for restricting access to the flash in some way.

    Nikos Karamolegkos said:
    Is there any example using the APPROTECT?

    Yes. With the current nRF devices that is just a matter of writing to the APPROTECT register in UICR during programming. So it does not really have any implications for your firmware itself.

    There is one possibility which I did not mention before that you could use to protect your certificate somewhat. You could use a device root key which you provision the CC310 with during boot, and then lock the flash page holding the key using ACL in the bootloader (after provisioning CC310). Then you could use a derived key to decrypt the certificate (which has been encrypted using the derived key during production). See nrf_cc3xx_platform_kmu.h for more. Unfortunately there is no example of this at this point.

  • I am not sure that I understand. Could you explain more why to sections for the ACL is problem? Also, about the device root key idea can you explain more? What is the derived key and how this helps?

  • Hi,

    Nikos Karamolegkos said:
    Could you explain more why to sections for the ACL is problem?

    Maybe I was unclear. Using multiple sections is not a problem. But You will not be able to read a section (from anywhere) after it is locked. So I am not sure that is what you want?

    Nikos Karamolegkos said:
    about the device root key idea can you explain more? What is the derived key and how this helps?

    Using a device root key gives you a possibility to protect your DTLS credentials in the way that you do not need to store them in raw flash, as you asked for in the original question. But that is not straight-forward, and it is not perfect.

    Let me explain the root key idea in more general terms first. The CC310 supports a root key which can be inserted at startup, and held in secure RAM until reset. Then you can subsequently use that to derive keys that you use for crypto operations. So you could do something like this:

    1. In the bootloader, insert the root key in CC310. Then lock access to the flash page holding the root key so that it can no longer be read (until next reset, and then the bootloader does the same thing).
    2. In your code you can derive a key from the root key. During production you use that to encrypt the DTLS credentials and store them encrypted.
    3. In the field you can decrypt the DTLS credentials using the derived key.

    As you see from above, the DTLS credentials would not be stored in cleartext in flash. However, the key that is used to encrypt it must be. It could provide a bit more security, and is the best you can do using only the nRF52840 and no other HW.

1 2 3 4