Multi-dimensional hierarchical hardware Trojan evaluation method for IP soft core

Abstract

The application provides a multi-dimensional layered hardware Trojan evaluation method for an IP soft core, constructs a Trojan multi-dimensional feature library, performs function integrity analysis to identify a first module in which a Trojan may exist, obtains equivalent RTL level code for a module in which no anomaly is found, takes each module of the RTL level code as a node and takes the calling relationship between each module as a weight to establish an information flow graph, compares the information flow graph with the Trojan multi-dimensional feature library to obtain a second module in which a Trojan may exist, analyzes the information flow graph, and takes a module in which the calling is less than a set threshold, a module with an isolated node and a module adjacent to the isolated node in the information flow graph as a third module in which a Trojan may exist, analyzes the first module, the second module and the third module, calculates code coverage, signal flip rate, signal and clock delay anomaly, power consumption anomaly and layout blocking anomaly, and comprehensively evaluates to locate a module in which a Trojan exists in the to-be-detected IP soft core.

Description

Technical Field

[0001] This invention relates to the field of chip security testing technology, specifically to a multi-dimensional, layered hardware Trojan evaluation method for IP soft cores. Background Technology

[0002] In recent years, hackers have increasingly penetrated electronic systems, from application software to operating systems and chips, and the threat to security is growing exponentially. In addition to viruses and malware in the application layer and operating system, a large number of hardware Trojans are hidden in the underlying chip design. Especially in today's world of specialization, the use of a large number of uncontrollable third-party IP soft cores can bring truly catastrophic security problems to users. The popularization of cloud computing and the Internet of Things has further amplified this impact. Therefore, the detection technology of IP soft core hardware Trojans has become a new research hotspot. Existing methods for detecting hardware Trojans mainly focus on two aspects: one is code review before RTL-level code synthesis to form a netlist, with related research including code coverage self-testing analysis and flip-flop rate self-testing analysis methods. However, such solutions have high requirements for test stimuli and cannot detect signal flip-flops within the encrypted IP soft core, resulting in a lack of universal applicability. The other approach mainly focuses on extended applications of hardware Trojan detection in the chip side channel after tape-out, mostly identifying them by measuring side channel information such as power consumption and latency. However, these methods all require benchmark data, and related artificial intelligence detection methods also require a large amount of test data for training. Under actual conditions, the benchmark data is subject to significant noise interference, and the test accuracy and reliability need further research and improvement.

[0003] Current research on hardware Trojan detection in IP soft cores mostly focuses on a specific type, such as encryption / leakage, or a commonly used function, such as adders / RSA algorithms. The detection process only considers one characteristic and cannot detect encrypted IP soft cores. In large-scale third-party IP soft cores, new technologies such as code obfuscation can change the way Trojan code is expressed, such as splitting watch counters or changing state machine encoding methods, further increasing the difficulty of Trojan code identification. Furthermore, hardware Trojan detection in encrypted IP soft cores cannot be achieved at the RTL level. A complete and reliable method for detecting hardware Trojans in both encrypted and unencrypted IP soft cores has not yet been developed, posing a threat to the current security and self-control of chips. Summary of the Invention

[0004] This invention proposes a multi-dimensional, layered hardware Trojan evaluation method for IP soft cores to address the technical problem that hardware Trojan detection of encrypted IP soft cores cannot be achieved at the RTL level, and that a complete and reliable method for hardware Trojan detection in encrypted / unencrypted IP soft cores has not yet been established.

[0005] To address the aforementioned technical problems, this invention provides a multi-dimensional, layered hardware Trojan evaluation method for IP soft cores, comprising the following steps:

[0006] Step S1: Extract the data of the hardware Trojan and perform feature extraction to build a multi-dimensional feature library of the Trojan;

[0007] Step S2: Perform functional integrity analysis on the IP soft core to be tested to identify the first module that may contain a Trojan horse; for modules that fail to detect anomalies, when the IP soft core to be tested is in an encrypted state, verify it in the FPGA and obtain the equivalent RTL-level code by the FPGA reverse extraction method;

[0008] Step S3: Using each module of the RTL-level code as a node and the call relationship between each module as a weight, establish an information flow graph; extract features from the information flow graph and compare it with the Trojan multidimensional feature library to obtain the second module that may contain a Trojan; analyze the information flow graph, and the modules with calls less than a set threshold, the modules with isolated nodes, and the modules adjacent to isolated nodes in the information flow graph are the third modules that may contain a Trojan.

[0009] Step S4: Analyze the first module, the second module, and the third module, calculate code coverage, signal flip rate, signal and clock delay anomalies, power consumption anomalies, and layout block anomalies, and perform a comprehensive evaluation to locate the module in the IP soft core to be detected that contains a Trojan.

[0010] Preferably, the method for feature extraction in step S1 includes the following steps:

[0011] Step S11: Extract the behavioral features BC = {BC1, BC2, ..., BC} of all training samples. i}, Statistical analysis of various behavioral characteristics BC i Frequency of occurrence in hardware Trojan program T and the frequency of occurrence in legal procedure N

[0012] Step S12: Calculate the mean total frequency E(BC) of each behavioral feature. i ):

[0013]

[0014] Step S13: Calculate the mean squared error of the inter-class frequencies of each behavioral feature:

[0015]

[0016] Step S14: Sort by the size of the mean square error and select the top 15 to form a fuzzy feature set, i.e., the Trojan horse multidimensional feature library.

[0017] Preferably, the code coverage in step S4 includes declaration coverage, path coverage, state machine coverage, trigger coverage, and expression coverage.

[0018] Preferably, the method for calculating the code coverage includes: finding non-executable program segments through the test program ISE group; adding test program groups based on the analysis results of the reverse netlist and the collection of program segments to increase the code coverage; and obtaining the code coverage F(n) after performing simulation tests.

[0019] Preferably, the method for calculating the signal flip rate in step S4 includes: synthesizing the RTL-level code to obtain the gate-level netlist of the circuit, and applying random excitation to the gate-level netlist to obtain the signal flip rate Z(n).

[0020] Preferably, the method for calculating the signal and clock delay anomaly in step S4 includes: adding a shadow register between the registers of the IP soft core to be tested, wherein the working clock CLK2 of the shadow register has the same frequency as the working clock CLK1 of the IP soft core to be tested, and CLK2 has a negative phase shift compared to CLK1; comparing the values ​​of the register and the shadow register in each clock cycle to obtain the signal and clock delay anomaly S(n).

[0021] Preferably, the power consumption is calculated by principal component analysis (PCA) in step S4, which includes the following steps:

[0022] Step S401: Construct the original power consumption data matrix based on the reference soft core:

[0023]

[0024] In the formula, n represents the number of samples, and p represents the number of sampling points for each sample;

[0025] Step S402: For the p vectors X1, ..., Xp of the original power consumption data matrix X, ... p Linear combination, expressed as:

[0026]

[0027] In the formula, a pp Indicates linear coefficients;

[0028] Abbreviated as:

[0029] F i =a 1i X i +a 2i X2 + ... + a pi X p i = 1, ..., p

[0030]

[0031] In the formula, a = (a1, a2, ..., a p )′,X=(X1,X2,…,X p )′;

[0032] Step S403: Maximize the variance of a'X and perform feature extraction;

[0033] Step S404: Based on the results of the feature extraction, the distribution of the IP soft core to be detected and the reference soft core in the dimensional space is compared to obtain the power consumption anomaly G(n).

[0034] Preferably, the calculation method for the abnormal layout block in step S4 includes: comparing and analyzing the circuit layout of the FPGA of the IP soft core to be detected with the data in the FPGA circuit layout feature library without hardware Trojans to obtain the layout block B(n).

[0035] Preferably, the method for comprehensive evaluation in step S4 includes the following steps:

[0036] Step S411: Calculate the code coverage F of the reference soft core. c (n), signal flip rate Z c (n), Signal and clock delay anomaly S c (n), Power consumption anomaly G c (n) and layout partitioning anomaly B c (n), and calculate the reference outlier E using the following formula. C :

[0037] E c =F c (n)*w1+Z c (n)*w2+S c (n)*w3+G c (n)*w4+B c (n)*w5

[0038] In the formula, w i Indicates weight;

[0039] Step S412: Calculate the outlier value E of the IP soft core to be detected using the formula in step S411. t ;

[0040] Step S413: Calculate outlier E t Compared with the reference outlier E C The deviation value U is set as a threshold. When U is set, the corresponding module is considered to contain a Trojan horse.

[0041] Preferably, in step S413, the formula for calculating the deviation value U is:

[0042]

[0043] The beneficial effects of this invention include at least the following: by constructing and analyzing a multi-dimensional feature library of Trojans, RTL-level code, and information flow graph, this invention can initially locate abnormal code modules, reduce the amount of subsequent detection, increase work efficiency, and reduce detection costs. At the same time, the encrypted soft core can be converted into RTL-level code, which can also be evaluated normally. The overall solution has the advantages of comprehensive evaluation dimensions, high positioning accuracy, and wide applicability. The overall evaluation process and calculation difficulty are more comprehensive, and the results are more reliable. Attached Figure Description

[0044] Figure 1 This is a flowchart of a method according to an embodiment of the present invention;

[0045] Figure 2 This is a schematic diagram of the hardware Trojan AES circuit according to an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram showing the comparison of simulation test module coverage in an embodiment of the present invention;

[0047] Figure 4 A schematic diagram of the flip rate under 200,000 sets of random stimuli in an embodiment of the present invention;

[0048] Figure 5 This is a schematic diagram of the simulation waveform analysis of signal and clock signal delay in an embodiment of the present invention. Detailed Implementation

[0049] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0050] like Figure 1 As shown, this embodiment of the invention provides a multi-dimensional layered hardware Trojan evaluation method for IP soft cores, including the following steps:

[0051] Step S1: Extract the data of the hardware Trojan and perform feature extraction to build a multi-dimensional feature library of the Trojan.

[0052] This invention, based on the structure and implementation of hardware Trojans, classifies and collects data such as power consumption and signal latency of hardware Trojans and stores them in a hardware Trojan library to establish a multi-dimensional feature library. Simultaneously, according to the analysis and extraction of hardware Trojan behavioral characteristics, a multi-dimensional feature library is established. Based on the characteristics of hardware Trojans, comparative experiments and analyses are conducted on a large number of chips containing hardware Trojans and legitimate chips. The mean square error method in probability statistics is used to extract hardware Trojan behavioral characteristics that are significantly different from legitimate IP soft cores. The calculation process is as follows:

[0053] Step S11: Extract the behavioral features BC = {BC1, BC2, ..., BC} of all training samples. i}, Statistical analysis of various behavioral characteristics BC i Frequency of occurrence in hardware Trojan program T and the frequency of occurrence in legal procedure N

[0054] Step S12: Calculate the mean total frequency E(BC) of each behavioral feature. i ):

[0055]

[0056] Step S13: Calculate the mean squared error of the inter-class frequencies of each behavioral feature:

[0057]

[0058] Step S14: Sort by the size of the mean square error and select the top 15 to form a fuzzy feature set, i.e., the Trojan horse multidimensional feature library.

[0059] Step S2: Perform functional integrity analysis on the IP soft core to be tested to identify the first module that may contain a Trojan horse; for modules that fail to detect anomalies, when the IP soft core to be tested is in an encrypted state, verify it in the FPGA and obtain the equivalent RTL-level code by the FPGA reverse extraction method.

[0060] Specifically, before starting the detection and identification process, the preprocessing operation of IP soft core functional integrity analysis is first completed. For normal or suspicious hardware Trojan chips, system functional testing must be performed. Since chips with added hardware Trojans will have functional differences from normal chips, functional integrity analysis can identify functionally tampered hardware Trojans. However, since hardware Trojans generally rely on few-state signals, non-exhaustive testing cannot guarantee detection.

[0061] This invention, from the perspective of testing RTL-level IP soft cores, uses a pseudo-exhaustive testing method for IP soft cores to test the chip. The testing method includes, but is not limited to, pseudo-exhaustive testing, and other testing methods are also acceptable.

[0062] The pseudo-exhaustive search method involves dividing the input into functional sub-blocks. Each sub-block's input consists of two parts: external input and inputs from other sub-blocks. These two types of inputs are treated as the sub-block's inputs, and the pseudo-exhaustive search method is used for testing. The inputs of other sub-blocks are treated as constants (0). When a circuit is divided into several functional sub-blocks, and these sub-blocks are only unidirectionally connected under a single input method, the pseudo-exhaustive search method can detect all errors.

[0063] Based on the above functional integrity analysis, if no anomalies are found, it is necessary to further determine and handle the encrypted / unencrypted state of the IP soft core. The process is divided into two cases:

[0064] 1) When the IP soft core is in an encrypted state, the encrypted soft core needs to be verified in the FPGA, and the equivalent RTL-level code can be obtained by the FPGA reverse extraction method.

[0065] 2) When the IP soft core is in an unencrypted state, only the normal function verification of the IP soft core is performed. After the verification is passed, the subsequent detection model analysis is carried out.

[0066] Step S3: Using each module of the RTL-level code as a node and the call relationship between each module as a weight, establish an information flow graph; extract features from the information flow graph and compare it with the Trojan multidimensional feature library to obtain the second module that may contain a Trojan; analyze the information flow graph, and the modules in the information flow graph with calls less than a set threshold, modules with isolated nodes, and modules adjacent to isolated nodes are the third modules that may contain a Trojan.

[0067] Specifically, the key to using information flow graphs in tracking and detecting Trojan workflows lies in the function calls within the AES multi-layered encryption algorithm. This workflow is interwoven with numerous activities unrelated to the Trojan. To discover and track the Trojan workflow amidst these seemingly unrelated functions, the solution is to assume a workflow is a connected subgraph within an information flow graph, which can be analyzed from RTL code. For this acquisition method to succeed, all possible information flows must be captured. If an information flow link is missed, the workflow will no longer be a connected graph, and the Trojan's main function will not be discovered.

[0068] Based on information flow graph theory, an information flow graph is formed by using each module of RTL-level code as a node and the call relationships between modules as weights. Feature extraction is performed on the information flow graph and compared with a multi-dimensional Trojan signature database. This allows for the identification and location of Trojans present in the database.

[0069] The information flow diagram also clearly shows that some modules are called more frequently and have higher weights, while others are called less frequently and have lower weights. Since Trojans are inherently hidden and require certain triggering conditions to be activated, Trojan programs should reside in the less frequently called modules in the information flow diagram. This achieves the initial goal of locating Trojan programs.

[0070] Finding few-state modules in the information flow graph is a key point in the second stage of evaluation and detection. In this invention, a hardware circuit module is assumed to be a connected subgraph of the information flow graph. The mutual calls and frequency of each module are used as edges and weights to form a complete information flow graph. This allows for a clearer identification of relatively isolated nodes in the graph. These nodes may be part of a hardware Trojan. By analyzing and tracing the modules adjacent to these Trojans, the approximate location of the hardware Trojan can be determined.

[0071] Step S4: Analyze the first module, the second module, and the third module, calculate code coverage, signal flip rate, signal and clock delay anomalies, power consumption anomalies, and layout block anomalies, and perform a comprehensive evaluation to locate the module in the IP soft core to be detected that contains a Trojan.

[0072] This step involves conducting simulation tests from five parallel factors: code coverage, signal toggle rate, signal and clock delay, power consumption, and layout partitioning, to achieve the screening purpose. The results of each factor are combined to form a multi-factor evaluation result, which is used to analyze the suspicious modules identified in the first step and precisely locate the Trojan program. In this embodiment of the invention, code coverage includes declaration coverage, path coverage, state machine coverage, trigger coverage, and expression coverage.

[0073] 1) Code coverage analysis

[0074] Code coverage primarily focuses on the controllability of statements or circuit structures. For example, whether statements are executed, or whether registers in a circuit are toggled. Theoretically, coverage can reach 100%, making it an ideal metric for evaluating the security of IP soft cores. With 100% code coverage, if the code contains malicious logic or backdoors, hidden hardware trojans will inevitably be activated. Hardware trojans with explicit functions such as tampering will be exposed, and other trojans that leak bypass information will be easier to detect. However, as design scale continues to grow, verification engineers cannot perform result checks on all internal signals—exhaustive observation of all internal signal waveforms is clearly impractical. Even the best test stimuli cannot guarantee 100% code coverage. Furthermore, if automatic comparison between simulated and expected values ​​is used, due to differences in implementation details, it is often difficult to find corresponding signals in the reference model to generate the expected values ​​for all internal signals in the design. Therefore, verification engineers typically select output signals and some important internal signals as observation signals to check the correctness of functionality.

[0075] First, there's the analysis of declaration coverage, which involves analyzing the number of times each declaration was executed during the verification process. A report will be provided after the simulation, detailing how many times each declaration was executed throughout the entire simulation. If some declarations were not executed, supplementary simulations are required. Second, there's the analysis of path coverage. Since branch control statements are used in the design to perform different operations based on different conditions, path coverage analysis can test whether all branches were executed. The third part is the analysis of state machine coverage, using statistical methods to test which state machine transitions occurred during the simulation. Next, there's the analysis of trigger coverage, checking whether certain local circuits were triggered to perform calculations and operations due to changes in a certain signal during the simulation. Finally, there's the analysis of expression coverage, which verifies the sufficiency of combinations by checking Boolean expressions, specifically whether combinations occurred throughout the verification process.

[0076] In this embodiment of the invention, the overall code coverage analysis process first identifies non-executable program segments using the ISE test program group. Then, based on the analysis results of the reverse netlist and the data collection on the program segments, additional test program groups are added to increase code coverage. Finally, a quantitative measure of code coverage, i.e., an indirect measure of program quality, is determined. Based on this, simulation tests are performed on each suspected module circuit, and the code coverage is then checked.

[0077] Ultimately, the code coverage rate f(n) of different suspicious modules will be obtained. Since these suspicious modules may contain Trojan code, the code coverage rate f(n) of some of these suspicious modules will be lower. Therefore, F(n) = 1 - f(n) is used to represent the anomaly index of the suspicious modules. Thus, the code coverage anomaly index F(n) is used as the first element in the multidimensional factor analysis to quantitatively analyze the suspicious modules.

[0078] 2) Signal flip rate anomaly analysis

[0079] If a circuit contains a Trojan horse, it will be difficult to trigger. Starting with the few-state points of the flip-flop rate, analyze the distribution of these few-state points. If they are relatively discrete, the possibility of inserting a Trojan horse at these few-state points is relatively small. If they are relatively concentrated, it may be because the entire triggering logic and functional logic of the Trojan horse have not flipped. The few-state point may be a node in the Trojan horse's triggering logic or functional logic. Using this characteristic, by applying test stimuli to the suspected circuit and then observing and analyzing the unflipped parts of the circuit, the few-state points can be found. Analyzing the distribution of the few-state points can then very likely lead to the discovery of the Trojan horse inserted in the circuit.

[0080] The identification process in this embodiment of the invention is as follows: After synthesizing the suspicious RTL code, the gate-level netlist of the circuit is obtained, and then random excitation is applied to the gate-level netlist to check the flip rate.

[0081] If the flip-flop rate is 100%, it can be determined that the circuit may not contain a Trojan, and further manual analysis is needed. If the flip-flop rate does not reach 100%, it can be preliminarily determined that the circuit may contain a Trojan, and the flip-flop rate data needs to be analyzed to find the few-state points with relatively few flips. After finding the few-state points, their distribution needs to be analyzed. If the distribution of the few-state points is relatively dispersed, it can be preliminarily determined that the circuit does not contain a Trojan. If the distribution of the few-state points is relatively concentrated, it can be preliminarily determined that the circuit may contain a Trojan. Next, additional test stimuli can be added to reduce the few-state points. The few-state points after multiple additional stimuli are analyzed. If they are relatively dispersed, it can be preliminarily determined that the circuit does not contain a Trojan, and further manual analysis is needed. If the distribution of the few-state points is relatively concentrated, it can be preliminarily determined that the circuit may contain a Trojan, and manual analysis of the concentrated few-state points is needed.

[0082] By measuring the signal flip rate of each suspicious module, a different signal flip rate z(n) is obtained for each suspicious module. Since a smaller signal flip rate z(n) indicates a higher probability of malware presence, an anomaly index Z(n) = 1 - z(n) is used as the suspicious indicator for the signal flip rate of the suspicious module. The signal flip rate anomaly index Z(n) is used as the second element in the multidimensional factor analysis for quantitative analysis of suspicious modules.

[0083] 3) Signal and clock delay anomaly analysis

[0084] The detection of signal and clock delay anomalies can be aided by clock signal detection circuits to assist in the detection of hardware Trojans. In this invention, we combined the reverse netlist analysis results with the chip structure of the RTL-level IP soft core to conduct a comparative analysis of the waveforms before and after, and then analyzed the anomalies of signal and clock signal delay.

[0085] The main principle is to add a shadow register between the original registers. The shadow register's operating clock, CLK2, has the same frequency as the original clock, CLK1, but CLK2 has a negative phase shift compared to CLK1. By comparing the values ​​of the original register and the shadow register in each clock cycle, if the comparison results are not equal, it indicates that there is a skew step in the path delay, thus determining that a hardware Trojan circuit has been implanted in the original combinational logic path.

[0086] Based on the above theory, comparing the clocks of each suspicious module yields different clock delays S(n). Since the existence of clock delays is caused by Trojan code, the magnitude of the path delay can be used as a quantitative indicator to measure whether a module contains Trojan code. Clock delay S(n) is used as the third element in multidimensional factor analysis for quantitative analysis of suspicious modules.

[0087] 4) Power consumption anomaly analysis

[0088] In chips containing hardware Trojans, power consumption will exhibit characteristics different from those of normal chips. We utilize a power consumption data acquisition board to collect circuit bypass information and design a chip power consumption data feature recognition algorithm based on feature matrices to perform chip normality detection and Trojan identification.

[0089] This invention employs Principal Component Analysis (PCA) to analyze power consumption anomalies. Specifically, for n reference samples, each sample has p sampling points; each sample can be represented as sample point X. i (x1,x2…x p ), thus obtaining the original power consumption data array:

[0090]

[0091] X has p vectors X1, ..., X2. p The linear combination is:

[0092]

[0093] In the formula a pp It represents a linear vector.

[0094] Simplifying it, it can be represented as:

[0095] F i =a 1i X i +a 2i X2 + ... + a pi X p i = 1, ..., p

[0096]

[0097] a = (a1, a2, ..., a p )′

[0098] X = (X1, X2, ..., X p )′

[0099] The simplified formula shows that the problem of PCA feature extraction is to find X that maximizes the variance of a'X in order to reduce dimensionality.

[0100] Var(a′X)=E(a′XE(a′X))(a′XE(a′x))′

[0101] Let the eigenvalues ​​of its covariance matrix U be λ1≥λ2≥…≥λ p >0, the corresponding unit eigenvectors are u1, u2, ..., u p .

[0102]

[0103]

[0104] When a = u1, we have

[0105]

[0106] Therefore, a = u1 makes Var(a'X) = a'∑a reach its maximum value, and:

[0107] Var(u1′X)=u1′Σu1=λ1

[0108] At the same time:

[0109]

[0110] After the feature extraction described above, the PCA results have different distributions in the dimensional space. For two different comparison samples, X1 = (x11, ..., x1n) and X2 = (x21, ..., x2n), let the distribution of X1 be F, then we have the following hypothesis:

[0111] H0:F∈Γ0

[0112] Where Γ0 is the distribution to which X2 belongs, the alternative hypothesis can be set as:

[0113] or

[0114] Γ1 is the distribution of F. To test whether the hypothesis is true, we first determine the difference between distributions Γ0 and Γ1 as m(Γ0,Γ1), where m satisfies the following condition:

[0115]

[0116] The larger the value of m(Γ0,Γ1), the greater the difference between Γ0 and Γ1.

[0117] Therefore, H0 is accepted when m(Γ0,Γ1) is small, and H0 is rejected when m(Γ0,Γ1) is large.

[0118] In other words, after performing Trojan detection based on the feature matrix, each suspicious module will obtain a difference value of m(Γ0,Γ1), and the larger the difference value, the greater the probability of the presence of a Trojan. Therefore, it can be assumed that the power consumption analysis difference value G(n) of each suspicious module is m(Γ0,Γ1), and the power consumption analysis difference value G(n) is used as the fourth element in the multidimensional factor analysis to quantitatively analyze the suspicious modules.

[0119] 5) Layout block anomaly check

[0120] A hardware Trojan is a malicious circuit inserted into the original circuit. Therefore, checking for anomalies in the circuit layout can help determine if a hardware Trojan has been implanted. By comparing and analyzing the circuit layout of an FPGA containing a hardware Trojan with data from a feature library of FPGA circuit layouts without a hardware Trojan, an anomaly index B(n) for the FPGA layout containing a hardware Trojan can be derived. This anomaly index B(n) serves as the fifth element in multidimensional factor analysis for quantitative analysis of suspicious modules.

[0121] The purpose of comprehensive hardware Trojan security assessment is to solve the problems of high false alarm rate and low accuracy caused by single-factor analysis. The core of the multi-dimensional hardware Trojan assessment model proposed in this invention is to comprehensively consider the various influencing factors such as code coverage, signal flip rate, delay, power consumption anomaly and layout anomaly after the hardware Trojan circuit is implanted. The hardware Trojan detection and assessment are completed by using five code coverage rate F(n), signal flip rate Z(n), signal and clock delay S(n), power consumption anomaly G(n) and layout block B(n) obtained from the above five aspects. The assessment weight settings in the embodiment of this invention are shown in Table 1.

[0122] Table 1

[0123] elements F(n) Z(n) S(n) G(n) B(n) Weight 0.2 0.2 0.1 0.3 0.2

[0124] In the actual evaluation process, for the reference soft core sample, the corresponding F can be obtained through the evaluation of the above five factors. c (n), Z c (n), S c (n), G c (n), B c The value of (n) is determined by combining it with the weight w. i The outlier E of the standard sample can be calculated. c :

[0125] E c =F c (n)*w1+Z c (n)*w2+S c (n)*w3+G c (n)*w4+B c (n)*w5

[0126] The F-values ​​corresponding to the evaluation values ​​of the five evaluation elements of the IP soft core to be tested are calculated. t (n), Z t (n), S t (n), G t (n), B t The value of (n) can be used to calculate the abnormal value E of the IP soft core to be detected using the above formula. t The deviation value U is calculated using the following formula:

[0127]

[0128] If U is greater than the set threshold of 0.05, then the module is considered to contain a hardware Trojan.

[0129] The present invention will be further described below through specific embodiments.

[0130] Using the AES encryption algorithm circuit as the carrier platform for a hardware Trojan, a functional tampering combined Trojan circuit based on an 8-bit sequence detector and a 4-bit counter was implemented. Figure 2 As shown, the circuit function was verified on the ISE software platform. The hardware Trojan circuit was designed based on the AES circuit. A sequence detector, a counter, and the calling function of the hardware Trojan program were added to the main calling function aesmain.v. When the trigger logic is successfully triggered, the Trojan function is called and started. The Trojan circuit is attached without making large-scale modifications to the original AES circuit. Different scales of hardware Trojan attachments are achieved by designing trigger logics of different sizes.

[0131] During circuit testing, a high code coverage rate is typically required. This necessitates selecting appropriate test codes based on the circuit's structure to ensure 100% code coverage, thereby enabling functional testing and analysis. Simply adding the most basic random test vectors is insufficient for effective circuit coverage and activation. Therefore, for AES circuit structures and implemented functions, it is crucial to write test vectors that provide the most comprehensive coverage possible. After testing the circuit, the code coverage rate is then assessed. Figure 3 As shown in the figure, assuming the code coverage rate f(n) of different suspicious modules, since these suspicious modules may contain Trojan code, the code coverage rate f(n) of some of these suspicious modules will be lower. Therefore, F(n) = 1 - F(n) is used to represent the anomaly index of the suspicious module. For example, the coverage rate f(n) of the trojan_function module in the figure is 67%, and its anomaly index F(n) = 1 - f(n) = 1 - 0.67 = 0.33; the coverage rate f(n) of the trojan_trigger module is 81%, and its anomaly index F(n) = 1 - f(n) = 0.19. The code coverage anomaly index F(n) is used as the first element in the multidimensional factor analysis to quantitatively analyze the suspicious modules.

[0132] When 200,000 sets of random stimuli are applied, the resulting tortuosity report is as follows: Figure 4 As shown in the figure, the switching rates of each signal node clearly reflect the information about the few-state points. A relatively clear judgment can be made regarding the few-state points. Figure 4 The net3, net7, net8, nn9, nn10 and data_temp[0]-data_temp[7] modules clearly show a significant difference from other signals in terms of the number of flips. Therefore, these signals can be identified as suspicious signals and will be the focus of subsequent experiments. Assuming that the signal flip rate of each module is z(n), the smaller the signal flip rate z(n) value, the greater the possibility of the Trojan horse. Therefore, the anomaly index Z(n) = 1-z(n) is used as the suspicious indicator of the signal flip rate of the suspicious module. For example, the flip rate z(n) of the net3 signal in the figure is 0.0018, and its anomaly index Z(n) = 1-z(n) = 0.9982. The signal flip rate anomaly index z(n) is used as the second element in the multidimensional factor analysis to quantitatively analyze the suspicious modules.

[0133] Simulation waveform analysis of clock delay, such as Figure 5 As shown in Table 2, detailed data is presented below.

[0134] Table 2

[0135]

[0136] Since the existence of clock delay is caused by Trojan code, the magnitude of clock delay can be used as a quantitative indicator to measure whether a module has Trojan code. Assuming the clock delay is S(n), then S(n) can be used as the third element in multidimensional factor analysis to quantitatively analyze suspicious modules.

[0137] The training data for the power consumption test consists of power consumption data from four normal chips, while the test data consists of power consumption data from a chip containing malware. The results should be normalized. After extensive testing, chips with a maximum matching rate greater than 60% are considered abnormal, with an error rate of less than 0.5%, demonstrating extremely high accuracy.

[0138] Due to experimental environment limitations, no specific calculation example was provided for the layout detection in this instance. However, the absence of one evaluation factor does not affect the interpretation of this invention.

[0139] In this embodiment, five experiments were conducted, and the percentage of Trojan horse scale, i.e., the percentage of Trojan horse logic to chip logic, were 0.05%, 3%, 1%, 0.5%, and 0.2%, respectively. It can be seen that the present invention has comprehensive evaluation dimensions, high positioning accuracy, wide applicability, high stability of evaluation results, and higher credibility in evaluating hardware Trojan horses.

[0140] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; only preferred embodiments of the present invention are illustrated. The descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. As long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0141] It should be noted that those skilled in the art can make various modifications and improvements without departing from the inventive concept, and these all fall within the scope of protection of this invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A multi-dimensional layered hardware Trojan evaluation method targeting IP soft cores, characterized in that: Includes the following steps: Step S1: Extract the data of the hardware Trojan and perform feature extraction to build a multi-dimensional feature library of the Trojan; Step S2: Perform functional integrity analysis on the IP soft core to be tested to identify the first module that may contain a Trojan horse; for modules that fail to detect anomalies, when the IP soft core to be tested is in an encrypted state, verify it in the FPGA and obtain the equivalent RTL-level code by the FPGA reverse extraction method; Step S3: Using each module of the RTL-level code as a node and the call relationship between each module as a weight, establish an information flow graph; extract features from the information flow graph and compare it with the Trojan multidimensional feature library to obtain the second module that may contain a Trojan; analyze the information flow graph, and the modules with calls less than a set threshold, the modules with isolated nodes, and the modules adjacent to isolated nodes in the information flow graph are the third modules that may contain a Trojan. Step S4: Analyze the first module, the second module, and the third module, calculate code coverage, signal flip rate, signal and clock delay anomalies, power consumption anomalies, and layout block anomalies, and perform a comprehensive evaluation to locate the module in the IP soft core to be detected that contains a Trojan. The method for calculating code coverage includes: finding non-executable program segments through the ISE test program group; adding test program groups based on the analysis results of the reverse netlist and the collection of program segments to increase code coverage; and obtaining the code coverage F(n) after performing simulation tests. The method for calculating the signal flip rate in step S4 includes: synthesizing the RTL-level code to obtain the gate-level netlist of the circuit, and applying random excitation to the gate-level netlist to obtain the signal flip rate Z(n); The method for calculating the signal and clock delay anomaly in step S4 includes: adding a shadow register between the registers of the IP soft core to be tested, wherein the working clock CLK2 of the shadow register has the same frequency as the working clock CLK1 of the IP soft core to be tested, and CLK2 has a negative phase shift compared to CLK1; comparing the values ​​of the register and the shadow register in each clock cycle to obtain the signal and clock delay anomaly S(n); The calculation method for the abnormal layout block in step S4 includes: comparing and analyzing the circuit layout of the FPGA of the IP soft core to be detected with the data in the FPGA circuit layout feature library without hardware Trojans to obtain the layout block B(n).

2. The method for evaluating multi-dimensional layered hardware Trojans targeting IP soft cores according to claim 1, characterized in that: The method for feature extraction in step S1 includes the following steps: Step S11: Extract behavioral features from all training samples Statistical analysis of various behavioral characteristics BC i Frequency of occurrence in hardware Trojan program T and the frequency of occurrence in legal procedure N ; Step S12: Calculate the mean total frequency E(BC) of each behavioral feature. i ): ； Step S13: Calculate the mean squared error of the inter-class frequencies of each behavioral feature: ； Step S14: Sort by the size of the mean square error and select the top 15 to form a fuzzy feature set, i.e., the Trojan horse multidimensional feature library.

3. The method for evaluating multi-dimensional layered hardware Trojans targeting IP soft cores according to claim 1, characterized in that: The code coverage mentioned in step S4 includes declaration coverage, path coverage, state machine coverage, trigger coverage, and expression coverage.

4. The method for evaluating multi-dimensional layered hardware Trojans targeting IP soft cores according to claim 1, characterized in that: Step S4 involves calculating the power consumption using Principal Component Analysis (PCA), which includes the following steps: Step S401: Construct the original power consumption data matrix based on the reference soft core: ； In the formula, n represents the number of samples, and p represents the number of sampling points for each sample; Step S402: For the p vectors X1, ..., Xp of the original power consumption data matrix X, ... p Linear combination, expressed as: ； In the formula, a pp Represents a linear vector; Abbreviated as: ； ； In the formula, , ; Step S403: Make Variance maximization is used for feature extraction. Step S404: Based on the results of the feature extraction, the distribution of the IP soft core to be detected and the reference soft core in the dimensional space is compared to obtain the power consumption anomaly G(n).

5. The method for evaluating multi-dimensional layered hardware Trojans targeting IP soft cores according to claim 1, characterized in that: The method for comprehensive evaluation in step S4 includes the following steps: Step S411: Calculate the code coverage F of the reference soft core. c (n), signal flip rate Z c (n), Signal and clock delay anomaly S c (n), Power consumption anomaly G c (n) and layout partitioning anomaly B c (n), and calculate the reference outlier E using the following formula. C : ; In the formula, w i Indicates weight; Step S412: Calculate the outlier value E of the IP soft core to be detected using the formula in step S411. t ; Step S413: Calculate outlier E t Compared with the reference outlier E C The deviation value U is set, and when U is set to a threshold, the corresponding module is considered to contain a Trojan.

6. The method for evaluating multi-dimensional layered hardware Trojans targeting IP soft cores according to claim 5, characterized in that: In step S413, the formula for calculating the deviation value U is: 。

Images