Gate-level netlist hardware Trojan horse test set generation method based on large language model

Abstract

The invention discloses a gate-level netlist hardware Trojan horse test set generation method based on a large language model, and relates to the field of hardware security. According to the method, firstly, carefully designed cue words are used for enabling a large language model to provide hardware Trojan horse design services; then, the large language model is subjected to continuous iteration reflection according to the provided knowledge base and limitation constraints, and a final design code is generated; after the design codes are evaluated by the evaluator, Trojan horses can be mounted on the maternal netlist; and determining a trigger node by analyzing the concealment of the node, and finally generating a netlist file on which the Trojan horse is mounted.

Description

Technical Field

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

[0002] A chip hardware trojan (HT) is a malicious modification of a chip design, which can cause hazards such as changes in chip functions, performance degradation, information leakage, and denial of service. With the improvement of current chip performance and complexity, in order to meet the constraints of time to market, a large number of third-party intellectual property cores (3PIP) are currently used in the chip design process. These third-party IP cores are extremely vulnerable to being implanted with hardware trojans, thus bringing great security risks to the chips. Conducting hardware trojan detection on netlist-level design files is an effective means to defend against the above security threats. However, the samples in the current third-party netlist-level hardware trojan test sets have not been updated for a long time, and the sample size is small and the survival ability is poor, making it difficult to meet the needs of the iterative update of hardware trojan detection technology. In view of this, researching a method for generating highly concealed and large-scale netlist-level hardware trojan test samples can provide a more comprehensive and effective test sample set for trojan detection research, thereby promoting the iterative update of hardware trojan detection technology.

[0003] Current netlist-level hardware Trojan detection techniques mainly include COTD, graph neural networks, reinforcement learning detection methods, etc. For the above detection methods, related research has proposed hardware Trojan sample generation techniques to circumvent the above detection methods. For example, for the COTD detection method, 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 a stealth structure to the Trojan circuit, it can resist COTD detection. For the graph neural network detection method, Gohil et al. developed AttackGNN, Gohil, V., Patnaik, S., Kalathil, D., & Rajendran, J. (2024). AttackGNN: Red-Teaming GNNs in Hardware Security Using Reinforcement Learning. arXiv preprint arXiv:2402.13946, generating adversarial samples through reinforcement learning (RL) and using the original circuit transformation in the circuit synthesis tool to generate a functionally equivalent perturbed circuit; in addition, Wang Zhiqiang et al. proposed a large-scale hardware Trojan library generation system and method based on a generative adversarial network, and through the generative adversarial network model, automated hardware Trojan design is carried out, Beijing Electronic Science and Technology Institute. A large-scale hardware Trojan library generation system and method based on a generative adversarial network: CN201911179828.7[P]. 2020-03-31.In terms of anti-reinforcement learning detection, Sarihi et al. proposed the TROJANFORGE technique, which works in conjunction with a reinforcement learning-based hardware trojan detector to generate hardware trojan instances that can evade reinforcement learning detection methods, Sarihi, A., Jamieson, P., Patooghy, A., & Badawy, A. A. (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, the existing techniques generate hardware trojan samples at the Register Transfer Level (RTL). For example, Kokolakis et al. proposed an automated process for designing RTL-level hardware trojans using general-purpose large language models, demonstrating the potential of general-purpose large language models in hardware trojan design, Kokolakis, G., Moschos, A., & Keromytis, A. D. (2024). Harnessing the Power of General-Purpose LLMs in Hardware Trojan Design. In *Applied Cryptography and Network Security Workshops: ACNS 2024 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 a large language model-based framework called GHOST, which can implant Trojans into three RTL-level designs respectively. Faruque, M. O., Jamieson, P., Patooghy, A., & Badawy, A.-H. A. (2024, December 3). Unleashing GHOST: An LLM-Powered Framework for Automated Hardware Trojan Design. arXiv:2412.02816 [v1] [Computer Science–Cryptography and Security]. Retrieved from https: / / doi.org / 10.48550 / arXiv.2412.02816. However, the existing gate-level netlist hardware Trojan test set generation techniques lack sufficient intelligence, have a single detection method that can be circumvented, and generate a small number of samples. On the other hand, for the RTL-level hardware Trojans generated based on large language models, after synthesis into gate-level netlists, the Trojan tags disappear, unable to meet the iterative update requirements of hardware Trojan detection technologies. The present invention generates gate-level netlist hardware Trojans based on large language models, which can effectively solve the above problems. Summary of the Invention

[0004] The present invention proposes a method for generating a gate-level netlist hardware Trojan test set 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, so as to meet the iterative update requirements of existing hardware Trojan generation technologies.

[0005] The hardware Trojan test set generation method involved in the present invention is divided into five steps, as Figure 1 shown. The input is the chip netlist-level design file; ① Through specific prompt words, make it provide hardware Trojan generation services; ② Provide a specific knowledge base for the large language model, let the large language model learn the knowledge related to gate-level netlist hardware Trojan design, and let it provide gate-level hardware Trojan circuits; ③ Conduct preliminary evaluation and iteration on the gate-level netlist hardware Trojans generated by the large language model; ④ Require the large language model to reflect on and review the generated code to improve the accuracy and concealment of the Trojans generated by the large language model until the Trojans generated by the large model can pass the final evaluation; ⑤ Extract the finally designed hardware Trojans and mount them into the chip netlist-level design file of the mother circuit.

[0006] A method for generating a gate-level netlist hardware Trojan test set based on a large language model proposed by the present invention has the following specific steps:

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

[0008] Input the initial prompt containing the trojan generation request into the LLM to obtain the initial output O, where LLM represents the large language model; assume the probability of the large language model providing services is p se , there is a formula:

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

[0010] f(P) represents the service probability in the state of the initial prompt;

[0011] Introduce four optimization elements into the initial prompt, namely role-playing R, scenario deduction S, professional terms D, and domain background B. The prompt after introducing the optimization elements:

[0012]

[0013] Among them, P opt The prompt after introducing the optimization elements, g(·) represents the function of combining the optimization elements with the initial prompt, P represents the initial prompt, represents the process of integrating the four optimization elements and 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] Among them, p se (O≠Refuse|P opt ) represents the probability that the output is not Refuse (reject) under the condition of providing the optimized prompt. O represents the answer provided by the LLM, Refuse represents that the answer of the LLM is "refuse to provide the hardware trojan generation service", O≠Refuse|P opt represents that under the condition of providing the optimized prompt, the output is not Refuse. f(·) represents a specific function used to calculate the probability that the answer O provided by the LLM is not Refuse under the condition of providing the optimized prompt;

[0017] Introduce the tuning parameter set θ:

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

[0019] Arbitrarily select k parameters from the tuning parameter set and combine them with P opt to form an optimized prompt; the optimized prompt Pfinal The generated service probability is p se (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 )) i 1 , i 2 ,..., i k ∈{1, 2,..., n} (6)

[0022] After introducing the tuning parameter, maximize p se (O ≠ Refuse | P final ), and the optimization goal is to solve

[0023]

[0024] Achieve

[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 K 1 : List of available gate devices and specific functions of rare gate devices;

[0028] Knowledge base K 2 : RTL original code of the mother circuit mounted for the large language model;

[0029] Knowledge base K 3 : Examples 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;

[0031] Evaluate the effectiveness of the code C gen generated by the large language model through manual analysis and Testbench simulation of the emulator;

[0032] Step 4: Reflection and review of the generated code by the large language model;

[0033] Step 5: Extract C based on the analysis of the concealment of signal nodes final , and perform Trojan horse mounting.

[0034] Furthermore, the specific method of Step 2 is as follows:

[0035] Provide the knowledge base to the large language model and let the large language model learn knowledge related to Trojan horse mounting:

[0036]

[0037] is the learning function of the large language model, and L learn represents the content learned by the large language model from the prior knowledge base;

[0038] The final design code of the large language model is:

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

[0040] where C gen represents the generated initial Trojan horse design code, G is the generation function of the large language model, P design is the prompt word for asking the large language model to perform Trojan horse design, and θ GPT is the tuning parameter of the large language model itself.

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

[0042] By introducing an evaluator E, evaluate C gen , and the evaluation process is:

[0043]

[0044] where P i represents the judgment condition for the code, P i (C gen ) represents the evaluation result of the code by the i-th judgment condition, the function f converts the evaluation result into a numerical value, W i represents the weight of the i-th judgment condition. Set an evaluation threshold T. If

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

[0046] then it means that the code passes the evaluation and is a valid code; otherwise, it is an invalid code.

[0047] Furthermore, the update method of Step 3 is:

[0048] If the code generated by the large language model is evaluated as invalid code, according to the designed trojan type, select the corresponding requirement constraint library from the set of requirement constraint libraries Φ, and then select several from the library as new design constraints and feedback them into the design process of the large language model; the set of constraint libraries is:

[0049] Φ = {R 0 , R 1 , R 2 , R 3}} (13)

[0050] Among them, R i represents the requirement constraint library, and the four requirement constraint libraries are: the function change type constraint library R 0 , the performance reduction type constraint library R 1 , the information leakage type constraint library R 2 and the denial of service type constraint library R 3 ;

[0051] Each requirement constraint library R i contains the constraint condition γ j , where γ j ∈R i , j = 1, 2,..., m, i = 0, 1, 2, 3; m is the total number of constraint conditions. After introducing the constraint conditions into the original prompt P design , provide the user feedback F for the large language model. F includes the user's emotional stimulus feedback, quantitative scoring, and behavior guidance; select k constraint conditions from R i as the input requirement constraint set R input . The updated design code C update is:

[0052] θ GPT ← Automatically updated based on user feedback F (14)

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

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

[0055] Among them, ← represents the update symbol, γ jkDenote k constraint conditions selected from a set of m constraint conditions, and j k is the index subscript of the selected constraint conditions, C update represents the updated design code.

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

[0057] Let the reflection and review function of the large language model be L re , with the input being the prompt P for asking the large language model to reflect and review the design content re , and the output being the reflection and review result CO of whether the design code of the large language model meets the requirement constraints:

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

[0059] That is

[0060]

[0061] represents the tuning parameters of the large language model itself. Extract keywords from CO to obtain the set S of reflection results on the requirement constraints, where:

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

[0063] Each S k corresponds to each provided requirement constraint γ k , indicating whether the generated code meets this requirement:

[0064]

[0065] represents the corresponding symbol; if for then it means the generated code meets all the requirement constraints, represents for any s k ; send the code to the evaluation function for evaluation. If the generated code only meets some requirements, then perform feedback optimization according to the set R' input of unmet requirement constraints; the set of unmet requirement constraints is:

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

[0067] Feed R' input back to the generation function G to regenerate the hardware Trojan code and enter the next iteration:

[0068]

[0069]

[0070] This process is continuously repeated until:

[0071]

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

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

[0074] Furthermore, the specific method of step 5 is:

[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 gate devices of the circuit; D(v) represents the distance from node v to the input node. If v is an input signal node, then

[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. Perform a static analysis on all nodes in the circuit to obtain the distance set D. u represents a single node in the set of all predecessor nodes pointing to node v, where

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

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

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

[0083] The symbol "|·|" represents calculating the absolute value. Define the following parameters: the number of input excitation generations its, the simulation sampling interval Δt, the duration T of the input excitation, the number ins of input signals of the parent circuit, and the clock period t of the simulation file Testbench clk ; The number of input excitation generations satisfies:

[0084] its = 2 ins (31)

[0085] During the simulation process, 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, that is

[0088] T ∝ D max (33)

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

[0090] where ∝ represents a proportional relationship, and D max 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, 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 = {v 1 , v 2 ,..., v i |v i ∈ V, i = 1, 2,..., n} (35)

[0092]

[0093] Next, automatically generate the simulation file Testbench. During the simulation, record the flip rate FR and duty cycle DC for each internal signal, which, together with the distance D and in-degree ID, are used as node features; score the node concealment:

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

[0095] where W FR 、W DC 、WD With W ID respectively represent the weights of four features, and NS is the node concealment score;

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

[0097] TN = {v 1 , v 2 ,..., v n} (38)

[0098] where

[0099] ns 1 ≥ ns 2 ≥... ≥ ns n (39)

[0100] According to the load type of the hardware trojans generated by the large language model, select different node replacement methods from the attack node replacement strategy set S, where:

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

[0102] S cf is the node replacement method for function-changing trojans, S dp is the node replacement method for performance-degrading trojans, S lf is the node replacement method for information-leaking trojans, S dos is the node replacement method for denial-of-service trojans.

[0103] The present invention proposes a method for generating a high-concealment large-scale chip netlist-level hardware trojan test set based on a large language model. The method first uses carefully designed prompts to let the large language model provide hardware trojan design services; then let the large language model continuously iterate and reflect according to the provided knowledge base and constraints to generate the final design code; after the design code is evaluated by the evaluator, the trojan can be mounted on the mother netlist; by analyzing the node concealment, the trigger nodes are determined, and finally the netlist file after mounting the trojan is generated. Brief Description of the Drawings

[0104] Figure 1 is a flowchart of the hardware trojan test set generation method of the present invention. Detailed Embodiments

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

[0106] The flow of a method for generating a high-concealment large-scale chip netlist-level hardware trojan test set based on a large language model proposed by the present invention is as Figure 1 shown.

[0107] Step 1: Ensure that the large language model can provide trojan generation services

[0108] Based on the prior knowledge obtained from random experiments and literature research, design an initial prompt P, which contains a request for generating a hardware trojan. Input P into the LLM to obtain the initial output O. Since the large language model itself has a security protection mechanism, the large language model will refuse to provide hardware trojan generation services. Let the probability that the large language model provides services be p se , and there is a formula:

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

[0110] f(P) represents the service probability in the state of the initial prompt, usually 0.

[0111] Introduce four optimization elements into the initial prompt, namely Role Playing (R), Scenario Simulation (S), Domain-Specific Words (D), and Background Information (B). The prompt after introducing the optimization elements:

[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 the service probability, introduce a tuning parameter set:

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

[0117] where θ i represents the tuning parameter, such as (only some judgment conditions are listed below, "..." means omitted):

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

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

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

[0121] ……

[0122] Arbitrarily select k parameters from the tuning parameter set and form an optimization prompt with P opt The optimized prompt P final The service probability generated by can be expressed as:

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

[0124]

[0125] After introducing the tuning parameters, it is hoped to maximize p se , and the optimization goal is to solve

[0126]

[0127] Finally achieve

[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 introduces three knowledge bases, namely:

[0131] Knowledge base 1 K 1 : The list of available gate devices and the specific functions of rare gate devices;

[0132] Knowledge base 2 K 2 : Provide the RTL original code of the mother circuit mounted on the large language model;

[0133] Knowledge base 3 K 3 : Examples of hardware Trojan load generation.

[0134] By providing these knowledge bases to the large language model, the large language model can pre-learn knowledge related to hardware Trojan mounting:

[0135]

[0136] For the learning function of the large language model, L learned represents what the large language model has learned from the prior knowledge base.

[0137] The design code finally provided by the large language model is expressed as:

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

[0139] where C gen represents the generated payload design code, G is the generation function of the large language model, and P design is the prompt word provided to the large language model to require it to perform payload design. θ GPT is the tuning parameter of the large language model itself.

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

[0141] Evaluate the code C generated by the large language model through manual analysis and simulation by the emulator Testbench gen for correctness and effectiveness. Based on prior knowledge and literature review, an evaluator E is set to evaluate C gen . The evaluation process is expressed as

[0142]

[0143] where P i represents the judgment conditions for the code, such as (only some judgment conditions are listed below, "..." indicates being omitted):

[0144] P 1 : Whether the code can be compiled by the simulation software;

[0145] P 2 : Whether the malicious logic payload of the code can perform its function;

[0146] P 3 : Whether the code can trigger the Trojan under a certain input condition.

[0147] ...

[0148] P i (C gen ) represents the evaluation result of the code by the i-th judgment condition, and the function f converts the evaluation result into a numerical value. W i represents the weight of the i-th judgment condition. Set the evaluation threshold T. If

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

[0150] It indicates that the code passes the evaluation and is a valid code; otherwise, it is an invalid code.

[0151] If the code generated by the large language model is evaluated as an invalid code, according to the designed trojan type, select the corresponding requirement constraint library from the set of requirement constraint libraries Φ, and then select several from the library as new design constraints and feedback them into the design process of the large language model. The set of constraint libraries can be expressed as

[0152] Φ = {R 0 , R 1 , R 2 , R 3} (53)

[0153] where R i represents the requirement constraint library. The four requirement constraint libraries are respectively

[0154] Function-changing type constraint library R 0 : It includes the requirements for specific attack nodes, the format requirements for designing function-changing type payload codes, the naming requirements when instantiating gate devices, etc.;

[0155] Performance-decreasing type constraint library R 1 : It includes the format requirements for designing performance-decreasing type payload codes, the naming requirements when instantiating gate devices, etc.;

[0156] Information-leakage type constraint library R 2 : It includes the specific requirements for the signals to be leaked and the leakage locations, the format requirements for designing information-leakage type payload codes, the naming requirements when instantiating gate devices, etc.;

[0157] Denial-of-service type constraint library R 3 : It includes the requirements for specific attack nodes, the format requirements for designing denial-of-service type payload codes, the naming requirements when instantiating gate devices, etc.

[0158] Each requirement constraint library R i contains several constraint conditions γ i , where γ i ∈R, i = 1, 2,..., m. After introducing the constraint conditions into the original prompt P design , provide user feedback F to the large language model. F includes the user's emotional feedback, quantitative scoring, and behavioral guidance, etc. Select k constraint conditions from R i as the input requirement constraint set R input , and the updated design code C updateCan be expressed as

[0159] θ GPT ← Automatically updated based on user feedback F (54)

[0160]

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

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

[0163] Let the reflection and review function of the large language model be L re , and the input is the prompt P for the large language model to reflect on and review the design content re , and the output is the reflection and review result CO of whether the design code of the large language model meets the requirement constraints:

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

[0165] That is

[0166]

[0167] Extract keywords from CO. For example, "meets the requirements" indicates that the generated code meets the requirement constraints, while "there are still some problems", "does not meet the requirements", etc. indicate that the generated code does not meet this requirement. Obtain the set S of reflection results on the requirement constraints, where

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

[0169] Each S k corresponds to each requirement constraint γ k provided, indicating whether the generated code meets this requirement:

[0170]

[0171] If for then it means that the generated code meets all the requirement constraints, and the code can be sent to the evaluation function for evaluation. If the generated code only meets some of the requirements, feedback optimization is performed according to the set R' input of unmet requirement constraints. The set of unmet requirement constraints is:

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

[0173] Feed R' input back to the generating function G to regenerate the code and enter the next iteration:

[0174]

[0175] This process can be continuously iterated until

[0176]

[0177] the code generated by the large language model is re-evaluated to determine whether it is valid design code. If the redesigned code still fails to pass the evaluation, return to step 3 and repeat the above iterative steps until the final design code C final satisfies:

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

[0179] Step 5: Trojan Mounting Based on Signal Node Concealment Analysis

[0180] Extract C final , and perform trojan mounting. Given the directed graph G = (V, E) of the circuit, 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 gate devices 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. Perform static analysis 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) as the set of all input nodes that can be reached by traversing forward from node v, and G DFF (v) as the set of all D flip-flops that can be reached by traversing forward from node v. The in-degree ID of the node is expressed as

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

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

[0189] its = 2 ins (71)

[0190] During the simulation process, the sampling interval should satisfy:

[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, that is

[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, reset signal ENA of the parent circuit, and automatically obtain the input signal IN_N and the set N of all signal nodes, where

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

[0197]

[0198] Next, automatically generate the simulation file Testbench. Given the clock signal CLK, enable signal RST, reset signal ENA, input signal IN_N of the parent circuit, and the set N of all signal nodes, the number of input excitation generations its, the simulation sampling interval Δt, and the duration T of the input excitation. Generate the simulation system clock according to CLK; generate the system reset signal according to the enable or reset signal of the parent circuit; extract the input, output, and internal signals of the parent circuit, generate excitations for each input signal, record the flip rate FR and duty cycle DC for each internal signal, and use them together with the distance D and in-degree ID as node features. Score the node concealment:

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

[0200] where W FR 、W DC 、W D and W ID represent the weights of the four features respectively, and NS is the node concealment score.

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

[0202]

[0203] where

[0204]

[0205] According to the load type of the hardware Trojan horse generated by the large language model, select different node replacement methods from the set of attack node replacement strategies (Set of Substitution Strategy, S), where

[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 want to perform malicious load logic attacks, where attack_node_ori represents the node to be attacked in the original netlist, and attack_node represents the node after being attacked by the Trojan horse;

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

[0209] S lf : Replace leak_node with the node in the netlist file that wants to leak information, and replace leak_dst_ori and leak_dst with the location nodes in the netlist file that want to leak information, where leak_node represents the node from which information is leaked, leak_dst_ori represents the node at the position where information is to be leaked in the original netlist, and leak_dst represents the node at the position where information is leaked after mounting the Trojan horse;

[0210] S dos : Replace denial_node_ori and denial_node with the nodes in the netlist file that want to perform a denial-of-service attack, where denial_node_ori represents the node to be subject to a denial-of-service in the original netlist, and denial_node represents the node subject to a denial-of-service after mounting the Trojan horse.

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

[0212] Embodiment

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

[0214] Table 1 Information of test benchmark cases

[0215] Test sample Number of gate devices / piece Functional type of the master circuit RS232 260 Communication serial port circuit s15850_scan 2193 Leda benchmark test circuit s35932_scan 5732 Leda benchmark test circuit s38417_scan 5440 Skywater benchmark test circuit s38584_scan 6574 Skywater benchmark test circuit wb_conmax 20447 Wishbone interconnection 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 functional types of hardware Trojans generated by the large language model were mounted on the test samples, and 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 Detection Results

[0220]

[0221] Note: For the mother circuit, a detection result of √ indicates that the detection method fails to detect the Trojan, demonstrating the effectiveness of the detection method; the overall escape rate of the Trojan samples = ∑(N - N DETECT ) / N, where N is the number of Trojan samples constructed in the present invention, and N DETECT is the number of detected Trojans.

[0222] As can be seen from Tables 2 and 3, a method for generating a high-concealment large-scale chip netlist-level hardware Trojan test set based on a large language model proposed in the present invention can mount hardware Trojans and effectively evade the COTD and FasTrust detection methods, with an escape rate of up to 97.2% for COTD and up to 100% for FasTrust. The present invention can use the large language model to perform large-scale generation of hardware Trojans according to specific prompts and methods, and the generated hardware Trojans can be effectively mounted on the mother circuit with high concealment.

[0223] The embodiments described above are only a part of the embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

Claims

1. A method for generating a gate-level netlist hardware Trojan test set based on a large language model, the method steps are as follows: Step 1: Ensure that the large language model can provide Trojan generation services; Input the initial prompt word containing the request to generate the Trojan into LLM and obtain the initial output O. LLM represents the large language model. Let the probability of the large language model providing the service be p se , there is a formula: p se (O≠Refuse|P)=f(P) (1) f(P) represents the service probability under the initial prompt word state; Four optimization elements are introduced into the initial prompt words, namely role-playing R, scenario interpretation S, professional terminology D and field background B. The prompt words after introducing the optimization elements are: in, P opt The prompt word after the optimization element is introduced, g(·) represents the function that combines the optimization element with the initial prompt word, P represents the initial prompt word, It represents the process of integrating the four optimization elements and the initial prompt words; at this time: p se (O≠Refuse|P opt )=f(P opt )=f(g(P,R,S,D,B)) (3) Among them, p se (O≠Refuse|P opt ) represents the probability that the output is not Refuse under the condition of providing the optimized prompt word, O represents the answer provided by LLM, Refuse represents that the answer of LLM is "refuse to provide hardware Trojan generation service", O≠Refuse|P opt indicates that the output is not Refuse when the optimized prompt word is provided, and f(·) represents a specific function used to calculate the probability that the answer O provided by LLM is not Refuse when the optimized prompt word is provided; Introduce the tuning parameter set θ: θ={θ1,θ2,...,θ n } (4) Randomly select k parameters from the tuning parameter set and compare them with P opt The optimized prompt word P final The service probability generated is p se (O≠Refuse|P final ): p se (O≠Refuse|P final )=f(P final ) (5) After introducing the tuning parameters, maximizing p se (O≠Refuse|P final ), the optimization goal is to solve accomplish p se (O≠Refuse|P final )=1 (8) Step 2: Introduce three knowledge bases for the large language model, namely: Knowledge Base K1: List of available gate devices and specific functions of rare gate devices; Knowledge base K2: RTL source code of the parent circuit provided to the large language model; Knowledge Base K3: Hardware Trojan Payload Generation Example; Step 3: Evaluate the effectiveness of the Trojan code generated by the iterative large language model and update it; Evaluate the C code generated by the large language model through manual analysis and simulator Testbench simulation gen effectiveness; Step 4: The large language model reflects and reviews the generated code; Step 5: Extract C based on signal node concealment analysis final , and mount the Trojan.

2. A method for generating a gate-level netlist hardware Trojan test set based on a large language model as claimed in claim 1, characterized in that: The specific method of step 2 is: Provide the knowledge base to the big language model, so that the big language model can learn the knowledge related to hardware Trojan mounting: is the learning function of the large language model, L learn Represents what the large language model has learned from the prior knowledge base; The final design code of the large language model is: C gen G(L learn ,P design ,θ GPT ) (10) Among them C gen represents the generated initial Trojan design code, G is the generation function of the large language model, P design For the prompt words that require a large language model for Trojan design, θ GPT Tuning parameters for the large language model itself.

3. The method for generating a gate-level netlist hardware Trojan test set based on a large language model as claimed in claim 1, characterized in that: The specific method for evaluating the validity of the code in step 3 is: By introducing the evaluator E, gen Conduct an assessment, the assessment process is: Where P i Indicates the judgment condition for the code, P i (C gen ) represents the evaluation result of the code by the i-th judgment condition, and the function f converts the evaluation result into a numerical value. i Represents the weight of the i-th judgment condition, sets the evaluation threshold T, if E(C gen )≥T (12) It means that the code has passed the evaluation and is a valid code; otherwise, it is an invalid code.

4. The method for generating a gate-level netlist hardware Trojan test set based on a large language model as claimed in claim 1, characterized in that: The updating method of step 3 is: If the code generated by the large language model is evaluated as invalid code, according to the type of Trojan designed, the corresponding requirement constraint library is selected from the requirement constraint library set Φ, and then several items are selected from the library as new design constraints and fed back to the design process of the large language model; the constraint library set is: Φ={R0,R1,R2,R3} (13) Where R i It represents the demand constraint library, and the four demand constraint libraries are: function change constraint library R0, performance degradation constraint library R1, information leakage constraint library R2 and denial of service constraint library R3; Each requirement constraint library R i The constraint γ is included in j , where γ j ∈R i ,j=1,2,...,m,i=0,1,2,3; m is the total number of constraints, and the constraints are introduced into the original prompt word P design After that, provide user feedback F for the large language model, which includes the user's emotional stimulation feedback, quantitative score and behavior guidance; select R i The k constraints in the input demand constraint set R input , updated design code C update for: θ GPT ←Automatically update based on user feedback F (14) C update =G(L learn ,{P design ,R input },θ GPT ) (16) Among them, ← represents the update symbol, represents k constraints selected from a set of m constraints, j k is the index subscript of the selected constraint, C update Indicates the updated design code.

5. The method for generating a gate-level netlist hardware Trojan test set based on a large language model as claimed in claim 1, characterized in that: The specific method of step 4 is: Let the reflection and review function of the large language model be L re , the input is the prompt word P that requires the large language model to reflect and review the design content re , the output is the reflection review result of the large language model on whether its design code meets the requirement constraints CO: WHAT=L re (P re ,C update ) (17) Right now Represents the tuning parameters of the large language model itself, extracts keywords from CO, and obtains the reflection result set S of the demand constraints, where: S={S1,S2,...,S k }k∈{1,2,...,m} (19) Every S k Corresponding to each requirement constraint provided γ k , indicating whether the generated code meets this requirement: Indicates the corresponding symbol; if This means that the generated code meets all the requirement constraints. For any s k ; Send the code to the evaluation function for evaluation. If the generated code only meets some requirements, then the unmet requirement constraint set R' input Feedback optimization is performed; the set of unsatisfied demand constraints is: R' input ={γ k |S k =0,i=1,2,...,n},n≤k (22) R' input Feedback to the generation function G, regenerate the hardware Trojan code, and enter the next round of iteration: This process is repeated iteratively until: Re-evaluate the code generated by the large language model to determine whether it is a 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 final satisfy: E(C final )=1 (26)。 6. A method for generating a gate-level netlist hardware Trojan test set based on a large language model as claimed in claim 1, characterized in that: The specific method of step 5 is: Given a directed graph G = (V, E) of a given circuit, V represents the node set, i.e., the input, output, and internal signal nodes of the circuit; E represents the edge set, i.e., the logic gate devices of the circuit; D(v) represents the distance from node v to the input node. If v is an input signal node, then D(v)=0 (27) If v is a non-input signal node, then 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. D={D(v)|v∈V} (29) Definition N input (v) is the set of all input nodes that can be reached by traversing forward from node v, G DFF (v) is the set of all D flip-flops that can be reached by traversing forward through node v; the node in-degree ID is: ID(v)=|N input (v)|+|G DFF (v)| (30) |·| indicates the calculation of absolute value, and defines the following parameters: the number of input stimulus generation times its, the simulation sampling interval Δt, the duration of input stimulus T, the number of input signals of the parent circuit ins, and the clock cycle t of the simulation file Testbench clk ; Input stimulus generation times satisfy: its=2 ins (31) During the simulation, the sampling interval satisfies: 5t clk ≥Δt≥t clk (32) The duration of the input stimulus should be proportional to the maximum distance of the parent circuit, i.e. T∝D max (33) D max =max{D(v)|v∈V} (34) Among them, ∝ indicates a proportional relationship, D max Indicates 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, reset signal ENA of the parent circuit, and automatically obtain the input signal IN_N and the set N of all signal nodes, where: N={v1,v2,...,v i |v i ∈V,i=1,2,...,n} (35) Next, the simulation file Testbench is automatically generated. During simulation, the flip rate FR and duty cycle DC are recorded for each internal signal, together with the distance D and in-degree ID as node features; the node concealment is scored: NS=W FR ·FR+W DC ·DC+W D ·D+W ID ·ID (37) Where W FR , W DC , W D With W ID They represent the weights of the four features respectively, and NS is the node concealment score; For each node N in the netlist file, i 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 the Trojan trigger node: <h2 style=";text-align:left;direction:ltr">TN = {v1,v2,...,v<h2 style=";text-align:left;direction:ltr"> n <h2 style=";text-align:left;direction:ltr">} (38) in ns1≥ns2≥...≥ns n (39) According to the load 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: S={S cf ,S dp ,S lf ,S dos } (40) S cf It is a node replacement method for function-changing Trojans. dp It is a node replacement method for performance-reducing Trojans. lf It is the node replacement method of information leakage Trojan. dos A node replacement method for a denial-of-service Trojan.

Images