axTLS, embedded security

Recently we were faced with the fact that our current encryption model isn’t strong enough to satisfy some of our more demanding customers. After discussing the possibilities of writing our own encryption model based on public strong encryption standards we finally decided to go for a SSL solution. Building upon an existing and proven standard carries much more weight than reinventing the wheel and I was faced with the task of locating a suitable SSL implementation for our embedded systems.

The first two implementations that popped into my head were of course GNU TLS and OpenSSL. After investigating both solutions I came to the following conclusions. GNU TLS has some external dependencies, such as libgcrypt and libgpg-error. As I want to keep dependencies to a minimum since we integrate them with our build system, which can be a painful process, that sort of spoke against GNU TLS. Though OpenSSL didn’t have any external dependencies we couldn’t already satisfy it had a problem which also plagued GNU TLS, it had a rather large footprint. Somewhere in the vicinity of five times larger than the binary it was going to be linked with. This was clearly something that would be difficult to motivate.

After some googling I discovered three very interesting alternatives, MatrixSSL, XySSL and axTLS. All designed for embedded systems and having an acceptable footprint.
MatrixSSL costs money for commercial use so I decided to push it to the back of the queue. XySSL had some weird problems on our platform resulting in the infamous “TANGO15 reboot“. axTLS, while only supporting TLSv1, worked flawlessly, was easy to compile and had a footprint of roughly 50% of the binary it would be linked with. Performance isn’t a factor for the application in questions and hence it was not investigated.

If you are looking for an SSL implementation for an embedded system and TLSv1 is good enough for you I can highly recommend axTLS.