SSL is supported, but not mandatory because a lot of the hardware we're targeting just isn't up to the task.

We're aware this isn't exactly optimal. Suggestions welcome.

Re: Key revocation, that's a good question and we should probably think hard about it. It's trivial to create a new stream, but obviously that could be a pain for various reasons.

You might check out stuff like Amazon's web services (DynamoDB, etc.) for inspiration. They sign requests with a hash of the request data and private access key (and date, etc.) so the private key doesn't need to be sent in the request. The data is still visible if it's over non-SSL but it keeps the key from getting out.

Yeah no SSL support on Arduino-capable hardware is a bummer. I have been able to do Amazon's signature generation on an Arduino without too much trouble though (just need to run SHA256 hash algorithm a few times). I would definitely think about key revocation and renewal since folks will need it if someone steals their keys.

Signing might be doable like that but it all depends on the size of the data that you're pushing. if it's a long string of readings that might not be so easy since you might not be able to fit everything in memory still (These devices routinely have <4k of ram). Might be doable to go byte by byte as you build the message and output it. It's certainly a challenging problem.

Yep the libraries I've used can generate a hash byte by byte luckily without loading everything in memory. Here's an example of how I call Amazon services and generate a signature on an Arduino: https://github.com/tdicola/CloudThermometer

You could always some form of SRP[0]. It shouldn't be too much overhead to do only when your session times out. At the very least you're 1) not sharing secrets 2) limits reply attacks to a finite amount of time.

The other method might be, as a sibling said, HMAC the message with a shared private key. If you can specify that clocks should be pretty close, your reply attack window becomes small.

[0]: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

We are having the SSL/security discussion in a lot of places, but it would be great to focus the effort here if possible: https://github.com/sparkfun/phant/issues/49

Security on 8-bit microcontrollers is one of the hardest problems we've encountered when building this service, and I think it's going to take a lot of community support to help us figure out a good solution that works on most devices. Thanks for all of the input so far!