De-clouding IoT

There is a lot of IoT (Internet of Things) stuff these days, and it is impressive what you can do with home automation - linking sensors and devices and command speakers and phones and all sorts. It is even impressive that third party linking services like If This Then That even exist now!

A lot of these devices make use of The Cloud in one way or another, but not all, and not all to the same extent. This is both good and bad, and represents something of the age old compromise of security and convenience in a way.

Today I am playing with three devices: A Daikin air-conditioning unit (as per my blog), a Withings Sleep monitor (as per my blog), and some new SONOFF switches. All have different approaches. All work with IFTTT, so if I was happy to just use the cloud, this would all be simple.

What's wrong with the cloud?

Convenience

The first thing that is right with the cloud is the convenience - simply connect a device, load a phone app, set up and it is working. Devices that live on your home WiFi and talk to servers on The Internet do tend to just work and be easy to use. But this convenience comes at a cost...

Privacy

One of the issues is privacy - the data from these devices is going to third parties - companies you don't know, or may not even know which country they are in. Often the "service" they provide is not something you even knew was needed when buying the product and is some separate "agreement". GDPR should make your data safe, but it is a law not a technical means. They may not understand GDPR (Withings clearly don't, and have been reported to the ICO). Even if they do understand GDPR you have no real way to know if they are following it properly, or if they will ever get hacked.

The main way to ensure privacy is to keep control of your data. A cloud based service inherently takes that control away.

Reliability

If a device needs the cloud to work, that is also a problem. Even the Withings Sleep monitor, which is totally cloud might seem like it is not an issue if your WiFi or Internet is down or they are doing maintenance on their servers, etc, but when you use the real-time triggers for getting up or going to bed to work the lights and heating and so on, suddenly it matters.

With locally connected and controlled devices in your home you can remove that reliance on the Internet and The Cloud, but at the cost of a single point of failure and equipment you have to maintain.

You also have to allow for the fact that this is most likely a free service, and something they can stop by choice, or because they go bust, or even politics between countries, and suddenly your devices are useless.

Adding extra parties like IFTTT just adds to the issues.

Security

Finally security - this is a huge issue with IoT. "The S in IoT stands for Security".

The Daikin air-con have no security - simple http requests. Even if there was a password it would be easy to snoop. It means anyone on your home network / WiFi can access the air-con.

Does it matter? After all anyone with a remote can do the same in the house or even from outside through the window (stories of someone turning on neighbours air-con through the letter box whilst they are away so heat rises to their flat and saves them money). But is it a big deal? Well, remember, this is not just about you - if someone could control all air-con in a country they could make them all turn on at the same second and cause a major power blip? They could monitor when you are in and not and break in when not. It is not so simple.

But they need to be one local network / WiFI? Well, no, they just need a compromised broadband router or compromised device (a lot of IoT is very hackable) on your LAN, or even some background secret function in some popular phone app. It is not as hard as it sounds.

So security of IoT really needs to improve.

What do I mean by de-clouding?

Basically I want to have devices I control, and home automation I manage using my computers in my home without using The Cloud. I can set up any remote access I want with a secure VPN. I then control my systems, and control my data. It means I have to maintain a machine, but I do that anyway, and it is not that hard - could even be a Raspberry Pi or some such.

Daikin

As per my blog, this was simple - no authentication just local http - it has no security.

The good news is that it makes it simple for me to lock down on separate WiFi SSID and VLAN and easy for me to write my own controls.

Apart from a lack of security, the other failing is a lack of documentation. I'd prefer if the API was actually documented - why not, Daikin?

Withings Sleep

The Withings Sleep monitor was more of a challenge - the security is trying with this one.

The device does an HTTP request to fetch the public key used for HTTPS, but includes its MAC and a random challenge in the request and gets a digest in the response. Any change to the response key, or even the request MAC causes it to abort and start again (DHCP, DNS, HTTP, etc). So it seems there is likely to be a per-device key check on the response and as such I cannot simply replace the public key returned. It then checks the public key on the HTTPS.

So yes, I am stuck. The good news is that it does do IFTTT and that can be linked by creating an applet to a webhook to poke my own server for triggers. Sadly this is not direct from the device, but via Withings, so no chance to intercept / hack that either. It has all the disadvantages of cloud and local servers combined, but does mean I can then control the actions I take directly - such as changing air-con settings, turning lights on/off, etc.

SONOFF

I was inspired by a blog post (here). It seems SONOFF are very cheap and very popular, even with alternative code that people flash in to the units. However, the security is poor in the first place meaning one can control them off-the-shelf. This is bad for security but good for de-clouding them.

First off, the simple in-line power switch (e.g. for lighting circuits) - which I have connected to a table lamp (purchases especially for this test, and obviously pixar style).

It was incredibly difficult to see the AP mode SSID pop up and connect to it, and I wonder if you just have to try several times. You long hold the button and it shows up if you are lucky (ITEAD-1000xxxxxx with password 12345678) But then the /device and /ap http commands work as explained in that blog. It seems serverName can be a host name.

As expected it then connects https. Unfortunately, even where the server has proper https and the name matches, it is just closing the connection after getting server certificate details. Arrrg.

Reading some of the comments, it seems I am not alone - even with a valid (LE) cert, the sonoff is not happy with the https negotiation. Grrr.

This sort of leaves me either using IFTTT and cloud, again, or re-flashing the code. Not amused.

What I think would help...

Firstly I think all IoT needs better security - maybe there needs to be a testing standard as part of compliance for CE marking (scary).

But also I really think the APIs should be published. This would allow devices to work directly with IFTTT or competing home automation systems or local controllers.

At the end of the day the closed approach, and forcing all data via the cloud maybe made commercial sense when companies could collect and use all that lovely personal data. GDPR kills that business model, and even makes having that data a potential liability! So please, let's open the APIs (securely) to allow more competition in the home automation market.

Oh, and don't forget support of the current IP protocol (IPv6).

Update: Current plan is to re-flash SONOFF. I'll blog more on that soon.