The Security Model

To speak plainly, there is a wide range of security properties with respect to the Internet of Things and home automation peripherals. Although there are some exceptions, the properties run the gamut from horrific to rather unfortunate.

Bearing that firmly in the front of your mind, here are the basics:

Perhaps the best suggestion for securing your network is to run all your things on a closed network attached to the steward's host, and have the steward run an additional interface for talking to the rest of your home network, i.e. get a Mac mini or Linux box with two Ethernet interfaces and a Wi-Fi interface.

In this scenario you would put all your wired things (e.g. Philips Hue lightbulbs) on the first Ethernet interface, put all your wireless things (e.g. the Netatmo weather station, Nest thermostat) on the Wi-Fi interface running with a hidden, randomly generated, 16-character SSID and a 16-character* WPA2 password. Then connect the second Ethernet interface to your home network, which is for your general purpose computing (e.g. your laptop, phones, tablets, and other devices). You will need to enable DHCP/NAT so that things like the Netatmo, Nest, etc., can upload and talk to their cloud back ends.

* 16 is the maximum password length supported by the Nest, in case you are wondering why we chose 16 characters as the maximum.

The Bootstrap

First, the client should be on a computer that's on the same network as the steward.

Whenever a client connects to the steward for the first time, the client warns that the certificate being used by the steward is untrusted. At this point, two actions must be undertaken:

Verifying the certificate

Compare the fingerprint reported by the client with the fingerprint in the file:


on the machine running the steward, e.g.

steward% cat sandbox/server.sha1
SHA1 Fingerprint=9E:DF:5F:C4:17:E2:3E:D3:88:E2:74:17:D6:93:91:8D:96:1D:9A:E1

If the two values match, then the client is talking directly to the steward; otherwise, there is another device on the network which is performing a man-in-the-middle attack. Find it and "fix" it as is appropriate.

Client (not user) Authentication

Clients authenticate to the steward, and the user associated with a client is authorized to invoke various API calls. There is a 1:N relationship between users and clients.

If no users are configured on the steward, then an unauthenticated API call from a device on the same network as the steward may be used to create the initial user and client.

Authentication: Time-based OTP (TOTP)

When a client is created, the steward responds with TOTP information allowing the client to authenticate itself. The methods used by the TOTP algorithm are based on RFC 6238, so programs such as Google Authenticator can be used for web-based access.

Privacy: HTTPS or SSH

After a client is created, it may upload an SSH public key fingerprint and retrieve a privacy package from the steward containing:

Note that at present, these steward ignores the SNI hostname and uses the same private keys for all clients. This will likely change in a future release.

HTTPS access

Whenever the client connects to the steward for API access:

SSH access

Note that at present, ssh is not implemented; please use https instead.

Whenever the client connects to the steward for ssh access:

Authorization: Roles

A user has one of five roles:

Security Roadmap

Security is everyone's problem. In the near future we intend to;