IoT Unravelled Part 3: Security | Hacker News Reader

IoT Unravelled Part 3: Security

troyhunt.com

68 pointsadamflanagan26 comments

I did a 3 part series on IoT and security on my blog back in 2016, titled "IoT Danger Zone" (https://2byt.es/post/dz-1/).

For home automation I use Home Assistant, for several years now (~6-7). I had two goals when I began; no cloud and not critical path. Being a software engineer with a degree in electronic engineering it was no issue for me to build my own hardware with ESP32 or ESP8266 and create my own IoT devices.

The no-cloud thing has worked out pretty well, I still don't connect to anything in the cloud, and I block call-home functionality in my firewall such as that of the Philips Hue.

The non-critical path thing has been great too. I can control all of the lights with Hue switches or the physical switches, the sensors for motion can be disabled if we have certain guests that aren't tech-savvy enough (or frankly just used to) deal with motion sensing lights. The automations are all enhancements to rather than driving the core functionality of anything in the home, and so if/when it falls over, things go back to the "normal" level of convenient; you have to turn on lights yourself, or use various remotes for things, the heating becomes manual, etc.

Security is still hard in IoT, good security needs good hardware, and IoT is rarely that, and by good I mean decent memory, hardware accelerated encryption algorithms, hardware secure key storage etc. Coupled with the extremely poor programming practices of a lot of IoT devices, security is all but a joke.

What do you mean with non-critical path? It sounds like you're suggesting something like wiring a light controller as a 3 way switch so you can always still use the physical switch? Is that the type of thing you're referring to with non-critical path? Any reading on that you can suggest?

So in my case, we leave the physical light switches on all the time, we use motion sensors or ZigBee wireless switches to control the lights. If the automation falls over we just switch them on and off using the switches. If family are visiting I switch the house to "guest mode" which deactivates the motion sensors and various other automations and we use the light switches like normal.

The term "critical path" is when a whole system depends on that thing to function; it is in the critical path.

For example, if I couldn't use the lights at all when the home automation server is down, or your Mac won't run any programs when the phone-home server is down, those things are on the critical path, without them the system fails.

The easiest thing is to use smart switches in the wall to replace your light switches instead of smart bulbs. Most smart switches will work as regular light switches even if the whole rest of your smart home is down. Then you use the smart home stuff to make everything more convenient but if the smart home is down it falls back to dumb home functionality.

An easy example is my pantry. It’s got a smart switch (Inovelli Zwave) hooked up for the light plus a door sensor on the door. Normally when you open the door the door sensor turns on the light by communicating with the smart switch and when you close the door the light goes off. But if everything is down the switch still acts like a regular light switch and you can turn the pantry lights off and on.

Other examples might be garage doors that open when they detect you pull in to the driveway. You want to make sure that you can still just press the garage door opener button so that you can get in like a normal person when presence detection fails.

Smart home functionality should enhance, not replace, at least until everything is 100% bullet proof and never fails or goes down (i.e. not in my lifetime)

> I still don't connect to anything in the cloud, and I block call-home functionality in my firewall such as that of the Philips Hue

If you're blocking your Philips Hue Bridge from connecting to the cloud, and you're a Home Assistant user, why not install the ZHA module and connect your lamps directly to HA instead of the Hue Bridge? I've been wanting to do this myself, but the prospect of losing access to both the native Hue app and the Hue Disco app is making it a hard sell in my household :)

Good question. When I started there was no alternative to the bridge, I haven't done much updating lately (I'm a new father) and it all works. I use WireGuard to connect for remote access.

I will certainly look into it as the Hue bridge accounts for a significant number of requests being blocked compared to my network's baseline.

Yeah Home Assistant really makes things better, but there is only so much it can do when manufacturers do things like this: [0]. These devices are not your own, resistance is futile.

Only Tasmota or ESPHome flashable device for me from now on.

[0] https://mobile.twitter.com/TPLINKUK/status/13286876591333990...

Either don’t buy things that don’t explicitly support offline use, or block their access to updates and keep them on an isolated vlan.

Is there still a reason to keep them on a separate vlan if they can't access the internet? I'm genuinely asking, I can block the thing's internet access but vlans are still on my list of "things to learn and do" :)

Because I may expose them to my guest vlan and wouldn’t want them to get compromised and have access to my home devices.

About VLANs, at a previous workplace, I've experienced firsthand the downsides of not segmenting the IoT devices in their own separate VLAN. One day, a misbehaving desktop hung during shutdown, and somehow went crazy spamming broadcast packets (I believe they were DHCP requests) to the network. The door access control was on the same network, and the broadcasts overloaded its tiny CPU, so nobody could get in. Had that device been in a separate VLAN, the errant broadcasts would never have reached it. (The fix was to unplug the broken desktop until it was fixed, segment the network so the door access control was not on the same VLAN as the desktops, and enable broadcast storm control on the switch.)

I do agree that segmenting IoT devices is definitely a good idea. However if your door access control cannot handle a busy network I really don't think it should be used as such.

I moved as much of my home automation as I could to ZigBee and have been planning to set up an "IoT" SSID.

But the first step is to defang/block any device that tries to call home to its maker (which is why most of my non-ZigBee devices run Tasmota firmware).

All the devices he talks about are wifi-enabled. What are the implications of non-wifi non-internet e.g. Zigbee devices?

> All the devices he talks about are wifi-enabled. What are the implications of non-wifi non-internet e.g. Zigbee devices?

None, as nobody is using them? IKEA zigbee remote is probably the one and only thing ever I saw on sale, and everyday use, and even they, saying this knowing an inside source, want to eventually switch to WiFi only.

That's not true at all. There are tons of ZigBee/Z-Wave devices available, most notably the Philips Hue series. I have over 60 ZigBee devices in my house, and so do a lot of people that I know. Also you can expect the next-gen low-power devices to switch to the still in-development CHIP spec (Connected Home over IP), not WIFI.

Ditto, but with z-wave devices instead. What makes you think CHIP is the next standard thats up for mass adoption when there is a bunch of competition in this space, with the likes of Sidewalk from Amazon or Thread which I think is what Apple are rolling out to the homekit enabled devices?

Amazon and Apple are both members of the CHIP working group. As far as I know, CHIP uses Thread as one of it's protocols (the other being a BLE derivative). Sidewalk uses WiFi, which is not very efficient for low-powered devices (eg. sensors, switch etc.)

Fair points! Looks like they are all memebers of eachothers working groups, no wonder the standards are a mess... https://xkcd.com/927/

Well to be honest, I really like the open-source approach that they have decided on for the development of the standard. You can follow the development of it's reference implementation on the Github repo of the project: https://github.com/project-chip/connectedhomeip

> That's not true at all. There are tons of ZigBee/Z-Wave devices available,

And they are being outsold 100-to-1 by noname WiFi based gear, which unlike them, works on day 1 — a thing most people want, hence the sales success.

Proprietary systems by far established a reputation for themselves as "doesn't work with anything, even itself."

WiFi is not a candy either, and for most people it means an increasingly mounting pile of one per-device apps, but that's definitely better than not having the device working at all after every homekit/google home update.

> Proprietary systems by far established a reputation for themselves as "doesn't work with anything, even itself."

Hue works extremely well with a Hue hub. But it’s even better to get a non-proprietary hub to connect your devices.

I would love to see some real sale stats if those claims are real? I have no idea how much they are supposidly outselling zigbee or z-wave devices.

From a purley anecdotal standpoint, you start with the wifi devices as they are low barrier to entry, (no hub required and normally comes with some sketchy 3rd part app); If you decide to go all in and buy more than a handful you naturally progress towards the zigbee/z-wave devices and ether a fully managed Proprietary "do it for me" system like SmartThings, or you go down the self managed route with HomeAssistant or OpenHAB.

Zigbee and Zwave are open protocols and work better than WiFi Devices which are more often Cloud Locked to their Vendor with no ablity for local control, even the integrations with HA are often API's to the vendors Cloud Servers not to the device itself

No if you want secure, local control of your home automation you want Zigbee and Zwave devices not WiFi.

There is a TON of these devices on the market, and not just ikea like your other post seems to suggest

Everyone using Comcast’s home security service has a bunch of them. The keypads, motion sensors, door sensors, and window sensors all use ZigBee.

I'd imagine that the security implications for non-wifi devices are somewhat less than for wifi-enabled devices. ZigBee devices do not "phone home" over the internet, and in addition to that are not able to download and upgrade their own firmware without a supporting internet-connected gateway/bridge device. Most of the risk comes from the attack surface that the gateway/bridge provides, or from attackers having physical access to individual devices (eg. by obtaining keys from the device's memory). As for ZigBee gateway/bridge devices, in most cases you can replace it with an open source solution that gives you more control (eg. Home Assistant + a Conbee USB stick)

Reply on news.ycombinator.com