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

Factory write of non-volatile storage items

Hello,

Our product has two pieces of information that must be programmed during production: a shared secret key (128 bits) and a public, unique device identifier, also 128 bits.

For our application, it is sufficient to store this information in the nRF9160 internal flash and use  APPROTECT UICR bit to prevent reading from the outside.

The simplest approach to storing these two pieces of information appears to be the Zephyr Non-Volatile Storage.

But I have two practical questions:

 1. after setting the APPROTECT bit, can a non-secure application read/write from/to flash ? 

 2. is it possible to populate the NVS sector without using the application ? By this I mean, in production  can we write the device unique key and ID 

     directly to the NVS sector ? If so, what is the format of the data, in this case ?

Parents
  • Hello, Nelson!

    1. Setting the APPROTECT bit should not affect the non-secure partition's ability to read/write from/to flash. We do have mechanisms for doing this as well, but the APPROTECT just locks the system for external access.
    2. This is possible in theory, but as NVS essentially is a file system it's not a trivial task. The NVS memory structure would need to be replicated on the host computer so that the data can be written on the correct format.

    Could I suggest storing the values in the UICR instead? For example in One-Time Programmable (OTP) memory and/or using the Key management unit(KMU)? It should be possible to write to these directories directly, and they can be accessed by the secure partition of the application (which can expose the information to the non-secure partition if necessary).

    Best regards,
    Carl Richard

Reply
  • Hello, Nelson!

    1. Setting the APPROTECT bit should not affect the non-secure partition's ability to read/write from/to flash. We do have mechanisms for doing this as well, but the APPROTECT just locks the system for external access.
    2. This is possible in theory, but as NVS essentially is a file system it's not a trivial task. The NVS memory structure would need to be replicated on the host computer so that the data can be written on the correct format.

    Could I suggest storing the values in the UICR instead? For example in One-Time Programmable (OTP) memory and/or using the Key management unit(KMU)? It should be possible to write to these directories directly, and they can be accessed by the secure partition of the application (which can expose the information to the non-secure partition if necessary).

    Best regards,
    Carl Richard

Children
  • Hello Carl,

    Thanks for your reply.

    I can change to use the OTP and the KMU, but my application will be running as non-secure because I need to use the modem. It is not clear to me what is possible to do with the OTP and KMU from a non-secure app. So I have two follow up questions:

    1. can the non-secure app read data from the OTP memory ? 

    2. can the non-secure app write (only write, not read) a new key to the KMU ? This is necessary because our device must support updating keys in the field 

    On a side note, the link you provided for the OTP memory is not working. I searched the SDK (I am using version v1.5.0) and only found the function "nnrfx_nvmc_otp_halfword_read"  the modules\hal\nordic\nrfx\drivers\include\nrfx_nvmc.h header. Which left me wondering how to write to the OTP ? Is it through the function call nrfx_nvmc_halfword_write() ? Or does it have to be part of the image ?

     Thanks again,

     Nelson

  • Hello again!

    1. Yes, this can be done by using secure entry functions as I have described in this answer
    2.  I must ask internally about this. I'm inclined to suggest that it might be possible to do using a secure entry function, but at the same time it doesn't make much sense to be able to write to a secure memory from a non-secure partition. The modem flash does support updating keys with write-only permission from the application processor.

    Could you try the links again? We had a short downtime on the documentation. For writing to the UICR (including OTP) you can use the nrfjprog command line tool or the function call you've already mentioned. For a demonstration on how keys can be written and read you can check out the Bootloader storage source code.

    For your initial question I also got back from the developers that a possible way of preparing NVS data is by creating an emulated image with the native_posix target where the desired data can be stored in a binary file. 

    Best regards,
    Carl Richard

  • The link works now, it was indeed a temporary issue.

    It is clearer now what storage options exist, and I will discuss internally on how to use them. In theory using the OTP and the KMU are the best options, but we need to check our use cases and also how feasible it is to setup the devices in production.

    Thanks again.

Related