Reference for mutual TLS and private key handling

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Tue, 20 Aug 2024 10:54:58 GMT

Hi again,

I made this sample recently to do CSR in v2.7.0. Maybe it can be useful to you:

PS: The patch in the sample currently breaks TF-M, but I am working on that.

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Mon, 05 Feb 2024 13:11:53 GMT

"psk" is for TLS with Pre-Shared Keys (PSK), which our PSA TLS drivers do not yet support for PSA Crypto.

Can I suggest that since TLS-PSK is kindof a corner case here, you start by trying to learn how to do TLS with asymmetric encryption?

RE: Reference for mutual TLS and private key handling

Cla — Mon, 05 Feb 2024 12:02:17 GMT

Thanks, you are right.

I do not fully understand. My understanding is now, the private information is in the `psk`, it is loaded with `tls_credential_add` in `tls_set_preshared_key` (in the sample from hard coded dummy_psk). The sample does not cover the safe storage of the psk. Do I understand correctly, that after a reset, the key is not persisted and needs to be loaded in (via NSPE-RAM) using `tls_credentila_add`-function again?

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Fri, 02 Feb 2024 11:38:18 GMT

From tls_set_credentials_from_ps:

Function for fetching the CA certificate from Protected Storage,

This gets the certificate, and the certificate is not secret, and is therefore it is not a problem to have this in NSPE RAM

RE: Reference for mutual TLS and private key handling

Cla — Fri, 02 Feb 2024 09:59:48 GMT

[quote userid="106736" url="~/f/nordic-q-a/107489/reference-for-mutual-tls-and-private-key-handling/466995"]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.[/quote]

I have maybe one follow up. In the sample, if I understand correctly, it still loads the key into NSPE RAM in the function `tls_set_credentials_from_ps`, did I understand correctly, that this can not be avoided?

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Wed, 31 Jan 2024 16:11:20 GMT

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

RE: Reference for mutual TLS and private key handling

Cla — Wed, 24 Jan 2024 16:56:35 GMT

[quote userid="106736" url="~/f/nordic-q-a/107489/reference-for-mutual-tls-and-private-key-handling/465816"]So we are on the same side, what will you use this randomness for?[/quote]

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

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Wed, 24 Jan 2024 13:44:07 GMT

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.

[quote user=""]Generate cryptographic randomness[/quote]

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

[quote user=""]

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.

[/quote]

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.

[quote user=""]Can slots in the KMU be used to store the private key forgoing the need for protected storage altogether?[/quote]

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.

[quote user=""]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?[/quote]

This is not the way, see above.

[quote user=""]How many space is in the KMU? I understand 125 slots a 128 bits/slot?[/quote]

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.

[quote user=""]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 ?[/quote]

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

[quote user="Cla"]From the sample you linked, I understand, that one would add the credentials anew with `tls_credentials_add` after each reset. Do you agree?[/quote]

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.

RE: Reference for mutual TLS and private key handling

Cla — Fri, 19 Jan 2024 16:49:09 GMT

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?

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Fri, 19 Jan 2024 15:36:10 GMT

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.

RE: Reference for mutual TLS and private key handling

Cla — Thu, 18 Jan 2024 15:06:25 GMT

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`?

RE: Reference for mutual TLS and private key handling

Cla — Thu, 18 Jan 2024 12:54:47 GMT

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?

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Thu, 18 Jan 2024 12:50:05 GMT

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?

RE: Reference for mutual TLS and private key handling

Cla — Thu, 18 Jan 2024 12:46:00 GMT

client

RE: Reference for mutual TLS and private key handling

Sigurd Hellesvik — Thu, 18 Jan 2024 12:41:52 GMT

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