You Can’t Secure What You Cannot Update: Hardware Edition

UPDATE – resin.io is now balena. Read the official announcement here, if you would like to find out more.

When people think about connected devices around them (cars, thermostats, fridges, routers) as something that can undergo software updates over the air, they often think of it as a necessary evil, with unsettling security implications. How do I know my fridge won’t update to send out more information than I’d like? How do I know it won’t be compromised remotely? What’s next, an antivirus for my thermostat?

Security and safety is a big deal. It used to be that cars had something like 1000 lines of code in them. 90% percent of the time spent developing that software was devoted to testing. After that trial by fire, the software was as solid as any other piece of hardware in the car. But as time goes by, more and more stuff is done via software, and it is all gathered up in codebases orders of magnitude larger than the 1000 lines of code of yore. And once a codebase is out there, any known security vulnerabilities make it readily exploitable.

One approach to securing a connected device is to spend 20 years testing it. But then you will never release anything to market, and when you do, it will likely be a bit behind the times. NASA can get away with that, but then competition in space isn’t what it used to be. Another approach is to bite the bullet, treat it like a modern software system that will have bugs regardless, and plan for that eventuality.

Tesla motors got this right. They built their cars with an over-the-air update capability. When Toyota and GM had to recall more than 2 million cars to their dealerships for a software patch, Tesla simply sent out an OTA update.

Now imagine some device being vulnerable to the Heartbleed bug. Maybe a connected device that is acting as a server for some other devices in your house, hospital, or manufacturing line. Oh, you thought that https/vpn channel you had set up was secure? Turns out it isn’t. Not only that but it’s actually a backdoor to the contents of your device. And attacks leave no trace. What’s that? You want to update your devices but don’t have an update mechanism in place? Well, that means you’ll have to abandon them to the wolves, or visit each house or have your users bring the device to you. Which means that besides being a LOT more painful/expensive/unlikely to update, the window of vulnerability just got a whole lot larger. How is this a more secure situation?

An update mechanism of course isn’t a panacea. The updating itself has to be done correctly. If not, you wind up with the situation Belkin’s WeMo products were in recently, where the update system could be abused to install malware. But at least you can update the update mechanism… via an update.

Software for hardware is inevitably becoming more complex. Anything above the minimally complex or formally proven to be secure requires the basic humility of accepting the fact that it will have bugs, some of them security related, and planning a way to fix them when they’re found. Leaving a connected device without an update mechanism is equivalent to refusing to come to terms with that reality. And doing a half-baked job of that update mechanism is courting trouble. A secure connected device needs updates, and needs the updating process to be built with the utmost attention to detail.

That’s hard to do when you’re rushing to build your product and the update mechanism isn’t the core differentiating feature, but this is the world we live in.

Any questions? or you’d just like to say hi, come find us on our community chat.