The UBOS Shepherd rules their #IoT Device Flock with a Staff

I’ve been doing a lot of thinking lately about how to manage large numbers of intelligent devices in our homes, the #IndieIoT way. Let’s say you pick up two dozen WiFi-enabled motion detectors or thermometers from the store and put them into your home: one or two for each room, hallway, window, attic, dog kennel, and so forth. How is each of them going to:

• know which WiFi network to connect to?
• know the WiFi password and perhaps other network settings they need to connect?
• know who gets to ssh or otherwise log in to them for administrative purposes?
• know who gets to access them as a regular user?
• know where to post new sensor readings?
• know from whom to take instructions for how often to measure and from whom not to?
• and so forth.

It’s the same for web cams, garage door openers, door locks, thermostats, washing machines, and other intelligent devices. Once we have dozens or hundreds of them in our homes, we cannot possibly configure each one at a time, like we need to today.

For example, if you buy a Fitbit Aria WiFi scale today, you first need to connect to its own WiFi hotspot, manually enter your house WiFi password, restart, reconnect to your home WiFi, and hope for the best. If you mistyped, you need to do it again. (I had to redo it twice!) This process is infuriatingly painful for one device, and simply impossible for a hundred.

There’s also the question of security. If I set up one WiFi scale, I can be quite certain that I got it connected to my own WiFi network, and nobody has taken over the administrator account (well, within reason). Why? Because it is such an unusual experience, I will pay attention! But what about if I need to set up a hundred devices? I might easily overlook one, or five devices, which could be used by my neighbor, for example, to spy on me in my bedroom. Or, I could accidentially add my neighbors’ sauna’s temperature sensor to my network, in which case my thermostat will turn my house into a freezer every time he’s having a good time in the sauna. This won’t do.

So we need to do better. And because I’m building the UBOS distro, which is made for these kinds of devices, I needed to come up with something better, and I think I have done so. Today, the solution requires that all participating devices have a USB port as the least common denominator, but this idea could obviously be made more flexible using additional protocols.

Enter the idea of the UBOS shepherd, their flock, and the staff through which the shepherd rules. First, a few definitions, and then, how it works.

The UBOS shepherd is the person who is responsible for the devices in a home. You can think of them as the “administrator” but because the administration is performed in a special way, we think “shepherd” is a better term.

Those devices, we call a flock. Like in a flock of sheep. All sheep are different in a flock, but for the purposes of the shepherd, they are all members of the same flock. Like the devices in my house: they may be different from each other, but still part of the same flock. Currently, they all need to have a USB port.

There is a special relationship between the shepherd and their flock: sheep know which herd and which shepherd they belong to. Certainly, the shepherd knows their sheep, and the sheep probably recognize the shepherd’s crook, aka staff.

The shepherd’s UBOS staff is a standard USB flash drive, but with a particular (very simple) file structure on it.

This is how it works:

The shepherd takes a plain normal USB flash drive, and turns it into their staff, by doing this on their computer:

• renames the device to “UBOS-STAFF”.
• creates a directory called “shepherd”
• creates a few files in that directory that contain all the info that the flock members need to know. (In today’s UBOS beta, we implemented the first one of those: an ssh key that allows the shepherd to ssh into the device, and ubos-admin it.)

Then, to add a new device to their flock, the shepherd simply inserts the USB flash drive / staff into the device’s USB port, and boots the device by connecting it to power. During boot, UBOS will recognize the UBOS staff, pick the relevant information from it, and configure itself in whatever way necessary. In our current implementation, that is just the SSH key; other things like WiFi information will follow.

But the result is a game changer because something so clumsy has become real simple. For example, to put a newly purchased Raspbery Pi 2 into service as an ownCloud server:

1. Put UBOS SD card into Raspberry Pi.
2. Insert USB stick / UBOS staff into Pi’s USB port.
3. Connect power cord to Raspberry, and wait a bit.
4. ssh shepherd@raspberry-pi-2.local sudo ubos-admin createsite, and answer a few questions. The ssh command works securely without password because UBOS has picked the ssh key from the staff, and added it to the shepherd login on the device.
5. Visit http://raspberry-pi-2.local/ to access your new instance of ownCloud. Of course, that works just as well for any other UBOS app.

Note that no password was required. No keyboard or monitor was required. And, because you “touched” the device with your staff, it was rather hard for attacker to get in the middle.

If you have a Raspberry Pi, or Beagle Bone, or a spare x86 server, you can try yourself: UBOS Quickstart. And I’d love to know what you think.