We’ve all seen the IoT device security trainwrecks: those gadgets that fail so spectacularly that the comment section lights up with calls of “were they even thinking about the most basic security?” No, they probably weren’t. Are you?
Hackaday Contributor and all around good guy Kerry Scharfglass thinks about basic security for a living, and his talk is pitched at the newcomer to device security. (Embedded below.) Of course “security” isn’t a one-size-fits-all proposition; you need to think about what threats you’re worried about, which you can ignore, and defend against what matters. But if you’ve never worked through such an exercise, you’re in for a treat here. You need to think like a maker, think like a breaker, and surprisingly, think like an accountant in defining what constitutes acceptable risks. Continue reading “Kerry Scharfglass Secures Your IoT Things”
Every day, we’re connecting more and more devices over the internet. No longer does a household have a single connected computer — there are smartphones, tablets, HVAC systems, deadbolts — you name it, it’s been connected. As the Internet of Things proliferates, it has become readily apparent that security is an issue in this space. [Andreas Spiess] has been working on this very problem, by bringing HTTPS to the ESP8266 and ESP32.
Being the most popular platform for IOT devices, it makes sense to start with the ESP devices when improving security. In his video, [Andreas] starts at the beginning, covering the basics of SSL, before branching out into how to use these embedded systems with secure cloud services, and the memory requirements to do so. [Andreas] has made the code available on GitHub so it can be readily included in your own projects.
Obviously implementing increased security isn’t free; there’s a cost in terms of processing power, memory, and code complexity. However, such steps are crucial if IOT devices are to become trusted in wider society. A malfunctioning tweeting coffee pot is one thing, but being locked out of your house is another one entirely.
We’ve seen other takes on ESP8266 security before, too. Expect more to come as this field continues to expand.
[Thanks to Baldpower for the tip!]
When we say “hack” here we most often mean either modifying something to do something different or building something out of parts. But as we build more Internet-connected things, it is worthwhile to think about the other kind of hack where people gain unauthorized access to a system. For example, you wouldn’t think a remote control would be a big deal for hackers. But the Logitech Harmony Hub connects to the Internet and runs Linux. What’s more is it can control smart devices like door locks and thermostats, so hacking it could cause problems. FireEye’s Mandian Red Team set out to hack the Harmony and found it had a lot of huge security problems.
The remote didn’t check Logitech’s SSL certificate for validity. It didn’t have a secure update process. There were developer tools (an SSH server) left inactive in the production firmware and — surprisingly — the root password was blank! The team shared their findings with Logitech before publishing the report and the latest patch from the company fixes these problems. But it is instructive to think about how your Raspberry Pi project would fare under the same scrutiny.
In fact, that’s the most interesting part of the story is the blow-by-blow description of the attack. We won’t spoil the details, but the approach was to feed the device a fake update package that turned on a dormant ssh server. Although they started by trying to solder wires to a serial port, that wasn’t productive and the final attack didn’t require any of that.
We’ve looked at some ways to harden Linux systems like the Raspberry Pi before, but honestly, it is an ongoing battle. We’ve seen plenty of devices with cybersecurity holes in them — some not found by good guy hackers first.
Frustrated by the glut of unsecured IoT devices? So are Microsoft. And they’re using custom Linux and hardware to do something about it.
Microsoft have announced a new ecosystem for secure IoT devices called “Azure Sphere.” This system is threefold: Hardware, Software, and Cloud. The hardware component is a Microsoft-certified microcontroller which contains Microsoft Pluton, a hardware security subsystem. The first Microsoft-certified Azure Sphere chip will be the MediaTek MT3620, launching this year. The software layer is a custom Linux-based Operating System (OS) that is more capable than the average Real-Time OS (RTOS) common to low-powered IoT devices. Yes, that’s right. Microsoft is shipping a product with Linux built-in by default (as opposed to Windows Subsystem for Linux). Finally, the cloud layer is billed as a “turnkey” solution, which makes cloud-based functions such as updating, failure reporting, and authentication simpler.
Continue reading “Microsoft Secures IoT From The Microcontroller Up”
There are many parts to building a secure networked device, and the entire industry is still learning how to do it right. Resources are especially constrained for low-cost microcontroller devices. Would it be easier to build more secure devices if microcontrollers had security hardware built-in? That is the investigation of Project Sopris by Microsoft Research.
The researchers customized the MediaTek MT7687, a chip roughly comparable to the hacker darling ESP32. The most significant addition was a security subsystem. It performs tasks notoriously difficult to do correctly in software, such as random number generation and security key storage. It forms the core of what they called the “hardware-based secure root of trust.”
Doing these tasks in a security-specific module solves many problems. If a key is not stored in memory, a memory dump can’t compromise what isn’t there. Performing encryption/decryption in task-specific hardware makes it more difficult to execute successful side-channel attacks against them. Keeping things small keeps the cost down and also eases verifying correctness of the code.
But the security module can also be viewed from a less-favorable perspective. Its description resembles a scaled-down version of the Trusted Platform Module. As a self-contained module running its own code, it resembles the Intel Management Engine, which is currently under close scrutiny.
Will we welcome Project Sopris as a time-saving toolkit for building secure networked devices? Or will we become suspicious of hidden vulnerabilities? The researchers could open-source their work to ease these concerns, but value of their work will ultimately depend on the fast-moving field of networked device security.
Do you know of other efforts to add hardware-assisted security to microcontrollers? Comment below or let us know via the tip line!
Image of Mount Sopris, namesake of the project, by [Hogs555] (CC-BY 4.0)
We’ve all seen the stories about IoT devices with laughably poor security. Both within our community as fresh vulnerabilities are exposed and ridiculed, and more recently in the wider world as stories of easily compromised baby monitors have surfaced in mass media outlets. It’s a problem with its roots in IoT device manufacturers treating their products as appliances rather than software, and in a drive to produce them at the lowest possible price.
The Australian government have announced that IoT security is now firmly in their sights, announcing a possible certification scheme with a logo that manufacturers would be able to use if their products meet a set of requirements. Such basic security features as changeable, non-guessable, and non-default passwords are being mentioned, though we’re guessing that would also include a requirement not to expose ports to the wider Internet. Most importantly it is said to include a requirement for software updates to fix known vulnerabilities. It is reported that they are also in talks with other countries to harmonize some of these standards internationally.
It is difficult to see how any government could enforce such a scheme by technical means such as disallowing Internet connection to non-compliant devices, and if that was what was being proposed it would certainly cause us some significant worry. Therefore it’s likely that this will be a consumer certification scheme similar to for example the safety standards for toys, administered as devices are imported and through enforcement of trading standards legislation. The tone in which it’s being sold to the public is one of “Think of the children” in terms of compromised baby monitors, but as long-time followers of Hackaday will know, that’s only a small part of the wider problem.
Thanks [Bill Smith] for the tip.
Baby monitor picture: Binatoneglobal [CC BY-SA 3.0].
The Espressif ESP8266 chipset makes three-dollar ‘Internet of Things’ development boards an economic reality. According to the popular automatic firmware-building site nodeMCU-builds, in the last 60 days there have been 13,341 custom firmware builds for that platform. Of those, only 19% have SSL support, and 10% include the cryptography module.
We’re often critical of the lack of security in the IoT sector, and frequently cover botnets and other attacks, but will we hold our projects to the same standards we demand? Will we stop at identifying the problem, or can we be part of the solution?
This article will focus on applying AES encryption and hash authorization functions to the MQTT protocol using the popular ESP8266 chip running NodeMCU firmware. Our purpose is not to provide a copy/paste panacea, but to go through the process step by step, identifying challenges and solutions along the way. The result is a system that’s end-to-end encrypted and authenticated, preventing eavesdropping along the way, and spoofing of valid data, without relying on SSL.
We’re aware that there are also more powerful platforms that can easily support SSL (e.g. Raspberry Pi, Orange Pi, FriendlyARM), but let’s start with the cheapest hardware most of us have lying around, and a protocol suitable for many of our projects. AES is something you could implement on an AVR if you needed to.
Continue reading “Practical IoT Cryptography On The Espressif ESP8266”