mbedtls_pk_write_key_pem() does not work with secp256r1 keys (and tfm?)

[randomdude]

Hi,

I'm writing an app that creates a CSR, has it signed by a (web-)server and subsequently uses it to authenticate to another (mqtt-)server. For the CSR generation and signing part I am using mbedtls, while for the authentication I am writing the credentials to the modem. This only works if I use an externally generated key, because I was not able to export a locally generated key via mbedtls_pk_write_key_pem(), no matter what I tried. The function exits with error code 0xc680, which doesn't seem to be defined anywhere. Furthermore, I haven't been able to use the mbedtls_strerror() function. It looks like it is being built, but the linker cannot find it.

I understand that mbedtls integration with tfm is a work in progress, but I'm struggling to keep up, and I'm afraid I got lost somewhere along the way.

So, to wrap this up let me reiterate:

• What does mbedtls-error 0xc680 mean?
• What do I need to do to use mbedtls_pk_write_key_pem()?
• What do I need to do to use mbedtls_strerror()?

Thanks in advance!

[Sigurd Hellesvik]

Hi Random Dude

What does mbedtls-error 0xc680 mean?

The mbedtls error codes are returned as negative numbers, for example:
"#define MBEDTLS_ERR_PEM_NO_HEADER_FOOTER_PRESENT -0x1080"

So if you handle the error as an unsigned integer, you might get overflow. For your case, 0xFFFF-0xC680 +1 = 0x3980.

And  0x3980 PK - Unavailable feature, e.g. RSA disabled for RSA key.
Which would make sense in your case.

Can you make sure my guess is correct?

What do I need to do to use mbedtls_pk_write_key_pem()?

Try to enable the curve you try to use by setting CONFIG_PSA_WANT_ECC_SECP_R1_256.

What do I need to do to use mbedtls_strerror()?

I'm just giving this a quick guess for now, but maybe this?

#include <mbedtls/error.h>

Regards,
Sigurd Hellesvik

[randomdude]

Hi Sigurd,

the "feature unavailable" error is the only one that makes sense, and it seems that it is in fact mbedtls_pk_write_key_der() that returns it. But I can't figure out why, since iI have CONFIG_PSA_WANT_ECC_SECP_R1_256 (and all its dependencies) enabled. The same goes for the mbedtls/error.h include line. If I don't have the #include, I get a compiler warning, but with it, the linker still can't find the actual function. I confirmed that the source file is being compiled by deliberately introducing a syntax error, which is correctly detected by the compiler.

[Sigurd Hellesvik]

Hi

Lets take a step back:

For the CSR generation and signing part I am using mbedtls

Is it an option for you to use the PSA Crypto API instead or mbedtls. See Crypto Samples for examples.

I think it should be possible to use mbedtls instead. But the PSA Crypto API is newer, and I would recommend it. See Legacy Mbed TLS. (I do not know if mbedtls_pk_write_key_der is legacy, but I can not find it in our docs for v2.0.0.)

Regards,
Sigurd Hellesvik

[randomdude]

Hi,

sorry for the delay, I was on vacation.

Sigurd Hellesvik said:

Is it an option for you to use the PSA Crypto API instead or mbedtls.

Actually, I was under the impression I was already using both. But maybe, while we're at it, let's take another step back:

The task I am trying to accomplish is to locally generate an ECDSA keypair, use that to generate an x509 CSR, have that CSR signed by a web server (that is part of our authentication infrastructure), and then use that signed certificate along with the previously generated private key to authenticate to our MQTT server.

From what I found in the docs and samples, the "right" way to use x509 certificates for authentication is to store them in the modem's credential storage. AFAIK that requires the private key in PEM format, but I haven't found a way to access that. Grepping through the v2.0.2 crypto samples, I havent found anything relating to exporting keys (in PEM format) either.

Maybe there is a better way to do what I'm trying to do, but by this point I am utterly confused by all the crypto options and how they all interact and relate to each other. Even after reading the crypto drivers page, it feels like I haven't learned that much from it, other than nrf_security uses its own fork of mbedtls, and where that is located. But to be honest, after reading that page I have even more questions than before, e.g. how do I tell if I'm using bult-in or legacy mbedtls? Why are there so many duplicated mbedtls related configs and which is which in menuconfig?

Can't tell if this really is this hard, or if I'm just being dense...

[Sigurd Hellesvik]

Hi,

randomdude said:

sorry for the delay, I was on vacation.

No worries, hope you had a nice vacation!

randomdude said:

But maybe, while we're at it, let's take another step back:

The task I am trying to accomplish is to locally generate an ECDSA keypair, use that to generate an x509 CSR

Thanks for the explanation, it makes this more clear to me.

For context, let me explain the two different options using TLS:

Offloaded socket

Offload the networking socket to the modem, and let the modem handle TLS communication.
The modem has its own TLS/DTLS driver.
When doing TLS, you have to have certificates. These certificates will be saved in the modems certificate storage.
Certificates in the modem certificate storage are write-only, meaning that your application can not read them back after provisioning.

Native socket

The application will handle TLS communication.
Certificates will have to be saved somewhere accessible by the application(not in the modem).

In general, we recommend using the offloaded socket.

Then some questions for you:

1. Will you use the certificates for a TLS connection, for some custom purpose, or something else?
2. Do you know if you want to use an offloaded socket or native socket?

randomdude said:

Can't tell if this really is this hard, or if I'm just being dense

Getting an overview over security in addition to all the other parts of an application is complicated, so I would go for "it is hard".

Regards,
Sigurd Hellesvik

[randomdude]

Hi,

let me cut right to your questions:

Sigurd Hellesvik said:

• Will you use the certificates for a TLS connection, for some custom purpose, or something else?
• Do you know if you want to use an offloaded socket or native socket?

The certificate (and private key) will be used to authenticate to our company's MQTT server, and I want to use offloaded sockets if possible. Actually I've already confirmed that part to work.

The problem is, that while I can access and write the signed certificate to a <Public Certificate> slot in the credentials storage, I haven't found a way to access the private key I generated in the very first step, to write it to corresponding the <Private Key> slot.

Sigurd Hellesvik said:

I would go for "it is hard".

Thanks for comforting me . I've been working with freeRTOS and the old nRF5 SDK for quite a while now, so I should know my way around these matters, but the switch to Zephyr caught me a bit off guard, I guess..

[Sigurd Hellesvik]

Hi,

In this case, I do not think you need to generate your keys in your application. You can make your modem generate them for you.

See Securely generating credentials on the nRF9160.

Regards,
Sigurd Hellesvik

[randomdude]

This might be exactly what I was missing. Although the instructions call for an external python script to convert the answer of the modem-KEYGEN command, the parser function in that script reveals that the first part of that answer actually is the CSR, already base64 encoded and ready to go. I'll just have to add the BEGIN/END lines, and I should be set.

I'll code that up and let you know how it works out.

[randomdude]

This actually works! But it seems a bit like a fluke that the function generates exactly the kind of key I need, and makes me wonder what would have been if I had needed any other type of key, like RSA or whatever. Although in that case my original approach could have worked.

But anyway, this will do for now (at least until the mbedtls key writing functions are fixed/fully implemented).

Thank you for your support and your patience!