Products > Embedded Computing

Anyone here familiar with MbedTLS?

(1/4) > >>

peter-h:
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.

soFPG:
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

peter-h:
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.

soFPG:
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?

peter-h:
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".

Navigation

[0] Message Index

[#] Next page