A hardware design security vulnerability qualitative analysis method and system

Abstract

The application discloses a hardware design security vulnerability qualitative analysis method and system, according to a mixed attribute label propagation logic element library and a mixed attribute model construction method based on discrete mapping, so that a corresponding mixed attribute model can be constructed for any HDL design in linear time; the label designed by the mixed attribute model integrates two types of attributes, so that the safety behavior related to the safety attribute and the clock attribute can be modeled simultaneously; the method provided by the application can realize effective discrimination of hardware Trojan horses and hardware time measurement channels by verifying the clock attribute and the safety attribute; the application is deployed in the design and verification stage of the EDA process, so that the HDL design security vulnerability can be detected early, and the design basis is provided for high-reliability hardware design.

Description

Technical Field

[0001] This invention pertains to hardware security vulnerability analysis methods in the field of hardware design security, specifically relating to a qualitative analysis method and system for hardware design security vulnerabilities. Background Technology

[0002] Hardware, as the root of trust in computer systems, has long been considered safe and reliable. However, the frequent hardware security problems in recent years indicate that there are a large number of security vulnerabilities in hardware. Once hardware security vulnerabilities are exploited by attackers, they can lead to the leakage of sensitive information, the tampering of key information, the loss of system functions, or even damage. In terms of type, hardware security vulnerabilities can be roughly divided into three categories: design defects, hardware Trojans, and hardware time-side channels. Among them, design defects can be effectively eliminated through high coverage verification during the design and verification stages, while the functional correctness verification involved in the EDA process is difficult to achieve the detection of hardware Trojans and hardware time-side channels. The reason is that: (1) Hardware Trojans often have the characteristics of strong concealment and long latency period. Its design often uses low-probability event triggering conditions, so it is often difficult to trigger hardware Trojan logic through limited test vectors in the existing EDA testing and verification process; (2) Hardware time side channels are different from traditional vulnerabilities. They are mostly caused by unbalanced execution paths (such as conditional branches, cache hits / misses, fast paths in arithmetic units with non-steady operation times) in the design or algorithm. They do not interfere with the normal function of the device, but only leak sensitive information in the operation through specific physical parameters (such as execution time, power consumption, etc.). Therefore, it is urgent to study security verification methods and technologies that can qualitatively analyze hardware time side channels and hardware Trojans.

[0003] Existing hardware Trojan detection methods mainly focus on several aspects, including destructive detection, suspicious circuit structure analysis, hardware Trojan logic testing based on activation sequence generation (ATPG), and hardware Trojan detection based on time-side channel analysis. Destructive detection detects hardware Trojans by comparing differences between the physical circuit and the design layout. This method has the advantage of high accuracy, but at the cost of irreversible damage to the chip. Suspicious circuit structure analysis utilizes the low trigger and low inversion characteristics of hardware Trojans to traverse and search for low-activity suspicious nodes in the circuit. However, this method is only suitable for detecting simple, small hardware Trojans. Hardware Trojan logic testing based on activation sequence generation mainly achieves detection by automatically generating test stimuli and observing the impact of the hardware Trojan on circuit values ​​at the output port. However, the hardware Trojan space can expand infinitely with the number of circuit nodes, making it impossible to generate key test vectors or calculate test coverage through enumeration. Therefore, the primary goal of this method is to optimize the test vector generation method under the maximum Trojan activation probability. Hardware Trojan detection based on time-side channel analysis detects hardware Trojans by measuring parameters such as delay, power consumption, and thermal radiation generated during circuit operation and comparing them with the golden model. However, the gold standard is often difficult to obtain.

[0004] Time-side channel (TSC) detection methods utilize statistical analysis to examine the results of multiple samplings, thereby obtaining the correlation between the execution time of the hardware design and sensitive information within the design. This allows for the recovery of leaked sensitive information and ultimately, qualitative detection of hardware-related TSCs. The essence of sampling-based statistical analysis is to directly launch a TSC attack on the design. Therefore, to achieve effective detection, a sufficient number of test results must be generated while ensuring that the given input test vector effectively covers the TSCs. However, this method often struggles to guarantee effective detection of highly concealed TSCs that occur only under extremely low-probability input conditions or are protected by sophisticated mechanisms. Summary of the Invention

[0005] The purpose of this invention is to provide a qualitative analysis method and system for hardware design security vulnerabilities, so as to overcome the problem of low accuracy in detecting hardware design security vulnerabilities in existing methods.

[0006] A qualitative analysis method for hardware design security vulnerabilities includes the following steps:

[0007] S1, synthesize the HDL design under test to generate a standard gate-level netlist;

[0008] S2, a library of logic components for hybrid attribute tag propagation is constructed based on hybrid attributes, hybrid attribute tags, and hybrid attribute tag propagation strategies;

[0009] S3. Map the components in the generated standard gate-level netlist to the hybrid attribute label propagation logic element library to obtain the hybrid attribute model of the HDL design under test.

[0010] S4. By verifying the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained.

[0011] Preferably, a synthesis tool is used to synthesize the HDL design into a standard gate-level netlist.

[0012] Preferably, the hybrid attribute tag propagation logic element library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy.

[0013] Preferably, the hybrid attributes include security attributes and clock attributes, both of which are represented in binary numbers.

[0014] Preferably, the hybrid attribute tag is a carrier of hybrid attributes, represented by an N-bit signal, used to mark and observe the flow of data; wherein, the highest N-1 bits are used to reflect the security attributes of the marked data, and the lowest N-2 bits are used to reflect the clock attributes of the marked data.

[0015] Preferably, the mixed attribute tag propagation logic element library implements mixed attribute tag propagation logic of AND gate, OR gate, NOT gate, and D flip-flop.

[0016] Preferably, the hybrid attribute model specifically includes:

[0017] First, assign corresponding hybrid attribute labels to all ports and signals in the standard gate-level netlist;

[0018] Discretize and map all instance logic gates in the standard gate-level netlist to the hybrid attribute tag propagation logic library to generate hybrid attribute tag propagation logic;

[0019] By writing ports and signals, mixed attribute labels of ports and signals, instance logic gates, and mixed attribute label propagation logic of instance logic gates into the HDL module, a mixed attribute model can be generated.

[0020] Preferably, the generation of security attributes involves dividing the hybrid attribute model into security domains according to the security policy and assigning it security attributes with hybrid attribute labels.

[0021] Clock attribute generation: Initialize the input mixed attribute labels of the generated mixed attribute label propagation model, and at the same time, simulate the clock attribute of the output under test by providing a set of input test vectors.

[0022] A hardware design security vulnerability qualitative analysis system includes: a preprocessing module and an analysis module;

[0023] The preprocessing module synthesizes the HDL design under test into a standard gate-level netlist, and constructs a hybrid attribute label propagation logic component library based on hybrid attributes, hybrid attribute labels, and hybrid attribute label propagation strategies. By mapping the components in the generated standard gate-level netlist to the hybrid attribute label propagation logic component library, the hybrid attribute model of the HDL design under test can be obtained.

[0024] Analysis module: By verifying the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained.

[0025] Preferably, the hybrid attribute tag propagation logic element library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy.

[0026] Compared with the prior art, the present invention has the following beneficial technical effects:

[0027] This invention provides a qualitative analysis method for hardware design security vulnerabilities. Based on a hybrid attribute tag propagation logic element library and a hybrid attribute model construction method based on discrete mapping, it enables the construction of a corresponding hybrid attribute model for any HDL design in linear time. The tags designed in the hybrid attribute model integrate two types of attributes, allowing simultaneous modeling of security behaviors related to both security and clock attributes. The method provided by this invention can effectively identify hardware Trojans and hardware time-based channels by verifying clock and security attributes. This invention is deployed in the design and verification phases of the EDA process, thus enabling early detection of HDL design security vulnerabilities and providing a design basis for high-reliability hardware design.

[0028] The model and model component library constructed in this invention are described using HDL language, thus avoiding the additional design overhead introduced by using other languages ​​for modeling, and can be effectively integrated with existing EDA tools and formal verification tools; the model constructed in this invention can effectively extract security attributes and clock attributes. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the analysis method flow in an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram of mixed attribute tags in an embodiment of the present invention.

[0031] Figure 3 This is a schematic diagram of the construction method based on discrete mapping in an embodiment of the present invention.

[0032] Figure 4This is a flowchart of the hardware time-side channel qualitative positioning analysis method based on hybrid attribute tag attribute verification in an embodiment of the present invention. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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 should fall within the scope of protection of the present invention.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] like Figure 1 As shown, this invention provides a qualitative analysis method for hardware design security vulnerabilities. This invention can model the security behavior of HDL designs using hybrid attribute labels and label propagation strategies, and detect hardware security vulnerabilities that lead to security policy violations through formal verification of hybrid attribute assertions, with accurate detection results. Specifically, it includes the following steps:

[0036] S1, synthesize the HDL design under test to generate a standard gate-level netlist;

[0037] S2, a library of logic components for hybrid attribute tag propagation is constructed based on hybrid attributes, hybrid attribute tags, and hybrid attribute tag propagation strategies;

[0038] S3. Map the components in the generated standard gate-level netlist to the hybrid attribute label propagation logic element library to obtain the hybrid attribute model of the HDL design under test.

[0039] S4. By verifying the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained.

[0040] Specifically, the HDL design under test is synthesized to generate a standard gate-level netlist: a synthesis tool (such as Synopsys Design Compiler) is used to synthesize the HDL (Hardware Description Language) design into a standard gate-level netlist. The synthesized standard gate-level netlist consists of GTECH general library components and does not contain any process information. Modules, signals, and logic gates are typically defined and instantiated using keywords such as module, input, output, wire, AN2, IV, OR2, and **FFGEN**.

[0041] The hybrid attribute tag propagation logic element library described in this application is a minimal, fully functional logic unit element library; the hybrid attribute tag propagation logic element library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy.

[0042] The hybrid attributes include security attributes and clock attributes, both represented by binary numbers. Security attributes reflect the security level of the data, with a single logical "0" representing a trusted and confidential security level, and a single logical "1" representing an untrusted and unconfidential security level. Clock attributes reflect the data's update clock cycle and are represented by multi-bit binary numbers.

[0043] Hybrid attribute tags are carriers of hybrid attributes, represented by an N-bit signal, used to mark and observe data flow. The highest N-1 bits reflect the security attributes of the marked data, and the lowest N-2 bits reflect the clock attributes. For example... Figure 2 The diagram shows a 7-bit mixed attribute tag. The lower 5 bits reflect the clock attribute of the tag data, while the highest bit reflects the security attribute of the tag data.

[0044] Hybrid attribute tag propagation strategy: The two attributes carried by a hybrid attribute tag are not only tightly coupled in representation, but also follow the same strategy in attribute calculation rules, namely, considering whether the input data affects the output. This strategy stipulates that: the confidential or untrusted attribute of the input will propagate to the output if and only if confidential or untrusted input data changes the output, resulting in the output being confidential or untrusted; the clock attribute of the input will propagate to the output if and only if the update of the input determines the update of the output. The clock attribute is calculated on a periodic basis.

[0045] The Mixed Attribute Tag Propagation Logic Element Library implements mixed attribute tag propagation logic using AND gates, OR gates, NOT gates, and D flip-flops.

[0046] AND-2 mixed attribute tag propagation logic:

[0047] The logical function of AND-2 is AND:{A,B}→O, where A, B, and O represent the input and output of AND-2, respectively; a mixed attribute label A is assigned to A, B, and O respectively. m B m and O m To reflect the mixed attributes of input and output data, an AND-2 mixed attribute label propagation logic function (O, O) can be obtained. m ) = MF AND-2 (A,B,A m B m The logical truth table of the function is constructed as shown in Table 1. The bit width of the mixed attribute tag is uniformly defined as 5 bits, with the highest bit A... m [4] indicates a security attribute, with the lower four bits A. m [3:0] indicates the clock property. When both inputs of an AND gate are updated in the same clock cycle, the update of the output will be consistent with the update of the inputs.

[0048] Table 1: Truth Table for Mixed Attribute Tag Propagation Logic in AND-2

[0049]

[0050] Consider the first row of the truth table (A=0, B=0, A m [4] = 0, A m [3:0] = x, B m [4] = 0, B m [3:0] = y). Here, inputs A and B are both marked as trusted / unconfidential and updated in clock cycles x and y, respectively. If x < y, then input A is updated earlier than input B. According to the logic rules of a two-input AND gate, when input A is updated to 0 in clock cycle x, output O is immediately updated to 0 without considering the influence of input B, only affected by the update of input A. Therefore, the clock attribute of output O is consistent with the clock attribute of output A, i.e., O... m [3:0] = A m [3:0] = x. Since inputs A and B are both trustworthy / non-secret, output O must also be trustworthy / non-secret, i.e., O m [4] = A m [4] = 0. Therefore, when A = 0, B = 0, A m [4] = B m [4] = 0, A m [3:0]<B m In the case of [3:0], the clock attribute label of input A will be passed to output O, i.e., O m={0, x}. Conversely, when A=0, B=0, A m [4] = B m [4] = 0, A m [3:0] = x > B m In the case of [3:0] = .y, the mixed attribute label of input B will be passed to output O, i.e., O m = {0, y}. Considering both cases, when both inputs A and B are trusted / unconfidential, and are updated to 0 in different clock cycles, the output mixed attribute label always matches the mixed attribute label of the first updated input, i.e., O. m = {0, min(x, y)}.

[0051] Consider the second row of the truth table (A=0, B=0, A m [4] = 0, A m [3:0] = x, B m [4] = 1, B m [3:0] = y). Since both input A and input B are 0, O m [3:0] always maintains consistency with the clock property of the first updated input, i.e., O m [3:0] = min(x,y). Furthermore, although input B is untrusted / confidential, since input A is 0, changes in input B will not affect the output. Therefore, output O is trusted / unconfidential. If trusted / unconfidential input A and untrusted / confidential input B are periodically updated to 0 at x and y respectively, the mixed attribute label of the output should be O. m ={0,min(x,y)}. When A=0,B=0,A m [4]=1,A m [3:0]=x,B m [4]=0,B m When [3:0] = y, the output mixed attribute tag should also be O. m ={0,min(x,y)}.

[0052] Consider the fifth row of the truth table (A=0, B=1, A m [4]=0,A m [3:0]=x,B m [4]=0,B m [3:0] = y). Inputs A and B are both marked as trusted / unconfidential and updated during clock cycles x and y, respectively. According to the logic rules of a two-input AND gate, the output is always sensitive to low-level inputs. Therefore, when inputs A and B are 0 and 1 respectively, the clock attribute of the output always remains consistent with the clock attribute of input A, i.e., 0. m [3:0] = A m[3:0] = x. Furthermore, since both inputs are trusted / non-secret, the output O must also be trusted / non-secret, i.e., O m [4] = B m [4] = A m [4] = 0. Taking into account both clock and security attributes, the mixed attribute label of input A will be passed to output O, i.e., O m ={0,x}.

[0053] Consider the sixth row of the truth table (A=0, B=1, A m [4]=0,A m [3:0]=x,B m [4]=1,B m [3:0] = y). Here, input B is marked as untrusted / confidential. Since input A is 0, O m [3:0] always maintains consistency with the clock properties of input A, i.e., O m [3:0] = x. Furthermore, although input B is untrusted / confidential, since input A is 0, changes in input B will not affect the output. Therefore, output O is trusted / unconfidential, i.e., O m [4] = B m [4] = 0. In summary, if the trusted / unconfidential input A and the untrusted / confidential input B are updated to 0 and 1 respectively in the x and y cycles, the output mixed attribute label should be O. m ={0,x}.

[0054] Consider the seventh row of the truth table (A=0, B=1, A m [4]=1,A m [3:0]=x,B m [4]=0,B m [3:0] = y). Input A is marked as untrusted / confidential. Since the clock attribute of the output always matches the clock attribute of input A when inputs A and B are 0 and 1 respectively, i.e., 0... m [3:0] = A m [3:0] = x. Furthermore, since input A is untrusted / secret, and changes in input A cause changes in output O, output O is also untrusted / secret, i.e., O m [4] = B m [4] = 1. In summary, if the untrusted / confidential input A and the trusted / unconfidential input B are updated to 0 and 1 respectively in the x and y cycles, the output mixed attribute label should be O. m ={1,x}.

[0055] Consider the thirteenth row of the truth table (A=1, B=1, A m [4]=0,Am [3:0] = x, B m [4] = 0, B m [3:0] = y), where both inputs are trustworthy / non - confidential. If x < y, then input A is updated before input B. When input A is updated to 1 at time x, the value of output O must depend on the value of input B. Thus, input B determines the update time of output O, so the clock property of output O will be consistent with that of input B, i.e., O m [3:0] = B m [3:0] = y. Additionally, since both input A and input B are trustworthy / non - confidential, then output O must be trustworthy / non - confidential, i.e., O m [4] = A m [4] = 0. So, when A = 1, B = 1, A m [4] = B m [4] = 0, A m [3:0] = x < B m [3:0] = y, the hybrid - attribute label of input B will be passed to output O, i.e., O m = {0, y}. On the contrary, when A = 1, B = 1, A m [4] = B m [4] = 0, A m [3:0] = x > B m [3:0] = y, the hybrid - attribute label of input A will be passed to output O, i.e., O m = {0, x}. Considering both cases above, if trustworthy / non - confidential inputs A and B are updated to 1 at x and y cycles respectively, the hybrid - attribute label of the output is always consistent with that of the last - updated input, i.e., O m = {0, max(x, y)}.

[0056] Consider the fourteenth row of the truth table (A = 1, B = 1, A m [4] = 0, A m [3:0] = x, B m [4] = 1, B m [3:0] = y). Among them, input B is marked as untrustworthy / confidential. Since both input A and input B are 1, so O m [3:0] is always consistent with the clock property of the last - updated input, i.e., O m [3:0] = max(x, y). Additionally, since input B is untrustworthy / confidential and the change of input B will cause the change of output O, thus input O is untrustworthy / confidential, i.e., O m [4] = B m[4] = 1. Considering the above, if the trusted / unconfidential input A and the untrusted / confidential input B are updated to 1 in the x and y cycles respectively, the output mixed attribute label should be 0. m ={1, max(x, y)}. Similarly, when A = 1, B = 1, A m [4]=1,A m [3:0]=x,B m [4]=0,B m [3:0] = y, or A = 1, B = 1, A m [4]=1,A m [3:0]=x,B m [4]=1,B m When [3:0] = y, the output mixed attribute tag should also be O. m ={1,max(x,y)}.

[0057] Construct the truth table of AND-2 mixed attribute label propagation logic, as shown in Table 1, which contains all combinations of input states. By analyzing this table, the mixed attribute label propagation logic function (O, O) of AND-2 can be further derived. m ) = MF AND-2 (A,B,A m B m The logical expression for ) is shown in Formula 1. Here, the symbols “·”, “+”, “()”, “{}”, and “[]” are the “bitwise AND”, “bitwise OR”, “bitwise concatenation”, “bitwise repeat extension”, and “bitwise selection” operators, respectively. By describing this formula using HDL language, the mixed attribute label propagation logic for the mixed attribute model component library instance AND-2 can be obtained.

[0058]

[0059] IV's mixed attribute tag propagation logic:

[0060] The logical function of IV is IV:{I}→O, where I and O represent the input and output of IV, respectively. A mixed attribute label I is assigned to I and O respectively. m and O m To reflect their mixed attributes, a mixed attribute label propagation logic function (O,O) for an IV can be obtained. m ) = MF IV (I,I m ).

[0061] Table 2: Truth Table of Mixed Attribute Label Propagation Logic for IV

[0062]

[0063] According to the logic rules of IV, the output logic is inverted and updated synchronously with the input. Therefore, the clock attribute in the mixed attribute label of the output should be consistent with the clock attribute of the input, i.e., O m [3:0]=I m [3:0]. Furthermore, since the security attribute of the output is only affected by the security attribute of the input, the security attribute of the output is consistent with the security attribute of the input. That is, when the input is untrusted / confidential, the output must be untrusted / confidential; similarly, when the input is trusted / non-confidential, the output must be trusted / non-confidential. Thus, the truth table of the mixed attribute label propagation logic for IV shown in Table 2 and the logical expression shown in Formula 2 can be derived.

[0064]

[0065] OR-2 mixed attribute tag propagation logic:

[0066] The logical function of OR-2 is OR:{A,B}→O, where A, B, and O represent the input and output of OR-2, respectively. Assign a mixed attribute label A to A, B, and O respectively. m B m and O m To reflect their mixed attributes (security and clock attributes), a mixed attribute label propagation logic function of OR-2 (O,O) can be obtained. m ) = MF OR-2 (A,B,A m B m According to De Morgan's law, given the same input and labels, the mixed attribute label propagation logic of OR-2 is completely opposite to that of AND-2. Similarly, the mixed attribute label propagation logic of OR-2 is constructed as shown in Formula 3.

[0067]

[0068] D-trigger mixed attribute label propagation logic:

[0069] The logic function of a D flip-flop is DFF:{D}→Q, where D and Q represent the input and output of the D flip-flop, respectively. Assign a mixed attribute label D to both D and Q. m and Q m To reflect their mixed attributes, a mixed attribute label propagation logic function (Q,Q) of an IV can be obtained. m ) = MF IV (D,D m ).

[0070] Table 3: Truth Table of Mixed Attribute Label Propagation Logic for D Flip-Flops

[0071]

[0072] Because the output of the D flip-flop always lags behind the input by one cycle, the clock attribute value of the output mixed attribute label will increment by one cycle based on the clock attribute value of the output mixed attribute label, i.e., Q. m [3:0]=D m [3:0]+1. Furthermore, since the security attribute of the output is only affected by the security attribute of the input, the security attribute of the output is consistent with the security attribute of the input. That is, when the input is untrusted / confidential, the output must be untrusted / confidential; similarly, when the input is trusted / non-confidential, the output must be trusted / non-confidential. Following these rules, we can derive not only the truth table of the mixed attribute label propagation logic for a D flip-flop shown in Table 3, but also the logical expression shown in Formula 4.

[0073]

[0074] The hybrid attribute tag propagation logic of basic logic gates is constructed to form a minimal, fully functional hybrid attribute tag propagation logic library. The features of this library are: (1) all library components are implemented in HDL language and can be integrated with standard EDA tools; (2) complex hybrid attribute tag propagation logic is extended based on the library components contained in this library.

[0075] like Figure 3 As shown, a hybrid attribute model of HDL design is constructed based on the discrete mapping method. Specifically, the hybrid attribute model of the HDL design under test can be obtained by mapping the components in the standard gate-level netlist to the hybrid attribute tag propagation logic element library.

[0076] Taking a 1-bit two-input selector (MUX-2) as an example, this section details the modeling of a hybrid attribute model: The standard gate-level netlist of MUX-2 includes port declarations, logic signal declarations, logic gate instances, and assignments. The specific modeling process is as follows:

[0077] (1) First, assign corresponding mixed attribute labels to all ports and signals in the standard gate-level netlist.

[0078] (2) Discretly map all instance logic gates in the standard gate-level netlist to the hybrid attribute label propagation logic library to generate hybrid attribute label propagation logic;

[0079] (3) By writing the port and signal, the mixed attribute label of the port and signal, the instance logic gate, and the mixed attribute label propagation logic of the instance logic gate into the HDL module, the mixed attribute model of MUX-2 can be generated.

[0080] By validating the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained, which is the hybrid attribute assertion process:

[0081] To achieve the downward mapping of high-level security requirements and generate assertions related to security and clock attributes, the generation of mixed attribute assertions requires the following three steps:

[0082] (1) Generation of security attributes: According to the security policy, the hybrid attribute model is divided into security domains and assigned security attributes with hybrid attribute labels; usually, confidential / untrusted security attributes need to be assigned to data in confidential / untrusted domains, while non-confidential / trusted attributes need to be assigned to data in non-confidential / trusted domains.

[0083] (2) Clock Attribute Generation: The generation of the hardware time measurement channel stems from the unpredictable hardware execution time caused by the unbalanced branch structure. That is, changes in the input lead to differences in the hardware execution time, allowing for the inference of the correlation between confidential data and execution time through multiple sampling and statistical analysis. Therefore, the key to clock attribute generation is determining the hardware execution time under an arbitrary set of inputs. To this end, it is necessary to initialize the input mixed attribute labels of the generated mixed attribute label propagation model, and simultaneously provide a set of input test vectors to simulate and test the clock attributes of the output under test.

[0084] (3) The security and clock attributes to be verified are described using SystemVerilog language, and mixed attribute assertions in SVA format are generated.

[0085] For example: Suppose a hybrid attribute tag propagation model for an encryption system is Cipher-System:{Plaintext,Key,clk,Key} m Plaintext m}→{O,O m ready, ready m}, where Plaintext and Key are the input plaintext and key, O is the ciphertext output, ready is the indicator signal, and A m B m O m and ready m These are their combined attribute tags. When encryption is complete, "ready" is set to high to indicate that encryption is finished.

[0086] In this hybrid attribute label propagation model, Key represents critical and sensitive data that needs protection and should not flow to non-security-sensitive areas, i.e., it should not flow to the ready indicator signal. Therefore, the security attributes of the hybrid attribute labels for Key and ready should be set to 1 and 0 respectively, while the time attributes of all hybrid attribute labels should be initialized to 0 for simulation testing.

[0087] Suppose that the simulation results show that the clock property of the output to be tested (ready) is T, then the assertion to be proved can be described as follows:

[0088] property Cipher-System-ready-Sidechannel:

[0089] @(posedge clk)

[0090] $rose(ready)|=>ready m [3:0] = T;

[0091] endproperty

[0092] property Cipher-System-ready:

[0093] @(posedge clk)

[0094] $rose(ready)|=>ready m [4]==1'b0;

[0095] endproperty

[0096] Among them, the assertion Cipher-System-ready and the assertion Cipher-System-ready-Sidechannel are used to describe, respectively, that security-critical keys have not flowed to unsecured areas and that security-critical keys have not been leaked from time-series channels.

[0097] If the assertion property model is provable, then the design is necessarily secure, and there are no time-side channels or hardware Trojans that could leak sensitive information. Conversely, if it is not provable, a counterexample will be provided that contradicts the assertion. This counterexample can serve as evidence to distinguish between hardware Trojans and hardware time-side channels. If the verification of only the clock property is not satisfied, it indicates that there is a hardware time-side channel in the design that could leak security-critical information; if the verification of only the security property is not satisfied, it indicates that there is a hardware Trojan in the design that could leak security-critical information.

[0098] Example

[0099] The hardware environment implemented is as follows: Intel i7-6700 CPU, @3.4G (2 processors) computer, 32.0GB memory; the software environment is: Windows 10 32-bit operating system, logic synthesis tool Synopsys Design Compiler (DC), formal verification tool Mentor Graphics QuestaFormal, logic simulation tool Mentor Graphics Modelsim.

[0100] This invention uses the RSA hardware encryption algorithm core benchmark BasicRSA.v as a test example. This core includes a hardware time-side channel that can implicitly output the key to a security-critical port. The specific reason is that modular exponentiation involves an unbalanced conditional branch, and the number of iterations in modular multiplication is related to the multiplier.

[0101] like Figure 4 As shown in (a), modular exponentiation is controlled by a key bit, which is shifted sequentially from right to left. If the current key bit is 1, RSA performs modular multiplication; otherwise, if the current key bit is 0, RSA performs only simple assignment. Since the number of cycles consumed by modular multiplication is much greater than that consumed by simple assignment, attackers can deduce the key bit by observing the execution time.

[0102] like Figure 4 As shown in (b), the number of iterations of the modular multiplication operation is determined by the position of the highest non-zero bit of the multiplier, so an attacker can infer the multiplier by observing the iteration time of each round.

[0103] The specific implementation is as follows:

[0104] 1: Logic synthesis of the original circuit design:

[0105] The logic synthesis tool was used to synthesize BasicRSA.v into a standard gate-level netlist, BasicRSA_netlist.v.

[0106] 2: Generation of a component library for the hybrid attribute tag propagation model

[0107] Construct a minimal, fully functional component library for the hybrid attribute tag propagation model.

[0108] 3: Generation of the hybrid attribute tag propagation model

[0109] The gate-level netlist BasicRSA_netlist.v is used to construct a hybrid attribute model to be verified. The internal operation of the modeling tool is as follows: First, all signals passing through the generated gate-level netlist BasicRSA_netlist.v are assigned corresponding hybrid attribute labels; second, all logic gates in the gate-level netlist BasicRSA_netlist.v are mapped to the hybrid attribute label propagation logic library, thus obtaining the hybrid attribute model of BasicRSA.v.

[0110] 4: Generation of mixed attribute assertions

[0111] The core contains two ports: a ciphertext output and a flag output "ready". The timing of setting the "ready" flag is related to the key and could potentially be exploited by an attacker to recover the key. Therefore, only targeted verification of the mixed attribute labels of "ready" is needed to determine whether there is a hardware time-side channel or hardware Trojan in the design that could leak the key. Based on the clearly defined analysis objectives, we first assume that the BasicRSA.v design does not contain any hardware side-channel or hardware Trojan that could leak the key to "ready"; secondly, we initialize all input mixed attribute labels to 13'b0; finally, we simulate and test the mixed attribute labels of "ready" with a set of arbitrary inputs. m Test results show that ready m The value of [11:0] is 12'b0011 01101011. This result can be used to define two assertion properties: RSA-ready. m [11:0] and property RSA-ready m

[12] , used to verify clock attributes and security attributes respectively:

[0112] property RSA-ready m -for11:

[0113] @(posedge clock)disable iff(reset)

[0114] $rose(ready)|->ready m [11:0]==12'b11 0110 1011;

[0115] Endproperty

[0116] property RSA-ready m -for12:

[0117] @(posedge clock)disable iff(reset)

[0118] $rose(ready)|->ready m

[12] ==1'b1;

[0119] Endproperty

[0120] The verification process is the process of qualitatively and locally analyzing the leakage time side channel. To verify the two assertions defined in step 4, the preconditions required for verification need to be defined. In the BasicRSA.v design, the key is security critical and affects the setting of the ready signal. Therefore, we define the precondition key

[12] = 1'b1. Since the propagation of the security attributes of the key is independent of the value of the key, any set of keys can be given as input, which can reduce the state space required for search to a certain extent.

[0121] The verification process is fully automated, requiring no human intervention. It only requires inputting the preconditions, the hybrid attribute label propagation model from BasicRSA.v, the hybrid attribute label propagation model library, and the assertions to be proven into the formal verification tool Mentor Graphics QuestaFormal. The system then searches for counterexamples of the assertions by traversing the input. If both assertions are unprovable, it indicates that at least one hardware time-side channel leaks the key assertion to the ready state in the design. Whether a hardware trojan exists in the design can be determined by searching for low-inversion-probability signals through design feedback. If the assertion is RSA-ready... m -For11 is not provable, but asserting RSA-ready is not. m If -for12 can prove it, then it means that there is a hardware time-based channel in the design; if it asserts RSA-ready m -for11 can prove, and assert RSA-ready m If the -for12 assertion is unprovable, it indicates the presence of a hardware Trojan in the design; if both assertions are provable, then the design is necessarily secure. The verification results show that both assertions are unprovable, consistent with the previous analysis of BasicRSA.v, proving the effectiveness of this patent in qualitatively detecting hardware security vulnerabilities.

[0122] This invention provides a hybrid attribute tag propagation logic component library and a hybrid attribute model construction method based on discrete mapping, enabling the construction of corresponding hybrid attribute models for any HDL design in linear time. The tags designed in the hybrid attribute model integrate two types of attributes, allowing simultaneous modeling of security behaviors related to security and clock attributes. The model and model component library constructed in this invention are described using HDL language, thus avoiding the additional design overhead introduced by using other languages ​​for modeling, and can be effectively integrated with existing EDA tools and formal verification tools. The model constructed in this invention can effectively extract security and clock attributes. The method provided in this invention can effectively identify hardware Trojans and hardware time measurement channels by verifying clock and security attributes. This invention is deployed in the design and verification stages of the EDA process, thus enabling early detection of security vulnerabilities in HDL designs and providing a design basis for high-reliability hardware design.

Claims

1. A qualitative analysis method for hardware design security vulnerabilities, characterized in that, Includes the following steps: S1, synthesize the HDL design under test to generate a standard gate-level netlist; S2, a library of logic components for hybrid attribute tag propagation is constructed based on hybrid attributes, hybrid attribute tags, and hybrid attribute tag propagation strategies; The Hybrid Attribute Tag Propagation Logic Element Library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy. The hybrid attribute tag is the carrier of hybrid attributes and is represented by an N-bit signal to mark and observe the flow of data. Among them, the highest N-1 bits are used to reflect the security attributes of the marked data, and the lower N-2 bits are used to reflect the clock attributes of the marked data. S3. Map the components in the generated standard gate-level netlist to the hybrid attribute label propagation logic element library to obtain the hybrid attribute model of the HDL design under test. S4. By verifying the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained.

2. The method for qualitative analysis of hardware design security vulnerabilities according to claim 1, characterized in that, The HDL design gate level is synthesized into a standard gate level netlist using a synthesis tool.

3. The method for qualitative analysis of hardware design security vulnerabilities according to claim 1, characterized in that, Hybrid attributes include security attributes and clock attributes, both of which are represented in binary numbers.

4. The method for qualitative analysis of hardware design security vulnerabilities according to claim 1, characterized in that, The Mixed Attribute Tag Propagation Logic Element Library implements mixed attribute tag propagation logic using AND gates, OR gates, NOT gates, and D flip-flops.

5. The method for qualitative analysis of hardware design security vulnerabilities according to claim 1, characterized in that, The hybrid attribute model specifically includes: First, assign corresponding hybrid attribute labels to all ports and signals in the standard gate-level netlist; Discretize and map all instance logic gates in the standard gate-level netlist to the hybrid attribute tag propagation logic library to generate hybrid attribute tag propagation logic; By writing ports and signals, mixed attribute labels of ports and signals, instance logic gates, and mixed attribute label propagation logic of instance logic gates into the HDL module, a mixed attribute model can be generated.

6. The method for qualitative analysis of hardware design security vulnerabilities according to claim 1, characterized in that, Security attribute generation: Based on the security policy, the hybrid attribute model is divided into security domains, and security attributes with hybrid attribute labels are assigned to it; Clock attribute generation: Initialize the input mixed attribute labels of the generated mixed attribute label propagation model, and at the same time, simulate the clock attribute of the output under test by providing a set of input test vectors.

7. A qualitative analysis system for hardware design security vulnerabilities, characterized in that, include: Preprocessing module and analysis module; The preprocessing module synthesizes the HDL design under test into a standard gate-level netlist, and constructs a hybrid attribute label propagation logic component library based on hybrid attributes, hybrid attribute labels, and hybrid attribute label propagation strategies. By mapping the components in the generated standard gate-level netlist to the hybrid attribute label propagation logic component library, the hybrid attribute model of the HDL design under test can be obtained. The Hybrid Attribute Tag Propagation Logic Element Library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy. The hybrid attribute tag is the carrier of hybrid attributes and is represented by an N-bit signal to mark and observe the flow of data. Among them, the highest N-1 bits are used to reflect the security attributes of the marked data, and the lower N-2 bits are used to reflect the clock attributes of the marked data. Analysis module: By verifying the hybrid attribute model using security and clock attributes, the security results of the HDL design under test can be obtained.

8. The hardware design security vulnerability qualitative analysis system according to claim 7, characterized in that, The Hybrid Attribute Tag Propagation Logic Component Library implements the hybrid attribute tag propagation logic of multiple basic logic units in HDL language based on the hybrid attribute tag propagation strategy.

Images