Why Hardware Security Matters

When people think of hacking, they tend to think of the flashy end result: someone runs a script, text flies by on a terminal, and ta-da! Access is granted.

What they don’t see is all of the work that goes into it beforehand. The reading and re-reading of datasheets, RFCs, code, and so on.

I think that this Hollywood view of hacking does product managers a disservice. It shifts the focus onto what a hacker could do with a couple seconds or minutes of time at a keyboard, rather than focusing on all of the information leaks that happened prior.

They assume that a hacker would never be able to get that far in their own product, simply because the hacker lacks the background information and/or time to dig in to things.

Fun fact: I once had a coworker that would run the “hollywood” program with its wildly scrolling text (sudo apt install hollywood if you want to try it out) to make his managers think he was working hard. It worked.

A hacker (white hat or otherwise) discovering that your product has a pre-auth buffer overflow that allows for code execution¹, or a hardcoded password², or is easily modifiable³ requires them to have spent a LOT of time with the software/firmware already.

But how did they get that firmware in the first place?

Those Tricky Hackers

There’s several options, a few of which I will list here:

• They downloaded it directly from your website, as a device update
• Your product updates itself via a companion mobile app, and they were able to proxy the traffic to intercept that update (or URL pointing to a binary file)
• OR they just had a physical copy of your device and you neglected hardware security, so they have as much access to your firmware as your own test engineers do.

You might think that hackers won’t be able to figure out your hardware without a schematic, but this isn’t a good assumption.

Typically, hardware engineers are not reinventing the wheel each time they add a debug-related footprint (UART, JTAG, etc), so these are pretty easy to spot. With a DMM to trace out which pins are power and ground, and a <$20 FTDI cable, they might have console access if you left that open.

With some squinting (or a microscope for those of us with slightly worse/older eyes), they can read the marking on the microprocessors or external memory chips, find the datasheet via a quick Google search, and understand the pinout.

• Are there pins labeled RX and TX, and what do they see when they solder leads on and hook up a logic analyzer?
• Are there external memory components with pins corresponding to SPI, or I2C, and if so, can they just dump out the contents? Or JTAG or SWD for microcontrollers?
• If they’re lucky there might even be pre-made scripts to dump out configuration data and binaries, as is the case for popular platforms like the ESP32.

As long as you are patient enough to read datasheets, and have some basic understanding of common embedded protocols, you are in business (IF hardware security was not considered). Other PCB patterns make themselves clear too: components related to power circuitry, antennas and components related to wireless signals, etc.

Notably, this approach of identifying components and tracing pinouts costs almost no money and only a bit of time, and who doesn’t love messing around with electronics?

I should know: one of my first projects out of college left me with malfunctioning PCBs and uncooperative engineers. Since they wouldn’t share any schematics with me, I had the choice to either not make any progress on my assigned task, or to essentially teach myself hardware reverse engineering. I chose the later (and eventually made friends with the engineers, too).

Hardware reverse engineering gets more complicated (and much cooler) from there: fault injection to bypass security features, side-channel attacks, exploits discovered in bootloaders, or “simply” decapping a chip and writing a tool to extract firmware from a high-resolution scan of ROM, as one does. Undeniably cool stuff, and the sort of talks that gets top billing at BlackHat and Defcon, but outside the scope of this post.

The Last Nail in the Coffin

Hopefully now I have disabused you of the idea that hackers are limited by the lack of hardware documentation or by lack of tools or money. If my early-20s self could figure this out with vanishingly little support from management (or god knows, a budget for tools), then it is within the realm of most hackers, researchers, and interested hobbyists.

And the amount of tooling and published research has only improved since then.

But!

I have skipped over an important rebuttal, which I’ll now address: “yeah, sure, they can do all of that, if they have access to the hardware. If.”

For creators of IoT devices, this is a foregone conclusion. If you do not have easily-available hardware for consumers to purchase, you do not have a thriving business. Your device is a couple clicks and an Amazon Prime delivery away.

But what about hackers and researchers getting their hands on other devices?

For equipment that goes in vehicles, or in manufacturing facilities, or any other not-consumer-focused-but-still-generally-available-to-businesses equipment, you do not have to be an authorized dealer to get your hands on it.

Check out Ebay, which has all manner of used telematics units, license plate readers, traffic signal controllers, PLCs, HMIs, ATM peripherals, even medical devices.

Sometimes, other devices–including devices that have no business being on Ebay–end up on Ebay. Take for example this story about the FBI investigating a voting machine purchased by an election security researcher in 2020.

In some cases, equipment (including very hard to get equipment) “falls off the back of trucks” and into the hands of researchers:

And this is saying nothing of folks who leverage industry connections or more devious methods like social engineering.

In short, counting on hackers to simply not find your product is security through obscurity: it works… until suddenly it doesn’t.

So, assume that it is possible for someone to get their hands on your embedded device, and act accordingly. Bake hardware security into your project from the beginning, so that your hardware engineers can support product security in their component choices, buried traces, and (with the support of the software team), secure boot, efuse settings, memory encryption, and so on.

That way, when some weirdo hobbyist buys your product off Ebay, they’ll struggle to get your firmware, and (hopefully) pick on someone else instead.