An algorithm encryption processing method, device, equipment and medium

Abstract

The application provides a processing method, device and equipment for algorithm encryption and a medium, comprising: obtaining an algorithm library; integrating the algorithm library into an execution environment, extracting a corresponding specific offset section to obtain trusted offset data and general offset data, and performing zero processing on the extracted position; respectively encrypting the trusted offset data and the general offset data to obtain trusted encrypted offset data and general encrypted offset data; adding the trusted encrypted offset data into a trusted file to generate a joint trusted file, and adding the general encrypted offset data into a general file to generate a joint general file; downloading a key, an initialization vector, the joint trusted file and the joint general file, and verifying a running environment; and respectively decrypting the joint trusted file and the joint general file according to the key and the initialization vector. The application prevents algorithm leakage.

Description

Technical Field

[0001] This invention relates to the field of encryption technology, and in particular to a processing method, apparatus, device, and medium for algorithm encryption. Background Technology

[0002] Electronic devices require the execution of various algorithms during use. These algorithms are typically provided by algorithm vendors who supply algorithm libraries to product owners. The corresponding algorithms are then downloaded to the hardware of the electronic device to achieve a specific function.

[0003] During the algorithm download process, because the algorithm is in plaintext and the hardware of electronic devices can be arbitrarily downloaded by other small systems (hack programs) to steal the algorithm, and because the peripheral interfaces of electronic devices can be illegally attacked, the algorithm may be leaked. How to protect the algorithm has become an urgent problem to be solved. Summary of the Invention

[0004] The purpose of this invention is to provide a method, apparatus, device, and medium for algorithm encryption to prevent algorithm leakage.

[0005] To solve the above-mentioned technical problems, the present invention is achieved through the following technical solution: This invention provides a method for algorithm encryption, comprising: Obtain an algorithm library, wherein the algorithm library includes a trusted algorithm library and a general algorithm library; The algorithm library is integrated into the corresponding execution environment, and specific offset segments are extracted to obtain reliable offset data and general offset data. The extracted positions are then zeroed out. Obtain the key and initialization vector, and encrypt the trusted offset data and the general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data; The trusted encrypted offset data is added to the trusted file and replaced at the position where it is set to zero to generate a joint trusted file. The general encrypted offset data is added to the general file and replaced at the position where it is set to zero to generate a joint general file. The key, the initialization vector, the joint trusted file, and the joint general file are downloaded to the electronic device, and the operating environment of the electronic device is verified to ensure the security of the operating environment. The joint trusted file and the joint general file are decrypted according to the key and the initialization vector, respectively, so as to save the generated decrypted data in the corresponding execution environment.

[0006] In one embodiment of the present invention, the steps of integrating the algorithm library into the corresponding execution environment, extracting the corresponding specific offset segment to obtain reliable offset data and general offset data, and setting the extracted positions to zero include: The trusted algorithm library is integrated into the security domain of the trusted execution environment to obtain the corresponding trusted files; The general algorithm library is integrated into the non-secure domain of the general execution environment to obtain the corresponding general files; Extract specific offset segments containing trusted algorithm libraries from the trusted file to generate trusted offset data; Extract specific offset segments containing a general algorithm library from the general file to generate general offset data; The positions of the data extracted from the trusted file and the general file are set to zero.

[0007] In one embodiment of the present invention, the steps of downloading the key, the initialization vector, the joint trusted file, and the joint universal file to the electronic device, and performing signature verification processing on the operating environment of the electronic device to ensure the security of the operating environment include: The joint trusted file and the joint general file are signed, and the key, the initialization vector, the joint trusted file, and the joint general file are downloaded to the memory of the electronic device and locked. The read-only memory of the electronic device is subjected to signature verification processing to obtain the signature verification result; When the read-only memory passes the signature verification, the bootloader of the electronic device is subjected to signature verification processing to obtain the signature verification result; When the bootloader passes the signature verification, it performs signature verification on the security domain of the trusted execution environment of the electronic device, obtains the signature verification result, and performs initialization processing on the general execution environment.

[0008] In one embodiment of the present invention, the step of performing signature verification processing on the read-only memory of the electronic device and obtaining the signature verification result includes: Check whether a specific bit of the one-time programmable memory is set. If the specific bit is set, execute the secure boot process; if the specific bit is not set, wait. The contents of the one-time programmable memory are checked to obtain the signature algorithm; the memory is checked to obtain the public key; the signature code length of the jump program is checked; and signature verification is performed. The system determines whether the signature verification is successful. If the signature verification is successful, the system performs signature verification on the bootloader program of the electronic device. If the signature verification fails, the system waits.

[0009] In one embodiment of the present invention, the step of performing signature verification on the bootloader of the electronic device and obtaining the signature verification result when the read-only memory passes the signature verification includes: The bootloader is checked to determine whether to jump to the next level program. If the next level program is not jumped to, the processor runs the bootloader. If the next level program is jumped to, the contents of the one-time programmable memory are checked to obtain the signature algorithm, the memory is checked to obtain the public key, the signature code length of the jump program is checked, and signature verification is performed. The system determines whether the signature verification passes. If the signature verification passes, the system performs signature verification on the security domain of the trusted execution environment of the electronic device. If the signature verification fails, the system waits.

[0010] In one embodiment of the present invention, the step of performing signature verification on the security domain of the trusted execution environment of the electronic device and obtaining the signature verification result to initialize the general execution environment when the bootloader signature verification is successful includes: The system configuration initialization process is performed on the security domain of the trusted execution environment of the electronic device; The contents of the one-time programmable memory are examined to obtain the signature algorithm; the memory is examined to obtain the public key; the signature code length of the jump program is checked; and signature verification is performed. The system determines whether the signature verification is successful. If the signature verification is successful, the system initializes the general execution environment of the electronic device. If the signature verification fails, the system waits.

[0011] In one embodiment of the present invention, the step of decrypting the joint trusted file and the joint general file according to the key and the initialization vector respectively, and saving the generated decrypted data in the corresponding execution environment includes: The trusted encryption offset data in the joint trusted file is decrypted according to the key and the initialization vector to generate trusted decryption offset data, which is then stored in a specific random access memory in the trusted execution environment. The general encrypted offset data in the joint general file is decrypted according to the key and the initialization vector to generate general decryption offset data, which is then stored in a random access memory segment of the general execution environment.

[0012] The present invention also provides an algorithm encryption processing device, comprising: An algorithm acquisition module is used to acquire an algorithm library, wherein the algorithm library includes a trusted algorithm library and a general algorithm library; The algorithm integration module is used to integrate the algorithm library into the corresponding execution environment, extract the corresponding specific offset segments to obtain reliable offset data and general offset data, and set the extracted positions to zero. The algorithm encryption module is used to obtain the key and the initialization vector, and to encrypt the trusted offset data and the general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data. The replacement module is used to add the trusted encrypted offset data to the trusted file and replace it at the position that has been zeroed to generate a joint trusted file, and to add the general encrypted offset data to the general file and replace it at the position that has been zeroed to generate a joint general file. The signature verification module is used to download the key, the initialization vector, the joint trusted file, and the joint universal file to the electronic device, and to perform signature verification processing on the operating environment of the electronic device to ensure the security of the operating environment; and The storage module is used to decrypt the joint trusted file and the joint general file according to the key and the initialization vector, respectively, so as to save the generated decrypted data in the corresponding execution environment.

[0013] The present invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the processing method for the algorithm encryption.

[0014] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the algorithm encryption processing method.

[0015] As described above, this invention provides a method, apparatus, device, and medium for algorithm encryption. By encrypting and decrypting the algorithm, it ensures that the algorithm can only run on the corresponding electronic device hardware. Since the algorithm itself contains secure boot information, it must pass verification at the next level before proceeding to the next stage. Simultaneously, the encryption and decryption of the algorithm ensures that even if the algorithm is leaked, it cannot be disassembled and cracked, effectively improving security. Furthermore, the cracked plaintext algorithm will only exist in RAM, preventing leakage. Finally, secure boot ensures the correspondence between the algorithm and the electronic product hardware, and the key and initialization vector will not be leaked.

[0016] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of an algorithm encryption processing method according to an embodiment of the present invention; Figure 2 for Figure 1 Flowchart of step S20; Figure 3 for Figure 1 Flowchart of step S50; Figure 4 for Figure 3 Flowchart of step S52; Figure 5 for Figure 4 Flowchart of step S521; Figure 6 for Figure 4 Flowchart of step S522; Figure 7 for Figure 4 Flowchart of step S523; Figure 8 for Figure 1 Flowchart of step S60; Figure 9 This is a schematic diagram of a processing device for algorithm encryption in one embodiment of the present invention.

[0019] In the diagram: 100, Algorithm Acquisition Module; 200, Algorithm Integration Module; 300, Algorithm Encryption Module; 400, Substitution Module; 500, Signature Verification Module; 600, Storage Module. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please see Figure 1 This invention provides a method for encrypting algorithms, which can be applied to encrypt algorithms downloaded into the hardware of electronic devices to prevent algorithm leakage. The method may include the following steps: Step S10: Obtain the algorithm library, which includes a trusted algorithm library and a general algorithm library; Step S20: Integrate the algorithm library into the corresponding execution environment, extract the corresponding specific offset segment to obtain reliable offset data and general offset data, and set the extracted position to zero. Step S30: Obtain the key and initialization vector, and encrypt the trusted offset data and the general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data. Step S40: Add trusted encrypted offset data to the trusted file and replace it with the position that has been zeroed to generate a joint trusted file. Add general encrypted offset data to the general file and replace it with the position that has been zeroed to generate a joint general file. Step S50: Download the key, initialization vector, joint trusted file and joint general file to the electronic device, and perform signature verification on the operating environment of the electronic device to ensure the security of the operating environment; Step S60: Decrypt the joint trusted file and the joint general file according to the key and initialization vector respectively, so as to save the generated decrypted data in the corresponding execution environment.

[0022] In one embodiment of the present invention, when performing step S10, specifically when algorithm encryption is required, the corresponding algorithm library (algo_lib.a) can be obtained from the algorithm provider. An algorithm library is typically a set of compiled code, including algorithms required to perform specific tasks (e.g., data processing, computation, etc.). These libraries can be provided as static libraries, where the ".a" extension may refer to a static library file for a UNIX-like operating system. Developers can link the algorithm library into their applications, thereby reusing the functionality of the algorithm library without rewriting code. The algorithm library may include a trusted algorithm library (tee_algo_lib.a) and a general-purpose algorithm library (ree_algo_lib.a).

[0023] In one embodiment of the present invention, a trusted algorithm library refers to an algorithm running in a Trusted Execution Environment (TEE). A Trusted Execution Environment is a secure area of ​​the processor (CPU) of an electronic device, where data and code segments are protected from the System-on-Chip (SoC) and cannot be explored or accessed by unauthorized programs, thus preventing attacks or intrusions by other parts of the operating system.

[0024] In one embodiment of the present invention, a general-purpose algorithm library refers to an algorithm running in a Rich Execution Environment (REE). The concept of a Rich Execution Environment corresponds to that of a Trusted Execution Environment (TEE), in which data and code segments are not protected by a System-on-Chip (SOC) and can be explored and accessed without authentication or authorization. Code running in a Rich Execution Environment typically does not possess the security guarantees provided by the TEE.

[0025] Please see Figure 2 In one embodiment of the present invention, when performing step S20, step S20 may specifically include the following steps: Step S21: Integrate the trusted algorithm library into the software of the secure domain of the trusted execution environment to obtain the corresponding trusted file (tee.bin), and integrate the general algorithm library into the software of the non-secure domain of the general execution environment to obtain the corresponding general file (ree.bin). Step S22: Extract a specific offset segment containing the trusted algorithm library from the trusted file to generate trusted offset data (raw_tee_algo_lib.bin), and extract a specific offset segment containing the general algorithm library from the general file to generate general offset data (raw_ree_algo_lib.bin). At the same time, set the positions of the data extracted from the trusted file and the general file to zero.

[0026] In one embodiment of the present invention, when performing step S21, specifically, integrating the trusted algorithm library into the TEE security domain (CMSE) refers to the developer adding code (i.e., the trusted algorithm library) designed for security-sensitive operations to the software running in the TEE. After algorithm integration, the executable file formed after compilation (usually including linking and possibly additional security measures such as signing) is a secure binary file (tee.bin), i.e., a trusted file. The trusted file has certain protection measures and is expected to be executed in the TEE.

[0027] In one embodiment of the invention, further, integrating the general algorithm library into the non-secure domain (CMNSE) of the REE refers to the developer adding a general algorithm library, different from the TEE, to the software running in the REE. After algorithm integration, and following compilation (and linking steps, etc.), the resulting executable binary file can be represented as a general file (ree.bin).

[0028] In one embodiment of the present invention, when step S22 is executed, specifically, in the trusted file (tee.bin), the code of the trusted algorithm library may be located in a segment with a specific starting address and length. This code (memory region) can be represented as a specific offset segment. Through memory offset, the start and end positions of this part can be accurately located, and then the data of this memory region is copied out and saved to a new file, namely the trusted offset data (raw_tee_algo_lib.bin). The trusted offset data contains the raw, unprocessed data of the algorithm library. In the original trusted file (tee.bin), the extracted data blocks need to be "zeroed out," that is, those data are replaced with 0. That is, the selected memory region is cleared or initialized so that the original memory region no longer contains the original code or data.

[0029] In one embodiment of the invention, further, in the general file (ree.bin), the code of the general file may be located in a segment with a specific starting address and length. This code (memory region) can be represented as a specific offset segment. Through memory offsets, the start and end positions of this part can be accurately located, and then the data of this memory region is copied out and saved to a new file, namely, the general offset data (raw_ree_algo_lib.bin). The general offset data contains the raw, unprocessed data of the algorithm library. In the original general file (ree.bin), the extracted data blocks need to be "zeroed," that is, those data are replaced with 0. That is, the selected memory region is cleared or initialized so that the original memory region no longer contains the original code or data.

[0030] In one embodiment of the present invention, when performing step S30, specifically during the encryption process, an open-source encryption tool, such as OpenSSL, is used to perform AES encryption. OpenSSL can generate a random AES key and an Initialization Vector (IV). The AES key is used for encryption and decryption, while the IV, in certain AES operating modes, is used to ensure that even if the same data block is encrypted multiple times, different encryption results will be produced, further increasing security.

[0031] In one embodiment of the present invention, when encrypting the trusted offset data (raw_tee_algo_lib.bin), the generated AES key and IV are used to encrypt the file content of the trusted offset data using AES, generating encrypted trusted offset data (aes_raw_tee_algo_lib.bin). AES encryption ensures that the algorithm library is not easily tampered with or leaked during transmission or storage. In this embodiment, the encryption command format can be represented as follows: openssl enc -aes-256-cbc -in raw_tee_algo_lib.bin -out aes_raw_tee_algo_lib.bin -K [hex_key] -iv [hex_iv]. Wherein, -K is followed by the AES key in hexadecimal format, and -iv is followed by the IV in hexadecimal format.

[0032] In one embodiment of the present invention, when encrypting the general offset data (raw_ree_algo_lib.bin), the generated AES key and IV are used to encrypt the file content of the general offset data using AES, generating encrypted general offset data (aes_raw_ree_algo_lib.bin). AES encryption ensures that the algorithm library is not easily tampered with or leaked during transmission or storage. In this embodiment, the encryption command format can be represented as follows: openssl enc -aes-256-cbc -in raw_tee_algo_lib.bin -out aes_raw_tee_algo_lib.bin -K [hex_key] -iv [hex_iv]. Wherein, -K is followed by the AES key in hexadecimal format, and -iv is followed by the IV in hexadecimal format.

[0033] In one embodiment of the present invention, when performing step S40, specifically during the generation of the combined trusted file (combine_tee.bin), it is necessary to first determine the specific location, i.e., the specific offset segment, where the content of the trusted algorithm library (tee_algo_lib.a) was previously set to 0. Then, the encrypted algorithm library is inserted, that is, the trusted encrypted offset data (aes_raw_tee_algo_lib.bin) is placed in the same location in the trusted file (tee.bin) where the previously set segment was 0. Finally, it is stored as a new binary image file; that is, the modified trusted file (tee.bin) can be saved as the combined trusted file (combine_tee.bin). During this process, the combined trusted file contains the encrypted algorithm library and is ready to be deployed to the hardware of the corresponding electronic device.

[0034] In one embodiment of the present invention, when performing step S40, further, during the process of generating the combined general file (combine_ree.bin), it is necessary to first determine the specific location, i.e., the specific offset segment, where the content of the general algorithm library (ree_algo_lib.a) was previously set to 0. Then, the encrypted algorithm library is inserted, that is, the general encrypted offset data (aes_raw_ree_algo_lib.bin) is placed in the same location in the general file (ree.bin) where the previously set segment was 0. Finally, it is stored as a new binary image file; that is, the modified general file (ree.bin) can be saved as the combined general file (combine_ree.bin). During this process, the combined general file contains the encrypted algorithm library and is ready to be deployed to the hardware of the corresponding electronic device.

[0035] Please see Figure 3 In one embodiment of the present invention, when step S50 is performed, step S50 may specifically include the following steps: Step S51: Sign the joint trusted file and the joint general file, download the key, initialization vector, joint trusted file and joint general file to the memory of the electronic device, and lock them; Step S52: Verify the operating environment of the electronic equipment to ensure the security of the operating environment.

[0036] In one embodiment of the present invention, when executing step S51, specifically after obtaining the combined trusted file (combine_tee.bin) and the combined general file (combine_ree.bin), a Secure Boot process can be initiated to sign the combined trusted file and the combined general file using the RSA algorithm. During the signing process, a key pair can be generated first. For example, an RSA algorithm can be used to generate a key pair, including a private key and a public key. The private key can be securely stored, and the public key is embedded in the firmware of the electronic device. Then, the combined trusted file and the combined general file can be signed using the aforementioned generated private key. The signing process typically involves calculating a hash digest of the file (such as SHA-256) using a hash function, and then encrypting this hash value using the private key. Signing is usually accomplished using a specialized signing tool, such as OpenSSL.

[0037] In one embodiment of the invention, the electronic device further verifies the validity of the aforementioned signature using a public key embedded in its firmware before startup or loading the TEE / REE. If signature verification fails (e.g., the file is tampered with), the startup process or loading may be blocked to ensure that no unauthorized or tampered code is executed. The electronic device performs the same hash calculation operation as the aforementioned signature on the federated trusted file and federated general file, then decrypts the federated trusted file and federated general file using the public key to obtain a hash value, and compares this decrypted hash value with the hash value just calculated. If they are the same, the verification is successful; if they are different, the verification fails.

[0038] In one embodiment of the present invention, after signing is completed, the AES key and initialization vector can be programmed into the memory of the electronic device, such as OTP Flash memory. OTP Flash memory is a programmable memory that can only be programmed once, i.e., a one-time programmable memory. Once the key and initialization vector are programmed into the OTP area, they cannot be changed or erased. The AES key is typically used to encrypt and decrypt data, while the initialization vector is used for encryption algorithms, ensuring that even the same data encrypted with the same key will yield different results, thus enhancing encryption security. After programming the AES key and initialization vector, the signed joint trusted file and joint universal file can be downloaded to the hardware of the electronic device and locked, for example, by writing these two images into the hardware's memory (such as Flash memory).

[0039] Please see Figure 4 In one embodiment of the present invention, when performing step S52, step S52 may specifically include the following steps: Step S521: Perform signature verification on the read-only memory of the electronic device and obtain the signature verification result; Step S522: When the read-only memory passes the signature verification, the bootloader program of the electronic device is subjected to signature verification processing to obtain the signature verification result; Step S523: When the bootloader passes the signature verification, the security domain of the trusted execution environment of the electronic device is verified to obtain the signature verification result, so as to initialize the general execution environment.

[0040] Please see Figure 5 In one embodiment of the present invention, when performing step S521, step S521 may specifically include the following steps: Step S5211: Check whether a specific bit of the one-time programmable memory is set. If the specific bit is set, execute the secure boot process. If the specific bit is not set, wait. Step S5212: Check the contents of the one-time programmable memory to obtain the signature algorithm, check the memory to obtain the public key, check the signature code length of the jump program, and perform signature verification. Step S5213: Determine whether the signature verification is successful. If the signature verification is successful, the electronic device's bootloader will be processed for signature verification. If the signature verification fails, wait.

[0041] In one embodiment of the present invention, when step S5211 is executed, specifically during the signature verification process of the read-only memory, since the AES key and initialization vector are burned into the one-time programmable memory (OTP Flash memory), and since the data in the OTP Flash memory cannot be modified, certain bits of the OTP Flash memory can be used to initiate the Secure Boot process. When determining whether the Secure Boot process needs to be initiated, it can be checked whether specific bits of the OTP Flash memory are set. A set bit indicates that the electronic device is configured to only accept boots from authorized firmware or software. A set bit not being set indicates that the electronic device may not require strict security checks, or is still in a development or debugging phase, and the device may wait (perhaps waiting for user input, a specific signal, or a timeout), or execute a boot process without security checks.

[0042] In one embodiment of the present invention, when step S5212 is executed, specifically, when a specific position is set, the contents of the OTP Flash memory can be checked for signature verification. During signature verification, firstly, the algorithm used for signing needs to be confirmed; the signature algorithm can be RSA, ECDSA, etc. The public key corresponding to the signature algorithm (such as RSA) can be stored in the OTP Flash memory and locked. Then, the public key stored in the firmware of the electronic device can be obtained; the firmware can be stored in memory. The public key can be used to verify the legality of the software signature, ensuring that the software has not been tampered with. Finally, the length of the signature code of the jump program can be checked to determine whether its length meets a predetermined standard.

[0043] In one embodiment of the present invention, when step S5213 is executed, specifically, in the signature verification process, all the above-mentioned security checks need to be verified. If all security checks meet expectations, it indicates that the verified software is legitimate, and the startup process will continue, and the bootloader of the electronic device will be verified. If any security check fails to meet expectations, it indicates that the verified software may be illegitimate, and the signature verification will fail, and the electronic device's system may not start.

[0044] Please see Figure 6In one embodiment of the present invention, when performing step S522, step S522 may specifically include the following steps: Step S5221: Check the bootloader to determine whether to jump to the next level program. If not, the processor runs the bootloader. If jumping to the next level program, check the contents of the one-time programmable memory to learn the signature algorithm, check the memory to obtain the public key, check the signature code length of the jump program, and perform signature verification. Step S5222: Determine whether the signature verification is successful. If the signature verification is successful, perform signature verification processing on the security domain of the trusted execution environment of the electronic device. If the signature verification fails, wait.

[0045] In one embodiment of the present invention, when executing step S5221, specifically, in the electronic device, the bootloader is a small program whose task is to initialize the hardware and load the main operating system. After the signature verification in the read-only memory is completed, the bootloader needs to be checked to determine whether to jump to the next level program. When not jumping to the next level program, it can be indicated that the processor is running the bootloader and will continue to execute its default operations, such as loading a preset firmware or operating system image. When jumping to the next level program, the contents of the OTP Flash memory can be checked for signature verification. During signature verification, firstly, the algorithm used for signing needs to be confirmed. The signature algorithm can be RSA, ECDSA, etc. The public key corresponding to the signature algorithm (such as RSA) can be stored in the OTP Flash memory and locked. Then, the public key stored in the firmware of the electronic device can be obtained. The firmware can be stored in the memory. The public key can be used to verify the legality of the software signature and ensure that the software has not been tampered with. Finally, the length of the signature code of the jump program can be checked to determine whether its length meets the predetermined standard for signature verification.

[0046] In one embodiment of the present invention, when step S5222 is executed, specifically, in the signature verification process, all the above-mentioned security checks need to be verified. If all security checks meet expectations, it indicates that the verified software is legitimate, and the startup process will continue, performing signature verification on the security domain of the trusted execution environment of the electronic device. If any security check fails to meet expectations, it indicates that the verified software may be illegitimate, and in this case, the signature verification fails, and the electronic device's system may not start.

[0047] Please see Figure 7 In one embodiment of the present invention, when step S523 is performed, step S523 may specifically include the following steps: Step S5231: Perform system configuration initialization processing on the security domain of the trusted execution environment; Step S5232: Check the contents of the one-time programmable memory to obtain the signature algorithm, check the memory to obtain the public key, check the signature code length of the jump program, and perform signature verification. Step S5233: Determine whether the signature verification is successful. If the signature verification is successful, the general execution environment of the electronic device is initialized. If the signature verification fails, wait.

[0048] In one embodiment of the present invention, when executing step S5231, specifically, after the signature verification of the bootloader is completed, the security domain of the Trusted Execution Environment (TEE) needs to be verified. In this embodiment, the security domain of the TEE can be initialized with system configuration, such as initializing the basic configuration of the TEE, including hardware resource allocation, memory management, security policies, etc. Initialization typically ensures that the code and data in the TEE run within specially protected hardware resources to prevent external attackers from accessing them.

[0049] In one embodiment of the present invention, when step S5232 is executed, specifically, the contents of the OTP Flash memory can be checked for signature verification. During signature verification, firstly, the algorithm used for signing needs to be confirmed; the signature algorithm can be RSA, ECDSA, etc. The public key corresponding to the signature algorithm (such as RSA) can be stored in the OTP Flash memory and locked. Next, the public key stored in the firmware of the electronic device can be obtained; the firmware can be stored in memory. The public key can be used to verify the legality of the software signature, ensuring that the software has not been tampered with. Finally, the length of the signature code of the jump program can be checked to determine whether its length meets a predetermined standard for signature verification.

[0050] In one embodiment of the present invention, when step S5233 is executed, specifically, in the signature verification process, all the above-mentioned security checks need to be verified. If all security checks meet expectations, it indicates that the verified software is legitimate, and the startup process will continue, and the general execution environment of the electronic device will be initialized. If any security check fails to meet expectations, it indicates that the verified software may be illegitimate, and the signature verification will fail, and the electronic device's system may not start. During the initialization of the general execution environment, the hardware of the electronic device can be detected and initialized, including the checking and configuration of the CPU, memory, storage devices, I / O devices, and other peripherals.

[0051] In one embodiment of the present invention, the above-described signature verification process is constrained to allow the algorithm to run only on the hardware of the corresponding electronic device, and the electronic device cannot run other programs signed with non-corresponding keys. The constraint factors can be expressed as follows: data in the OTP Flash memory cannot be modified once written, and the writing process typically occurs on the production line where the product is burned; the higher-level program verifies the signature of the next-level program running on the System-on-Chip (SOC) using the public key, and only after successful verification can it continue to jump to the next level; the signature of the next-level program is signed with the product owner's private key; the running REE CMNSE software is also verified by the TEE's CMSE, and therefore is trustworthy.

[0052] Please see Figure 8 In one embodiment of the present invention, when step S60 is performed, step S60 may specifically include the following steps: Step S61: Decrypt the trusted encryption offset data in the joint trusted file according to the key and initialization vector to generate trusted decryption offset data, and save it in a specific random access memory in the trusted execution environment; Step S62: Decrypt the general encrypted offset data in the joint general file according to the key and initialization vector to generate general decryption offset data, and save it in a random access memory in the general execution environment.

[0053] In one embodiment of the present invention, when executing step S61, specifically, after the signature verification process is completed, the combined trusted file (combine_tee.bin) needs to be decrypted. First, the combined trusted file (combine_tee.bin) program can be run to obtain the key and initialization vector (AESKey&IV) stored in the OTP Flash memory. Then, the offset position in the combined trusted file (combine_tee.bin) corresponding to the trusted encrypted offset data (aes_raw_tee_algo_lib.bin) can be decrypted using the key and initialization vector. The combined trusted file can be decrypted using the key and initialization vector to generate the corresponding trusted decryption offset data. After decryption, the trusted decryption offset data needs to be placed in a specific random access memory within the trusted execution environment, i.e., a specific RAM area of ​​the TEE. This RAM area is typically designed to be highly secure to ensure that sensitive data and algorithms are not accessed by the ordinary operating system environment. After RAM loading, the TEE can use these decrypted algorithms and code to perform highly secure operations, such as key management, digital signatures, encryption and decryption.

[0054] In one embodiment of the invention, the trusted decryption offset data is further stored in a specific RAM area of ​​the TEE, ensuring that the trusted decryption offset data cannot be easily overwritten until the chip loses power. During the decryption process of the trusted encrypted offset data, it is ensured that even if the encrypted data is intercepted during storage or transmission, it cannot be deciphered or used without a proper key and initialization vector. This security is further enhanced by using the TEE and a specific RAM area to securely run the decryption data, thereby protecting sensitive operations and information running within the TEE.

[0055] In one embodiment of the present invention, when step S62 is executed, specifically after the decryption of the combined trusted file is completed, the TEE initialization program is completed and jumps to the REE program. When it is necessary to decrypt the combined general file (combine_ree.bin), the application running in the REE does not directly process the confidential information. The application in the REE needs to send a request to the TEE. The application can send a request to the TEE service interface through a secure channel, notifying the TEE that specific data needs to be decrypted, such as specifying the offset position of the data to be decrypted. When the TEE receives the request from the REE, it can obtain the key and initialization vector (AESKey&IV) stored in the OTP Flash memory, and use the key and initialization vector to decrypt the offset position in the combined general file (combine_ree.bin) corresponding to the general encrypted offset data (aes_raw_ree_algo_lib.bin). After decryption, the TEE can transfer the decrypted general decryption offset data back to a segment of random access memory in the general execution environment, such as a secure area of ​​the REE's RAM. Applications within the REE can access the generic decryption offset data for further processing, while the TEE's RAM area remains securely isolated to prevent sensitive data leakage. By storing the generic decryption offset data in a secure region of the REE's RAM, the generic decryption offset data cannot be easily overwritten until the chip loses power.

[0056] In one embodiment of the invention, furthermore, in this way, applications in the REE can utilize the security services provided by the TEE to perform decryption operations on sensitive data, while not being exposed to the potentially more vulnerable REE environment. This security design that separates the two execution environments can leverage the high security performance of the TEE while maintaining the system's flexibility and efficiency. The algorithm part is encrypted and downloaded into the electronic device's memory. After decryption through the above process, the plaintext will only exist in the RAM of the TEE and the REE respectively. When the CPU's PC pointer runs at the corresponding REE's algorithm interface and needs to access critical data stored in the TEE, the CPU will switch to secure mode to access and return the data allowed by the REE. This data is data provided by the algorithm vendor that can be accessed by the REE.

[0057] As can be seen, in the above scheme, the encryption and decryption of the algorithm ensures that it can only run on the corresponding electronic device hardware. Because the algorithm itself contains secure boot information, it must pass verification from the previous level before proceeding to the next stage. Simultaneously, the encryption and decryption ensures that even if the algorithm is leaked, it cannot be disassembled and cracked, effectively improving security. Furthermore, the cracked algorithm plaintext will only exist in RAM, preventing leakage. Finally, secure boot guarantees the correspondence between the algorithm and the electronic product hardware, and the key and initialization vector will not be leaked.

[0058] Please see Figure 9 The present invention also provides an algorithm encryption processing device, which can be used to encrypt algorithms downloaded to the hardware of electronic devices to prevent algorithm leakage. The processing flow of this device corresponds to the processing flow of the aforementioned processing method. The processing device may include an algorithm acquisition module 100, an algorithm integration module 200, an algorithm encryption module 300, a substitution module 400, a signature verification module 500, and a storage module 600. The functions of each module are as follows: In one embodiment of the present invention, the algorithm acquisition module 100 can be used to acquire an algorithm library, wherein the algorithm library includes a trusted algorithm library and a general algorithm library.

[0059] In one embodiment of the present invention, the algorithm integration module 200 can be used to integrate the algorithm library into the corresponding execution environment, extract the corresponding specific offset segment to obtain reliable offset data and general offset data, and set the extracted position to zero.

[0060] Furthermore, the algorithm integration module 200 can be specifically used to integrate a trusted algorithm library into the software of the secure domain of a trusted execution environment to obtain a corresponding trusted file (tee.bin), and to integrate a general algorithm library into the software of the non-secure domain of a general execution environment to obtain a corresponding general file (ree.bin); extract specific offset segments containing the trusted algorithm library from the trusted file to generate trusted offset data (raw_tee_algo_lib.bin), extract specific offset segments containing the general algorithm library from the general file to generate general offset data (raw_ree_algo_lib.bin), and simultaneously, zero out the positions of the data extracted from the trusted file and the general file.

[0061] In one embodiment of the present invention, the algorithm encryption module 300 can be used to obtain a key and an initialization vector, and to encrypt trusted offset data and general offset data respectively, so as to obtain corresponding trusted encrypted offset data and general encrypted offset data.

[0062] In one embodiment of the present invention, the substitution module 400 can be used to add trusted encrypted offset data to a trusted file and replace it at the position that has been zeroed to generate a joint trusted file, and add general encrypted offset data to a general file and replace it at the position that has been zeroed to generate a joint general file.

[0063] In one embodiment of the present invention, the signature verification module 500 can be used to download the key, initialization vector, joint trusted file, and joint general file to the electronic device, and perform signature verification processing on the operating environment of the electronic device to ensure the security of the operating environment. Specifically, the signature verification module 500 can be used to sign the joint trusted file and the joint general file, download the key, initialization vector, joint trusted file, and joint general file to the memory of the electronic device, and perform signature verification processing on the operating environment of the electronic device to ensure the security of the operating environment.

[0064] Furthermore, the signature verification module 500 can be used to perform signature verification processing on the read-only memory of the electronic device and obtain the signature verification result. Specifically, the signature verification module 500 can be used to check whether a specific bit of the one-time programmable memory is set. When the specific bit is set, the secure boot process is executed. When the specific bit is not set, the process waits, checks the contents of the one-time programmable memory to obtain the signature algorithm, checks the memory to obtain the public key, checks the signature code length of the jump program, and performs signature verification processing to determine whether the signature verification is successful. If the signature verification is successful, the signature verification processing is performed on the bootloader of the electronic device. If the signature verification fails, the process waits.

[0065] Furthermore, the signature verification module 500 can also be used to perform signature verification processing on the bootloader of the electronic device when the signature verification of the read-only memory passes, and obtain the signature verification result. Specifically, the signature verification module 500 can be used to check the bootloader, determine whether to jump to the next level program, and if not jump to the next level program, the processor runs the bootloader. If jumping to the next level program, the contents of the one-time programmable memory are checked to obtain the signature algorithm, the memory is checked to obtain the public key, the signature code length of the jump program is checked, and signature verification processing is performed to determine whether the signature verification passes. If the signature verification passes, the security domain of the trusted execution environment of the electronic device is verified; if the signature verification fails, the process waits.

[0066] Furthermore, the signature verification module 500 can also be used to perform signature verification processing on the security domain of the trusted execution environment of the electronic device when the bootloader's signature verification passes, obtain the signature verification result, and perform initialization processing on the general execution environment. Specifically, the signature verification module 500 can be used to perform system configuration initialization processing on the security domain of the trusted execution environment, check the contents of the one-time programmable memory to obtain the signature algorithm, check the memory to obtain the public key, check the signature code length of the jump program, and perform signature verification processing to determine whether the signature verification passes. If the signature verification passes, the general execution environment of the electronic device is initialized; if the signature verification fails, the process waits.

[0067] In one embodiment of the present invention, the storage module 600 can be used to decrypt the joint trusted file and the joint general file according to the key and the initialization vector, respectively, so as to save the generated decrypted data in the corresponding execution environment. Specifically, the storage module 600 can be used to decrypt the trusted encryption offset data in the joint trusted file according to the key and the initialization vector, generate trusted decryption offset data, and save it in a specific random access memory in the trusted execution environment; and to decrypt the general encryption offset data in the joint general file according to the key and the initialization vector, generate general decryption offset data, and save it in a segment of random access memory in the general execution environment.

[0068] Specific limitations regarding the processing device for algorithm encryption can be found in the limitations of the processing method for algorithm encryption described above, and will not be repeated here. Each module in the aforementioned processing device for algorithm encryption can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the corresponding operations of each module.

[0069] The present invention also provides a computer device comprising a processor, a memory, a network interface, and a database connected via a system bus. The processor provides computational and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of an algorithm encryption processing method.

[0070] In one embodiment of the present invention, the computer device may include a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the algorithm library, which includes a trusted algorithm library and a general algorithm library; The algorithm library is integrated into the corresponding execution environment, and specific offset segments are extracted to obtain reliable offset data and general offset data. The extracted positions are then zeroed out. Obtain the key and initialization vector, and encrypt the trusted offset data and general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data; Add trusted encrypted offset data to the trusted file and replace the position that has been zeroed to generate a joint trusted file. Add general encrypted offset data to the general file and replace the position that has been zeroed to generate a joint general file. The key, initialization vector, joint trusted file, and joint general file are downloaded to the electronic device, and the operating environment of the electronic device is verified to ensure the security of the operating environment. The joint trusted file and the joint general file are decrypted according to the key and initialization vector respectively, and the generated decrypted data is saved in the corresponding execution environment.

[0071] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the aforementioned method embodiments.

[0072] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0073] The embodiments of the present invention disclosed above are merely illustrative of the invention. The embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A method for processing algorithm encryption, characterized in that, include: Obtain an algorithm library, wherein the algorithm library includes a trusted algorithm library and a general algorithm library; The algorithm library is integrated into the corresponding execution environment, and specific offset segments are extracted to obtain reliable offset data and general offset data. The extracted positions are then zeroed out. Obtain the key and initialization vector, and encrypt the trusted offset data and the general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data; The trusted encrypted offset data is added to the trusted file and replaced at the position where it was set to zero to generate a joint trusted file. The general encrypted offset data is added to the general file and replaced at the position where it was set to zero to generate a joint general file. The key, the initialization vector, the joint trusted file, and the joint general file are downloaded to the electronic device, and the operating environment of the electronic device is verified to ensure the security of the operating environment. The joint trusted file and the joint general file are decrypted according to the key and the initialization vector, respectively, so as to save the generated decrypted data in the corresponding execution environment.

2. The encryption processing method according to claim 1, characterized in that, The steps of integrating the algorithm library into the corresponding execution environment, extracting specific offset segments to obtain reliable offset data and general offset data, and setting the extracted positions to zero include: The trusted algorithm library is integrated into the security domain of the trusted execution environment to obtain the corresponding trusted files; The general algorithm library is integrated into the non-secure domain of the general execution environment to obtain the corresponding general files; Extract specific offset segments containing trusted algorithm libraries from the trusted file to generate trusted offset data; Extract specific offset segments containing a general algorithm library from the general file to generate general offset data; The positions of the data extracted from the trusted file and the general file are set to zero.

3. The encryption processing method according to claim 1, characterized in that, The steps of downloading the key, the initialization vector, the joint trusted file, and the joint universal file to the electronic device, and performing signature verification on the operating environment of the electronic device to ensure the security of the operating environment include: The joint trusted file and the joint general file are signed, and the key, the initialization vector, the joint trusted file, and the joint general file are downloaded to the memory of the electronic device and locked. The read-only memory of the electronic device is subjected to signature verification processing to obtain the signature verification result; When the read-only memory passes the signature verification, the bootloader of the electronic device is subjected to signature verification processing to obtain the signature verification result; When the bootloader passes the signature verification, it performs signature verification on the security domain of the trusted execution environment of the electronic device, obtains the signature verification result, and performs initialization processing on the general execution environment.

4. The encryption processing method according to claim 3, characterized in that, The step of performing signature verification processing on the read-only memory of the electronic device and obtaining the signature verification result includes: Check whether a specific bit of the one-time programmable memory is set. If the specific bit is set, execute the secure boot process; if the specific bit is not set, wait. The contents of the one-time programmable memory are checked to obtain the signature algorithm; the memory is checked to obtain the public key; the signature code length of the jump program is checked; and signature verification is performed. The system determines whether the signature verification is successful. If the signature verification is successful, the system performs signature verification on the bootloader program of the electronic device. If the signature verification fails, the system waits.

5. The encryption processing method according to claim 3, characterized in that, The step of performing signature verification on the bootloader of the electronic device and obtaining the signature verification result when the read-only memory passes the signature verification includes: The bootloader is checked to determine whether to jump to the next level program. If the next level program is not jumped to, the processor runs the bootloader. If the next level program is jumped to, the contents of the one-time programmable memory are checked to obtain the signature algorithm, the memory is checked to obtain the public key, the signature code length of the jump program is checked, and signature verification is performed. The system determines whether the signature verification passes. If the signature verification passes, the system performs signature verification on the security domain of the trusted execution environment of the electronic device. If the signature verification fails, the system waits.

6. The encryption processing method according to claim 3, characterized in that, The step of performing signature verification on the security domain of the trusted execution environment of the electronic device when the bootloader passes the signature verification, and obtaining the signature verification result to initialize the general execution environment includes: The system configuration initialization process is performed on the security domain of the trusted execution environment of the electronic device; The contents of the one-time programmable memory are examined to obtain the signature algorithm; the memory is examined to obtain the public key; the signature code length of the jump program is checked; and signature verification is performed. The system determines whether the signature verification is successful. If the signature verification is successful, the system initializes the general execution environment of the electronic device. If the signature verification fails, the system waits.

7. The encryption processing method according to claim 1, characterized in that, The step of decrypting the joint trusted file and the joint general file according to the key and the initialization vector respectively, and saving the generated decrypted data in the corresponding execution environment includes: The trusted encryption offset data in the joint trusted file is decrypted according to the key and the initialization vector to generate trusted decryption offset data, which is then stored in a specific random access memory in the trusted execution environment. The general encrypted offset data in the joint general file is decrypted according to the key and the initialization vector to generate general decryption offset data, which is then stored in a random access memory segment of the general execution environment.

8. A processing device for algorithm encryption, characterized in that, include: An algorithm acquisition module is used to acquire an algorithm library, wherein the algorithm library includes a trusted algorithm library and a general algorithm library; The algorithm integration module is used to integrate the algorithm library into the corresponding execution environment, extract the corresponding specific offset segments to obtain reliable offset data and general offset data, and set the extracted positions to zero. The algorithm encryption module is used to obtain the key and the initialization vector, and to encrypt the trusted offset data and the general offset data respectively to obtain the corresponding trusted encrypted offset data and general encrypted offset data. The replacement module is used to add the trusted encrypted offset data to the trusted file and replace it at the position that has been zeroed to generate a joint trusted file, and to add the general encrypted offset data to the general file and replace it at the position that has been zeroed to generate a joint general file. The signature verification module is used to download the key, the initialization vector, the joint trusted file, and the joint universal file to the electronic device, and to perform signature verification processing on the operating environment of the electronic device to ensure the security of the operating environment; and The storage module is used to decrypt the joint trusted file and the joint general file according to the key and the initialization vector, respectively, so as to save the generated decrypted data in the corresponding execution environment.

9. A computer 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, it implements the steps of the processing method for algorithm encryption as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the processing method for encrypting the algorithm as described in any one of claims 1 to 7.

Images