Thanks to Pekka Jäppinen for comments on the text.

Background

My initial inspiration for getting into home automation was the fact that my dad started to build a house to “the middle of nowhere”. He currently works about 800 kilometers from the house with visits to the house being on average about every two weeks or so. As the occupation is so low, there’s no point in having the house at a constant +22 degrees Celsius. The energy bills would be massive, especially as the temperatures in Finland are anywhere in the range of -35 to +35 degrees Celsius, with long cold periods during the winter.

Current system

The system consists of 7 temperature sensors and 5 relays, all attached to Onewire. The temperature sensors determine the state of one relay, which controls a 6 kW boiler. 6 kW isn’t enough to keep the house warm, but there’s enough power to keep the house clearly above freezing point under any circumstances. Temperatures are measured from both floors of the house, boiler room as well as outgoing and returning circulation water of the boiler. Of course there’s also a sensor for outside temperature etc.

Hardware running the automation is currently ODROID-U2, although all the stuff is platform independant. I run the same code (although newer, WIP-version) at my flat on a normal desktop PC. The system is coded mainly with Django, a Python framework for building web-based applications. Django was chosen mainly because I like Python and it also hides the “ugly side” of databases, wrapping all the objects as classes, which can be manipulated quite easily. Also Django has quite solid security record and has tools for setting privileges for users.

Reliability and security in home automation

For reasons mentioned before (occupancy of the house, extreme temperatures etc), I’ve always designed all the hard- and software with reliability being the first priority. If the outside temperature is around -30 C and the house is kept around +8 - +10 C even couple of hours of downtime might be catastrophic. The house is kept warm by warm water circulating under the floor. If the pipes freeze, the repair costs would be calculated in tens of thousands euros. This is why the system must be rock-solid, with failures always leading to the boiler being turned on.

Reliability is also the reason why I have chosen to build my own system, instead of relying on code written by others (also, back in ‘06 there wasn’t much to choose from). It gives me greater control over the code and I’m (fairly) sure to understand everything that’s happening. Of course, I use libraries and software written by others, but I always have the control over failure points. The last resort in case of an error is shutting down the system and going to a known state (with the boiler turned on).

There is multiple points when considering security in IT-systems, four of which I’ve assessed to be the most important for home automation:

• Accessibility
• Assurance
• Confidentiality and integrity
• Threat assessment

Accessibility

For one being able to trust a system, one must be able to access it when needed. If you can’t see the system functioning as expected, how are you supposed to trust that it’s working as expected?

This has been quite a struggle so far, as the house doesn’t have a wired network connection. The interface has to rely on 3G mobile network for access and this was a really big problem before Dovado was found. They produce high availability routers, which can not only reboot the modem used for connecting but also boot itself, if the connection isn’t restored in case of a failure. We’ve been using Dovado Tiny for a couple of years now, and not once has accessibility been lost for more than a few minutes because of network connection.

Of course, network connection isn’t the only part of the equation. Even if there is a network connection, the user interface might have crashed. This is why SSH access is also enabled for the system, so it’s possible to reach even if Web UI is unresponsive. This has happened couple of times so far, but it has been possible to reboot the UI (or even the whole system) via SSH.

If network connection is alive, but the PC cannot be reached, there’s an embedded UI in the Dovado. This doesn’t allow doing anything to the system, but helps to confirm that the system has crashed instead of the network. This of course leads to different actions based on the conditions.

Assurance

If the system isn’t reached, one has to be assured that it is functioning the way it was planned to. This was very hard during the first couple of years (and still is today, especially with harsh conditions).

With the introduction of remotely readable energy meters for practically every household in Finland, the situation has eased up a bit. The energy companies are forced to provide energy measurements to the customer as they are received from the meters. In practice this means that we get energy consumption measurements every 24 hours or so. In case the system is offline and there’s no immediate danger of anything critical happening, we can just wait for the measurements and check if the boiler has been turned on. As the average power consumption is around 800 W, a 6 kW boiler is quite easy to notice

As there has been failures and the system has functioned as it should, “assurance level” towards the system has grown day by day. Luckily, failures have been a few but existent. Without failures, there wouldn’t be any indication of the fail-safe mechanisms working the way they’re designed to.

Confidentiality and integrity

As noted in another post by @crosseyejack, home automation poses a huge risk of helping “unfriendly” people to know your daily habits, for example when you leave home for work, go to sleep etc. Also, part of confidentiality is hiding and disabling stuff from users allowed to access the system.

As I mentioned before, I use the same system for my flat as my dads house uses. Here it controls everything from lighting to TV and amplifier. I also have extended the functionality so that once I start playing a video on the media center, the lights are turned off and if I pause, the lights are turned on, to a dim level sufficient enough to walk to the bathroom. I showed the logs to one of my friends and he could identify the actions of my last day in under two minutes, with resolution down to minutes! I had woken up at 8am in the morning and turned on the lights. After a while, I turned on the display of my PC, browsed around the Internet for a while, was off to work (everything turned off). I came back home around 2pm, with devices turning back on again… As I watched a movie, he could even find the times I went to the bathroom or fridge, as the video was paused and lights turned on for a while.

These kinds of observations are easy to make by everyone, even if they don’t know you. That’s why it’s important to secure home automation systems with a proper authentication. Of course, the easiest is to setup a proven system, such as OpenVPN to isolate the system from public Internet. This does however hinder accessibility of the system. You can’t access the system if there’s a need to use an unknown device to connect.

Luckily for me, Django has a proven track record for security. It also includes features for limiting access rights for the users, both by groups and predetermined profiles. So far I’ve mainly used this for “show-casing” the system, but have experimented with features like a user profile to only using “home / away” -functions and limiting the control for temperature limits etc. This way a person not “knowledgeable” of the system could still use it to control basic functions without breaking anything.

Also, there’s a application for Django which allows the use of two-factor authentication to be used. This relies on a person knowing the username and password as well as having access to a device holding a code changing every X seconds. I haven’t set this up to production yet, but I’ve done some tests with it.

To everyone using OpenHab, I suggest reading Security article in the wiki. This allows you to enable authentication for the system (doesn’t seem to use authentication out-of-box, which is baffling to me :S).

Wireless sensors and confidentiality / integrity

Wireless sensors pose a huge risk to confidentiality of data. Not only is the data accessible by everyone in the range of sensors, it’s also quite easy to fake data. By accessing the data from wireless sensors, one could easily bypass all the authentication of the system itself and gather the same information as show in the user interface.

By faking the data, the risks are quite a lot higher. The attacker could for example fake data coming from a magnet sensor and make it seem like a door is closed while it’s not. EnOcean does bring some light to this situation though, with possibility to check data integrity with checksum. This does however need support from the device receiving the messages, for example raising an alert if too much data is received from a sensor.

The main drawback of wireless sensors is that it’s quite hard to notice these kinds of attacks, even after one has happened, as there might not be physical evidence. For wired sensors, there’s always some kind of evidence. It might be a small cut left by a wire-tap, a screw turned in a different position or a device left behind.

Threat assessment

As with every system, it all boils down to the risks. In case of home automation, the risks are directed towards you and your home. By comparison, in everyday Internet-usage the risks are mostly towards your “Internet-personality”.

In most cases, an insecure home automation leads to the risks noted in the previous subtopic. In the case of my dads house, there could be damages calculated in tens of thousands euros. Also, the damages might not be covered by insurance, as the hacker could set the system so that it doesn’t turn on the boiler, even if the sensors would say so. The insurance demands that the temperature indoors is kept above a certain temperature and if it drops below that, insurance doesn’t cover the damages.

Of course, hacking a home automation system isn’t the first priority for most thieves, but in the future it could be. Especially if there is “one system to rule them all”, it could and most probably will become a major target for hacking. This is why home automation should be designed secure from the ground up, to avoid issues in the future. Most of the systems are designed to last decades after install and should be able to withstand issues in the future as well. Also, even many temporary solutions, even if they might be setup just for testing are likely to be left in production, if the solution works and there’s no real reason to change it.