EEVblog Electronics Community Forum

Products => Computers => Embedded Computing => Topic started by: peter-h on December 02, 2021, 06:01:08 pm

Title: Anyone here familiar with MbedTLS?
Post by: peter-h on December 02, 2021, 06:01:08 pm
With a colleague, I am working on a product which previously used PolarSSL but was later changed to MbedTLS which, in the ST ARM 32F417 implementation, is believed to be less buggy.

It is working ok as far as we have got, but we are finding that as well as needing some 100k more FLASH, it needs nearly 50k of RAM, which on the 32F417 (128k RAM) would normally be OK but due to other required functionality it leaves us just 10k, which is sure to bite us in the bum one day.

The architecture we are using for MbedTLS is a 48k (48k was found to be the smallest that works) static buffer within which TLS runs its own heap. I am aware that in the most generic case one has to have
enough for one 16k buffer (plus a bit) for HTTPS, but what concerns me is that there appears to be no way to determine the worst case memory usage, across various usage scenarios.

It would be great to reduce this 48k to say 30k.

Some of the protocols which come from ST we know we don't need (e.g. PPP) but within any of them there is the question of which cipher suite needs supporting.

What is the minimum cipher suite required to be able to use MbedTLS as an HTTPS client for use with typical current cloud-based file storage or data logging APIs such as Dropbox, Google Drive, Loggly etc? 

And what is the recommended minimum cipher suite required to implement an HTTPS server that would be able to negotiate a session with most current web-browsers?

The goal is to ideally reduce both RAM and code size requirements for use in an embedded device that needs to work both as a general purpose server and client, without requiring support for multiple
 concurrent sessions.

The other thing is that even the ST port of MbedTLS doesn't appear to make use of ST CPU hardware features such as AES256, DES, etc, which the 32F417 has in hardware. This speeds things up hugely but much more importantly in our case, saves a lot of RAM. For example AES256 can use about 10k if done in software.

I think the main questions are

1) Which cipher suites are worth supporting? For example DES arguably isn't, but you never know what some customer might want, and if everybody else thinks DES is dead, there will be money in doing it :)

2) What can be done to reduce the amount of RAM? Digging around the internet, lots of people have been up this path. It does seem strange that this library takes up so much space, given its name...

3) What is the best way to determine the RAM requirement? For example one can't test an HTTPS server with every possible client (although AIUI a 16k RX buffer should always do).

Thank you very much in advance for any input.

Title: Re: Anyone here familiar with MbedTLS?
Post by: soFPG on December 05, 2021, 11:53:25 am
I've used MbedTLS during work and we ended up using TLS v1.2 because, afaik, TLS v1.3 is not supported (at least not in the version which came with Mbed OS).

I had to use a lot of debug functions to track down why MbedTLS would crash after a request.

However, we had an external SDRAM attached to the STM32F4 so enough memory was available.

Unfortunately, we couldn't get it to work 100% reliably because sometimes either the HTTPS JSON-response was faulty (invalid character somewhere in the string) or the board crashed with a Hardfault upon parsing the response.

Up to this day I believe that either there is a bug in the HTTPS code which handles the response or the STM32F4 memory protection unit can't handle unaligned access even if it should be enabled.

In the end, the experience wasn't too great and we ended up with a Qt-App on Raspberry Pi which worked flawlessly after 2 days of work.

We probably did something wrong but I think as soon as you go from HTTP to HTTPs you should think about switching to an embedded linux device which has a complete network stack which is tested for decades.

I remember how many google searches it took to figure out that you have to add a parameter string "st0" to get the DNS working otherwise Mbed wasn't able to resolve the URL  |O
Title: Re: Anyone here familiar with MbedTLS?
Post by: peter-h on December 06, 2021, 09:26:01 pm
I guess most people implementing this stuff are doing it in a company, in a paid job, so can't talk about it in detail. The usual problem... anyone working in this field ends up googling for many hours, finding forum after forum full of posts with zero replies, occassionally coming across a post which points you to a bug fix.

I am not working on this part myself but as the owner of the business I am sort of the "project manager" so need to know roughly what is going on, and I am writing the documentation so I need to understand it. Various things amaze me, especially how non-viable this HTTPS stuff is on typical embedded micros such as a 32F4, whose 168MHz speed, 1MB FLASH and 128k/196k of RAM are otherwise extremely powerful for embedded work. Just the collection of root certificates comes to 200k, and MbedTLS is supposed to be able to traverse through this lot when establishing the identity of a server it is connecting to. There is not enough RAM for a start. It's not fast, either, taking around 5 seconds for the simplest session setup (a "I am alive" ping to a server). It can just about be made to work if you are running a single session, or if you just run TLS to establish a secure session but without server certificate verification (unless the server is a private one in which case you need just 1 certificate stored - probably most "IOT" products are doing it this way).

So no wonder so many people ditch this stuff and stick a board in there running Linux. Then you have proven code, GB of RAM, and can do "everything". An embedded product trying to do this will have a very limited functionality, carefully chosen to do a specific job.

Title: Re: Anyone here familiar with MbedTLS?
Post by: soFPG on December 10, 2021, 09:10:59 pm
Yes, 100% agreement.

I think about it like this: At least there is an option to run HTTPS if you are willing to connect an external SDRAM.

But why did you chose the STM32F4 if you are aware that this would probably be solved much easier on an embedded linux machine?
Title: Re: Anyone here familiar with MbedTLS?
Post by: peter-h on December 17, 2021, 10:08:40 pm
The problem is that if you are going to build a box which can run linux, and run it at a performance level sufficient to even produce config screens which take less than a few seconds to load (ever played with low-end linux boxes like Linksys?), then you are looking at hardware which will cost quite a bit more, and draw quite a bit more power.

The product I am working on has way more than enough performance for its intended application, which includes various "web" (or "IOT", in modern fashionable language) functions. It is just TLS which is proving to be a problem, but we don't need any real performance on TLS; it just "needs to work".
Title: Re: Anyone here familiar with MbedTLS?
Post by: Foxxz on December 18, 2021, 01:09:30 am
One thing I would recommend and have seen others do to lighten the load on the CA cert size is not to install any and provide a method for installing just the one specific for the server you will connect to. Or if you ultimately control the server it will use install your own CA with a 50 year expiration.

I've seen IOT devices just accept any certificate valid or not. But I'm assuming if you are running TLS you want actual security.

If you don't need to encrypt the information but still verify it's authenticity you might go for a more lightweight approach such as a MAC/HMAC/signature based authentication of messages.
Title: Re: Anyone here familiar with MbedTLS?
Post by: peter-h on December 18, 2021, 08:49:41 am
" is not to install any and provide a method for installing just the one specific for the server you will connect to. Or if you ultimately control the server it will use install your own CA with a 50 year expiration."

Yes indeed; this is the conclusion we came to as well.

If talking to a private server under your control (probably the most common solution for "IOT" devices) then you load just that one certificate, and you put the max lifetime on it. Then users can have both encryption and host authentication.

If talking to some "public" site (e.g. although obviously one would not actually be doing that one :) ) then encryption is easy enough because the site will give you that certificate allright, but if you want to be sure you are talking to "" and not a spoofed version then you have much more work. But more importantly you need a secure means of periodically updating the root certificates (around 130 of them, AIUI) because if anybody can get in there to update them, you can be spoofed. Browsers deal with this by grabbing new certificates during a browser update (or maybe the OS itself does it? - if that was actually the case then no browser would now work on winXP or even win7, but FF still runs ok on XP, and win7 is fully functional with all including Chrome). Anyway, this aspect is going to get dropped because we don't have enough RAM for the 200k block. And the current certificate for will change all the time so you can't just preload it and in effect treat as a private server. We do have a serial FLASH file system (FAT-FS) into which we can load a 200k file (so it isn't taking up 200k in the CPU FLASH) and I don't know why MbedTLS can't just read one certificate at a time into RAM - 2k would be enough - as it is stepping through them. I am not the person working on this bit and I only just understand how it is supposed to work. But if MbedTLS (which AFAICT is the typical totally unsupported open source product, with user forum(s) which almost nobody participates on) really needs 200k of RAM for this, it is pretty useless for "embedded" work.

There is no obvious way to securely update the root certificate block in an embedded system which is an industrial product, with no keypad/LCD, and has to work for many years. The most obvious option (holding a button at power-up, or similar, or doing it via USB) needs physical access. And needs this to be documented, but any docs will be lost after a few years, if not immediately. Same problems with a remote update; the product will either have to be on an open port (which raises all sorts of issues) or has to fetch a certificate bundle from a private server (which needs to be maintained, "for ever"). Then the customer ends up with a time bomb. In the early 1980s I designed a product which had code to generate day of week from the date (an industrial multizone heating controller, which had different programs for different days, so needed to know the day of week) and the way I did it would break after 29 years. So they would all stop working in 2012 :) The company selling it went bust in 1993 so nobody faced the music for it but I am sure a fair number (1000s were sold) were still installed and running in 2012. But that product had a user interface and the fix was to set the date 29 years back :)

BTW we don't have enough pins left on the 32F417 (QFP100) to connect an external RAM chip.