Hardware Trojan Detection Using Effective Property-Checking Method

Abstract

Hardware Trojans refer to additional logic maliciously implanted by attackers in integrated circuits (ICs). Because of the potential security threat of hardware Trojans, they have attracted extensive attention to security issues. As a formal verification method, property checking has been proved to be a powerful solution for hardware Trojan detection. However, existing property-checking methods are limited by the unity of security properties and the model explosion problem of formal models. The limitations above hinder the practical applications of these methods. To alleviate these challenges, we propose an effective property-checking method for hardware Trojan detection. Specifically, we establish the formal model based on the principle of finite state machine (FSM), and the method can alleviate the model explosion problem. For property writing, we extract the core behavior characteristics of hardware Trojans and then generate properties for the verification of certain types of hardware Trojans. Experimental results demonstrate that our approach is applicable to detect information leakage and denial of service (DoS) hardware Trojans by verifying security properties.

1. Introduction

With the rapid development of the integrated circuit production industry, more and more third-part intellectual property (IP) cores are used to form systems on chips (SoCs) in an integrated circuit design process [1]. However, this design mode has attracted the attention in security fields due to hardware Trojans [2] inserted in third-party IPs. The definition of hardware Trojan is the malicious logic inserted into integrated circuits by attackers in order to do damage to chips. The function of hardware Trojans include information leakage, denial of service, function tampering, and performance reduction.

To ensure the security of ICs, many methods have been developed targeting hardware Trojan detection [3,4,5,6,7,8,9]. Formal verification has been proved the most effective among all the existing methods. The formal method mainly includes three methods: property checking, equivalence checking and theorem proving. Property checking is the most automatic and powerful technique in the field of formal verifications.

Some formal verification-based hardware Trojan detection methods have been proposed. However, it either is hard to deal with the state explosion problem for existing methods, or it lacks automatic implementation for the whole verification process. To solve these problems, we propose a framework to automatically extract FSM models from RTL design and check the general property for hardware Trojan detection purposes.

The main contributions of this paper are as follows.

• We proposed a totally automated formal verification framework for hardware Trojan detection, including FSM-based model building, security property generation and verification processes.
• The FSM model which describes the behavior of the circuit is, for the first time, automatically extracted from RTL design for hardware security verification. The state explosion problem is relieved by this modeling method.
• Security property for hardware Trojan detection is generated according to the common behavior of hardware Trojans. The property can be used to check a class of hardware Trojans.

The rest of this paper is organized as follows. In Section 2, the threat model is introduced and previous work on formal verification-based hardware Trojan detection methods are discussed. In Section 3, we introduce our automatic framework and explain the modeling parser in detail. Section 4 shows the experiment results for our framework on an RSIC-V CPU benchmark. In Section 5, we discuss the limitations of our work. Finally, conclusions are drawn in Section 6.

2. Background

2.1. Threat Model

Hardware Trojan can be inserted at any stage in an IC lifecycle. In this paper, we assume that the adversary can access the hardware design and make modifications to RTL code or a netlist file to create information leakage paths. On the other hand, we assume that the adversary has knowledge of the functionalities and design details of the hardware design. Therefore, they can obtain the information they want by triggering the Trojan and observing the Trojan output.

2.2. Related Work

Formal verification is firstly proposed for software system verification. However, currently, formal methods have been widely applied in hardware security verification areas. Immigrated from the proof-carrying code, the proof-carrying hardware (PCH) framework has been proved effective in hardware security assurance in soft IP [10,11,12]. This framework relies on theorem proving and equivalence checking. Drzevitzky proposed the first PCH framework to verify the security of dynamically reconfigurable hardware platforms by checking the equivalence of design specifications and design implementations without setting security properties [13]. Guo et al. developed an integrated theorem-proving and model-checking method for a PCH framework. This method can be used to verify large systems [14]. However, the PCH framework is lacking in automation.

Model-checking-based hardware security verification methods are more advanced in automated implementation. He proposed an FSM-based model-building method and hardware Trojan detection strategy [15]. The model of GLIFT is used to track sensitive information flow and verify the property of information leakage [16,17,18]. However, existing model checking-based hardware Trojan detection methods suffer from the state space explosion problem and cannot be used exclusively for verifying large designs. In addition, property writing still relies on manual analysis, and it obeys the “one case one discussion” principle, which increases the time overhead of verification.

2.3. Property Checking

Property checking is a method to detect security properties from all reachable states and behaviors in a given model. One of the most outstanding advantages of property checking is that it has a high degree of automation. When the model and properties are prepared, the process of detection or verification will be totally automatic in a property checker. The other advantage is that the property checker can generate a countermeasure if the model cannot satisfy the property. This feature can help the verifier track the malicious logic in hardware design when using property checking in hardware security verification.

UPPAAL [19] is a model checker jointly developed by Uppsala University and Aalborg University for real-time system verification. UPPAAL supports timed automata. It also supports integer variables, user-defined functions, and channel synchronization extensions. The model checker has three parts: editor, simulator and verifer. The editor is where the model of the system is established. The simulator is a part of the simulation of the model established in the editor. The verifier is a part that we use to write and validate security properties. The process of verification is totally automatic. UPPAAL will use an on-the-fly method to automatically find out whether there exists a path that satisfies the property.

2.4. Finite State Machine

Finite state machine is a model that describes the state transitions of digital circuits. The FSM model can represent the total states of the circuit and transition relationships between them. A finite state machine generally consists of three parts: the initial state, a set of intermediate states, and a set of transition functions between a series of states. The initial state is denoted as s${}_0$. The intermediate states are defined as s${}_i$. The set of total states is denoted as S. The transition relationship is denoted as C. The construction of FSM is shown in the following equations:

$$s_0,s_i\in S$$

(1)

$$FSM:=C\wedge S$$

(2)

3. Methodology

The proposed framework automates the property-checking process by extracting the FSM model of a circuit from its RTL design. It extracts the behavior state and transition condition between states from the circuit and converts them to formal constraints. Moreover, the general property for hardware Trojan verification is summarized. Finally, the formal model and security property are input to UPPAAL to achieve the goal of hardware Trojan verification and detection.

3.1. Framework Overview

As shown in Figure 1, the working procedure of the proposed framework is divided into the following steps. The RTL design is firstly input to the RTL to an FSM parser. This parser helps to extract FSM from RTL circuit design. Details of the parser will be discussed in Section 3.2. We denote the RTL design with R, the FSM with F and the extraction relationship with f. The FSM is then converted into a formal model through an FSM to XML parser. In the formal model of FSM, states are specified with name and location in GUI, and transition relationships are defined with source state, target state and transition condition. We denote the formal model with M and the conversion relationship with g. The modeling procedure is shown as follows.

$$\mathbf{R}\stackrel{f\left(\mathbf{R}\right)}{\to }\mathbf{F}\stackrel{g\left(\mathbf{F}\right)}{\to }\mathbf{M}$$

(3)

In this framework, we conclude general security property for hardware Trojan detection. Take information leakage hardware Trojan as an example. The function of most information leakage hardware Trojans is that when the predefined input signal is observed, the Trojan will be activated and start to leakage sensitive information. The core behavior of the information leakage Trojan function is that the channel of information leakage is triggered. Mapped to the FSM model, the behavior of a triggering Trojan to leak information is translated into a state, and the trigger condition is translated into a transition condition to the state. So, the general property we conclude for Trojan detection is: “there is a path that can reach the trigger state in the model”. We translate the property to logic language as follws.

$$E<>Model.Trojantrigger$$

(4)

In this property, E means Exist, <> means Future, Model is the name of model and Trojantrigger is the name of the state. The property means there is a path in Model that can reach the state Trojantrigger.

If there is a Trojan, counterexample generation property is needed to localize the Trojan. The counterexample generation property assumes that there is no Trojan in the circuit. It will not pass the verification when the Trojan exists. Then, the counterexample generation function of the model checker is used to search the Trojan triggering function in the model. We denote the general property with p and the counterexample generation property with p’. The relation between p and p’ is:

$$p^{\prime }:=\neg p$$

(5)

Represented by logic language, p’ is shown as Equation (6).

$$A\left[\right]notModel.Trojantrigger$$

(6)

In this property, A means All and [] means Globally. The property means there is no path in Model that can reach the state Trojantrigger.

3.2. RTL to FSM

We developed an automatic parser for extracting the FSM model from the RTL design of the circuit. The parser is developed in Python language.

As shown in Figure 2, different from the existing FSM model-extracting method, our FSM model takes behaviors of the circuit as the state and takes the condition of circuit behavior as the condition of state transition. This modeling method more intensively focuses on describing the function of the circuit compared with pyverilog. Ref. [15] builds the FSM model basing DFF in circuit netlist, which faces the state explosion problem that when there are n DFFs, the amount of state is 2${}^n$. Compared with this method, our proposed method can avoid modeling massive amounts of states and alleviate the state explosion problem.

There are five parts of this parser. In the code-collating part, the parser analyzes the format of the RTL code. Blank spaces, blank lines and unnecessary line feeds are removed. The format of the code is adjusted to be more unified, so that the model can be extracted more efficiently. Then, in the state-locating part, the parser tracks the keywords representing conditions and selects the code block between the beginning and ending of the condition statement. On this basis, in the state-extracting part, the parser traverses the code block tracked at the last step to make clear the state to be extracted. We regard the result of assignment behavior in the condition code block as the state. When the parser traverses the whole code block and checks every condition statement, the state is defined. Then, in the transition condition-extracting part, the condition of assignment behavior is extracted as the transition condition between states. Finally, in the model-generating part, the states and transition conditions are integrated to form the whole FSM model.

4. Experiment

To demonstrate the proposed formal verification framework, we set up the experiment to verify the security property in an RISC-V CPU core [20]. Trojans are inserted into the CPU RTL design.

4.1. Experimental Setup

The main tool we used for experimentation is UPPAAL. We applied UPPAAL to verify if there exists a Trojan in the RTL design of the circuit. All the experiments are set in Windows 10 on a computing manchine with Core(TM) i5-6400 CPU @ 2.70 GHz and 12 GB memory. We choose a CPU core to evaluate the practicality of the proposed framework. The CPU core is designed in RISC-V architecture.

For fitting to the attack model, we insert some Trojans into the RTL design. The Trojans we insert into the CPU core are standard Trojans from Trust-Hub [21]. The function of the inserted Trojans includes information leakage and denial of service. We set the instruction signal in the control unit as a trigger signal of the Trojan. The parser extracts the FSM model from the Trojan-inserted RTL design. After that, the formal model of FSM as well as security properties are input to the model checker. Finally, the model and properties are checked together in UPPAAL.

4.2. Modeling and Trojan Detecting

In Figure 3, we show the structure of the RISC-V CPU core we used as a benchmark and an insertion template of hardware Trojan. Specifically, taking information leakage Trojan as an example, the trigger of the Trojan is connected to the first 7 bits and bits [14:12] of the instruction signal of the CPU core. Other bits of instruction signal are set as sensitive information. Whenever the predefined trigger signal is observed, the Trojan leaks the sensitive information.

To further alleviate the state explosion problem, we modeled the circuit separately according to the modules’ circuit design structure. The FSM model of the control unit module of the CPU core is shown in Figure 4 as an example. The model includes four parts: the gray dot means state, the edge shows the transition relationship between two states, the green statement means the transition condition between two states and the blue statement means the synchronization variation, which is used to show the control relationship between two modules. The connection between different modules is realized by synchronization variation in UPPAAL.

To detect the hardware Trojan inserted into the benchmark, the security property is generated according to the general property we discussed in Section 3.1. If the property passes the verification, it shows that there is a Trojan in the circuit. The counterexample generation property is developed to track the trigger condition of the Trojan. The counterexample generation property fails verification; by the counterexample, in other words, the path to the Trojan state will be found.

4.3. Results and Analysis

Table 1. Results of Trojan detection experiments.

Trojan	Function	Detected or Not	Counterexample Found or Not	Total Time (ms)
T400	Information leakage	Y	Y	150
T1300	Information leakage	Y	Y	192
T1500	Information leakage	Y	Y	200
T500	Denial of Service	Y	Y	196
T1800	Denial of Service	Y	Y	171
T1900	Denial of Service	Y	Y	205

shows the results of our experiments. We choose several Trojans whose function includes information leakage and denial of service as experiment benchmarks. All the Trojans are triggered by specific signals.

All the Trojans are detected by security property generated according to the general property, which shows the high automation of the framework. The total time of security property verification and counterexample generation property verification is shown in the last column of Table 1. The total time of different Trojan benchmarks does not make much difference, which is because that the model scale of the original circuit is too large compared to the Trojan. Therefore, the scale difference between different models is small. As a result, there is little difference in total time.

Furthermore, the counterexample is generated after the counterexample generation property is verified. Take T400 as an example, as shown in Figure 5, Process1 is the instantiation of the original circuit model and Process2 is the instantiation of the Trojan model. The connection between two models relies on the synchronization variation set. When the instruction of alh is input, the original circuit model is transferred to the behavior state represented by alh, and the Trojan model is transferred to the activated state in the meanwhile. The counterexample specifically shows the trigger behavior of hardware Trojan. The counterexample can also help developers improve their designs.

5. Limitations and Discussion

Our proposed framework has an excellent performance in Trojan detection at the RTL of the circuit. However, there are still some limitations, such as a lack of ability to detect an always-on Trojan and determine the function of the Trojan. Our security property generation method framework is based on the trigger behavior of Trojans; if there is no trigger behavior, the security property will lose the verification target. In addition, our proposed method can only detect if there is a Trojan but cannot find out the malicious behavior of the Trojan. The developers need to check the RTL design according to the counterexample and then ensure the malicious behavior of the Trojan.

In the future, we will take always-on hardware Trojans into account. We will focus on the function behavior of Trojan payload to propose a more targeted general property which can determine the function of a Trojan automatically.

6. Conclusions

In this paper, a property checking-based Trojan detection framework is proposed. The RTL design is firstly translated to an FSM model through a parser. Then, the general property that can support to verify a type of hardware Trojan is concluded. Finally, the model checker UPPAAL verifies the FSM model with security property. There are three advantages of our proposed framework. Firstly, the whole process of hardware Trojan detection and verification is automated. Compared with other works, our paper realizes the automatic generation of security property, which fills a key link in the automation process of formal verification. Secondly, the model we build according to circuit RTL behavior is more refined and more suitable for security verification. So, the work in our paper can deal with the state explosion problem better. Thirdly, our property generation method breaks through the restriction of “one case, one discussion”. The property can support the detection of a kind of hardware Trojan which reduces the human participation. In the future, more targeted verification properties will be proposed, and always-on Trojans will be taken into account. Therefore, the depth and scope of verification will be extended. In addition, the theory of deep learning and neural network will be used in the model-building process. In addition, the framework will become more standardized and automatic in our future work.