Reference for mutual TLS and private key handling

[Cla]

I intend to implement an application on nrf9160, that makes use of mutual-tls to communicate with a peer.

To this end, I need to store a private key in a save place on the nrf9160 and create tls-sockets from it.

My understanding of the recommended approach is as follows:

1. Comparing the developer.nordicsemi.com/.../README.html flash a provisioning image to initialize the HUK, hardware unique keys.
2. Flash the production image, that has protected storage enabled.
   1. Generate cryptographic randomness
   2. Write it to protected storage
   3. The protected storage will encrypt it using the identity key `NRF_KMU_SLOT_IDENT`
   4. Then write it to internal trusted storage (optionally additionaly encrypted with NRF_KMU_SLOTMKEK if configured that way by selecting CONFIG_TFM_ITS_ENCRYPTED)
   5. Read it to NSPE-RAM from protected storage to create csr with mbedtls.
   6. Read it to NSPE-RAM from protected storage to hand it off to zephyrs tls_credentials_add-API.

From devzone.nordicsemi.com/.../persistent-storage-of-keys-and-data-using-the-nrf-connect-sdk I understand, that the recommended approach would be to use the crypto api to generate a key with persistent live-time. This stores it in ITS, but would that not be unencrypted unless above config is set?

Am I understanding the recommended approach correctly?

Are there better alternative? For example:

1. Can slots in the KMU be used to store the private key forgoing the need for protected storage altogether?
2. Can the key be derrived from a HUK every time before use forgoing the need to store it anywhere persistently? If so which HUK shall be used?
3. How many space is in the KMU? I understand 125 slots a 128 bits/slot?
4. Is there an alternative to tls_credentials_add and mbedtls sockets, that allows to store the information persistently in some other way? Maybe developer.nordicsemi.com/.../sockets.html ?

Edit: please fix your forum. I had a much harder time making above text show properly then it should be.

[Sigurd Hellesvik]

Hi Cla,

Let me start by not answering anything of what you ask and instead ask you a question:

Are you going to use the nRF9160 as a client or server?

Regards,
Sigurd Hellesvik

[Cla]

client

[Sigurd Hellesvik]

In that case, we usually recommend that you do TLS operations in the modem of the nRF9160, and not in the application.
The modem has its own security features, so you do not have to handle that yourself, which will make life easier for everyone involved.

To make sure this is not an XY Problem:

Is there any reason that you use the application for TLS instead, and are you sure that is the way you want to do it?

[Cla]

Thank you for your reply. I intentionally asked the question as openly as I could to check, if there are alternatives, that I am unaware of.

Please note, that I am not intending to use the nrf9160 for LTE. Instead I am using it with other networking interfaces.

Can the TLS operations of the modem be used with (zephyr) sockets, that do not use the modem (LTE) but some other networking interface?

If no, that is the reason that I use the application for TLS.
If yes, could you give me some more information on it?

[Cla]

In other words, I am attempting to ask: what is the best way to do Y? Y=`generate and securely store a private key for mutual tls on an nrf9160 on a network interface, that is not LTE`?

[Sigurd Hellesvik]

My first though is: Why in the world would you use a nRF9160 and then go ahead and use another network interface?
So if you want to entertain my curiosity, I am curious to what you are doing? (optional)

However, that is besides the point. I agree that in your case, it makes sense to use TLS from the application, so I will help you with that, which is why you are here after all.

Yes, TLS from the application is what I would recommend.

I think the PSA TLS sample might be what you are looking for, but I suspect that you have seen this sample already.

Next week I will look into the questions you got in the top of this ticket, cause I need to read some on this to be sure before I give answers.

[Cla]

Thanks.

From the sample you linked, I understand, that one would add the credentials anew with `tls_credentials_add` after each reset. Do you agree?

[Sigurd Hellesvik]

EDIT: I wrote a new answer here:  RE: Reference for mutual TLS and private key handling. See that instead of this comment. I also removed some things from this comment, so it will be inclomplete.

Generate cryptographic randomness

So we are on the same side, what will you use this randomness for?

• Read it to NSPE-RAM from protected storage to create csr with mbedtls.
• Read it to NSPE-RAM from protected storage to hand it off to zephyrs tls_credentials_add-API.

You dont want to have keys in NSPE-RAM if you can avoid it. We use opaque keys for this instead. See the other newer comment for more info on this.

Can slots in the KMU be used to store the private key forgoing the need for protected storage altogether?

Instead of using the KMU for the private key, we recommend generating the private key in the PSA Crypto API, which will make it live in ITS, and use opaque key handling from there. If you want the ITS will be encrypted with the Hardware unique key (HUK) of type MKEK, which lives in the KMU for the nRF9160.

Opaque key handling is when you only use a reference to the key, and not the key itself. This makes it possible to call crypto APIs (PSA or mbedtls) from the NSPE without having the key in the NSPE.

Can the key be derrived from a HUK every time before use forgoing the need to store it anywhere persistently? If so which HUK shall be used?

This is not the way, see above.

How many space is in the KMU? I understand 125 slots a 128 bits/slot?

See KEYSLOT.KEY[n].VALUE[o] and KMU.
From the latter:

" In total there are 128 key slots available, where each key slot can store one 128-bit key value together with an access policy and a destination address for the key value. Multiple key slots can be combined in order to support key sizes larger than 128 bits. "

I think you are correct that 3 slots are already used, so that would be 125 left yes.

Is there an alternative to tls_credentials_add and mbedtls sockets, that allows to store the information persistently in some other way? Maybe developer.nordicsemi.com/.../sockets.html ?

See the newer comment mentioned above were I suggest how you should do this.

Cla said:

From the sample you linked, I understand, that one would add the credentials anew with `tls_credentials_add` after each reset. Do you agree?

The sample is for TLS communication, not for generating certificates. The PSA TLS sample assumes that you already have certificates and keys.

 The sample seems to only use tls_credentials_add for NSPE. If you have a look at all the code in the "non-secure" folders, which confusingly enough are for code running when we build with TF-M, it uses something else.

The tls_credentials_add in main is only used for preshared keys, as we do not support this in PSA Crypto TLS yet.

See how tls_set_credentials points to either non-secure folder or secure folder, all depending on if TF-M is enabled or not.

EDIT: This comment was last edited 31. Jan 17:18. I changed it quite a lot then, so if you remember something from last time you read it, that may have changed. Sorry for the possible confusion.