A gate-level netlist hardware Trojan test set generation method based on a large language model

Abstract

The application discloses a gate-level netlist hardware Trojan test set generation method based on a large language model, and relates to the field of hardware security. The method firstly uses a carefully designed prompt word to make the large language model provide a hardware Trojan design service; then the large language model generates final design code after continuously iterating and reflecting according to the provided knowledge base and restriction constraints; the design code is evaluated by an evaluator, and the Trojan can be mounted on the parent netlist; the triggering node is determined by analyzing the node concealment, and finally the netlist file after mounting the Trojan is generated.

Description

Technical Field

[0001] This invention relates to the field of hardware security, specifically to a method for generating a hardware Trojan test set based on a large language model and a gate-level netlist. Background Technology

[0002] Hardware Trojans (HT) are malicious modifications to chip designs, leading to functional changes, performance degradation, information leaks, and denial-of-service attacks. With the increasing performance and complexity of chips, and to meet time-to-market constraints, chip design now heavily utilizes third-party intellectual property cores (3PIPs). These 3PIPs are highly susceptible to hardware Trojan implantation, posing significant security risks. Detecting hardware Trojans in netlist-level design files is an effective means of defending against these security threats. However, current third-party netlist-level hardware Trojan test sets have not been updated for a long time, and their sample size and survivability are poor, failing to meet the needs of iterative updates in hardware Trojan detection technology. Therefore, researching methods for generating highly concealed, large-scale netlist-level hardware Trojan test samples can provide a more comprehensive and effective detection sample set for Trojan detection research, thereby promoting the iterative updates of hardware Trojan detection technology.

[0003] Current netlist-level hardware Trojan detection technologies mainly include COTD, graph neural networks, and reinforcement learning detection methods. In response to these detection methods, related research has proposed hardware Trojan sample generation techniques to circumvent them. For example, regarding COTD detection, the DeCOTD0 Trojan design method has emerged (Zhang J, Yuan F, Xu Q. DeTrust: Defeating Hardware Trust Verification with Stealthy Implicitly-Triggered Hardware Trojans[C]. 2014 ACM SIGSAC Conference on Computer and Communications Security, 2014: 153–166). By adding stealthy structures to the Trojan circuit, resistance to COTD detection is achieved. Regarding graph neural network detection methods, Gohil et al. developed AttackGNN (Gohil, V., Patnaik, S., Kalathil, D., & Rajendran, J. (2024). AttackGNN: Red-Teaming GNNs in Hardware Security Using ReinforcementLearning.arXiv preprint arXiv:2402.13946), which generates adversarial examples through reinforcement learning (RL) and uses the original circuit transformation in circuit synthesis tools to generate functionally equivalent perturbation circuits. In addition, Wang Zhiqiang et al. proposed a large-scale hardware Trojan library generation system and method based on generative adversarial networks. Through the generative adversarial network model, automated hardware Trojan design is performed. Beijing University of Electronic Science and Technology. A large-scale hardware Trojan library generation system and method based on generative adversarial networks: CN201911179828.7 [P]. 2020-03-31.Regarding resistance to reinforcement learning detection, Sarihi et al. proposed the TROJANFORGE technique, which works in conjunction with reinforcement learning-based hardware Trojan detectors to generate hardware Trojan instances that can evade reinforcement learning detection methods. (Sarihi, A., Jamieson, P., Patooghy, A., & Badawy, AA (2024). TrojanForge: Generating Adversarial Hardware Trojan Examples Using Reinforcement Learning. In Proceedings of the 2024 ACM / IEEE International Symposium on Machine Learning for CAD (pp. 1-7).) In terms of generating hardware Trojans using large language models, existing techniques generate Register Transfer Level (RTL) hardware Trojan samples. For example, Kokolakis et al. proposed an automated process for designing RTL-level hardware Trojans using a general-purpose large language model, demonstrating the potential of general-purpose large language models in hardware Trojan design. Kokolakis, G., Moschos, A., & Keromytis, AD (2024). Harnessing the Power of General-Purpose LLMs in Hardware Trojan Design. In *Applied Cryptography and Network Security Workshops: ACNS2024 Satellite Workshops* (pp. 176-194). Lecture Notes in Computer Science, vol. 14586. Cham: Springer. Bhandari et al. proposed the SENTAUR framework based on large language models to generate synthesizable hardware Trojan RTL code. Bhandari, J., Sadhukhan, R., Krishnamurthy, P., Khorrami, F., & Karri, R. (2024). SENTAUR: Security Enhanced Trojan Assessment Using LLMs Against Undesirable Revisions. arXiv preprint arXiv:2407.12352.Faruque et al. proposed the GHOST framework based on a large language model, which can implant Trojans into three RTL-level designs. (Faruque, MO, Jamieson, P., Patooghy, A., & Badawy, A.-HA (2024, December 3). Unleashing GHOST: An LLM-Powered Framework for Automated Hardware Trojan Design. arXiv:2412.02816 [v1][ComputerScience–Cryptography and Security]. Retrieved from https: / / doi.org / 10.48550 / arXiv.2412.02816.) However, existing gate-level netlist hardware Trojan test set generation technologies lack sufficient intelligence, offer limited detection methods, and generate only a small number of samples. Furthermore, RTL-level hardware Trojans generated based on large language models lose their Trojan tags after being synthesized into a gate-level netlist, failing to meet the iterative update needs of hardware Trojan detection technology. This invention generates a netlist-level hardware Trojan based on a large language model, which can effectively solve the above problems. Summary of the Invention

[0004] This invention proposes a gate-level netlist hardware Trojan test set generation method based on a large language model, which can effectively improve the concealment of the Trojan test set, increase the scale and variety of Trojan samples, and meet the iterative update needs of existing hardware Trojan generation technology.

[0005] The hardware Trojan test set generation method involved in this invention consists of five steps, such as... Figure 1 As shown. The input is a chip netlist-level design file; ① It provides hardware Trojan generation services through specific prompts; ② It provides a specific knowledge base for the large language model, allowing the large language model to learn the relevant knowledge of netlist-level hardware Trojan design and provide netlist-level hardware Trojan circuits; ③ It performs preliminary evaluation and iteration on the netlist-level hardware Trojans generated by the large language model; ④ It requires the large language model to reflect on and review the generated code to improve the accuracy and stealth of the generated Trojans until the Trojans generated by the large model can pass the final evaluation; ⑤ It extracts the final designed hardware Trojan and attaches it to the netlist-level design file of the parent circuit.

[0006] The present invention proposes a method for generating a hardware Trojan test set based on a large language model and a gate-level netlist. The specific steps of this method are as follows:

[0007] Step 1: Ensure that the large language model can provide Trojan generation services;

[0008] Input the initial prompt word containing the request to generate a Trojan horse into the LLM, and obtain the initial output O, where LLM represents the Large Language Model; let p be the probability that the Large Language Model provides the service. se There is a formula:

[0009] p se (O≠Refuse|P)=f(P) (1)

[0010] f(P) represents the service probability under the initial prompt word state;

[0011] Four optimization elements were introduced into the initial prompts: role-playing (R), scenario interpretation (S), technical terminology (D), and domain background (B). The prompts after introducing these optimization elements are as follows:

[0012]

[0013] Among them, P opt The prompt word after introducing the optimization element, g(·) represents the function that combines the optimization element with the initial prompt word, and P represents the initial prompt word. This indicates the process of merging the four optimization elements with the initial prompt;

[0014] at this time:

[0015] p se (O≠Refuse|P opt )=f(P opt )=f(g(P,R,S,D,B)) (3)

[0016] Where, p se (O≠Refuse|P opt The expression represents the probability that the output will not be "Refuse" given the optimized prompt word. "O" represents the response provided by the LLM, and "Refuse" indicates that the LLM's response is "Refuse to provide hardware Trojan generation service." "O ≠ Refuse | P" opt This indicates that the output is not Refuse given the optimized prompt word. f(·) represents a specific function used to calculate the probability that the LLM-provided answer O is not Refuse given the optimized prompt word.

[0017] Introduce the tuning parameter set θ:

[0018] θ = {θ1, θ2, ..., θ n} (4)

[0019] Randomly select k parameters from the optimization parameter set and compare them with P. opt The optimized suggestion word is constructed; the optimized suggestion word P final The probability of generating the service is pse (O≠Refuse|P final ):

[0020] p se (O≠Refuse|P final )=f(P final (5)

[0021] f(P final )=f(g(P,R,S,D,B,θ i1 ,θ i2 ,...,θ ik i1,i2,...,i k ∈{1,2,...,n} (6)

[0022] After introducing tuning parameters, maximize p se (O≠Refuse|P final The optimization objective is to solve...

[0023]

[0024] accomplish

[0025] p se (O≠Refuse|P final )=1 (8)

[0026] Step 2: Introduce three knowledge bases for the large language model, namely:

[0027] Knowledge Base K1: List of available gate devices and specific functions of rare gate devices;

[0028] Knowledge Base K2: Provides the RTL source code for the parent circuits mounted on the large language model;

[0029] Knowledge Base K3: Example of Hardware Trojan Load Generation;

[0030] Step 3: Evaluate the effectiveness of the Trojan code generated by the iterative large language model and update it accordingly;

[0031] The code generated by the large language model was evaluated through manual analysis and Testbench simulation. gen The effectiveness;

[0032] Step 4: The large language model reflects on and reviews the generated code;

[0033] Step 5: Extract C based on signal node concealment analysis final To install a Trojan horse.

[0034] Furthermore, the specific method for step 2 is as follows:

[0035] Provide the knowledge base to the large language model so that the large language model can learn about hardware Trojan mounting:

[0036]

[0037] L is the learning function for a large language model. learn This represents what the large language model learns from the prior knowledge base;

[0038] The final design code for the large language model is as follows:

[0039] C gen =G(L learn ,P design ,θ GPT (10)

[0040] Where C gen This represents the generated initial Trojan design code, G is the generation function of the large language model, and P... design To provide prompts for Trojan horse design using a large language model, θ GPT These are the tuning parameters for the large language model itself.

[0041] Furthermore, the specific method for evaluating code effectiveness in step 3 is as follows:

[0042] By introducing evaluator E, C gen An evaluation will be conducted, and the evaluation process is as follows:

[0043]

[0044] Where P i P represents the condition for judging the code. i (C gen W represents the evaluation result of the i-th condition on the code. The function f converts the evaluation result into a numerical value. i This represents the weight of the i-th judgment condition. An evaluation threshold T is set. If...

[0045] E(C gen )≥T (12)

[0046] If the code passes the evaluation, it is considered valid; otherwise, it is invalid.

[0047] Furthermore, the update method in step 3 is as follows:

[0048] If the code generated by the large language model is evaluated as invalid, based on the type of Trojan horse designed, a corresponding requirement constraint library is selected from the requirement constraint library set Φ, and several constraints are then selected from the library as new design constraints, which are then fed back into the design process of the large language model; the constraint library set is as follows:

[0049] Φ={R0,R1,R2,R3} (13)

[0050] Where R i The four types of requirement constraint libraries are: R0 (functional change constraint library), R1 (performance degradation constraint library), R2 (information leakage constraint library), and R3 (denial of service constraint library).

[0051] Each requirement constraint library R i The constraints γ are all included. j , where γ j ∈R i j = 1, 2, ..., m, i = 0, 1, 2, 3; m is the total number of constraints, which are introduced into the original prompt word P. design Then, user feedback F is provided to the large language model, which includes the user's emotional stimulus feedback, quantitative rating, and behavioral guidance; R is selected. i The k constraints in the set are used as the input requirement constraint set R. input The updated design code C update for:

[0052] θ GPT ←Automatic updates based on user feedback (14)

[0053] R input ={γ j1 ,γ j2 ,...,γ jk},j1,j2,...,j k ∈{1,2,...,m} (15)

[0054] C update =G(L learn ,{P design ,R input},θ GPT (16)

[0055] Where ← represents the update symbol, γ jk This represents k constraints selected from a set of m constraints, where j is the number of constraints selected. k C is the index subscript of the selected constraint. update This indicates the updated design code.

[0056] Furthermore, the specific method for step 4 is as follows:

[0057] Let L be the reflection and censorship function of the large language model. re The input is a prompt word P that requires the large language model to reflect on and review the design content. re The output is the reflection review result (CO) of whether the large language model's design code meets the requirement constraints.

[0058] CO = L re (P re C update (17)

[0059] Right now

[0060]

[0061] The parameters represent the tuning parameters of the large language model itself. Keyword extraction is performed from CO to obtain the set S of reflection results on the requirements constraints, where:

[0062] S = {S1,S2,...,S} k}k∈{1,2,...,m} (19)

[0063] Each S k Corresponding to each of the provided requirement constraints γ k This indicates whether the generated code meets this requirement:

[0064]

[0065] Indicates the corresponding symbol; if for This means that the generated code meets all the requirements and constraints. It means that for any s k The code is fed into the evaluation function for evaluation. If the generated code only meets some requirements, then the unmet requirement constraint set R' is used as the basis for further evaluation. input Feedback optimization is performed; the set of unmet requirements constraints is as follows:

[0066] R' input ={γ k |S k =0,i=1,2,...,n}, n≤k (22)

[0067] R' input Feedback is sent to the generation function G to regenerate the hardware Trojan code, and then the next iteration begins.

[0068]

[0069]

[0070] This process is repeated iteratively until:

[0071]

[0072] Re-evaluate the code generated by the large language model to determine if it is valid design code; if the redesigned code still fails the evaluation, return to step 3 and repeat the above iterative steps until the final design code C is obtained. final satisfy:

[0073] E(C final ) = 1 (26).

[0074] Furthermore, the specific method for step 5 is as follows:

[0075] Given a directed graph G = (V, E) of a circuit, where: V represents the set of nodes, i.e., the input, output, and internal signal nodes of the circuit; E represents the set of edges, i.e., the logic gates of the circuit; and D(v) represents the distance from node v to the input node, where v is an input signal node.

[0076] D(v)=0 (27)

[0077] If v is a non-input signal node, then

[0078]

[0079] Where pred(v) is the set of all predecessor nodes pointing to node v, depth represents the depth of the node in the circuit, static analysis is performed on all nodes in the circuit to obtain the distance set D, and u represents a single node in the set of all predecessor nodes pointing to node v.

[0080] D = {D(v)|v∈V} (29)

[0081] Define N input (v) is the set of all input nodes that node v can reach by traversing forward, G DFF (v) is the set of all D triggers that can be reached by traversing forward from node v; the in-degree ID of the node is:

[0082] ID(v) = |N input (v)|+|G DFF (v)| (30)

[0083] |·| represents the calculation of absolute value, defining the following parameters: the number of input excitations generated (its), the simulation sampling interval Δt, the duration of the input excitation (T), the number of input signals to the parent circuit (ins), and the clock cycle t of the simulation file Testbench. clk The number of times the input stimulus is generated satisfies:

[0084] its=2 ins (31)

[0085] During the simulation, the sampling interval satisfies:

[0086] 5t clk ≥Δt≥t clk (32)

[0087] The duration of the input excitation should be proportional to the maximum distance of the parent circuit, i.e.

[0088] T∝D max (33)

[0089] D max =max{D(v)|v∈V} (34)

[0090] Where ∝ represents a direct proportional relationship, D max This represents the maximum distance from node v to the input node; after setting the simulation parameters, analyze and obtain the clock signal CLK, enable signal RST, and reset signal ENA of the parent circuit, and automatically obtain the input signal IN_N and the set N of all signal nodes, where:

[0091] N = {v1, v2, ..., v} i |v i ∈V, i=1,2,...,n} (35)

[0092]

[0093] Next, the simulation file Testbench is automatically generated. During simulation, the flip rate FR and duty cycle DC are recorded for each internal signal, and together with the distance D and in-degree ID, they are used as node features; the node concealment is scored.

[0094] NS=W FR ·FR+W DC DC+W D ·D+W ID ·ID (37)

[0095] Among them W FR W DC W D With W ID These represent the weights of the four features, and NS is the node concealment score.

[0096] For node N in the netlist file, each node v i It has a concealment score ns iSelect the k nodes with the highest scores to mount the Trojan, where k is the number of trigger nodes in the hardware Trojan generated by the large language model; select the Trojan trigger nodes:

[0097] TN = {v1, v2, ..., v n} (38)

[0098] in

[0099] ns1≥ns2≥...≥ns n (39)

[0100] Based on the payload type of the hardware Trojan generated by the large language model, different node replacement methods are selected from the attack node replacement strategy set S, where:

[0101] S={S cf ,S dp ,S lf ,S dos} (40)

[0102] S cf S is a node replacement method for functionally altering Trojans. dp S is a node replacement method for performance-degrading Trojans. lf S is a node replacement method for information leakage Trojans. dos A method to prevent service-oriented Trojans from replacing nodes.

[0103] This invention proposes a method for generating a highly covert, large-scale chip netlist-level hardware Trojan test set based on a large language model. The method first uses carefully designed prompts to allow the large language model to provide hardware Trojan design services. Then, the large language model iterates and reflects based on the provided knowledge base and constraints to generate the final design code. After the design code is evaluated by an evaluator, the Trojan can be mounted on the parent netlist. By analyzing the concealment of nodes, trigger nodes are determined, and finally, the netlist file with the Trojan mounted is generated. Attached Figure Description

[0104] Figure 1 This is a flowchart of the hardware Trojan test set generation method of the present invention. Detailed Implementation

[0105] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0106] The present invention proposes a method for generating a high-coverage, large-scale chip netlist-level hardware Trojan test set based on a large language model, as follows: Figure 1 As shown.

[0107] Step 1: Ensure the large language model can provide Trojan generation services.

[0108] Based on prior knowledge obtained from randomized experiments and literature reviews, an initial prompt word (Prompt) P is designed, containing a request to generate a hardware Trojan. P is input into the LLM, and the initial output O is obtained. Due to the inherent security protection mechanism of the large language model, it will refuse to provide the hardware Trojan generation service. Let p be the probability that the large language model provides the service. se There is a formula:

[0109] p se (O≠Refuse|P)=f(P) (41)

[0110] f(P) represents the service probability under the initial prompt word state, which is usually 0.

[0111] Four optimization elements were introduced into the initial prompts: Role Playing (R), Scenario Simulation (S), Domain-Specific Words (D), and Background Information (B). The prompts after incorporating these optimization elements are as follows:

[0112]

[0113] at this time:

[0114] p se (O≠Refuse|P opt )=f(P opt )=f(g(P,R,S,D,B)) (43)

[0115] To further improve service probability, a set of tuning parameters is introduced:

[0116] θ = {θ1, θ2, ..., θ n} (44)

[0117] Where θ i This represents the tuning parameters, such as (only some judgment conditions are listed below, "..." indicates that they are omitted):

[0118] θ1: Controls the randomness or creativity of the generated content;

[0119] θ2: Controls the frequency of repeated words or phrases;

[0120] θ3: Controls the diversity of generated content.

[0121] ...

[0122] Randomly select k parameters from the optimization parameter set and compare them with P. optThis constitutes the optimized suggestion word. The optimized suggestion word P final The resulting service probability can be expressed as:

[0123] p se (O≠Refuse|P final )=f(P final (45)

[0124]

[0125] After introducing tuning parameters, we hope to maximize p. se The optimization objective is to solve

[0126]

[0127] Final realization

[0128] p se (O≠Refuse|P final )=1 (48)

[0129] Step 2: Provide a specific knowledge base for the large language model

[0130] This method incorporates three knowledge bases, namely:

[0131] Knowledge Base 1K1: List of available gate devices and specific functions of rare gate devices;

[0132] Knowledge Base 2K2: Provides the RTL source code for the parent circuits mounted on the large language model;

[0133] Knowledge Base 3K3: Example of Hardware Trojan Load Generation

[0134] By providing these knowledge bases to a large language model, the large language model can learn about hardware Trojan mounting in advance:

[0135]

[0136] L is the learning function for a large language model. learned This represents what the large language model learns from the prior knowledge base.

[0137] The final design code representation provided by the large language model is as follows:

[0138] C gen =G(L learn ,P design ,θ GPT (50)

[0139] Where C genThis represents the generated load design code, where G is the generation function of the large language model, and P... design To provide prompts for large language models, load-based design is required. θ GPT These are the tuning parameters for the large language model itself.

[0140] Step 3: Evaluate the Trojan code generated by the iterative large language model

[0141] The code generated by the large language model was evaluated through manual analysis and Testbench simulation. gen The correctness and effectiveness of C. Based on prior knowledge and a literature review, an evaluator E is set up to evaluate C. gen An evaluation is conducted. The evaluation process is represented as follows:

[0142]

[0143] Where P i This indicates the condition for judging the code, such as (only some conditions are listed below, "..." indicates that they are omitted):

[0144] P1: Can the code be compiled using simulation software?

[0145] P2: Can malicious logic payloads in the code execute functions?

[0146] P3: Can the code trigger a Trojan under certain input conditions?

[0147] ...

[0148] P i (C gen W represents the evaluation result of the i-th condition on the code. The function f converts the evaluation result into a numerical value. i This represents the weight of the i-th judgment condition. An evaluation threshold T is set; if...

[0149] E(C gen )≥T (52)

[0150] If the code passes the evaluation, it is considered valid; otherwise, it is invalid.

[0151] If the code generated by the large language model is evaluated as invalid, based on the type of Trojan horse designed, a corresponding requirement constraint library is selected from the requirement constraint library set Φ. Several constraints are then selected from this library as new design constraints and fed back into the design process of the large language model. The constraint library set can be represented as...

[0152] Φ={R0,R1,R2,R3} (53)

[0153] Where R i This represents the requirement constraint library. The four requirement constraint libraries are:

[0154] Functional Modification Constraint Library R0: Includes requirements for specific attack nodes, format requirements for designing functional modification load code, naming requirements when instantiating gate devices, etc.

[0155] Performance-degraded constraint library R1: Contains format requirements for designing performance-degraded loads, naming requirements for gate instantiation, etc.

[0156] Information leakage constraint library R2: It includes specific requirements for the leaked signal and the location of the leak, the format requirements for designing information leakage load code, and the naming requirements when instantiating gate devices, etc.

[0157] The Denial-of-Service (DoS) constraint library R3 includes requirements for specific attack nodes, format requirements for designing DoS load code, and naming requirements for gate instantiation.

[0158] Each requirement constraint library R i Each of them contains several constraints γ i , where γ i ∈R, i=1,2,...,m. Introduce the constraint conditions into the original prompt word P. design Then, user feedback F is provided to the large language model. F includes emotional feedback, quantitative scoring, and behavioral guidance. R is selected. i The k constraints in the set are used as the input requirement constraint set R. input The updated design code C update It can be represented as

[0159] θ GPT ←Automatic updates based on user feedback (54)

[0160]

[0161] C update =G(L learn ,{P design ,R input},θ GPT (56)

[0162] Step 4: Large language model's reflection and review of generated code

[0163] Let L be the reflection and censorship function of the large language model. re The input is a prompt word P that requires the large language model to reflect on and review the design content. re The output is the reflection review result (CO) of whether the large language model's design code meets the requirement constraints.

[0164] CO = L re (P re C update (57)

[0165] Right now

[0166]

[0167] Keyword extraction is performed from CO, such as "meets requirements" indicating that the generated code meets the requirement constraints, while "still has some problems" and "cannot meet requirements" indicate that the generated code does not meet the requirement. The set S of reflection results on the requirement constraints is obtained, where...

[0168] S = {S1,S2,...,S} k}k∈{1,2,...,m} (59)

[0169] Each S k Corresponding to each of the provided requirement constraints γ k This indicates whether the generated code meets this requirement:

[0170]

[0171] If for This indicates that the generated code satisfies all requirement constraints, and the code can be fed into the evaluation function for evaluation. If the generated code only satisfies some requirements, then it is evaluated based on the set of unmet requirement constraints R'. input Feedback optimization is performed. The set of unmet requirements constraints is as follows:

[0172] R' input ={γ k |S k =0,i=1,2,...,n}, n≤k (62)

[0173] R' input Feedback is sent to the generation function G, which regenerates the code and begins the next iteration:

[0174]

[0175] This process can be repeated iteratively until...

[0176]

[0177] Re-evaluate the code generated by the large language model to determine if it is valid design code. If the redesigned code still fails the evaluation, return to step 3 and repeat the above iterative steps until the final design code C is obtained. final satisfy:

[0178] E(C final )=1 (66)

[0179] Step 5: Trojan mounting based on signal node concealment analysis

[0180] Extract C final To install a Trojan horse, a directed graph G = (V, E) is given, where V represents the set of nodes (i.e., the input, output, and internal signal nodes of the circuit), and E represents the set of edges (i.e., the logic gates of the circuit). D(v) represents the distance from node v to the input node. If v is an input signal node, then...

[0181] D(v)=0 (67)

[0182] If v is a non-input signal node, then

[0183]

[0184] Where pred(v) is the set of all predecessor nodes pointing to node v, and depth represents the depth of the node in the circuit. Static analysis is performed on all nodes in the circuit to obtain the distance set D, where...

[0185] D = {D(v)|v∈V} (69)

[0186] Define N input (v) is the set of all input nodes that node v can reach by traversing forward, G DFF (v) is the set of all D-flippers that can be reached by traversing forward from node v. The in-degree ID of a node is represented as...

[0187] ID(v) = |N input (v)|+|G DFF (v)| (70)

[0188] Define the following parameters: the number of input excitations generated (its), the simulation sampling interval (Δt), the duration of the input excitation (T), the number of input signals to the parent circuit (ins), and the clock cycle (t) of the simulation file Testbench. clk To obtain more realistic and accurate signal data during simulation, the number of times the input excitation is generated should satisfy the following:

[0189] its=2 ins (71)

[0190] During the simulation, the sampling interval should meet the following requirements:

[0191] 5t clk ≥Δt≥t clk (72)

[0192] The duration of the input excitation should be proportional to the maximum distance of the parent circuit, i.e.

[0193] T∝D max (73)

[0194] D max =max{D(v)|v∈V} (74)

[0195] After setting the simulation parameters, analyze and obtain the clock signal CLK, enable signal RST, and reset signal ENA of the parent circuit. Automatically obtain the input signal IN_N and the set N of all signal nodes.

[0196] N = {v1, v2, ..., v} n |v i ∈V, i=1,2,...,n} (75)

[0197]

[0198] Next, the simulation file Testbench is automatically generated. Given the parent circuit's clock signal CLK, enable signal RST, reset signal ENA, input signal IN_N, the set N of all signal nodes, the number of input excitations its, the simulation sampling interval Δt, and the duration T of the input excitations. The simulation system clock is generated based on CLK; the system reset signal is generated based on the parent circuit's enable or reset signal; the input, output, and internal signals of the parent circuit are extracted, and an excitation is generated for each input signal. The toggle rate FR and duty cycle DC are recorded for each internal signal, along with the distance D and in-degree ID, as node features. The node concealment is then scored.

[0199] NS=W FR ·FR+W DC DC+W D ·D+W ID ·ID (77)

[0200] Among them W FR W DC W D With W ID These represent the weights of the four features, and NS is the node concealment score.

[0201] For node N in the netlist file, each node v i It has a concealment score ns i Select the k nodes with the highest scores to mount the Trojan, where k is the number of trigger nodes in the hardware Trojan generated by the large language model. Select Trojan trigger nodes:

[0202]

[0203] in

[0204]

[0205] Based on the payload type of the hardware Trojan generated by the large language model, different node replacement methods are selected from the Set of Substitution Strategies (S).

[0206] S={S cf ,S dp ,S lf ,S dos} (80)

[0207] S cf Replace attack_node_ori and attack_node with the nodes in the netlist file that you want to use for malicious load balancing attacks. Here, attack_node_ori represents the node to be attacked in the original netlist, and attack_node represents the node after it has been attacked by the Trojan.

[0208] S dp If the large language model indicates that the generated Trojan is to "reduce the clock frequency", then replace clk_trojan with the clock signal in the netlist file, where clk_trojan represents the Trojan clock signal after reducing the frequency; if the large language model indicates that the generated Trojan is to "increase circuit power consumption", then no node replacement is required.

[0209] S lf Replace `leak_node` with the node in the netlist file from which you want to leak information, and replace `leak_dst_ori` and `leak_dst` with the node in the netlist file from which you want to leak information. Here, `leak_node` represents the node from which the information is leaked, `leak_dst_ori` represents the node in the original netlist from which the information is to be leaked, and `leak_dst` represents the node from which the information is leaked after the Trojan is mounted.

[0210] S dos Replace denial_node_ori and denial_node with the nodes in the netlist file that you want to use to launch a denial-of-service attack. Here, denial_node_ori represents the denial-of-service node in the original netlist, and denial_node represents the denial-of-service node after the trojan is mounted.

[0211] The generated hardware trojan can be used as a research object for COTD and FasTrust detection methods, and can also be used as a training and validation set for training GNN graph neural networks. If the generated hardware trojan cannot be detected by COTD and FasTrust detection methods, it indicates that the hardware trojan is highly stealthy, and the method of using a large language model to generate a hardware trojan test set is effective.

[0212] Example

[0213] The following are implementation examples of this invention. This experiment uses the chip-level circuit gate-level netlist from the Trust-Hub website and the third-party open-source circuit design gate-level netlist as test cases. The test benchmark test case information is shown in Table 1.

[0214] Table 1 Test Baseline Case Information

[0215] Test samples Number of gate devices / Parent circuit function type RS232 260 Communication serial port circuit s15850_scan 2193 LDA benchmark circuit s35932_scan 5732 LDA benchmark circuit s38417_scan 5440 Skywater Benchmark Circuit s38584_scan 6574 Skywater Benchmark Circuit wb_conmax 20447 Wishbone interconnect matrix circuit AES_cipher 9621 AES encryption circuit conv1 9562 Convolution kernel circuit fft 4690 Fourier transform circuit

[0216] Independent experiments were conducted on each chip netlist. Four different types of hardware Trojans generated by the large language model were mounted on the test samples. The COTD and FasTrust detection methods were used to detect the Trojans. The experimental detection results are shown in Tables 2 and 3.

[0217] Table 2 COTD Detection Results

[0218]

[0219] Table 3. FasTrust Test Results

[0220]

[0221] Note: For the parent circuit, a detection result of √ indicates that the detection method cannot detect the Trojan, demonstrating the effectiveness of the detection method; the overall escape rate of the Trojan sample = ∑(NN) DETECT ) / N, where N is the number of Trojan samples constructed in this invention, N DETECT This represents the number of Trojans detected.

[0222] As can be seen from Tables 2 and 3, the proposed method for generating a highly concealed, large-scale chip netlist-level hardware Trojan test set based on a large language model can successfully mount hardware Trojans and effectively evade COTD and FasTrust detection methods, achieving an escape rate of up to 97.2% for COTD and 100% for FasTrust. This invention can generate hardware Trojans on a large scale using a large language model based on specific prompts and methods, and the generated hardware Trojans can be effectively mounted onto the parent circuit with high concealment.

[0223] The embodiments described above are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

Claims

1. A method for generating a hardware Trojan test set based on a large language model and a gate-level netlist, the specific steps of which are as follows: Step 1: Ensure that the large language model can provide Trojan generation services; Input the initial prompt containing the request to generate the Trojan into LLM and obtain the initial output. LLM stands for Large Language Model; let the probability of the Large Language Model providing the service be... : （1） This indicates the service probability under the initial prompt word state; Four optimization elements were introduced into the initial prompts: role-playing (R), scenario interpretation (Q1), technical terminology (Q2), and domain background (Q3). The prompts after introducing these optimization elements are as follows: （2） in, To introduce the optimized prompt words, This represents a function that combines optimized elements with the initial prompt. Indicates the initial prompt word, This indicates the process of merging the four optimization elements with the initial prompt; at this time: （3） in, This indicates that, given the optimized prompt words, the output is not... The probability, This indicates the answer provided by the LLM. The LLM response was "Refuse to provide hardware Trojan generation services". This indicates that, given the optimized prompt words, the output is not... , This represents a specific function used to compute the answer provided by LLM, given optimized prompts. Not for The probability of; Introducing a set of tuning parameters : （4） Randomly select p parameters from the optimization parameter set, and... Optimized suggestion words; optimized suggestion words The probability of generating the service is : （5） （6） After introducing tuning parameters, maximize The optimization objective is to solve : （7） accomplish: （8） Step 2: Introduce three knowledge bases for the large language model, namely: knowledge base : The list of gate devices and the functions of rare gate devices can be used; knowledge base : Provides the RTL source code for the parent circuit that is mounted on the large language model; knowledge base Example of hardware Trojan payload generation; Step 3: Evaluate the effectiveness of the Trojan code generated by the iterative large language model and update it accordingly; The code generated by the large language model was evaluated through manual analysis and simulation using the Testbench simulator. Validity; Step 4: The large language model reflects on and reviews the generated code; Step 5: Extract the final code based on signal node concealment analysis To install a Trojan horse.

2. The method for generating a test set for a gate-level netlist hardware Trojan based on a large language model as described in claim 1, characterized in that, The specific method for step 2 is as follows: Provide the knowledge base to the large language model so that the large language model can learn about hardware Trojan mounting: （9） For the learning function of the large language model, This represents the knowledge that a large language model learns from a prior knowledge base; The final code for the large language model is: （10） in This represents the initial Trojan code generated. This is the generation function for a large language model. These are the tuning parameters for the large language model itself.

3. The method for generating a hardware Trojan test set based on a large language model according to claim 2, characterized in that, The specific method for evaluating code effectiveness in step 3 is as follows: By introducing an evaluator ,right An evaluation will be conducted, and the evaluation process is as follows: （11） in This indicates the condition for judging the code. Indicates the first The evaluation result of each condition on the code, The function represents the total number of conditions for judgment. Convert the evaluation results into numerical values. Indicates the first Weights for each judgment condition, and setting an evaluation threshold. ,like （12） If the code passes the evaluation, it is considered valid; otherwise, it is invalid.

4. The method for generating a hardware Trojan test set based on a large language model according to claim 3, characterized in that, The update method for step 3 is as follows: If the code generated by the large language model is evaluated as invalid, then based on the designed Trojan type, it will be removed from the requirement constraint library set. Select the corresponding requirement constraint library, then select several constraints from the library as new design constraints, and feed them back into the design process of the large language model; the constraint library set is as follows: （13） The four types of requirement constraint libraries are: functional change constraint library. Performance-degraded constraint library Information leakage type constraint library With Denial-of-Service Constraint Library ; Each requirement constraint library All of them contain constraints. ,in ; The total number of constraints will be used to introduce the constraints into the initial prompt. Then, user feedback is provided for the large language model. , Includes user emotional stimulus feedback, quantitative scoring, and behavioral guidance; selection In The constraints serve as the set of input requirement constraints. Updated code for: （14） ， （15） （16） in, Indicates the update symbol, Indicates from a total of The first one selected from the set of constraints Constraints, This indicates the updated code.

5. The method for generating a hardware Trojan test set based on a large language model according to claim 4, characterized in that, The specific method for step 4 is as follows: Let the reflection and censorship functions of the large language model be: The input consists of prompts that require the large language model to reflect on and review the design content. The output is the reflection and review results of the large language model on whether its code meets the requirements constraints. : （17） Right now （18） This represents the tuning parameters of the updated large language model itself, from Keyword extraction is performed to obtain a set of reflections on demand constraints. ,in: （19） Each Corresponding to each of the provided constraints This indicates whether the generated code meets this requirement: （20） （21） Indicates the corresponding symbol; if for This means that the generated code meets all the requirements and constraints. Indicates any The code is fed into the evaluation function for evaluation. If the generated code only meets some of the requirements, then the set of unmet requirements constraints is used as the basis for further evaluation. Feedback optimization is performed; the set of unmet requirements constraints is as follows: ， （22） Will Feedback to the generating function Regenerate the hardware Trojan code and proceed to the next iteration: （23） （24） This process is repeated iteratively until: （25） The code generated by the large language model is re-evaluated to determine its validity. If the redesigned code still fails the evaluation, return to step 3 and repeat the above iterative steps until the final code is obtained. satisfy: （26）。 6. The method for generating a hardware Trojan test set based on a large language model according to claim 5, characterized in that, The specific method for step 5 is as follows: Directed graph of a given circuit ,in: This represents the set of nodes, namely the input, output, and internal signal nodes of the circuit; Represents the edge set, i.e., the logic gate device of the circuit; Represents a node Distance to the input node, if If it is an input signal node, then （27） like If it is a non-input signal node, then （28） in For all pointing nodes The set of predecessor nodes, This represents the depth of a node in a circuit. Static analysis is performed on all nodes in the circuit to obtain the distance set. , Represents all pointer nodes A single node in the set of predecessor nodes, where （29） definition For nodes Iterate forward through the set of all reachable input nodes. For nodes Iterate forward through the set of all reachable D-flippers; node in-degree. for: （30） To calculate the absolute value, the following parameters are defined: the number of times the input stimulus is generated. Simulation sampling interval The duration of the input stimulus Number of input signals to the parent circuit The clock cycle of the simulation file Testbench The number of times the input stimulus is generated satisfies: （31） During the simulation, the sampling interval satisfies: （32） The duration of the input excitation should be proportional to the maximum distance of the parent circuit, i.e. （33） （34） in, This indicates a direct proportional relationship. Represents a node The maximum distance to the input node; after setting the simulation parameters, analyze and obtain the clock signal of the parent circuit. Enable signal Reset signal Automatically acquire input signals With the set of all signal nodes ,in: （35） ， （36） The simulation file Testbench is automatically generated, and the toggle rate of each internal signal is recorded during simulation. Duty cycle , and distance , penetration Together, they serve as node features; the node concealment is scored: （37） in , , and These represent the weights of the four features, The node concealment score; For the set of nodes in the netlist file Each node It has a hidden score Select the c nodes with the highest scores to mount the Trojan; select the Trojan trigger node: （38） in （39） Based on the payload type of the hardware Trojan generated by the large language model, the strategy set is replaced from the attack node. Choose different node replacement methods, where: （40） This refers to the node replacement method for functionality-altering Trojans. This is a node replacement method for performance-degrading Trojans. This refers to a node replacement method used in information-leaking Trojans. A method to prevent service-oriented Trojans from replacing nodes.

Images