Hello,

Here's a partial answer.

On 05/12/2024 12:49, Bas Prins via mbed-tls wrote:
(…)

But other than that, integrating Mbed TLS would mean:

- figure out which options i want to enable in Mbed TLS

- cross compile it for our arm toolchain

- extend our build scripts to compile against 3 static Mbed TLS libraries

- figure out how to read the CA certificates, and provide them to Mbed TLS

- test and fail, and hopefully be man enough to solve the challenges ahead...

That does seem like a reasonable plan, yes.

undefined reference to `mbedtls_cipher_auth_encrypt_ext'
undefined reference to `mbedtls_cipher_auth_decrypt_ext'
undefined reference to `mbedtls_cipher_free'
undefined reference to `mbedtls_cipher_init'
undefined reference to `mbedtls_cipher_info_from_type'
undefined reference to `mbedtls_ct_memcmp'
undefined reference to `mbedtls_cipher_setup'
undefined reference to `mbedtls_cipher_setup'
undefined reference to `mbedtls_cipher_setkey'
undefined reference to `mbedtls_cipher_setkey'

All of those are TLS code that is not finding crypto functions. I notice mbedtls_ct_memcmp which is compiled unconditionally, so it's not just a problem with configuration. Two things I can think of. First, make sure your build scripts are up-to-date: old build scripts might be missing constant_time.o which didn't exist in ancient versions of the library. Second, make sure your linker command is in the right order: -lmbedtls -lmbedx509 -lmbedcrypto to allow tls functions to call x509/crypto functions, and x509 to call crypto functions.

undefined reference to `mbedtls_ssl_get_max_frag_len'

That function no longer exists in Mbed TLS 3.x, please upgrade your application code. See the migration guide at
https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-3.6/docs/3.0-migration-guide.md#deprecated-functions-were-removed-from-ssl

I followed the suggestion of your documentation, and went for a minimal example configuration. Pure on intuition, I went for "config-ccm-psk-dtls1_2.h". Because the file name suggests it brings TSL 1.2 which is basically all I need. I think.

That configuration is a good example for doing TLS with only pre-shared keys, but not if you use certificates. If you use certificates, I would suggest config-suite-b.h as a starting point. It does TLS 1.2 with a certain set of parameters and has comments to guide you on common things you may want to tweak.

What does "no asymmetric cryptography" exactly mean? Isn't that the pure basis of TLS altogether?

If I want to achieve HTTPS using TLS, is this a good starting point?

On the world wide web, clients needs to be able to communicate with servers that they have no prior knowledge of. Asymmetric cryptography is required for that. But the TLS protocol can also be used without asymmetric cryptography in some specialized environments, e.g. when a few clients are talking to a single server that they have previously been paired with (IoT “dust” talking to a local gateway). In such environment, it's practical to use pre-shared symmetric keys (PSK). If that's not your use case, you can ignore the existence of PSK.

2. Undefined references: wrong configuration, or should I supply some of the implementations?

As mentioned before, I have quite a few linking errors related to the cipher module. I tried to find answers in the documentation, but came up empty.

I assume (again...) that I should be able to get rid of these linking errors by enabling more features in Mbed TLS. But I honestly get lost in #define's. And maybe it's documented somewhere, but I couldn't find it.

At first glance the linker errors don't look to me like a configuration problem, but I'm not sure. We try to arrange for an #error from check_config.h for inconsistent configurations, but that doesn't catch all possibilities.

3. Root CA provided by me?

I assume I need to provide at least one root CA for Mbed TLS to be able to verify the public key provided by the server, at some point, right? I would expect some callback I need to implement where such a root CA was read (in my case, i would have to read if from flash). Am I misunderstanding Mbed TLS on this aspect also? Or did I just miss the obvious spot where to Mbed TLS requests a root CA?

Yes, you'll need to provide at least one root CA. That's mbedtls_ssl_conf_ca_chain() (or other functions in more complicated scenarios). I do notice that the documentation doesn't mention the common phrase “root CA”: it talks about “fully trusted top-level CAs”, which means the same thing but is not the common term. I'll propose a documentation improvement.

Best regards,

--
Gilles Peskine
Mbed TLS developer