How Code Is Embedded

By Ambuj Kumar, System Architect at Rambus Cryptography Research Division
Today, chip development and manufacturing processes have become exponentially complex. A typical chip may include dozens of semiconductor IPs, using various EDA tools, and developed around the globe,.

The chip itself goes through very complex lifecycle from RTL through netlist, GDS data, wafer, and packaged die, to eventually become an end-user recognizable device.

At every stage of the chip manufacturing process, an adversary can, maliciously, alter the chip. Typically, it is the ASIC engineers who write the high level code (Verilog or VHDL). There is little to stop a disgruntled or otherwise malevolent engineer from include malicious code in the high level code. This code, just like the other code, gets synthesized into netlists, which, unlike high level code, are harder to analyze manually. Thusly, the malicious code may go unnoticed.

This strategy is particularly effective if the bad code is smaller in size and scope compared to the good code. However, it is possible that such an insertion may be flagged by an RTL – gate equivalence checker EDA tool. Unless, of course, there is collusion between person running equivalence checker and the malevolent engineer.

It is also possible for an EDA tool (either during synthesis or during backend) itself, to alter hardware logic without any knowledge of the engineer using it. This can happen if the tool is malevolent or is working under a rogue host process (e.g., virus or malware).

Another case is where a malevolent IP vendor can, knowingly provide an IP with malicious code to a chip manufacturer. Often times, IP vendors provide only a gate level implementation, so the chip manufacturer cannot do RTL to gates comparison.

Similarly, during chip fabrication, an attacker may add malicious logic. Such an attack is hard to notice if design and fabrication are done in different companies in different geographies, as is the case with many fabless designs.

Additionally, a device (like a smartphone) is vulnerable to insertion attacks during board assembly where an extra component can be added or a genuine component can be replaced by a malicious component.

A typical smartphone has tens of embedded processors each with its firmware. So, a malicious firmware developer can mixtheir malicious code with genuine firmware code.

Once a malicious code is inserted into the system, it may remain dormant until an opportune moment arises. Trigger events may be based on time or on a specific operation. For example, malicious code may wait for a cryptographic operation with a specific data pattern before it triggers. Once it triggers, it may expose cryptographically sensitive keys, for example.

If malicious code is attached to firmware running on an embedded processor, the malicious code may wait for operations like memory access to a specific address, or when particular data is accessed.

Once the code becomes active, there are a number of actions that can occur. For example, it may escalate privilege of the user process. Or allow the process to access any portion of memory, including restricted.

The fundamental concern is that a very small in-hardware (or low level firmware) code can drastically change behavior of the system. For example, a system may use PKI based scheme to authenticate externally loaded code. The malicious code may change the public key used for authentication thereby giving a malicious user complete control over the system.

Since hardware (or low level firmware stored in ROM/OTP) is harder to replace, recovering from a hardware malicious code is complex and costly.

Since hardware is the most privileged portion of the system, if hardware is malicious, all bets are off. System can expose any sensitive date (including credentials, private data, or sensitive keys) to a remote hacker.