Protecting integrated circuits from silicon Trojan horses

Story

February 10, 2009

Post-fab validation IP instruments are protecting military SoCs from dangerous "Trojan-horse" logic.

With complex integrated circuits functioning in and around virtually all aspects of consumer, industrial, and military electronics, secure manufacturing of these devices has become a vital issue. For economic reasons, nearly all ICs are fabricated by foreign foundries and include Intellectual Property (IP) cores supplied by a wide range of third-party technology providers. IC development is often outsourced to design and test service vendors who use automated tools from many different vendors.

This common process from design to manufacturing provides wrongdoers with numerous opportunities to insert Trojan-horse logic – effectively a hardware hack aimed at sabotaging an IC’s mission-critical functionality. Until now, no reliable methods existed to guarantee pre-deployment detection of this kind of rogue silicon attack. This problem raises national-security implications of staggering significance: A Trojan can wreak havoc in the basic civilian infrastructure (electric grid, communication, and banking networks), sabotage critical missions, disable weapon systems, or provide back-door access to otherwise highly secure systems. However, new reconfigurable post-fab validation IP instruments are aiming to solve the Trojan problem.

Trojan attacks and possible defenses

Trojan attacks can occur in a variety of ways. For example, a Trojan might be inserted into an IP core provided as an RTL model. Such a Trojan could be designed to be activated in a field-deployed IC by a time-bomb mechanism (for example, “disable the core one month after system reset”) or by a booby-trap mechanism (for example, “set the core in test mode after 100 billion packets have been processed”). Intrusions such as these ensure the Trojan will not be activated during pre-silicon verification (using simulation or emulation) or even during conventional silicon validation. Formal verification methods are not capable of dealing with the full functional range of today’s SoC designs. If the Trojan is never activated during simulation or emulation, it could be identified by analyzing areas with low functional coverage during pre-silicon verification. But typically a complex IC is sent for tapeout with many areas still having incomplete functional coverage, as complete coverage cannot be achieved in practice.

In post-silicon testing, most proposed Trojan detection techniques analyze different physical characteristics of the IC (such as power consumption, timing variations, and layout structures) with respect to a perfect, and perfectly trustable, reference. However, the presence of a Trojan in the RTL model of the device precludes having a such a perfect “golden model”; this invalidates the basic assumption that is the cornerstone of most detection methods. Even if a golden model does exist, such a model covers only the functional logic. Insertion of infrastructure logic in the design for testability, reliability, manufacturability, and so forth provides many additional opportunities for hiding Trojans “in plain sight.”

Consider a two-stage attack that first inserts a Trojan in the layout model using spare gates without any connection to the functional logic, then follows up with a Focused Ion Beam (FIB) attack that connects the Trojan to the functional logic. Such a Trojan would be invisible until the FIB attack occurs. Destructive reverse-engineering techniques are not applicable since the FIB attack would target only a subset of the fabricated ICs. Today, we don’t have any scalable non-destructive technique able to detect modifications introduced by a FIB attack. But even if we had such a technique, it would be extremely difficult to use it effectively on a large number of ICs.

Table 1 summarizes the analysis of the different types of pre-deployment Trojan detection techniques. The inescapable conclusion is that classic detection methods cannot guarantee that ICs deployed in the field are Trojan-free. (This does not mean that we should not use pre-deployment detection techniques. They are necessary but not sufficient.)

Table 1

(Click graphic to zoom by 1.4x)

Clearly, today’s complex IC designs need deeply embedded infrastructure logic to implement post-deployment security checks during normal operation. However, the amount of embedded logic required to comprehensively check the security of an entire IC may be prohibitively expensive. Plus, security requires that checking logic be invisible to attackers and to any embedded software running on the device in question. No efficient solution has historically satisfied these requirements, until now.

A new approach for detecting Trojan attacks in SoCs

A new approach for detecting Trojans in SoCs involves adding reconfigurable Design-For-Enabling-Security (DEFENSE) logic to the functional design to implement real-time security monitors. This infrastructure logic consists of embedded, software-configurable silicon “instruments” that can implement a range of security checks to monitor an IC’s operation for unexpected or illegal behavior. Reconfigurability allows a large number and variety of checks to be implemented on shared IP-instrument hardware. Being reconfigurable, its function is not visible to reverse-engineering efforts that analyze the circuit. Additionally, unlike FPGA-like hard macros, the soft-reconfigurable logic cannot be distinguished from functional ASIC logic.

Reconfigurable IP instruments can be inserted at any stage in the design (RTL, netlist, layout, and silicon), do not rely on a golden reference model, and are application- and technology-independent. In this implementation, the “service” logic is indistinguishable from “mission” logic. “Service” logic is also invisible to the application and system software and therefore protected from software-based attacks. Figure 1 shows the architecture of an SoC with infrastructure logic inserted. The insertion is done at RTL, with the designer selecting the important signals to be monitored. The instrumented RTL model is then processed by standard chip design flow.

Figure 1

Signal Probe Networks (SPNs) are configured to select a subset of the monitored signals and transport them to Security Monitors (SMs). An SPN is a distributed pipelined MUX network designed to support multiple clock domains. An SM is a programmable transaction engine configured to implement an FSM to check user-specified behavior properties of the signals currently brought to its inputs to be analyzed. The Security and Control Processor (SECORPRO) reconfigures SPNs to select the groups of signals to be checked by SMs and reconfigures SMs to perform the required checks. The configuration of one SM does not interrupt the normal system operation or the checking activity of other SMs. All configurations are encrypted and stored in the secure flash memory, and all security checks are application- and circuit-dependent.

Instrument logic inserted in the IC performs two types of checks. The first type is a set of user-specified security violations such as:

• An attempt to access a restricted address space
• A control signal supposed to be inactive is activated
• Denial of service occurs
• A core responds to a request addressed to another core
• A core with a deactivated clock has output changes
• A core enters a mode of operation that is illegal in the current system state

The second type of checks consists of the general correctness properties of system behavior. The rationale for this is that an activated Trojan will make the system operate in an incorrect way. These checks might be the same that were performed in pre-silicon verification. For example, these could include the assertions used in simulation to verify the correct implementation of the standard communication protocols used on-chip (AMBA, PCI, and so on) or the behavior of a specific block.

Thus, tools are provided to define the “personalities” for the reconfigurable instruments. To define a check, a chip designer specifies the FSM to be implemented by a security monitor. All checks are prepared and verified pre-deployment in a secure environment, and their corresponding configurations are preloaded in the secure flash. The chip manufacturer does not have access to, and therefore cannot know, the contents of the flash memory.

In a powered-off chip, the reconfigurable logic is “blank” (unprogrammed), thus its function is perfectly concealed from attackers trying to reverse engineer the device. Similarly, the control logic of SECORPRO is configured at power-on from the secure flash, so its function is also invisible to an attacker. As shown in Figure 1, the security checkers are not accessible from either the functional logic or from the embedded software. Similarly, SECORPRO is invisible to the other on-chip application processors.

Countermeasures first

When an attack is detected, the first step should be to deploy countermeasures such as disabling a suspect block or forcing a safe operational mode. An intelligent infrastructure platform can implement countermeasures by controlling specified signals by the Signal Control block that enables SECORPRO to override the value of a signal (see again Figure 1). For example, if a core exhibits illegal behavior, SECORPRO may isolate that core by disabling its clock, powering it off, resetting it continuously, or forcing safe values on its outputs.

These represent only basic counter-measures that need to be integrated in a system-level solution for surviving detected attacks. System-level recovery may combine techniques such as provision of fail-safe states, spare logic to replace misbehaving logic, and returning to last safe checkpoint. These topics, however, are beyond the scope of this discussion.

Modern ICs get secure

Security for today’s integrated circuits demands a reconfigurable infrastructure platform for post-deployment detection of Trojan attacks against ICs in mission-critical applications. Such technology exists as a natural extension of commercially available silicon-proven platforms designed by DAFCA, Inc., used for in-system silicon validation and debug to prevent wrongdoers from impairing or interfering with an IC’s mission-critical functionality. The national-security issues solved by this approach can introduce a new level of protection against infrastructure disruption, weapon-systems sabotage, or other such security breaches.

Miron Abramovici is cofounder and CTO of DAFCA, Inc. Prior to DAFCA, he was a Distinguished Member of Technical Staff at Bell Labs in Murray Hill, NJ. He coauthored ‚ÄúDigital Systems Testing & Testable Design,‚Äù adopted worldwide as a standard textbook. He is author of more than 100 publications and designer of 29 issued patents. He was principal investigator on large projects funded by DARPA and NIST. He is a Fellow of IEEE. He can be reached at [email protected].

Peter L. Levin is president and CEO of DAFCA, Inc. Prior to DAFCA, he was a general partner in the Munich-based venture capital firm Techno Venture Management (TVM). Peter served as a White House Fellow and presidential appointee during the Clinton administration, serving as special assistant to the director of the Office of Management and Budget; assistant to the counselor to the President; and an expert consultant to the presidential science advisor. He began his academic career at Worcester Polytechnic Institute, where he received the National Science Foundation Presidential (G.H.W. Bush) Young Investigator Award for his work in high-performance computing. He can be reached at [email protected].

DAFCA, Inc.

774-204-0021

www.dafca.com