Embedded Security - TCP/IP, SSL, XBee, Encryption?

For the past while I have been digging around getting communications working between development boards and computers. There are many examples for using TCP/IP, XBee, Zigbee etc and using them to send and receive data, this is all fine.

Now I get to the point where I want to prototype a light bulb or thermostat and the question of security comes up. I remember there was a popular brand of WiFi light bulb that had a security issue where it would broadcast a key or a piece of information that could be used to gain unauthorized access to the entire WiFi network. I think this has since been resolved in a firmware update.

What are the current best practices for implementing secure communication? I think for TCP/IP the standard is to use SSL, and although I can find lots of information on SSL and what it is I do not find much on the specifics of actually implementing it. I know the SSL channel/socket needs to be established and this requires the use of a key. But how does this part of the dance work? How do you share a key without an established secure channel, this at first glance would look to be troublesome because if anyone is eavesdropping on the communication they can capture this key as well before the security is setup.

With all the rage about IoT I am looking into prototyping my own gateways and devices mainly out of exploratory interest. Personally the architecture I think is most robust and secure is by having a local network of devices communicating to a gateway server (windows based at this time). This allows for a few things, the gateway server can handle much more traffic than an embedded device and can evolve over time to provide network protection / device discovery / over the air device firmware updates etc. in a central location instead of having to update each device individually to handle cross cutting concerns. It can act as a firewall to the embedded IoT devices.

So for now to explore everything I want to have embedded development boards with both Xbee/Zigbee/RF module AND WiFi communication. It can be configured to either go through a gateway or to serve to the internet directly using WiFi.

In all cases authentication/authorization and encryption remain the final question marks. Is there any good information out there that explains it through examples? What is the 30,000ft view? The way I see it is that I need to get all my communication going without any security and then add in the security code.

For example I could have a dev board with a TCP/IP stack and web server, then add in a SSL module. Now I need to add access control to protected areas with a login mechanism. So if someone connects to a device over the web they will see a page with any public information and a login option. After logging in they can control things with their level of authorization. How would you handle the login, since the secure channel has not been created the password they send to initiate secure communication would be sent in plain text.

Another example would be XBee communication. They offer 128bit AES out of the box but you can choose to disable this and use your own encryption. So to get two modules communication securely you would need a key for the encryption/decryption. How would this key be shared to initialize the encryption. If you wanted to offer a XBee dongle for a computer where you could securely login to any XBee node on the network the above example would apply. Instead of a webpage it would probably be a text based console that offers the same display/login functionality. But again they would need to enter in a key/password to initiate the secure channel, since it is getting initiated using this key, the key itself would be sent in plain text?

I did read about some security documents that outline using a public/private key system and having each board loaded with a pre-shared key. This key would be used to establish an encrypted channel so the above scenarios would have the encryption established before the user logs in, thus sending their password in an encrypted channel. So is this what is typically done? Why were those light bulbs sending out information in an unencrypted format that could be used to compromise the network?

As it should be painfully obvious I am new to all the security aspects, so even something that describes security in general for embedded/desktop applications would be useful. What are the different strategies/architectures/libraries/techniques that are used and accepted as reliably secure?

Ok there are really two related concepts that you need to deal with in somehting like this:

Authorisation (Am I supposed to respond to stuff you send) and crypto (We should prevent any unaurthorised node receving these signals from figuring out what they say).

The second part is relatively easy in theory, if devilishly hard to get right, the first part is a pain in a consumer product.

Taking the second part first (becuase you really need that working before addressing the first part), there are a couple of common approaches.

You can give every device that belongs to you an explicit shared secret in some way (WIFI sort of does this) and use that to key the encryption (AES128 is as good a symetric cypher as anything for this sort of thing), easy but now the user has to be typing keys into all their devices.

You can fit a magic button that when pressed on both ends initiates a key exchange (Google "DH key exchange" for the way to do this securely (Depends on good random number generators on both ends), see most bluetooth things for examples of this kind of pairing.

Both of these have the virtue that an explicit user action has taken place to connect the device to a network, and you can be pretty sure that any packet you get that decrypts correctly is something you are authorised to be interested in (Because the keys are secure).

Once you have a secure link the device can tell the controller its serial number which can then be used as a unique address for talking to the device over the encrypted channel, easy.

The problem comes when you do not have that magic button that you can use to trigger pairing, because then our 'lightbulb' has to advertise its presence (Which has to be effectively in the clear because there can be no unique shared secret at this point), the controller then notices and starts the key exchange game (The trouble is there could be more then one controller in range).....

The bulb people just stuffed up, it happens, crypto is notoriously hard to get right, which is why everybody sane uses an existing library.

Now, none of this is a problem on a grown up microprocessor with gobs of ram (well ok, 16Kb+ and no power constraints), but it becomes a major problem when the target is something that wakes up once a day, has 128 bytes of ram and runs from a coin cell.

I highly commend a copy of "Applied Cryptography", probably still THE book on this stuff.

You may also want to track down a recording of "Milking the digital cash cow" a talk given at 30C3 about how not to do NFC security.

Regards, Dan.