Mobile QR Code QR CODE

  1. (Electronics and Communication Engineering, Kwangwoon University, Korea)



Hardware security, hardware trojan, third-party IP trust, LFSR-based

I. Introduction

In the long years, hardware has been viewed as a trusted party of the whole computer system where it executes all the signals coming from the software. But, as the cost of fabrication technology dramatically increases, several semiconductor businesses engage in a fabless business model. This business model includes outsourcing fabrication and packaging which includes adopting intellectual property (IP) cores in designing to lower the production cost. Furthermore, faster time-to-market adds up the reason to go on fabless model. With this scheme, security of the design is less prioritized which can be resulted in various threats. Insertion of hardware trojan on the IP cores can be one of these threats.

In general, hardware trojans are malicious modifications and insertions to system’s circuit design which is difficult to detect during verification for a reason that it only executes when a trigger is activated at certain rare conditions. An adversary uses hardware trojan to compromise the functionality and security of a chip, like for example, changing the functionality at rare condition, reducing the reliability and lifetime, disabling the system at specific time or stealing secret information. The insertion may occur in different abstraction level where among all levels, the register-transfer and gate level have high trojan insertion occurrences. However, in gate level it requires high level of sophistication to successfully insert a hardware trojan. These stealthy ways of inserting and modifying system’s circuit is a big security threat that need to be considered rigorously. Several methods, from simple prevention solution (1,2) to detection method (3,4), are proposed to increase the trust of the design specially on the third-party IP cores. However, the existing hardware trojan design appeared in the literature are limited and simple which confines the capability of the existing hardware detection and the possible detection methods in the future.

The remaining sections are organized as follows; Section II shows the proposed hardware trojan and Section III explains and demonstrates how comparison scheme is implemented in the existing detection method. Experiment results are shown in Section IV and finally, concluded in Section V.

Fig. 1. General structure of hardware trojan design

../../Resources/ieie/JSTS.2020.20.2.214/fig1.png

Fig. 2. Illustration of circuit and information flow graph (IFG) (a) Proposed hardware trojan circuit, (b) IFG of digital counter, (c) IFG of LFSR, (d) IFG of proposed hardware trojan

../../Resources/ieie/JSTS.2020.20.2.214/fig2-a.png

(a)

../../Resources/ieie/JSTS.2020.20.2.214/fig2-b.png

(b)

../../Resources/ieie/JSTS.2020.20.2.214/fig2-c.png

(c)

../../Resources/ieie/JSTS.2020.20.2.214/fig2-d.png

(d)

II. Proposed Linear Feedback Shift Register Hardware Trojan

1. LFSR-based Hardware Trojan

Hardware trojans can be classified based on its activation mechanism, trigger and payload. Basically, executing malicious functions, which can be defined as the payload, depends on the trigger of the hardware trojan design as shown in Fig. 1. The design of the trigger specifies how stealthy a hardware trojan can be and the inputs for the trigger can be from the external signal through an antenna or from internal circuit signals. Once the conditions are met on the trigger logic, it will send a signal to the payload circuitry to perform the malicious behavior which eventually activates the hardware trojan. Moreover, hardware trojans can be inserted in different phase of the integrated circuit (IC) production lifecycle. The proposed hardware trojan follows these classifications, it employs triggering mechanism and can be inserted in the design phase of the IC production lifecycle specifically on the third-party IP cores.

Existing hardware trojans, specifically the timer-based hardware trojan, uses digital counters as a trigger where it counts the number of clock cycles or the number of rare events on a certain system and executes the payload whenever the timer reaches its maximum value or specified number. In (5), instead of using a digital counter, it used linear feedback shift register (LFSR) and combined with the circuitry of an IP core to have an XORed result from LFSR and non-malicious internal signals. However, this hardware trojan implementation can be detected by considering the high number of incoming signals to the output node as discussed in Section III.

For the proposed hardware trojan, it also employs the use of LFSR, as the trigger and, instead of incrementing the value using the clock or rare events, it changes the value according to its feedback polynomial and compared to the predefined pattern.

2. Extending the LFSR-based Hardware Trojan

Using LFSR alone can be comparable as the timer-based hardware trojan given that the number of the stage is increased to come up with a longer time before the activation of the hardware trojan. But this way of implementation can be detected using the existing hardware trojan detection method as discussed in Section III.

Another way of implementing can be done by adding shift register after the LFSR circuit as shown in Fig. 2(a). The input data from non-malicious internal signals is used to initialize the LFSR and serve as the combination to be compared on the LFSR state to control the shifting of the shift register. The size of the shift register is always (n + 2)-bit where n is the size of the LFSR. The extra 2-bits of the shift register serves as the result values from shifting the shift register which means that its values change whenever a shifting occurs. The shifting happens whenever the state value of the LFSR has the same value with the input signal where input signals are specified non-malicious internal signals. Otherwise, the state value of LFSR is passed to the n-bit value of the shift register. Further, the extra 2-bits of the shift register are added to lower the activation probability. Based on this, Algorithm 1 is proposed. In line 4-6, the value of the LFSR is always passed to the n-bit value of the shift register to vary its value every clock cycle. Then in line 8-10, the hardware trojan signal, which is connected directly to the payload, is triggered when the value of the shift register and the predefined combination is equal.

3. Activation Probability

In order to avoid detection during functional verification, timer-based hardware trojans tend to be large in number which could reach at least millions of cycles. In this assumption, the number of bits of a timer could be approximately twenty bits (since $10^{6} \approx 2^{20}$) (7), which gave an activation probability of

(1)
$a_{p}=\frac{1}{2^{20}}=0.9538 \times 10^{-6}$

Input: Non-malicious internal signals

Output: Hardware Trojan Signal

Initial Value: Initial state of n-bit LFSR from input

1 $\quad$for every clock cycle

2 $\quad$$\quad$ if state of n-bit LFSR is equal to the signal input, then

3 $\quad$$\quad$$\quad$ shift (n+2)-bit shift register by 1

4 $\quad$$\quad$ else

5 $\quad$$\quad$$\quad$ set [(n-1):0] value of (n+2)-bit shift register using

6 $\quad$$\quad$$\quad$ the LFSR state

7 $\quad$if value of (n+2)-bit shift register equals to predefined

8 $\quad$(n+2)-bit combination, then

9 $\quad$$\quad$ Propagate the hardware trojan signal

Algorithm 1. Extending LFSR-based Hardware Trojan

$\quad$

Input: Information Flow Graph

Output: Possible Hardware Trojan Candidate

1 $\quad$for each node do

2 $\quad$$\quad$ if nodes l, m, n creates a loop, then

3 $\quad$$\quad$$\quad$ Add l, m, n in a loop group

4 $\quad$for each node in loop group do

5 $\quad$$\quad$ List all immediate node/s except the nodes already

6 $\quad$$\quad$ in the loop group

7 $\quad$for each immediate node do

8 $\quad$$\quad$ if immediate node is common to all nodes in the

9 $\quad$$\quad$ loop group, then

10 $\quad$$\quad$$\quad$ Report loop group as hardware trojan candidate

Algorithm 2. Proposed extended algorithm

On the other hand, for the proposed hardware trojan with n-bit LFSR and (n+2)-bit shift register, the activation probability can be computed by

(2)
$a_{P}=\left(\frac{1}{2^{n}-1}\right)^{3}\left(\frac{1}{2^{n}-1}\right)\left(\frac{2^{n}}{2\left(2^{n}-1\right)}\right)^{2}$

where $\left(\frac{1}{2^{n}-1}\right)^{3}$ is the probability that the input signal is equal to LFSR state and the degree of three signifies the number of shifting to have (n+2)-bit combination. $\left(\frac{1}{2^{n}-1}\right)$ is the probability that the [(n-1):0] value of (n+2)-bit shift register is equal to [(n-1):0] value of predefined combination. Lastly, the $\left(\frac{2^{n}}{2\left(2^{n}-1\right)}\right)^{2}$ is the probability for the remaining 2-bits to be equal to [(n+2):n] value of predefined combination.

With 5-bits LFSR and 7-bits shift register, the activation probability is $0.2884 \times 10^{-6}$ which is comparable with the 20-bits timer-based hardware trojan, but the number of bits used is lesser. Also, the number of bits is intentionally lessened to prevent from being detected on the existing detection methods.

III. Extending ML-FASTrust for Detection Method

Several methods are proposed to increase the trust of the design specially on the third-party IP cores. In (6), employing register transfer level information flow tracking is proposed by adding a security label to each signal and track the influence of flow of that signal throughout the circuit. However, this method only considers the counter type hardware trojan and focuses on the other input of the activating node rather than on the entire design and characteristics of the hardware trojan design.

Table 1. Proposed Hardware Trojan in ML-FASTrust Framework Experiment Result

Benchmark

Feature 1

Feature 2

Feature 3

Feature 4

threshold: 20

threshold: 20

threshold: 20

threshold:

1

number of loop group

number of nodes

number of nodes

number of nodes

number of loop group

RS232-T300

1

32

33

32

0

RS232-T500

1

32

33

32

0

AES-T900

1

128

110

128

0

AES-1200

1

128

110

128

0

AES-1500

1

128

110

128

0

BasicRSA-T300

1

32

33

32

0

BasicRSA-T400

1

32

33

32

0

LFSR alone

0

0

33

32

0

New Hardware Trojan (extended LFSR)

0

0

7

0

0

Table 2. Proposed Extended Algorithm Experiment Result

Benchmark

Proposed Detection Method

number of loop group

number of nodes

number of nodes where comparison occurs

RS232-T300

1

32

1

RS232-T500

1

32

1

AES-T900

1

128

1

AES-1200

1

128

1

AES-1500

1

128

1

BasicRSA-T300

1

32

1

BasicRSA-T400

1

32

1

LFSR alone

1

32

1

New Hardware Trojan (extended LFSR)

1

5

7

In (7), the method in detecting hardware trojan are based on feature analysis where four (4) different features are introduced to report possible hardware trojan candidate. Feature 1 is specifically for the time-triggered hardware trojan where it reports a loop group with loop nodes that are greater than the threshold. Loop node is defined as a node that contains a self-loop as shown in Fig. 2(b). Feature 2 reports hardware trojan candidate by counting the number of incoming signals of a node and should be greater than the threshold. Feature 3 is the combination of feature 1 and feature 2. And, feature 4 is specifically for DeTrust hardware trojan design (8).

The proposed hardware trojan can be classified under feature 1, thus, extending the algorithm of feature 1 can make the new hardware trojan detectable as shown in Algorithm 2. The extended algorithm includes the detection of the LFSR circuit and reporting this LFSR circuit based on comparison scheme instead of comparing the number of loop nodes to a predefined threshold.

Line 1-3 describe how LFSR circuit is detected. The specified loop means a group of connected nodes that formed a loop. In Fig. 2(c), nodes q2-q4-q3 and nodes q0-q4-q3-q2-q1 are example of a loop. All LFSR circuit will have this kind of connection since there should always be a feedback signal to implement an LFSR circuit.

The remaining lines describes how comparison scheme is implemented. In line 5-7, immediate node means the succeeding node of a node. In Fig. 2(d), s0, s1, s2, s3, s4, s5 and s6 are immediate nodes of q0, q1, q2, q3, q4. If the immediate node is common to all nodes in the loop group, it means that, the values of the nodes in the loop group can possibly be used to compare to other signals like a predefined constant. Thus, comparison scheme is used since timer-based and LFSR-based hardware trojan is triggered if the predefined combination is satisfied.

IV. Experiment Results

1. LFSR-based Hardware Trojan in ML-FASTrust Detection Method

The proposed hardware trojan is tested on the existing state-of-the-art hardware trojan detection method called the ML-FASTrust (7).

Table 1 shows the result of the new hardware trojan on the detection method together with the existing hardware trojans from Trust-Hub benchmark suite (9). Testing with LFSR alone with activation probability comparable as of timer-based hardware trojan and proposed hardware trojan is also included and shows that it is detected by the existing detection method. In feature 2 of new hardware trojan, the highest number that has the maximum number of incoming signals is only seven (7) which comes from the 7-bit shift register which is lesser than the threshold, thus, treated as undetected.

The proposed hardware trojan is implemented using FPGA, where the RTL code is synthesized and translated into a logic level to be physically implemented. Specifically, it is inserted on a 128-bit Advanced Encryption Standard (AES) symmetric-key algorithm where experiment shows that the inserted hardware trojan only incurs 2.78 percent (2.78%) increased of the overall power consumption. With this, the area and power overhead consumed by hardware trojan is greatly much smaller than the size of a normal design and can be considered negligible.

2. LFSR-based Hardware Trojan in Extended Algorithm

The proposed extended algorithm is implemented using C language. The Verilog code of the LFSR-based and counter-based hardware trojan are converted into xml file using Verilator tool (10). The Verilog code is utilized for a reason that in register transfer level occurs the highest insertion and the control of the hardware functionality is defined in this level. Through this conversion, the information flow graph (IFG) can be implemented and further use for Algorithm 2 implementation.

Table 2 shows the result of the proposed extended algorithm. The last column shows the number of nodes where the hardware trojan can have comparison with another signal. In case for the new hardware trojan, the number node resulted to seven (7) since the comparison of LFSR with another signal occurs in the shift register which has a size of 7 bits as depicted in Algorithm 1.

V. Conclusions

In this paper, we have proposed a hardware trojan based on linear feedback shift register and extended it to lower the activation probability. Experimental results show that the proposed hardware trojan evades the existing state-of-the-art detection method. In addition, by extending ML-FASTrust framework using a comparison scheme, the proposed hardware trojan can be detected. With this, a new hardware trojan can be considered in testing and developing future detection method.

ACKNOWLEDGMENTS

This work was supported by Kwangwoon University 2019 and by the MISP Korea under the National Program for Excellence in SW (2017-0-00096) supervised by IITP.

REFERENCES

1 
Vaidyanathan. K., May 2014, Efficient and secure intellectual property (IP) design with split fabrication, Proc. HOST, pp. 13-18DOI
2 
Imeson F., Emtenan A., Garg S., Tripunitara M. V., 2013, Securing computer hardware using 3D integrated circuit (IC) technology and split manufacturing for obfuscation, Proc. USENIX Security, pp. 495-510Google Search
3 
Waksman A., Suozzo M., Sethumadhavan S., 2013, FANCI: Identification of stealthy malicious logic using Boolean functional analysis, Proc. ACM SIGSAC Conf. Comput. Commun. Security, pp. 697-708DOI
4 
Zhang J., Yuan F., Wei L., Liu Y., Xu Q., Jul 2015, VeriTrust: Verification for hardware trust, IEEE Trans. Comput.-Aided Design Integr. Circuits Syst., Vol. 34, No. 7, pp. 1148-1161DOI
5 
Syed Kamran Haider, Jin Chenglu, van Dijk Marten, 2017, Advancing the state-of-the-art in hardware trojans design., IEEE 60th International Midwest Symposium on Circuits and Systems (MWSCAS), IEEEDOI
6 
Armaiti Ardeshiricham, 2017, Register transfer level information flow tracking for provably secure hardware design., Design, Automation & Test in Europe Conference & Exhibition (DATE), IEEEDOI
7 
Chen X., July 2018, Hardware Trojan Detection in Third-Party Digital Intellectual Property Cores by Multilevel Feature Analysis, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Vol. 37, No. 7, pp. 1370-1383DOI
8 
Zhang J., Yuan F., Xu Q., 2014, DeTrust: Defeating hardware trust verification with stealthy implicitly-triggered hardware trojans, Proc. ACM SIGSAC Conf. Comput. Commun. Security, pp. 153-166DOI
9 
Tehranipoor M., Forte D., Aug 2016, Trust-Hub [online], Available: https://www.trust-hub.org/ benchmarks.phpGoogle Search
10 
Snyder W., June 2004, Verilator [online], Available: https://www.veripool.org/wiki/verilatorGoogle Search

Author

Ann Jelyn Tiempo
../../Resources/ieie/JSTS.2020.20.2.214/au1.png

Ann Jelyn Tiempo received her B.S. degree in Electronics Engineering from University of Mindanao Tagum in 2013 and is currently studying for M.S. degree in Electronics and Communication Engineering at Kwangwoon University.

Ji-Hoon Kim
../../Resources/ieie/JSTS.2020.20.2.214/au2.png

Woo-Young Jung received his B.S., M.S. and PhD degrees in Electronics and Communication Engineering from Kwangwoon University.

He is currently a CTO in Innovative Research and Analysis Inc. in Philippines and EPSOLUTE Co. Ltd. in Korea.

Ji-Hoon Kim
../../Resources/ieie/JSTS.2020.20.2.214/au3.png

Yong-Jin Jeong received his B.S. degree in Control and Instrumen-tation Engineering from Seoul National University in 1983.

He received his M.S. and PhD degrees in Electrical and Computer Engineering from University of Massachusetts.

He is currently a professor in the Dept. of Electronics and Communications Engineering, Kwangwoon University.