cancel
Showing results for 
Search instead for 
Did you mean: 

STSAFE-A110 and MbedTLS - Authenticating IoT device to MS Azure IoT Hub

naNEQ
Associate

Hi,

In our application, we want to authenticate our IoT devices in Azure IoT Hub using X509 certificates with the help of STSAFE-A110. The application is written in Zephyr RTOS and is using the MbedTLS library for the TLS part. Using the in-tree Zephyr libraries for secure sockets, it is necessary to load the device private key and certificate, in the simplest way from an MCU Flash memory. They are eventually used when calling the functions mbedtls_pk_parse_key() and mbedtls_x509_crt_parse(). My goal is to integrate STSAFE-A110 in this process, so that the device private key and certificate are stored in STSAFE-A110 instead of the MCU Flash. I'd like to get some feedback on whether the process sounds reasonable.

I suppose the process would look something like this:

  1. While in production, we should provision STSAFE-A110 with the device's individual certificate. It needs to be like this, because authentication in Azure requires that the subject common name is the same as the unique id that the device is registered in IoT Hub.
    1. First, we should ask STSAFE-A110 to generate a new private key in slot 1.
    2. Then, we generate a CSR based on this key.
    3. The CSR is given to the PKI and the device certificate is returned.
    4. The device certificate is stored in STSAFE-A110 memory zone 1.

  2. In normal operation, the MbedTLS library should be instructed to establish the TLS connection using the key in slot 1 and the certificate in zone 1.

I suppose we can't avoid step 1 (certificate provisioning in production). It's probably not a good idea to use directly the leaf certificate and private key in slot 0, since all STSAFE-A110 chips share the same PKI.

Step 2 is one topic that I have doubts about whether the whole concept works. As mentioned, the libraries currently require the private key to be present in a buffer in the RAM, but this is of course not going to work, since the private key in STSAFE-A110 cannot be read out. So how to do it? I studied thoroughly the sample code given in this topic by @Benjamin BARATTE, but it doesn't contain an example of how to use the private key and certificate inside the STSAFE-A110 for TLS communications with MbedTLS.

Additionally, if searching for information inside the github repo of MbedTLS, my understanding is that waiting until the new PSA crypto API is fully rolled-out, with support for opaque drivers for the secure elements, is generally better. See for example here. Any thoughts on this? When using the PSA crypto API and the opaque drivers, is perhaps the only difference that a private key will never exist in the code, not even as a struct? I'm not sure I fully understand this topic.

Any comments are welcome! :)

2 REPLIES 2
Benjamin BARATTE
ST Employee

Hi @naNEQ,

 

Thanks for your interest in STSAFE-A solution.

For your application, the STSAFE-A perso service provides possibility to have the STSAFE-A UID in the certificate CN. Also, we a custom perso of the STSAFE-A, you can have a dedicated CA certificate and then use the STSAFE-A solution directly with Azure IoT Hub.

For the second part, you will need to patch the MbedTLS usage by Zephyr RTOS to avoid calling the mbedtls_pk_parse_key() but instead create a mbedtls_pk_context with custom mbedtls_pk_info_t structure like in the code example I have provided the article.

Unfortunately, the interpretation of Zephyr RTOS doing explicit call to mbedtls_pk_parse_key() is not a inline with SE implementation. Even with the PSA API with opaque structure but this will requires update on Zephyr RTOS also.

Could please point me to the Zephyr piece of code your are mentioning ?

I will check what we can propose to update this part to make it compatible with the MbedTLS example.

 

Best Regards,

 

Benjamin

 

Hi @Benjamin BARATTE,

thanks a lot for your insights and help.

The subsystem that has this kind of approach I described is the implementation of TLS sockets, so it is integral part of the communications, if one choses this path.

You can have a look here for parsing the private key and here for parsing the x509 certificate. Both are called when this function is called in tls_mbedtls_init().

I suppose there need to be changes, so that the function mbedtls_ssl_conf_own_cert() is called directly and mbedtls is instructed to take the private key and certificate directly from the STSAFE-A110, right?