WO2023133862A1 - 数据处理方法及系统 - Google Patents

数据处理方法及系统 Download PDF

Info

Publication number
WO2023133862A1
WO2023133862A1 PCT/CN2022/072190 CN2022072190W WO2023133862A1 WO 2023133862 A1 WO2023133862 A1 WO 2023133862A1 CN 2022072190 W CN2022072190 W CN 2022072190W WO 2023133862 A1 WO2023133862 A1 WO 2023133862A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
engine
hardware
data
plaintext
Prior art date
Application number
PCT/CN2022/072190
Other languages
English (en)
French (fr)
Inventor
郭永伟
谢美伦
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to PCT/CN2022/072190 priority Critical patent/WO2023133862A1/zh
Priority to CN202280003742.2A priority patent/CN116868195A/zh
Publication of WO2023133862A1 publication Critical patent/WO2023133862A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Definitions

  • the embodiments of the present application relate to the field of electronic technologies, and in particular, to a data processing method and system.
  • terminal devices such as mobile phones, tablets, personal computers (PCs, personal computers), IoT (Internet of Things, Internet of Things), wearable devices, etc.
  • IoT Internet of Things, Internet of Things
  • wearable devices etc.
  • security applications with high security requirements such as mobile payment, mobile finance, and car keys installed on mobile phones have been widely used.
  • the implementation of these security applications on mobile phones requires not only the development of corresponding software applications, but more importantly, the need to provide hardware-level security solutions for mobile phone chips to ensure the security of users' property and sensitive data.
  • each manufacturer uses the hardware cryptographic engine in the chip platform of the terminal device to provide general cryptographic services for its upper-layer applications to ensure safe storage or transmission of data.
  • keystore systems When designing software and hardware for these cryptographic services (or called keystore systems), it is usually necessary to make trade-offs and balances in terms of performance, security, cost, and power consumption.
  • the current hardware encryption engine can be divided into the following three types of security levels from low to high:
  • the hardware cryptographic engine of the SoC System-on-Chip, system-on-chip
  • the plaintext of other keys is stored in the memory.
  • the design method of this hardware cryptographic engine makes the plaintext of the key in the memory not stored in the hardware, which is easy to be stolen by malicious programs.
  • the anti-tampering and anti-side channel attack capabilities are weak, and the security level is relatively low.
  • TEE Trusted Execution Environment
  • TEE Trusted Execution Environment
  • ARM's TrustZone technology is generally an execution environment based on the same CPU for resource isolation and time slice rotation. The security level Compared with the pure hardware isolation method, it is lower.
  • SE Secure Element
  • SE Secure Element
  • the embodiments of the present application provide a data processing method and system.
  • this system by storing the root key in the AO storage unit and introducing multiple hardware engines, the key plaintext only exists inside the hardware engine, so that the data encryption and decryption operations have better performance and security .
  • an embodiment of the present application provides a data processing system, including a plurality of hardware engines, a first storage unit, and a second storage unit that is always on (Always On, AO), and the plurality of hardware engines include The first hardware engine and the second hardware engine, the second storage unit is hardwired to the plurality of hardware engines respectively, the second storage unit is unreadable by software, and the first hardware engine runs on TEE or SEE (Secure Execution Environment, safe execution environment), the second hardware engine runs in REE (Rich Execution Environment, rich execution environment);
  • the first hardware engine is configured to: read the first root key from the second storage unit; based on the first root key, encrypt the plaintext of the first key to generate the ciphertext of the first key ; Write the first key ciphertext into the first storage unit.
  • the second hardware engine is configured to: read the first root key from the second storage unit; read the first key ciphertext from the first storage unit; The root key decrypts the first key ciphertext to generate the first key plaintext; based on the first key plaintext, encrypts or decrypts the first data to generate second data.
  • the second storage unit is used to store the first root key, and is used to write the first root key only once when the data processing system is initialized.
  • the first storage unit may be configured as a shared memory of multiple hardware engines.
  • the first storage unit can be an on-chip memory (such as a register), and can also be an off-chip memory (such as (DDR SDRAM, double-rate synchronous dynamic random access memory), NVM (Non-volatile memory, non-volatile Memory, memory that does not lose data when power is lost, etc.).
  • an on-chip memory such as a register
  • an off-chip memory such as (DDR SDRAM, double-rate synchronous dynamic random access memory), NVM (Non-volatile memory, non-volatile Memory, memory that does not lose data when power is lost, etc.).
  • the hard-wired connection may be a chip-level physical connection.
  • a hardwired connection can be used to refer to a permanent physical connection for transferring data between two computers, as opposed to a switched connection.
  • the second storage unit may be an independent register (such as an AO register), or may be a storage unit (memory) deployed on the chip.
  • the second storage unit may be written with the first root key once when the data processing system is powered on.
  • the second storage unit may be written into the root key under software control.
  • the BootLoader controls to write the first root key to the second storage unit once.
  • the first hardware engine runs in the SEE
  • the first hardware engine may be an SE
  • the SE has an independent CPU and storage space.
  • the plaintext of the first key may be the plaintext of the working key of an upper-layer application (for example, the first application).
  • the first data may be application data to be encrypted and decrypted of an upper layer application (such as the first application).
  • system may further include a first software program for operating the first hardware engine, and a second software program for operating the second hardware engine.
  • the second software program can provide the first interface to the upper-layer application, so that the upper-layer application can call the cryptographic service provided by the multiple hardware engines.
  • the second software program can call the first software program, so that the first software program controls the first hardware engine.
  • the first hardware engine runs in the TEE
  • the first software program may include a first driver program of the first hardware engine and a software service (which may be called HiCrypto TA (Trusted Application, may be referred to as HiCrypto TA) to control the first driver program letter app)).
  • HiCrypto TA Trusted Application
  • HiCrypto TA Trusted Application
  • the first hardware engine runs in the SEE
  • the first software program may include the operating system of the first hardware engine and the software service for calling the operating coefficient (which may be called HiCrypto SA (Secure Application, safe application program) ).
  • the second software program of the second hardware engine may include a second driver of the second hardware engine and a software service for controlling the second driver (which may be called HiCrypto CA (Client Application, client application program)).
  • HiCrypto CA Client Application, client application program
  • the upper layer application can read the first key ciphertext from the first storage unit.
  • the upper-layer application when it needs to encrypt and decrypt the application data, it can call the first interface to call the second software program, so that the second software program can control the second hardware engine, based on the first encryption code passed in by the upper-layer application.
  • the key ciphertext is used to perform encryption or decryption operations on the first data to be encrypted and decrypted.
  • the first key ciphertext and the first data may be transmitted to the second hardware engine through the first storage unit.
  • the first key ciphertext and the first data can be passed to the second hardware engine at one time during a function call, or the first key ciphertext can be respectively passed in by calling different functions and the first data to the second hardware engine, which is not limited in this application.
  • the upper-layer application when it needs to encrypt and decrypt the application data, it can call the first interface to call the second software program, so that the second software program can control the second hardware engine, based on the first encryption code passed in by the upper-layer application.
  • the key ciphertext is used to perform encryption or decryption operations on the first data to be encrypted and decrypted.
  • the first key ciphertext and the first data may be transmitted to the second hardware engine through the first storage unit.
  • the first key ciphertext and the first data can be passed to the second hardware engine at one time during a function call, or the first key ciphertext can be respectively passed in by calling different functions and the first data to the second hardware engine, which is not limited in this application.
  • the system of the embodiment of the present application includes a plurality of hardware engines, and an AO storage unit hard-wired to each hardware engine.
  • the AO storage unit can store a root key, and the AO storage unit is not readable by software, and the AO storage unit is only in When the data processing system is initialized, the root key is written once, so that the security of the root key can be improved; the first hardware engine running in the TEE or SEE can use the root key read from the AO storage unit to Encrypt the key plaintext of the upper-layer application, and share the key ciphertext to the second hardware engine through the first storage unit, so that the key plaintext does not leave the hardware throughout the whole process, reaching the hardware security level; the second hardware running in REE The engine can use the root key read from the AO storage unit to decrypt the key ciphertext (for example, the key ciphertext can be read from the first storage unit), so that the key plaintext can be used to encrypt and decrypt data , the second hardware engine can directly perform data encryption and
  • the first root key in the AO storage unit can be used to protect the key plaintext, and the AO storage unit, as a hardware storage unit unreadable by software, can improve the security of the key plaintext. Protection strength; in addition, the AO storage unit is hard-wired with multiple hardware engines, and each time multiple hardware engines read the first key from the AO storage unit, it does not go through the ACPU (application processor), which can ensure the protection required.
  • the key (such as the working key of the application) is securely transmitted between multiple hardware engines; moreover, in addition to using the AO storage unit for the connection channel between multiple hardware engines, the design can be effectively decoupled and operated independently , which can help maximize performance.
  • the system of the embodiment of the present application utilizes multiple hardware engines and AO storage units to realize the hardware-level protection of the key to be protected.
  • the embodiment of the present application can significantly reduce the CPU load by using a dedicated hardware engine , effectively control power consumption (heating), and at the same time achieve the effect that the key does not leave the hardware throughout the process.
  • the second storage unit is configured to be written into the first root key only when the data processing system is powered on.
  • the second storage unit may write the first root key once and cannot continue to write the first root key.
  • the second storage unit refreshes the internally stored root key every time the system is powered on, and after the system is powered on once, data cannot be written after writing data once, so that after the system is powered on once , the root key to encrypt the plaintext of the key to be protected is the same, so that after the system is powered on once, when the key plaintext needs to be used for data encryption and decryption multiple times, the same root key can be used multiple times to encrypt the key
  • the ciphertext is decrypted to obtain the plaintext of the key without frequent switching of the root key used, which can further improve data encryption and decryption performance and encryption security.
  • the first hardware engine includes a first true random number generation module; the first true random number generation module is configured to be used in the data processing system A first true random number is generated during initialization, and the first true random number is used as the first root key.
  • the above functions can be automatically performed when the data processing system is powered on, and the first software program can also be controlled by the BootLoader , the first hardware engine is controlled by the above-mentioned first software program, so that the first true random number generating module performs the above-mentioned function, which is not limited in the present application.
  • the true random number can be randomly generated by the first true random number generation module each time the system is initialized, Hardware-level encryption protection is performed on the plaintext of the key to improve the protection strength of the plaintext of the key.
  • the first hardware engine is further configured to: generate the first root key according to the first variable and the second root key, the The second root key is a preset key; the first root key is written into the second storage unit.
  • the first hardware engine executes the additional functions defined in this implementation manner, it can be controlled and executed by the first software program.
  • the first variable may be pre-configured in the first software program, and the first software program transmits it to the first hardware engine when the first software program controls the first hardware engine.
  • the second root key may be a hardware root key in the first hardware engine, and the hardware root key may be a unique hardware root key preset in the first hardware engine.
  • the first hardware engine may include a key derivation module, and the key derivation module may perform key derivation on the second root key according to the first variable, so as to generate the first root key.
  • the first hardware engine can process the second root key according to the first variable to generate the first root key for protecting the plaintext of the key, which can improve the performance of the first root key. Generation flexibility.
  • the first hardware engine runs in the SEE
  • the multiple hardware engines further include a third hardware engine
  • the third hardware engine runs In said TEE
  • the third hardware engine is configured to: read the first root key from the second storage unit; based on the first root key, decrypt the ciphertext of the first key to generate the The first key plaintext; based on the first key plaintext, encrypt or decrypt the third data to generate fourth data.
  • the first Two hardware engines are used to perform encryption and decryption operations on data.
  • the second hardware engine meets the preset conditions, for example, the second hardware engine is busy.
  • the encryption and decryption algorithms required for encryption and decryption are different.
  • the third hardware engine reads the first root key written by the first hardware engine from the second storage unit to use the encryption and decryption that meets the data encryption and decryption requirements of this time. Algorithms are used to perform encryption and decryption operations on data, which can improve the reliability of data encryption and decryption in the system of the embodiment of the present application.
  • the third data may be the same as or different from the first data, which is not limited in the present application.
  • system may further include a third software program for operating a third hardware engine.
  • the third software program may include the TA described in the first aspect and a driver program for controlling the third hardware engine.
  • the second software program can call the third software program, so that the third software program controls the third hardware engine.
  • the second hardware engine further includes a first register, wherein the first register is unreadable by software and unwritable by software;
  • the first register is configured to store the first key plaintext, where the first key plaintext is used to encrypt or decrypt application data, where the application data may include the first data.
  • the second hardware engine may decrypt the first key ciphertext based on the first root key to generate the first key plaintext , and then, the second hardware engine may write the plaintext of the first key generated by this engine into the first register.
  • the number of the first registers may be one or more, which is not limited in the present application.
  • the data processing system further includes a first software program and a second software program, the second software program has a first interface, and the first application runs in the REE;
  • the first software program is used to control the first hardware engine
  • the second software program is used to control the second hardware engine.
  • the first application is an upper-layer application for users.
  • the second software program can provide the first interface to the upper-layer application, so that the upper-layer application can call the cryptographic service provided by the multiple hardware engines.
  • the second software program can call the first software program, so that the first software program controls the first hardware engine.
  • the second software program is further configured to control the second hardware engine in response to a second request from the first application to the first interface.
  • the second request is a three-segment function call request
  • the second hardware engine may send the handle information of the first register to the first application through the second software program in response to the second request; then , the first application can invoke the second software program by triggering the second request carrying the handle information multiple times, so that the second software program can control the second hardware engine to read the first encryption key from the first register according to the handle information.
  • Key plaintext to encrypt and decrypt application data is a three-segment function call request
  • the first register in the second hardware engine by configuring the first register in the second hardware engine to use the first register to store the first key plaintext, since the first register is unreadable and unwritable by software, it can be ensured that the ACPU cannot The first key plaintext is read from the first register in the second hardware engine, so that the key plaintext reaches hardware-level security.
  • the first hardware engine is specifically configured to: based on the key parameter and the first root key, perform the plaintext processing of the first key Encrypt to generate first ciphertext data; obtain verification data according to the first ciphertext data; wherein, the first key ciphertext includes the key parameter, the first ciphertext data, and the check data;
  • the second hardware engine is specifically configured to: perform verification and authentication on the first ciphertext data based on the verification data in the first key ciphertext;
  • the key parameters and the first root key are used to decrypt the first ciphertext data to obtain the first key plaintext, wherein the first key plaintext is used to decrypt the first Data is encrypted or decrypted.
  • the first hardware engine can use the GCM mode of the AES or SM4 algorithm to perform the encryption operation of the plaintext of the key.
  • the The specific algorithm of the authenticated encryption algorithm is not limited to the GCM mode of AES or SM4, and may also be other authenticated encryption algorithms.
  • the GCM mode of SM4 can be used for authentication and encryption to ensure the integrity of plaintext or other authentication content.
  • the verification parameters can include but not limited to the following parameters: TAG, optionally including additional authentication data (AAD, Additional Authentication Data).
  • Key parameters may include an IV (initialization vector) value.
  • TAG is a message authentication code in GCM mode.
  • the IV value may be generated by a true random number generating module in the first hardware engine (it may be any true random number generating module configured in the first hardware engine).
  • AAD may be imported by the first application.
  • the first hardware engine may be specifically configured to: encrypt the plaintext of the first key of the first application based on the IV value and the first root key to generate first ciphertext data; Text data and the AAD (optional) imported by the first application, calculate TAG; use the IV value, the AAD (optional), the first ciphertext data and the TAG as the first key ciphertext;
  • the second hardware engine can be specifically configured to: calculate TAG' for the first ciphertext data in the first key ciphertext and the AAD (optional); detect that TAG is the same as TAG', and pass the verification authentication , and then, based on the first root key and the IV value in the first key ciphertext, decrypt the first ciphertext data to generate the first key plaintext.
  • the first hardware engine when it encrypts the key plaintext, it can set the key parameter IV value and the TAG used for verification, so that the system of this embodiment can support the authentication of the upper layer application And anti-counterfeiting, to prevent other applications from stealing the plaintext of the key, and using this system to decrypt the data of the specific application by pretending to be a specific application.
  • the data processing system further includes a first software program and a second software program, the second software program has a first interface, and the first application runs on in the REE;
  • the first software program is used to control the first hardware engine to perform operations and read and write operations;
  • said second software program for:
  • controlling the second hardware engine to perform computation and read and write operations
  • the first software program is invoked.
  • the first software program is used to control the first hardware engine
  • the second software program is used to control the second hardware engine.
  • the first application is an upper-layer application for users.
  • the second software program can provide the first interface to the upper-layer application, so that the upper-layer application can call the cryptographic service provided by the multiple hardware engines.
  • the second software program can call the first software program, so that the first software program controls the first hardware engine.
  • the first application can communicate with the second software program by calling the first interface, for example, the second software program can receive the first request of the first application through the first interface;
  • the second software program can call the first software program in response to the first request, and then the first software program can control the first hardware engine to perform operations and read and write operations.
  • the first hardware engine can Software program control, read the first root key from the second storage unit; based on the first root key, encrypt the plaintext of the first key to generate a first key ciphertext; The key ciphertext is written into the first storage unit.
  • the second software program may read information indicating the first key ciphertext from the first storage unit in response to the first request of the first application (for example, the first key ciphertext is in address information in the first storage unit), and send this information to the first application.
  • the second software program when the second software program responds to the first request, it may assign address information to the first application, where the address information is an address in the first storage unit for writing the above-mentioned first key ciphertext information.
  • the second software program may send the address information to the first software program in response to said first request.
  • the first software program may send the address information to the first hardware engine when controlling the first hardware engine to perform the encryption operation of the key plaintext described in the first aspect, so that the first hardware engine follows the address information, and write the generated key ciphertext into the first storage unit.
  • the second software program may respond to the first request and send the address information to the first application for the first application to read from the first storage unit. Get the first key ciphertext.
  • the first application can use the first key ciphertext to call the second software program through the first interface, for example, the first application sends the second software program to the second software program through the first interface. send the second request;
  • the second software program can control the second hardware engine to perform computation and read and write operations in response to the second request.
  • the second hardware engine can control the second software program to read the first A key; read the first key ciphertext from the first storage unit; based on the first root key, decrypt the first key ciphertext to generate the first ciphertext key plaintext; based on the first key plaintext, encrypt or decrypt the first data to generate second data.
  • the second hardware engine After the second hardware engine executes the data encryption and decryption operation, the second hardware engine can write the second data into the first storage unit, and the write address of the second data in the first storage unit can be triggered by the first application in the second If the request is carried in the second request, the first application can read the second data from the corresponding address of the first storage unit.
  • the upper layer application running in the REE can communicate with the second software program through the first interface, so that the second software program calls the first software program to control the first hardware engine to perform calculation and read and write operations , so that the first key plaintext of the upper-layer application is encrypted in the first hardware engine to generate the first key ciphertext, so that the upper-layer application obtains the first key ciphertext.
  • the upper-layer application can communicate with the second software program through the first interface, and the second software program controls the second hardware engine to perform calculations and read and write operations, so that the second hardware engine reads and writes from the
  • the second storage unit reads the first root key; reads the first key ciphertext from the first storage unit; based on the first root key, encrypts the first key Decrypt the text to generate the first key plaintext; based on the first key plaintext, encrypt or decrypt the first data to generate the second data, without switching the operating environment to TEE or SEE, in the REE,
  • the data encryption and decryption operation is independently performed by the second hardware engine, which can greatly reduce the time loss of the path and effectively improve the performance of data encryption and decryption.
  • the first hardware engine is further configured to obtain a fourth root key according to the second variable and the second root key, wherein the The fourth root key is used to encrypt or decrypt the plaintext of the first key; and decrypt the ciphertext of the second key of the first application based on the fourth root key to generate the first Key plaintext, wherein the second key ciphertext is generated by the first application according to the first key plaintext and sent to the first software program through the second software program.
  • the above-mentioned second variable may be the same as or different from the above-mentioned first variable, and the above-mentioned second variable may be preconfigured in the first software program, and the first hardware engine obtains according to the second variable and the second root key
  • the principle of the fourth root key is the same as the principle of the first hardware engine generating the first root key according to the first variable and the second root key in the above-mentioned implementation, and will not be repeated here.
  • the above-mentioned second variable can be configured in the first software program of the system before the system leaves the factory, and the second variable can be distributed by a third-party password management center (such as PKI (Public Key Infrastructure)), and the third-party password management
  • the center also has the second variable and the second root key, and the third-party password management center can generate the fourth root key according to the second variable and the second root key, and distribute it to upper-layer applications offline.
  • the upper layer application is the first application.
  • the upper layer application may include the cloud and the first application.
  • the third-party password management center can distribute the fourth root key offline to the cloud side of the first application.
  • the cloud when the cloud needs to import the working key to the system of this application, it can import the above-mentioned second key ciphertext encapsulated with the fourth root key.
  • the cloud can call the second software program through the interface, so that the second software program can call the first software program, so as to use the information transmitted by the cloud to indicate the second key ciphertext of the first application (For example, the second key ciphertext, optionally, it may be the address information of the second key ciphertext), which is imported into the first hardware engine to encrypt the working key.
  • the second key ciphertext optionally, it may be the address information of the second key ciphertext
  • the key imported into the first hardware engine may be a second key ciphertext encapsulated with a symmetric key, wherein the symmetric key may be based on the second variable and the second root key , and the fourth root key obtained.
  • the system of the embodiment of the present application can support the scenario where the application imports a symmetrically encapsulated key. Not only can the ciphertext of the second key to be protected be left out of the hardware, but also the fourth root key can be used for the second key through the second variable. After the root key is derived, the second variable with different values can be configured for different applications or different businesses, so that the fourth root key required for development can be flexibly customized according to customer needs.
  • the first hardware engine further includes a second true random number generation module
  • the second true random number generating module may be the same as or different from the first true random number generating module, which is not limited in the present application.
  • the second true random number generating module is configured to generate a second true random number and a third true random number as the first public key plaintext and the second true random number when the data processing system is initialized (including but not limited to power-on). a private key plaintext;
  • the first hardware engine is further configured to encrypt the plaintext of the first private key based on the first root key, generate a ciphertext of the first private key, and write the ciphertext of the first private key into the first A storage unit; read the first private key ciphertext from the first storage unit; decrypt the first private key ciphertext based on the first root key, and generate the first private key plaintext ; Based on the first private key plaintext, decrypt the third key ciphertext to obtain the first key plaintext of the first application; wherein, the third key ciphertext is the first application based on the ciphertext
  • the first public key plaintext is encrypted data of the first key plaintext
  • the third key ciphertext is generated by the first application and sent to the first software through the second software program program.
  • the first software program may be used to obtain the first public key plaintext from the first hardware engine and send it to the second software program; the second software program may be used to convert the first public key to A public key is sent in plain text to the upper layer application.
  • the upper layer application is the first application.
  • the upper layer application may include the cloud and the first application.
  • the cloud when the cloud needs to import the working key into the system of the present application, it can import the above-mentioned third key ciphertext encapsulated with the plaintext of the first public key.
  • the cloud can call the second software program through the interface, so that the second software program can call the first software program, so as to use the information transmitted by the cloud to indicate the third key ciphertext of the first application (For example, the third key ciphertext, optionally, it may be the address information of the second key ciphertext), which is imported into the first hardware engine to encrypt the working key.
  • the third key ciphertext optionally, it may be the address information of the second key ciphertext
  • the key imported into the first hardware engine may be the third key ciphertext encapsulated using an asymmetric key, and the system in the embodiment of the present application may support importing an asymmetrically encapsulated key.
  • the ciphertext of the third key to be protected can be kept out of the hardware, and the key that encapsulates the plaintext of the first key can be flexibly customized and developed according to customer needs.
  • the key used to encapsulate the working key of the application in the embodiment of the present application can be generated by the first hardware engine through random numbers, without resorting to an external password management center, and the key management flexibility of the application is higher.
  • the first hardware engine includes a third true random number generation module
  • the third true random number generating module may be the same as or different from the first true random number generating module, which is not limited in the present application.
  • the second software program is further configured to call the first software program to control the first hardware engine in response to a fifth request from the first application to the first interface, and the fifth request includes the plaintext of the first key;
  • the third true random number generating module is configured to generate a fourth true random number as the first key plaintext of the first application in response to the fifth request.
  • the first hardware engine can use the true random number generation module to generate the working key of the first application (that is, the first key plaintext), and the application does not need to import the working key, so that the system in the embodiment of the present application can Applied to key generation scenarios.
  • the second software program is further configured to call the first a software program to control the first hardware engine, the sixth request including the first key plaintext;
  • the first hardware engine is further configured to write the first key in plaintext into the first storage unit;
  • the second hardware engine also includes a second register.
  • the second register is software-writable and software-unreadable
  • the second hardware engine is configured to read the first key plaintext from the first storage unit, and write the first key plaintext into the second register, wherein the second register uses to store the plaintext of the first key.
  • the channel for the application to directly set the second register of the plaintext key can be reserved in the second hardware engine, and the channel for passing the plaintext key to the second hardware engine can be provided for the application, because the application can directly Pass the plaintext of the key to the second hardware engine in the REE, without passing the plaintext of the key to the first hardware engine running in the TEE or SEE, so that the key can be imported and used in the REE only
  • the operation of data encryption and decryption using the key can accelerate the performance of data encryption and decryption without occupying CPU load.
  • the system is integrated in a system on chip (SoC).
  • SoC system on chip
  • the embodiment of the present application provides a data processing method, which is applied to a data processing system, and the data processing system includes a plurality of hardware engines, a first storage unit, and a second storage unit of AO, and the plurality of hardware engines It includes a first hardware engine and a second hardware engine, the second storage unit is hardwired to the multiple hardware engines respectively, the second storage unit is unreadable by software, and the first hardware engine runs on TEE or In SEE, the second hardware engine runs in REE, and the method includes: the first hardware engine reads the first root key from the second storage unit; the first hardware engine reads the first root key based on the first hardware engine A key, encrypting the first key plaintext to generate the first key ciphertext; the first hardware engine writes the first key ciphertext into the first storage unit; the second hardware engine Read the first root key from the second storage unit; the second hardware engine reads the first key ciphertext from the first storage unit; the second hardware engine based on the The first root key decrypts the
  • the second storage unit is specifically configured to be written into the first root key only when the data processing system is powered on.
  • the second storage unit may write the first root key once and cannot continue to write the first root key.
  • the method before the first hardware engine reads the first root key from the second storage unit, the method further includes: the first hardware The engine generates a first true random number when the data processing system is initialized, uses the first true random number as the first root key, and writes the first root key into the second storage unit.
  • the method before the first hardware engine reads the first root key from the second storage unit, the method further includes: the first hardware The engine generates the first root key according to the first variable and the second root key, and writes the first root key into the second storage unit, wherein the second root key is a preset Set the key.
  • the first hardware engine runs in the SEE
  • the multiple hardware engines further include a third hardware engine
  • the third hardware engine runs In the TEE
  • the method further includes: the third hardware engine reads from the second storage unit The first root key; the third hardware engine decrypts the first key ciphertext based on the first root key to generate the first key plaintext; the third hardware engine Encrypt or decrypt the third data based on the plaintext of the first key to generate fourth data.
  • the second hardware engine further includes a first register, wherein the first register is unreadable by software and unwritable by software; the second hardware engine The engine decrypts the first key ciphertext based on the first root key, and after generating the first key plaintext, the method further includes: the second hardware engine decrypting the first ciphertext The key is written in plaintext to the first register.
  • the first register is used to store the first key plaintext, where the first key plaintext is used to encrypt or decrypt application data, wherein the application data may include the first data.
  • the first hardware engine encrypts the first key plaintext based on the first root key to generate the first key ciphertext, including : The first hardware engine encrypts the plaintext of the first key based on the key parameter and the first root key to generate first ciphertext data, and obtains a checksum according to the first ciphertext data verification data; wherein, the first key ciphertext includes the key parameter, the first ciphertext data and the verification data; the second hardware engine is based on the first root key, Deciphering the first key ciphertext to generate the first key plaintext includes: the second hardware engine, based on the verification data in the first key ciphertext, If the verification and authentication pass, the second hardware engine decrypts the first ciphertext data based on the key parameter and the first root key to obtain the The first key plaintext, wherein the first key plaintext is used to encrypt or decrypt the first data.
  • the data processing system further includes a first software program and a second software program, the second software program has a first interface, and the first application runs on
  • the method further includes: the first software program controls the first hardware engine to perform calculation and read and write operations; the second software program controls the second hardware engine to perform calculation and read and write operations , and communicate with the first application through the first interface, and invoke the first software program.
  • the method further includes: the second software program calls the A first software program to control the first hardware engine, wherein the third request includes information indicating a second key ciphertext for the first application, the second key ciphertext being based on the first The data obtained by encrypting the plaintext of the first key with the four keys.
  • the fourth root key is a root key generated by the first hardware engine based on the second variable and the second root key; wherein, the plaintext of the first key is based on the fourth root key The key decrypts data obtained by decrypting the second key ciphertext.
  • the first hardware engine is further configured to obtain a fourth root key according to the second variable and the second root key, wherein the fourth root key is used to encrypting or decrypting the key plaintext; and decrypting the second key ciphertext of the first application based on the fourth root key to generate the first key plaintext, wherein the second key encryption
  • the text is generated by the first application according to the plaintext of the first key and sent to the first software program through the second software program.
  • the first software program obtains the plaintext of the first public key, and sends the plaintext of the first public key to the second software program, wherein,
  • the first public key plaintext is a second true random number generated by the first hardware engine when the data processing system is initialized;
  • the second software program sends the first public key plaintext to the first An application;
  • the second software program is further configured to call the first software program to control the first hardware engine in response to a fourth request from the first application to the first interface, wherein the The fourth request includes information indicating a third key ciphertext, where the third key ciphertext is data obtained by encrypting the first key plaintext based on the first public key plaintext.
  • the first key plaintext is the data after decrypting the third key ciphertext based on the first private key plaintext; wherein, the first private key plaintext is when the data processing system is powered on , the third true random number generated by the first hardware engine; wherein, the first root key is also used to encrypt or decrypt the plaintext of the first private key.
  • the first hardware engine includes a third true random number generation module
  • the third true random number generating module may be the same as or different from the first true random number generating module, which is not limited in the present application.
  • the second software program may call the first software program to control the first hardware engine in response to a fifth request from the first application to the first interface, the fifth request including the first a key plaintext;
  • the third true random number generating module may generate a fourth true random number as the first key plaintext of the first application in response to the fifth request.
  • the first hardware engine can use the true random number generation module to generate the working key of the first application (that is, the first key plaintext), and the application does not need to import the working key, so that the method in the embodiment of the present application
  • the applied system can be applied to key generation scenarios.
  • the second software program may call the first software program to respond to the sixth request of the first application to the first interface Controlling the first hardware engine, the sixth request includes the first key plaintext; the first hardware engine may write the first key plaintext into the first storage unit; the second The hardware engine also includes a second register.
  • the second register is software-writable and software-unreadable
  • the second hardware engine may read the first key plaintext from the first storage unit, and write the first key plaintext into the second register, wherein the second register is used for The plaintext of the first key is stored.
  • the channel for the application to directly set the second register of the plaintext key can be reserved in the second hardware engine, and the channel for passing the plaintext key to the second hardware engine can be provided for the application, because the application can directly Pass the plaintext of the key to the second hardware engine in the REE, without passing the plaintext of the key to the first hardware engine running in the TEE or SEE, so that the key can be imported and used in the REE only
  • the operation of data encryption and decryption using the key can accelerate the performance of data encryption and decryption without occupying CPU load.
  • the system is integrated in a SoC.
  • the second aspect and any implementation manner of the second aspect correspond to the first aspect and any implementation manner of the first aspect respectively.
  • technical effects corresponding to the second aspect and any implementation manner of the second aspect reference may be made to the technical effects corresponding to the above-mentioned first aspect and any implementation manner of the first aspect, and details are not repeated here.
  • the embodiment of the present application provides a chip, including one or more interface circuits, one or more processors, multiple hardware engines, a first storage unit, and a second storage unit of AO, the multiple hardware
  • the engine includes a first hardware engine and a second hardware engine, the second storage unit is hardwired to the plurality of hardware engines, the second storage unit is unreadable by software, and the first hardware engine runs on the TEE Or in the SEE, the second hardware engine runs in the REE, and the multiple hardware engines can implement the second aspect and the method in any implementation manner of the second aspect.
  • the third aspect and any implementation manner of the third aspect correspond to the second aspect and any implementation manner of the second aspect respectively.
  • the technical effects corresponding to the third aspect and any one of the implementation manners of the third aspect refer to the technical effects corresponding to the above-mentioned second aspect and any one of the implementation manners of the second aspect, which will not be repeated here.
  • the embodiment of the present application provides a computer-readable storage medium.
  • the computer-readable storage medium stores a computer program, and when the computer program is run on the computer or the processor, the computer or the processor is made to execute the second aspect or the method in any possible implementation manner of the second aspect.
  • the fourth aspect and any implementation manner of the fourth aspect correspond to the second aspect and any implementation manner of the second aspect respectively.
  • the technical effects corresponding to the fourth aspect and any one of the implementation manners of the fourth aspect refer to the above-mentioned second aspect and the technical effects corresponding to any one of the implementation manners of the second aspect, and details are not repeated here.
  • the embodiment of the present application provides a computer program product.
  • the computer program product includes a software program, and when the software program is executed by a computer or a processor, the method in the fifth aspect or any possible implementation manner of the fifth aspect is executed.
  • the fifth aspect and any implementation manner of the fifth aspect correspond to the second aspect and any implementation manner of the second aspect respectively.
  • the technical effects corresponding to the fifth aspect and any one of the implementation manners of the fifth aspect refer to the above-mentioned second aspect and the technical effects corresponding to any one of the implementation manners of the second aspect, which will not be repeated here.
  • an embodiment of the present application provides a data processing device, including a plurality of hardware engines, a first storage unit, and a second storage unit of AO, the plurality of hardware engines include a first hardware engine and a second hardware engine, The second storage unit is hard-wired connected to the plurality of hardware engines respectively, the second storage unit is unreadable by software, the first hardware engine runs in TEE or SEE, and the second hardware engine runs in In the REE, the data processing device is configured to execute the method in the second aspect or any possible implementation manner of the second aspect.
  • the sixth aspect and any implementation manner of the sixth aspect correspond to the second aspect and any implementation manner of the second aspect respectively.
  • the technical effects corresponding to the sixth aspect and any one of the implementation manners of the sixth aspect refer to the above-mentioned second aspect and the technical effects corresponding to any one of the implementation manners of the second aspect, and details are not repeated here.
  • FIG. 1 is a schematic diagram of the architecture of a multi-hardware cryptographic engine system according to an embodiment of the present application
  • FIG. 2 is a framework diagram of interaction between a multi-hardware cryptographic engine system and an application according to an embodiment of the present application;
  • FIG. 3 is a schematic diagram of an interaction process between multiple hardware cryptographic engines according to an embodiment of the present application
  • FIG. 4a is one of the work flow diagrams of a multi-hardware cryptographic engine system in a key generation scenario according to an embodiment of the present application
  • FIG. 4b is a sequence diagram of a key encryption process of a multi-hardware cryptographic engine system according to an embodiment of the present application
  • FIG. 4c is a sequence diagram of a key usage process of a multi-hardware cryptographic engine system according to an embodiment of the present application.
  • Fig. 5 is a working flow diagram of a key usage process of a multi-hardware cryptographic engine system according to an embodiment of the present application
  • FIG. 6 is a sequence diagram of a key usage process of a multi-hardware cryptographic engine system according to an embodiment of the present application
  • FIG. 7 is a sequence diagram of a key usage process of a multi-hardware cryptographic engine system according to an embodiment of the present application.
  • Fig. 8 is a working flow chart of a multi-hardware cryptographic engine system under the scenario of key import without encapsulation according to the embodiment of the present application;
  • Fig. 9 is a working flow chart of a multi-hardware cryptographic engine system in the scenario of encapsulation and import of keys according to an embodiment of the present application;
  • Fig. 10 is a working flow chart of a multi-hardware cryptographic engine system under the scenario of key import without encapsulation according to the embodiment of the present application;
  • Fig. 11 is a working flow chart of a multi-hardware cryptographic engine system under the scenario of key import without encapsulation according to the embodiment of the present application;
  • Fig. 12 is a schematic structural diagram of a device provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a chip provided by an embodiment of the present application.
  • first and second in the description and claims of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order of objects.
  • first target object, the second target object, etc. are used to distinguish different target objects, rather than describing a specific order of the target objects.
  • multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.
  • the Android Keystore (Android keystore) system can store encryption keys in a secure container (such as TEE provided by SoC). After the encryption key of the application enters the Keystore, the key cannot be exported, so that the encryption key stored in the container can be used to encrypt the application data without exporting the key, so as to improve the extraction of the key from the terminal device difficulty.
  • a secure container such as TEE provided by SoC.
  • Keystore is able to provide the following classes of operations: generate keys; import and export asymmetric keys (no key wrapping, only public keys can be exported); import raw symmetric keys (no key wrapping); Asymmetric encryption and decryption; asymmetric signing and verification using digests and appropriate padding modes; symmetric encryption and decryption in appropriate modes (including AEAD mode); generation and verification of symmetric message authentication codes.
  • protocol elements such as usage, mode and padding, and access control restrictions
  • Keystore can use two security measures to prevent key material from being extracted:
  • the application When an encryption operation is performed through a key in the Android Keystore, the application will feed the plaintext, ciphertext, and message to be signed or verified to the system process that performs the encryption operation in the background. If the application process is compromised, the attacker may be able to use the application key but not be able to extract the key material (for example, for use outside of the Android device).
  • this feature When this feature is enabled for a key, its key material is never exposed outside the secure hardware. If the Android operating system is compromised or the attacker can read the device's internal storage, the attacker may be able to use the Android Keystore of any application on the Android device, but cannot extract this data from the device. This feature can only be enabled if the device's security hardware supports the specific combination of key algorithm, blocking mode, padding scheme, and digest that the key is authorized to use with.
  • Supported devices running Android 9 or higher can have StrongBox Keymaster, an implementation located in the hardware security module.
  • the hardware security module can contain the following components:
  • DRAM Dynamic Random Access Memory, dynamic random access memory
  • coprocessor or other core resources with the application processor (AP, Application Processor);
  • Tamper-resistant including resistance to physical penetration and tampering, must be resistant to side-channel attacks.
  • the Android Keystore system verifies the integrity of the keys via the TEE.
  • Secure Key Import is a new feature of Android 9. This new function allows applications to embed existing keys into keystores in a more secure manner, and is also applicable to various enterprise application scenarios.
  • the source of the key may be located locally or on a remote server in a cloud data center, and the security key may be encrypted using a public wrapping key from the user's device.
  • TEE is an execution environment based on the same CPU for resource isolation and time slice rotation, and its security level is lower than that of pure hardware isolation.
  • Android 9 or higher version can support StrongBox Keymaster, but the CPU of the SE that StrongBox Keymaster is attached to is generally a smart card level, which has high security, but the encryption and decryption performance is weak; and if the working key used for data encryption and decryption If the key is exported to StrongBox Keymaster to improve the performance of encryption and decryption, the plain text of the key will be exported to the hardware, and the security level will be reduced to TEE or lower.
  • the hardware cryptographic engine based on the SoC platform of the terminal device provides cryptographic services for upper-layer applications
  • the design of the hardware cryptographic engine inside the SoC is more critical, and needs to be traded off in terms of performance, security, and area (related to cost).
  • the SoC of the embodiment of the present application provides multiple hardware cryptographic engines, which can provide cryptographic services (hereinafter referred to as HiCrypto Service (Hardware inside Crypto Service)) in a manner of linkage of multiple hardware cryptographic engines, so as to achieve the balance of security, performance and cost. balance.
  • HiCrypto Service Hardware inside Crypto Service
  • the hardware cryptographic engine is used to indicate that cryptographic-related algorithm processing is added to the hardware engine.
  • the key can be placed in the multi-hardware cryptographic engine, and the encryption and decryption of application data can be realized without the key being exported to the hardware.
  • the security level can reach the security level of pure hardware isolation, and can Enhance encryption and decryption performance.
  • FIG. 1 exemplarily shows an architecture diagram of a multi-hardware cryptographic engine system according to an embodiment of the present application.
  • FIG. 2 exemplarily shows a framework diagram of interaction between a multi-hardware cryptographic engine system and an application according to an embodiment of the present application.
  • the multi-hardware encryption engine system may include a SoC security subsystem at the hardware layer, and the security subsystem may include multiple hardware encryption engines.
  • the hardware cryptographic engine is used to indicate a hardware engine that adds cryptographic-related algorithm processing.
  • the multi-hardware cryptographic engine may include a REE hardware cryptographic engine (hereinafter referred to as HCE-REE engine), a TEE hardware cryptographic engine (hereinafter referred to as HCE-TEE engine).
  • HCE-REE engine REE hardware cryptographic engine
  • HCE-TEE engine TEE hardware cryptographic engine
  • the HCE-REE engine and the HCE-TEE engine can be two submodules in a passive HCE (Hardware Crypto Engine, hardware cryptographic engine).
  • the multi-hardware cryptographic engine of the security subsystem may optionally include inSE.
  • inSE Inside/or On-die Secure Element, internal or on-chip security element
  • on-chip hardware security module which may include but not limited to: independent secure CPU, true random number generator (True Random Number Generator, TRNG) and secure storage space.
  • TRNG true Random Number Generator
  • the multi-hardware cryptographic engine system may include a hardware cryptographic engine driver located at the REE kernel layer.
  • the hardware cryptographic engine driver is used to call the HCE-REE engine and the HCE-TEE engine.
  • the hardware cryptographic engine driver may include an HCE-REE driver for invoking the HCE-REE engine and an HCE-TEE driver for invoking the HCE-TEE engine.
  • this multi-hardware cryptographic engine system can also include inSE operating system (being SEE OS), and SEE OS is used for calling inSE.
  • SEE OS inSE operating system
  • SEE OS is used for calling inSE.
  • the multi-hardware cryptographic engine system may also include a cryptographic service located at the hardware abstraction layer.
  • the multi-hardware cryptographic engine of the embodiment of the present application can provide the above-mentioned cryptographic service (hereinafter referred to as HiCrypto Service) in linkage.
  • the cryptographic service can provide an SDK (Software Development Kit, software development kit) interface of the operating system to provide application developers with the cryptographic service of the multi-hardware cryptographic engine system of the embodiment of the present application.
  • the cryptographic service can be used to call the hardware cryptographic engine driver of the kernel layer, optionally, to call the inSE operating system to realize the control of multiple hardware cryptographic engines, so as to control the multiple hardware cryptographic engines using the embodiment of the present application.
  • the application of the hardware cryptographic engine system provides data encryption and decryption services.
  • HiCrypto Service is used as supporting software with multi-hardware cryptographic engines, and may include HCE-TEE cryptographic services running in TEE, HCE running in REE (Rich Execution Environment, rich execution environment) -REE password service, optionally, can also include inSE password service running in SEE (Secure Execution Environment, secure execution environment).
  • HCE-TEE cryptographic service HCE-REE cryptographic service, and inSE cryptographic service are all built-in software in the multi-hardware cryptographic engine system, and can provide HUKS (Harmony Universal KeyStore, Hongmeng general keystore system) interface to provide password services to APP.
  • HUKS Harmon Universal KeyStore, Hongmeng general keystore system
  • the HUKS interface may be a part of the SDK interface in FIG. 1 , and may be used to provide an interface for invoking the cryptographic service described in the embodiment of the present application for applications at the application layer.
  • the HUKS interface may include but not limited to C, C++, Java, JS and other multilingual APIs (Application Programming Interface, application programming interface).
  • the HCE-TEE cryptographic service is used to call the HCE-TEE driver to make the HCE-TEE engine work.
  • the HCE-TEE engine can be used to generate or import the working key of the application, and encrypt the working key.
  • the inSE password service is used to call the SEE OS to make inSE work.
  • inSE can be used to generate or import the working key of the application, and encrypt the working key.
  • the HCE-REE cryptographic service can be used to receive the calling request of the APP to the HUKS interface, and in response to the calling request (such as a calling request for generating or importing a work key), to call the HCE-TEE cryptographic service or inSE Cryptographic service, HCE-TEE cryptographic service or inSE cryptographic service can respond to the call request, generate or import the work key of the application in the HCE-TEE engine or inSE, and encrypt the work key in the hardware engine, and send The ciphertext structure of the encrypted work key is returned to the App.
  • the calling request such as a calling request for generating or importing a work key
  • the HCE-REE cryptographic service can also be used to receive an APP call request to the HUKS interface (which can carry the ciphertext structure), and in response to the call request (such as a call request for encrypting and decrypting application data),
  • the HCE-REE driver can encrypt and decrypt the application data based on the ciphertext structure.
  • the HCE-REE engine can be used to decrypt the working key ciphertext generated by the HCE-TEE engine or inSE (that is, the key ciphertext in this article), and use the decrypted working key plaintext (that is, the key plaintext) to encrypt and decrypt the application data of the App.
  • HiCrypto CA Client Application, client application
  • HiCrypto TA Trusted Application, trusted application
  • TA Transaction Application, trusted application
  • HiCrypto CA and HiCrypto TA can run on the ACPU (Application CPU, application processor) of a terminal device (such as a mobile phone).
  • the inSE has an independent CPU, therefore, the inSE cryptographic service (HiCrypto SA (Secure Application, security application, referring to the application of inSE), hereinafter referred to as SA) runs on the independent CPU of the inSE.
  • HiCrypto SA Secure Application, security application, referring to the application of inSE
  • HCE-TEE cryptographic service, HCE-TEE driver, and HCE-TEE engine are all running in the TEE; App, HUKS interface, HCE-REE cryptographic service, HCE-REE driver, and HCE-TEE
  • the REE engine runs in the REE; the inSE cryptographic service, SEE OS, and inSE all run in the SEE.
  • inSE is an optional hardware structure in a multi-hardware cryptographic engine system, so the inSE cryptographic service, SEE OS, and inSE shown in the dashed box in Figure 2 are also optional in the system architecture.
  • a function call request for generating or importing a working key may be triggered to generate or import a key in the HCE-TEE engine or inSE (or import a key in the HCE-REE engine) ; and in the case that the terminal device is not restarted, the application can trigger the function call request for encrypting and decrypting the application data multiple times, so that the HCE-REE engine uses the generated or imported key to perform multiple executions on the application data Encryption and decryption operations.
  • the function interface for generating the work key may be different from the function interface for importing the work key.
  • the App when the App requests to encrypt and decrypt the application data, it may be implemented through a one-stage function call or a three-stage function call.
  • the App can carry the data to be encrypted and decrypted and the above-mentioned ciphertext structure in the called function, so that the HCE-REE engine can decrypt the ciphertext structure to obtain the plaintext of the App's working key, and use
  • the plain text of the work key is used to encrypt and decrypt the data to be encrypted and decrypted, and return the encryption and decryption results of the application data to the App.
  • the App can call the first function (such as CryptoInit()) to pass the ciphertext structure to the HCE-REE engine, and the HCE-REE engine can decrypt the ciphertext structure and write the plaintext of the obtained working key into the A described below. class register, and returns the handle of the class A register to the App. Wherein, the handle can be used to identify the class A register in which the plaintext of the work key is written.
  • the first function such as CryptoInit()
  • the App can call the second function (such as CryptoUpdate()) to pass in the handle of the Class A register and the data to be encrypted and decrypted to the HCE-REE engine.
  • Class A register and use the work key plaintext in the class A register to perform encryption and decryption operations on the data to be encrypted and decrypted, and return the encryption and decryption structure of the application data to the App.
  • the App can call a third function (such as CryptoFinal()) to pass in the handle of the Class A register, so that the HCE-REE engine can release the Class A register that stores the plaintext of the working key of the App, such as clearing the Class A register pointed to by the handle data in the register.
  • a third function such as CryptoFinal()
  • the App may call the second function multiple times to perform multiple encryption and decryption operations on the application data.
  • the multi-hardware cryptographic engine is implemented based on the self-developed SoC platform, and the plaintext of the application key only appears inside the hardware cryptographic engine, so that the plaintext of all application keys
  • the hardware is used so that the plaintext of the application key will not be exposed to the ACPU (Application CPU, application processor, A core), so it is difficult for malicious applications using the ACPU to steal the plaintext key of the application, which improves the security of the application key.
  • the HCE-REE engine can obtain the working key ciphertext of the application encrypted by the HCE-TEE engine or inSE, and decrypt it to obtain the plaintext of the working key; and, the application in the REE environment can call HiCrypto CA through the SDK interface,
  • the HCE-REE engine can be directly operated without going through other engines, so that the plain text of the working key can be used inside the HCE-REE engine to encrypt and decrypt application data.
  • the encryption and decryption process of application data can be realized in the REE environment without switching the environment to TEE or SEE, which can reduce the loss of channel performance and improve the performance of encryption and decryption. Therefore, the multi-hardware cryptographic engine system of the embodiment of the present application can take into account high application security and high encryption and decryption performance.
  • the components included in the hardware abstraction layer, kernel layer, and hardware layer shown in FIG. 1 do not constitute specific limitations on the multi-hardware cryptographic engine system of the embodiment of the present application.
  • the system may also include more or fewer components than shown in the illustrations, or combine some components, or separate some components, or arrange different components.
  • FIG. 3 exemplarily shows a schematic diagram of an interaction process between the multi-hardware encryption engines in the embodiment of the present application.
  • the multi-hardware cryptographic engine of SoC may include HCE-REE engine and HCE-TEE engine, then the module of HCE-TEE engine/inSE shown in Figure 3 is used to represent HCE -TEE engine.
  • the multi-hardware cryptographic engine of SoC can include HCE-REE engine and HCE-TEE engine and inSE, then the module of HCE-TEE engine/inSE shown in Figure 3 is used to represent inSE, then in The HCE-TEE engine is not shown in FIG. 3 .
  • modules of the HCE-TEE engine/inSE shown in Fig. 4a, Fig. 8, and Fig. 9 are similar to the engines expressed by the modules of the HCE-TEE engine/inSE shown in Fig. 3, and in different embodiments , which can express different hardware engines.
  • the security subsystem can include AO (Always On, normally open, not power-off) register (also known as SessionKey register), AO register and HCE-TEE engine, HCE-REE engine, inSE (in multiple hardware Engines including inSE case) are hardwired (a chip-level connection).
  • AO Always On, normally open, not power-off
  • HCE-TEE engine also known as SessionKey register
  • HCE-REE engine HCE-REE engine
  • inSE in multiple hardware Engines including inSE case
  • the AO register writes data once when the multi-hardware cryptographic engine system is initialized, and the AO register is not powered off, unreadable by software and locked for writing, for example, the size is 256 bits.
  • the HCE-TEE engine can include TRNG, KM (Key Management, key management) encryption module.
  • TRNG can be used to generate random numbers.
  • the encryption algorithm used by the KM encryption module includes but is not limited to AES (Advanced Encryption Standard, advanced encryption standard, a symmetric encryption algorithm), SM4 (SM4algorithm, SM4 algorithm, a symmetric block cipher algorithm), and can also include sufficient security strength Other symmetric block cipher algorithms.
  • AES Advanced Encryption Standard
  • SM4 SM4algorithm
  • SM4 algorithm SM4 algorithm
  • a symmetric block cipher algorithm a symmetric block cipher algorithm
  • the KM encryption module can be used to use the GCM mode of the AES or SM4 algorithm to perform encryption operations, but the specific algorithm of the authentication encryption algorithm used by the KM encryption module in the present application is not limited to the GCM mode of AES or SM4, Other authentication encryption algorithms can also be used.
  • the inSE may include TRNG and KM encryption modules, whose functions are the same as those described above for the internal modules of the HCE-TEE engine, and will not be repeated here.
  • the HCE-REE engine can include a KM decryption module, a class A register, and a data encryption and decryption module, as shown in the dotted line in the HCE-REE engine of Figure 3, and the HCE-REE engine can optionally include a class B register .
  • dotted lines in Fig. 3 are used to represent optional modules and optional operations of the multi-hardware cryptographic engine.
  • the KM decryption module can be used to use the GCM mode of the AES or SM4 algorithm to perform a decryption operation.
  • the specific algorithm of the authentication decryption algorithm used by the KM decryption module in this application is not limited to AES or SM4
  • the GCM mode can also be other authentication decryption algorithms.
  • the type A register is used to set the ciphertext key entering the HCE-REE engine, which is unreadable and unwritable by software. It should be noted that the data stored in the class A register is the plaintext format of the ciphertext key, that is, the key plaintext shown in FIG. 3 .
  • the number of A-type registers can be one or more.
  • the HCE-REE engine includes n A-type registers from Key slot1 to Key slot n, n is a positive integer, and the specific value of n is not limited.
  • the number of Class A registers can be flexibly configured according to actual needs.
  • the type B register is used to set the plaintext key entering the HCE-REE engine, which is writable by software but not readable.
  • the number of type B registers may be one or more, and the specific number may be flexibly configured according to actual requirements.
  • the multiple B-type registers can be used to store plaintext keys (ie, plaintext work keys) for different applications respectively.
  • a class B register (such as Key slot 0) will be described as an example.
  • the HCE-TEE engine, HCE-REE engine, and inSE can transmit information such as data, instructions, or keys through the shared memory shared by the three hardware cryptographic engines.
  • shared memory may include but not limited to: DDR (DDR SDRAM, double-rate synchronous dynamic random access memory), NVM (Non-volatile memory, non-volatile memory, no loss of data when power off no lost memory).
  • DDR DDR SDRAM, double-rate synchronous dynamic random access memory
  • NVM Non-volatile memory, non-volatile memory, no loss of data when power off no lost memory.
  • the internal modules of the above three hardware encryption engines in FIG. 3 can be controlled by the respective software services of the three hardware encryption engines shown in FIG. 2 when performing their respective functions.
  • the CA can call the TA, and the TA calls the HCE-TEE driver to make the HCE-TEE engine or inSE execute the process performed by the HCE-TEE engine shown in Figure 3; or, the CA can call the SA, and the SA calls SEE OS, to make inSE execute the process of inSE execution shown in Figure 3.
  • the CA can invoke the HCE-REE driver to make the HCE-REE engine execute the process performed by the HCE-REE engine shown in FIG. 3 .
  • the TRNG inside the HCE-TEE engine can randomly generate the root key , and directly set the root key into the AO register through hard-wired methods such as DMA (Direct Memory Access, direct memory access).
  • DMA Direct Memory Access, direct memory access
  • root key described herein is used to represent the encryption key of the working key of the application.
  • the above-mentioned process performed by the TRNG can be triggered by software, for example, in the stage where the terminal device starts the BootLoader, the BootLoader controls the TA in Figure 2, and the TA in Figure 2 invokes the HCE-TEE driver to Trigger TRNG to implement the above process to improve the flexibility of the root key generation method.
  • the terminal device starts the BootLoader stage, that is, when the multi-hardware cryptographic engine system is initialized, TA calls the HCE-TEE driver to control the TRNG to generate the root key, and controls the process of TRNG writing the root key into the AO register, which will make the root key Enter the memory of the TEE during the short window period of the bootloader stage of the terminal device.
  • the process of generating the root key for TRNG and setting the generated root key to the AO register can be configured without triggering by software TRNG automatically generates the root key when the system is powered on, and writes the root key into the AO register.
  • the KM encryption module in the HCE-TEE engine can read the root key from the AO register, and use the root key to apply the working key plaintext (that is, Figure 3 and The key plaintext described in subsequent embodiments) is encrypted, and the encryption result of the key plaintext is sent to the shared memory.
  • the working key plaintext that is, Figure 3 and The key plaintext described in subsequent embodiments
  • the key plaintext in the HCE-TEE engine in Figure 3 can be imported into the HCE-TEE engine by the application (it can be imported with key encapsulation or key encapsulation), or it can be generated by the HCE-TEE engine. This application does not limit this.
  • the TRNG inside the HCE-TEE engine can randomly generate the root key , and directly set the root key into the AO register through hard-wired methods such as DMA.
  • root key described herein is used to represent the encryption key of the working key of the application.
  • the above-mentioned process performed by the TRNG can be triggered by software, for example, in the stage where the terminal device starts the BootLoader, the BootLoader controls the TA in Figure 2, and the TA in Figure 2 invokes the HCE-TEE driver to Trigger TRNG to implement the above process to improve the flexibility of the root key generation method.
  • the process of generating a root key for the TRNG and setting the generated root key to the AO register may not be triggered by software, and the TRNG is configured to automatically execute the above process during the system power-on phase.
  • the KM encryption module in the inSE can read the root key set by the TRNG from the AO register, and use the root key to encrypt the plaintext of the working key of the application (that is, Figure 3 and subsequent implementation
  • the key plaintext described in the example is encrypted, and the encryption result of the key plaintext (which can be the ciphertext structure described below, or the ciphertext result of the key plaintext) is sent to the shared memory.
  • inSE in Figure 3 can be imported to inSE by an application (key encapsulation or import without key encapsulation), or can be generated by inSE, which is not limited in this application.
  • the CA can call the SA according to the process shown in Figure 2, to trigger inSE to execute the above process shown in FIG. 3 .
  • the CA can call the TA according to the flow shown in FIG. 2 to trigger the HCE-TEE engine to execute the above process shown in FIG. 3 to ensure the balance of performance and security.
  • the KM decryption module can be used to read the encryption result of the key plaintext written by the inSE or HCE-TEE engine from the shared memory, and to read the root key from the AO register, and to use the root key
  • the encrypted result is decrypted to obtain the key plaintext, which is used to send the key plaintext to the Class A register.
  • the data encryption and decryption module can be used to read the key plaintext from the class A register; and use the key plaintext to encrypt the data plaintext to generate data ciphertext; or use the key plaintext to decrypt the data ciphertext to generate data plaintext .
  • the HCE-REE engine of the embodiment of the present application reserves a channel for setting the B-type register of the working key plaintext, so that the application in the REE can transfer the key plaintext to the shared memory, and the CA can control the HCE-REE
  • the REE driver reads the key plaintext imported by the application from the shared memory, and writes the key plaintext into the B-type register.
  • the data encryption and decryption module in the HCE-REE engine can be used to read the key plaintext from the B-type register, and use the key ciphertext to perform data encryption and decryption operations, without switching the operating environment to TEE or SEE, which can improve data encryption and decryption performance.
  • AO registers unreadable, write-locked hard-wired connections (chip-level connections) can be provided for use by multiple hardware cryptographic engines, so that when the working key of the application is transmitted between multiple hardware cryptographic engines, it can be used by
  • the true random number protection randomly generated by the HCE-TEE engine or TRNG in inSE every time the terminal device is turned on can enable the safe transmission of the working key between multiple hardware cryptographic engines, and the plaintext of the working key does not leave the hardware throughout the process, improving encryption. key security.
  • multiple hardware encryption engines can be effectively decoupled in design, and can run independently without affecting each other, which is conducive to maximizing performance.
  • the AO register can be used to store the root key (the encryption and decryption key of the working key of the application), so that when the root key is transmitted between the HCE-TEE engine, the HCE-REE engine, and the inSE through the AO register , the ACPU is invisible, reaching the security level of hardware isolation.
  • Fig. 4a exemplarily shows a working flow chart of a multi-hardware cryptographic engine system in a key generation scenario.
  • Fig. 4b exemplarily shows a sequence diagram of a key encryption process of a multi-hardware cryptographic engine system.
  • Fig. 4a a system workflow combining the key authentication scheme with the system architecture of the embodiment of the present application is described.
  • the multi-hardware cryptographic engine system of the embodiment of the present application can also include the key authentication scheme described in Figure 4a according to business requirements, and the following text will not go into details for each scenario one by one.
  • the key authentication scheme please refer to the authentication scheme described in this embodiment.
  • the authentication encryption algorithm used in the key authentication scheme of this embodiment is GCM (Galois/Counter Mode, Galois Counter Mode, a block cipher algorithm mode), but this application does not refer to the authentication encryption algorithm Make specific restrictions.
  • the authenticated encryption algorithm used by the KM encryption module and the KM decryption module in FIG. 4a may be the GCM mode of the AES or SM4 algorithm.
  • the GCM mode of SM4 can be used for authentication encryption to ensure the integrity of plaintext or other authentication content.
  • the encryption can include but not limited to the following parameters: IV value, TAG, optionally including additional authentication data (AAD, Additional Authentication Data) .
  • AAD data can be used for authentication and anti-counterfeiting.
  • the length of the IV value may be 12 bytes, but this application does not limit the length of the IV value.
  • TAG is a message authentication code in GCM mode, used to verify the integrity of encrypted data and AAD, and the length of TAG in GCM mode is at least 12 bytes, preferably 16 bytes.
  • this system encrypts the sensitive data of the application (that is, the application plaintext data to be encrypted), if there is data that needs to protect integrity but does not need to protect confidentiality (such as program context data), it can be used as an AAD parameter , to protect its integrity.
  • Figure 4a when the HCE-TEE engine and inSE are used for password generation, the internal modules have similar functions. Therefore, in Figure 4a, the internal modules of the two hardware cryptographic engines are described in a block diagram, in order to facilitate readers' understanding , Figure 4b and Figure 4c take the HCE-TEE engine to execute the key generation and key encryption process shown in Figure 4a as an example, but it should be noted that inSE executes the process shown in Figure 4a and the HCE-TEE engine The executed processes are similar, and reference may be made to the descriptions in FIG. 4b and FIG. 4c , which will not be repeated hereafter.
  • the TA controls the HCE-TEE engine to generate a root key by invoking the HCE-TEE driver.
  • the HCE-TEE engine generates a root key, and writes the root key into the AO register.
  • TRNG can generate a random number as the root key, and write it into the AO register in a hard-wired manner, as described in the embodiment of Figure 3, this process can be controlled by software (here The implementation of S101 and S103 is controlled by software) or automatically executed by TRNG, which is not limited in this application.
  • the root key of the application when the root key of the application is written into the AO register under software control, the root key can not only be a random number generated by TRNG, but also be derived from the hardware root key according to the derived component root key, for example, the hardware root key shown in Figure 9(1) can be derived (the derived component can be the same as or different from the derived component in 9(1)) to obtain the root key written into the AO register, etc. , this application does not limit the specific generation method of the root key written in the AO register.
  • the App triggers a key generation request by calling the HUKS interface, and sends the key generation request to the CA.
  • the App may call the HUKS interface to call the CA.
  • the embodiment of this application describes a one-stage function call, so the first encryption request triggered by the App may include but not limited to: data to be encrypted and decrypted (take the data to be encrypted as an example, the data to be encrypted is the HCE-REE engine in Figure 4a
  • the data plaintext) information optionally, may also include AAD parameters.
  • the AAD parameters may include but not limited to: App program context data (including but not limited to package name), KeyAlias and key parameters of App work key, etc.
  • the CA sends a first call request to the TA in response to the key generation request.
  • the TA may control the HCE-TEE engine to generate a work key and encrypt the work key by calling the HCE-TEE driver in response to the first call request.
  • the AAD parameter in the first call request can be written into the HCE-TEE engine through software control.
  • the HCE-TEE engine generates a working key (that is, the key plaintext in Figure 4a), and obtains authentication parameters.
  • the TRNG of the HCE-TEE engine can generate a random number as a working key, that is, key plaintext.
  • the method for generating the key plaintext by the HCE-TEE engine is not limited to using TRNG, but can also be realized by other methods, and the specific method can be flexibly configured according to needs.
  • the authentication parameters here may include but not limited to: the IV value generated by the TRNG in the HCE-TEE engine, and the AAD parameter passed in by the application.
  • the HCE-TEE engine can read the root key from the AO register, and use the root key to encrypt the plaintext of the key to obtain a ciphertext structure.
  • the KM encryption module of the HCE-TEE engine can use the GCM mode to use the IV value and the root key read from the AO register to encrypt the data to be encrypted (including key plaintext here) , generate the key ciphertext; and the KM encryption module calculates the TAG for the key ciphertext and AAD. Finally, the ciphertext structure (including IV, key ciphertext, TAG and AAD parameters) is obtained.
  • the HCE-TEE engine writes the ciphertext structure into the shared memory.
  • the shared memory may include a storage area that loses data when power fails (eg, DDR), and a storage area that does not lose data when power fails (eg, NVM).
  • DDR storage area that loses data when power fails
  • NVM storage area that does not lose data when power fails
  • the KM encryption module can write the generated ciphertext structure into the DDR.
  • a HUK (Hardware Unique Key, hardware unique key) encryption module is also configured in the HCE-TEE engine, and the HUK encryption module can be configured with hardware Unique key (i.e. hardware root key). Then the HUK encryption module can use the key derived from the hardware root key to encrypt the key plaintext and generate the key ciphertext', here the ciphertext of the key plaintext is named key ciphertext', which is used to distinguish the Key ciphertext in DDR.
  • hardware Unique key i.e. hardware root key
  • Key ciphertext' is used to represent the working key ciphertext obtained by encrypting the key plaintext using the key derived from the hardware root key by the HUK encryption module shown in Figure 4a as the encryption key.
  • the key ciphertext (such as the key ciphertext in the DDR in Figure 4a) is used to represent the working key ciphertext after the key plaintext is encrypted with the root key in the AO register as the encryption key.
  • This application can provide two keys for encrypting and decrypting the plaintext of the working key, one is the root key randomly generated by TRNG, and the other is the key derived from the hardware root key, which is written into AO generated by TRNG The random number in the register is used as the root key, which is more secure.
  • the HUK encryption module can write the generated key ciphertext ' into the NVM safe storage area, so that after power failure, the HUK encryption module can also read the working key from the NVM safe storage area.
  • Ciphertext is used for encryption and decryption of application data to improve the reliability of data encryption and decryption.
  • the HUK encryption module is not configured with an authenticated encryption algorithm such as GCM, but only a non-authenticated encryption algorithm. Then for authentication, if the system is powered off, the HUK encryption module can read the key ciphertext’ from the NVM safe storage area, and use the unique hardware key to decrypt it to obtain the key plaintext. Then encrypt in GCM mode through the KM encryption module, and write the ciphertext structure into DDR.
  • an authenticated encryption algorithm such as GCM
  • the HUK encryption module can also be configured with an authentication encryption algorithm including but not limited to GCM, so that the ciphertext structure generated by the HUK encryption module is also with authentication data (for example, including IV, key password, etc.) Text', TAG, AAD, etc.).
  • authentication data for example, including IV, key password, etc.
  • the ciphertext structure of the NVM safe storage area can be directly used to write to the HCE-REE engine.
  • the write address of the ciphertext structure in the shared memory can be configured by the CA as a parameter in the first call request of S202, and then passed to the HCE-TEE driver through S203 to control the HCE-TEE engine.
  • the write address of the ciphertext structure in the shared memory can be configured by the TA as a parameter of S203, and after S205, the TA can return the address information of the ciphertext structure to the CA.
  • the ciphertext structure may be returned to the App as a handle.
  • the process also includes: S2062, the CA may respond to the key generation request, and return the address information of the App's ciphertext structure in the shared memory to the App.
  • the App can read the ciphertext structure from the shared memory according to the address information, and carry it when requesting to encrypt and decrypt application data.
  • the application can trigger a key generation request to trigger the execution of the process shown in Figure 4b, so as to implement the encryption of the working key of the application, and return the ciphertext structure of the working key to the application as a response result.
  • the application can carry the ciphertext structure to request encryption and decryption of the application data through one-segment or segmented function calls.
  • FIG. 4 c taking an App as an example through a one-stage function call, it exemplarily shows a sequence diagram of a key usage process of a multi-hardware cryptographic engine system.
  • the App uses the ciphertext structure returned by the process in Figure 4b to request the process of encrypting application data, which may include:
  • the App triggers a data encryption request by calling the HUKS interface
  • the App can write the ciphertext structure into the shared memory, and carry the address information of the ciphertext structure in the shared memory to the data encryption request.
  • the App may write plaintext data into the shared memory, and carry the address information of the plaintext data in the shared memory to the data encryption request.
  • the CA may control the HCE-REE engine to read the data plaintext of the App by invoking the HCE-REE driver.
  • the HCE-REE engine reads data plaintext from the shared memory.
  • the data plaintext information in the data encryption request can be the address information of the data plaintext (also known as the source address), and the above App in the REE environment can write the data plaintext into the shared memory, and store the data plaintext in the shared memory
  • the address (that is, the source address) is carried to the data encryption request, so that the HCE-REE engine can be controlled by the HCE-REE driver to read the plaintext data from the source address.
  • the CA controls the HCE-REE engine to read the ciphertext structure by invoking the HCE-REE driver in response to the data encryption request.
  • the CA can obtain the address information of the App's ciphertext structure in the shared memory based on the data encryption request; and the CA can pass the address information of the ciphertext structure as a parameter through S209 to control the HCE-REE The engine reads the ciphertext structure from the shared memory.
  • the HCE-REE engine reads the ciphertext structure from the shared memory.
  • the KM decryption module in the HCE-REE engine can read the application's ciphertext structure (including IV, key ciphertext, TAG, AAD parameters) from the DDR.
  • the application's ciphertext structure including IV, key ciphertext, TAG, AAD parameters
  • the HCE-REE engine reads the root key from the AO register, uses the root key to decrypt the ciphertext structure, and obtains the key plaintext.
  • the KM decryption module in the HCE-REE engine can not only decrypt the key ciphertext to obtain the key plaintext, but also perform authentication.
  • the KM decryption module can be used to calculate TAG' to compare whether TAG' is the same as the TAG read from DDR. If they are the same, it means that the key plaintext and AAD are complete, so as to realize the authentication and Anti-Counterfeiting.
  • the KM decryption module can calculate the TAG' for the key ciphertext and AAD read from the DDR, and compare whether the TAG' is the same as the TAG read from the DDR. If they are the same, the authentication passes, otherwise the authentication fails.
  • the KM decryption module can use the root key read from the AO register and the IV value read from the DDR to decrypt the obtained key ciphertext to obtain the key plaintext.
  • the key plaintext can be written into the above-mentioned type A register.
  • the HCE-REE engine uses the key plaintext to encrypt the data plaintext to obtain the data ciphertext.
  • the data encryption and decryption module in the HCE-REE engine can use the key plaintext to encrypt the data plaintext of the App to obtain the data ciphertext.
  • the encryption algorithm may include but not limited to AES, SM4 and so on.
  • the HCE-REE engine writes the data ciphertext to the shared memory.
  • the data encryption request triggered by the App in S215 may also include a target address for writing data ciphertext.
  • the HCE-REE engine may write data ciphertext to the target address in the shared memory in response to the data encryption request.
  • the CA also controls the execution of the HCE-REE engine by invoking the HCE-REE driver in response to the data encryption request.
  • the App directly reads the data ciphertext from the shared memory.
  • the App can directly read the data ciphertext from the target address without going through the password service of the embodiment of the present application.
  • the process of FIG. 4c can be executed again.
  • the App when the App triggers the request, it can carry the ciphertext structure of the App, so that the CA can use the ciphertext structure for authentication and decryption, and use the authenticated and decrypted key plaintext for data encryption and decryption.
  • the App can send the ciphertext structure (the ciphertext structure returned to the App by the CA when executing the process in Figure 4b) ) into the shared memory in Figure 4a, and carry the address information of the ciphertext structure in the shared memory as a parameter in the data encryption request in S215, then the CA can use the address information of the ciphertext structure passed in by the App to call
  • the HCE-REE driver controls the HCE-REE engine to read the ciphertext structure from the shared memory for data encryption and decryption in the REE environment.
  • the HCE-TEE engine or inSE in the scenario of key generation, the HCE-TEE engine or inSE generates a working key for an application and encrypts the generated working key.
  • the App sends data encryption and decryption requests to the HCE-REE engine based on the ciphertext structure generated by the HCE-TEE engine or inSE through a one-step function call, and the HCE-REE engine can use the ciphertext structure Implement encryption and decryption of application data.
  • the App only needs to trigger a function call once, and the system of the embodiment of the present application can implement data encryption and decryption of the App.
  • the working key of the App can remain unchanged, so after the App triggers a key generation request, the system can return the generated ciphertext structure to the App.
  • the App can use the ciphertext structure bound to the App and its work key to operate the HCE-REE engine through the CA and HCE-REE drivers to perform data encryption.
  • Decryption so that data encryption and decryption do not need to be switched to TEE or SEE, and the ciphertext structure can be used to encrypt and decrypt data in the REE environment, effectively reducing channel performance loss and improving data encryption and decryption performance.
  • the HCE-REE engine authenticates and decrypts the ciphertext structure passed in by the App, and uses the authenticated and decrypted -Data encryption and decryption are performed in the REE engine, so that the working key can achieve hardware-level security during use, and the use of the working key is only completed in the REE, without switching to TEE or SEE, and does not affect the encryption and decryption performance.
  • the HCE-REE engine in the REE environment can use the AO register under the condition that the HCE-TEE engine and inSE do not participate. root key, decrypt and authenticate the key ciphertext, and then write the decrypted and authenticated key plaintext into the Class A register to perform encryption and decryption operations on the application data that needs to be encrypted and decrypted this time, which can avoid the execution environment Switching from REE to TEE or SEE can effectively reduce path performance loss and further improve data encryption and decryption performance.
  • the App only needs to trigger a key generation request once to execute the process in Figure 4b. Every time the App needs to encrypt and decrypt data, it does not need to execute the process in Figure 4b. It only needs to pass One-stage function call to trigger the execution of the process in Figure 4c to perform data encryption and decryption.
  • the number of A-type registers in Figure 4a can be 1 to reduce the size of the chip area.
  • the ciphertext structure in the DDR in Figure 4a (example may include IV, key ciphertext, TAG, AAD), under the protection mechanism of the Linux kernel, the ciphertext
  • the structure is only visible to this app, and not to other apps, thus preventing other apps from encrypting and decrypting the data of this app.
  • FIG. 5 taking an App as an example through a three-segment function call, it exemplarily shows a working flow chart of a cryptographic use process of a multi-hardware cryptographic engine system.
  • FIG. 6 and FIG. 7 show the sequence diagrams of the key usage process of the multi-hardware cryptographic engine system under the three-stage function call scenario.
  • FIG. 5(1) and FIG. 6 show the process of the first function call in the three-segment function call scenario.
  • the App can obtain the ciphertext structure of the working key of the App generated by the HCE-TEE engine or inSE by triggering a key generation request, and the App can generate the key based on the process shown in Figure 4b.
  • call the first function such as CryptoInit()
  • the HCE-REE engine can decrypt the ciphertext structure and write the obtained working key plaintext into the following In the class A register, and return the handle of the class A register to the App.
  • the handle can be used to identify the class A register in which the plaintext of the work key is written.
  • the processing to the first function may include:
  • the App triggers a first function request by calling the HUKS interface.
  • the first function request may include the ciphertext structure returned to the App in FIG. 4b.
  • the App can write the ciphertext structure into the shared memory, and carry the address information of the ciphertext structure in the shared memory to the first function request.
  • the function interface requested by the first function may be CryptoInit().
  • the App can write the ciphertext structure of the working key (for example, including IV, key ciphertext, TAG, and AAD parameters) into the DDR.
  • the working key for example, including IV, key ciphertext, TAG, and AAD parameters
  • the CA controls the HCE-REE engine to read the ciphertext structure by calling the HCE-REE driver in response to the first function request.
  • the HCE-REE engine reads the ciphertext structure from the shared memory.
  • the KM decryption module in the HCE-REE engine can read the ciphertext structure of the application (for example, including IV, key ciphertext, TAG, AAD parameters) from the DDR.
  • the ciphertext structure of the application for example, including IV, key ciphertext, TAG, AAD parameters
  • the HCE-REE engine reads the root key from the AO register, uses the root key to decrypt the ciphertext structure, and obtains the key plaintext.
  • the KM decryption module in the HCE-REE engine can not only decrypt the key ciphertext to obtain the key plaintext, but also perform authentication.
  • the HCE-REE engine writes the key plaintext into the A-type register.
  • the key plaintext can be written into the above-mentioned type A register.
  • the number of Class A registers here is n, including Key slot 1 to Key slot n, where n is a positive integer greater than 1.
  • the KM decryption module here writes the key plaintext into Key slot 1 .
  • the CA controls the HCE-REE drive, and the HCE-REE drive then controls the HCE-REE engine.
  • the HCE-REE driver can select the target Key slot register allocated to the App from the n class A registers, so as to control the KM decryption module to write the key plaintext of the App Target Key slot register, such as Key slot 1 in Figure 5(1).
  • each class A register can be used to store a key plaintext.
  • the HCE-REE driver When the HCE-REE driver allocates A-type registers to an App key in clear text, it can dynamically allocate A-type registers, for example, use an empty A-type register that does not store any data as the allocation object, or it can also allocate A according to the application.
  • Class A registers for example, each application can have a unique Class A register, or, Class A registers can also be allocated according to the business type of the application, for example, if the work keys of different business types of the same application are different, then the different The working key of the service can be written into different A-type registers respectively.
  • the HCE-REE driver may respond to the first function request, and return the handle information of the type A register to the App through the CA.
  • the KM decryption module in Figure 5 (1) is controlled by the HCE-REE driver, and after the key plaintext is written into Key slot1, it can return information to notify the HCE-REE driver that the data is written into the register successfully. Then the HCE-REE driver can send the handle (handle) used to identify Key slot 1 in the HCE-REE engine to the App via the CA.
  • handle of the type A register can uniquely identify a type A register.
  • the handle may be a random number of a certain length, and the random number may include a flag bit for identifying the type A register and a data bit (wherein, the data bit is random data).
  • the HCE-REE driver responds to the App's data encryption and decryption request, it can determine the Class A register through the flag bit of the handle in the encryption and decryption request. The difficulty of stealing the working key can be enhanced by setting the data bit in the handle.
  • the handle may not include the above-mentioned flag bit, but may include a random number.
  • the HCE-REE driver may store the corresponding relationship between the handle of the A-type register and the identification information of the A-type register. In the stage of using the working key, the corresponding relationship can be used to determine the type A register that stores the key plaintext.
  • this application does not limit the timing of generating the handle of the A-type register by the HCE-REE driver.
  • the HCE-REE driver allocates the target Key slot register to the App in response to the first function request, it can generate the handle that can identify the register.
  • the handle of the target Key slot register can also generate a handle that can identify the target Key slot register after the KM decryption module writes the key plaintext into the target Key slot register.
  • the application’s work key can be configured in the A-type register of the HCE-REE engine by triggering the call request of the first segment of the function, and the handle of the A-type register It is returned to the application to be used by the application for multiple subsequent requests to encrypt and decrypt the requested data.
  • FIG. 5(2) and FIG. 7 show the process of the second-stage function call in the three-stage function call scenario.
  • the App can call the second function (such as CryptoUpdate()) to pass in the handle of the A-type register and the data to be encrypted and decrypted to the HCE-REE engine, and the HCE-REE engine can find the The Class A register that stores the plaintext of the working key of the App, and use the plaintext of the working key in the Class A register to perform encryption and decryption operations on the data to be encrypted and decrypted, and return the encryption and decryption structure of the application data to the App.
  • the second function such as CryptoUpdate()
  • processing to the second function may include:
  • the App triggers a second function request by calling the HUKS interface, and sends the second function request to the CA.
  • the App may receive handle information for identifying Key slot 1, and then the App may trigger a second function request according to business requirements.
  • the second function request may include but not limited to: the source address of the data to be encrypted (for example, the data plaintext in FIG. 5(2) ), and the handle information of the Key slot used to identify Key slot 1.
  • the CA may control the HCE-REE engine to read the data plaintext (that is, the data to be encrypted) of the App by calling the HCE-REE driver.
  • the HCE-REE engine reads data plaintext from the shared memory.
  • the second function request can carry the address information of the data plaintext (also known as the source address), and the above App in the REE environment can write the data plaintext into the shared memory, and write the address of the data plaintext in the shared memory (That is, the source address) is carried to the second function request, so that the data encryption and decryption module in the HCE-REE engine in Figure 5(2) can be driven and controlled by the HCE-REE, and read data plaintext from the source address.
  • the data plaintext also known as the source address
  • the above App in the REE environment can write the data plaintext into the shared memory, and write the address of the data plaintext in the shared memory (That is, the source address) is carried to the second function request, so that the data encryption and decryption module in the HCE-REE engine in Figure 5(2) can be driven and controlled by the HCE-REE, and read data plaintext from the source address.
  • the CA may further control the HCE-REE driver to determine the target register according to the handle information in response to the second function request.
  • the second function request carries a handle used to identify the Class A register Key slot 1, for example, the handle includes flag bits and data bits, then the HCE-REE driver can determine the target register according to the flag bits in the handle It is the key slot 1 of the class A register, thereby controlling the HCE-REE engine to execute S404.
  • the HCE-REE engine can read the key plaintext from the target register.
  • the data encryption and decryption module in the HCE-REE engine can be driven and controlled by the HCE-REE to obtain the handle of the Key slot passed in by the App, so that according to the handle of the Key slot, To read key plaintext from Key slot 1.
  • the HCE-REE engine uses the key plaintext to encrypt the data plaintext to obtain the data ciphertext.
  • the data encryption and decryption module in the HCE-REE engine can use the key plaintext to encrypt the data plaintext of the App to obtain the data ciphertext.
  • the encryption algorithm may include but not limited to AES, SM4 and so on.
  • the HCE-REE engine writes the data ciphertext to the shared memory.
  • the second function request triggered by the App in S401 may also include a target address for writing data ciphertext.
  • the HCE-REE engine may write the data ciphertext into the target address in the shared memory.
  • the CA may also control the execution of the HCE-REE engine by invoking the HCE-REE driver in response to the second function request.
  • the App directly reads the data ciphertext from the shared memory.
  • the App can directly read the data ciphertext from the target address without going through the password service of the embodiment of the present application.
  • the data encryption and decryption module may include m data encryption and decryption modules, where m is a positive integer greater than 1.
  • m and n may be the same or different, which is not limited in the present application.
  • the functions of the m data encryption and decryption modules are the same, and the algorithms used (including but not limited to AES, SM4) can be different.
  • m data encryption and decryption modules can operate in parallel to perform multiple encryption and decryption tasks of application data, so as to support the use of multiple working keys for data encryption and decryption.
  • multiple encryption and decryption tasks executed in parallel may involve different applications, or different services of the same application.
  • the HCE-REE engine can improve data encryption and decryption performance in a multi-core manner with multiple data encryption and decryption modules.
  • any data encryption and decryption module among the m data encryption and decryption modules needs to switch the key plaintext used when switching the encryption and decryption tasks, then only need to pass It only needs to switch the identification (for example, index) of the A-type register read by the data encryption and decryption module, and the key switching overhead of the data encryption and decryption module can be reduced by means of multiple A-type registers.
  • the App can trigger a third function request (for example, CryptoFinal()) by calling the HUKS interface.
  • the third function request can carry the identification A The handle of the class register Key slot 1, so that the HCE-REE engine can clear the class A register pointed to by the handle, that is, the data in Key slot 1 in Figure 5 (2), to release a class A register resource.
  • the working key of the application can be configured in the A-type register of the HCE-REE engine, and the handle identifying the A-type register is returned to the application. Then, when the terminal device is not restarted, when the application needs to perform data encryption and decryption multiple times, the application can trigger the second function call request multiple times, and carry the handle to the second function call request.
  • the HCE-REE engine To enable the HCE-REE engine to use the key plaintext in the class A register identified by the handle for encryption and decryption of application data.
  • each time the HCE-REE engine encrypts and decrypts application data it does not need to read from the shared memory to identify the application and work.
  • the ciphertext structure of the key does not need to be authenticated and decrypted each time, which can greatly improve the data encryption and decryption performance of the HCE-REE engine.
  • inSE is used to generate the working key of the application
  • inSE since inSE has an independent on-chip CPU, the plaintext of the working key (that is, the plaintext of the key) can be made out of the hardware in the whole process, and the plaintext of the key
  • the ACPU is invisible and can reach the pure hardware isolation level, which can improve the security of the working key.
  • the plaintext of the working key may enter the TEE memory within a short time window during which the plaintext of the working key is generated.
  • the plain text of the working key can not be seen in the TEE throughout the whole process, which can reach the TEE security level.
  • the key is imported into the HCE-TEE engine or inSE without encapsulation, it is used to express the working key of the application in plain text and imported from the application to the HCE-TEE engine or inSE.
  • Fig. 8 exemplarily shows a working flow chart of a multi-hardware cryptographic engine system under the scenario of key import without encapsulation.
  • the HCE-TEE engine or inSE encrypts the working key imported by the application, and the process of making the HCE-REE engine The process of encrypting and decrypting application data by using the encrypted work key.
  • the App when the App imports the key plaintext to the HCE-TEE engine, it can be seen from Figure 2 and Figure 8 that the App can call the CA by calling the HUKS interface, and the CA will call the TA, and the TA will call the HCE-TEE driver to The plain text of the key passed in by the app is written into the HCE-TEE engine.
  • Fig. 4b exemplarily shows a sequence diagram of a key encryption process in a key generation scenario.
  • the multi-hardware cryptographic engine system can encrypt the imported working key based on the sequence diagram described in FIG. 4b.
  • the App triggers a key import request by calling the HUKS interface.
  • the key import request The parameters in can further include the key plaintext.
  • TA only needs to control the HCE-TEE engine through the HCE-TEE driver, and encrypt the plaintext key passed in the key import request That is, there is no need to control the HCE-TEE engine to generate a working key.
  • FIG. 4 c taking an App as an example through a one-stage function call, it exemplarily shows a sequence diagram of a key usage process of a multi-hardware cryptographic engine system.
  • the multi-hardware cryptographic engine system can encrypt the application data based on the sequence diagram described in Figure 4c.
  • the multi-hardware cryptographic engine For the specific workflow, reference may be made to the description of FIG. 4c, which will not be repeated here.
  • the HCE-TEE engine or inSE can encrypt the plaintext of the key imported by the application and return the generated ciphertext structure to the App.
  • the App can trigger a function call to use the HCE-REE engine to encrypt and decrypt the application data.
  • the working key of the App can remain unchanged. Then, after the App triggers a key import request, the system can return the generated ciphertext structure to the App.
  • the App can use the ciphertext structure bound to the App and its work key to operate the HCE-REE engine through the CA and HCE-REE drivers to perform data encryption. Decryption, so that data encryption and decryption do not need to be switched to TEE or SEE, and the ciphertext structure can be used to encrypt and decrypt data in the REE environment, effectively reducing channel performance loss and improving data encryption and decryption performance.
  • the HCE-REE engine uses the ciphertext structure of the application to encrypt and decrypt data
  • the ciphertext structure can be authenticated and decrypted in the HCE-REE engine
  • the authenticated and decrypted work key can be used in the HCE-REE engine.
  • Data encryption and decryption are performed in the REE engine, so that the working key can achieve hardware-level security during use, and the use of the working key is only completed in the REE, without switching to TEE or SEE, and does not affect the encryption and decryption performance.
  • the number of the A-type register in Figure 8 can be 1, so as to reduce chip area.
  • the ciphertext structure in the DDR in Figure 8 (example may include IV, key ciphertext, TAG, AAD), under the protection mechanism of the Linux kernel, the ciphertext
  • the structure is only visible to this app, and not to other apps, thus preventing other apps from encrypting and decrypting the data of this app.
  • the App can also make the HCE-TEE
  • the REE engine uses the ciphertext structure to encrypt and decrypt the application data. For the specific process, refer to FIG. 4c and the descriptions of the embodiments in FIG. 6 and FIG. 7 , which will not be repeated here.
  • the application imports the unencapsulated working key to the HCE-TEE engine in plain text
  • the plaintext of the working key enters the TEE memory, but the plaintext of the working key can be kept out of the TEE throughout the entire process, and the security level of the TEE can be reached.
  • the key is encapsulated and imported into the HCE-TEE engine or inSE, and is used to express the working key of the application in the form of cipher text, which is imported from the application to the HCE-TEE engine or inSE.
  • FIG. 9 exemplarily shows a working flow chart of a plaintext import process of working keys in a multi-hardware cryptographic engine system under the scenario of importing keys with encapsulation.
  • the HCE-TEE engine or the TRNG in the inSE can generate the root key and write it into the AO register by hard wire.
  • This step is a precursor step, so it is not shown in Figure 9.
  • This step can be controlled by software or the terminal device starts the BootLoader stage, and the HCE-TEE engine or TRNG in the inSE automatically executes the above process.
  • the application (for example, App1) is an application that needs to be used in conjunction with the cloud, therefore, the cloud sends the ciphertext of the working key of the application to inSE.
  • FIG. 9(1) exemplarily shows an execution process in the scenario of key symmetric encapsulation import.
  • SE (including on-chip inSE and external eSE), can achieve smart card security level certification (such as CC EAL4+/5+), and can meet the StrongBox security level.
  • SE has an independent CPU and a secure OS, on which multiple applications (applets) can run, with higher security and flexibility, and can be used in customized application scenarios for specific government and enterprise customers.
  • the KM key derivation module in inSE can receive the hardware root key and the derivation component provided by the software;
  • the hardware root key may be configured in the inSE, for example, configured in a certain hardware component in the inSE.
  • the hardware root key is the hardware key of inSE, which can be HUK (Hardware Unique Key, hardware unique key, one machine, one secret), or HGK (Hardware Global Key, hardware public key, that is, multiple hardware passwords A hardware key that can be used by any engine).
  • HUK Hardware Unique Key
  • HGK Hard Global Key
  • hardware public key that is, multiple hardware passwords A hardware key that can be used by any engine.
  • the derived component can be configured in the SA, which is input to the KM key derivation module.
  • the derived component configured in the SA may be provided by a third-party key management center (such as PKI (Public Key Infrastructure)) before the system leaves the factory.
  • a third-party key management center such as PKI (Public Key Infrastructure)
  • the PKI may provide the same or different derived components, which is not limited in the present application.
  • PKI is a key management center, for the hardware root key configured and inSE, the hardware root key is also stored in PKI, then PKI can use the same derivation component as in Figure 9(1) and the inSE
  • the above hardware root key is used to derive the device-cloud shared root key, and the device-cloud shared root key is distributed offline to App1's cloud.
  • the SA can control the components in the inSE configured with the hardware root key, and pass the hardware root key to the KM key derivation module.
  • the KM key derivation module can derive the hardware root key according to the derived component based on eFuse (or OTP), and obtain the terminal-cloud shared root key.
  • the derivation algorithm and key level can be flexibly developed and customized by SA.
  • the device-cloud shared root key of App1 generated by the KM key derivation module is the same as the device-cloud shared root key generated by PKI and distributed to App1's cloud.
  • HUK is derived to obtain SUK
  • HGK is derived to obtain SGK.
  • the KM key derivation module and the KM encryption module in Fig. 9(2) may be one module or two independent modules, which is not limited in this application.
  • the cloud of App1 can import the key ciphertext encapsulated with the above-mentioned end-cloud shared root key to inSE.
  • the SA running on the inSE can receive the working key ciphertext from the cloud application (that is, the key ciphertext in Figure 9(1)), and the SA can import the key ciphertext to inSE.
  • the cloud can call the CA through the HUKS interface, and the CA calls the SA, and the SA uses the SEE OS to transfer the working key ciphertext of the application passed to the cloud (that is, in Figure 9 (1) key ciphertext) to inSE.
  • the application needs to work with the cloud, so the cloud sends the ciphertext of the working key of the application.
  • the cloud uses the derived terminal-cloud shared root key to encrypt the plaintext of the working key of the application to obtain the above-mentioned working key ciphertext (that is, the key ciphertext in Figure 9(1)).
  • the KM decryption module can use the end-cloud shared root key to decrypt the key ciphertext and obtain the App key plaintext.
  • InSE encrypts the key plaintext and returns the ciphertext structure of the key plaintext to the App; and the App uses one-stage function calls or three-stage function calls to make the HCE-REE engine process the App's application data based on the ciphertext structure
  • the App uses one-stage function calls or three-stage function calls to make the HCE-REE engine process the App's application data based on the ciphertext structure
  • the cloud can transmit the video data to be decrypted to the mobile phone, and the app installed in the mobile phone and the cloud can call the CA through the HUKS interface, and the CA can control the HCE-REE engine through the HCE-REE driver to use the
  • the plaintext of the key obtained and decrypted by the shared memory is used to decrypt the video data to obtain the plaintext video.
  • the HCE-REE engine returns the plaintext data to the app through the shared memory, and the user can browse the video data sent by the cloud in the app.
  • distinguishing UK and GK keys can meet different business requirements. In some application scenarios, it may be necessary to distribute the same working key in a large-scale broadcast manner. In some scenarios, more key derivation levels may be required. SA can be flexibly developed and customized according to customer needs.
  • FIG. 9(2) exemplarily shows an execution process in the scenario of key asymmetric encapsulation import.
  • inSE's TRNG can generate a pair of asymmetric keys: public key plaintext KPub and private key plaintext Kpriv;
  • SA controls the transfer of Kpriv generated by TRNG to the KM encryption module, and SA controls the KM encryption module to use the root key of the working key plaintext generated by TRNG to encrypt Kpriv, and write the encrypted result, such as the private key ciphertext, to NVM Secure storage area, or DDR; and SA control to send the KPub generated by TRNG to the cloud through secure transmission;
  • the SA when the SA sends the KPub to the cloud through secure transmission, based on the architecture shown in Figure 2, the SA sends the KPub generated by inSE to the CA, and the CA then sends the KPub to the cloud. This process does not go through the shared memory .
  • the cloud After the cloud stores KPub, it can import the working key ciphertext of App1 packaged with KPub.
  • the cloud can send the key ciphertext to inSE.
  • the specific process is: the cloud sends the key ciphertext to the CA by calling the HUKS interface, and the CA calls the SA to send the key ciphertext to inSE.
  • the cloud uses the public key plaintext KPub to encrypt the plaintext of the working key of App1 (App1 used with the cloud) to obtain the key ciphertext
  • SA can control the KM decryption module to read back the private key ciphertext from the NVM safe storage area, that is, the ciphertext of Kpriv;
  • the KM decryption module can read the root key of the working key from the AO register, and use the root key to decrypt the ciphertext of the private key to obtain the plaintext Kpriv of the private key;
  • SA controls the PKE (Public Key Equipment) decryption module, and uses the private key plaintext Kpriv to decrypt the key ciphertext passed in from the cloud to obtain the App key plaintext.
  • PKE Public Key Equipment
  • the KM encryption module and the KM decryption module can use an authenticated encryption algorithm such as GCM to encrypt and decrypt the key, and can authenticate the key.
  • GCM authenticated encryption algorithm
  • the HCE-TEE engine or inSE can encrypt the key plaintext , and return the ciphertext structure of the key plaintext to the App; and the process of making the HCE-REE engine encrypt and decrypt the application data of the App based on the ciphertext structure by the App through a one-stage function call or a three-stage function call, refer to The description of the foregoing embodiment is sufficient, and details are not repeated here.
  • the multi-hardware cryptographic engine system can support the import of encapsulated keys.
  • the plaintext of the working key of the application can not be exported from the hardware throughout the process, and the hardware can be reached. level security.
  • the multi-hardware cryptographic engine system encrypts the plaintext of the working key of the application, that is, the key plaintext, generates a ciphertext structure, and returns the ciphertext structure to the App the process of.
  • the App uses one-segment function call or three-segment function call to make the HCE-REE engine use the ciphertext structure to encrypt and decrypt the application data. You can refer to the one-segment function call and three-segment function call in the above-mentioned embodiment. The description of the specific embodiment of the segmented function call will not be repeated here.
  • the key is imported into the HCE-REE engine without encapsulation, it is used to express that the working key of the application is imported from the application to the HCE-REE engine in plain text.
  • the HCE-TEE engine is configured with a Class B register for setting the plaintext of the work key passed in by the application.
  • a Class B register for setting the plaintext of the work key passed in by the application.
  • Plain text is a channel for data encryption and decryption directly in the REE environment, without switching the operating environment to TEE or SEE, which can improve data encryption and decryption performance.
  • Fig. 10 exemplarily shows a working flow chart of a multi-hardware cryptographic engine system in the scenario where the key is imported into the HCE-REE engine without encapsulation.
  • the app can call the HUKS interface to trigger a data encryption and decryption request, which can include key plaintext and data to be encrypted and decrypted, such as data plaintext.
  • the App can write the plaintext of the key and the plaintext of the data into the shared memory, and carry the address information of the plaintext of the key and the plaintext of the data in the data encryption and decryption request.
  • the CA can respond to the data encryption and decryption request, call the HCE-REE driver, control the HCE-REE engine, read the key plaintext from the shared memory, and write it into Key slot 0; then, the HCE-REE engine uses the data encryption and decryption module Read the data plaintext from the shared memory and encrypt it with the key plaintext to obtain the data ciphertext to return to the App.
  • Fig. 11 exemplarily shows a working flow chart of a multi-hardware cryptographic engine system in the scenario where the key is imported into the HCE-REE engine without encapsulation.
  • the HCE-REE engine may include k B-type registers, which are respectively Key slot 1 to Key slot k, where k is a positive integer greater than 1.
  • the app can call the HUKS interface to trigger a key import request, which can include key plaintext.
  • the App can write the key plaintext into the shared memory, and carry the address information of the key plaintext in the key import request.
  • the CA can call the HCE-REE driver, control the HCE-REE engine, read the key plaintext from the shared memory, and write it into a free Class B register, such as Key slot 1.
  • the HCE-REE driver can determine the registers used to store the key plaintext of the App among the k B-type registers according to business requirements, application IDs (such as package names), etc. For specific solutions, refer to the above embodiments, here No longer.
  • the HCE-REE driver returns the handle used to identify the Class B register (Key slot 1 here) in the HCE-REE engine to the App through the CA.
  • the App After the App receives the handle used to identify the Class B register (here, Key slot 1), it calls the HUKS interface according to business requirements, and triggers a data encryption and decryption request.
  • the data encryption and decryption request can carry the Class B register used for identification ( Here is the handle of Key slot 1), the data to be encrypted and decrypted (such as data plaintext);
  • the app can write the handle and data plaintext used to identify the class B register (here Key slot 1) into the shared memory, and write the handle used to identify the class B register (here Key slot 1)
  • the address information and the address information of the data plaintext are carried in the data encryption and decryption request.
  • the CA can respond to the data encryption and decryption request, call the HCE-REE driver, control the HCE-REE engine, read the key plaintext from the shared memory, and the handle used to identify the class B register (here Key slot 1); Then, the data encryption and decryption module of the HCE-REE engine reads the data plaintext from the shared memory, and reads the key plaintext from the Type B register Key slot 1 according to the handle used to identify the Type B register (Key slot 1 here). , and use the key plaintext to encrypt the data plaintext, generate data ciphertext, and return it to the App.
  • the HCE-REE engine is used to encrypt and decrypt data to improve data encryption and decryption performance.
  • the multi-hardware encryption engine in the system of the embodiment of the present application may include an HCE-REE engine and an HCE-TEE engine, and the HCE-TEE engine realizes the encryption of the working key, and the HCE-REE The engine decrypts the working key, and uses the decrypted working key to encrypt and decrypt data, which can improve the performance of data encryption and decryption.
  • the multi-hardware cryptographic engine in the system of the embodiment of the present application may include HCE-REE engine and inSE to implement the encryption of the working key by inSE, and decrypt the working key by the HCE-REE engine, And use the decrypted work key for data encryption and decryption, the security of the work key is higher.
  • the multi-hardware encryption engine in the system of the embodiment of the present application may include an HCE-REE engine, an HCE-TEE engine, and an inSE, and the inSE generates the root key in the AO register, and uses the root key
  • the root key encrypts the working key, which can improve key security;
  • the HCE-REE engine and the HCE-TEE engine have similar functions, and can use the root key to decrypt the working key ciphertext, and use the decrypted working key to decrypt Data encryption and decryption.
  • the data encryption and decryption work is mainly realized by the HCE-REE engine, which can be busy in the HCE-REE engine, or the encryption and decryption algorithm configured in the HCE-REE engine is the same as the encryption and decryption algorithm required for the encryption and decryption of the application data.
  • the HCE-TEE engine uses the root key to decrypt the working key ciphertext, and uses the decrypted working key to encrypt and decrypt data.
  • the HCE-TEE engine uses an internally configured encryption and decryption algorithm that can support the current data encryption and decryption of the application to perform encryption and decryption operations on the application data to improve the reliability of data encryption and decryption.
  • both the HCE-REE engine and the HCE-TEE engine can read the root key from the AO register to decrypt the ciphertext of the working key for data encryption. decrypt.
  • the security subsystem inside the SoC may include multiple hardware cryptographic engines such as HCE-REE engine, HCE-TEE engine, and inSE, and the HCE-REE engine may use the key in the engine to encrypt data.
  • HCE-REE engine may use the key in the engine to encrypt data.
  • Decryption no need to switch the operating environment, data encryption and decryption performance is higher; inSE contains an independent CPU, when used for work key import/generation, and work key encryption, the work key plaintext can reach hardware level security, security higher.
  • inSE is programmable and can be customized flexibly. However, inSE runs in the SEE environment. When passing the working key to the HCE-REE engine, it needs to switch the CPU and the operating environment, and the performance is poor.
  • the HCE-TEE engine can run on the ACPU, so when using the HCE-TEE engine to import/generate work keys and encrypt work keys, there is no need to switch the operating environment, and the security and performance are between the HCE-REE engine and Among inSEs, the advantages of balanced security are more prominent.
  • the embodiment of the present application can realize the division of labor and cooperative work among multiple hardware cryptographic engines through the effective cooperation of the cryptographic service components CA/TA/SA, and can support various scenarios such as security key import, generation, and data encryption and decryption.
  • inSE is taken as an example to describe a hardware security module (SE) with an independent CPU and a secure OS in a multi-hardware cryptographic engine.
  • SE hardware security module
  • the SE in a multi-hardware cryptographic engine is not limited to being located in the SoC
  • the internal inSE can also be expanded into an independent external SE chip, namely eSE.
  • the present application does not limit the number and combination of hardware cryptographic engines in the SoC.
  • the security subsystem in FIG. 1 may include multiple REE hardware cryptographic engines, multiple TEE hardware cryptographic engines, multiple inSEs, multiple Various combinations between eSE, and more hardware cryptographic engines not listed.
  • FIG. 12 is a schematic structural diagram of a data processing device provided by an embodiment of the present application.
  • the data processing device 500 may include: the above-mentioned HCE-TEE engine, HCE-REE engine, processor 501, transceiver 505, and optionally a memory 502.
  • the data processing device also includes Including SE.
  • the data processing device further includes an AO register, and the AO register is respectively hardwired to the HCE-TEE engine, the HCE-REE engine, and the SE.
  • the transceiver 505 may be called a transceiver unit, a transceiver, or a transceiver circuit, etc., and is used to implement a transceiver function.
  • the transceiver 505 may include a receiver and a transmitter, and the receiver may be called a receiver or a receiving circuit for realizing a receiving function; the transmitter may be called a transmitter or a sending circuit for realizing a sending function.
  • Computer program or software code or instructions 504 may be stored in memory 502, which may also be referred to as firmware.
  • the processor 501 can control the MAC layer and the PHY layer by running the computer program or software code or instruction 503 therein, or by calling the computer program or software code or instruction 504 stored in the memory 502, so as to realize various embodiments of the present application The communication method provided.
  • the processor 501 may be a central processing unit (central processing unit, CPU), and the memory 502 may be, for example, a read-only memory (read-only memory, ROM) or a random access memory (random access memory, RAM).
  • the processor 501 and transceiver 505 described in this application can be implemented in integrated circuit (integrated circuit, IC), analog IC, radio frequency integrated circuit RFIC, mixed signal IC, application specific integrated circuit (application specific integrated circuit, ASIC), printed circuit board (printed circuit board, PCB), electronic equipment, etc.
  • integrated circuit integrated circuit, IC
  • analog IC analog IC
  • radio frequency integrated circuit RFIC radio frequency integrated circuit
  • mixed signal IC application specific integrated circuit
  • ASIC application specific integrated circuit
  • PCB printed circuit board
  • electronic equipment etc.
  • the above data processing apparatus 500 may further include an antenna 506, and each module included in the data processing apparatus 500 is only an example for illustration, and this application is not limited thereto.
  • the structure of the data processing device may not be limited by FIG. 12 .
  • the data processing means may be a stand-alone device or may be part of a larger device.
  • the implementation form of the data processing device may be:
  • An independent integrated circuit IC, or a chip, or a chip system or subsystem (2) a set of one or more ICs, optionally, the set of ICs can also include storage for storing data and instructions components; (3) modules that can be embedded in other equipment; (4) vehicle equipment, etc.; (5) others, etc.
  • the chip shown in FIG. 13 includes a processor 601 and an interface 602 .
  • the number of processors 601 may be one or more, and the number of interfaces 602 may be more than one.
  • the chip or chip system may include a memory 603 .
  • the embodiment of the present application also provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, the computer program includes at least one piece of code, and the at least one piece of code can be executed by a computer to control the computer It is used to realize the above-mentioned method embodiment.
  • the embodiments of the present application further provide a computer program, which is used to implement the foregoing method embodiments when the computer program is executed by a terminal device.
  • the program may be stored in whole or in part on a storage medium packaged with the processor, or stored in part or in whole in a memory not packaged with the processor.
  • the embodiment of the present application also provides a chip, including a network port controller and a processor.
  • the network port controller and the processor can implement the foregoing method embodiments.
  • the steps of the methods or algorithms described in connection with the disclosure of the embodiments of the present application may be implemented in the form of hardware, or may be implemented in the form of a processor executing software instructions.
  • the software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (Random Access Memory, RAM), flash memory, read-only memory (Read Only Memory, ROM), erasable programmable read-only memory ( Erasable Programmable ROM, EPROM), Electrically Erasable Programmable Read-Only Memory (Electrically EPROM, EEPROM), registers, hard disk, removable hard disk, CD-ROM, or any other form of storage medium known in the art.
  • An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium.
  • the storage medium may also be a component of the processor.
  • the processor and storage medium can be located in the ASIC.
  • the functions described in the embodiments of the present application may be implemented by hardware, software, firmware or any combination thereof.
  • the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
  • Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a storage media may be any available media that can be accessed by a general purpose or special purpose computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种数据处理方法及系统，该系统包括第一硬件引擎和第二硬件引擎，以及与每个硬件引擎硬线连接的AO存储单元，第一硬件引擎可在TEE或SEE中，利用从AO存储单元读取的根密钥对密钥明文加密；第二硬件引擎可在REE中利用所述根密钥对密钥密文解密，并使用解密后的密钥明文，来对应用的数据进行加解密操作。该系统可使应用的密钥明文全程不出硬件，达到硬件级别安全，且AO存储单元为软件不可读，仅在所述数据处理系统初始化时被写入一次所述第一根密钥，可提升密钥密文的破解难度，另外，可在REE中使用解密后的密钥明文，来对应用的数据进行加解密，无需切换运行环境，可提升数据加解密性能。

Description

数据处理方法及系统 技术领域
本申请实施例涉及电子技术领域，尤其涉及一种数据处理方法及系统。
背景技术
目前，终端设备，例如手机、平板、个人电脑(PC，personal computer)、IoT(Internet of Things，物联网)、可穿戴设备等成为人们日常生活中不可或缺的工具。在实际生活中，手机上安装的移动支付、移动金融、汽车钥匙等对安全性要求较高的安全应用得到了广泛应用。手机实现这些安全应用不仅需要开发相应的软件应用，更为关键的是，需要为手机芯片提供硬件级的安全解决方案，以确保用户的财产和敏感数据安全。
为了确保敏感数据(例如用户的个人数据或隐私数据)的安全，通常需要对敏感数据进行加密保护后以进行安全存储或传输。为此，各厂商利用终端设备的芯片平台中的硬件密码引擎为其上层应用提供了通用密码服务，以确保数据的安全存储或传输。在对这些密码服务(或称为密钥库系统)进行软硬件方面设计时，通常要从性能、安全、成本和功耗等多方面进行取舍和平衡。
目前的硬件密码引擎，安全级别从低到高可分为以下三种：
一，考虑性能和成本，只将部分私钥配置于SoC(System-on-Chip，系统级芯片)的硬件密码引擎中，其他密钥明文均存储至内存。这种硬件密码引擎的设计方式，使得内存中的密钥明文没有保存在硬件之内，容易被恶意程序窃取，防篡改和抗侧信道攻击能力较弱，安全级别相对最低。
二，将密钥材料绑定至终端设备的可信执行环境(TEE，Trusted Execution Environment)，TEE(比如ARM的TrustZone技术)一般是基于同一CPU进行资源隔离和时间片轮换的执行环境，安全级别相较纯硬件隔离方式较低。
三，将密钥材料绑定至安全元件(SE，Secure Element)，SE一般是一种纯硬件隔离方式，有自己独立的CPU和相关资源，安全级别相对较高，但性能较差。
因此，目前各芯片平台中的硬件密码引擎在提供密码服务时，难以兼顾性能和安全。
发明内容
为了解决上述技术问题，本申请实施例提供一种数据处理方法及系统。在该系统中，通过将根密钥存储在AO存储单元中并引入多个硬件引擎，使密钥明文只存在于硬件引擎内部，从而使对数据的加解密操作有更好的性能和安全性。
第一方面，本申请实施例提供一种数据处理系统，包括多个硬件引擎、第一存储单元以及常开不掉电(Always On，AO)的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在TEE或SEE(Secure Execution  Environment，安全执行环境)中，所述第二硬件引擎运行在REE(Rich Execution Environment，富执行环境)中；
所述第一硬件引擎，用于：从所述第二存储单元读取第一根密钥；基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文；将所述第一密钥密文写入第一存储单元。
所述第二硬件引擎，用于：从所述第二存储单元读取所述第一根密钥；从所述第一存储单元读取所述第一密钥密文；基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据。
所述第二存储单元，用于存储第一根密钥，以及用于仅在所述数据处理系统初始化时被写入一次所述第一根密钥。
示例性地，第一存储单元可以被配置为多硬件引擎的共享内存。
示例性地，第一存储单元可以是片上内存(例如寄存器)，还可以是片下内存(例如(DDR SDRAM，双倍速率同步动态随机访问存储器)、NVM(Non-volatile memory，非易失性存储器，掉电不丢失数据掉线不丢失的内存)等)。
示例性地，硬线连接可以是一种芯片级的物理连接。
例如，硬线连接可用于表示两台计算机之间传输数据用的一种与开关连接不同的永久性物理连接。
示例性的，第二存储单元可以是独立的寄存器(例如AO寄存器)，还可以是部署在芯片上的存储单元(memory)。
示例性的，所述第二存储单元，可在所述数据处理系统上电时被写入一次所述第一根密钥。
示例性的，所述第二存储单元可由软件控制被写入上述根密钥。示例性的，可在所述数据处理系统启动BootLoader时，BootLoader控制写入一次所述第一根密钥到第二存储单元。
可选地，第一硬件引擎运行在SEE中，第一硬件引擎可以是SE，SE具有独立的CPU和存储空间。
示例性地，第一密钥明文可为上层应用(例如第一应用)的工作密钥明文。
示例性地，第一数据可为上层应用(例如第一应用)的待加解密的应用数据。
可选地，该系统还可包括用于操控第一硬件引擎的第一软件程序，用于操控第二硬件引擎的第二软件程序。
第二软件程序可向上层应用提供第一接口，以供上层应用调用多硬件引擎所提供的密码服务。
第二软件程序可调用第一软件程序，以使第一软件程序操控第一硬件引擎。
示例性的，第一硬件引擎运行在TEE中，第一软件程序可包括第一硬件引擎的第一驱动程序和控制所述第一驱动程序的软件服务(可称为HiCrypto TA(Trusted Application，可信应用程序))。
示例性的，第一硬件引擎运行在SEE中，所述第一软件程序可包括第一硬件引擎的 操作系统和调用该操作系数的软件服务(可称为HiCrypto SA(Secure Application，安全应用程序))。
示例性的，第二硬件引擎的第二软件程序可包括第二硬件引擎的第二驱动程序和控制第二驱动程序的软件服务(可称为HiCrypto CA(Client Application，客户端应用程序))。
示例性地，上层应用可从第一存储单元读取所述第一密钥密文。
示例性地，上层应用在需要对应用数据进行加解密时，可调用第一接口，来调用第二软件程序，以使第二软件程序操控第二硬件引擎，基于上层应用传入的第一密钥密文来对待加解密的第一数据执行加密或解密操作。
示例性地，第一密钥密文和第一数据可以通过第一存储单元，传入第二硬件引擎。
示例性地，第一密钥密文和第一数据可以在一次函数调用过程中，一次性传入至第二硬件引擎，也可以通过调用不同的函数，来分别传入第一密钥密文和第一数据至第二硬件引擎，本申请对此不做限制。
示例性地，上层应用在需要对应用数据进行加解密时，可调用第一接口，来调用第二软件程序，以使第二软件程序操控第二硬件引擎，基于上层应用传入的第一密钥密文来对待加解密的第一数据执行加密或解密操作。
示例性地，第一密钥密文和第一数据可以通过第一存储单元，传入第二硬件引擎。
示例性地，第一密钥密文和第一数据可以在一次函数调用过程中，一次性传入至第二硬件引擎，也可以通过调用不同的函数，来分别传入第一密钥密文和第一数据至第二硬件引擎，本申请对此不做限制。
本申请实施例的系统包括多个硬件引擎，以及与每个硬件引擎硬线连接的AO存储单元，AO存储单元可存储有根密钥，且AO存储单元软件不可读，且AO存储单元仅在所述数据处理系统初始化时被写入一次根密钥，从而可提升根密钥的安全度；运行在TEE或SEE中的第一硬件引擎可利用从AO存储单元读取的根密钥，来对上层应用的密钥明文加密，并将密钥密文通过第一存储单元共享至第二硬件引擎，可使密钥明文全程不出硬件，达到硬件安全级别；运行在REE中的第二硬件引擎可利用从AO存储单元读取的根密钥对密钥密文(示例性的，可从第一存储单元读取密钥密文)解密，从而可使用密钥明文对数据进行加解密操作，第二硬件引擎可在REE中直接进行数据加解密操作，不需要切换到TEE或SEE环境，可减少切换通路的时间损耗，提高数据加解密性能。
此外，在本申请实施例中，可利用AO存储单元中的第一根密钥，来对密钥明文进行保护，而AO存储单元作为软件不可读的硬件存储单元，可提升对密钥明文的保护强度；另外，AO存储单元与多个硬件引擎分别硬线连接，多个硬件引擎每次从AO存储单元读取第一根密钥，均不经过ACPU(应用处理器)，可确保需要保护的密钥(例如应用的工作密钥)在多硬件引擎之间的安全传输；而且，多个硬件引擎之间除了使用AO存储单元进行连接的通道外，设计上可有效进行解耦，独立运作，从而可有利于最大化发挥性能。
另外，本申请实施例的系统利用多个硬件引擎和AO存储单元，可实现对待保护密钥的硬件级别保护，与软件算法相比，本申请实施例通过使用专用硬件引擎，可以显著降低CPU负载，有效控制功耗(发热)，同时达成了密钥全程不出硬件的效果。
根据第一方面，所述第二存储单元，用于仅在所述数据处理系统上电时被写入第一根密钥。此外，第二存储单元还可写入一次第一根密钥之后不可继续写入该第一根密钥。
在本申请实施例中，第二存储单元每次系统上电时刷新内部存储的根密钥，且在系统一次上电后，写入一次数据之后不可继续写入数据，使得系统一次上电后，对需要进行保护的密钥明文进行加密的根密钥相同，使得系统一次上电后，在需要多次使用密钥明文进行数据加解密时，可多次使用同一根密钥来对密钥密文解密，以获取密钥明文，无需频繁切换所用的根密钥，可进一步提升数据加解密性能和加密安全性。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎包括第一真随机数生成模块；所述第一真随机数生成模块，用于在所述数据处理系统初始化时生成第一真随机数，并将所述第一真随机数作为所述第一根密钥。
示例性的，第一真随机数生成模块在执行生成作为第一根密钥的第一真随机数，可在数据处理系统上电时，自动执行上述功能，还可以由BootLoader控制第一软件程序，由上述第一软件程序操控第一硬件引擎，以使第一真随机数生成模块执行上述功能，本申请对此不做限制。
在本申请实施例中，在将密钥明文(例如上层应用的工作密钥)在多硬件引擎之间传输时，可由每次系统初始化时第一真随机数生成模块随机生成的真随机数，对密钥明文进行硬件级加密保护，以提升密钥明文的保护强度。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎，还用于：按照第一变量和第二根密钥，生成所述第一根密钥，所述第二根密钥为预设密钥；将所述第一根密钥写入所述第二存储单元。
示例性地，第一硬件引擎在执行本实现方式所限定的附加功能时，可由第一软件程序操控来执行。
示例性地，第一变量可预先配置与第一软件程序内，由第一软件程序在操控第一硬件引擎时，传入第一硬件引擎。
示例性地，第二根密钥可为第一硬件引擎内的硬件根密钥，该硬件根密钥可为第一硬件引擎内预设的唯一的硬件根密钥。
示例性地，第一硬件引擎内可包括密钥派生模块，密钥派生模块可按照第一变量，来对第二根密钥进行密钥派生，以生成第一根密钥。
在本申请实施例中，可由第一硬件引擎按照第一变量对第二根密钥进行处理，来生成用于对密钥明文进行保护的第一根密钥，可提升第一根密钥的生成方式的灵活性。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎运行在所述SEE中，所述多个硬件引擎还包括第三硬件引擎，所述第三硬件引擎运行在所述TEE中；
所述第三硬件引擎，用于：从所述第二存储单元读取所述第一根密钥；基于所述第 一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；基于所述第一密钥明文，对第三数据进行加密或解密，生成第四数据。
示例性地，在多个硬件引擎包括运行在SEE中的第一硬件引擎、运行在REE中的第二硬件引擎，以及运行在TEE中的第三硬件引擎时，在大多数场景下，可由第二硬件引擎来对数据执行加解密操作，可在第二硬件引擎满足预设条件的情况下，例如第二硬件引擎忙碌，再如，第二硬件引擎内配置的加解密算法，与本次数据加解密所需要使用的加解密算法算法不同，由第三硬件引擎从第二存储单元读取第一硬件引擎所写入的第一根密钥，来使用满足本次数据加解密需求的加解密算法，来对数据进行加解密操作，可提升本申请实施例的系统的数据加解密的可靠性。
示例性地，上述第三数据与所述第一数据可以相同或不同，本申请对此不做限制。
示例性地，所述系统还可包括用于操控第三硬件引擎的第三软件程序。
示例性地，第三软件程序可包括第一方面所述的TA和控制第三硬件引擎的驱动程序。
与上述第一方面的描述类似，第二软件程序可调用第三软件程序，以使第三软件程序操控第三硬件引擎。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第二硬件引擎还包括第一寄存器，其中，所述第一寄存器为软件不可读、软件不可写；
所述第一寄存器，用于存储所述第一密钥明文，其中，所述第一密钥明文用于对应用的数据进行加密或解密，其中，所述应用的数据可包括所述第一数据。
示例性地，在第二硬件引擎从第一存储单元读取第一密钥密文后，可基于第一根密钥对第一密钥密文进行解密，以生成所述第一密钥明文，然后，第二硬件引擎可将本引擎解密生成的该第一密钥明文写入第一寄存器。
示例性地，第一寄存器的数量可以是一个或多个，本申请对此不做限制。
可选地，所述数据处理系统还包括第一软件程序、第二软件程序，所述第二软件程序具有第一接口，第一应用运行在所述REE中；
第一软件程序用于操控第一硬件引擎，第二软件程序用于操控第二硬件引擎。
第一应用为供用户使用的上层应用。第二软件程序可向上层应用提供第一接口，以供上层应用调用多硬件引擎所提供的密码服务。
第二软件程序可调用第一软件程序，以使第一软件程序操控第一硬件引擎。
所述第二软件程序，还用于响应于所述第一应用对所述第一接口的第二请求，控制所述第二硬件引擎。
可选地，第二请求为三段式函数调用请求，那么第二硬件引擎可响应于该第二请求，将所述第一寄存器的句柄信息，通过第二软件程序发送至第一应用；然后，第一应用可通过多次触发携带该句柄信息的第二请求，来调用第二软件程序，以使第二软件程序控制第二硬件引擎按照该句柄信息从第一寄存器中读取第一密钥明文，来对应用数据进行加解密操作。
在本申请实施例中，通过在第二硬件引擎中配置第一寄存器，以利用第一寄存器存储第一密钥明文，由于第一寄存器为软件不可读、软件不可写，从而可确保ACPU无法从 第二硬件引擎内的第一寄存器中读取第一密钥明文，使密钥明文达到硬件级别安全。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎，具体用于：基于密钥参数和所述第一根密钥，对所述第一密钥明文进行加密，生成第一密文数据；根据所述第一密文数据，获取校验数据；其中，所述第一密钥密文包括所述密钥参数、所述第一密文数据以及所述校验数据；
所述第二硬件引擎，具体用于：基于所述第一密钥密文中的所述校验数据，对所述第一密文数据进行校验认证；在校验认证通过的情况下，基于所述密钥参数和所述第一根密钥，对所述第一密文数据进行解密，获取所述第一密钥明文，其中，所述第一密钥明文用于对所述第一数据进行加密或解密。
示例性地，第一硬件引擎可利用AES或SM4算法的GCM模式，来执行密钥明文的加密操作，需要说明的是，本申请对于第一硬件引擎在对密钥明文进行加密时所使用的认证加密算法的具体算法并不限制于AES或SM4的GCM模式，还可以是其他认证加密算法。
示例性地，SM4的GCM模式可以用于认证加密以保证明文或其它认证内容的完整性，在加密时校验参数可包括但不限于以下参数：TAG，可选地包括额外认证数据(AAD，Additional Authentication Data)。密钥参数可包括IV(初始向量)值。
示例性地，TAG是GCM模式中的消息认证码。
示例性地，IV值可由第一硬件引擎内的真随机数生成模块(可以是第一硬件引擎内配置的任意一个真随机数生成模块)来生成。
示例性地，AAD可由第一应用传入。
所述第一硬件引擎，可具体用于：基于IV值和所述第一根密钥，对第一应用的第一密钥明文进行加密，生成第一密文数据；对所述第一密文数据和所述第一应用传入的AAD(可选地)，计算TAG；将所述IV值、所述AAD(可选地)、所述第一密文数据以及所述TAG作为第一密钥密文；
第二硬件引擎，可具体用于：对所述第一密钥密文中的第一密文数据和所述AAD(可选地)计算TAG’；检测到TAG与TAG’相同，校验认证通过，然后，基于所述第一根密钥和所述第一密钥密文中的所述IV值，对所述第一密文数据解密，生成所述第一密钥明文。
在本申请实施例中，第一硬件引擎在对密钥明文加密时，可设置密钥参数IV值，以及用于校验的TAG，从而使得本实施例的系统能够支持对上层应用的鉴权和防假冒，以防止其他应用窃取该密钥明文，以伪装为特定应用来利用本系统对该特定应用的数据进行解密。
根据第一方面，或者以上第一方面的任意一种实现方式，所述数据处理系统还包括第一软件程序、第二软件程序，所述第二软件程序具有第一接口，第一应用运行在所述REE中；
所述第一软件程序，用于控制所述第一硬件引擎进行运算和读写操作；
所述第二软件程序，用于：
控制所述第二硬件引擎进行运算和读写操作；
通过所述第一接口与所述第一应用通信；
调用所述第一软件程序。
示例性地，第一软件程序用于操控第一硬件引擎，第二软件程序用于操控第二硬件引擎。
第一应用为供用户使用的上层应用。第二软件程序可向上层应用提供第一接口，以供上层应用调用多硬件引擎所提供的密码服务。
第二软件程序可调用第一软件程序，以使第一软件程序操控第一硬件引擎。
示例性的，第一应用可通过调用第一接口，来与第二软件程序通信，例如第二软件程序可通过第一接口接收第一应用的第一请求；
第二软件程序可响应于该第一请求，调用第一软件程序，然后，第一软件程序可控制第一硬件引擎进行运算和读写操作，具体的，所述第一硬件引擎可经第一软件程序控制，从所述第二存储单元读取第一根密钥；基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文；将所述第一密钥密文写入第一存储单元。
所述第二软件程序可响应于第一应用的第一请求，从所述第一存储单元中读取用于指示所述第一密钥密文的信息(例如该第一密钥密文在第一存储单元中的地址信息)，并将该信息发送至所述第一应用。
示例性地，第二软件程序在响应于所述第一请求时，可对该第一应用分配地址信息，该地址信息为第一存储单元中用于写入上述第一密钥密文的地址信息。第二软件程序可在响应于所述第一请求时，将该地址信息发送至第一软件程序。
示例性地，第一软件程序可在控制第一硬件引擎来执行第一方面所述的密钥明文的加密操作时，将该地址信息发送至第一硬件引擎，以使第一硬件引擎按照该地址信息，将生成的密钥密文写入第一存储单元。
示例性地，待密钥密文写入第一存储单元之后，第二软件程序可响应于该第一请求，将该地址信息发送至第一应用，以供第一应用从第一存储单元读取第一密钥密文。
示例性地，第一应用在获取到第一密钥密文之后，可利用该第一密钥密文通过第一接口调用第二软件程序，例如第一应用通过第一接口向第二软件程序发送第二请求；
第二软件程序可响应于该第二请求，控制第二硬件引擎进行运算和读写操作，具体的，第二硬件引擎可经由第二软件程序控制从所述第二存储单元读取所述第一根密钥；从所述第一存储单元读取所述第一密钥密文；基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据。
第二硬件引擎在执行了数据加解密操作之后，第二硬件引擎可将第二数据写入第一存储单元，第二数据在第一存储单元中的写入地址可由第一应用在触发第二请求时携带至第二请求中，那么第一应用可从第一存储单元的相应地址中读取到第二数据。
在本申请实施例中，运行在REE中的上层应用可通过第一接口与第二软件程序进行通信，来使第二软件程序调用第一软件程序以操控第一硬件引擎进行运算和读写操作， 从而在第一硬件引擎内对上层应用的第一密钥明文加密生成第一密钥密文，以使上层应用获取该第一密钥密文。待上层应用需要进行数据加解密时，上层应用可通过第一接口与第二软件程序通信，第二软件程序控制所述第二硬件引擎进行运算和读写操作，以使第二硬件引擎从所述第二存储单元读取所述第一根密钥；从所述第一存储单元读取所述第一密钥密文；基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据，无需切换运行环境至TEE或SEE，可在REE中，由第二硬件引擎独自执行数据加解密操作，可大大减少通路时间损耗，有效提高数据加解密性能。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎，还用于按照第二变量和所述第二根密钥，获取第四根密钥，其中，所述第四根密钥用于对所述第一密钥明文进行加密或解密；以及基于所述第四根密钥对所述第一应用的第二密钥密文解密，生成所述第一密钥明文，其中，所述第二密钥密文由所述第一应用根据所述第一密钥明文生成并通过所述第二软件程序发送至所述第一软件程序。
示例性地，上述第二变量与上述第一变量可以相同或不同，上述第二变量可预先配置于第一软件程序内，所述第一硬件引擎按照第二变量和第二根密钥，获取第四根密钥的原理，与上述实现方式中所述第一硬件引擎按照第一变量和第二根密钥，生成第一根密钥的原理相同，这里不再赘述。
示例性的，上述第二变量可在系统出厂前配置于系统的第一软件程序中，该第二变量可由第三方密码管理中心(例如PKI(公钥基础设施))分发，且第三方密码管理中心也具有该第二变量和所述第二根密钥，第三方密码管理中心可按照第二变量和第二根密钥生成上述第四根密钥，离线分发给上层应用。例如该上层应用为第一应用。再如，在第一应用为端云配套使用的应用时，该上层应用可以包括云端和第一应用。
那么在上层应用包括云端和第一应用时，那么第三方密码管理中心可将第四根密钥离线分发给第一应用的云端侧。
那么云端在需要导入工作密钥至本申请的系统时，可导入使用该第四根密钥封装后的上述第二密钥密文。
示例性的，云端可通过接口调用第二软件程序，以使第二软件程序可调用第一软件程序，以将云端传入的用于指示所述第一应用的第二密钥密文的信息(例如第二密钥密文，可选地，可以是第二密钥密文的地址信息)，导入到第一硬件引擎进行工作密钥的加密。
在本申请实施例中，导入至第一硬件引擎内的密钥可以是使用对称密钥封装后的第二密钥密文，其中，对称密钥可以是按照第二变量和第二根密钥，而获取的第四根密钥。本申请实施例的系统可支持应用导入对称封装的密钥的场景，不仅能够使待保护的第二密钥密文全程不出硬件，而且，第四根密钥可通过第二变量对第二根密钥派生得到，那么可对不同应用或不同业务配置不同取值的第二变量，从而能够根据客户需求而灵活定制开发所需要的第四根密钥。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎还包括第二真随机数生成模块；
示例性地，所述第二真随机数生成模块可以与上述第一真随机数生成模块相同或不同，本申请对此不做限制。
所述第二真随机数生成模块，用于在所述数据处理系统初始化(包括但不限于上电)时，生成第二真随机数和第三真随机数分别作为第一公钥明文和第一私钥明文；
所述第一硬件引擎，还用于基于所述第一根密钥对所述第一私钥明文加密，生成第一私钥密文并将所述第一私钥密文写入所述第一存储单元；从所述第一存储单元读取所述第一私钥密文；基于所述第一根密钥，对所述第一私钥密文解密，生成所述第一私钥明文；基于所述第一私钥明文，对第三密钥密文解密，获取所述第一应用的第一密钥明文；其中，所述第三密钥密文为所述第一应用基于所述第一公钥明文对所述第一密钥明文进行加密后的数据，所述第三密钥密文由所述第一应用生成并通过所述第二软件程序发送至所述第一软件程序。
示例性的，所述第一软件程序可用于从所述第一硬件引擎获取所述第一公钥明文，并发送至所述第二软件程序；所述第二软件程序可用于将所述第一公钥明文发送至上层应用。例如该上层应用为第一应用。再如，在第一应用为端云配套使用的应用时，该上层应用可以包括云端和第一应用。
示例性的，云端在需要导入工作密钥至本申请的系统时，可导入使用该第一公钥明文封装后的上述第三密钥密文。
示例性的，云端可通过接口调用第二软件程序，以使第二软件程序可调用第一软件程序，以将云端传入的用于指示所述第一应用的第三密钥密文的信息(例如第三密钥密文，可选地，可以是第二密钥密文的地址信息)，导入到第一硬件引擎进行工作密钥的加密。
在本申请实施例中，导入至第一硬件引擎内的密钥可以是使用非对称密钥封装后的第三密钥密文，本申请实施例的系统可支持导入非对称封装的密钥的场景，能够使待保护的第三密钥密文全程不出硬件，而且能够根据客户需求而灵活定制开发对第一密钥明文进行封装的密钥。
另外，本申请实施例对应用的工作密钥进行封装的密钥可由第一硬件引擎通过随机数生成，可以不借助于外部密码管理中心，对应用的密钥管理上灵活性更高。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第一硬件引擎包括第三真随机数生成模块；
示例性地，所述第三真随机数生成模块可以与上述第一真随机数生成模块相同或不同，本申请对此不做限制。
所述第二软件程序，还用于响应于所述第一应用对所述第一接口的第五请求，调用所述第一软件程序以控制所述第一硬件引擎，所述第五请求包括所述第一密钥明文；
所述第三真随机数生成模块，用于响应于所述第五请求，生成第四真随机数作为所述第一应用的所述第一密钥明文。
本申请实施例中，第一硬件引擎可使用真随机数生成模块来生成第一应用的工作密钥(即第一密钥明文)，无需应用导入工作密钥，使得本申请实施例的系统可应用到密钥生成场景中。
根据第一方面，或者以上第一方面的任意一种实现方式，所述第二软件程序，还用于响应于所述第一应用对所述第一接口的第六请求，调用所述第一软件程序以控制所述第一硬件引擎，所述第六请求包括所述第一密钥明文；
所述第一硬件引擎，还用于将所述第一密钥明文写入所述第一存储单元；
所述第二硬件引擎还包括第二寄存器。
示例性地，所述第二寄存器为软件可写、软件不可读；
所述第二硬件引擎用于从所述第一存储单元读取所述第一密钥明文，并将所述第一密钥明文写入所述第二寄存器，其中，所述第二寄存器用于存储所述第一密钥明文。
本申请实施例的系统中，可在第二硬件引擎内保留应用直接设置明文密钥的第二寄存器的通道，可为应用提供传入明文密钥到第二硬件引擎的通道，由于应用可直接传入密钥明文到REE中的第二硬件引擎，而无需传入密钥明文到运行在TEE或SEE中的第一硬件引擎，从而只需在REE中就可以实现密钥导入以及使用导入的密钥进行数据加解密的操作，能够对数据加解密性能进行加速，不需要占用CPU负载。
根据第一方面，或者以上第一方面的任意一种实现方式，所述系统集成在片上系统(SoC)中。
第二方面，本申请实施例提供一种数据处理方法，应用于数据处理系统，所述数据处理系统包括多个硬件引擎、第一存储单元以及AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在TEE或SEE中，所述第二硬件引擎运行在REE中，所述方法包括：所述第一硬件引擎从所述第二存储单元读取第一根密钥；所述第一硬件引擎基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文；所述第一硬件引擎将所述第一密钥密文写入第一存储单元；所述第二硬件引擎从所述第二存储单元读取所述第一根密钥；所述第二硬件引擎从所述第一存储单元读取所述第一密钥密文；所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；所述第二硬件引擎基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据；其中，所述第二存储单元，用于存储第一根密钥，以及用于仅在所述数据处理系统初始化时被写入一次所述第一根密钥。
根据第二方面，所述第二存储单元，具体用于仅在所述数据处理系统上电时被写入所述第一根密钥。此外，第二存储单元还可写入一次第一根密钥之后不可继续写入该第一根密钥。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一硬件引擎从所述 第二存储单元读取第一根密钥之前，所述方法还包括：所述第一硬件引擎在所述数据处理系统初始化时生成第一真随机数，并将所述第一真随机数作为所述第一根密钥，以及将所述第一根密钥写入所述第二存储单元。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一硬件引擎从所述第二存储单元读取第一根密钥之前，所述方法还包括：所述第一硬件引擎按照第一变量和第二根密钥，生成所述第一根密钥，以及将所述第一根密钥写入所述第二存储单元，其中，所述第二根密钥为预设密钥。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一硬件引擎运行在所述SEE中，所述多个硬件引擎还包括第三硬件引擎，所述第三硬件引擎运行在所述TEE中；所述第一硬件引擎将所述第一密钥密文写入第一存储单元之后，所述方法还包括：所述第三硬件引擎从所述第二存储单元读取所述第一根密钥；所述第三硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；所述第三硬件引擎基于所述第一密钥明文，对第三数据进行加密或解密，生成第四数据。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第二硬件引擎还包括第一寄存器，其中，所述第一寄存器为软件不可读、软件不可写；所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文之后，所述方法还包括：所述第二硬件引擎将所述第一密钥明文写入所述第一寄存器。
示例性的，所述第一寄存器，用于存储所述第一密钥明文，其中，所述第一密钥明文用于对应用的数据进行加密或解密，其中，所述应用的数据可包括所述第一数据。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一硬件引擎基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文，包括：所述第一硬件引擎基于密钥参数和所述第一根密钥，对所述第一密钥明文进行加密，生成第一密文数据，以及根据所述第一密文数据，获取校验数据；其中，所述第一密钥密文包括所述密钥参数、所述第一密文数据以及所述校验数据；所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文，包括：所述第二硬件引擎基于所述第一密钥密文中的所述校验数据，对所述第一密文数据进行校验认证，在校验认证通过的情况下，所述第二硬件引擎基于所述密钥参数和所述第一根密钥，对所述第一密文数据进行解密，获取所述第一密钥明文，其中，所述第一密钥明文用于对所述第一数据进行加密或解密。
根据第二方面，或者以上第二方面的任意一种实现方式，所述数据处理系统还包括第一软件程序、第二软件程序，所述第二软件程序具有第一接口，第一应用运行在所述REE中，所述方法还包括：所述第一软件程序控制所述第一硬件引擎进行运算和读写操作；所述第二软件程序控制所述第二硬件引擎进行运算和读写操作，以及通过所述第一接口 与所述第一应用通信，以及调用所述第一软件程序。
根据第二方面，或者以上第二方面的任意一种实现方式，所述方法还包括：所述第二软件程序响应于所述第一应用对所述第一接口的第三请求，调用所述第一软件程序以控制所述第一硬件引擎，其中，所述第三请求包括用于指示所述第一应用的第二密钥密文的信息，所述第二密钥密文为基于第四根密钥对所述第一密钥明文进行加密后的数据。其中，所述第四根密钥为所述第一硬件引擎基于第二变量和所述第二根密钥生成的根密钥；其中，所述第一密钥明文为基于所述第四根密钥对所述第二密钥密文进行解密后的数据。
示例性的，所述第一硬件引擎，还用于按照第二变量和所述第二根密钥，获取第四根密钥，其中，所述第四根密钥用于对所述第一密钥明文进行加密或解密；以及基于所述第四根密钥对所述第一应用的第二密钥密文解密，生成所述第一密钥明文，其中，所述第二密钥密文由所述第一应用根据所述第一密钥明文生成并通过所述第二软件程序发送至所述第一软件程序。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一软件程序获取第一公钥明文，并将所述第一公钥明文发送至所述第二软件程序，其中，所述第一公钥明文为在所述数据处理系统初始化时，所述第一硬件引擎生成的第二真随机数；所述第二软件程序将所述第一公钥明文发送至所述第一应用；所述第二软件程序，还用于响应于所述第一应用对所述第一接口的第四请求，调用所述第一软件程序以控制所述第一硬件引擎，其中，所述第四请求包括用于指示第三密钥密文的信息，其中，所述第三密钥密文为基于所述第一公钥明文对所述第一密钥明文进行加密后的数据。其中，所述第一密钥明文为基于第一私钥明文对所述第三密钥密文进行解密后的数据；其中，所述第一私钥明文为在所述数据处理系统上电时，所述第一硬件引擎生成的第三真随机数；其中，所述第一根密钥还用于对所述第一私钥明文进行加密或解密。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第一硬件引擎包括第三真随机数生成模块；
示例性地，所述第三真随机数生成模块可以与上述第一真随机数生成模块相同或不同，本申请对此不做限制。
所述第二软件程序可响应于所述第一应用对所述第一接口的第五请求，调用所述第一软件程序以控制所述第一硬件引擎，所述第五请求包括所述第一密钥明文；
所述第三真随机数生成模块可响应于所述第五请求，生成第四真随机数作为所述第一应用的所述第一密钥明文。
本申请实施例中，第一硬件引擎可使用真随机数生成模块来生成第一应用的工作密钥(即第一密钥明文)，无需应用导入工作密钥，使得本申请实施例的方法所应用的系统可应用到密钥生成场景中。
根据第二方面，或者以上第二方面的任意一种实现方式，所述第二软件程序可响应于所述第一应用对所述第一接口的第六请求，调用所述第一软件程序以控制所述第一硬件引擎，所述第六请求包括所述第一密钥明文；所述第一硬件引擎可将所述第一密钥明文写入所述第一存储单元；所述第二硬件引擎还包括第二寄存器。
示例性地，所述第二寄存器为软件可写、软件不可读；
所述第二硬件引擎可从所述第一存储单元读取所述第一密钥明文，并将所述第一密钥明文写入所述第二寄存器，其中，所述第二寄存器用于存储所述第一密钥明文。
本申请实施例的系统中，可在第二硬件引擎内保留应用直接设置明文密钥的第二寄存器的通道，可为应用提供传入明文密钥到第二硬件引擎的通道，由于应用可直接传入密钥明文到REE中的第二硬件引擎，而无需传入密钥明文到运行在TEE或SEE中的第一硬件引擎，从而只需在REE中就可以实现密钥导入以及使用导入的密钥进行数据加解密的操作，能够对数据加解密性能进行加速，不需要占用CPU负载。
根据第二方面，或者以上第二方面的任意一种实现方式，所述系统集成在SoC中。
第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第三方面，本申请实施例提供一种芯片，包括一个或多个接口电路、一个或多个处理器、多个硬件引擎、第一存储单元以及AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在TEE或SEE中，所述第二硬件引擎运行在REE中，所述多个硬件引擎可实现第二方面以及第二方面的任意一种实现方式中的方法。
第三方面以及第三方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第四方面，本申请实施例提供一种计算机可读存储介质。计算机可读存储介质存储有计算机程序，当计算机程序运行在计算机或处理器上时，使得计算机或处理器执行第二方面或第二方面的任一种可能的实现方式中的方法。
第四方面以及第四方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第五方面，本申请实施例提供一种计算机程序产品。计算机程序产品包含软件程序，当软件程序被计算机或处理器执行时，使得第五方面或第五方面的任一种可能的实现方式中的方法被执行。
第五方面以及第五方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。
第六方面，本申请实施例提供一种数据处理装置，包括多个硬件引擎、第一存储单元以及AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在TEE或SEE中，所述第二硬件引擎运行在REE中，所述数据处理装置用于执行如第二方面或第二方面的任一种可能的实现方式中的方法。
第六方面以及第六方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。第六方面以及第六方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。
附图说明
图1为本申请实施例的一种多硬件密码引擎系统的架构示意图；
图2为本申请实施例的一种多硬件密码引擎系统与应用交互的框架图；
图3为本申请实施例的一种多硬件密码引擎之间的交互过程的示意图；
图4a为本申请实施例的一种在密钥生成场景下的多硬件密码引擎系统的工作流程图之一；
图4b为本申请实施例的一种多硬件密码引擎系统的密钥加密过程的时序图；
图4c为本申请实施例的一种多硬件密码引擎系统的密钥使用过程的时序图；
图5为本申请实施例的一种多硬件密码引擎系统的密钥使用过程的工作流程图；
图6为本申请实施例的一种多硬件密码引擎系统的密钥使用过程的时序图；
图7为本申请实施例的一种多硬件密码引擎系统的密钥使用过程的时序图；
图8为本申请实施例的一种在密钥无封装导入场景下的多硬件密码引擎系统的工作流程图；
图9为本申请实施例的一种在密钥有封装导入场景下的多硬件密码引擎系统的工作流程图；
图10为本申请实施例的一种在密钥无封装导入场景下的多硬件密码引擎系统的工作流程图；
图11为本申请实施例的一种在密钥无封装导入场景下的多硬件密码引擎系统的工作流程图；
图12为本申请实施例提供的一种装置的结构示意图；
图13为本申请实施例提供的一种芯片的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整 地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
在传统技术中，Android Keystore(安卓密钥库)系统可以在一个安全的容器中(如借助于SoC提供的TEE)存储加密密钥。在应用的加密密钥进入Keystore之后，密钥不可导出，从而可以在不导出密钥的前提下，利用容器中存储的加密密钥对应用数据实现加密操作，以提高从终端设备中提取密钥的难度。
Keystore能够提供以下类别的操作：生成密钥；导入和导出不对称密钥(无密钥封装，仅公钥可导出)；导入原始对称密钥(无密钥封装)；使用适当的填充模式进行不对称加密和解密；使用摘要和适当的填充模式进行不对称签名和验证；以适当模式(包括AEAD模式)进行对称加密和解密；生成和验证对称消息验证码。
其中，生成或导入密钥时，系统会指定协议元素(例如，用途、模式和填充，以及访问控制限制)，这些元素会永久绑定到相应密钥，以确保无法以任何其他方式使用相应密钥。
Keystore可使用两项安全措施来避免密钥材料被提取：
1)密钥材料永不进入应用进程。
通过Android Keystore内的密钥执行加密操作时，应用会在后台将待签署或验证的明文、密文和消息馈送到执行加密操作的系统进程。如果应用进程受到攻击，攻击者也许能使用应用密钥，但无法提取密钥材料(例如，在Android设备以外使用)。
2)开发者可以将密钥材料绑定至Android设备的安全硬件，例如TEE和SE。
为密钥启用此功能时，其密钥材料永远不会暴露于安全硬件之外。如果Android操作系统受到攻击或者攻击者可以读取设备内部存储空间，攻击者也许能在Android设备上使用任意应用的Android Keystore，但无法从设备上提取这些数据。只有设备的安全硬件支持密钥算法、分块模式、填充方案和密钥有权配合使用的摘要的特定组合时，才可启用此功能。
运行Android 9或更高版本的受支持设备可拥有StrongBox Keymaster，它是位于 硬件安全模块(hardware security module)中的一种实现。
该硬件安全模块可包含以下组成部分：
独立CPU，不与应用处理器(AP，Application Processor)共享任何缓存、DRAM(Dynamic Random Access Memory，动态随机存取存储器)、协处理器或其他核心资源；
安全存储空间，必须具有安全存储空间，以确保内容的机密性、完整性、真实性、一致性和新鲜度。除非经过StrongBox API允许，否则不得读取或更改存储内容；
真随机数生成器；
具有防篡改功能，包括防物理渗透和干扰，必须能够抗侧信道攻击。
在检查存储在StrongBox Keymaster中的密钥时，Android Keystore系统会通过TEE证实密钥的完整性。
此外，安全密钥导入(Secure Key Import)是Android 9的新功能。在该新功能中，可允许应用程序以更安全的方式将已有密钥植入到密钥库中，还可适用于多种企业应用场景。而密钥的来源可能位于本地或云数据中心的远程服务器，可使用来自用户设备的公开封装密钥对安全密钥进行加密。另外，只有搭载Keymaster 4或更高版本的设备才支持该安全密钥导入功能。
对于Android 9之前的Keymaster版本仅支持TEE的安全级别。TEE是基于同一CPU进行资源隔离和时间片轮换的执行环境，安全级别低于纯硬件隔离的安全级别。
Android 9或更高版本可支持StrongBox Keymaster，但StrongBox Keymaster所依附的SE的CPU一般是智能卡级别，具有较高的安全性，但加解密性能较弱；而如果把用于数据加解密的工作密钥导出StrongBox Keymaster，以提升加解密性能，则密钥明文会出硬件，安全级别将降低到TEE或更低级别。
因此，终端设备的基于SoC平台的硬件密码引擎在为上层应用提供密码服务时，其SoC内部的硬件密码引擎设计较为关键，需要在性能、安全和面积(与成本相关)等方面权衡。
为此，本申请实施例的SoC提供了多硬件密码引擎，可以使用多硬件密码引擎联动的方式提供密码服务(后文称HiCrypto Service(Hardware inside Crypto Service))，以达成安全、性能和成本的平衡。可以理解的是，硬件密码引擎用于表示硬件引擎中增加了密码相关的算法处理过程。在上述多硬件密码引擎中，密钥可置于多硬件密码引擎中，能够在密钥不导出硬件的情况下，实现应用数据的加解密，安全级别可达到纯硬件隔离的安全级别，并能够增强加解密性能。
图1示例性地示出了本申请实施例的一种多硬件密码引擎系统的架构图。
图2示例性地示出了本申请实施例的一种多硬件密码引擎系统与应用交互的框架图。
请参照图1，该多硬件密码引擎系统，可包括位于硬件层的SoC的安全子系统，该安全子系统可包括多硬件密码引擎。
其中，硬件密码引擎用于表示增加了密码相关的算法处理的硬件引擎。
其中，多硬件密码引擎可包括REE硬件密码引擎(后文称HCE-REE引擎)、TEE硬件密码引擎(后文称HCE-TEE引擎)。
可选地，HCE-REE引擎和HCE-TEE引擎可以是一个被动的HCE(Hardware Crypto  Engine，硬件密码引擎)内的两个子模块。
另外，考虑到SoC的面积成本和市场需求等因素，如图1所示，安全子系统的多硬件密码引擎可选地包括inSE。
其中，inSE(Inside/or On-die Secure Element，内部或片上安全元件)是一个片上硬件安全模块，可包括但不限于：独立的安全CPU、真随机数生成器(True Random Number Generator，TRNG)和安全存储空间。
请继续参照图1，该多硬件密码引擎系统可包括位于REE内核层的硬件密码引擎驱动。
硬件密码引擎驱动用于调用HCE-REE引擎和HCE-TEE引擎。
示例性地，如图2所示，该硬件密码引擎驱动可包括用于调用HCE-REE引擎的HCE-REE驱动和用于调用HCE-TEE引擎的HCE-TEE驱动。
可选地，如图1所示，该多硬件密码引擎系统还可包括inSE操作系统(即SEE OS)，SEE OS用于调用inSE。
请继续参照图1，该多硬件密码引擎系统还可包括位于硬件抽象层的密码服务。
本申请实施例的多硬件密码引擎可联动地提供上述密码服务(后文称HiCrypto Service)。该密码服务可提供操作系统的SDK(Software Deve lopment Kit，软件开发工具包)接口，以向应用开发者提供本申请实施例的多硬件密码引擎系统的密码服务。
如图1所示，该密码服务可用于调用内核层的硬件密码引擎驱动，可选地，用于调用inSE操作系统，以实现对多硬件密码引擎的控制，从而对使用本申请实施例的多硬件密码引擎系统的应用提供数据加解密服务。
示例性地，请参照图2，HiCrypto Service作为和多硬件密码引擎配套使用的软件，可包括运行在TEE中的HCE-TEE密码服务、运行在REE(Rich Execution Environment，富执行环境)中的HCE-REE密码服务，可选地，还可包括运行在SEE(Secure Execution Environment，安全执行环境)中的inSE密码服务。
HCE-TEE密码服务、HCE-REE密码服务、inSE密码服务这三种软件组件均为多硬件密码引擎系统内出厂内置的软件，并可对REE中的应用(App，Application)提供HUKS(Harmony Universal KeyStore，鸿蒙通用密钥库系统)接口，以向APP提供密码服务。
示例性地，HUKS接口可以是图1中的SDK接口的一部分，可用于对应用层的应用提供调用本申请实施例所述的密码服务的接口。
示例性地，HUKS接口可包括但不限于C、C++、Java、JS等多语言的API(Application Programming Interface，应用程序编程接口)。
示例性地，HCE-TEE密码服务用于调用HCE-TEE驱动来使HCE-TEE引擎进行工作。
示例性地，HCE-TEE引擎可用于生成或导入应用的工作密钥，以及对该工作密钥进行加密。
可选地，inSE密码服务用于调用SEE OS来使inSE进行工作。
示例性地，inSE可用于生成或导入应用的工作密钥，以及对该工作密钥进行加密。
示例性地，HCE-REE密码服务可用于接收APP对HUKS接口的调用请求，并响应于该调用请求(例如用于生成或导入工作密钥的调用请求)，来调用HCE-TEE密码服务或inSE 密码服务，HCE-TEE密码服务或inSE密码服务可响应于该调用请求，在HCE-TEE引擎或inSE中生成或导入应用的工作密钥，以及对工作密钥在硬件引擎内进行加密，并将加密后得到的工作密钥的密文结构返回给App。
示例性地，HCE-REE密码服务还可用于接收APP对HUKS接口的调用请求(可携带该密文结构)，并响应于该调用请求(例如用于对应用数据进行加解密的调用请求)，来调用HCE-REE驱动以使HCE-REE引擎进行工作，HCE-REE引擎可基于该密文结构来对应用数据进行加解密。
示例性地，HCE-REE引擎可用于对HCE-TEE引擎或inSE生成的工作密钥密文(即本文中的key密文)进行解密，并使用解密后的工作密钥明文(即本文所述的key明文)，来对App的应用数据进行加解密操作。
如图2所示，HCE-REE密码服务(HiCrypto CA(Client Application，客户端应用程序)，后文简称CA)运行在REE中，HCE-TEE密码服务(HiCrypto TA(Trusted Application，可信应用程序)，后文简称TA)运行在TEE中，因此，HiCrypto CA和HiCrypto TA可运行在终端设备(例如手机)的ACPU(Application CPU，应用处理器)之上。而inSE具有独立CPU，因此，inSE密码服务(HiCrypto SA(Secure Application，安全应用程序，指代inSE的应用程序)，后文简称SA)运行在inSE的独立CPU之上。
需要说明的是，图1和图2所示的箭头方向为请求或命令调用方向，在图1和图2中，存在交互(即存在单箭头)的各模块之间的数据流方向则可以是双向的。
另外，在图2中，HCE-TEE密码服务、HCE-TEE驱动、以及HCE-TEE引擎都是运行在TEE中的；App、HUKS接口、HCE-REE密码服务、HCE-REE驱动、以及HCE-REE引擎都是运行在REE中的；inSE密码服务、SEE OS、以及inSE都是运行在SEE中的。
应当理解的是，inSE在多硬件密码引擎系统中为可选地硬件结构，那么如图2的虚线框所示的inSE密码服务、SEE OS、以及inSE在系统架构中也是可选地。
示例性地，应用在启动阶段，可触发用于生成或导入工作密钥的函数调用请求，以在HCE-TEE引擎或inSE中生成或导入密钥(或在HCE-REE引擎中导入密钥)；并在终端设备未重启的情况下，应用可多次触发用于对应用数据进行加解密的函数调用请求，以使HCE-REE引擎使用生成或导入的密钥，来对应用数据执行多次加解密操作。
其中，用于生成工作密钥的函数接口，与用于导入工作密钥的函数接口可以不同。
另外，需要说明的是，App在请求对应用数据进行加解密时，可通过一段式函数调用或三段式函数调用的方式来实现。
对于一段式函数调用的情况，App可在调用的函数中携带待加解密数据以及上述密文结构，以使HCE-REE引擎，对该密文结构解密，得到App的工作密钥明文，并使用该工作密钥明文来对待加解密数据进行加解密操作，返回应用数据的加解密结果给App。
对于三段式函数调用的情况：
App可调用第一函数(例如CryptoInit())来传入密文结构至HCE-REE引擎，HCE-REE引擎可对密文结构解密，并将得到的工作密钥明文写入下文所述的A类寄存器中，并返回A类寄存器的句柄给App。其中，该句柄可用于标识写入有该工作密钥明文的A类寄存器。
App可调用第二函数(例如CryptoUpdate())来传入A类寄存器的句柄以及待加解密数据至HCE-REE引擎，HCE-REE引擎可基于该句柄找到存储有该App的工作密钥明文的A类寄存器，并使用该A类寄存器内的工作密钥明文，来对待加解密数据进行加解密操作，返回应用数据的加解密结构给App。
App可调用第三函数(例如CryptoFinal())来传入A类寄存器的句柄，以使HCE-REE引擎来释放存储有该App的工作密钥明文的A类寄存器，例如清除句柄指向的A类寄存器中的数据。
其中，App可多次调用第二函数，以进行多次的应用数据加解密操作。
在本申请实施例所提供的多硬件密码引擎系统中，多硬件密码引擎基于自研的SoC平台实现，应用的密钥明文仅出现在硬件密码引擎内部，可以做到所有应用密钥的明文不出硬件，使得应用密钥明文不会暴露给ACPU(Application CPU，应用处理器，A核)，那么使用ACPU的恶意应用则难以窃取应用的明文密钥，提升了应用密钥的安全性。而且，HCE-REE引擎可获取到经HCE-TEE引擎或inSE加密后的应用的工作密钥密文，并解密得到工作密钥明文；以及，REE环境中的应用可通过SDK接口调用HiCrypto CA，可在不经过其他引擎的情况下直接操作HCE-REE引擎，以能够在HCE-REE引擎内部使用工作密钥明文进行应用数据的加解密。使得应用数据的加解密过程在REE环境下即可实现，不需要切换环境到TEE或SEE，可降低通路性能损耗，提升加解密性能。因此，本申请实施例的多硬件密码引擎系统可兼顾应用的高安全性和高加解密性能。
需要说明的是，图1示出的硬件抽象层、内核层、硬件层所包含的部件，并不构成对本申请实施例的多硬件密码引擎系统的具体限定。在本申请另一些实施例中，该系统还可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。
对于图1中SoC的安全子系统内的多硬件密码引擎，图3示例性地示出了本申请实施例的多硬件密码引擎之间的交互过程的示意图。
如图3所示，考虑到HCE-TEE引擎与inSE的部分功能相同，因此，为了便于理解，将HCE-TEE引擎与inSE之间相同的模块和相同的功能在同一框图中示出。
需要说明的是，在一种可能的实施方式中，SoC的多硬件密码引擎可包括HCE-REE引擎和HCE-TEE引擎，那么图3所示的HCE-TEE引擎/inSE的模块用于表示HCE-TEE引擎。
在一种可能的实施方式中，SoC的多硬件密码引擎可包括HCE-REE引擎和HCE-TEE引擎以及inSE，那么图3所示的HCE-TEE引擎/inSE的模块用于表示inSE，则在图3中未示出HCE-TEE引擎。
需要说明的是，图4a、图8、图9中所示的HCE-TEE引擎/inSE的模块，与图3所示的HCE-TEE引擎/inSE的模块所表达的引擎类似，不同实施方式中，可表达不同的硬件引擎。
如图3所示，该安全子系统可包括AO(Always On，常开，不掉电)寄存器(又称SessionKey寄存器)，AO寄存器与HCE-TEE引擎、HCE-REE引擎、inSE(在多硬件引擎包括inSE的情况下)均硬线连接(一种芯片级连接)。
AO寄存器在该多硬件密码引擎系统初始化时写一次数据，并且，AO寄存器不掉电， 软件不可读且写锁定，例如大小为256bit。
如图3所示，HCE-TEE引擎可包括TRNG，KM(Key Management，密钥管理)加密模块。
示例性地，TRNG可用于生成随机数。
KM加密模块所使用的加密算法包括但不限于AES(Advanced Encryption Standard，高级加密标准，一种对称加密算法)、SM4(SM4algorithm，SM4算法，一种对称分组密码算法)，还可包括安全强度足够的其他对称分组密码算法。
示例性地，KM加密模块可用于利用AES或SM4算法的GCM模式，来执行加密操作，但是本申请对于KM加密模块所使用的认证加密算法的具体算法并不限制于AES或SM4的GCM模式，还可以是其他认证加密算法。
可选地，在SoC包括inSE的情况下，inSE可包括TRNG和KM加密模块，其功能与上文对HCE-TEE引擎内部模块的功能描述一样，这里不再赘述。
如图3所示，HCE-REE引擎可包括KM解密模块、A类寄存器，数据加解密模块，如图3的HCE-REE引擎内的虚线所示，HCE-REE引擎可选地包括B类寄存器。
图3中的虚线用于表示多硬件密码引擎的可选模块和可选操作。
示例性地，所述KM解密模块可用于利用AES或SM4算法的GCM模式，来执行解密操作，同样的，本申请对于KM解密模块所使用的认证解密算法的具体算法并不限制于AES或SM4的GCM模式，还可以是其他认证解密算法。
示例性地，A类寄存器，用于对进入HCE-REE引擎中的密文密钥进行设置，软件不可读且不可写。需要说明的是，A类寄存器所存储的数据是该密文密钥的明文格式，即图3所示的key明文。
示例性地，A类寄存器的数量可以是一个或多个，例如HCE-REE引擎包括Key slot1～Key slot n的n个A类寄存器，n为正整数，n的具体数值不做限制，可根据实际需要而灵活配置A类寄存器的数量。
示例性地，B类寄存器，用于对进入HCE-REE引擎中的明文密钥进行设置，软件可写但不可读。
示例性地，B类寄存器的数量可以是一个或多个，具体数量可根据实际需求而灵活配置。在B类寄存器的数量为多个的情况下，多个B类寄存器可分别用于存储不同应用的明文密钥(即明文工作密钥)。后文以一个B类寄存器(例如Key slot 0)为例进行说明。
此外，如图3所示，HCE-TEE引擎、HCE-REE引擎、inSE之间可通过该三个硬件密码引擎共享的共享内存进行数据或指令或密钥等信息的传输。
示例性地，共享内存的实现方式可包括但不限于：DDR(DDR SDRAM，双倍速率同步动态随机访问存储器)、NVM(Non-volatile memory，非易失性存储器，掉电不丢失数据掉线不丢失的内存)。
对于图3中上述三个硬件密码引擎的内部模块在执行各自的功能时，可分别由如图2所示的三个硬件密码引擎各自的软件服务来控制。
具体而言，CA可调用TA，由TA调用HCE-TEE驱动，来使HCE-TEE引擎或inSE执行图3中所示的HCE-TEE引擎执行的过程；或者，CA可调用SA，由SA调用SEE OS，来 使inSE执行图3中所示的inSE执行的过程。
另外，CA可调用HCE-REE驱动，来使HCE-REE引擎执行图3所示的HCE-REE引擎所执行的过程。
为了更加清楚简洁的描述本申请的技术方案，后文将不再详细赘述硬件密码引擎的密码服务，通过控制驱动或inSE操作系统，来对该硬件密码引擎进行控制的具体过程。
下面对图3所示的各硬件密码引擎内部模块的工作过程做简单描述。
首先，对HCE-TEE引擎内部模块的工作过程进行描述：
在多硬件密码引擎系统初始化启动阶段，或者该多硬件密码引擎系统所在的主机或终端设备初始化启动阶段，或者多硬件密码引擎系统上电时，HCE-TEE引擎内部的TRNG可随机生成根密钥，并通过例如DMA(Direct Memory Access，直接存储器访问)等硬线方式将所述根密钥直接设置到AO寄存器中。
需要说明的是，本文所述的根密钥用于表示应用的工作密钥的加密密钥。
可选地，在一个实施例中，TRNG所执行的上述过程，可由软件触发实现，例如在终端设备启动BootLoader阶段，BootLoader控制图2中的TA，图2中的TA调用HCE-TEE驱动，来触发TRNG实现上述过程，以提升根密钥生成方式的灵活性。
考虑到终端设备启动BootLoader阶段，即多硬件密码引擎系统初始化时，TA调用HCE-TEE驱动来控制TRNG生成根密钥，并控制TRNG将根密钥写入AO寄存器的过程，会使根密钥在终端设备启动BootLoader阶段的短暂窗口期中进入TEE的内存。为此，为了提高根密钥的安全性，可选地，在另一个实施例中，对于TRNG生成根密钥，以及将生成的根密钥设置至AO寄存器的过程可不经软件触发，而配置TRNG在系统上电时自动执行生成根密钥，将根密钥写入AO寄存器。
在HCE-TEE引擎运行阶段，HCE-TEE引擎中的KM加密模块，可从AO寄存器读取所述根密钥，并采用所述根密钥来对应用的工作密钥明文(即图3和后续实施例所述的key明文)进行加密，并将key明文的加密结果送入共享内存。
需要说明的是，图3中HCE-TEE引擎中的key明文可以是应用导入至HCE-TEE引擎的(可以有密钥封装或密钥无封装导入)，也可以是HCE-TEE引擎生成的，本申请对此不做限制。
然后，对inSE内部模块的工作过程进行描述：
在多硬件密码引擎系统初始化启动阶段，或者该多硬件密码引擎系统所在的主机或终端设备初始化启动阶段，或者多硬件密码引擎系统上电时，HCE-TEE引擎内部的TRNG可随机生成根密钥，并通过例如DMA等硬线方式将所述根密钥直接设置到AO寄存器中。
需要说明的是，本文所述的根密钥用于表示应用的工作密钥的加密密钥。
可选地，在一个实施例中，TRNG所执行的上述过程，可由软件触发实现，例如在终端设备启动BootLoader阶段，BootLoader控制图2中的TA，图2中的TA调用HCE-TEE驱动，来触发TRNG实现上述过程，以提升根密钥生成方式的灵活性。
可选地，在另一个实施例中，对于TRNG生成根密钥，以及将生成的根密钥设置至AO寄存器的过程可不经软件触发，而配置TRNG在系统上电阶段自动执行上述过程。
由于inSE具有独立CPU，那么不论TRNG经有软件控制还是自动执行上述过程，都不 会使根密钥出硬件，确保根密钥的安全，进而确保应用的工作密钥的安全。
在inSE运行阶段，inSE中的KM加密模块，可从AO寄存器读取TRNG所设置的所述根密钥，并采用所述根密钥来对应用的工作密钥明文(即图3和后续实施例所述的key明文)进行加密，并将key明文的加密结果(可以是下文所述的密文结构，或者key明文的密文结果)送入共享内存。
需要说明的是，图3中inSE中的key明文可以是应用导入至inSE的(可以有密钥封装或密钥无封装导入)，也可以是inSE生成的，本申请对此不做限制。
可选地，在SoC包括inSE的场景下，考虑到HCE-TEE引擎的安全性相较inSE的安全性较低，那么为了提升安全性，可按照图2所示的流程，由CA调用SA，来触发inSE执行图3所示的上述过程。
示例性地，在SoC不包括inSE的场景下，可按照图2所示的流程，由CA调用TA，来触发HCE-TEE引擎执行图3所示的上述过程，以确保性能和安全的均衡。
最后，对HCE-REE引擎内部模块的工作过程进行描述：
KM解密模块，可用于从共享内存读取由inSE或HCE-TEE引擎写入的key明文的加密结果，以及用于从AO寄存器读取所述根密钥，以及用于采用所述根密钥对该加密结果进行解密，以获取key明文，并用于将key明文发送至A类寄存器。
数据加解密模块，可用于从A类寄存器读取key明文；以及采用该key明文，来对数据明文加密，生成数据密文；或者用于采用该key明文，对数据密文解密，生成数据明文。
可选地，本申请实施例的HCE-REE引擎保留了用于设置工作密钥明文的B类寄存器的通道，以使REE中的应用可传入key明文至共享内存，并且CA可控制HCE-REE驱动，从共享内存读取应用导入的key明文，并将key明文写入B类寄存器。那么HCE-REE引擎中数据加解密模块可用于从B类寄存器读取key明文，并利用该key密文执行数据的加解密操作，无需切换运行环境至TEE或SEE，可提升数据加解密性能。
在图3的SoC中，可提供AO寄存器(不可读，写锁定)硬线连接(芯片级连接)给多硬件密码引擎使用，使得应用的工作密钥在多硬件密码引擎之间传输时，可由每次终端设备开机时HCE-TEE引擎或inSE中的TRNG随机生成的真随机数保护，能够使工作密钥在多硬件密码引擎之间进行安全传输，工作密钥明文全程不出硬件，提升密钥安全性。
此外，多硬件密码引擎之间除安全的AO寄存器的通道外，设计上可有效的解耦，并能够独立运行，互不影响，有利于最大化发挥性能。
在上述实施例中，AO寄存器可用于存储根密钥(应用的工作密钥的加解密密钥)，使得HCE-TEE引擎、HCE-REE引擎、inSE之间通过AO寄存器在传递根密钥时，ACPU不可见，达到硬件隔离级别的安全度。
下面结合不同的应用场景，来对本申请实施例的多硬件密码引擎系统的工作过程做详细阐述。
密钥生成场景。
图4a示例性地示出了一种在密钥生成场景下的多硬件密码引擎系统的工作流程图。
图4b示例性地示出了一种多硬件密码引擎系统的密钥加密过程的时序图。
在图4a中，描述了将密钥鉴权的方案与本申请实施例的系统架构相结合的系统工作流程。需要说明的是，在其他应用场景下，本申请实施例的多硬件密码引擎系统同样可根据业务需求而包括图4a所描述的密钥鉴权方案，后文不再对各个场景一一赘述密钥鉴权方案，请参考本实施例所描述的鉴权方案即可。
示例性地，本实施例的密钥鉴权方案所使用的认证加密算法为GCM(Galois/Counter Mode，伽罗华计数器模式，一种分组密码算法模式)，但是本申请对于认证加密算法并不做具体限制。
示例性地，图4a中的KM加密模块和KM解密模块所使用的认证加密算法可为AES或SM4算法的GCM模式。
SM4的GCM模式可以用于认证加密以保证明文或其它认证内容的完整性，在加密时可包括但不限于以下参数：IV值、TAG，可选地包括额外认证数据(AAD，Additional Authentication Data)。
示例性地，AAD数据可用于鉴权和防假冒。
示例性地，在AES的GCM模式中，IV值的长度可为12字节，但本申请对于IV值的长度不做限制。
示例性地，TAG是GCM模式中的消息认证码，用于验证被加密数据及AAD的完整性，GCM模式的TAG的长度至少为12字节，优选为16字节。
本系统在对应用的敏感数据(即待加密的应用明文数据)进行加密的同时，如果存在需要保护完整性但无需保护机密性的数据时(例如程序上下文数据)，则可以将其作为AAD参数，以保护其完整性。
下面结合图2来对图4a～图4c进行描述：
如图4a所示，HCE-TEE引擎和inSE在用于密码生成时，内部模块的功能类似，因此，在图4a中将两个硬件密码引擎的内部模块在一个框图中描述，为了便于读者理解，图4b和图4c以HCE-TEE引擎来执行图4a所示的密钥生成和密钥加密流程为例进行说明，但是需要注意的是，inSE执行图4a所示的流程与HCE-TEE引擎所执行的流程类似，可参考图4b和图4c的描述，后文不再一一赘述。
请参照图4a和图4b，该本申请实施例的流程可包括如下步骤：
S101，TA通过调用HCE-TEE驱动控制HCE-TEE引擎生成根密钥。
S103，HCE-TEE引擎生成根密钥，并将根密钥写入AO寄存器。
示例性地，在安装有本系统的终端设备启动阶段，TRNG可生成随机数作为根密钥，并以硬线方式写入AO寄存器，如图3实施例的描述，该过程可由软件控制(这里的S101、S103的实现由软件控制)或者TRNG自动执行，本申请对此不做限制。
可选地，在由软件控制来将应用的根密钥写入AO寄存器时，该根密钥不仅可以是TRNG生成的随机数，还可以是对硬件根密钥按照派生分量得到的派生后得到的根密钥，例如可对图9(1)中所示的硬件根密钥派生(派生分量可以与9(1)中的派生分量相同或不同)得到作为写入AO寄存器的根密钥等，本申请对于写入AO寄存器中的根密钥的具体生成方式不做限制。
S201，App通过调用HUKS接口触发密钥生成请求，并将密钥生成请求发送至CA。
示例性地，在App启动之后，如图2所示，App可调用HUKS接口来调用CA。
本申请实施例描述的是一段式函数调用，那么App触发的第一加密请求可包括但不限于：待加解密数据(以待加密数据为例，待加密数据为图4a的HCE-REE引擎中的数据明文)的信息，可选地，还可包括AAD参数。
示例性地，AAD参数可包括但不限于：App的程序上下文数据(包括但不限于包名)、KeyAlias和App的工作密钥的密钥参数等。
S202，CA响应于密钥生成请求，发送第一调用请求至TA。
S203，TA可响应于第一调用请求，通过调用HCE-TEE驱动，以控制HCE-TEE引擎生成工作密钥并对工作密钥加密。
可选地，在S202和S203的过程中，该第一调用请求中的AAD参数可经软件控制写入HCE-TEE引擎。
S204，HCE-TEE引擎生成工作密钥(即图4a中的key明文)，并获取鉴权参数。
示例性地，如图4a所示，HCE-TEE引擎的TRNG可生成随机数来作为工作密钥，即key明文。
当然，本申请对于HCE-TEE引擎生成key明文的方式并不限制于通过TRNG来实现，还可以通过其他方式来实现，具体方式可根据需要灵活配置。
示例性地，这里的鉴权参数可包括但不限于：HCE-TEE引擎中TRNG生成的IV值、应用传入的AAD参数。
S205，HCE-TEE引擎可从AO寄存器读取根密钥，并利用根密钥对key明文加密，得到密文结构。
示例性地，如图4a所示，HCE-TEE引擎的KM加密模块可使用GCM模式，来使用IV值以及从AO寄存器读取的根密钥，来对待加密数据(这里包括key明文)进行加密，生成key密文；以及KM加密模块对key密文和AAD计算出TAG。最后，得到密文结构(包括IV、key密文、TAG以及AAD参数)。
S2061，HCE-TEE引擎将密文结构写入共享内存。
示例性地，共享内存可包括掉电丢失数据的存储区域(例如DDR)，和掉电不丢失数据的存储区域(例如NVM)。
示例性的，如图4a所示，KM加密模块可将生成的密文结构写入DDR。
示例性地，考虑到DDR中的数据掉电会丢失，如图4a所示，HCE-TEE引擎中还配置了HUK(Hardware Unique Key，硬件唯一密钥)加密模块，HUK加密模块可配置有硬件唯一密钥(即硬件根密钥)。那么HUK加密模块可采用对硬件根密钥所派生的密钥，来对key明文加密，并生成key密文’，这里将key明文的密文命名为key密文’，用于区分图4a中DDR内的key密文。
Key密文’，用于表示采用图4a所示的HUK加密模块对硬件根密钥派生的密钥作为加密密钥，对key明文进行加密得到的工作密钥密文。
而key密文(例如图4a中DDR内的key密文)，用于表示以AO寄存器中的根密钥作为加密密钥对key明文进行加密后的工作密钥密文。
本申请可提供对工作密钥明文进行加解密的两种密钥，一种为TRNG随机生成的根密 钥，一种为对硬件根密钥派生得到的密钥，采用TRNG生成的写入AO寄存器内的随机数作为根密钥，安全性更高。
示例性的，如图4a所示，HUK加密模块可将生成的key密文’写入NVM安全存储区域，使得掉电后，HUK加密模块还可从NVM安全存储区读取到工作密钥的密文，以用于应用数据的加解密，提升数据加解密的可靠性。
可选地，在一种实施方式中，如图4a所示，HUK加密模块未配置有诸如GCM等的认证加密算法，只是非认证加密算法。那么为了进行鉴权，如果系统掉电，HUK加密模块可从NVM安全存储区读取key密文’，并使用硬件唯一密钥进行解密，得到key明文。然后再经KM加密模块进行GCM模式的加密，将密文结构写入DDR。
可选地，在另一种实施方式中，HUK加密模块也可以配置有包括但不限于GCM的认证加密算法，使得HUK加密模块生成的密文结构也是带认证数据的(例如包括IV、key密文’、TAG、AAD等)。在系统掉电后，可直接使用NVM安全存储区的密文结构，来写入HCE-REE引擎。
可选地，对于密文结构在共享内存中的写入地址，可由CA配置为S202的第一调用请求中的参数，以此经S203传递至HCE-TEE驱动进行HCE-TEE引擎的控制。
或者，可选地，对于密文结构在共享内存中的写入地址，可由TA配置为S203的参数，待S205之后，TA可将密文结构的地址信息返回给CA。
在生成与特定程序和该特定程序的密钥绑定的密文结构之后，可将该密文结构作为句柄返回给App。
那么在S2061之后，该流程还包括：S2062，CA可响应于密钥生成请求，将该App的密文结构在共享内存中的地址信息返回给App。
示例性地，App可依据该地址信息从共享内存中读取密文结构，以用于请求对应用数据进行加解密时携带。
应用可触发密钥生成请求，以触发执行图4b的流程，以实现对应用的工作密钥的加密，并将工作密钥的密文结构作为响应结果返回给应用。在终端设备未重启的情况下，应用可携带该密文结构来通过一段式或分段式函数调用，来请求对应用数据进行加解密。
1-1、一段式函数调用场景。
在图4c中，以App通过一段式函数调用为例，示例性地示出了一种多硬件密码引擎系统的密钥使用过程的时序图。
如图4c所示，App使用经图4b的流程所返回的密文结构，来请求对应用数据进行加密的过程，该流程可包括：
S215，App通过调用HUKS接口，触发数据加密请求；
示例性地，App可将密文结构写入共享内存，并将该密文结构在共享内存的地址信息携带至该数据加密请求中。
示例性地，App可将数据明文写入共享内存，并将该数据明文在共享内存的地址信息携带至该数据加密请求中。
S207，CA可响应于数据加密请求，通过调用HCE-REE驱动，以控制HCE-REE引擎读取App的数据明文。
S208，HCE-REE引擎从共享内存读取数据明文。
示例性地，数据加密请求中数据明文的信息可以是数据明文的地址信息(又称源地址)，处于REE环境中的上述App可将数据明文写入共享内存，并将数据明文在共享内存中的地址(即源地址)携带至数据加密请求中，以使HCE-REE引擎可受HCE-REE驱动控制，从该源地址读取数据明文。
S209，CA响应于数据加密请求，通过调用HCE-REE驱动，控制HCE-REE引擎读取密文结构。
示例性地，CA可基于该数据加密请求，而获取到App的密文结构在共享内存中的地址信息；并且CA可将密文结构的该地址信息作为参数通过S209传递，以控制HCE-REE引擎从共享内存中读取到密文结构。
S210，HCE-REE引擎从共享内存读取密文结构。
示例性地，如图4a所示，HCE-REE引擎中的KM解密模块可从DDR读取该应用的密文结构(包括IV、key密文、TAG、AAD参数)。
S211，HCE-REE引擎从AO寄存器读取根密钥，利用根密钥对密文结构解密，得到key明文。
示例性地，如图4a所示，HCE-REE引擎中的KM解密模块不仅可对key密文解密，得到key明文，还可进行鉴权。
示例性地，KM解密模块可用于计算TAG’，来对比TAG’与从DDR中读取的TAG是否相同，如果相同，则说明key明文和AAD都是完整的，以实现对应用的鉴权和防假冒。
KM解密模块可对从DDR中读取的key密文和AAD来计算TAG’，并对比TAG’与从DDR中读取的TAG是否相同，如果相同，则鉴权通过，否则鉴权不通过。
如果鉴权通过，KM解密模块可使用从AO寄存器读取的根密钥，以及从DDR读取的IV值，来对得到的上述key密文进行解密，得到key明文。
在KM解密模块对key密文解密成功以及鉴权成功后，可将key明文写入上文所述的A类寄存器。
通过在对该App的工作密钥加密时，设置鉴权参数，可支持对上层应用的鉴权和防假冒，以防止其他应用窃取该工作密钥，以对该App的数据进行解密。
S212，HCE-REE引擎利用key明文，对数据明文加密，得到数据密文。
示例性地，如图4a所示，HCE-REE引擎中的数据加解密模块可使用key明文，来对App的数据明文加密，得到数据密文。其中，加密算法可以包括但不限于AES、SM4等。
S213，HCE-REE引擎写入数据密文至共享内存。
示例性地，S215中App触发的数据加密请求还可包括用于写入数据密文的目标地址。
HCE-REE引擎可响应于该数据加密请求，来将数据密文写入共享内存中的该目标地址。
需要说明的是，HCE-REE引擎在执行S211、S212、S213各步骤时，也是由CA响应于数据加密请求通过调用HCE-REE驱动，来控制HCE-REE引擎执行的。
S214，App直接从共享内存读取数据密文。
示例性的，由于该目标地址由App设置，那么App可不经由本申请实施例的密码服务，直接从该目标地址读取数据密文。
在终端设备未重启的情况下，在App再次触发对数据加解密的请求时，可再次执行图4c的流程。其中，App在触发该请求时刻可携带该App的密文结构，以使CA可该密文结构进行认证和解密，并使用经过认证和解密的key明文进行数据加解密。
示例性地，如图4c所示，在终端设备未重启、App再次触发上述数据加密请求的情况下，App可将密文结构(在执行图4b的流程时由CA返回给App的密文结构)写入图4a的共享内存，并将密文结构在共享内存中的地址信息作为参数携带在S215中的该数据加密请求中，那么CA可利用App传入的密文结构的地址信息，调用HCE-REE驱动以控制HCE-REE引擎从共享内存中读取密文结构，以用于在REE环境下的数据加解密。
在上述图4a中，描述了在密钥生成场景下，HCE-TEE引擎或inSE对应用的工作密钥生成的过程，以及对生成的工作密钥进行加密的过程，以及通过App的一段式函数调用，来使HCE-REE引擎利用加密后的工作密钥进行应用数据加解密的过程。
在图4b中，描述了在密钥生成场景下，HCE-TEE引擎或inSE对应用的工作密钥生成的过程，以及对生成的工作密钥进行加密的过程。
在图4c中，描述了App通过一段式函数调用，来基于HCE-TEE引擎或inSE生成的密文结构，发送数据的加解密请求至HCE-REE引擎，HCE-REE引擎可利用该密文结构实现对应用数据的加解密。
在该过程中，App只需要触发一次函数调用，本申请实施例的系统就可以实现对该App的数据加解密。在终端设备的一次开机内(未重启)，App的工作密钥可不变，那么在App触发密钥生成请求之后，本系统可将生成的密文结构返回给App。那么在App通过一段式函数调用请求来触发数据加解密时，App可使用和该App及其工作密钥绑定的密文结构，来通过CA和HCE-REE驱动操作HCE-REE引擎进行数据加解密，使得数据加解密不需要切换到TEE或SEE，能够在REE环境下利用该密文结构来对数据进行加解密，有效减少通路性能损耗，提升数据加解密性能。
而且，App每次通过一段式函数调用请求来触发数据加解密时，HCE-REE引擎均对App传入的密文结构进行认证和解密，并使用认证通过和解密后的工作密钥来在HCE-REE引擎内进行数据加解密，使工作密钥在使用过程中可达到硬件级别安全，且工作密钥的使用过程仅在REE中完成，不需要切换到TEE或SEE，不影响加解密性能。
示例性地，本申请实施例的多硬件密码引擎系统在执行数据加解密过程时，可在HCE-TEE引擎、inSE不参与的情况下，由处于REE环境中的HCE-REE引擎使用AO寄存器中的根密钥，对key密文进行解密和认证，然后，将通过解密和认证的key明文写入A类寄存器，以对本次需要加解密的应用数据进行加解密操作，可以避免将执行环境从REE切换至TEE或SEE，有效减少通路性能损耗，可进一步提升数据的加解密性能。
可以理解的是，在一次开机内，该App只需要触发一次密钥生成请求来执行图4b的流程，App后续每次需要进行数据加解密时，均无需在执行图4b的流程，只需要通过一段式函数调用，来触发执行图4c的流程来进行数据加解密即可。
在一段式函数调用的场景下，本申请实施例的HCE-REE引擎每次进行数据加解密都需要从例如DDR等共享内存中重新读取该App所传入的密文结构，并通过KM解密模块对该密文结构进行解密和认证后，才进行数据的加解密，可对App的身份进行认证，能够 防止其他应用盗用本App的工作密钥进行数据加解密。
考虑的芯片面积，在一段式函数调用的场景下，每次进行数据加解密是将key明文重新写入A类寄存器，因此，图4a中的A类寄存器的数量可以是1个，以缩小芯片面积。
需要说明的是，在一段式函数调用的场景下，图4a中DDR中的密文结构(示例性可包括IV、key密文、TAG、AAD)，在Linux内核的保护机制下，该密文结构只有该App可见，其他App并不可见，从而可以防止其他应用对本应用的数据进行加解密。
1-2、三段式函数调用场景。
在图5中，以App通过三段式函数调用为例，示例性地示出了一种多硬件密码引擎系统的密码使用过程的工作流程图。
图6和图7示出了三段式函数调用场景下多硬件密码引擎系统的密钥使用过程的时序图。
图5(1)和图6示出了三段式函数调用场景下的第一段函数调用的过程。
参照图4a和图4b的实施例的描述，App可通过触发密钥生成请求，来获取HCE-TEE引擎或inSE生成的该App的工作密钥的密文结构，App可基于图4b的流程所返回的密文结构，调用第一函数(例如CryptoInit())来传入密文结构至HCE-REE引擎，HCE-REE引擎可对密文结构解密，并将得到的工作密钥明文写入下A类寄存器中，并返回A类寄存器的句柄给App。其中，该句柄可用于标识写入有该工作密钥明文的A类寄存器。
如图5(1)和图6所示，对第一函数的处理过程可包括：
S301，App通过调用HUKS接口，触发第一函数请求。
示例性地，该第一函数请求可包括图4b中返回给App的密文结构。
App可将密文结构写入共享内存，并将该密文结构在共享内存的地址信息携带至该第一函数请求中。
示例性地，第一函数请求的函数接口可以是CryptoInit()。
示例性地，如图5(1)所示，App可将工作密钥的密文结构(例如包括IV、key密文、TAG、AAD参数)写入DDR。
S209，CA响应于第一函数请求，通过调用HCE-REE驱动，控制HCE-REE引擎读取密文结构。
S210，HCE-REE引擎从共享内存读取密文结构。
示例性地，如图5(1)所示，HCE-REE引擎中的KM解密模块可从DDR读取该应用的密文结构(例如包括IV、key密文、TAG、AAD参数)。
S211，HCE-REE引擎从AO寄存器读取根密钥，利用根密钥对密文结构解密，得到key明文。
示例性地，如图5(1)所示，HCE-REE引擎中的KM解密模块不仅可对key密文解密，得到key明文，还可进行鉴权。
关于鉴权的具体方案可参照上述一段式函数调用场景下图4c中S211的具体描述，这里不再赘述。
S302，HCE-REE引擎将key明文写入A类寄存器。
示例性地，如图5(1)所示，在KM解密模块对key密文解密成功以及鉴权成功后， 可将key明文写入上文所述的A类寄存器。
如图5(1)所示，这里的A类寄存器的数量为n个，包括Key slot 1～Key slot n，n为大于1的正整数，例如这里KM解密模块将key明文写入Key slot 1。
需要说明的是，HCE-REE引擎在执行S211和S302时，都是经CA对HCE-REE驱动控制，HCE-REE驱动再控制HCE-REE引擎实现的。
示例性地，HCE-REE驱动可响应于该第一函数请求，来从n个A类寄存器中，选择分配至该App的目标Key slot寄存器，以控制KM解密模块将该App的key明文写入目标Key slot寄存器，例如图5(1)中的Key slot 1。
另外，需要说明的是，每个A类寄存器可用于存储一个key明文。
HCE-REE驱动在对一个App的key明文分配A类寄存器时，可动态分配A类寄存器，例如将未存储有任何数据的空的A类寄存器作为分配对象，或者，还可按照应用来分配A类寄存器，例如每个应用可对应有唯一的一个A类寄存器，或者，还可按照应用的业务类型来分配A类寄存器，例如同一应用的不同业务类型的工作密钥不同，那么同一应用的不同业务的工作密钥可分别写入不同的A类寄存器。
S303，HCE-REE驱动可响应于第一函数请求，将A类寄存器的句柄信息，通过CA返回给App。
示例性地，图5(1)中的KM解密模块经HCE-REE驱动控制，将key明文写入Key slot1后，可返回信息通知HCE-REE驱动，数据写入寄存器成功。那么HCE-REE驱动可将用于标识HCE-REE引擎中Key slot 1的句柄(hand le)经由CA发送至App。
需要说明的是，A类寄存器的句柄可唯一地标识一个A类寄存器。
可选地，在一种实施方式中，该句柄可以是一定长度的随机数，该随机数可包括用于标识A类寄存器的标志位，以及数据位(其中，数据位是随机数据)。HCE-REE驱动在响应于App的数据加解密请求时，可通过该加解密请求中句柄的标志位，来确定A类寄存器。而通过设置句柄中的数据位可增强工作密钥的窃取难度。
可选地，在另一种实施方式中，该句柄可不包括上述标志位，可包括随机数。那么HCE-REE驱动可存储有A类寄存器的句柄与A类寄存器的标识信息的对应关系。以在工作密钥使用阶段，利用该对应关系，确定存储有key明文的A类寄存器。
另外，本申请对于HCE-REE驱动对A类寄存器的句柄的生成时机不做限制，可以在HCE-REE驱动响应于该第一函数请求，对App分配目标Key slot寄存器之后，生成该能够标识该目标Key slot寄存器的句柄，也可以在KM解密模块将key明文写入目标Key slot寄存器之后，生成能够标识该目标Key slot寄存器的句柄。
经过图5(1)和图6的过程，通过应用触发第一段函数的调用请求，可将应用的工作密钥配置于HCE-REE引擎的A类寄存器中，并将该A类寄存器的句柄返回给应用，以用于应用后续多次请求进行请求数据加解密。
图5(2)和图7示出了三段式函数调用场景下的第二段函数调用的过程。
在第二段函数调用的过程中，App可调用第二函数(例如CryptoUpdate())来传入A类寄存器的句柄以及待加解密数据至HCE-REE引擎，HCE-REE引擎可基于该句柄找到存储有该App的工作密钥明文的A类寄存器，并使用该A类寄存器内的工作密钥明文，来对 待加解密数据进行加解密操作，返回应用数据的加解密结构给App。
如图5(2)和图7所示，对第二函数的处理过程可包括：
S401，App通过调用HUKS接口，触发第二函数请求，并将第二函数请求发送至CA。
示例性地，在图6的S303之后，App可接收到用于标识Key slot 1的句柄信息，然后，App可根据业务需求而触发第二函数请求。
示例性地，第二函数请求可包括但不限于：待加密数据(例如图5(2)的数据明文)的源地址，用于标识Key slot 1的Key slot的句柄信息。
S402，CA可响应于第二函数请求，通过调用HCE-REE驱动，以控制HCE-REE引擎读取App的数据明文(即待加密数据)。
S208，HCE-REE引擎从共享内存读取数据明文。
示例性地，第二函数请求中可携带数据明文的地址信息(又称源地址)，处于REE环境中的上述App可将数据明文写入共享内存，并将数据明文在共享内存中的地址(即源地址)携带至第二函数请求中，以使图5(2)的HCE-REE引擎中的数据加解密模块可受HCE-REE驱动控制，从该源地址读取数据明文。
S403，CA还可响应于第二函数请求，控制HCE-REE驱动依据句柄信息确定目标寄存器。
示例性地，第二函数请求中携带了用于标识A类寄存器Key slot 1的句柄，例如该句柄包括标志位和数据位，那么HCE-REE驱动可依据句柄中的标志位，来确定目标寄存器为A类寄存器key slot 1，从而控制HCE-REE引擎执行S404。
S404，HCE-REE引擎可从目标寄存器读取key明文。
示例性地，如图5(2)所示，HCE-REE引擎中的数据加解密模块，可经HCE-REE驱动控制，得到App传入的Key slot的句柄，从而依据该Key slot的句柄，来从Key slot 1中读取key明文。
S212，HCE-REE引擎利用key明文，对数据明文加密，得到数据密文。
示例性地，如图5(2)所示，HCE-REE引擎中的数据加解密模块可使用key明文，来对App的数据明文加密，得到数据密文。其中，加密算法可以包括但不限于AES、SM4等。
S213，HCE-REE引擎写入数据密文至共享内存。
示例性地，S401中App触发的第二函数请求还可包括用于用于写入数据密文的目标地址。
HCE-REE引擎可响应于该第二函数请求，将数据密文写入共享内存中的该目标地址。
需要说明的是，HCE-REE引擎在执行S404、S212、S213各步骤时，也可由CA响应于第二函数请求通过调用HCE-REE驱动，来控制HCE-REE引擎执行。
S214，App直接从共享内存读取数据密文。
示例性的，由于该目标地址由App设置，那么App可不经由本申请实施例的密码服务，直接从该目标地址读取数据密文。
可选地，如图5(2)所示，数据加解密模块可包括m个数据加解密模块，m为大于1的正整数。其中，m与n可以相同或不同，本申请对此不做限制。m个数据加解密模块的 功能相同，所使用的算法(包括但不限于AES、SM4)可以不同。
示例性地，m个数据加解密模块可包括使用AES算法的m1个数据加解密模块，以及使用SM4的m2个数据加解密模块，其中，m＝m1+m2，这样，HCE-REE引擎可支持国密和国际双算法体系的切换。
那么在HCE-REE引擎同时执行多个数据加解密任务时，可由m个数据加解密模块并行操作来执行应用数据的多个加解密任务，以支持使用多种工作密钥进行数据加解密。示例性的，并行执行的多个加解密任务可涉及不同应用，或同一应用的不同业务等。HCE-REE引擎能够以多个数据加解密模块的多核方式来提升数据加解密性能。此外，HCE-REE引擎中通过设置多个A类寄存器，那么m个数据加解密模块中的任意一个数据加解密模块在切换加解密任务时，则需要切换所使用的key明文，那么只需要通过对数据加解密模块所读取的A类寄存器的标识(例如index)进行切换即可，能够以多A类寄存器的方式，来减少数据加解密模块的密钥切换开销。
在上述图5(2)和图7的实施例中，描述了使用工作密钥进行数据加解密的过程，App可多次触发第二函数请求，以实现对应用数据的多次加解密操作。
对于三段式函数调用场景下的第三段函数调用的过程，未在附图中示出。
在执行图7的流程之后，待App本次不再需要进行数据加解密时，可通过调用HUKS接口，触发第三函数请求(例如CryptoFinal())，第三函数请求中可携带用于标识A类寄存器Key slot 1的句柄，以使HCE-REE引擎来清除句柄所指向的A类寄存器，即图5(2)中的Key slot 1中的数据，以释放一个A类寄存器资源。
在上述图5～图7的实施例中，描述了App通过三段式函数调用，来实现对应用数据进行加密的过程。
在上述实施例中，通过应用触发第一段函数调用请求，可将应用的工作密钥配置于HCE-REE引擎的A类寄存器中，并将标识该A类寄存器的句柄返回给应用。那么在终端设备未重启的情况下，应用在需要多次进行数据加解密时，应用可通过多次触发第二段函数的调用请求，并将该句柄携带至该第二段函数调用请求中，以使HCE-REE引擎使用该句柄标识的A类寄存器内的key明文，来用于应用数据的加解密。相较于一段式函数调用的场景，在分段式函数调用的场景下，HCE-REE引擎每次进行应用数据的加解密时，不需要每次从共享内存读取用于标识该应用和工作密钥的密文结构，也不需要每次对该密文结构进行认证和解密，从而可大幅提升HCE-REE引擎的数据加解密性能。
在上述实施例的密钥生成场景中，若使用inSE生成应用的工作密钥，由于inSE具有独立的片上CPU，则可做到工作密钥明文(即key明文)全程不出硬件，key明文对ACPU不可见，可达到纯硬件隔离级别，能够提升工作密钥的安全性。
在上述实施例的密钥生成场景中，若使用HCE-TEE引擎生成应用的工作密钥，可在生成工作密钥明文的短暂时间窗内，出现工作密钥明文进入TEE内存的情况，但可做到工作密钥明文全程不出TEE，可达到TEE安全级别。
密钥导入场景。
2-1、密钥无封装导入HCE-TEE引擎或inSE的场景
该密钥无封装导入HCE-TEE引擎或inSE的场景，用于表达应用的工作密钥以明文的 方式，由应用导入至HCE-TEE引擎或inSE。
可以理解的是，密钥无封装导入HCE-TEE引擎或inSE的场景下，同样适用于上述实施例所述的HCE-TEE引擎或inSE对得到的应用的工作密钥明文进行加密，以得到密文结构返回给App的过程，以及App通过一段式或三段式调用，来使HCE-REE引擎通过密文结构来对应用数据进行加解密的过程，原理相同，这里不再赘述。
图8示例性示出了一种在密钥无封装导入场景下的多硬件密码引擎系统的工作流程图。
在图8中，描述了在密钥无封装导入的场景下，HCE-TEE引擎或inSE对应用导入的工作密钥进行加密的过程，以及通过App的一段式函数调用，来使HCE-REE引擎利用加密后的工作密钥进行应用数据加解密的过程。
对比图4a和图8可知，密钥无封装导入至HCE-TEE引擎或inSE引擎的场景，与密钥生成场景之间，多硬件密码引擎系统的执行过程基本一致，区别可在于：在密钥生成场景中，应用的工作密钥明文(即key明文)由HCE-TEE引擎或inSE内的TRNG生成。在密钥无封装导入至HCE-TEE引擎或inSE引擎的场景中，应用的key明文并非由HCE-TEE引擎或inSE内的TRNG生成，而是由App间接导入至HCE-TEE引擎或inSE的。关于图8的具体过程可参照图4a的详细描述，这里不再赘述。
示例性地，App在导入key明文至HCE-TEE引擎时，结合图2和图8可以看到，App可通过调用HUKS接口以调用CA，CA再调用TA，TA通过调用HCE-TEE驱动，将App传入的key明文写入HCE-TEE引擎。
示例性地，App在导入key明文至inSE时，结合图2和图8可以看到，App可通过调用HUKS接口以调用CA，CA再调用SA，SA通过调用SEE OS，将App传入的key明文写入inSE。
示例性地，在图4b中，示例性地示出了一种在密钥生成场景下的密钥加密过程的时序图。
那么在本申请实施例所述的密钥无封装导入HCE-TEE引擎的场景下，多硬件密码引擎系统可基于图4b所描述的时序图来对导入的工作密钥进行加密。
需要注意的是，在将图4b结合到本实施例的场景下，在图4b的S201中，App通过调用HUKS接口，触发密钥导入请求，该密钥导入请求，相比于密钥生成请求中的参数，还可进一步包括key明文。此外，在将图4b结合到本实施例的场景下，在图4b的S203、S204中，TA只需要通过HCE-TEE驱动控制HCE-TEE引擎，对密钥导入请求中传入的key明文加密即可，无需控制HCE-TEE引擎生成工作密钥。
在上述图4b的实施例所描述的内容中，除这里提及的上述区别之处，均可应用到本申请实施例所述的密钥无封装导入HCE-TEE引擎的场景中。
在图4c中，以App通过一段式函数调用为例，示例性地示出了一种多硬件密码引擎系统的密钥使用过程的时序图。
示例性地，在本申请实施例所述的密钥无封装导入HCE-TEE引擎的场景下，多硬件密码引擎系统可基于图4c所描述的时序图来进行应用数据的加密，多硬件密码引擎的具体工作流程可参考关于图4c的描述，这里不再赘述。
在密钥无封装导入HCE-TEE引擎或inSE的场景中，HCE-TEE引擎或inSE可对应用导入的密钥明文进行加密，并将生成的密文结构返回给App。当App需要对应用数据加解密时，可触发一次函数调用来利用HCE-REE引擎进行应用数据加解密。在终端设备的一次开机内(未重启)，App的工作密钥可不变，那么在App触发密钥导入请求后，本系统可将生成的密文结构返回给App。那么在App通过一段式函数调用请求来触发数据加解密时，App可使用和该App及其工作密钥绑定的密文结构，来通过CA和HCE-REE驱动操作HCE-REE引擎进行数据加解密，使得数据加解密不需要切换到TEE或SEE，能够在REE环境下利用该密文结构来对数据进行加解密，有效减少通路性能损耗，提升数据加解密性能。
而且，HCE-REE引擎在使用应用的密文结构来对数据加解密时，可在HCE-REE引擎内对密文结构进行认证和解密，并使用认证和解密后的工作密钥来在HCE-REE引擎内进行数据加解密，使工作密钥在使用过程中可达到硬件级别安全，且工作密钥的使用过程仅在REE中完成，不需要切换到TEE或SEE，不影响加解密性能。
考虑的芯片面积，在一段式函数调用的场景下，每次进行数据加解密是将key明文重新写入A类寄存器，因此，图8中的A类寄存器的数量可以是1个，以所缩小芯片面积。
需要说明的是，在一段式函数调用的场景下，图8中DDR中的密文结构(示例性可包括IV、key密文、TAG、AAD)，在Linux内核的保护机制下，该密文结构只有该App可见，其他App并不可见，从而可以防止其他应用对本应用的数据进行加解密。
另外，在密钥无封装导入HCE-TEE引擎或inSE的场景下，多硬件密码引擎系统将生成的密文结构返回给App后，App还可以通过三段式函数调用的方式，来使HCE-REE引擎利用该密文结构对应用数据进行加解密操作，具体过程可参照图4c，以及图6和图7的实施例的描述，这里不再赘述。
在上述实施例的密钥无封装导入inSE的场景中，若应用将无封装的工作密钥明文导入至inSE，由于inSE具有独立的片上CPU，则可做到工作密钥明文(即key明文)全程不出硬件，key明文对ACPU不可见，可达到纯硬件隔离级别，能够提升工作密钥的安全性。
在上述实施例的密钥无封装导入HCE-TEE引擎的场景中，若应用将无封装的工作密钥明文导入至HCE-TEE引擎，可在应用将工作密钥明文导入至HCE-TEE引擎的短暂时间窗内，出现工作密钥明文进入TEE内存的情况，但可做到工作密钥明文全程不出TEE，可达到TEE安全级别。
2-2密钥有封装导入HCE-TEE引擎或inSE的场景
该密钥有封装导入HCE-TEE引擎或inSE的场景，用于表达应用的工作密钥以密文的方式，由应用导入至HCE-TEE引擎或inSE。
可以理解的是，密钥有封装导入HCE-TEE引擎或inSE的场景下，同样适用于上述实施例所述的HCE-TEE引擎或inSE对得到的应用的工作密钥明文进行加密，以得到密文结构返回给App的过程，以及App通过一段式或三段式调用，来使HCE-REE引擎通过密文结构来对应用数据进行加解密的过程，原理相同，这里不再赘述。
图9示例性示出了一种在密钥有封装导入场景下多硬件密码引擎系统的工作密钥明文导入过程的工作流程图。
在终端设备开机启动BootLoader阶段，HCE-TEE引擎或inSE中的TRNG可生成根密钥，并硬线写入至AO寄存器，该步骤为先导步骤，因此，未在图9中示出，另外，该步骤可由软件控制或者终端设备开机启动BootLoader阶段，HCE-TEE引擎或inSE中的TRNG自动执行上述过程。
在图9实施例中，应用(例如App1)是一款需要与云端配合使用的应用程序，因此，由云端发送应用的工作密钥密文至inSE。
请参照图9(1)，示例性地示出了一种在密钥对称封装导入场景下的执行过程。
SE(包括片上inSE和外置eSE)，可达到智能卡安全级别认证(如CC EAL4+/5+)，能够满足StrongBox安全级别。SE中有独立CPU和安全OS，其上可运行多种应用程序(Applet)，安全性和灵活性都更高，可用于特定政企客户的定制应用场景。
以inSE为例进行说明：
inSE中的KM密钥派生模块可接收硬件根密钥和软件提供的派生分量；
示例性地，硬件根密钥可配置在inSE中，例如配置于inSE中的某个硬件组件中。
示例性地，硬件根密钥是inSE的硬件密钥，可以是HUK(Hardware Unique Key，硬件唯一密钥，一机一密)，或者HGK(Hardware Global Key，硬件公共密钥，即多硬件密码引擎均可使用的硬件密钥)。
派生分量可配置于SA中，由SA输入至KM密钥派生模块。
示例性的，配置于SA中的派生分量可在系统出厂前，由第三方密钥管理中心(例如PKI(公钥基础设施)提供。
示例性的，对于不同应用，PKI可提供相同或不同的派生分量，本申请对此不做限制。
由于PKI是密钥管理中心，对于配置与inSE中的硬件根密钥，PKI中也存储有该硬件根密钥，那么PKI可利用与图9(1)中相同的派生分量和该inSE中的上述硬件根密钥，来派生得到端云共享根密钥，并将该端云共享根密钥离线分发给App1的云端。
另外，SA可控制配置有硬件根密钥的inSE中的组件，将硬件根密钥传入KM密钥派生模块。
KM密钥派生模块，可基于eFuse(或OTP)，按照派生分量对硬件根密钥进行派生，得到端云共享根密钥。其中，派生算法和密钥层级可由SA灵活开发定制。
这里KM密钥派生模块所生成的App1的端云共享根密钥，与PKI所生成的分发给App1的云端的端云共享根密钥相同。
示例性地，对HUK进行派生，得到SUK；对HGK进行派生，得到SGK。
另外，KM密钥派生模块与图9(2)中的KM加密模块可以是一个模块，也可以是两个独立的模块，本申请对此不做限制。
App1的云端可导入使用上述端云共享根密钥封装的key密文至inSE。
具体的，inSE上运行的SA可收到来自云端的应用的工作密钥密文(即图9(1)中的key密文)，SA可将该key密文导入inSE。
示例性地，基于图2所示的架构，云端可通过HUKS接口调用CA，由CA调用SA，SA 通过SEE OS来将云端传入的应用的工作密钥密文(即图9(1)中的key密文)传入至inSE。
后文所述的云端与inSE的数据交互，也是图2所示的软件控制流程来实现，后文不再一一赘述。
本示例中，应用需要与云端配合使用，因此，由云端发送应用的工作密钥密文。
其中，云端采用上述派生得到的端云共享根密钥，对应用的工作密钥明文进行加密，得到上述工作密钥密文(即图9(1)中的key密文)。
KM解密模块可使用端云共享根密钥，来对key密文解密，得到App的key明文。
关于inSE对key明文进行加密，并将key明文的密文结构返回给App；以及App通过一段式函数调用或三段式函数调用，来使HCE-REE引擎基于该密文结构对App的应用数据进行加解密的过程，参照上述实施例的描述即可，这里不再赘述。
示例性地，云端可将待解密的视频数据传入手机，手机中安装的与该云端配套使用App，可通过HUKS接口调用CA，CA可通过HCE-REE驱动控制HCE-REE引擎，来使用从共享内存获取并解密后的key明文，来对视频数据解密，得到明文视频，HCE-REE引擎将明文数据通过共享内存返回给App，用户可在App中浏览云端下发的视频数据。
在本实施例中，区分UK和GK两种密钥可满足不同业务需求，在有些应用场景下，可能需要规模广播式分发相同工作密钥，有些场景下可能需要更多的密钥派生层级，SA可根据客户需求进行灵活开发定制。
请参照图9(2)，示例性地示出了一种在密钥非对称封装导入场景下的执行过程。
以inSE为例进行说明：
在终端设备第一次开机或该业务第一次启用时，inSE的TRNG可生成一对非对称密钥：公钥明文KPub和私钥明文Kpriv；
SA控制将TRNG生成的Kpriv传入KM加密模块，SA控制KM加密模块使用TRNG生成的工作密钥明文的根密钥，来对Kpriv加密，将加密后的结果，例如私钥密文写入NVM安全存储区，或者DDR；以及SA控制将TRNG生成的KPub通过安全传输发送至云端；
示例性的，SA在将KPub通过安全传输发送至云端时，可基于图2所示的架构，SA将inSE生成的KPub发送至CA，CA再将KPub发送至云端，这个过程中不经过共享内存。
云端在存储有KPub之后，可导入使用KPub封装的App1的工作密钥密文。
如图9(2)所示，云端可发送key密文至inSE，具体过程为：云端通过调用HUKS接口，将key密文发送至CA，CA调用SA，将key密文发送至inSE。
其中，云端使用公钥明文KPub对App1(和云端配套使用的App1)的工作密钥明文加密，得到key密文
在inSE接收到来自云端的key密文后，SA可控制KM解密模块从NVM安全存储区读回私钥密文，即Kpriv的密文；
KM解密模块，可从AO寄存器读取工作密钥的根密钥，并使用该根密钥来对私钥密文解密，得到私钥明文Kpriv；
SA控制PKE(Public Key Equiption)解密模块，使用私钥明文Kpriv对云端传入的key密文进行解密，得到App的key明文。
在图9(2)中，KM加密模块和KM解密模块可使用例如GCM的认证加密算法来对密钥进行加解密，可对密钥进行认证。
基于按照图9所示出的流程，在HCE-TEE引擎或inSE将应用的工作密钥密文(即key密文)解密，得到key明文后，HCE-TEE引擎或inSE可对key明文进行加密，并将key明文的密文结构返回给App；以及App通过一段式函数调用或三段式函数调用，来使HCE-REE引擎基于该密文结构对App的应用数据进行加解密的过程，参照上述实施例的描述即可，这里不再赘述。
在本申请实施例中，多硬件密码引擎系统可支持密钥有封装的导入，在有封装的密钥导入至inSE的场景下，可做到应用的工作密钥明文全程不出硬件，达到硬件级别安全。
上文以将有封装的密钥导入inSE为例进行说明，但是在将有封装的密钥导入HCE-TEE引擎时，方法类似，这里不再赘述。
需要说明的是，考虑到HCE-TEE引擎运行在ACPU之上，而inSE运行在不与ACPU共享的独立CPU之上，那么为了图9(2)中公钥明文的安全，可将密钥有封装导入的场景应用到inSE来实现，以避免应用到HCE-TEE引擎中来实现时，公钥明文被恶意应用窃取的风险。
另外，在密钥有封装导入HCE-TEE引擎或inSE的场景下，多硬件密码引擎系统对应用的工作密钥明文，即key明文进行加密，生成密文结构，并将密文结构返回给App的过程。以及App通过一段式函数调用，或三段式函数调用的方式，来使HCE-REE引擎利用该密文结构对应用数据进行加解密操作的过程，可参照上述实施例的一段式函数调用和三段式函数调用的具体实施例的描述，这里不再赘述。
2-3、密钥无封装导入HCE-REE引擎的场景
该密钥无封装导入HCE-REE引擎的场景，用于表达应用的工作密钥以明文的方式，由应用导入至HCE-REE引擎。
如图3所示，HCE-TEE引擎中配置了用于设置应用传入的工作密钥明文的B类寄存器，通过设置B类寄存器，可保留多硬件密码引擎系统利用应用传入的工作密钥明文，直接在REE环境下进行数据加解密的通道，无需切换运行环境至TEE或SEE，可提升数据加解密性能。
2-3-1、HCE-REE引擎中B类寄存器的数量为一个
图10示例性地示出了一种在密钥无封装导入HCE-REE引擎的场景下多硬件密码引擎系统的工作流程图。
在HCE-REE引擎中的B类寄存器的数量为一个的情况下，如图10所示，B类寄存器为Key slot 0，那么可不区分一段式函数调用和三段式函数调用的不同场景，下面结合图2、图3来对图10的过程进行描述：
首先，App可调用HUKS接口，来触发数据加解密请求，该数据加解密请求可包括key明文以及待加解密的数据，例如数据明文。
示例性地，App可将key明文和数据明文写入共享内存，并将key明文和数据明文的地址信息携带在数据加解密请求中。
然后，CA可响应于该数据加解密请求，调用HCE-REE驱动，控制HCE-REE引擎，从 共享内存读取key明文，并写入Key slot 0；然后，HCE-REE引擎使用数据加解密模块从共享内存读取数据明文，并使用key明文进行加密，得到数据密文，以返回给App。
其中，HCE-REE引擎进行数据加解密的详细流程与上述实施例的流程类似，这里不再赘述。
2-3-2、HCE-REE引擎中B类寄存器的数量为多个
图11示例性地示出了一种在密钥无封装导入HCE-REE引擎的场景下多硬件密码引擎系统的工作流程图。
在HCE-REE引擎中的B类寄存器的数量为多个的情况下，如图11所示，HCE-REE引擎可包括k个B类寄存器，分别为Key slot 1～Key slot k，其中，k为大于1的正整数。
在分段式函数调用的场景下，结合图2、图3来对图11的过程进行描述：
请参照图11(1)：
首先，App可调用HUKS接口，来触发密钥导入请求，该密钥导入请求可包括key明文。
示例性地，App可将key明文写入共享内存，并将key明文的地址信息携带在密钥导入请求中。
然后，CA可响应于该密钥导入请求，调用HCE-REE驱动，控制HCE-REE引擎，从共享内存读取key明文，并写入空闲的B类寄存器，例如Key slot 1中。
其中，HCE-REE驱动可根据业务需求、应用ID(例如包名)等方式来确定k个B类寄存器中，用于存储该App的key明文的寄存器，具体方案可参照上文实施例，这里不再赘述。
然后，HCE-REE驱动响应于该密钥导入请求，将HCE-REE引擎中用于标识B类寄存器(这里为Key slot 1)的句柄，通过CA返回给App。
请参照图11(2)：
App在接收到用于标识标识B类寄存器(这里为Key slot 1)的句柄之后，根据业务需求调用HUKS接口，触发数据加解密请求，该数据加解密请求可携带用于标识标识B类寄存器(这里为Key slot 1)的句柄、待加解密数据(例如数据明文)；
示例性地，App可将用于标识标识B类寄存器(这里为Key slot 1)的句柄和数据明文写入共享内存，并将用于标识标识B类寄存器(这里为Key slot 1)的句柄的地址信息、数据明文的地址信息携带在数据加解密请求中。
然后，CA可响应于该数据加解密请求，调用HCE-REE驱动，控制HCE-REE引擎，从共享内存读取key明文，以及用于标识标识B类寄存器(这里为Key slot 1)的句柄；然后，HCE-REE引擎的数据加解密模块从共享内存读取数据明文，以及依据用于标识标识B类寄存器(这里为Key slot 1)的句柄，从B类寄存器Key slot 1中读取key明文，并使用key明文来对数据明文加密，生成数据密文，以返回给App。
其中，HCE-REE引擎进行数据加解密的详细流程与上述实施例描述的数据加解密流程类似，这里不再赘述。
在HCE-REE引擎中的B类寄存器的数量为多个，且一段式函数调用的场景下，App 每次触发数据加解密请求均需要携带待加解密的数据以及key明文，HCE-REE引擎的工作流程与图10的方案类似，这里不再赘述。
在密钥无封装导入HCE-REE引擎的场景中，考虑到应用的工作密钥是应用以明文的方式导入到HCE-REE引擎的，应用本身并不关心工作密钥的安全性，那么可在对密钥安全性较低的场景下，使用HCE-REE引擎来对数据进行加解密，以提升数据加解密性能。
在一种可能的实现方式中，本申请实施例的系统中的多硬件密码引擎可包括HCE-REE引擎和HCE-TEE引擎，由HCE-TEE引擎实现对工作密钥的加密，由HCE-REE引擎对工作密钥解密，并使用解密后的工作密钥进行数据加解密，可提升数据加解密性能。
在一种可能的实现方式中，本申请实施例的系统中的多硬件密码引擎可包括HCE-REE引擎和inSE由inSE实现对工作密钥的加密，由HCE-REE引擎对工作密钥解密，并使用解密后的工作密钥进行数据加解密，工作密钥的安全度更高。
在一种可能的实现方式中，本申请实施例的系统中的多硬件密码引擎可包括HCE-REE引擎、HCE-TEE引擎以及inSE，由inSE生成AO寄存器中的根密钥，并使用根密钥对工作密钥进行加密，可提升密钥安全性；HCE-REE引擎、HCE-TEE引擎的功能类似，可使用根密钥对工作密钥密文解密，并使用解密后的工作密钥进行数据加解密。
其中，数据加解密工作主要由HCE-REE引擎实现，可在HCE-REE引擎忙碌，或者，HCE-REE引擎内配置的加解密算法，与本次应用数据的加解密所需要使用的加解密算法算法不同时，由HCE-TEE引擎使用根密钥对工作密钥密文解密，并使用解密后的工作密钥进行数据加解密。
示例性地，考虑到HCE-REE引擎内配置的数据加解密算法不一定能够支持所有上层应用的数据加解密需求，因此，可在HCE-REE引擎内配置的数据加解密算法不支持本次数据加解密的情况下，由HCE-TEE引擎使用内部配置的、且能够支持应用的本次数据加解密的加解密算法，来对应用数据进行加解密操作，以提升数据加解密可靠性。
其中，虽然AO寄存器中的根密钥由inSE配置，但是，HCE-REE引擎、HCE-TEE引擎均可从AO寄存器读取根密钥来进行工作密钥密文的解密，以用于数据加解密。
在本申请上述各个实施例中，SoC内部的安全子系统可包括HCE-REE引擎、HCE-TEE引擎和inSE等多硬件密码引擎，HCE-REE引擎可使用引擎内的密钥来对数据进行加解密，无需切换运行环境，数据加解密性能更高；inSE内含独立CPU，在用于工作密钥导入/生成，以及工作密钥的加密时，工作密钥明文可达到硬件级别安全，安全性更高。且inSE可编程，可灵活定制。但inSE运行在SEE环境下，在将工作密钥传递至HCE-REE引擎时，需要切换CPU和运行环境，性能较差。HCE-TEE引擎可运行在ACPU之上，那么在使用HCE-TEE引擎进行工作密钥导入/生成，以及工作密钥的加密时，无需切换运行环境，安全性和性能介于HCE-REE引擎和inSE之间，均衡安全的优点更加突出。本申请实施例可通过密码服务组件CA/TA/SA的有效配合，来实现多硬件密码引擎之间的分工协同工作，能够支持安全密钥导入、生成以及数据加解密等多种场景。
在本申请的上述各个实施例中，以inSE为例，来说明多硬件密码引擎中具有独立CPU和安全OS的硬件安全模块(SE)，但是，多硬件密码引擎中的SE并不限于位于SoC内部的inSE，还可以扩展为独立的外置SE芯片，即eSE。
另外，本申请对于SoC内的硬件密码引擎的数量和组合方式不做限制，例如图1的安全子系统中可包括多个REE硬件密码引擎、多个TEE硬件密码引擎、多个inSE、多个eSE，以及未列举的更多硬件密码引擎之间的多种组合。
下面介绍本申请实施例提供的一种装置。如图12所示：
图12为本申请实施例提供的一种数据处理装置的结构示意图。如图12所示，该数据处理装置500可包括：上述HCE-TEE引擎、HCE-REE引擎、处理器501、收发器505，可选的还包括存储器502，可选地，该数据处理装置还包括SE。
可选地，该数据处理装置还包括AO寄存器，AO寄存器与HCE-TEE引擎、HCE-REE引擎以及SE分别硬线连接。
所述收发器505可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器505可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
存储器502中可存储计算机程序或软件代码或指令504，该计算机程序或软件代码或指令504还可称为固件。处理器501可通过运行其中的计算机程序或软件代码或指令503，或通过调用存储器502中存储的计算机程序或软件代码或指令504，对MAC层和PHY层进行控制，以实现本申请各实施例提供的通信方法。其中，处理器501可以为中央处理器(central processing unit，CPU)，存储器502例如可以为只读存储器(read-only memory，ROM)，或为随机存取存储器(random access memory，RAM)。
本申请中描述的处理器501和收发器505可实现在集成电路(integrated circuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(application specific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。
上述数据处理装置500还可以包括天线506，该数据处理装置500所包括的各模块仅为示例说明，本申请不对此进行限制。
数据处理装置的结构可以不受图12的限制。数据处理装置可以是独立的设备或者可以是较大设备的一部分。例如所述数据处理装置的实现形式可以是：
(1)独立的集成电路IC，或芯片，或，芯片系统或子系统；(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，指令的存储部件；(3)可嵌入在其他设备内的模块；(4)车载设备等等；(5)其他等等。
对于数据处理装置的实现形式是芯片或芯片系统的情况，可参见图13所示的芯片的结构示意图。图13所示的芯片包括处理器601和接口602。其中，处理器601的数量可以是一个或多个，接口602的数量可以是多个。可选的，该芯片或芯片系统可以包括存储器603。
其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
基于相同的技术构思，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序包含至少一段代码，该至少一段代码可由计算机执行，以控制计算机用以实现上述方法实施例。
基于相同的技术构思，本申请实施例还提供一种计算机程序，当该计算机程序被终端设备执行时，用以实现上述方法实施例。
所述程序可以全部或者部分存储在与处理器封装在一起的存储介质上，也可以部分或者全部存储在不与处理器封装在一起的存储器上。
基于相同的技术构思，本申请实施例还提供一种芯片，包括网口控制器与处理器。网口控制器与处理器可实现上述方法实施例。
结合本申请实施例公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(Random Access Memory，RAM)、闪存、只读存储器(Read Only Memory，ROM)、可擦除可编程只读存储器(Erasable Programmable ROM，EPROM)、电可擦可编程只读存储器(Electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (22)

  1. 一种数据处理系统，其特征在于，包括多个硬件引擎、第一存储单元以及常开不掉电AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在可信执行环境TEE或安全执行环境SEE中，所述第二硬件引擎运行在富执行环境REE中；
    所述第一硬件引擎，用于：
    从所述第二存储单元读取第一根密钥；
    基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文；
    将所述第一密钥密文写入第一存储单元；
    所述第二硬件引擎，用于：
    从所述第二存储单元读取所述第一根密钥；
    从所述第一存储单元读取所述第一密钥密文；
    基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；
    基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据；
    所述第二存储单元，用于存储第一根密钥，以及用于仅在所述数据处理系统初始化时被写入一次所述第一根密钥。
  2. 根据权利要求1所述的系统，其特征在于，所述第二存储单元，具体用于仅在所述数据处理系统上电时被写入所述第一根密钥。
  3. 根据权利要求1或2所述的系统，其特征在于，所述第一硬件引擎包括第一真随机数生成模块；
    所述第一真随机数生成模块，用于在所述数据处理系统初始化时生成第一真随机数，并将所述第一真随机数作为所述第一根密钥。
  4. 根据权利要求1或2所述的系统，其特征在于，所述第一硬件引擎，还用于：
    按照第一变量和第二根密钥，生成所述第一根密钥，所述第二根密钥为预设密钥；
    将所述第一根密钥写入所述第二存储单元。
  5. 根据权利要求1至4中任意一项所述的系统，其特征在于，所述第一硬件引擎运行在所述SEE中，所述多个硬件引擎还包括第三硬件引擎，所述第三硬件引擎运行在所述TEE中；
    所述第三硬件引擎，用于：
    从所述第二存储单元读取所述第一根密钥；
    基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；
    基于所述第一密钥明文，对第三数据进行加密或解密，生成第四数据。
  6. 根据权利要求1至5中任意一项所述的系统，其特征在于，所述第二硬件引擎还包括第一寄存器，其中，所述第一寄存器为软件不可读、软件不可写；
    所述第一寄存器，用于存储所述第一密钥明文，其中，所述第一密钥明文用于对应用的数据进行加密或解密，其中，所述应用的数据包括所述第一数据。
  7. 根据权利要求1至6中任意一项所述的系统，其特征在于，
    所述第一硬件引擎，具体用于：
    基于密钥参数和所述第一根密钥，对所述第一密钥明文进行加密，生成第一密文数据；
    根据所述第一密文数据，获取校验数据；
    其中，所述第一密钥密文包括所述密钥参数、所述第一密文数据以及所述校验数据；
    所述第二硬件引擎，具体用于：
    基于所述第一密钥密文中的所述校验数据，对所述第一密文数据进行校验认证；
    在校验认证通过的情况下，基于所述密钥参数和所述第一根密钥，对所述第一密文数据进行解密，获取所述第一密钥明文，其中，所述第一密钥明文用于对所述第一数据进行加密或解密。
  8. 根据权利要求1至7中任意一项所述的系统，其特征在于，所述数据处理系统还包括第一软件程序、第二软件程序，所述第二软件程序具有第一接口，第一应用运行在所述REE中；
    所述第一软件程序，用于控制所述第一硬件引擎进行运算和读写操作；
    所述第二软件程序，用于：
    控制所述第二硬件引擎进行运算和读写操作；
    通过所述第一接口与所述第一应用通信；
    调用所述第一软件程序。
  9. 根据权利要求1至8任一项所述的系统，其特征在于，所述系统集成在片上系统SoC中。
  10. 一种数据处理方法，其特征在于，应用于数据处理系统，所述数据处理系统包括包括多个硬件引擎、第一存储单元以及常开不掉电AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在可信执行环境TEE或安全执行环境SEE中，所述第二硬件引擎运行在富执行环境REE中，所述方法包括：
    所述第一硬件引擎从所述第二存储单元读取第一根密钥；
    所述第一硬件引擎基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文；
    所述第一硬件引擎将所述第一密钥密文写入第一存储单元；
    所述第二硬件引擎从所述第二存储单元读取所述第一根密钥；
    所述第二硬件引擎从所述第一存储单元读取所述第一密钥密文；
    所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；
    所述第二硬件引擎基于所述第一密钥明文，对第一数据进行加密或解密，生成第二数据；
    其中，所述第二存储单元，用于存储第一根密钥，以及用于仅在所述数据处理系统初始化时被写入一次所述第一根密钥。
  11. 根据权利要求10所述的方法，其特征在于，所述第二存储单元，具体用于仅在所述数据处理系统上电时被写入所述第一根密钥。
  12. 根据权利要求10或11所述的方法，其特征在于，所述第一硬件引擎从所述第二存储单元读取第一根密钥之前，所述方法还包括：
    所述第一硬件引擎在所述数据处理系统初始化时生成第一真随机数，并将所述第一真随机数作为所述第一根密钥，以及将所述第一根密钥写入所述第二存储单元。
  13. 根据权利要求10或11所述的方法，其特征在于，所述第一硬件引擎从所述第二存储单元读取第一根密钥之前，所述方法还包括：
    所述第一硬件引擎按照第一变量和第二根密钥，生成所述第一根密钥，以及将所述第一根密钥写入所述第二存储单元，其中，所述第二根密钥为预设密钥。
  14. 根据权利要求10至13中任意一项所述的方法，其特征在于，所述第一硬件引擎运行在所述SEE中，所述多个硬件引擎还包括第三硬件引擎，所述第三硬件引擎运行在所述TEE中；
    所述第一硬件引擎将所述第一密钥密文写入第一存储单元之后，所述方法还包括：
    所述第三硬件引擎从所述第二存储单元读取所述第一根密钥；
    所述第三硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文；
    所述第三硬件引擎基于所述第一密钥明文，对第三数据进行加密或解密，生成第四数据。
  15. 根据权利要求10至14中任意一项所述的方法，其特征在于，所述第二硬件引擎还包括第一寄存器，其中，所述第一寄存器为软件不可读、软件不可写；
    所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文之后，所述方法还包括：
    所述第二硬件引擎将所述第一密钥明文写入所述第一寄存器。
  16. 根据权利要求10至15中任意一项所述的方法，其特征在于，
    所述第一硬件引擎基于所述第一根密钥，对第一密钥明文进行加密，生成第一密钥密文，包括：
    所述第一硬件引擎基于密钥参数和所述第一根密钥，对所述第一密钥明文进行加密，生成第一密文数据，以及根据所述第一密文数据，获取校验数据；其中，所述第一密钥密文包括所述密钥参数、所述第一密文数据以及所述校验数据；
    所述第二硬件引擎基于所述第一根密钥，对所述第一密钥密文进行解密，生成所述第一密钥明文，包括：
    所述第二硬件引擎基于所述第一密钥密文中的所述校验数据，对所述第一密文数据进行校验认证，在校验认证通过的情况下，所述第二硬件引擎基于所述密钥参数和所述第一根密钥，对所述第一密文数据进行解密，获取所述第一密钥明文，其中，所述第一密钥明文用于对所述第一数据进行加密或解密。
  17. 根据权利要求10至16中任意一项所述的方法，其特征在于，所述数据处理系统还包括第一软件程序、第二软件程序，所述第二软件程序具有第一接口，第一应用运行在所述REE中，所述方法还包括：
    所述第一软件程序控制所述第一硬件引擎进行运算和读写操作；
    所述第二软件程序控制所述第二硬件引擎进行运算和读写操作，以及通过所述第一接口与所述第一应用通信，以及调用所述第一软件程序。
  18. 根据权利要求10至17任一项所述的方法，其特征在于，所述系统集成在片上系统SoC中。
  19. 一种数据处理装置，其特征在于，包括多个硬件引擎、第一存储单元以及常开不掉电AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在可信执行环境TEE或安全执行环境SEE中，所述第二硬件引擎运行在富执行环境REE中，所述数据处理装置用于执行如权利要求10至18中任意一项所述的方法。
  20. 一种芯片，其特征在于，包括一个或多个接口电路、一个或多个处理器、多个硬件引擎、第一存储单元以及常开不掉电AO的第二存储单元，所述多个硬件引擎包括第一硬件引擎和第二硬件引擎，所述第二存储单元与所述多个硬件引擎分别硬线连接，所述第二存储单元为软件不可读，所述第一硬件引擎运行在可信执行环境TEE或安全执行环境SEE中，所述第二硬件引擎运行在富执行环境REE中，所述多个硬件引擎用于执行权利要求10至权利要求18中任一项所述的方法。
  21. 一种计算机存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序运行在计算机或处理器上时，使得所述计算机或所述处理器执行如权利要求10至权利要求18中任一项所述的方法。
  22. 一种计算机程序产品，其特征在于，所述计算机程序产品包括软件程序，当所述软件程序被计算机或处理器执行时，使得权利要求10至18任一项所述的方法的步骤被执行。
PCT/CN2022/072190 2022-01-14 2022-01-14 数据处理方法及系统 WO2023133862A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/CN2022/072190 WO2023133862A1 (zh) 2022-01-14 2022-01-14 数据处理方法及系统
CN202280003742.2A CN116868195A (zh) 2022-01-14 2022-01-14 数据处理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2022/072190 WO2023133862A1 (zh) 2022-01-14 2022-01-14 数据处理方法及系统

Publications (1)

Publication Number Publication Date
WO2023133862A1 true WO2023133862A1 (zh) 2023-07-20

Family

ID=87279867

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/072190 WO2023133862A1 (zh) 2022-01-14 2022-01-14 数据处理方法及系统

Country Status (2)

Country Link
CN (1) CN116868195A (zh)
WO (1) WO2023133862A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114553476A (zh) * 2022-01-10 2022-05-27 网宿科技股份有限公司 基于国密和国际算法的https请求的处理方法和装置
CN117786729A (zh) * 2024-02-26 2024-03-29 芯能量集成电路(上海)有限公司 一种芯片密钥管理方法及系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070180515A1 (en) * 2002-08-07 2007-08-02 Radoslav Danilak System and method for transparent disk encryption
CN104081712A (zh) * 2012-02-09 2014-10-01 英特尔公司 使用隐藏的根密钥的可重复的应用特定的加密密钥获得
US9064135B1 (en) * 2006-12-12 2015-06-23 Marvell International Ltd. Hardware implemented key management system and method
CN106529308A (zh) * 2015-09-10 2017-03-22 深圳市中兴微电子技术有限公司 一种数据加密方法、装置及移动终端
US20210200882A1 (en) * 2019-12-31 2021-07-01 Arm Limited Device, System, and Method of Policy Enforcement for Rich Execution Environment
CN113704835A (zh) * 2021-08-20 2021-11-26 北京计算机技术及应用研究所 一种支持加密卡功能的可信存储硬盘
CN113821835A (zh) * 2021-11-24 2021-12-21 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070180515A1 (en) * 2002-08-07 2007-08-02 Radoslav Danilak System and method for transparent disk encryption
US9064135B1 (en) * 2006-12-12 2015-06-23 Marvell International Ltd. Hardware implemented key management system and method
CN104081712A (zh) * 2012-02-09 2014-10-01 英特尔公司 使用隐藏的根密钥的可重复的应用特定的加密密钥获得
CN106529308A (zh) * 2015-09-10 2017-03-22 深圳市中兴微电子技术有限公司 一种数据加密方法、装置及移动终端
US20210200882A1 (en) * 2019-12-31 2021-07-01 Arm Limited Device, System, and Method of Policy Enforcement for Rich Execution Environment
CN113704835A (zh) * 2021-08-20 2021-11-26 北京计算机技术及应用研究所 一种支持加密卡功能的可信存储硬盘
CN113821835A (zh) * 2021-11-24 2021-12-21 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114553476A (zh) * 2022-01-10 2022-05-27 网宿科技股份有限公司 基于国密和国际算法的https请求的处理方法和装置
CN117786729A (zh) * 2024-02-26 2024-03-29 芯能量集成电路(上海)有限公司 一种芯片密钥管理方法及系统
CN117786729B (zh) * 2024-02-26 2024-05-24 芯能量集成电路(上海)有限公司 一种芯片密钥管理方法及系统

Also Published As

Publication number Publication date
CN116868195A (zh) 2023-10-10

Similar Documents

Publication Publication Date Title
US9965653B2 (en) Trusted computing
CN109858265B (zh) 一种加密方法、装置及相关设备
US7986786B2 (en) Methods and systems for utilizing cryptographic functions of a cryptographic co-processor
US7503064B2 (en) Framework for providing a security context and configurable firewall for computing systems
US7657754B2 (en) Methods and apparatus for the secure handling of data in a microcontroller
US8935746B2 (en) System with a trusted execution environment component executed on a secure element
KR101608510B1 (ko) 글로벌 플랫폼 규격을 사용하는 발행자 보안 도메인에 대한 키 관리 시스템 및 방법
US11082231B2 (en) Indirection directories for cryptographic memory protection
CN101551784B (zh) 一种usb接口的ata类存储设备中数据的加密方法及装置
US10303880B2 (en) Security device having indirect access to external non-volatile memory
US20090307451A1 (en) Dynamic logical unit number creation and protection for a transient storage device
WO2022073429A1 (zh) 数据管理方法、装置及系统、存储介质
WO2023273647A1 (zh) 虚拟化可信平台模块实现方法、安全处理器及存储介质
Chang et al. User-friendly deniable storage for mobile devices
WO2023133862A1 (zh) 数据处理方法及系统
JP5806187B2 (ja) 秘密情報の交換方法およびコンピュータ
CN112363800B (zh) 一种网卡的内存访问方法、安全处理器、网卡及电子设备
CN114244565A (zh) 密钥分发方法、装置、设备、存储介质和计算机程序产品
Proskurin et al. seTPM: Towards flexible trusted computing on mobile devices based on globalplatform secure elements
US11972002B2 (en) Method of logging in to operating system, electronic device and readable storage medium
Boubakri et al. Architectural Security and Trust Foundation for RISC-V
Jung et al. An architecture for virtualization-based trusted execution environment on mobile devices
Han et al. Design and implementation of a portable TPM scheme for general-purpose trusted computing based on EFI
Caetano SmartZone: Enhancing the security of TrustZone with SmartCards
CN110059489A (zh) 安全电子设备

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 202280003742.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22919510

Country of ref document: EP

Kind code of ref document: A1