Hardware Security Vulnerabilities that Engineers Should Know

Why should engineers care about hardware security? Because they can help prevent vulnerabilities through design!

Engineers traditionally don't really like talking about security issues. This doesn't, however, negate how important it is for engineers to know about cryptography so that they can address it in their designs moving forward.

So far, we've talked about an engineer's (brief) intro to cyptography, the Diffie-Hellman exchange, and how ECC (elliptic-curve cryptography) works.

Now it’s time to learn how hackers break cryptography, so you can start the long journey to protect your design from common attacks.

 

Why Electrical Engineers Should Care about Security

If you are responsible for providing secure devices to an enterprise-level or safety-critical design, you should discuss your design with your chip-vendors and/or security researchers at every stage of the design process. Companies like Microchip, SiLabs, WolfSSL, etc. have engineers on staff that can assist you with your designs and educate you about security.

After all, there's arguably no such thing as a 100% secure system.

 

“There never was a horse that couldn’t be rode. There never was a rider that couldn’t be throwed.”

 

Security researchers play a life-long game of cat and mouse with hackers. Time and time again, “unbreakable” encryption has been broken. Whether or not your message stays encrypted depends on part selection, how well you design your circuit, how well you implement your code, and whether or not your attacker is sufficiently motivated and equipped to defeat your designs. Your job as an engineer is to do everything you can to protect your private key.

You are probably aware that there is virtually nothing you can do to protect your private keys from a nation-state. The resources that various government agencies can bring to bear against electronic and human targets are significant and overwhelming. Even if the spies aren’t able to retrieve private keys off of a device, they can always hack the computer that programmed the device, infiltrate the plant where the ICs are made, compromise an employee...

Fortunately, you don’t really need to worry about nation-states hacking your devices. Unfortunately, it is usually a much simpler affair than we'd like to believe. A teenager with around $250 worth of hardware and access to YouTube training videos can suss the private keys out of a microcontroller in an afternoon. And a malicious programmer can steal data in just a few minutes.

In order to be prepared for secure design, it's important to understand the threats at hand. Here's a high-level view of some well-known hardware-based security vulnerabilities—and what you may be able to do to mitigate them.

Examples of Embedded Systems Security Issues

Let's look at some major hardware vulnerabilities examples and discuss some tips for more secure design. 

 

Electromagnetic Side-Channel Attacks

Researchers have known about electromagnetic side-channel attacks for decades. Any time a mechanical switch or a transistor changes state, an electromagnetic wave propagates along and outwards from the conductor. If that electromagnetic wave is intercepted by a hacker, they can often reconstruct the data used to create the wave. See Van Eck Phreaking, Tempest, or the video below to learn more.

Mitigating Electromagnetic Side-Channel Attacks 

Use industry best-practices when designing and laying out your PCB. 

1. Place decoupling capacitors as close as possible to power pins.
2. Use a solid ground plane beneath your IC.
3. Use EMI shielding atop your IC.

It won’t stop someone with physical access to your device, but it will make their job that much tougher. 

 

Differential Power Analysis Attacks

To crack encryption on most microcontrollers, all you need is a $0.005 resistor, an analog-to-digital converter, and a rudimentary understanding of the Python programming language.

When the digital gates in a microcontroller switch, they disturb the power rails that lead into a microcontroller. Hackers have learned to place a 50 Ω resistor and an analog-to-digital converter across the power rails to record the minuscule changes in current that occur during microcontroller operation. 

The microcontroller is interrogated via the SPI program/debug interface while the differential power measurement data is recorded. Later, the data is analyzed, and the peaks and pulses are used to correlate and fingerprint individual microcontroller actions. 

Through careful analysis, hackers can pull out almost any information they want from a microcontroller.

Mitigating Differential Power Analysis Attacks

This hack is easily done with software-based cryptographic code, so use crypto hardware accelerators that implement DPA countermeasures whenever possible. As before, use industry best practices in design and layout. Choose a BGA footprint and run your power rails in intermediate layers of your PCB and, if you really have cause for concern, embed your IC in an intermediate layer of your PCB with copper planes above and below and use via stitching all around. After all, if the bad guys can’t get to the power rails, they can’t easily perform differential power analysis.

Alternatively, use a hardware-based security core, since those are not as susceptible to this hack (they are still hackable). Engineers know about this vulnerability and design against it in a variety of ways. As an example, the Silicon Labs Wireless Gecko Series 2 has an integrated security core and Microchip makes a line of security ICs, including cryptographic modules that you can use in your designs.

Man in the Middle Attacks

There are several Man-in-the-Middle attacks. This paper demonstrates an "Invalid Curve Attack". The simpler hypothetical example that follows is just one possible attack vector.

When you play music from your computer through a Bluetooth speaker named “MyTunes,” data moves directly from your computer to the speaker. But when you connect your computer to an external website named “AllAboutCircuits.com,” you may or may not be aware that your computer is not immediately connected directly to another computer called “AllAboutCircuits”. 

The first thing that happens is that your computer contacts your router, and your router contacts a Domain Name Server (DNS) that translates the name AllAboutCircuits.com into an IPV4 or an IPV6 address (104.20.234.39).  This usually happens quickly and the data is stored locally to speed up future browsing.

 

DNS entry for AllAboutCircuits.com on a Windows 10 PC.

 

The data then bounces from computer to router to gateway to switch to etc... to a computer whose IP address matches 104.20.234.39. The number of hops varies from website to website and location to location. At each location, if the computer is not secured, the data can be intercepted, traffic redirected, or something else entirely.

 

This route trace shows all “hops” from my laptop to the AllAboutCircuits.com website

The Setup to the Man-in-the-Middle Attack

There are a variety of ways a man-in-the-middle attack might occur. Consider just this one type of attack.

 

Image of "Bob" from ThisPersonDoesNotExist.com

 

Bob bought a fancy new wireless router. He gets his toy home and hooks it up to his home network. And just to make certain he hasn’t spent too much money on his new toy, he checks his bank account balance on his computer.

 

Image of "Mallory" from ThisPersonDoesNotExist.com

 

Mallory is a hacker. She uses the website shodan.io (or similar) to identify routers, webcams, Raspberry Pi, or IoT devices that are on the internet, sees Bob’s new router, grins and rubs her hands menacingly because she now has a new toy, too.

Mallory uses the default username/password (admin/default, admin/admin, admin/password, etc.) that come with all devices. Most manufacturers use the same username/password for all devices and most people do not bother to change them, so it doesn’t take her much time to find one or more entry points. Mallory simply logs into the device, flashes it with her own firmware, and changes the DNS server to a DNS server of her choosing.

She can do this because:

• Manufacturers lazily use the same username/passwords on all of their devices.
• End-Users overwhelmingly do not change their default passwords.
• Device manufacturers either do not require signed firmware or their private key is compromised and in-the-wild.

Now Mallory has access to a private network. She’s no longer a hacker on the web, she’s now inside Bob’s personal home network, and can watch data move back and forth. The data is encrypted, so she can’t necessarily see what it is yet—but she can see that Bob visits and logs into ThisBankDoesNotExist.com (123.123.123.123) pretty frequently, so she set to work setting up a server and webpage for Bob that is a pixel-perfect copy of ThisBankDoesNotExist.com’s login page. 

Then Mallory changes Bob’s DNS entry for ThisBankDoesNotExist.com to (123.45.67.89)

The Attack

Bob navigates to ThisBankDoesNotExist.com. He doesn't bother typing https:// before the domain name, and through Mallory’s hacks, he isn’t connecting to the correct computer, he's at http://ThisBankDoesNotExist.com -- so no certificate warnings pop up.

Bob doesn’t know any of this though; he sees the pixel-perfect copy and types his username/password in Mallory’s computer, and just as he expects, the account information shows up. 

Except now, Mallory can see everything—every transaction, every authorized account holder, and even Bob’s super-complicated username/password (bob/letmein) that he uses to protect his account information.

 

 

 

The Aftermath of the Hack

Almost all websites use end-to-end encryption. That means the data can only be decrypted at Bob’s computer and the Bank computer. Mallory has introduced a new endpoint. Bob’s traffic is encoded at his computer and decoded at Mallory’s computer. Then the data is re-encoded at Mallory’s computer and decoded at the Bank’s computer. This still appears as end-to-end encryption to both Bob and the Bank. 

But there’s an intermediate endpoint—Mallory’s computer. Mallory can do the same trick to find Bob’s hospital records, email, etc.

How to Secure Embedded Systems

The easiest way to keep your devices secure is to make your products difficult to hack.

If they encounter resistance, there's a chance that the hacker will just move on to the next target. On the other hand, it’s difficult for an individual or a small company to prevent nation-state hacks. Fortunately, many “hackers” are just “script kiddies” who lack the expertise to develop novel attacks and solve problems when they occur. If there isn’t a YouTube video and a GitHub for your device, they won’t know what to do and they’ll move on.

Also, talk to your microchip vendor to learn more about securing your devices. Both Microchip and Silicon Labs were featured prominently in this series of articles because both companies made engineers available for an interview for these articles.

If you design an IoT device there are several things you can do to reduce the likelihood that your customers will lose their life-savings due to your negligent engineering and programming practices. 

In addition to the thoughts mentioned above, consider these additional steps:

1. Design with a microcontroller and toolchain that supports firmware authentication (AKA secure boot). Only correctly signed digital firmware will run on the microcontroller, and only you know the private key. Both Silicon Labs and Microchip (and other vendors) have microcontrollers that support secure boot.
2. Use a microcontroller that has a secure debug feature where possible. Some of these hacks are possible because hackers can inject and retrieve data from the host microcontroller and use it to determine what is happening inside the microcontroller package. If the data comes out scrambled or not at all, they’ll be frustrated and move on. Again, Silicon Labs and Microchip (and other vendors) have this capability.
3. Read about security, ask questions of experts, and send your design to the application engineers at your device manufacturer to receive feedback on your proposed security scheme, board layout, etc.
4. Use anti-tamper techniques to wipe your private key from memory if the device is tampered with.
   • TE Connectivity makes piezo-film sheets that can wrap entirely around your PCB. If the sheet is cut, disturbed, melted, etc., it will generate a voltage to indicate a tamper condition.
   • Use capacitive or inductive sensors (such as those from TI) to detect when your project enclosure has been opened, or Hall-effect sensors to detect when case screws are rotated.
5. Assume that by the time your device is in the hands of the first customer, it has already been compromised. Create a project security blueprint that allows one or many individual devices to be compromised without affecting your entire project.

This article series has been a mere introduction to security. It is your responsibility as an engineer to make the IoT safe for everyone.