Posted on Tue 22 November 2016

IOT security: the key and the castle

People just don’t take security seriously, because security is hard to understand and hard to implement and hard to maintain. We need a new way of “doing” security, and I’ve got an idea. Let’s go back to the notion of skeuomorphism: we use pictorial representations of real-world objects to represent similar functions in a graphical user interface. The floppy disk icon that means save, the little printer that means print and the iconic handset that looks nothing like a modern telephone that means call are all examples of skeuomorphic design.

Your home is your castle, so let’s put a 3D-printed case on a specialized IOT gateway device that looks like a Castle. On top, a slot for a nice large physical key. About the size of a small TV remote control would be good.

In order to attach a new IOT Thing to your network, you need to lock it to your house with the Key. Plug the Thing in (or charge it, or whatever) and bring the Key over to the Thing. The Key has a little blue hollow circle LED lit up.

Maybe the Thing has a keyhole icon printed on it somewhere; possibly a button needs to be pushed. When the Thing and the Key have talked to each other, the blue LED hollow circle winks off, and a green LED dot turns on.

Take the Key back to the Castle and put it in the slot. The green light blinks off.

What just happened?

The Key contained configuration information for your Castle network. An IP address, a one-time code to establish wifi authentication, an encryption password to talk to the Castle. When you brought the Key over to unlock your Thing, that information was sent to the Thing via a very short range wireless communication system. In return, the Key received requests from the Thing:

  • it would like to receive connections from certain network ranges on certain ports,
  • it would like to contact a particular domain name on a specific port
  • it expects about so much traffic on average,
  • and about so much traffic on a bursty, short-term basis
  • it will send about so much traffic on average
  • it would like to talk to other devices in your Castle with certain protocols and capabilities

and those requests were communicated to the Castle when you brought the key back to it.

Now the Thing can talk to the Castle, over an encrypted connection. All communication needs to happen via the Castle, which will decide whether or not the Thing can talk to anything else. The requests that the Thing made are not changeable over the air; you’ll need to walk the Key around again if you want them to change.

Now, the Castle will need to have a user interface to manage all these connections. It should probably have two representations: a text config file system for nerds and automation folks, and a web-based, graphical system for everybody else. Either way, changes are not actually made on the Castle until a physical button is pressed to commit those changes.

In a very real sense, your home is your Castle.


© -dsr-. Send feedback or comments via email — by continuing to use this site you agree to certain terms and conditions.

Built using Pelican. Derived from the svbhack theme by Giulio Fidente on github.