• State Verified Answer
  • Replies 17 replies
  • Subscribers 70 subscribers
  • Views 8791 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 213624
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Saving root key on battery powered devices

bperrin2

Hi,

On battery powered devices, how is it possible to retain a root key when changing batteries? 

The crypto cell has an Always On power domain for retaining device secrets but it seems to work when crypto cell is disabled for power saving reasons. However, it doesn’t seems to retain keys when not powered. Or are the keys stored in flash zone only readable by the crypto cell?

If not what will be the proposed solution by Nordic?

Thanks in advance for your support.

Bernard

Parents
  • 0

    Hi,

    You cannot retain the root key within CryptoCell, and the nRF52840 does not have any secure flash, so you have to store it in (normal) flash. You are still able to keep the key in a reasonably secure manner using something like the following strategy:

    • Store the key in a reserved flash region.
    • Enable read-back protection using Control access port. This prevents a debugger from accessing the flash (the only way to disable it is to first do a full chip erase).
    • In the bootloader:
      • Read the key from flash and copy it to CryptoCell (secure always on RAM).
      • Enable ACL to protect the key so that it cannot be accessed by the application.

    The above procedure should keep the root key safe against most kinds of attacks, but it does not provide protection against decapping. If you need that, then the only option is to use an additional device, such as for example the OPTIGA Trust X instead.

  • 0 in reply to Einar Thorsrud

    Thank you for your clear answer.

    If we consider decapping as a possible attack: is the solution to have an extra chip safe? I guess it will be possible to sniff the communication lines between the Infineon and the nRF chips when it try to get the master key. The exchange could be encrypted with a key but this will require to store this key somewhere starting with a chicken and egg problem. Am i wrong?

    I have another question concerning the JTAG: is it possible to connect / disconnect it by software. For example, we would like to have it disconnected by default and reconnected when a demand is done by the smart device via a secure connection (with a second level of security above BLE). This could be required for example during maintenance operations.

    If this is possible, I would be very happy to get a pointer to a coding example.

    Bernard

  • 0 in reply to bperrin2

    Hi,

    The point with using the OPTIGA Trust X in this case is that it provides secure key storage. You can only write keys to the Trust X, never read it back. The key is safe there and is never communicated to the nRF52840. Instead, any data that needs to be encrypted or decrypted must be sent back and forth to the Trust X, as this has the key(s).

    You cannot activate the debug interface from firmware once it has been deactivated. The only way is to do a full chip erase (see Control access port). (Note that the nRF device only has SWD, not JTAG).

Reply
  • 0 in reply to bperrin2

    Hi,

    The point with using the OPTIGA Trust X in this case is that it provides secure key storage. You can only write keys to the Trust X, never read it back. The key is safe there and is never communicated to the nRF52840. Instead, any data that needs to be encrypted or decrypted must be sent back and forth to the Trust X, as this has the key(s).

    You cannot activate the debug interface from firmware once it has been deactivated. The only way is to do a full chip erase (see Control access port). (Note that the nRF device only has SWD, not JTAG).

Children
Related