I have been looking more into SSL/TLS on embedded systems and though I would share my initial findings. Feel free to give any input you have working with embedded SSL/TLS codes.
Essentially in the long term I want to provide a complete code base for internet applications on Procyon (http://http://teholabs.com/products/procyon.html).
For a long time I was only really aware of MatrixSSL as an option for embedded systems. At some point though I stumbled upon this wikipedia note:
http://en.wikipedia.org/wiki/Comparison ... mentations (http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations)
It is a good read for certain. There appears to be enough choice.
From the tables contained in the above the lightest code bases are axTLS and PolarSSL. The most complete SSL/TLS for an embedded system seems to be CyaSSL.
As it turns out PolarSSL was originally XySSL which had a BSD license. When the original author stopped maintaining it, it was updated as PolarSSL and then relicensed as GPL or commercial only. I personally find that extremely distasteful. I would not find it distasteful if you simply GPL your fork of a BSD project, but to dual license something and attempt to draw a fee to allow a commercial use from a formerly BSD licensed project? Ick. The new maintainer is offering "support", but basically his stance seems to be you have to either contribute money or time. (see the 6th post: http://polarssl.org/forum_view_topic?topic_id=27 (http://polarssl.org/forum_view_topic?topic_id=27))
[I also should note if you significantly modify a BSD project and want to charge for it I also don't find that distasteful that is after all the point of permissive licensing! A significant modification should either be some sort of new concept or a significant rewrite]
My personal view is such compulsory requirements mean it is not free. This caused me to look if anyone had forked the BSD version or if I simply could find the older BSD version, sure enough someone had:
http://www.stackfoundry.com/open-source/tropicssl/ (http://www.stackfoundry.com/open-source/tropicssl/)
Both PolarSSL and CyaSSL offer a FOSS exception to allow use with other OSS approved licenses, frankly I find that quite annoying as well.
So in summary of what code bases I find usable from a licensing prospective:
TropicSSL and axTLS are clear winners in terms of the license
CyaSSL and PolarSSL are GPL V2 + FOSS which is less desirable
Next I looked at the code bases.
CyaSSL looks the most complex, and that is born out in terms of the code size (27kLOC). Meanwhile PolarSSL/TopicSSL and axTLS come in at less than half of that with 12-14kLOC.
In terms of file/module organization TropicSSL/XySSL/PolarSSL looks a bit better than axTLS at least at first glance.
I conclude that if I want to have the most robust SSL/TLS I should look to port CyaSSL. If I want the freest SSL I should adopt axTLS or TropicSSL/XySSL. axTLS is still maintained by the original author while XySSL is not.
That concludes my thoughts for now.
Edit: fixed character inversion on TLS
Cool investigation, thanks for sharing. I'll post up an excerpt, but you should do a blog post. This is good info :)
I figured it would be easier to discuss with others in a forum than on my blog but I just mirrored it on the blog.
I was hoping that some others would have opinions. For instance if I build on top of FreeRTOS or something it would basically have to be GPL anyway. Nuttx could still be BSD as could bare metal SSL + TCP/IP stack though what kinds of OS like calls these libraries need I haven't looked into yet. To me it looks like axTLS needs a POSIX environment to function. That is a pretty big requirement. Meaning I lean toward the old BSD XySSL or a derivative of that still BSD, but it isn't maintained (TropicSSL doesn't look all that active either) and I have a lot on my plate, too much to become the maintainer of an SSL library. Happy to help but maintainer is probably too much.
Thanks for all this accumulation of knowledge :D .... I was just thinking about how I want to do some ssl comm from the cm4 board I'm expecting soon and my server .. the first thing I thought of was to use yassl (the yet another ssl implementation that's used in general mysql setup) and to try to convert it to embedded env (have not looked at the code yet) but looks like there's bunch of implementations already :D ... sorry I can't be of any help attm but I will go trough all these you mention and check them myself ... if I stumble upon something interesting I'll post here
Hi Arhi,
yaSSL certainly looks the most complete (and CyaSSL is targeted at embedded). If you are used to it that might be the best way for you to go. Check out the code base of TropicSSL or PolarSSL though pretty modular looking to me, but you may well be a better programmer and be able to point something out I didn't notice in my 10 min glance at the SRC.
I'm not "used to" yaSSL, it's just implementation my "peeps" made and "only" one I ever used :D so I wanted to start there without actually checking what's available. I will definitely check now first what's out there in the embedded market before I start using anything... anyhow it looks like it will have to go on hold for now as the project I hoped I will finalize in few weeks just shown itself to be way bigger then I anticipated
Hi Brian,
Thanks for the info here, very valuable. I am starting an embedded project that will heavily depend on secure cloud comms. Looking at using the Spark Core with NuttX, but now my next question/concern is around security.
Have you, since this was originally posted, done any updated research into the topic?
Have you done an actual embedded project using SSL, and if so, can you share some of the info wrt the libraries chosen, problems encountered and related issues?
Much appreciated
Andre.
When computer on a board systems dropped to below 50 dollars I stopped thinking about pushing this type of system. Now if I wanted a complex system I probably would use a BBB + external system to do any absolute real time stuff, unless it is just a box and then I would use something with the nicest software stack or power use or whatever (MSP430, M3/M4/M0 or AVR-8; I haven't worked with PIC. AVR-8 for slow USB devices, MSP for low power, M3/M4 for everything else).
Brian