Coen Roest

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

6 years, 8 months ago.

RAM requirements mbed TLS with CA certificate chain verification

Hi,

The mbedtls forum seems to be a bit quiet at the moment but maybe someone here can help me.

What are the memory requirements for mbed TLS when verifying a CA certificate (x.509) of a server? I believe this setting is switched on using MBEDTLS_SSL_VERIFY_REQUIRED in mbedtls_ssl_conf_authmode().

Is the whole chain loaded in RAM and verified at once or are the certificates loaded in RAM one by one? Or is this something that can be switched using a setting? This has quite some impact on the required RAM in case of a long certificate chain.

Cheers!

I had similar question during my server/client setup. As I was controlling both server/client end I could use own CA.

Way around I got(for now) is switching role of endpoints. Micro as TCP server + SSL client ! with remote PC as TCP client + SSL Server.

posted by Pankaj Jagtap 20 Sep 2019

1 Answer

Hanno Becker
6 years, 8 months ago.

Hi Coen!

first, certificate verification is performed if the authentication mode, as configured by mbedtls_ssl_conf_authmode, is either MBEDTLS_SSL_VERIFY_REQUIRED or MBEDTLS_SSL_VERIFY_OPTIONAL. The difference is in how the result of the verification affects the ongoing handshake: For MBEDTLS_SSL_VERIFY_REQUIRED, the handshake stops immediately, while for MBEDTLS_SSL_VERIFY_OPTIONAL, it is up to the application using Mbed TLS to inspect the failure flags and to decide if it considers them tolerable or not, or alternative to report them appropriately before failing.

Regarding the RAM usage, your right in that currently the CA chain needs to be present in RAM, for two reasons:

  • Firstly, handshake messages are currently entirely reassembled in RAM before being passed to the respective parsing functions. In particular, even if the certificate handshake message is implicitly (TLS) or explicitly (DTLS) fragmented, there will always be a contiguous buffer allocated in RAM large enough to hold the whole message.
  • Secondly, the certificate verification routine expects the CRT chain as well as list of trusted CA's to be present in RAM at the time of verification.

We are currently working on some alternative messaging infrastructure that allows for gradual message processing, so while I cannot make promises, there's hope we can cut down the RAM usage for CRT chains and CRT verification in the future.

I hope this helps - please feel free to ask more questions,

Kind regards,

Hanno, Mbed TLS team member

Accepted Answer

Hi Hanno!

Thanks for your answer. Can you give me an estimate of the typical RAM usage of an Amazon / Azure certificate? Would an MCU with 128kb of RAM be enough or is it too tight?

posted by Coen Roest 05 Apr 2018

Hi Coen!

I cannot comment on the size of Amazon / Azure certificates, but relevant factors would be the length of the certificate chain as well as the type of public keys they contain (e.g. Elliptic Curve keys are shorter then RSA keys for the same level of security) - do you have the possibility to inspect the certificates on a test system? Regarding your second question, I think the size of the overall system stack is more relevant here than the size of the certificates: What Mbed components are you using, and how are they configured? When it comes to the configuration of Mbed TLS, there are multiple ways through which you can reduce the RAM footprint, as detailed e.g. in https://tls.mbed.org/kb/how-to/reduce-mbedtls-memory-and-storage-footprint (note also that there has been a very recent addition of the option MBEDTLS_AES_FEWER_TABLES which allows to save 6kb of RAM when using AES, see https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.h#L461). In particular, you have the possibility to downscale the incoming and outgoing data buffers (which default to 16kb each) and to inform the server about it through the MaximumFragmentLength extension, see https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/ssl.h#L2127.

I hope this helps!

Kind regards,

Hanno, Mbed TLS team member

posted by Hanno Becker 05 Apr 2018

Hi,

This post is very useful. I am using mbedTLS in low (RAM) memory footprint system. I am having 1 question here. Once verification is done , while reading the data from server, do we need to keep certificates in RAM. Is it necessary. Is there way to clear memory once initial authentication is completed.

Thanks bala

posted by balabharathi d 30 Jul 2018

Hi bala,

currently, the peer's CRT is stored for the lifetime of the TLS session, and you can access it anytime through the mbedtls_ssl_get_peer_cert() function, see https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/ssl.h#L2741. Beyond that, the CRT is used internally to make sure it does not change on a renegotiation.

Now that you brought up this point, though, we are internally considering to allow removal of the CRT after the initial handshake.

Kind regards,

Hanno, Mbed TLS team member

posted by Hanno Becker 01 Aug 2018