Over the last few weekends I’ve rebuilt my smart home solution. It reminded me of how hard it is to build something that is secure.
First, you will have to forgive me as I’m going to give a tutorial on what I needed to do. If you want to skip to just the security bit, please scroll down to “Security Challenge”.
To control both power switches and thermostatic radiator values on the same system, I choose the LightwaveRF product set. A choice made on price / availability considerations. With the LightwaveRF model, the IoT sensors / switches, communicate over RF with a hub, connected to my LAN. To communicate with the hub, there is a iPhone/Android app. All relatively easy to set up.
I also have some Philips Hue lightbulbs, controlled by a different App.
I wanted a single app, not two to control my home.
Prior to IOS 10, to solve this, about a year ago, I went down the OpenRemote road. This works for the Phillips system, and partially for LightwaveRF.
To explain why I say partially, I now need a bit of explanation on how LightwaveRF works.
To send a command to a device, you need to send a UDP datagram to the LightwaveRF hub (the dat gram format is not easy to piece together – you need a NDA signed with LightwaveRF – or a network scanner and Google). So far so good.
However, to interface with the thermostat, you really want to know the current room temperature and thermostat setting. LightwaveRF sends this data asynchronously via UDP broadcast (NB: this is the basis of my security gripe – see below). I could not find a way of getting OpenRemote to deal with that, and Google suggested no one else had a solution too (I was using OpenRemote 2.0, there is some suggestion this may now be possible with a more recent version).
HomeKit
When IOS 10 came out with HomeKit, I decided to revisit the problem, and leave OpenRemote behind, swapping to HomeKit.
Sadly, LightwaveRF does not provide Apple HomeKit support, so you have to roll your own (there is some suggestion LightwaveRF are sorting this, but it will need new hardware – not going there, current hardware is fine!)
In short, I built an Apple Homebridge and used a UDP listener to feed the room temperature values into the Homebridge, so I can see it via HomeKit, and use Siri to turn my heating on.
(If interested, I have written a more technical explanation, with code snippets, of how I did this, seems to be an FAQ on various forums, but with few answers.)
Now to the point of the blog…
Security Challenge.
Thank you for sticking with this article so far. Now the security point.
One of the driving principle of good security is network segregation (see Cyber Essentials at Home).
The LightwaveRF communication model makes this impossible. The LightwaveRF WifI Bridge uses UDP broadcast so MUST be on the same sub network as the Raspberry PI running the Apple Bridge. The Apple Bridge MUST be on the same subnet as the iPhone (unless I invest in AppleTV or a sacrificial iPad running IOS 10 that always sits at home).
(I say “impossible“, I could use a Nexor secure information exchange solution to implement a cross domain network UDP re-broadcast, but seems a little over kit to turn the heating on at home).
The Phillips Hue system is more friendly in this respect – it uses HTTP request/response, so can traverse a suitable firewall/router segregated network with appropriate network segregation.
In Conclusion.
I started this project, as I wanted to understand the security challenges of building a smart home. I had the concept of using basic segregation to keep things clean, I did not expect to fail at the first hurdle.
I also didn’t expect it to be so hard – most people are not going to write Java code to get their smart home working. We have a long way to go.
Once Upon a Camayoc 