The mbed would benefit hugely from some kind of robust AAA framework for secure comms.

I notice that someone was working on a yaSSL port a while ago:

http://mbed.org/users/toddouska/code/CyaSSL/

Have you used this? I'm interested in what people are doing for M2M security on the mbed, care to share your best practices?

Ashley

when I researched SSL/TLS for small-RAM embedded, answer was: need much more RAM. Maybe could squeeze into 125KB, but that's too much.

AES128-CCM can fit in about 24KB, if you want to encrypt the payload and do your own nonce scheme.

OK,

So I revisited this today and got it working.

I re-ported CyaSSL as the version above was an old one and I changed some options.

Here is a test program that uses the VodafoneUSBModem library to connect to a server over SSL:

http://mbed.org/users/ashleymills/code/Encrypted/

It's very rough and ready at the minute and I had to change a bunch of stuff so it's not modular and all the dependencies are forks since I had to make a few minor changes.

This program will connect to a cyaSSL example server (from the cyassl download) on a remote host using PSK auth, over the cellular connection and then send the word "hello" and then quit.

I hope to find the time to provide some clear examples how you would use this with certs etc, but now that I've got this far, it shouldn't be difficult.

Ashley

Did you ever check out TropicSSL? TropicSSL is a fork of PolarSSL/XySSL before they relicensed it under the GPL. I haven't got it up and running yet but it looks a lot smaller than CyaSSL.

No I haven't checked that out, but looking at the github, it appears to not have been touched for 2 or 3 years. My preference would be to go for something that has regular security updates. A couple of years ago for example there were a slew of SSL vulnerabilities around chaining certificates, see for example:

https://www.youtube.com/watch?v=ibF36Yyeehw

You should be able to get cyassl reasonably small by turning off all unwarranted ciphers and setting a few other options; it needs some experimentation.

I had been meaning to look at openssl since it is dual-licensed, but I had imagined that it would be impossible to get it small enough.

Ashley

Actually, looking at http://gitorious.org/tropicssl it would appear there are more recent commits, even this month. This could definitely be worth looking at.

Actually, looking at http://gitorious.org/tropicssl it would appear there are more recent commits, even this month. This could definitely be worth looking at.

I was going to post that link. I haven't checked the logs, but I know of commercial products using Tropic so I assume the bugs have been fixed.

I've had a brief look at importing the codebase for tropicssl. It's not going to be as easy as cyassl as there are a couple of signals not supported by rtx, there are some missing filesystem function calls, and a couple of other peculiarities.

Ergo, I'm going to put that presently unquantifiable task on hold for a bit, because I came across this:

http://axtls.sourceforge.net/

This is another good candidate. It only supports TLSv1.1 (latest TLS version is v1.2), but v1.1 is still considered a secure protocol. To put this in perspective, many people still use SSLv2 which TLS supercedes.

I'll take a look at axtls and come back.

Ashley

OK, so I got round to porting axTLS. It was what's known in the industry as "a ballache", but it works.

Just tested an RSA 1024 self-signed X.509 cert on my server and connected to it using the mbed, and verified it (using it as the CA). Then send a few words back and forth using AES256/SHA encryption. Don't worry about the self-signed bit, you could import other CAs, but of course, you'd have to be careful about space.

I didn't have to modify the mbed library to do this, so I should be able to package axTLS into a reusable library.

The great news is, axTLS is BSD-style licensed so none of the nastiness of cyaSSL license.

With both client and server auth, you could do some cool things.

When I get some free time, my next task will be to publish the code along with a tutorial.

Ashley

Hi Ashley,

Can you share the axTLS code? I'd be quite interested in taking a look at it. I don't really mind if it's in a rough state at this point.

Thanks, Robert

Sure,

http://mbed.org/users/ashleymills/code/AXTLSTest/

If you edit axTLS/ssl/cert.h you can change the default certificate. I tested this with a self-signed certificate.

You'll also have to change the IP of the test server I'm using, since you don't have access to that, but if you compile axTLS on a server and run the server you will be able to see this connect and see two-way encrypted conversation being sent back and forth.

Ashley

Thanks Ashley! I forgot to ask yesterday; what were the RTX problems with Tropic? I took a look at Tropic a while back and the only problems I came across were things like time.h not being implemented.

Well Tropic uses ansi c "signal" function call, for example in calls like "signal(SIGPIPE, SIG_IGN)", and "signal(SIGALRM, sighandler)".

I wasn't sure this was supported by the RTX as it has its own functions for sending signals. I'm sure there is an easy workaround for someone familiar with using that function, but I couldn't be bothered with it as I found axTLS. Path of least resistance :)

It would be worth taking another look at it.

BTW, one thing I meant to mention about any of these implementations is the entropy source. This axTLS implementation uses the RTC to seed the RNG on the mbed, because there is no /dev/urandom, the implementers have this to say about this former approach (from comments):

and

So this needs to be sorted before using this in practice. This looks like a good candidate:

http://mbed.org/users/Remco/notebook/secure-hardware-random-number-using-the-mbed/

Although I've not done any tests yet to see how "random" this entropy source really is.

Ashley

OK, I'll just write here for my own reminder. Concerning SIGPIPE, from man 7 socket:

"When writing onto a connection-oriented socket that has been shut down (by the local or the remote end) SIGPIPE is sent to the writing process and EPIPE is returned. The signal is not sent when the write call specified the MSG_NOSIGNAL flag."

This is also part of the POSIX spec.

The library sets "signal(SIGPIPE, SIG_IGN)", which says to ignore the signal. But the RTOS threads don't understand these signals natively, and AFAIK, lwip doesn't send this signal anyway but it does set errno to EPIPE in such a case. So actually with tropic we can just comment "signal(SIGPIPE,SIG_IGN)" out.

Alternatively, you could define SIGPIPE and SIG_IGN, but since the action is to ignore the signal, it wouldn't make much sense to bother.

I expect the other issues with Tropic are also easy to deal with, but they should be examined closely to ensure everything works as expected.

Hello,

Just to update this topic. I've made some libraries based from axTLS and cyassl to ease the use of SSL on mbed. Here are some links for those of you who are interested :

• TLS_cyassl
• TLS_axTLS

They both have the same public API so if your code is using on of these libraries, you can change the underlying implementations without making any changes to your code.

Then, I also made small wrappers to make GET requests :

• HTTPSClient_cyassl
• HTTPSClient_axTLS

Great stuff François!

I've been working on some DTLS stuff with Cya. Here is an Ethernet example. I also explain howto setup the test rig, and provide a nifty script to generate a self-signed cert for server and a device certificate. The script also generates mbed includes for the CA cert and dev cert+key in DER format:

Caveats:

I've only tested this with a few packets so far, so I can't say anything about long term stability. This may need some tweaking for memory use etc, but it should be a good starting point.

Also, I'm not entirely sure CyaSSL deals with fragmented packets correctly. You'll notice you have to use the -f flag on the CyaSSL test server, which groups packets together. This is something that needs to be looked into.

I'm working on the cellular example, and will keep you posted.

Just thought I'd let you know that I ported tinydtls (http://tinydtls.sourceforge.net/) to mbed:

Here are ethernet and cellular code examples:

I need to add a decent random seeding function to the library port, which I'll do soon.

The port took a while because I spent forever tracking down a nasty gotcha: long story short, tinydtls uses uthash to keep track of sessions and uses sockaddr_in as part of the key. lwip doesn't use a standard sockaddr_in (it splits the normally short sin_family into two uchars sin_len and sin_family). Anything that lwip had touched had sin_len set, but my conventionally constructed sockaddr_in structures didn't which meant an unexpected hash mismatch. The fix for this is to set sin_len manually on conventionally constructed packets if you intend to use them as part of a hash key as interface/address/port.

Anyway, this is all great, and I've sent 2848 messages and counting with the library, but there is one "little" problem at the minute: It turns out that tinydtls isn't actually complete (I guess the v0.4 should have been a clue). The author hasn't finished the key store aspect of the library. What's supposed to happen is you setup a callback which gives you the ID (a string) of the peer, and you're supposed to pass back the key structure for that peer so that the library can perform authentication. However, it turns out that the callback never passes in the ID, because the functionality hasn't been written.

So any callback you write has to either guess what key to try based on host, or just pass back the same key structure each time. Clearly this isn't useful for multiple peers. I've sent Olaf an email to see what his plans are in this regard, but I might try and fix it myself as it doesn't seem that difficult. Until now, you can test this if you want with a single peer (or with every peer having the same PSK).

Cheers

Ashley

Hey,

Good news.

It turns out that there was a secret version 0.5.0 in the repository. Lesson learned, don't rely on downloads pages to be uptodate.

Anyway. PSK is now fixed in that you get the ID of the peer, and can hence choose the right key for the peer in the key callback (useful eh?) :P

In addition they have added support for TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, which means you can use elliptic curve keypairs. I haven't checked which curves they use and whether or not they are the dodgy NSA ones or not.

I have to do some work on setting a suitably random seed for the PRNG, which is on my TODO list.

One thing I noticed when testing this library is that the handshake can be unreliable. The reason is that packets sometimes get lost by the mbed. I wrote a test program to flood the mbed with UDP packets, and indeed you can see it missing packets if you fire them fast enough. I was able to send about 200 packets per second before the mbed started losing UDP packets.

But of course, this loss depends on the load of the mbed. The reason the handshake is more sensitive is because the load is quite heavy due to the cryptographic work. There are a couple of issues here:

1. The handshake protocol should be robust to packet loss. DTLS is designed to re-transmit lost packets, so regardless of whether the mbed is losing packets when it shouldn't, the handshake should not fail. Some work needs to be done to look at ensuring retransmissions are done during the handshake. An interim solution might be to retry the whole handshake at the application layer until it works. This isn't as crazy as it sounds as once you've shook hands you can maintain the session for a very long time. To be fair on tinydtls, I will state that even CyaSSL on mbed also seems to have a non-robust handshake procedure that is very sensitive to packet loss (although I've not tried the absolute latest version).
2. I am a little worried that the mbed is not good at receiving network traffic when under load. Obviously there are limits here as to what can be done. Flooding the mbed with 200 packets a second is not a sensible use case, but receiving one or two packets whilst under heavy CPU load is. I've got some ideas how to explore this further.

I'm going to start using tinydtls in anger over the next couple of months, and I'll discover whether it can be used for a real application in this context. I hope so.

Regards

Ashley