Load control terminal program trusted loading method and electronic equipment

Abstract

The invention provides a load control terminal program trusted loading method and electronic equipment, and the method comprises the steps: transmitting an operation instruction to a hardware security module through a central processing unit, negotiating a first session key with the hardware security module, and generating an equipment fingerprint through the hardware security module; intercepting a to-be-loaded program by utilizing a linux system kernel interception program calling entry, transmitting a signature original text of the to-be-loaded program to a hardware security module, and checking the signature original text by utilizing the hardware security module; if the signature original text is successfully verified, a random number generated by a true random number generator of the hardware security module is combined with the device fingerprint to generate a second session key; calling a communication interface between the kernel and the hardware security module, sending the sensitive data of the program to the hardware security module, encrypting the sensitive data by using a second session key, and mapping the encrypted sensitive data to an independent address space; and when the operation of the program is finished or interrupted, erasing the second session key and the random number by using the hardware security module.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to a method for trusted loading of a negative control terminal program and an electronic device. Background Art

[0002] In industrial control systems, load-controlled terminals are responsible for monitoring and managing power or other critical infrastructure. Traditional eBPF (Extended Berkeley Packet Filter) is a technology that allows user-mode programs to run sandbox programs in the Linux kernel. It is widely used in network monitoring and performance analysis of load-controlled terminals. However, during the program loading process, the storage of certificates and keys is easily counterfeited or attackers can directly extract private keys through physical interfaces to sign malicious eBPF programs, causing the kernel to be unable to recognize the legitimacy of the code. In addition, using static keys to encrypt memory or relying on MMU isolation, the keys are fixed for a long time and are easy to be extracted by attacks, allowing attackers to reversely deduce the network topology related to the load-controlled terminal, thereby implementing targeted attacks, etc. Summary of the invention

[0003] In view of this, the purpose of the present application is to propose a method and electronic device for trusted loading of a load control terminal program that overcomes the above-mentioned problems or at least partially solves the above-mentioned problems.

[0004] Based on the above purpose, the first aspect provided by the present application provides a method for trusted loading of a negative control terminal program, which is applied to a Linux system, comprising: 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.

[0005] Optionally, after using the central processing unit to send an operation instruction to the hardware security module, negotiating a first session key with the hardware security module, and using the hardware security module to generate a device fingerprint, 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.

[0006] Optionally, using the central processing unit to send an operation instruction to the hardware security module to negotiate a first session key with the hardware security module includes: 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.

[0007] Optionally, the 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.

[0008] Optionally, the determining of the program to be loaded, intercepting the program call entry by using the Linux system kernel, intercepting the program to be loaded, 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, 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.

[0009] Optionally, in response to the original signature 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.

[0010] Optionally, 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 encrypting the sensitive data using the second session key, 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; The second random number is derived by using the true random generator of the hardware security module, and the encryption key, the The ciphertext, the hash value of the authentication key and the second random number are subjected to a finite field operation to generate an authentication tag.

[0011] Optionally, mapping the encrypted sensitive data to an independent address space, setting access to the encrypted data only by 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 central processing unit cache; The independent address space is set to allow only the hardware security module to access it.

[0012] Optionally, 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 includes: 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.

[0013] According to a second aspect of the present application, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the first aspect when executing the computer program.

[0014] From the above, it can be seen that the trusted loading method and electronic device of the negative control terminal program provided by the present application utilize the hardware-level physical unclonable device fingerprint generated by the hardware security module. The fingerprint cannot be copied by software or cloned by hardware. In conjunction with the pre-setting of the main chain and backup chain of the industrial protocol root certificate in the secure storage area of ​​the hardware security module, the unique data source of the hardware, that is, the unique identity code of 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, generates an unclonable device fingerprint, realizes the strong binding of the negative control terminal's identity to the physical chip, and the device fingerprint cannot be copied 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 compare and verify the hash values ​​of the main chain and the backup chain respectively, and the verification needs to be authorized by the hardware security module, so as to further realize the uniqueness and anti-counterfeiting capability of the negative control terminal device identity.

[0015] It further intercepts the program before it is loaded, and uses the hardware security module to submit the original signature of the metadata of the program to be loaded to the hardware security module for decryption verification. The verification process is completely completed in the hardware (hardware security module), and the hardware verification process cannot be bypassed from the outside, preventing attackers from maliciously signing the program to be loaded through the debugging interface or memory scanning.

[0016] A dynamic and one-time second session key is generated based on a random number, the hash value of the program to be loaded, and the device fingerprint to prevent the encrypted data from being decrypted in batches due to key leakage. Attackers can reversely deduce the grid topology and then carry out targeted attacks on the precision relay protection system.

[0017] By encrypting and authenticating the sensitive data of the program to be loaded, performance loss is reduced, resource waste is avoided, the encrypted sensitive data is mapped to an independent address space, and only the hardware security module is set to access and cache is prohibited. Hardware-level memory protection is achieved.

[0018] Finally, when the loading of the program to be loaded is completed or interrupted, the second session key and the random number are erased to ensure that historical or future data cannot be decrypted even if the second session key is leaked.

[0019] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the technical solutions in the present application or related technologies, the drawings required for use in the embodiments or related technical descriptions are briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0021] Figure 1 This is a flow chart of a method 100 for loading a program in a negative control terminal in accordance with an embodiment of the present application; Figure 2 This is a flowchart of using double chain verification in an embodiment of the present application; Figure 3 A flow chart of generating device fingerprints according to an embodiment of the present application; Figure 4 This is a flow chart of verifying the original signature in an embodiment of the present application; Figure 5 A flow chart of generating a second session key according to an embodiment of the present application; Figure 6 A flowchart of encrypting a program to be loaded according to an embodiment of the present application; Figure 7 A schematic diagram of the communication interface between the kernel and the hardware security module of an embodiment of the present application; Figure 8 A schematic diagram of a memory mapping interface according to an embodiment of the present application; Fig. 9 This is a schematic diagram of a trusted loading device for a negative control terminal program according to an embodiment of the present application; Fig.10 A schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0022] In order to make the objectives, technical solutions and advantages of the present application more clearly understood, the present application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0023] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should be the usual meanings understood by people with ordinary skills in the field to which the present application belongs. The "first", "second" and similar words used in the embodiments of the present application do not represent any order, quantity or importance, but are only used to distinguish different components. "Including" or "comprising" and similar words mean that the elements or objects appearing in front of the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0024] Taking the power load control terminal as an example, first of all, the eBPF mechanism program of the relevant technology relies on software certificates (such as X.509) to bind the MAC / IP of the load control terminal during program loading. On this basis, the attacker can forge the identity of the load control terminal by cloning the certificate, and use the forged identity to impersonate the legitimate terminal to inject malicious load control instructions (such as DL / T 645 protocol), causing the power grid master station to be unable to distinguish between the real device identity and the access device identity, and the malicious load control instructions are mistakenly executed, resulting in overload tripping or frequency instability, which may trigger cascading power outages in severe cases.

[0025] Secondly, if the metadata signing 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 the malicious eBPF program (such as tampering with the IEC 61850 electricity metering logic). The system kernel cannot recognize the legitimacy of the program code, causing the load control terminal to hide the real power consumption data in the sampled value reporting.

[0026] Third, the load control terminal uses static keys to encrypt the data of the eBPF program, or relies on the MMU (memory management unit) to isolate sensitive memory areas. The static keys are fixed and can be easily extracted by DMA attacks. The data encrypted by the static keys can be decrypted in batches (such as stealing feeder protection settings). Attackers can reversely infer the grid topology and implement precise targeted attacks on the relay protection system.

[0027] At the same time, the load control terminal usually runs the Linux system, and its kernel loading mechanism (insmod) and eBPF verifier (BPFverifier) ​​lack hardware-level trust anchors, allowing the above-mentioned attacks to penetrate deeply into the mainstream through the Rootkit, ultimately threatening the overall credibility of the power monitoring and data acquisition system (SCADA).

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

[0029] First, let’s define the relevant terms: HSM (Hardware Security Module): A dedicated security chip independent of the CPU (Central Processing Unit) that provides key security storage, cryptographic operation acceleration, and physical tamper-proofing functions.

[0030] Fuse area (OTP): One-Time Programmable 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).

[0031] eBPF (Extended Berkeley Packet Filter): A programmable framework that runs in kernel mode for efficient processing of network packets or system calls.

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

[0033] True Random Number Generator (TRNG): A hardware module that generates random numbers based on a physical noise source, ensuring that the random numbers are unpredictable.

[0034] AES-GCM encryption: An encryption mode that combines AES block encryption with GMAC authentication. It supports encryption and simultaneous generation of authentication tags (AuthTag) to ensure data confidentiality and integrity.

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

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

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

[0038] Figure 1 A flowchart of a negative control terminal program trusted loading method 100 provided in an embodiment of the present application is shown. The method 100 starts at step S101, 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 using the hardware security module to generate a device fingerprint.

[0039] In some embodiments, using a central processing unit to send an operation instruction to a hardware security module to negotiate a first session key with the hardware security module includes: Sending an operation instruction to the hardware security module using a central processing unit; wherein the operation instruction includes a first public key, a first private key and an elliptic curve of the central processing unit; In this step, after the load control terminal is powered on, the central processing unit (CPU) sends the INIT_HSM instruction code 0xA1 through the SPI bus. The instruction code carries an ASN.1 encoded data packet that complies with the X.690 specification, including the first public key Q_CPU, the first private key d_CPU and the elliptic curve temporarily generated by the central processing unit, and a 16-byte challenge random number Nonce_term.

[0040] After receiving the operation instruction, the hardware security module is triggered to start the self-test program to verify the integrity of the internal firmware.

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

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

[0043] In some embodiments, the RSA-RSA-3072 signature process: SHA-384 hash comparison: H_{fw} = SHA-384(FirmwareImage) RSA-3072 Signature Verification: DecryptedHash = Sig_{fw}^{d} \mod n Where (n, e) are the RSA public key parameters preset by the HSM manufacturer Comparison verdict: if (H_fw == DecryptedHash) { Start the Trusted Execution Environment (TEE); } else { Trigger tamper-proof fuse burning; }.

[0044] Among them, H_fw is the firmware hash value, FirmwareImage is the firmware image, and DecryptedHash is the decrypted hash value.

[0045] During the key negotiation phase between the central processing unit and the hardware security module, the first session key is generated using the Elliptic Curve Type Declaration (NISTP-256 Elliptic Curve) Diffie-Hellman (ECDH) protocol: 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; 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).

[0046] 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 two parties generate a 256-bit first session key through a shared key algorithm: K_master = SHA3-256(x(Q_HSM × d_CPU) || x(Q_CPU × d_HSM)), Among them, x() represents the x coordinate of the elliptic curve point.

[0047] In some embodiments, reference Figure 3 As shown, the hardware security module is used to generate a device fingerprint, including: S301, using the hardware security module to extract the salt value of its own security storage area; The salt value is a 256-bit random string built into the hardware security module (HSM).

[0048] S302, using the hardware security module to read the unique identity code in the fuse area; The unique identity code is the unique identifier of the chip stored in the fuse area (such as the 96-bit UID_OTP of STM32).

[0049] S303, using the hardware security module to read the hardware interface address between the hardware security module and the fuse area; The hardware interface address between the hardware security module and the fuse area is the MAC address pre-burned in the chip.

[0050] S304, generating a device fingerprint using a 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.

[0051] SHA3-256 represents a NIST standardized hash algorithm that outputs a 256-bit (32-byte) digest.

[0052] In this embodiment, the hardware uniqueness data source is combined, that is, the unique identity code of 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 are used to generate an unclonable hardware fingerprint, thereby achieving a strong binding between the identity of the negative control terminal and the physical chip. The device fingerprint cannot be copied by software or cloned by hardware. Even if an attacker tampers with the MAC address or protocol field of the negative control terminal, the device fingerprint cannot be forged, and the injected false instructions will be identified and intercepted to avoid the attack.

[0053] In some embodiments, after step S101, the central processing unit is used to transmit the root certificate chain preset by the negative control terminal to the hardware security module, and the hardware security module verifies the root certificate chain using a preset hash algorithm and stores it.

[0054] refer to Figure 2 , specifically including, S201, using a central processing unit to split the root certificate chain of the load control terminal into a primary chain and a backup chain, and using a preset first hash algorithm and a second hash algorithm to calculate the hash values ​​of the primary chain and the backup chain respectively; In this step, the load control terminal splits the OPC UA root certificate chain into the main chain and the classified chain, and calculates the hash value for each: Hash_primary = SHA-256(CertChain_primary), Hash_backup = BLAKE2s(CertChain_backup).

[0055] Wherein SHA-256 and BLAKE2s represent the preset first hash algorithm and second hash algorithm respectively.

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

[0057] In some embodiments, asymmetric splitting is utilized as the splitting strategy.

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

[0059] Afterwards, S202, the main chain, backup chain and hash value are transmitted to the hardware security module.

[0060] S203: Use the first hash algorithm and the second hash algorithm preset by the hardware security module to verify the hash values ​​of the primary chain and the backup chain.

[0061] In this step, the hash values ​​of the primary chain and the backup chain are recalculated using the first hash algorithm and the second hash algorithm preset in the hardware security module, and compared with the hash values ​​of the primary chain and the backup chain transmitted to the hardware security module, thereby achieving security enhancement.

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

[0063] For example, the main chain is written in plain text into the EFUSE storage area to achieve physical tamper-proof.

[0064] S205: derive a key from the backup chain using the device fingerprint and encrypt it and store it in the authorized access area of ​​the hardware security module.

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

[0066] In this embodiment, the industrial protocol dual certificate chain is bound to 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 must be authorized by the hardware security module, so as to further realize the uniqueness and anti-counterfeiting capability of the negative control terminal device identity.

[0067] Through the unique data source of hardware, that is, using the unique identity code of 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. The device fingerprint cannot be copied 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 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 must be authorized by the hardware security module, further realizing the uniqueness and anti-counterfeiting capability of the negative control terminal device identity.

[0068] Neither the device fingerprint nor the dual certificate chain can be copied through software or cloned through hardware. Even if an attacker tampers with the MAC address or protocol field of the negative control terminal, since the device fingerprint and dual certificate chain cannot be forged, the injected false instructions will be identified and intercepted to avoid the attack.

[0069] In step S102, the program to be loaded is determined, the program call entry is intercepted by the Linux system kernel, the program to be loaded is intercepted, and the signature original of the program to be loaded is transmitted to the hardware security module, and the signature original is verified by the hardware security module.

[0070] 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 the hardware verification process cannot be bypassed by the outside.

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

[0072] Specifically, refer to Figure 4 , step S102 includes: S401, 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.

[0073] During the loading process of the program to be loaded, it is not loaded directly into the Linux system kernel, but an interception function is registered in the kernel source code. The interception function is hung at 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 causes the kernel to be unable to recognize the legitimacy of the program code to be loaded.

[0074] In some embodiments, the program call entry may be a program call function bpf_prog_load, and the interception function may be a hook function ebpf_security_hook defined by a Linux system kernel security module (Linux Security Module, LSM).

[0075] In some optional 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.

[0076] S402: In response to the interception function being triggered, pausing the program to be loaded and extracting metadata of the program to be loaded.

[0077] In this step, the loading request of the program to be loaded in the current process is suspended and the system enters the waiting state (TASK_INTERRUPTIBLE). The bpf_prog structure is parsed to extract the metadata of the program to be loaded.

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

[0079] In some optional embodiments, an elliptic curve digital signature algorithm is used with the P-384 curve, and the signature value includes r and s coordinates, which facilitates subsequent verification of the identity and integrity of the program to be loaded.

[0080] In some embodiments, the signature original and signature value in the metadata of the program to be loaded are transmitted to the hardware security module through the DMA channel, and the entire process is encrypted using the SPI bus (CTR-DRBG mode).

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

[0082] For example, the original signature: Sign_Data = TS || Nonce || prog_hash TS: 64-bit UNIX timestamp (anti-replay attack) Nonce: 128-bit CTR-DRBG random number prog_hash: SHA-256 summary of the program instruction set to be loaded ECDSA-P384 signature value (r, s coordinate pair).

[0083] The encapsulation format of the signature original and signature value: struct { uint8_t nonce

[16] ; / / Random number generated by CTR-DRBG uint32_t timestamp; / / UNIX timestamp (millisecond precision) uint8_t signature

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

[32] ; / / SHA-256 hash of the program code segment to be loaded } __attribute__((packed)) sig_packet.

[0084] As in the above encapsulation format, the second random number is a random number generated in the CTR-DRBG (deterministic random bit generator) mode.

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

[0086] 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, each program to be loaded must pass through the hardware security module to extract the private key during the loading process, eliminating the possibility of extracting the second public key through the software layer (such as TPM / file system) through JTAG debugging, thereby using the second public key to maliciously sign the program to be loaded, resulting in the Linux system kernel being unable to recognize the legitimacy of the program code to be loaded. Furthermore, before the program to be loaded is loaded, the original signature and signature value of the metadata need to be submitted to the hardware security module for decryption comparison and verification, and the hardware verification process cannot be bypassed externally.

[0087] In some optional embodiments, the ECDSA-P384 algorithm is used to compare the signature key, the signature original and the signature value.

[0088] First, the package of the original signature and the signature value is received, and the second public key is taken out from the secure storage area of ​​the hardware security module. The second random number of the original signature is used to verify the mathematical relationship of the elliptic curve with the signature key, and the signature value is compared. The identity and integrity of the original signature are determined by the signature value. If the comparison is successful, the hash value of the second public key and the hash value of the original signature are used. If the match is successful, the timestamp of the original signature is further verified to prevent replay attacks.

[0089] Finally, the status code is returned: 0xAC: Verification successful, loading allowed; 0xED: Verification fails or the certificate expires, interception is performed and a syslog alarm is triggered.

[0090] It is understandable that the original signature is encapsulated in the header extension area of ​​the program to be loaded, which itself includes a certificate issued by a trusted digital certificate authority. Similarly, the signature private key burned into the secure storage area is also pre-burned according to the certificate.

[0091] Afterwards, in step S103, in response to successful verification of the original signature, a second session key is generated using a random number generated by a true random number generator of the hardware security module in combination with the device fingerprint.

[0092] Specifically, refer to Figure 5 , step S103 includes: S501 . Generate a random number R using a true random number generator (TRNG) of a hardware security module.

[0093] S502, extracting a hash value of the program to be loaded using a hardware security module; S503: Use the first session key to encrypt the random number, the hash value, and the device fingerprint to generate a second session key.

[0094] 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.

[0095] Then 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 field is mapped to an independent address space, and only the hardware security module is set to access and caching is prohibited.

[0096] 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, thereby blocking the DMA attack from stealing the plain text.

[0097] Specifically, refer 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, using the second session key to encrypt the sensitive data, including: S601, 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.

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

[0099] Understandably, in the program to be loaded, .data contains dynamic state information (such as network packet counters), which may cause denial of service (DoS) and statistical fraud if tampered with. .radata contains sensitive configuration (such as filtering rules), so it needs to be encrypted and protected.

[0100] S602: Use the hardware security module to set a lifecycle function of the second session key and split the second session key into an encryption key and an authentication key.

[0101] In this step, the second session key K_{session} is split into: Encryption key (DEK): first 128 bits, Authentication key (AK): the last 128 bits.

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

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

[0104] For example, the .data and .radata segments are split into 4KB blocks. The plaintext data blocks are encrypted in AES-CTR mode to generate ciphertext.

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

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

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

[0108] The authentication tag is represented as: AuthTag = AES-256-GCM(Plaintext, DEK, IV, AAD=AK).

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

[0110] At this point, the encryption and authentication of the sensitive data in the program to be loaded is completed. After the Linux kernel continues to load the program to be loaded, the receiver of the kernel uses the above method to recalculate the authentication tag and compare it with the authentication tag generated by the hardware security module. If they are consistent, the sensitive data of the program to be loaded has not been tampered with, and the loading and running continues. If they are inconsistent, it means that the sensitive data has been tampered with or the encryption key or authentication key is wrong or the second random number does not match, and the loading of the program to be loaded is stopped.

[0111] After completing the encryption of the sensitive data of the program to be loaded, the encrypted sensitive data must be protected to prevent cache side channel attacks. The encrypted sensitive data is further mapped to an independent address space, and only the hardware security module is set to access and cache is prohibited.

[0112] Furthermore, the encrypted sensitive data is mapped to an independent address space, and only the hardware security module is set to access it and cache is prohibited, including: The hardware security module is used to send the ciphertext and the authentication tag to the Linux system kernel.

[0113] In some exemplary embodiments, the ciphertext and authentication tag are returned to the kernel: struct { uint8_t iv

[12] ; / / GCM initialization vector uint8_t ciphertext[N] ; / / ciphertext data uint8_t tag

[16] ; / / AuthTag } encrypted_section.

[0114] The Linux system kernel is used to call a memory mapping interface to set independent address spaces for the ciphertext and the authentication tag.

[0115] Exemplarily, the ciphertext and authentication tag are mapped to independent address spaces 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 extension version of the traditional mmap() system call. The key differences are as follows: Figure 8As shown. Independent address spaces are automatically allocated unpredictable areas.

[0116] A memory protection unit is enabled to perform regional isolation on the independent address space.

[0117] Enable the Memory Protection Unit (MPU) to isolate independent address spaces and prevent unauthorized DMA access.

[0118] Setting the independent address space disables the central processing unit cache.

[0119] By setting RW_NO_CACHE for the page table entries of independent address spaces, the CPU cache is disabled to defend against side channel attacks.

[0120] The independent address space is set to allow only the hardware security module to access it.

[0121] By setting PROT_EXEC for the page table entry of the independent address space, only the hardware security module is allowed to access it, that is, the hardware security module decryption engine dynamically decrypts during JIT compilation. In other words, if you want to decrypt the ciphertext in the independent address space, you need to call the second session key of the hardware security module to decrypt it to ensure the security of the ciphertext.

[0122] At this point, the Linux kernel implements trusted loading of programs to be loaded.

[0123] Finally, in step S105, in response to the completion of the execution of the program to be loaded, the second session key and the random number are erased using the hardware security module.

[0124] After the loading program is completed, the hardware security module actively erases the second session key and the random number, and only the ciphertext in step S104 is retained in the memory of the negative control terminal. Each time the loading program is loaded, the second session key must be forcibly regenerated through the hardware security module to achieve forward security.

[0125] Specifically, step S105 includes: In response to the completion or interruption of the running of the program to be loaded, a program end instruction is received by utilizing the hardware security module.

[0126] The hardware security module executes an 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; wherein the erase instruction covers the storage area of ​​the second session key.

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

[0128] In this embodiment, when the loading program is finished or interrupted, the erase instruction is executed as follows: memset(K_session, 0xFF, 32); / / Overwrite the key storage area, hsm_flash_erase(SECTOR_KEY); / / Trigger physical erase instruction.

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

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

[0131] It should be noted that the above describes some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the above embodiments and still achieve the desired results. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0132] Based on the same technical concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides a trusted loading device for a negative control terminal program.

[0133] refer to Fig. 9 , the negative control terminal program trusted loading device comprises: The handshake module 901 is used to send an operation instruction to the hardware security module using the central processing unit, negotiate a first session key with the hardware security module, and generate a device fingerprint using the hardware security module; Verification module 902, used to determine the 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; The key module 903 is used to generate a second session key by combining a random number generated by a true random number generator of the hardware security module with a device fingerprint in response to successful verification of the original signature; The encryption module 904 is used to 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, encrypt the sensitive data using the second session key, map the encrypted sensitive data to an independent address space, set it to be accessible only to the hardware security module and prohibit caching; The erasing module 905 is used to erase the second session key and the random number using the hardware security module in response to the completion or interruption of the running of the program to be loaded.

[0134] For the convenience of description, the above device is described in terms of functions divided into various modules. Of course, when implementing the present application, the functions of each module can be implemented in the same or multiple software and / or hardware.

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

[0136] Based on the same technical concept, corresponding to any of the above-mentioned embodiment methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the negative control terminal program trusted loading method described in any of the above embodiments is implemented.

[0137] Fig.10 A more specific schematic diagram of the hardware structure of an electronic device provided in this embodiment is shown, and the device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are connected to each other through the bus 1050 in the device.

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

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

[0140] The input / output interface 1030 is used to connect the input / output module to realize information input and output. The input / output module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, an indicator light, etc.

[0141] The communication interface 1040 is used to connect a communication module (not shown) to realize communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0142] The bus 1050 includes a path that transmits information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0143] 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, it can be understood by those skilled in the art that the above device may also only include the components necessary for implementing the embodiments of the present specification, and does not necessarily include all the components shown in the figure.

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

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

[0146] 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. Information can be computer-readable instructions, data structures, modules of programs, 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 technology, read-only compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

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

[0148] 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 a computer so that the computer and / or the processor execute the trusted loading method of the negative control terminal program. Corresponding to the execution subject corresponding to each step in each embodiment of the trusted loading method of the negative control terminal program, the processor that executes the corresponding step can belong to the corresponding execution subject.

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

[0150] A person skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application (including the claims) is limited to these examples. In line with the concept of the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0151] In addition, to simplify the description and discussion, and in order not to make the embodiments of the present application difficult to understand, the known power / ground connections to the integrated circuit (IC) chip and other components may or may not be shown in the provided drawings. In addition, the device may be shown in the form of a block diagram to avoid making the embodiments of the present application difficult to understand, and this also takes into account the fact that the 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 (that is, these details should be fully within the scope of understanding of those skilled in the art). Where specific details (e.g., circuits) are set forth to describe exemplary embodiments of the present application, it is obvious to those skilled in the art that the embodiments of the present application can be implemented without these specific details or with changes in these specific details. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0152] Although the present application has been described in conjunction with specific embodiments of the present application, many alternatives, modifications and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may use the discussed embodiments.

[0153] The embodiments of the present application are intended to cover all such substitutions, 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 principles of the embodiments of the present application should be included in the scope of protection 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