Embedded System Security for Hardware Designers

Today, I had the pleasure of an open discussion about hardware hacking with the security experts at VDA Labs in Grand Rapids, Michigan. James King, Ethical Hacker, and Josh Sharpe, Cybersecurity Consultant, walked me through what they look for when trying to compromise an embedded system. I thought I would see what hardware designers can do to slow them down and pass on that information to my fellow designers.

VDA Labs helps companies determine the efficacy of their security solutions by actively attacking devices, systems, and networks at the request of their clients. (They can only have their own systems attacked). After walking around VDA’s office and hearing about the ATM they hacked into “raining money”, and the casino they were scheduled to break into, I was convinced that these were the guys I wouldn't want attacking anything I cared about. These guys prove that embedded system security, both at the physical and logical layers, is something every designer should consider.

A Designer's Role in Embedded System Security

As hardware designers, we must balance designing an easy-to-work with PCB with clear labels, standard connectors, good documentation practices, ease of assembly, optimized cost, and the often neglected appropriate level of security. The unfortunate reality with embedded system security is that the easier you design your board for development, the easier it is for someone with malicious intentions to compromise your system.

In the case of the ATM that rains money, VDA couldn't go into detail on how the attack was executed, but they highlighted that a lot of these systems are just off the shelf components that manufacturers (and anybody) could easily get if they knew what parts to buy. For designers, it’s important to use good data security practices to control access to design information. In regulated industries, such as defense and aerospace, security requirements are put into overdrive.

Embedded system developers have an obligation to consider security at three levels:

1. At the physical level, where a device could be tampered with or probed by an attacker;
2. At the logical (firmware) level, where a device could be controlled via JTAG or Flashed to execute malicious code;
3. At the external or platform level, where a device could be maliciously controlled through external software (e.g., through a web platform in the cloud).

Common Embedded System Attack Vectors

Another attack vector that VDA labs used to gain access is clearly labeled connectors, pins, and part numbers. This type of tampering forces designers to start thinking about what happens in physical layer security to prevent unauthorized access. Such measures range from scrubbing components to remove MPNs to using a James Bond-like forced ESD pulse to forcibly destroy the device.

VDA told me about a device that can sit on top of a microcontroller and extract all the information from the device. This device is expensive, but can likely be thwarted just by using a BGA package instead of a leaded package that exposes sensitive signals. It’s easy to imagine someone gaining control of a system over JTAG if they can get to the right signals. I had never considered the security advantages of a BGA package until that moment, but it seems like a pretty easy change for a lot of extra security.

Obscuring important debug or programming connectors, or even removing them entirely is another recommended practice. It’s simple enough to create an extra drawing which labels all the sensitive signals on a board, maybe it doesn't need to always be on the silkscreen layer. Routing sensitive signals on internal layers and eliminating physical conductor access from the outside is a good step towards protecting those signals. Anyone with enough time, budget, and skill can compromise a design, but easy practices like this can go a long way in discouraging them. As an attacker, if I had to find signals not knowing they were internal, or that the programming header had been scrubbed off of the design, I might consider moving on to something easier to compromise.

Think About Embedded System Security Early

The biggest recommendation I got was to take embedded system security into account from the beginning of the product development cycle, especially if it's going to be a networked device. Even if the device’s application does not warrant extreme security measures, it is important to note that it may be used as a launch point for an attack on another device. Target’s payment processing network was famously hacked through credentials gained from the HVAC system.

Security is one of those things that is often forgotten, declared unimportant for the application, or saved as a final procedure. To combat this mentality, designers need to think about what could happen if their product fell into the wrong hands, or was used to execute someone else’s code. Could anyone be hurt? What damage could be done to your stakeholder’s reputation? What kind of damage could occur? Regulated industries are required to consider these points around embedded system security, but with massive proliferation of new IoT devices, everyone will need to think about these points at the physical level as well as at the logical level.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium and continue reading about digital input sampling for embedded systems in Altium Designer®.