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]

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.

[Cla]

Sigurd Hellesvik said:

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

I forgot to say. To initialize the private key before writing in the next step.

[Sigurd Hellesvik]

I had one of our crypto experts read though my previous message, and they caught some misunderstandings. I will edit that comment soon after I have posted this.

So instead of that comment, I will suggest how you can do mutual TLS for a client with the PSA Crypto API.

Let's split this into some steps, to keep it tidy.

• Provisioning
  
  • Generate private key
  • Get Client Certificate from Certificate Signing Request (CSR)
  • Get Clouds CA certificate
• Runtime
  • Do TLS handshake

Provisioning

Generate private key

Use the PSA Crypto API. See Crypto: ECDSA sample.

This will generate the key in SPE and store it in ITS. Set CONFIG_TFM_ITS_ENCRYPTED if you want to encrypt ITS. This will use the MKEK to encrypt ITS.

CSR

We do not have a sample for this. See Using opaque ECDSA keys to generate certificate signing requests (CSRs) for a list of steps. Specifically the subsection "Application flow with PSA".

Since we set up mbedtls to use opaque keys, the private key will never be in NSPE for this operation, which is good.

Store the Client Certificate in PS from NSPE. The Client Certificate is public information, so it can be stored however you want really.

The CSR will be done against a CA, often controlled by you. Normally you will sign the Client Certificate against a root certificate or intermediate certificate you have, so that you do not need to store every client certificate in the cloud.

Get cloud server CA cert

The device needs to know the servers certificate to be able to authenticate the cloud server. This is usually done with a Certificate Authority (CA) certificate.

Since the cloud server CA certificate is not secret, it can be stored available to the NSPE. (For example using Protected Storage).

Which cloud server CA certificate need and how you aquire it depends on the cloud server. For example for Azure IoT Hub, that would be the Baltimore CyberTrust Root Certificate.

Runtime

Now that you have configured your device, you have a Private Key in ITS, a Client certificate and Cloud CA certificate in your non-volatile storage (for example Persistent Storage).

Our PSA TLS sample which I linked to earlier show you how to do the TLS handshake using the PSA Crypto API and then communicate over the established link.

I will have a colleguae read through this as well tomorrow, so beware there might be edits. I am learning here as well.

Let me know if you got any questions.

EDIT: Last edit of this post 2024-02-01 09:40