• State Verified Answer
  • Replies 9 replies
  • Subscribers 88 subscribers
  • Views 2718 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 292246
Options

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!

Parents Reply Children
  • 0 in reply to Sigurd Hellesvik

    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.

  • 0 in reply to randomdude

    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

  • 0 in reply to Sigurd Hellesvik

    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...

  • 0 in reply to randomdude

    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

  • 0 in reply to Sigurd Hellesvik

    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 Slight smile. 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..

Related