The Ugly Truth about Consumer Networks and the IoT

Today’s IoT device design is fundamentally contrary to consumer interests

Security is hard. Security that is easy to use is harder. However, this is not license to sell architecturally-flawed products to people who do not know any better.

Security takes a back seat to ease of use

The market commands all business decisions, and easy to use devices are the easiest to sell. This leaves us with a market saturated with devices that, without specific knowledge and configuration on the part of the consumer, are vulnerable to attack.

So how do we take the security burden away from consumers? So far, the answer has been to maintain a remote server which the IoT product securely connects to. All the user has to do is get it connected to their network (which can be as easy as pushing a couple of buttons) and they are good to go. Great, right? Not so much.

Remote server dependent devices can create a single door through which infiltrators can access thousands of private networks

Giving a remote server access to a device inside your network is fundamentally dangerous. This is why corporations with secure VPNs do not give access to private devices without strict security guidelines in place. If the remote server is compromised, it can feed bad code to the device within your network. In turn, that device can attack other devices, and your whole network can be compromised. A recent example of this was the NotPetya attack, which affected several international companies (including Maersk, Merck, and Nuance), as well as much of the Ukrainian government.

“Never trust anything that can think for itself if you can’t see where it keeps its brain.” — Arthur Weasley

For example, let’s say I decide that I want to keep track of my goldfish tank’s water temp. I buy Tankr, a made up product that will probably hit CES next year, and connect it to my network. Tankr is run by a couple of enthusiastic fish lovers who have decided to dabble in the IoT, but are not information security experts.

Tankr gets hit with an attack that compromises their servers. Before they can take action, a remote firmware update is pushed out that compromises my Tankr device. If I’m lucky, my fishtank is now participating in an ironic DDoS attack against Team Aqua. If I’m less lucky, any other vulnerable device on my network (such as a slightly out of date Windows computer) could be encrypted and held for ransom. Tankr never saw it coming, and neither did any of their users.

There are rare cases where there is probably not a concern- such as if a device can only call out and upload information, but is unable to update itself- but they are uncommon. Even devices that in theory cannot be updated remotely are still vulnerable, as Jeep owners found out last year. In general, if it can connect to your network, you should not trust it. If it can update itself, the device is a vulnerability waiting to happen.

Remote server dependent devices are problematic anyway

Ask owners of a Revolv — a home automation hub purchased by Nest — and they will warn you about server dependency. After purchasing Revolv in 2014, Nest decided to drop any support of the product and discontinue sales. In May of 2016 Revolv servers were shut off, turning the home automation hub into a brick shaped like the tears of anyone who bought it.

You don’t have to look far to find other examples. Koubachi (maker of fancy moisture sensors for your garden) was purchased by Husqvarna, and their servers were to shut down at the end of this year (though they extended it to the end of 2018). The businessman in me says it is graceful of them to continue supporting legacy products, but the consumer in me is deeply troubled that a $100 moisture sensor could be useless after the company that manufactures it is bought.

It doesn’t take a startup getting bought to create problems for you. Phillips was embroiled in controversy last year after they walked back their support for third party bulbs with their Hue Bridges. They ultimately reversed the decision, but wouldn’t have without strong customer pushback. It’s not uncommon for companies to change strategies or policies that will affect you directly, and rolling back to how it worked before either isn’t a choice or prevents future improvements. It’s a bad situation.

The solution isn’t as easy as you’d think

So the obvious answer is to build a hub that everything talks to within your local network. That way it can handle the processing, and any information that needs to get out can be vetted and pass through it. Unfortunately, there isn’t a viable product like that available right now, primarily for business reasons.

Samsung SmartThings is barely more than a hardware repeater that depends on a constant connection to a remote server to do any real logic. They recently updated it so 1–1 actions will work without the server (your lights will turn on when you hit the switch), but you can’t control them with your phone, or have them run on a schedule, or do anything that would be considered 'smart’. Wink is the same way, and while each are trying to come up with local processing solutions, neither one is close at this point.

OpenHab and HomeAssistant, two open source systems, only allow local processing. Vera is hardware solution that can be local only, but requires extensive customization to do so. In any of these cases, the configuration is much more complex than the average consumer can handle, and many consumer IoT products don’t support direct local connections anyway. My Ecobee thermostat, for example, requires anything that wants to talk to it to connect through their web API. Even if the API connection is not required, most consumers don’t know how to look up the local address and access it directly anyway.

I understand why companies prefer remote server connections over local processing. In some cases (such as the SmartThings Hub), it enables the consumer-end device to be low cost, smaller and easier to design, and draw little power if battery backup is an option. It also makes it easy to maintain the software, as in many cases there is no need for firmware updates that can leave users out in the cold, and any variations in device manufacturing can be accounted for in the API.

Oh, and if you depend on someone else’s servers, you are much more likely to stay in the ecosystem. Companies use this to their advantage in a number of ways, whether it be through subscription fees for you or licensing fees for guaranteed device compatibility, there is money to be made from it.

Why this matters

Consumers have rights. The products they pay for should not impose a security threat or have an expiration date. At a minimum, IoT manufacturers should include a local device API for each of their products so users can choose to reduce risk and not have to reverse engineer everything they purchase. Ideally, local connections would be the default setting, and an industry standard for network-based IoT connectivity would be reached. And yes, I know about Zigbee, Z-wave, and other non-wifi wireless protocols, and they have their own issues to be discussed in another article.

There are a number of products that are committed to this standard. The newly released Flair vents, for example, have committed to a local API and are as transparent as a young company can be. There are many that could stand to learn from them, and I hope for my own sake some companies do.