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.
Kerry works through three products, an IoT medical training device, a smart deadbolt, and an IoT dockless shared scooter. While you might think that the medical device would demand high security, it was actually the simplest on his list. It’s used by medical professionals on-site, in a controlled environment, and there’s not much else you can do with it. They took some effort to make flashing the wrong firmware difficult, including flashing only over USB, but basically they decided that the bare-minimum of security was acceptable.
Contrast the medical device with the IoT lock. The lock is all about security and securing your house. Worse, if it fails, it would lock you out of your house. And the threat surface is large. Imagine using the lock on your door to let people in to your AirBnB rental — now you have a stranger with extended physical access to the device, who could even dismount it without looking too odd.
There are privacy concerns, denial of service attacks, and the possibility to use it to pivot into your home network. Needless to say, the firmware update mechanism here was a lot more complex, involving authentication and encryption, and Kerry goes into the whole chain here.
Finally, the scooter. The device itself is cool, stealable, a public safety hazard if it fails, and if you could figure out a way to turn them off remotely, you know videos would show up on YouTube. In short, it’s a security nightmare. Half of this was solved by having the scooter techs frequently get hands on the devices. Firmware can only be flashed locally with a cable. The techs could see if anything was added to the PCBA. Etc. The other half was solved by dedicating a separate microcontroller to the throttle and brakes, disconnecting the most important driving functions from the IoT stuff.
What’s most interesting about the scooter case study is all the things the company chose not to fight against. User stupidity? Nope. Theft? They only have an expected life of 6 months anyway, and aftermarket “brains” are available on Amazon for anyone who really wants to steal it.
There are tons of other threats, but the overarching theme of Kerry’s talk is identifying which risks you can mitigate, and which you can’t. Focusing your efforts on the basic stuff gets you past the basic threats. And that’ll keep the companies that Kerry worked for from ending up shamed in the Hackaday comment section.