Negative control terminal program trusted loading method and electronic device

Abstract

The present application provides a method for securely loading a negative control terminal program and an electronic device. The method includes: sending an operation instruction to a hardware security module by using a central processing unit, negotiating a first session key with the hardware security module, and generating a device fingerprint by using the hardware security module; intercepting a program call entry by using a linux system kernel, intercepting a program to be loaded, and transmitting the original signature of the program to be loaded to the hardware security module, and verifying the original signature by using the hardware security module; if the verification of the original signature is successful, generating a second session key by using a random number generated by a true random number generator of the hardware security module in combination with the device fingerprint; calling a communication interface between the kernel and the hardware security module, sending sensitive data of the program to the hardware security module, encrypting the sensitive data by using the second session key, and mapping the encrypted sensitive data to an independent address space; when the program runs to an end or is interrupted, erasing the second session key and the random number by using the hardware security module.

Description

Technical Field

[0001] This application relates to the field of network security technology, and particularly to a method for securely loading a negative control terminal program and an electronic device. Background Art

[0002] In an industrial control system, a negative control terminal is responsible for monitoring and managing power or other critical infrastructure. Traditional eBPF (Extended Berkeley Packet Filter) is a technology that allows user-space programs to run sandboxed programs in the Linux kernel and is widely used in network monitoring, performance analysis, etc. of negative control terminals. However, during the program loading process, since the storage of certificates and keys can be easily forged or an attacker can directly extract the private key through a physical interface, thus signing a malicious eBPF program, resulting in the kernel being unable to recognize the code's legitimacy. In addition, when using static key encryption for memory or relying on MMU isolation, the keys are fixed for a long time and are easily attacked and extracted, enabling an attacker to reverse-derive the network topology related to the negative control terminal and thus carry out targeted attacks. Summary of the Invention

[0003] In view of this, the purpose of this application is to propose a method for securely loading a negative control terminal program and an electronic device that overcome or at least partially solve the above problems.

[0004] Based on the above purpose, in the first aspect of this application, a method for securely loading a negative control terminal program is provided, which is applied to a Linux system and includes:

[0005] Using a central processing unit to send an operation instruction to a hardware security module, negotiating a first session key with the hardware security module, and generating a device fingerprint using the hardware security module;

[0006] Determining a program to be loaded, using the Linux system kernel to intercept the program call entry, intercepting the program to be loaded, and transmitting the original signature of the program to be loaded to the hardware security module for verification by the hardware security module;

[0007] In response to successful verification of the original signature, generating a second session key using a random number generated by a true random number generator of the hardware security module in combination with the device fingerprint;

[0008] Using the Linux system kernel to call the communication interface between the kernel and the hardware security module, sending sensitive data of the program to be loaded to the hardware security module, encrypting the sensitive data using the second session key, mapping the encrypted sensitive data to an independent address space, setting access only by the hardware security module and prohibiting caching;

[0009] In response to the end or interruption of the operation of the program to be loaded, use the hardware security module to erase the second session key and the random number.

[0010] Optionally, after using the central processing unit to send an operation instruction to the hardware security module, negotiate the first session key with the hardware security module, and use the hardware security module to generate a device fingerprint, further include:

[0011] Use the central processing unit to split the root certificate chain of the negative control terminal into a main chain and a backup chain, and use a preset first hash algorithm and second hash algorithm to calculate the hash values of the main chain and the backup chain respectively;

[0012] Transmit the main chain, the backup chain and the hash values to the hardware security module;

[0013] Use the first hash algorithm and the second hash algorithm preset in the hardware security module to verify the hash values of the main chain and the backup chain;

[0014] Store the main chain in the one-time programmable area of the hardware security module;

[0015] Use the device fingerprint to encrypt the derived key of the backup chain and store it in the authorized access area of the hardware security module.

[0016] Optionally, using the central processing unit to send an operation instruction to the hardware security module and negotiating the first session key with the hardware security module includes:

[0017] Use the central processing unit to send an operation instruction to the hardware security module; the operation instruction includes the first public key, the first private key and the elliptic curve of the central processing unit;

[0018] Use the hardware security module to generate a second private key, and use the second private key and the elliptic curve to generate a second public key;

[0019] Generate the first session key according to the first private key, the first public key, the second private key and the second public key;

[0020] The first session key is expressed as:

[0021] K_master = SHA3-256(x(Q_HSM × d_CPU) || x(Q_CPU × d_HSM)),

[0022] where d_CPU, Q_CPU, d_HSM, Q_HSM represent the first private key, the first public key, the second private key and the second public key respectively, and x() represents taking the x coordinate of the elliptic curve point.

[0023] Optionally, generating the device fingerprint using the hardware security module includes:

[0024] Extracting the salt value of its own secure storage area using the hardware security module;

[0025] Reading the unique identity code in the fuse area using the hardware security module;

[0026] Reading the hardware interface address between the hardware security module and the fuse area using the hardware security module;

[0027] Generating the device fingerprint using the hardware security module according to the salt value, the unique identity code, and the hardware interface address;

[0028] The device fingerprint is represented as:

[0029] dev_fingerprint = SHA3-256(UID_OTP || MAC_addr || Salt_HSM),

[0030] where Salt_HSM, UID_OTP, and MAC_addr represent the salt value, the unique identity code, and the hardware interface address respectively, || represents data concatenation, and SHA3-256 represents a standardized hashing algorithm.

[0031] Optionally, determining the program to be loaded, using the linux system kernel to intercept the program call entry, intercepting the program to be loaded, and transmitting the original signature of the program to be loaded to the hardware security module, and verifying the original signature using the hardware security module, includes:

[0032] Registering an interception function in the kernel source code using the linux system kernel and mounting the interception function to the program call entry;

[0033] In response to the trigger of the interception function, pausing the program to be loaded and extracting the metadata of the program to be loaded;

[0034] Encrypting the original signature in the metadata using the second private key to form a signature value, and encapsulating and sending the original signature and the signature value to the hardware security module;

[0035] Comparing and verifying the original signature and the signature value using the second public key burned in the secure storage area by the hardware security module.

[0036] Optionally, in response to the successful verification of the original signature, generating a second session key by combining the random number generated by the true random number generator of the hardware security module with the device fingerprint, includes:

[0037] Generate a random number using the true random number generator of the hardware security module;

[0038] Extract the hash value of the program to be loaded using the hardware security module;

[0039] Encrypt the random number, hash value, and device fingerprint using the first session key to generate a second session key;

[0040] The second session key is expressed as:

[0041] K_{session} = HMAC_{SHA256}(R || dev_fingerprint || prog\_hash),

[0042] where R, prog\_hash, and dev_fingerprint represent the random number, hash value, and device fingerprint respectively, HMAC represents the first session key inside the hardware security module, and SHA256 represents the hash algorithm.

[0043] Optionally, use the linux system kernel to call the communication interface between the kernel and the hardware security module, and send the sensitive data of the program to be loaded to the hardware security module, and encrypt the sensitive data using the second session key, including:

[0044] Use the linux system kernel to call the interface between the kernel and the hardware security module, and send the sensitive data of the program to be loaded to the hardware security module;

[0045] Use the hardware security module to set the life cycle function of the second session key and split the second session key into an encryption key and an authentication key;

[0046] Split the sensitive data into plaintext data blocks of a fixed length, and encrypt the plaintext data blocks using the encryption key to generate ciphertext;

[0047] Determine the hash value of the ciphertext and the authentication key;

[0048] Use the true random generator of the hardware security module to derive a second random number, and perform finite field operations on the encryption key,

[0049] the hash value of the ciphertext and the authentication key, and the second random number to generate an authentication tag.

[0050] Optionally, map the encrypted sensitive data to an independent address space, set access only by the hardware security module and prohibit caching, including:

[0051] Use the hardware security module to send the ciphertext and the authentication tag to the Linux system kernel;

[0052] Use the Linux system kernel to call the memory mapping interface to set independent address spaces for the ciphertext and the authentication tag correspondingly;

[0053] Enable the memory protection unit to perform regional isolation on the independent address space;

[0054] Set the independent address space to disable the central processing unit cache;

[0055] Set the independent address space to only allow access by the hardware security module.

[0056] Optionally, in response to the end or interruption of the program to be loaded, use the hardware security module to erase the second session key and the random number, including:

[0057] In response to the end or interruption of the program to be loaded, use the hardware security module to receive an end-of-program instruction;

[0058] Use the hardware security module to execute an erase instruction according to the end-of-program instruction; wherein the erase instruction overwrites the storage area of the second session key;

[0059] Erase the second session key and the random number generated by the true random number generator;

[0060] Use the Linux system kernel to receive the end-of-program instruction and clear the memory of the program to be loaded.

[0061] In a second aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the method described in the first aspect is implemented.

[0062] As can be seen from the above, the negative control terminal program trusted loading method and the electronic device provided by this application utilize the hardware-level physically unclonable device fingerprint generated by the hardware security module. This fingerprint cannot be replicated by software or cloned by hardware. In cooperation with the main chain and backup chain of the industrial protocol root certificate pre-set in the secure storage area of the hardware security module, through the unique data source of the hardware, that is, by using the unique identity code in the fuse area, the hardware interface address between the hardware security module and the fuse area, and the salt value in the secure storage area of the hardware security module itself, an unclonable device fingerprint is generated to achieve a strong binding between the identity of the negative control terminal and the physical chip. This device fingerprint cannot be replicated by software or cloned by hardware. Further combined with the binding of the industrial protocol dual certificate chain in the hardware security module, the negative control terminal needs to verify its identity through two certificate chains during communication, that is, the hardware security module needs to respectively compare and verify the hash values of the main chain and the backup chain, and the verification needs to be authorized by the hardware security module, further realizing the uniqueness and anti-counterfeiting ability of the negative control terminal device identity.

[0063] Further intercept before the program is loaded. Use the hardware security module to submit the signed original text of the metadata of the program to be loaded to the hardware security module for decryption and verification. The verification process is completely completed in the hardware (hardware security module), and external parties cannot bypass the hardware verification process to prevent attackers from maliciously signing the program to be loaded through the debugging interface or memory scanning.

[0064] A dynamic and single-use second session key generated based on a random number, the hash value of the program to be loaded, and the device fingerprint, avoiding the batch decryption of encrypted data caused by key leakage. Attackers can reverse-derive the power grid topology structure and then carry out a targeted attack on the precision relay protection system.

[0065] By encrypting and authenticating the sensitive data of the program to be loaded, reducing performance loss and avoiding resource waste, mapping the encrypted sensitive data to an independent address space, and setting access only by the hardware security module and prohibiting caching. Implement hardware-level memory protection.

[0066] Finally, when the program to be loaded is loaded or interrupted, erase the second session key and the random number to ensure that even if the second session key is leaked, historical or future data cannot be decrypted.

[0067] The above description is only an overview of the technical solution of the present invention. In order to be able to more clearly understand the technical means of the present invention, it can be implemented in accordance with the content of the specification. And in order to make the above and other purposes, features and advantages of the present invention more obvious and understandable, the specific embodiments of the present invention are specifically given below. BRIEF DESCRIPTION OF THE DRAWINGS

[0068] To more clearly illustrate the technical solutions in the present application or related technologies, the following will briefly introduce the drawings required for use in the embodiments or the description of related technologies. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0069] Figure 1 Flowchart of the negative control terminal program trusted loading method 100 according to an embodiment of the present application;

[0070] Figure 2 Flowchart of using double-chain verification according to an embodiment of the present application;

[0071] Figure 3 Flowchart of generating a device fingerprint according to an embodiment of the present application;

[0072] Figure 4 Flowchart of verifying the original signature text according to an embodiment of the present application;

[0073] Figure 5 Flowchart of generating a second session key according to an embodiment of the present application;

[0074] Figure 6 Flowchart of encrypting the program to be loaded according to an embodiment of the present application;

[0075] Figure 7 Schematic diagram of the communication interface between the kernel and the hardware security module according to an embodiment of the present application;

[0076] Figure 8 Schematic diagram of the memory mapping interface according to an embodiment of the present application;

[0077] Figure 9 Schematic diagram of the negative control terminal program trusted loading device according to an embodiment of the present application;

[0078] Figure 10 Schematic diagram of an electronic device according to an embodiment of the present application. Detailed implementation manners

[0079] To make the objectives, technical solutions, and advantages of the present application more clear and understandable, the following further elaborates on the present application in detail in combination with specific embodiments and with reference to the accompanying drawings.

[0080] It should be noted that unless otherwise defined, the technical terms or scientific terms used in the embodiments of this application should have the ordinary meanings understood by those of ordinary skill in the field to which this application belongs. The "first", "second" and similar words used in the embodiments of this application do not indicate any order, quantity or importance, but are only used to distinguish different components. Words such as "including" or "comprising" mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Words such as "connected" or "linked" are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right", etc. are only used to represent relative positional relationships, and when the absolute position of the object being described changes, the relative positional relationship may also change accordingly.

[0081] Taking the power negative control terminal as an example, first, in the loading of the eBPF mechanism program in the related technology, it depends on a software certificate (such as X.509) to bind the MAC / IP of the negative control terminal. On this basis, an attacker can forge the identity of the negative control terminal by cloning the certificate, and use the forged identity to impersonate a legitimate terminal to inject malicious load control instructions (such as the DL / T 645 protocol), resulting in the grid master station being unable to distinguish the real device identity from the access device identity, and the malicious load control instructions being misexecuted, leading to overload tripping or frequency instability. In severe cases, it may trigger cascading power outages.

[0082] Secondly, if the metadata signature key of the eBPF program is stored in the software layer (such as TPM / file system), the attacker can extract the private key through the JTAG modulation interface and use the private key to sign a malicious eBPF program (such as tampering with the IEC 61850 power metering logic). The system kernel cannot recognize the legality of the program code, resulting in the negative control terminal hiding the real power consumption data in the sampling value report.

[0083] Thirdly, the negative control terminal uses a static key to encrypt the data of the eBPF program, or relies on the MMU (Memory Management Unit) to isolate sensitive memory areas. The static key is fixed and easily extracted by DMA attacks. The data encrypted by the static key can be batch decrypted (such as stealing the feeder protection setting value). The attacker can reverse-derive the grid topology structure and then carry out a targeted attack on the relay protection system.

[0084] At the same time, the negative control terminal usually runs the linux system, and its kernel loading mechanism (insmod) and eBPF verifier (BPFverifier) lack a hardware-level trust anchor, making the above attacks spread deeply through Rootkit, ultimately threatening the overall credibility of the power monitoring and data acquisition system (SCADA).

[0085] Based on this, an embodiment of the present application provides a method for securely loading a negative control terminal program, which is applied to the Linux system and includes: sending an operation instruction to the hardware security module by using the central processing unit, establishing an encrypted channel with the hardware security module and negotiating a first session key, and generating a device fingerprint by using the hardware security module; determining the program to be loaded, intercepting the program to be loaded by using the Linux system kernel to intercept the program call entry, and transmitting the original signature of the program to be loaded to the hardware security module, and verifying the original signature by using the hardware security module; in response to the successful verification of the original signature, generating a second session key by combining the random number generated by the true random number generator of the hardware security module with the device fingerprint; calling the kernel and hardware security module interface by using the Linux system kernel, sending the sensitive data of the program to the hardware security module, encrypting the sensitive data by using the second session key, mapping the encrypted fields to an independent address space, setting access only by the hardware security module and prohibiting caching; in response to the end of the operation of the program to be loaded, erasing the second session key and the random number by using the hardware security module.

[0086] First, the relevant terms are defined as follows:

[0087] HSM (Hardware Security Module): A dedicated security chip independent of the CPU (Central Processing Unit), providing key secure storage, cryptographic operation acceleration, and physical anti-tampering functions.

[0088] Fuse area (OTP): A one-time programmable (OTP) storage area inside the chip, which cannot be modified after writing, and is usually used to store the unique identifier of the device (such as STM32UID).

[0089] eBPF (Extended Berkeley Packet Filter): A programmable framework running in the kernel state, used to efficiently process network packets or system calls.

[0090] SPI bus encryption: An encryption communication protocol based on SPI (Serial Peripheral Interface), using the CTR-DTBG (Deterministic Random Bit Generator) mode to generate a key stream and directly XOR-encrypt the transmitted data.

[0091] True Random Number Generator (TRNG): A hardware module that generates random numbers based on physical noise sources to ensure that the random numbers are unpredictable.

[0092] AES-GCM encryption: An encryption mode that combines AES block encryption and GMAC authentication, supporting the generation of an authentication tag (AuthTag) during encryption to ensure data confidentiality and integrity.

[0093] Forward Secrecy: Even if the long-term key is leaked, the historical session keys cannot be cracked, ensuring that the security of past communications does not depend on future keys.

[0094] LSM Hook (Linux Security Module Hook): A security extension mechanism for the Linux kernel that allows custom modules to intercept system calls (such as bpf_prog_load) and enforce security policies.

[0095] Security Sandbox: An isolated execution environment that restricts a program's access to system resources and prevents the spread of malicious operations.

[0096] Figure 1 The flowchart of the trusted loading method 100 for the negative control terminal program provided by the embodiments of the present application is shown. The method 100 starts from step S101, where the central processing unit is used to send an operation instruction to the hardware security module, negotiate a first session key with the hardware security module, and generate a device fingerprint using the hardware security module.

[0097] In some embodiments, using the central processing unit to send an operation instruction to the hardware security module and negotiate a first session key with the hardware security module includes:

[0098] Using the central processing unit to send an operation instruction to the hardware security module; wherein the operation instruction includes the first public key, the first private key, and the elliptic curve of the central processing unit.

[0099] In this step, after the negative control terminal is powered on, the central processing unit (CPU) sends the INIT_HSM instruction code 0xA1 through the SPI bus. This instruction code carries an ASN.1 encoded data packet that conforms to the X.690 specification, including the first public key Q_CPU, the first private key d_CPU, the elliptic curve, and a 16-byte challenge random number Nonce_term temporarily generated by the central processing unit.

[0100] After receiving the operation instruction, the hardware security module triggers the hardware security module to start a self-check program to verify the integrity of the internal firmware.

[0101] In some exemplary embodiments, the elliptic curve type declaration can be the NIST P-256 elliptic curve. The challenge random number is generated by a TRNG that conforms to the AIS-31 Class PTG.2 standard.

[0102] In some exemplary embodiments, the firmware integrity is verified based on the comparison of the RSA-3072 signature and the SHA-384 hash.

[0103] In some embodiments, the RSA-RSA-3072 signature process:

[0104] SHA-384 Hash Comparison: H_{fw} = SHA-384(FirmwareImage)

[0105] RSA-3072 Signature Verification:

[0106] DecryptedHash = Sig_{fw}^{d} \mod n

[0107] where (n, e) are the RSA public key parameters pre-set by the HSM manufacturer

[0108] Comparison Decision:

[0109] if (H_fw == DecryptedHash) {

[0110] Start the Trusted Execution Environment (TEE);

[0111] } else {

[0112] Trigger the anti-tampering fuse burning;

[0113] }

[0114] where H_fw is the firmware hash value, FirmwareImage is the firmware image, and DecryptedHash is the decrypted hash value

[0115] In the key negotiation phase between the central processing unit and the hardware security module, the Elliptic Curve Diffie-Hellman (ECDH) protocol of the elliptic curve type declaration (NISTP-256 elliptic curve) is used to generate the first session key:

[0116] Use the hardware security module to generate a second private key, and use the second private key and the elliptic curve to generate a second public key;

[0117] The hardware security module generates a temporary second private key d_HSM∈ [1, n-1], and calculates the second public key Q_HSM = d_HSM×G (G is the base point of the elliptic curve).

[0118] Generate the first session key according to the first private key, first public key, second private key and second public key;

[0119] Both parties generate a 256-bit first session key through the shared key algorithm:

[0120] K_master = SHA3-256(x(Q_HSM × d_CPU) || x(Q_CPU × d_HSM)),

[0121] Among them, x() represents taking the x coordinate of the elliptic curve point.

[0122] In some embodiments, with reference to Figure 3 as shown, generating a device fingerprint using a hardware security module includes:

[0123] S301. Using the hardware security module to extract the salt value of its own secure storage area;

[0124] The salt value is a 256-bit random string built into the hardware security module (HSM).

[0125] S302. Using the hardware security module to read the unique identity code in the fuse area;

[0126] The unique identity code is the unique chip identifier stored in the fuse area (such as the 96-bit UID_OTP of STM32).

[0127] S303. Using the hardware security module to read the hardware interface address between the hardware security module and the fuse area;

[0128] The hardware interface address between the hardware security module and the fuse area is the MAC address pre-burned in the chip.

[0129] S304. According to the salt value, unique identity code, and hardware interface address, using the hardware security module to generate a device fingerprint;

[0130] The device fingerprint is represented as:

[0131] dev_fingerprint = SHA3-256(UID_OTP || MAC_addr || Salt_HSM),

[0132] where Salt_HSM, UID_OTP, and MAC_addr represent the salt value, unique identity code, and hardware interface address respectively, || represents data concatenation, and SHA3-256 represents a standardized hashing algorithm.

[0133] SHA3-256 represents the NIST standardized hashing algorithm, which outputs a 256-bit (32-byte) digest.

[0134] In this embodiment, by combining hardware uniqueness data sources, that is, using the unique identity code in the fuse area, the hardware interface address between the hardware security module and the fuse area, and the salt value of the hardware security module's own secure storage area, an unclonable hardware fingerprint is generated to achieve a strong binding between the identity of the negative control terminal and the physical chip. This device fingerprint cannot be replicated by software or cloned by hardware. Even if an attacker tampers with the MAC address or protocol field of the negative control terminal, since the device fingerprint cannot be forged, the injected false instructions will be recognized and intercepted, thus avoiding attacks.

[0135] In some embodiments, after step S101, the central processing unit is used to transmit the root certificate chain preset in the negative control terminal to the hardware security module, and the hardware security module uses a preset hash algorithm to verify the root certificate chain and store it.

[0136] Reference Figure 2 , specifically including, S201: Use the central processing unit to split the root certificate chain of the negative control terminal into a main chain and a backup chain, and use a preset first hash algorithm and second hash algorithm to calculate the hash values of the main chain and the backup chain respectively;

[0137] In this step, the negative control terminal splits the OPC UA root certificate chain into a main chain and a classified one, and calculates the hash values respectively:

[0138] Hash_primary = SHA-256(CertChain_primary),

[0139] Hash_backup = BLAKE2s(CertChain_backup).

[0140] Among them, SHA-256 and BLAKE2s respectively represent the preset first hash algorithm and second hash algorithm.

[0141] It can be understood that the OPC UA root certificate chain is an authentication system for industrial communication to ensure secure communication between devices.

[0142] In some embodiments, asymmetric splitting is used as the splitting strategy.

[0143] Exemplarily, the root certificate chain is split into a main chain and a backup chain through the splitting strategy, where the main chain may include an entity certificate and an intermediate CA, and the backup chain includes an intermediate CA and a root CA.

[0144] After that, S202: Transmit the main chain, the backup chain and the hash values to the hardware security module.

[0145] S203: Use the first hash algorithm and the second hash algorithm preset in the hardware security module to verify the hash values of the main chain and the backup chain.

[0146] In this step, the first hash algorithm and the second hash algorithm preset in the hardware security module are used to recalculate the hash values of the main chain and the backup chain, and compare them with the hash values of the main chain and the backup chain transmitted to the hardware security module, so as to achieve security enhancement.

[0147] S204: Store the main chain in the one-time programmable area of the hardware security module.

[0148] Exemplarily, write the main chain plaintext into the EFUSE storage area. Physical anti-tampering can be achieved.

[0149] S205. Encrypt the derived key for the backup chain using the device fingerprint and store it in the authorized access area of the hardware security module.

[0150] Exemplarily, the backup chain is encrypted using AES-GCM-256, and the encrypted backup chain is stored in the reserved partition of the eMMC, with the partition address being 0x8000 - 0xFFFF, and access requires authorization from the hardware security module.

[0151] In this embodiment, through the industrial protocol dual certificate chains bound in the hardware security module, the negative control terminal needs to verify its identity through two sets of certificate chains during communication, that is, the hardware security module needs to compare and verify the hash values of the main chain and the backup chain respectively, and the verification requires authorization from the hardware security module, further realizing the uniqueness and anti-forgery ability of the negative control terminal device identity.

[0152] Through the unique data source of the hardware, that is, using the unique identity encoding in the fuse area, the hardware interface address between the hardware security module and the fuse area, and the salt value in the secure storage area of the hardware security module itself, an unclonable hardware fingerprint is generated to achieve a strong binding between the identity of the negative control terminal and the physical chip. This device fingerprint cannot be replicated by software or cloned by hardware. Further combined with the industrial protocol dual certificate chains bound in the hardware security module, the negative control terminal needs to verify its identity through two sets of certificate chains during communication, that is, the hardware security module needs to compare and verify the hash values of the main chain and the backup chain respectively, and the verification requires authorization from the hardware security module, further realizing the uniqueness and anti-forgery ability of the negative control terminal device identity.

[0153] Neither the device fingerprint nor the dual certificate chains can be replicated by software or cloned by hardware. Even if an attacker tampers with the MAC address or protocol fields of the negative control terminal, since the device fingerprint and the dual certificate chains cannot be forged, the injected false instructions will be recognized and intercepted to avoid attacks.

[0154] In step S102, determine the program to be loaded, use the linux system kernel to intercept the program call entry, intercept the program to be loaded, and transmit the original signature of the program to be loaded to the hardware security module for verification by the hardware security module.

[0155] In this step, before the kernel loads the program to be loaded, the original signature in the metadata of the program to be loaded is encrypted and sent to the hardware security module for decryption verification, and external parties cannot bypass the hardware verification process.

[0156] It should be noted that in the embodiments of the present application, the program to be loaded or the program is described by taking the eBPF program as an example.

[0157] Specifically, referring to Figure 4 , step S102 includes:

[0158] S401. Register an interception function in the kernel source code using the Linux system kernel and mount the interception function to the program call entry.

[0159] During the loading process of the program to be loaded, it is not directly loaded in the Linux system kernel. Instead, an interception function is registered in the kernel source code, and the interception function is hung on the program call entry. When the user calls the program call entry, the interception function is automatically triggered to intercept the program to be loaded, avoiding direct loading of the program, which may cause the kernel to fail to recognize the legality of the code of the program to be loaded.

[0160] In some embodiments, the program call entry can be the program call function bpf_prog_load, and the interception function is the hook function ebpf_security_hook customized by the Linux Security Module (LSM) of the Linux system kernel.

[0161] In some alternative embodiments, the interception function is to implement the ebpf_security_hook structure in the Linux system source code security / ebpf_hook.c and mount it to the bpf_prog_load program call entry.

[0162] S402. In response to the trigger of the interception function, pause the program to be loaded and extract the metadata of the program to be loaded.

[0163] In this step, pause the loading request of the program to be loaded of the current process and enter the waiting state (TASK_INTERRUPTIBLE). Parse the bpf_prog structure and extract the metadata of the program to be loaded.

[0164] S403. Encrypt the original signature in the metadata using the second private key to form a signature value, and encapsulate and send the original signature and the signature value to the hardware security module.

[0165] In some alternative embodiments, through the Elliptic Curve Digital Signature Algorithm, using the P-384 curve, the signature value includes the r and s coordinates, which is convenient for subsequent verification of the identity and integrity of the program to be loaded.

[0166] In some embodiments, send the original signature and the signature value in the metadata of the program to be loaded to the hardware security module through the DMA channel, and encrypt the whole process using the SPI bus (CTR-DRBG mode).

[0167] In some embodiments, the original signature includes the timestamp of the original signature, the second random number, and the hash value of the original signature.

[0168] Exemplarily, the original signature: Sign_Data = TS || Nonce || prog_hash

[0169] TS: 64-bit UNIX timestamp (to prevent replay attacks)

[0170] Nonce: 128-bit CTR-DRBG random number

[0171] prog_hash: SHA-256 digest of the program instruction set of the program to be loaded

[0172] ECDSA-P384 signature value (r, s coordinate pair).

[0173] The encapsulation format of the original signature and the signature value:

[0174] struct {

[0175] uint8_t nonce

[16] ; / / Random number generated by CTR-DRBG

[0176] uint32_t timestamp; / / UNIX timestamp (precision in milliseconds)

[0177] uint8_t signature

[96] ; / / ECDSA-P384 signature value (R||S format)

[0178] uint8_t prog_hash

[32] ; / / SHA-256 hash of the code segment of the program to be loaded

[0179] } __attribute__((packed)) sig_packet;

[0180] As per the above encapsulation format, the second random number is a random number generated in CTR-DRBG (Deterministic Random Bit Generator) mode.

[0181] S404. Use the second public key burned in the secure storage area by the hardware security module to compare and verify the original signature and the signature value.

[0182] In this embodiment, the second public key of the metadata of the program to be loaded is permanently burned into the secure storage area of the hardware security module. That is, for each program to be loaded, the private key must be extracted by the hardware security module during the loading process, eliminating the possibility of extracting the second public key through JTAG debugging at the software layer (such as TPM / file system), thereby maliciously signing the program to be loaded using the second public key, resulting in the Linux system kernel being unable to recognize the legality of the code of the program to be loaded. Further, before the program to be loaded is loaded, the original signed text and the signature value of the metadata need to be submitted to the hardware security module for decryption comparison and verification, and external parties cannot bypass the hardware verification process.

[0183] In some alternative embodiments, the ECDSA-P384 algorithm is used to compare the signature key, the original signed text, and the signature value.

[0184] First, receive the encapsulated package of the original signed text and the signature value, and retrieve the second public key from the secure storage area of the hardware security module. Use the second random number of the original signed text to verify the elliptic curve mathematical relationship with the signature key, and compare the signature value. Determine the identity and integrity of the original signed text through the signature value. If the comparison is successful, then use the hash value of the second public key and the hash value of the original signed text. If the match is successful, further verify the timestamp of the original signed text to prevent replay attacks.

[0185] Finally, return the status code:

[0186] 0xAC: Verification successful, allow loading;

[0187] 0xED: Verification failed or certificate expired, intercept and trigger syslog alarm.

[0188] It can be understood that the original signed text is encapsulated in the header extension area of the program to be loaded, and it itself includes a certificate issued by a trusted digital certificate authority. Similarly, the signed private key burned into the secure storage area is also pre-burned according to this certificate.

[0189] After that, in step S103, in response to successful verification of the original signed text, a second session key is generated by combining the random number generated by the true random number generator of the hardware security module with the device fingerprint.

[0190] Specifically, referring to Figure 5 , step S103 includes:

[0191] S501. Use the true random number generator (TRNG) of the hardware security module to generate a random number R.

[0192] S502. Use the hardware security module to extract the hash value of the program to be loaded;

[0193] S503. Encrypt the random number, the hash value, and the device fingerprint using the first session key to generate the second session key.

[0194] The second session key is represented as:

[0195] K_{session} = HMAC_{SHA256}(R || dev_fingerprint || prog\_hash),

[0196] where R, prog\_hash, and dev_fingerprint represent a random number, a hash value, and a device fingerprint respectively, HMAC represents the first session key inside the hardware security module, and SHA256 represents a hash algorithm.

[0197] After that, in step S104, the linux system kernel is used to call the communication interface between the kernel and the hardware security module, and the sensitive data of the program is sent to the hardware security module. The sensitive data is encrypted using the second session key, the encrypted fields are mapped to an independent address space, and only the hardware security module is set to access and caching is prohibited.

[0198] In this step, the unique second session key generated by the hardware security module is used to encrypt the sensitive data of the program to be loaded, blocking the DMA attack from stealing the plaintext.

[0199] Specifically, referring to Figure 6 Using the linux system kernel to call the communication interface between the kernel and the hardware security module, and sending the sensitive data of the program to the hardware security module, and encrypting the sensitive data using the second session key, includes:

[0200] S601. Use the linux system kernel to call the communication interface between the kernel and the hardware security module, and send the sensitive data of the program to be loaded to the said hardware security module.

[0201] In this step, the communication interface hsm_encrypt_section() between the kernel and the hardware security module is called using the kernel. Its essence is a kernel-level driver function, and the implementation details are as Figure 7 shown. The sensitive data of the program to be loaded, including the.data and.radata segments, is sent to the hardware security module through the SPI bus, and the sensitive data is encrypted using the second session key.

[0202] It can be understood that in the program to be loaded,.data contains dynamic state information (such as a network packet counter), and if it is tampered with, it may lead to statistical deception after a denial of service (DoS). The.radata contains sensitive configurations (such as filtering rules), so it needs to be encrypted and protected.

[0203] S602. Set the life cycle function of the second session key using the hardware security module and split the second session key into an encryption key and an authentication key.

[0204] In this step, the second session key \(K_{session}\) is split into:

[0205] Encryption key (DEK): The first 128 bits,

[0206] Authentication key (AK): The last 128 bits.

[0207] The life cycle of the second session key is marked as "volatile" and retained in the register of the hardware security module.

[0208] S603. Split the sensitive data into plaintext data blocks of a fixed length, and encrypt the plaintext data blocks using the encryption key to generate ciphertext.

[0209] Exemplarily, the.data and.radata segments are split according to a size of 4KB. The plaintext data blocks are encrypted using the AES-CTR mode to generate ciphertext.

[0210] S604. Determine the hash value of the ciphertext and the authentication key.

[0211] Exemplarily, in this step, the GMAC algorithm is used to calculate the hash value of the ciphertext and the authentication key.

[0212] S605. Derive a second random number using the true random generator of the hardware security module, and perform a finite field operation on the encryption key, the hash value of the ciphertext and the authentication key, and the second random number to generate an authentication tag.

[0213] The authentication tag is expressed as:

[0214] AuthTag = AES-256-GCM(Plaintext, DEK, IV, AAD=AK).

[0215] AES-256-GCM (Galois / Counter Mode) is a symmetric algorithm mode that combines encryption and authentication. Plaintext represents the plaintext data block, that is, the.data and.radata segments of 4KB. DEK is the encryption key. AAD=AK represents the authentication key. IV represents the second random number, which is a 12-byte random number.

[0216] So far, the encryption and authentication of the sensitive data in the program to be loaded are completed. After the subsequent Linux kernel continues to load the program to be loaded, the receiver of the kernel recalculates the authentication tag using the above method and compares it with the authentication tag generated by the hardware security module. If they are the same, the sensitive data of the program to be loaded has not been tampered with, and the loading and running continue. If they are different, it indicates that the sensitive data has been tampered with, or the encryption key or authentication key is incorrect, or the second random number does not match, and the program to be loaded stops being loaded.

[0217] After completing the encryption of the sensitive data in the program to be loaded, it is also necessary to protect the encrypted sensitive data to prevent cache side-channel attacks. Further, map the encrypted sensitive data to an independent address space, and set it to be accessible only by the hardware security module and prohibit caching.

[0218] Further, mapping the encrypted sensitive data to an independent address space, setting it to be accessible only by the hardware security module and prohibiting caching, includes:

[0219] Use the hardware security module to send the ciphertext and the authentication tag to the Linux system kernel.

[0220] In some exemplary embodiments, the ciphertext and the authentication tag are returned to the kernel:

[0221] struct {

[0222] uint8_t iv

[12] ; / / GCM initialization vector

[0223] uint8_t ciphertext[N]; / / Ciphertext data

[0224] uint8_t tag

[16] ; / / AuthTag

[0225] } encrypted_section;

[0226] Use the Linux system kernel to call the memory mapping interface to set the corresponding independent address space for the ciphertext and the authentication tag.

[0227] Exemplarily, map the ciphertext and the authentication tag to an independent address space through mmap_protect. It can be understood that mmap_protect is a security-enhanced memory mapping interface implemented by the kernel-level memory management subsystem. Its essence is a hardware security extended version of the traditional mmap() system call, and its key differences are compared as Figure 8 shown. The independent address space is an automatically allocated unpredictable area.

[0228] Enable the memory protection unit to perform regional isolation on the independent address space.

[0229] Enable the Memory Protection Unit (MPU) to isolate regions of the independent address space and prevent unauthorized DMA access.

[0230] Set the independent address space to disable the central processing unit cache.

[0231] By setting RW_NO_CACHE for the page table entries of the independent address space, disable the central processing unit cache to defend against side-channel attacks.

[0232] Set the independent address space to allow access only by the hardware security module.

[0233] By setting PROT_EXEC for the page table entries of the independent address space, allow access only by the hardware security module, that is, the hardware security module decryption engine decrypts dynamically during JIT compilation. In other words, to decrypt the ciphertext in the independent address space, it is necessary to call the second session key of the hardware security module for decryption to ensure the security of the ciphertext.

[0234] Thus, the linux kernel realizes the trusted loading of the program to be loaded.

[0235] Finally, in step S105, in response to the end of the program to be loaded, use the hardware security module to erase the second session key and the random number.

[0236] After the program to be loaded ends, the hardware security module actively erases the second session key and the random number. Only the ciphertext in step S104 is retained in the memory of the negative control terminal, and each time the program to be loaded is loaded, it is necessary to force the hardware security module to regenerate the second session key to achieve forward security.

[0237] Specifically, step S105 includes:

[0238] In response to the end or interruption of the program to be loaded, use the hardware security module to receive the program end instruction.

[0239] Use the hardware security module to execute the erase instruction according to the program end instruction to erase the second session key and the random number generated by the true random number generator; where the erase instruction overwrites the storage area of the second session key.

[0240] Use the linux system kernel to receive the program end instruction and clear the memory of the program to be loaded.

[0241] In this embodiment, when the program to be loaded ends or is interrupted, the following erase instruction is executed:

[0242] memset(K_session, 0xFF, 32); / / Overwrite the key storage area

[0243] hsm_flash_erase(SECTOR_KEY); / / Trigger the physical erase instruction.

[0244] By calling the specially designed secure memory cleaning function secure_memzero() in the Linux kernel, the copy of the ciphertext data is cleaned to ensure that no plaintext remains.

[0245] It should be noted that the method of the embodiment of the present application can be executed by a single device, such as a computer or a server, etc. The method of this embodiment can also be applied to a distributed scenario, and completed by multiple devices cooperating with each other. In this case of a distributed scenario, one of the multiple devices can only execute one or more steps of the method of the embodiment of the present application, and these multiple devices will interact with each other to complete the described method.

[0246] It should be noted that some embodiments of the present application have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the above embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0247] Based on the same inventive concept, corresponding to the method of any of the above embodiments, the present application further provides a trusted loading device for a negative control terminal program.

[0248] Refer to Figure 9 , the trusted loading device for the negative control terminal program includes:

[0249] A handshake module 901, configured to send an operation instruction to the hardware security module by using a central processing unit, negotiate a first session key with the hardware security module, and generate a device fingerprint by using the hardware security module;

[0250] An authentication module 902, configured to determine a program to be loaded, intercept the program call entry by using the Linux system kernel, intercept the program to be loaded, and transmit the original signature of the program to be loaded to the hardware security module for verification by the hardware security module;

[0251] A key module 903, configured to, in response to successful verification of the original signature, generate a second session key by combining a random number generated by a true random number generator of the hardware security module with the device fingerprint;

[0252] An encryption module 904, configured to utilize a Linux system kernel to call a communication interface between the kernel and a hardware security module, send sensitive data of a program to be loaded to the hardware security module, encrypt the sensitive data by using a second session key, map the encrypted sensitive data to an independent address space, and set access only by the hardware security module and prohibit caching.

[0253] An erasure module 905, configured to, in response to the end or interruption of the operation of the program to be loaded, erase the second session key and the random number by using the hardware security module.

[0254] For convenience of description, the above device is described by dividing it into various modules according to functions. Of course, when implementing the present application, the functions of each module can be implemented in one or more software and / or hardware.

[0255] The device in the above embodiment is used to implement the corresponding negative control terminal program trusted loading method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be described herein again.

[0256] Based on the same technical concept, corresponding to the method in any of the above embodiments, the present application further provides an electronic device, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, it implements the negative control terminal program trusted loading method in any of the above embodiments.

[0257] Figure 10 FIG. shows a more specific schematic diagram of the hardware structure of the electronic device provided in this embodiment. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. Among them, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other inside the device through the bus 1050.

[0258] The processor 1010 may be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0259] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store the operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0260] The input / output interface 1030 is used to connect to the input / output module to achieve information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Among them, the input devices can include keyboards, mice, touchscreens, microphones, various sensors, etc., and the output devices can include displays, speakers, vibrators, indicator lights, etc.

[0261] The communication interface 1040 is used to connect to the communication module (not shown in the figure) to achieve communication and interaction between this device and other devices. Among them, the communication module can achieve communication through wired means (such as USB, network cable, etc.) or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0262] The bus 1050 includes a path for transmitting information between various components of the device (such as the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0263] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device may also only include the components necessary for implementing the solutions of the embodiments of this specification and does not necessarily include all the components shown in the figure.

[0264] The electronic device in the above embodiment is used to implement the corresponding negative control terminal program trusted loading method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0265] Based on the same technical concept, corresponding to the method in any of the above embodiments, the present application also provides a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to make the computer execute the negative control terminal program trusted loading method described in any of the above embodiments.

[0266] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0267] The computer instructions stored in the storage medium of the above embodiment are used to cause the computer to execute the trusted loading method of the negative control terminal program as described in any one of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0268] Based on the same inventive concept, corresponding to the trusted loading method of the negative control terminal program described in any of the above embodiments, the present disclosure also provides a computer program product, which includes computer program instructions. In some embodiments, the computer program instructions can be executed by one or more processors of the computer to cause the computer and / or the processor to execute the trusted loading method of the negative control terminal program. Corresponding to the execution subjects corresponding to the steps in the respective embodiments of the trusted loading method of the negative control terminal program, the processor that executes the corresponding steps can belong to the corresponding execution subject.

[0269] The computer program product of the above embodiment is used to cause the computer and / or the processor to execute the trusted loading method of the negative control terminal program as described in any one of the above embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be elaborated here.

[0270] Those of ordinary skill in the art should understand that the discussion of any of the above embodiments is only exemplary and is not intended to imply that the scope of the present application (including the claims) is limited to these examples; under the concept of the present application, the technical features in the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of brevity.

[0271] In addition, for simplicity of explanation and discussion, and in order not to make the embodiments of the present application difficult to understand, known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Further, the devices may be shown in block diagram form in order to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that details of the implementation of these block diagram devices are highly dependent on the platform on which the embodiments of the present application are to be implemented (i.e., these details should be fully within the understanding of those skilled in the art). In cases where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present application, it will be apparent to those skilled in the art that the embodiments of the present application may be practiced without these specific details or with variations of these specific details. Accordingly, these descriptions should be considered illustrative rather than restrictive.

[0272] Although the present application has been described in connection with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those of ordinary skill in the art in light of the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0273] Embodiments of the present application are intended to cover all such alternatives, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the embodiments of the present application shall be included within the protection scope of the present application.

Claims

1. A method for loading a program in a load-controlled terminal, applied to a Linux system, characterized in that: include: Using a central processing unit to send an operation instruction to a hardware security module, negotiate a first session key with the hardware security module, and use the hardware security module to generate a device fingerprint; Determine a program to be loaded, intercept the program call entry by using the Linux system kernel, intercept the program to be loaded, and transmit the original signature of the program to be loaded to the hardware security module, and verify the original signature by using the hardware security module; In response to the signature original text verification being successful, generating a second session key using a random number generated by a true random number generator of the hardware security module in combination with the device fingerprint; Using the Linux system kernel to call the communication interface between the kernel and the hardware security module, and sending the sensitive data of the program to be loaded to the hardware security module, encrypting the sensitive data using the second session key, mapping the encrypted sensitive data to an independent address space, setting only the hardware security module to access and prohibiting caching; In response to the completion or interruption of the running of the program to be loaded, the second session key and the random number are erased by using the hardware security module.

2. The method according to claim 1, characterized in that After sending an operation instruction to the hardware security module by using the central processing unit, negotiating a first session key with the hardware security module, and generating a device fingerprint by using the hardware security module, the method further includes: Using the central processing unit to split the root certificate chain of the load control terminal into a main chain and a backup chain, and using a preset first hash algorithm and a second hash algorithm to calculate the hash values ​​of the main chain and the backup chain respectively; Transmitting the main chain, the backup chain and the hash value to the hardware security module; Verify the hash values ​​of the primary chain and the backup chain using the first hash algorithm and the second hash algorithm preset by the hardware security module; Storing the master chain in a one-time programmable area of ​​the hardware security module; The backup chain is encrypted using the device fingerprint and stored in the authorized access area of ​​the hardware security module.

3. The method according to claim 1, characterized in that Utilizing the central processing unit to send an operation instruction to the hardware security module and negotiate a first session key with the hardware security module, including: Using the central processing unit to send an operation instruction to the hardware security module; wherein the operation instruction includes a first public key, a first private key and an elliptic curve of the central processing unit; Generate a second private key using the hardware security module, and generate a second public key using the second private key and the elliptic curve; Generate the first session key according to the first private key, the first public key, the second private key and the second public key; The first session key is expressed as: K_master = SHA3-256(x(Q_HSM × d_CPU) || x(Q_CPU × d_HSM)), Among them, d_CPU, Q_CPU, d_HSM, Q_HSM represent the first private key, the first public key, the second private key and the second public key respectively, and x() represents the x-coordinate of the elliptic curve point.

4. The method according to claim 1, characterized in that: The step of generating a device fingerprint by using the hardware security module includes: Utilize the hardware security module to extract the salt value of its own security storage area; Using the hardware security module to read the unique identity code in the fuse area; Using the hardware security module to read the hardware interface address between the hardware security module and the fuse area; generating the device fingerprint using the hardware security module according to the salt value, the unique identity code and the hardware interface address; The device fingerprint is represented as: dev_fingerprint = SHA3-256(UID_OTP || MAC_addr || Salt_HSM), Among them, Salt_HSM, UID_OTP and MAC_addr represent the salt value, unique identity code and hardware interface address respectively, || represents data splicing, and SHA3-256 represents the standardized hash algorithm.

5. The method according to claim 3, characterized in that: The method of determining a program to be loaded, intercepting a program call entry by using a Linux system kernel, intercepting the program to be loaded, transmitting a signature original of the program to be loaded to the hardware security module, and verifying the signature original by using the hardware security module includes: Using the Linux system kernel to register an interception function in the kernel source code, and mounting the interception function to the program call entry; In response to the interception function being triggered, pausing the program to be loaded and extracting metadata of the program to be loaded; Encrypting the original signature in the metadata using the second private key to form a signature value, and encapsulating the original signature and the signature value and sending them to the hardware security module; The second public key burned into the secure storage area of ​​the hardware security module is used to compare and verify the original signature and the signature value.

6. The method according to claim 1, characterized in that In response to the signature original text verification being successful, a second session key is generated by combining a random number generated by a true random number generator of the hardware security module with the device fingerprint, including: Generate a random number using a true random number generator of the hardware security module; Extracting the hash value of the program to be loaded using the hardware security module; Encrypting the random number, the hash value, and the device fingerprint using the first session key to generate a second session key; The second session key is expressed as: K_{session} = HMAC_{SHA256}(R || dev_fingerprint || prog\_hash), Among them, R, prog\_hash and dev_fingerprint represent random numbers, hash values ​​and device fingerprints respectively, HMAC represents the first session key inside the hardware security module, and SHA256 represents the hash algorithm.

7. The method according to claim 1, characterized in that Using the Linux system kernel to call the communication interface between the kernel and the hardware security module, and sending the sensitive data of the program to be loaded to the hardware security module, and using the second session key to encrypt the sensitive data, including: Using the Linux system kernel to call the kernel and hardware security module interface, and sending the sensitive data of the program to be loaded to the hardware security module; Using the hardware security module, setting a lifecycle function of the second session key and splitting the second session key into an encryption key and an authentication key; Splitting the sensitive data into plaintext data blocks of fixed length, encrypting the plaintext data blocks using the encryption key, and generating ciphertext; Determining a hash value of the ciphertext and the authentication key; A second random number is derived by using the true random generator of the hardware security module, and a finite field operation is performed on the encryption key, the hash value of the ciphertext and the authentication key, and the second random number to generate an authentication tag.

8. The method according to claim 7, characterized in that The step of mapping the encrypted sensitive data to an independent address space, setting the access to the encrypted data to be limited to the hardware security module and prohibiting caching includes: Using the hardware security module to send the ciphertext and the authentication tag to the Linux system kernel; Using the Linux system kernel to call a memory mapping interface, the ciphertext and the authentication tag are set to have independent address spaces corresponding to each other; Enabling a memory protection unit to perform regional isolation on the independent address space; Setting the independent address space to disable the central processing unit cache; The independent address space is set to allow only the hardware security module to access it.

9. The method according to claim 6, characterized in that In response to the completion or interruption of the running of the program to be loaded, erasing the second session key and the random number by using the hardware security module, including: In response to the completion or interruption of the running of the program to be loaded, receiving a program end instruction by using the hardware security module; Utilizing the hardware security module to execute an erase instruction according to the program end instruction; wherein the erase instruction overwrites a storage area of ​​the second session key; Erasing the second session key and the random number generated by the true random number generator; The Linux system kernel is used to receive the program end instruction and clear the memory of the program to be loaded.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 9 is implemented.

Images