Data processing method and system

Abstract

The embodiment of the application provides a data processing method and system, the system comprises a first hardware engine and a second hardware engine, and an AO storage unit hard-wired connected with each hardware engine, the first hardware engine can encrypt key plaintext in TEE or SEE by using a root key read from the AO storage unit; the second hardware engine can decrypt key ciphertext in REE by using the root key, and use the decrypted key plaintext to perform encryption and decryption operation on data of an application. The system can make the key plaintext of the application not out of the hardware all the way, achieve hardware level security, and the AO storage unit is unreadable for software, and is written with the first root key only once when the data processing system is initialized, which can improve the cracking difficulty of the key ciphertext, in addition, the decrypted key plaintext can be used in REE to perform encryption and decryption on data of an application, without switching the running environment, which can improve the encryption and decryption performance of data.

Description

Technical Field

[0001] This application relates to the field of electronic technology, and in particular to a data processing method and system. Background Technology

[0002] Currently, terminal devices such as mobile phones, tablets, personal computers (PCs), IoT (Internet of Things), and wearable devices have become indispensable tools in people's daily lives. In real life, security applications with high security requirements, such as mobile payment, mobile finance, and car keys, are widely used on mobile phones. Implementing these security applications on mobile phones not only requires the development of corresponding software applications, but more importantly, it requires providing hardware-level security solutions for the mobile phone chip to ensure the safety of users' assets and sensitive data.

[0003] To ensure the security of sensitive data (such as users' personal or private data), it is typically necessary to encrypt and protect the data before secure storage or transmission. To this end, manufacturers utilize hardware cryptographic engines within the chip platforms of terminal devices to provide general cryptographic services for their upper-layer applications, ensuring the secure storage or transmission of data. When designing the hardware and software aspects of these cryptographic services (or keystore systems), trade-offs and balances must usually be made regarding performance, security, cost, and power consumption.

[0004] Current hardware cryptographic engines can be categorized into three security levels, from lowest to highest:

[0005] First, considering performance and cost, only a portion of the private key is configured in the hardware cryptographic engine of the SoC (System-on-Chip), while the plaintext of the other keys is stored in memory. This hardware cryptographic engine design means that the plaintext of the keys in memory is not stored in the hardware, making it vulnerable to being stolen by malicious programs. It also results in weak resistance to tampering and side-channel attacks, and thus has the lowest level of security.

[0006] Second, bind the key material to the trusted execution environment (TEE) of the terminal device. TEE (such as ARM's TrustZone technology) is generally an execution environment based on the same CPU with resource isolation and time slice rotation, and its security level is lower than that of pure hardware isolation.

[0007] Third, bind the key material to the Secure Element (SE). SE is generally a pure hardware isolation method with its own independent CPU and related resources. It has a relatively high security level, but poor performance.

[0008] Therefore, the hardware cryptographic engines in various chip platforms currently struggle to balance performance and security when providing cryptographic services. Summary of the Invention

[0009] To address the aforementioned technical problems, embodiments of this application provide a data processing method and system. In this system, by storing the root key in an AO storage unit and introducing multiple hardware engines, the plaintext key exists only within the hardware engines, thereby improving the performance and security of data encryption and decryption operations.

[0010] In a first aspect, embodiments of this application provide a data processing system, including multiple hardware engines, a first storage unit, and an always-on (AO) second storage unit. The multiple hardware engines include 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 software-unreadable. The first hardware engine runs in a TEE or SEE (Secure Execution Environment), and the second hardware engine runs in a REE (Rich Execution Environment).

[0011] The first hardware engine is configured to: read the first key from the second storage unit; encrypt the first key plaintext based on the first key to generate the first key ciphertext; and write the first key ciphertext into the first storage unit.

[0012] 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; decrypt the first key ciphertext based on the first root key to generate the first key plaintext; and encrypt or decrypt first data based on the first key plaintext to generate second data.

[0013] The second storage unit is used to store the first root key and to write the first root key only once during the initialization of the data processing system.

[0014] For example, the first storage unit can be configured as shared memory for multiple hardware engines.

[0015] For example, the first storage unit may be on-chip memory (e.g., a register) or off-chip memory (e.g., DDR SDRAM, Double Data Rate Synchronous Dynamic Random Access Memory, NVM (Non-volatile memory, memory that does not lose data when power is off or when disconnected)).

[0016] For example, a hardwired connection can be a chip-level physical connection.

[0017] For example, a hardwired connection can be used to represent a permanent physical connection, different from a switch connection, for transmitting data between two computers.

[0018] For example, the second storage unit can be a separate register (such as an AO register) or a storage unit deployed on the chip.

[0019] For example, the second storage unit may be written with the first root key once when the data processing system is powered on.

[0020] For example, the second storage unit may be written with the aforementioned root key under software control. For example, when the data processing system starts the BootLoader, the BootLoader may control the writing of the first root key to the second storage unit once.

[0021] Optionally, the first hardware engine runs in the SEE, and the first hardware engine can be the SE, which has its own CPU and storage space.

[0022] For example, the first key plaintext may be the working key plaintext of an upper-layer application (e.g., the first application).

[0023] For example, the first data may be application data to be encrypted or decrypted from an upper-layer application (e.g., the first application).

[0024] Optionally, the system may also include a first software program for controlling the first hardware engine and a second software program for controlling the second hardware engine.

[0025] The second software program can provide a first interface to the upper-layer application, allowing the upper-layer application to call the password services provided by the multiple hardware engines.

[0026] The second software program can call the first software program so that the first software program can control the first hardware engine.

[0027] For example, the first hardware engine runs in a TEE, and the first software program may include a first driver for the first hardware engine and a software service (which may be called HiCrypto TA (Trusted Application)) that controls the first driver.

[0028] For example, the first hardware engine runs in SEE, and the first software program may include the operating system of the first hardware engine and the software service that calls the operating coefficient (which may be called HiCrypto SA (Secure Application)).

[0029] For example, the second software program of the second hardware engine may include a second driver for the second hardware engine and a software service that controls the second driver (which may be referred to as HiCrypto CA (Client Application)).

[0030] For example, an upper-layer application can read the first key ciphertext from the first storage unit.

[0031] For example, when an upper-layer application needs to encrypt or decrypt 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 to perform encryption or decryption operations on the first data to be encrypted or decrypted based on the first key ciphertext passed in by the upper-layer application.

[0032] For example, the first key ciphertext and the first data can be transmitted to the second hardware engine through the first storage unit.

[0033] For example, the first key ciphertext and the first data can be passed to the second hardware engine at once during a single function call, or the first key ciphertext and the first data can be passed to the second hardware engine separately by calling different functions. This application does not limit this.

[0034] For example, when an upper-layer application needs to encrypt or decrypt 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 to perform encryption or decryption operations on the first data to be encrypted or decrypted based on the first key ciphertext passed in by the upper-layer application.

[0035] For example, the first key ciphertext and the first data can be transmitted to the second hardware engine through the first storage unit.

[0036] For example, the first key ciphertext and the first data can be passed to the second hardware engine at once during a single function call, or the first key ciphertext and the first data can be passed to the second hardware engine separately by calling different functions. This application does not limit this.

[0037] The system in this embodiment includes multiple hardware engines and an AO storage unit hardwired to each hardware engine. The AO storage unit stores a root key and is software-inaccessible. The root key is written to the AO storage unit only once during the initialization of the data processing system, thereby improving the security of the root key. The first hardware engine running in a TEE or SEE can use the root key read from the AO storage unit to encrypt the plaintext key of the upper-layer application and share the ciphertext key to the second hardware engine through the first storage unit. This ensures that the plaintext key never leaves the hardware, achieving a hardware security level. The second hardware engine running in a REE can use the root key read from the AO storage unit to decrypt the ciphertext key (exemplarily, the ciphertext key can be read from the first storage unit). This allows the plaintext key to be used for data encryption and decryption operations. The second hardware engine can perform data encryption and decryption operations directly in the REE without switching to a TEE or SEE environment, reducing the time loss of switching paths and improving data encryption and decryption performance.

[0038] Furthermore, in this embodiment, the first key in the AO storage unit can be used to protect the plaintext of the key. As a software-unreadable hardware storage unit, the AO storage unit can enhance the protection strength of the plaintext key. In addition, the AO storage unit is hardwired to multiple hardware engines, and each time the 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 secure transmission of the key that needs to be protected (such as the working key of the application) between the multiple hardware engines. Moreover, apart from the channel used to connect the multiple hardware engines through the AO storage unit, the design can effectively decouple them and allow them to operate independently, thereby maximizing performance.

[0039] In addition, the system of this application embodiment utilizes multiple hardware engines and AO storage units to achieve hardware-level protection of the key to be protected. Compared with software algorithms, this application embodiment can significantly reduce CPU load and effectively control power consumption (heat generation) by using a dedicated hardware engine, while achieving the effect of keeping the key out of the hardware throughout the entire process.

[0040] According to the first aspect, the second storage unit is configured to have the first key written to it only when the data processing system is powered on. Furthermore, the second storage unit can also be configured to prevent further writing of the first key after it has been written once.

[0041] In this embodiment, the second storage unit refreshes the root key stored internally each time the system is powered on. After the system is powered on once, no more data can be written after the first data is written. This ensures that the root key used to encrypt the plaintext key that needs to be protected is the same after the system is powered on once. This allows the same root key to be used multiple times to decrypt the ciphertext key and obtain the plaintext key when the plaintext key needs to be used for data encryption and decryption multiple times after the system is powered on once, without the need to frequently switch the root key used. This further improves the data encryption and decryption performance and encryption security.

[0042] According to the first aspect, or any implementation of the first aspect above, the first hardware engine includes a first true random number generation module; the first true random number generation module is used to generate a first true random number during the initialization of the data processing system, and use the first true random number as the first root key.

[0043] For example, the first true random number generation module can automatically perform the above function when the data processing system is powered on, and the first software program can be controlled by the BootLoader to control the first hardware engine so that the first true random number generation module can perform the above function. This application does not limit this.

[0044] In this embodiment of the application, when transmitting the plaintext key (e.g., the working key of an upper-layer application) between multiple hardware engines, the plaintext key can be protected by hardware-level encryption using a truly random number generated by the first truly random number generation module each time the system is initialized, thereby improving the protection strength of the plaintext key.

[0045] According to the first aspect, or any implementation of the first aspect above, the first hardware engine is further configured to: generate the first root key according to the first variable and the second root key, wherein the second key is a preset key; and write the first key into the second storage unit.

[0046] For example, the first hardware engine may be controlled by the first software program to perform the additional functions defined in this implementation.

[0047] For example, the first variable may be pre-configured in the first software program and passed to the first hardware engine by the first software program when it controls the first hardware engine.

[0048] For example, the second root key may be a hardware root key within the first hardware engine, which may be a unique hardware root key preset within the first hardware engine.

[0049] For example, the first hardware engine may include a key derivation module, which can perform key derivation on the second root key according to the first variable to generate the first root key.

[0050] In this embodiment of the application, 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 flexibility of the generation method of the first root key.

[0051] According to the first aspect, or any implementation of the first aspect above, the first hardware engine runs in the SEE, and the plurality of hardware engines further includes a third hardware engine, which runs in the TEE;

[0052] The third hardware engine is configured to: read the first root key from the second storage unit; decrypt the first key ciphertext based on the first root key to generate the first key plaintext; and encrypt or decrypt the third data based on the first key plaintext to generate the fourth data.

[0053] For example, when multiple hardware engines include a first hardware engine running in SEE, a second hardware engine running in REE, and a third hardware engine running in TEE, in most scenarios, the second hardware engine can perform encryption and decryption operations on the data. If the second hardware engine meets preset conditions, such as being busy, or if the encryption / decryption algorithm configured in the second hardware engine is different from the encryption / decryption algorithm required for this data encryption / decryption, the third hardware engine can read the first key written by the first hardware engine from the second storage unit and use the encryption / decryption algorithm that meets the requirements of this data encryption / decryption to perform the data encryption / decryption operation. This can improve the reliability of data encryption and decryption in the system of this application embodiment.

[0054] For example, the third data mentioned above may be the same as or different from the first data, and this application does not impose any restrictions on this.

[0055] For example, the system may also include a third software program for controlling a third hardware engine.

[0056] For example, the third software program may include the TA described in the first aspect and a driver for controlling the third hardware engine.

[0057] Similar to the description of the first aspect above, the second software program can call the third software program to enable the third software program to control the third hardware engine.

[0058] According to the first aspect, or any implementation of the first aspect above, the second hardware engine further includes a first register, wherein the first register is software unreadable and software unwritable;

[0059] The first register is used to store the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt application data, wherein the application data may include the first data.

[0060] For example, after the second hardware engine reads the first key ciphertext from the first storage unit, it can decrypt the first key ciphertext based on the first root key to generate the first key plaintext. Then, the second hardware engine can write the first key plaintext generated by this engine into the first register.

[0061] For example, the number of first registers can be one or more, and this application does not limit this.

[0062] Optionally, the data processing system further includes a first software program and a second software program, the second software program having a first interface, and the first application running in the REE;

[0063] The first software program is used to control the first hardware engine, and the second software program is used to control the second hardware engine.

[0064] The first application is the upper-layer application for user use. The second software program provides a first interface to the upper-layer application, allowing it to call the cryptographic services provided by the multiple hardware engines.

[0065] The second software program can call the first software program so that the first software program can control the first hardware engine.

[0066] The second software program is also used to control the second hardware engine in response to a second request from the first application to the first interface.

[0067] Optionally, if the second request is a three-part function call request, then the second hardware engine can respond to the second request by sending the handle information of the first register to the first application through the second software program. Then, the first application can call the second software program by triggering the second request carrying the handle information multiple times, so that the second software program controls the second hardware engine to read the first key plaintext from the first register according to the handle information, and to perform encryption and decryption operations on the application data.

[0068] In this embodiment of the application, by configuring a first register in the second hardware engine to store the first key plaintext, since the first register is unreadable and unwritable by software, it can be ensured that the ACPU cannot read the first key plaintext from the first register in the second hardware engine, so that the key plaintext achieves hardware-level security.

[0069] According to the first aspect, or any implementation of the first aspect above, the first hardware engine is specifically used for: encrypting the first key plaintext based on the key parameters and the first root key to generate first ciphertext data; and obtaining verification data based on the first ciphertext data; wherein the first key ciphertext includes the key parameters, the first ciphertext data, and the verification data.

[0070] The second hardware engine is specifically used to: verify and authenticate the first ciphertext data based on the verification data in the first key ciphertext; and, if the verification and authentication pass, decrypt the first ciphertext data based on the key parameters and the first root key to obtain the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt the first data.

[0071] For example, the first hardware engine can use the GCM mode of the AES or SM4 algorithm to perform the encryption operation of the key plaintext. It should be noted that the specific authentication encryption algorithm used by the first hardware engine when encrypting the key plaintext is not limited to the GCM mode of AES or SM4, but can also be other authentication encryption algorithms.

[0072] For example, SM4's GCM mode can be used for authentication encryption to ensure the integrity of plaintext or other authenticated content. Verification parameters during encryption may include, but are not limited to, the following: TAG, optionally including Additional Authentication Data (AAD). Key parameters may include IV (Initialization Vector) values.

[0073] For example, TAG is a message authentication code in GCM mode.

[0074] For example, the IV value can be generated by a true random number generation module within the first hardware engine (which can be any true random number generation module configured within the first hardware engine).

[0075] For example, AAD can be passed in by the first application.

[0076] The first hardware engine can be specifically used 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; calculate the TAG for the first ciphertext data and the AAD (optionally) passed in by the first application; and use the IV value, the AAD (optionally), the first ciphertext data and the TAG as the first key ciphertext.

[0077] The second hardware engine can be specifically used to: calculate TAG' on the first ciphertext data in the first key ciphertext and the AAD (optionally); detect that the TAG is the same as TAG', verify and authenticate successfully, and then decrypt the first ciphertext data based on the first root key and the IV value in the first key ciphertext to generate the first key plaintext.

[0078] In this embodiment, when encrypting the plaintext key, the first hardware engine can set the key parameter IV value and the TAG for verification, thereby enabling the system of this embodiment to support authentication and anti-spoofing of upper-layer applications, so as to prevent other applications from stealing the plaintext key and impersonating a specific application to use this system to decrypt the data of that specific application.

[0079] According to the first aspect, or any implementation of the first aspect above, the data processing system further includes a first software program and a second software program, the second software program having a first interface, and the first application running in the REE;

[0080] The first software program is used to control the first hardware engine to perform calculations and read / write operations;

[0081] The second software program is used for:

[0082] Control the second hardware engine to perform computation and read / write operations;

[0083] Communicating with the first application through the first interface;

[0084] Invoke the first software program.

[0085] For example, a first software program is used to control a first hardware engine, and a second software program is used to control a second hardware engine.

[0086] The first application is the upper-layer application for user use. The second software program provides a first interface to the upper-layer application, allowing it to call the cryptographic services provided by the multiple hardware engines.

[0087] The second software program can call the first software program so that the first software program can control the first hardware engine.

[0088] For example, the first application can communicate with the second software program by calling the first interface. For instance, the second software program can receive the first request from the first application through the first interface.

[0089] In response to the first request, the second software program can call the first software program. Then, the first software program can control the first hardware engine to perform calculations and read / write operations. Specifically, the first hardware engine can be controlled by the first software program to read the first key from the second storage unit; based on the first key, encrypt the first key plaintext to generate the first key ciphertext; and write the first key ciphertext into the first storage unit.

[0090] The second software program may, in response to a first request from the first application, read information from the first storage unit that indicates the first key ciphertext (e.g., the address information of the first key ciphertext in the first storage unit) and send the information to the first application.

[0091] For example, in response to the first request, the second software program may allocate address information to the first application, which is the address information in the first storage unit used to write the aforementioned first key ciphertext. The second software program may also send this address information to the first software program in response to the first request.

[0092] For example, when the first software program controls the first hardware engine to perform the encryption operation of the key plaintext described in the first aspect, it may send the address information to the first hardware engine so that the first hardware engine writes the generated key ciphertext into the first storage unit according to the address information.

[0093] For example, after the key ciphertext is written to the first storage unit, the second software program may respond to the first request by sending the address information to the first application so that the first application can read the first key ciphertext from the first storage unit.

[0094] For example, after obtaining 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 a second request to the second software program through the first interface.

[0095] In response to the second request, the second software program can control the second hardware engine to perform computation and read / write operations. Specifically, the second hardware engine can be controlled by the second software program to read the first root key from the second storage unit; read the first key ciphertext from the first storage unit; decrypt the first key ciphertext based on the first root key to generate the first key plaintext; and encrypt or decrypt the first data based on the first key plaintext to generate the second data.

[0096] After performing data encryption and decryption operations, the second hardware engine can write the second data into the first storage unit. The write address of the second data in the first storage unit can be carried by the first application in the second request when it triggers the second request. Then the first application can read the second data from the corresponding address of the first storage unit.

[0097] In this embodiment, an upper-layer application running in the REE can communicate with a second software program through a first interface. The second software program then calls the first software program to control the first hardware engine to perform computation and read / write operations. This allows the first hardware engine to encrypt the plaintext of the upper-layer application's first key, generating ciphertext, which the upper-layer application can then access. When the upper-layer application needs to encrypt or decrypt data, it can communicate with the second software program through the first interface. The second software program controls the second hardware engine to perform computation and read / write operations. This allows the second hardware engine to read the first root key from the second storage unit; read the ciphertext of the first key from the first storage unit; decrypt the ciphertext of the first key based on the first root key to generate the plaintext of the first key; and encrypt or decrypt the first data based on the plaintext of the first key to generate the second data. This eliminates the need to switch the runtime environment to a TEE or SEE. The second hardware engine can independently perform data encryption and decryption operations within the REE, significantly reducing path time loss and effectively improving data encryption and decryption performance.

[0098] According to the first aspect, or any implementation of the first aspect above, 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 encrypt or decrypt the first key plaintext; and to decrypt the second key ciphertext 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.

[0099] For example, the second variable mentioned above may be the same as or different from the first variable mentioned above. The second variable may be pre-configured in the first software program. The principle by which the first hardware engine obtains the fourth key according to the second variable and the second key is the same as the principle by which the first hardware engine generates the first key according to the first variable and the second key in the above implementation method, and will not be repeated here.

[0100] For example, the second variable mentioned above can be configured in the system's first software program before the system leaves the factory. This second variable can be distributed by a third-party cryptographic management center (e.g., PKI (Public Key Infrastructure)). The third-party cryptographic management center also possesses the second variable and the second root key. The third-party cryptographic management center can generate the fourth root key mentioned above according to the second variable and the second root key, and distribute it offline to the upper-layer application. For example, this upper-layer application is the first application. Furthermore, when the first application is an application used in conjunction with the cloud, the upper-layer application can include both the cloud and the first application.

[0101] When the upper-layer application includes both 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.

[0102] When the cloud needs to import the working key into the system of this application, it can import the above-mentioned second key ciphertext encapsulated using the fourth key.

[0103] For example, the cloud can call a second software program through an interface, so that the second software program can call the first software program to import the information of the second key ciphertext (e.g., the second key ciphertext, optionally, the address information of the second key ciphertext) passed from the cloud to indicate the first application into the first hardware engine for encrypting the working key.

[0104] In this embodiment, the key imported into the first hardware engine can be a second key ciphertext encapsulated using a symmetric key. The symmetric key can be a fourth key obtained according to the second variable and the second key. The system in this embodiment supports scenarios where applications import symmetrically encapsulated keys. This not only ensures that the second key ciphertext to be protected remains entirely within the hardware, but also allows the fourth key to be derived from the second key using the second variable. Therefore, different values ​​for the second variable can be configured for different applications or services, enabling flexible customization of the fourth key according to customer needs.

[0105] According to the first aspect, or any implementation of the first aspect above, the first hardware engine further includes a second true random number generation module;

[0106] For example, the second true random number generation module may be the same as or different from the first true random number generation module described above, and this application does not impose any restrictions on this.

[0107] The second true random number generation module is used to generate a second true random number and a third true random number as the first public key plaintext and the first private key plaintext, respectively, during the initialization (including but not limited to power-on) of the data processing system.

[0108] The first hardware engine is further configured to encrypt the first private key plaintext based on the first root key, generate a first private key ciphertext, and write the first private key ciphertext into the first 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 to generate the first private key plaintext; and decrypt the third key ciphertext based on the first private key plaintext to obtain the first key plaintext of the first application; wherein the third key ciphertext is data encrypted by the first application based on the first public key plaintext, and the third key ciphertext is generated by the first application and sent to the first software program through the second software program.

[0109] For example, the first software program can 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 can be used to send the first public key plaintext to an upper-layer application. For example, the upper-layer application is the first application. Furthermore, when the first application is an application used in conjunction with the cloud, the upper-layer application may include the cloud and the first application.

[0110] For example, when the cloud needs to import the working key into the system of this application, it can import the ciphertext of the third key that is encapsulated in plaintext using the first public key.

[0111] For example, the cloud can call a second software program through an interface, so that the second software program can call a first software program to import the information of the third key ciphertext (e.g., the address information of the third key ciphertext, optionally, the second key ciphertext) passed from the cloud to indicate the first application into the first hardware engine for encrypting the working key.

[0112] In this application embodiment, the key imported into the first hardware engine can be a third key ciphertext encapsulated using an asymmetric key. The system of this application embodiment can support the scenario of importing asymmetric encapsulated keys, enabling the third key ciphertext to be protected to remain within the hardware throughout the process. Moreover, it can flexibly customize and develop a key to encapsulate the first key plaintext according to customer needs.

[0113] In addition, the key used to encapsulate the working key of the application in this embodiment can be generated by the first hardware engine through random numbers, which can be done without the aid of an external cryptographic management center, thus providing greater flexibility in key management for the application.

[0114] According to the first aspect, or any implementation of the first aspect above, the first hardware engine includes a third true random number generation module;

[0115] For example, the third true random number generation module may be the same as or different from the first true random number generation module described above, and this application does not impose any restrictions on this.

[0116] The second software program is further configured to, in response to a fifth request from the first application to the first interface, invoke the first software program to control the first hardware engine, the fifth request including the first key plaintext;

[0117] The third true random number generation module is used to generate a fourth true random number as the first key plaintext of the first application in response to the fifth request.

[0118] In this embodiment, the first hardware engine can use a true random number generation module to generate the working key (i.e., the first key plaintext) for the first application without requiring the application to import the working key, thus enabling the system of this embodiment to be applied to key generation scenarios.

[0119] According to the first aspect, or any implementation of the first aspect above, the second software program is further configured to, in response to a sixth request from the first application to the first interface, invoke the first software program to control the first hardware engine, wherein the sixth request includes the first key plaintext.

[0120] The first hardware engine is also used to write the first key plaintext into the first storage unit;

[0121] The second hardware engine also includes a second register.

[0122] For example, the second register is software writable but software unreadable;

[0123] The second hardware engine is used 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 is used to store the first key plaintext.

[0124] In the system of this application embodiment, a channel for the application to directly set the plaintext key in the second register can be reserved in the second hardware engine. This provides a channel for the application to pass the plaintext key to the second hardware engine. Since the application can directly pass the plaintext key to the second hardware engine in the REE, without passing the plaintext key to the first hardware engine running in the TEE or SEE, the key import and data encryption / decryption operations can be performed in the REE alone. This can accelerate the data encryption / decryption performance without occupying CPU load.

[0125] According to the first aspect, or any implementation of the first aspect above, the system is integrated in a system-on-a-chip (SoC).

[0126] Secondly, embodiments of this application provide a data processing method applied to a data processing system. The data processing system includes multiple hardware engines, a first storage unit, and a second storage unit of an AO (Automatic Array of Components). The multiple hardware engines include a first hardware engine and a second hardware engine. The second storage unit is hardwired to each of the multiple hardware engines and is software-unreadable. The first hardware engine runs in a TEE (Technical Equipment Environment) or SEE (System-on-Engineer), and the second hardware engine runs in a REE (Remote Equipment Environment). The method includes: the first hardware engine reading a first root key from the second storage unit; the first hardware engine encrypting plaintext of the first key based on the first root key to generate ciphertext of the first key; the first hardware engine writing the ciphertext of the first key into the first storage unit; the second hardware engine reading the first root key from the second storage unit; the second hardware engine reading the ciphertext of the first key from the first storage unit; the second hardware engine decrypting the ciphertext of the first key based on the first root key to generate plaintext of the first key; and the second hardware engine encrypting or decrypting first data based on the plaintext of the first key to generate second data. The second storage unit is used to store the first root key and is used to be written to the first root key only once during the initialization of the data processing system.

[0127] According to the second aspect, the second storage unit is specifically configured to have the first root key written to it only when the data processing system is powered on. Furthermore, the second storage unit may also be configured to prevent further writing of the first root key after it has been written once.

[0128] According to the second aspect, or any implementation of the second aspect above, before the first hardware engine reads the first root key from the second storage unit, the method further includes: the first hardware engine generating a first true random number during the initialization of the data processing system, using the first true random number as the first root key, and writing the first root key into the second storage unit.

[0129] According to the second aspect, or any implementation of the second aspect above, before the first hardware engine reads the first root key from the second storage unit, the method further includes: the first hardware engine generating the first root key according to the first variable and the second root key, and writing the first root key into the second storage unit, wherein the second root key is a preset key.

[0130] According to the second aspect, or any implementation of the second aspect above, the first hardware engine runs in the SEE, and the plurality of hardware engines further includes a third hardware engine running in the TEE; after the first hardware engine writes the first key ciphertext into the first storage unit, the method further includes: the third hardware engine reading the first root key from the second storage unit; the third hardware engine decrypting the first key ciphertext based on the first root key to generate the first key plaintext; and the third hardware engine encrypting or decrypting third data based on the first key plaintext to generate fourth data.

[0131] According to the second aspect, or any implementation of the second aspect above, the second hardware engine further includes a first register, wherein the first register is software-unreadable and software-unwritable; after the second hardware engine decrypts the first key ciphertext based on the first root key to generate the first key plaintext, the method further includes: the second hardware engine writing the first key plaintext into the first register.

[0132] For example, the first register is used to store the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt application data, wherein the application data may include the first data.

[0133] According to the second aspect, or any implementation thereof, 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 first key plaintext based on the key parameters and the first root key to generate first ciphertext data, and obtains verification data based on the first ciphertext data; wherein, the first key ciphertext includes the key parameters, the first ciphertext data, and the verification data; the second hardware engine decrypts the first key ciphertext based on the first root key to generate the first key plaintext, including: the second hardware engine performs verification and authentication on the first ciphertext data 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 parameters and the first root key to obtain the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt the first data.

[0134] According to the second aspect, or any implementation of the second aspect above, the data processing system further includes a first software program and a second software program, the second software program having a first interface, the first application running in the REE, and the method further includes: the first software program controlling the first hardware engine to perform calculation and read / write operations; the second software program controlling the second hardware engine to perform calculation and read / write operations, communicating with the first application through the first interface, and calling the first software program.

[0135] According to the second aspect, or any implementation of the second aspect above, the method further includes: the second software program, in response to a third request from the first application to the first interface, invoking the 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 data encrypted with the first key plaintext based on a fourth root key. The fourth root key is a root key generated by the first hardware engine based on a second variable and the second root key; the first key plaintext is data decrypted with the second key ciphertext based on the fourth key.

[0136] For example, 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 encrypt or decrypt the first key plaintext; and to decrypt the second key ciphertext of the first application based on the fourth 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.

[0137] According to the second aspect, or any implementation thereof, the first software program obtains the first public key plaintext and sends the first public key plaintext to the second software program, wherein the first public key plaintext is a second true random number generated by the first hardware engine during the initialization of the data processing system; the second software program sends the first public key plaintext to the first application; the second software program is further configured to respond to a fourth request from the first application to the first interface by invoking the first software program to control the first hardware engine, wherein the fourth request includes information for indicating a third key ciphertext, wherein the third key ciphertext is data encrypted based on the first public key plaintext. The first key plaintext is data decrypted based on the first private key plaintext; the first private key plaintext is a third true random number generated by the first hardware engine when the data processing system is powered on; and the first root key is further used to encrypt or decrypt the first private key plaintext.

[0138] According to the second aspect, or any implementation of the second aspect above, the first hardware engine includes a third true random number generation module;

[0139] For example, the third true random number generation module may be the same as or different from the first true random number generation module described above, and this application does not impose any restrictions on this.

[0140] The second software program may respond to a fifth request from the first application to the first interface by invoking the first software program to control the first hardware engine, the fifth request including the first key plaintext;

[0141] The third true random number generation module may, in response to the fifth request, generate a fourth true random number as the first key plaintext of the first application.

[0142] In this embodiment of the application, the first hardware engine can use a true random number generation module to generate the working key (i.e., the first key plaintext) of the first application without requiring the application to import the working key, so that the system to which the method of this embodiment of the application is applied can be applied to key generation scenarios.

[0143] According to the second aspect, or any implementation of the second aspect above, the second software program may, in response to the first application's sixth request to the first interface, invoke the first software program to control the first hardware engine, the sixth request including the first key plaintext; the first hardware engine may write the first key plaintext into the first storage unit; the second hardware engine further includes a second register.

[0144] For example, the second register is software writable but software unreadable;

[0145] The second hardware engine can 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 to store the first key plaintext.

[0146] In the system of this application embodiment, a channel for the application to directly set the plaintext key in the second register can be reserved in the second hardware engine. This provides a channel for the application to pass the plaintext key to the second hardware engine. Since the application can directly pass the plaintext key to the second hardware engine in the REE, without passing the plaintext key to the first hardware engine running in the TEE or SEE, the key import and data encryption / decryption operations can be performed in the REE alone. This can accelerate the data encryption / decryption performance without occupying CPU load.

[0147] According to the second aspect, or any implementation of the second aspect above, the system is integrated into the SoC.

[0148] The second aspect and any implementation thereof correspond to the first aspect and any implementation thereof, respectively. The technical effects of the second aspect and any implementation thereof are similar to those of the first aspect and any implementation thereof, and will not be repeated here.

[0149] Thirdly, embodiments of this application provide 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 engines include 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 not readable by software. The first hardware engine runs in TEE or SEE, and the second hardware engine runs in REE. The multiple hardware engines can implement the methods in the second aspect and any implementation of the second aspect.

[0150] The third aspect and any implementation thereof correspond to the second aspect and any implementation thereof, respectively. The technical effects of the third aspect and any implementation thereof can be found in the technical effects of the second aspect and any implementation thereof, as described above, and will not be repeated here.

[0151] Fourthly, embodiments of this application provide a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed on a computer or processor, causes the computer or processor to perform the methods of the second aspect or any possible implementation thereof.

[0152] The fourth aspect and any implementation thereof correspond to the second aspect and any implementation thereof, respectively. The technical effects of the fourth aspect and any implementation thereof can be found in the technical effects of the second aspect and any implementation thereof, as described above, and will not be repeated here.

[0153] Fifthly, embodiments of this application provide a computer program product. The computer program product includes a software program that, when executed by a computer or processor, causes the method in the fifth aspect or any possible implementation thereof to be performed.

[0154] The fifth aspect and any implementation thereof correspond to the second aspect and any implementation thereof, respectively. The technical effects of the fifth aspect and any implementation thereof can be found in the technical effects of the second aspect and any implementation thereof, as described above, and will not be repeated here.

[0155] In a sixth aspect, embodiments of this application provide a data processing apparatus, including a plurality of hardware engines, a first storage unit, and a second storage unit of an AO. The plurality of hardware engines include a first hardware engine and a second hardware engine. The second storage unit is hardwired to the plurality of hardware engines and is software unreadable. The first hardware engine runs in a TEE or SEE, and the second hardware engine runs in a REE. The data processing apparatus is used to execute the method as described in the second aspect or any possible implementation thereof.

[0156] The sixth aspect and any implementation thereof correspond to the second aspect and any implementation thereof, respectively. The technical effects of the sixth aspect and any implementation thereof are similar to those of the second aspect and any implementation thereof, and will not be repeated here. Attached Figure Description

[0157] Figure 1 This is a schematic diagram of the architecture of a multi-hardware cryptographic engine system according to an embodiment of this application;

[0158] Figure 2 This is a framework diagram illustrating the interaction between a multi-hardware cryptographic engine system and an application, according to an embodiment of this application.

[0159] Figure 3 This is a schematic diagram illustrating the interaction process between multiple hardware cryptographic engines according to an embodiment of this application;

[0160] Figure 4a This is one of the flowcharts of a multi-hardware cryptographic engine system in a key generation scenario according to an embodiment of this application;

[0161] Figure 4b This is a timing diagram of the key encryption process of a multi-hardware cryptographic engine system according to an embodiment of this application;

[0162] Figure 4c This is a timing diagram of the key usage process of a multi-hardware cryptographic engine system according to an embodiment of this application;

[0163] Figure 5 This is a flowchart illustrating the key usage process of a multi-hardware cryptographic engine system according to an embodiment of this application.

[0164] Figure 6 This is a timing diagram of the key usage process of a multi-hardware cryptographic engine system according to an embodiment of this application;

[0165] Figure 7 This is a timing diagram of the key usage process of a multi-hardware cryptographic engine system according to an embodiment of this application;

[0166] Figure 8 This is a flowchart illustrating the workflow of a multi-hardware cryptographic engine system in a key import scenario without encapsulation, according to an embodiment of this application.

[0167] Figure 9 This is a flowchart illustrating the workflow of a multi-hardware cryptographic engine system in a scenario where the key is encapsulated and imported, according to an embodiment of this application.

[0168] Figure 10 This is a flowchart illustrating the workflow of a multi-hardware cryptographic engine system in a key import scenario without encapsulation, according to an embodiment of this application.

[0169] Figure 11 This is a flowchart illustrating the workflow of a multi-hardware cryptographic engine system in a key import scenario without encapsulation, according to an embodiment of this application.

[0170] Figure 12 A schematic diagram of the structure of an apparatus provided in an embodiment of this application;

[0171] Figure 13 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

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

[0173] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0174] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0175] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0176] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0177] In traditional technologies, the Android Keystore system stores encryption keys in a secure container (such as a TEE provided by the SoC). Once an application's encryption key is entered into the Keystore, the key cannot be exported. This allows for encryption of application data using the encryption key stored in the container without exporting the key, thus increasing the difficulty of retrieving the key from the terminal device.

[0178] Keystore provides the following categories of operations: generating keys; importing and exporting asymmetric keys (without key encapsulation, only public keys can be exported); importing raw symmetric keys (without key encapsulation); asymmetric encryption and decryption using appropriate padding patterns; asymmetric signing and verification using digests and appropriate padding patterns; symmetric encryption and decryption in appropriate patterns (including AEAD patterns); and generating and verifying symmetric message verification codes.

[0179] When generating or importing a key, the system specifies protocol elements (such as purpose, mode and padding, and access control restrictions), which are permanently bound to the corresponding key to ensure that the key cannot be used in any other way.

[0180] Keystore employs two security measures to prevent key materials from being extracted:

[0181] 1) Key materials will never enter the application process.

[0182] When performing encryption operations using keys within the Android Keystore, the application feeds the plaintext, ciphertext, and message to be signed or verified to the system process performing the encryption operation in the background. If the application process is compromised, an attacker might be able to use the application key, but would not be able to extract the key material (e.g., for use outside the Android device).

[0183] 2) Developers can bind key materials to the security hardware of Android devices, such as TEE and SE.

[0184] When this feature is enabled for a key, its key material is never exposed outside the security hardware. If the Android operating system is compromised or an 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 will not be able to extract this data from the device. This feature can only be enabled if the device's security hardware supports a specific combination of key algorithms, block patterns, padding schemes, and digests that the key is authorized to use.

[0185] Supported devices running Android 9 or later can have StrongBox Keymaster, which is an implementation located in the hardware security module.

[0186] This hardware security module may include the following components:

[0187] An independent CPU that does not share any cache, DRAM (Dynamic Random Access Memory), coprocessor, or other core resources with the application processor (AP).

[0188] Secure storage space is required to ensure the confidentiality, integrity, authenticity, consistency, and freshness of content. Stored content must not be read or modified without permission from the StrongBox API.

[0189] True random number generator;

[0190] It must have anti-tampering features, including protection against physical penetration and interference, and be able to resist side-channel attacks.

[0191] When checking the key stored in StrongBox Keymaster, the Android Keystore system verifies the integrity of the key via TEE.

[0192] In addition, Secure Key Import is a new feature in Android 9. This feature allows applications to embed existing keys into a keystore in a more secure manner, and is applicable to various enterprise application scenarios. The key source may be a remote server located locally or in a cloud data center, and the secure key can be encrypted using a publicly available encapsulation key from the user's device. Furthermore, this Secure Key Import feature is only supported on devices running Keymaster 4 or later.

[0193] For Keymaster versions prior to Android 9, only the TEE security level is supported. TEE is an execution environment based on the same CPU with resource isolation and time-slice rotation, and its security level is lower than that of pure hardware isolation.

[0194] Android 9 or later supports StrongBox Keymaster, but the CPU of the SE that StrongBox Keymaster relies on is generally at the smart card level, which has high security but weak encryption and decryption performance. If the working key used for data encryption and decryption is exported from StrongBox Keymaster to improve encryption and decryption performance, the plaintext key will be exported to the hardware, and the security level will be reduced to TEE or lower.

[0195] Therefore, when the hardware cryptographic engine of a terminal device based on the SoC platform provides cryptographic services to upper-layer applications, the design of the hardware cryptographic engine inside the SoC is critical and needs to be balanced in terms of performance, security and area (related to cost).

[0196] To address this, the SoC in this application provides multiple hardware cryptographic engines. These engines can work together to provide cryptographic services (hereinafter referred to as HiCrypto Service, or Hardware Inside Crypto Service) to achieve a balance between security, performance, and cost. It is understood that "hardware cryptographic engine" refers to the addition of cryptographic-related algorithm processing within the hardware engine. In the aforementioned multiple hardware cryptographic engines, the key can be placed within each engine, enabling encryption and decryption of application data without exporting the key to the hardware. This achieves a security level comparable to pure hardware isolation and enhances encryption and decryption performance.

[0197] Figure 1 An architectural diagram of a multi-hardware cryptographic engine system according to an embodiment of this application is shown as an example.

[0198] Figure 2 An exemplary diagram illustrates the framework of an application interaction between a multi-hardware cryptographic engine system and an embodiment of this application.

[0199] Please refer to Figure 1 The multi-hardware cryptographic engine system may include a security subsystem of the SoC located at the hardware layer, and the security subsystem may include multiple hardware cryptographic engines.

[0200] Among them, hardware cryptographic engine is used to refer to hardware engine that adds cryptographic-related algorithm processing.

[0201] Among them, the multiple hardware cryptographic engines may include the REE hardware cryptographic engine (hereinafter referred to as the HCE-REE engine) and the TEE hardware cryptographic engine (hereinafter referred to as the HCE-TEE engine).

[0202] Alternatively, the HCE-REE engine and the HCE-TEE engine can be two sub-modules within a passive HCE (Hardware CryptoEngine).

[0203] In addition, considering factors such as the area cost of SoC and market demand, such as Figure 1 As shown, the security subsystem's multi-hardware cryptographic engine may optionally include inSE.

[0204] Among them, inSE (Inside / or On-die Secure Element) is an on-chip hardware security module, which may include, but is not limited to: a separate secure CPU, a True Random Number Generator (TRNG), and secure storage space.

[0205] Please continue to refer to Figure 1The multi-hardware cryptographic engine system may include a hardware cryptographic engine driver located in the REE kernel layer.

[0206] The hardware cryptographic engine driver is used to call the HCE-REE engine and the HCE-TEE engine.

[0207] For example, such as Figure 2 As shown, the hardware cryptographic engine driver may include an HCE-REE driver for calling the HCE-REE engine and an HCE-TEE driver for calling the HCE-TEE engine.

[0208] Optionally, such as Figure 1 As shown, the multi-hardware cryptographic engine system may also include an inSE operating system (i.e., SEE OS), which is used to call inSE.

[0209] Please continue to refer to Figure 1 The multi-hardware cryptographic engine system may also include cryptographic services located in the hardware abstraction layer.

[0210] The multi-hardware cryptographic engines in this application embodiment can work together to provide the aforementioned cryptographic service (hereinafter referred to as HiCryptoService). This cryptographic service can provide the operating system's SDK (Software Development Kit) interface to provide application developers with the cryptographic services of the multi-hardware cryptographic engine system in this application embodiment.

[0211] like Figure 1 As shown, the cryptographic service can be used to call the kernel-level hardware cryptographic engine driver, and optionally, to call the inSE operating system to control multiple hardware cryptographic engines, thereby providing data encryption and decryption services to applications using the multi-hardware cryptographic engine system of this application embodiment.

[0212] For example, please refer to Figure 2 HiCrypto Service, as software used in conjunction with multiple hardware cryptographic engines, may include HCE-TEE cryptographic service running in TEE, HCE-REE cryptographic service running in REE (Rich Execution Environment), and optionally, inSE cryptographic service running in SEE (Secure Execution Environment).

[0213] The three software components, HCE-TEE, HCE-REE, and inSE, are all pre-installed software within the multi-hardware cryptographic engine system. They can also provide the HUKS (Harmony Universal KeyStore) interface to applications in the REE to provide cryptographic services to the apps.

[0214] For example, the HUKS interface can be Figure 1 It is part of the SDK interface and can be used to provide an interface for applications at the application layer to call the cryptographic services described in the embodiments of this application.

[0215] For example, the HUKS interface may include, but is not limited to, APIs (Application Programming Interfaces) in multiple languages ​​such as C, C++, Java, and JS.

[0216] For example, the HCE-TEE cryptographic service is used to invoke the HCE-TEE driver to enable the HCE-TEE engine to function.

[0217] For example, the HCE-TEE engine can be used to generate or import working keys for an application, and to encrypt those working keys.

[0218] Optionally, the inSE cryptographic service is used to invoke the SEE OS to enable inSE to function.

[0219] For example, inSE can be used to generate or import working keys for an application, and to encrypt those working keys.

[0220] For example, the HCE-REE cryptographic service can be used to receive a call request from an APP to the HUKS interface, and in response to the call request (e.g., a call request for generating or importing a working key), call the HCE-TEE cryptographic service or the inSE cryptographic service. The HCE-TEE cryptographic service or the inSE cryptographic service can respond to the call request, generate or import the application's working key in the HCE-TEE engine or inSE, encrypt the working key within the hardware engine, and return the ciphertext structure of the encrypted working key to the APP.

[0221] For example, the HCE-REE cryptographic service can also be used to receive a call request from an APP to the HUKS interface (which may carry the ciphertext structure), and in response to the call request (e.g., a call request for encrypting or decrypting application data), call the HCE-REE driver to enable the HCE-REE engine to work. The HCE-REE engine can encrypt or decrypt application data based on the ciphertext structure.

[0222] For example, the HCE-REE engine can be used to decrypt the working key ciphertext (i.e., the key ciphertext in this document) generated by the HCE-TEE engine or inSE, and use the decrypted working key plaintext (i.e., the key plaintext in this document) to perform encryption and decryption operations on the application data of the App.

[0223] like Figure 2 As shown, the HCE-REE cryptographic service (HiCrypto CA (Client Application), hereinafter referred to as CA) runs in the REE, and the HCE-TEE cryptographic service (HiCrypto TA (Trusted Application), hereinafter referred to as TA) runs in the TEE. Therefore, HiCrypto CA and HiCrypto TA can run on the ACPU (Application CPU) of the terminal device (e.g., a mobile phone). However, inSE has an independent CPU; therefore, the inSE cryptographic service (HiCrypto SA (Secure Application, referring to the inSE application), hereinafter referred to as SA) runs on the independent CPU of the inSE.

[0224] It should be noted that, Figure 1 and Figure 2 The arrows shown indicate the direction of the request or command invocation. Figure 1 and Figure 2 In this context, the data flow between modules that interact (i.e., have a single arrow) can be bidirectional.

[0225] In addition, Figure 2 In this system, the HCE-TEE cryptographic service, HCE-TEE driver, and HCE-TEE engine all run within the TEE; the App, HUKS interface, HCE-REE cryptographic service, HCE-REE driver, and HCE-REE engine all run within the REE; and the inSE cryptographic service, SEE OS, and inSE all run within the SEE.

[0226] It should be understood that inSE is an optional hardware architecture in multi-hardware cryptographic engine systems, so if... Figure 2 The dashed box indicates that the inSE cryptographic service, SEE OS, and inSE are also optional in the system architecture.

[0227] For example, during the startup phase, the application can trigger a function call request to generate or import a working key to generate or import a key in the HCE-TEE engine or inSE (or import a key in the HCE-REE engine); and without restarting the terminal device, the application can trigger a function call request multiple times to encrypt or decrypt application data, so that the HCE-REE engine can use the generated or imported key to perform multiple encryption and decryption operations on the application data.

[0228] The function interface used to generate the working key can be different from the function interface used to import the working key.

[0229] Additionally, it should be noted that when an app requests encryption or decryption of application data, it can do so through a single-function call or a three-function call.

[0230] In the case of a single function call, the App can carry the data to be encrypted / 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 working key of the App, and use the plaintext working key to perform encryption and decryption operations on the data to be encrypted / decrypted, and return the encryption and decryption results of the application data to the App.

[0231] For the case of a three-part function call:

[0232] The App can call the first function (e.g., CryptoInit()) to pass the ciphertext structure to the HCE-REE engine. The HCE-REE engine can decrypt the ciphertext structure, write the obtained working key plaintext into the Class A register described below, and return a handle to the Class A register to the App. This handle can be used to identify the Class A register containing the working key plaintext.

[0233] The App can call a second function (such as CryptoUpdate()) to pass the handle of the Class A register and the data to be encrypted or decrypted to the HCE-REE engine. The HCE-REE engine can find the Class A register that stores the plaintext of the App's working key based on the handle, 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 or decrypted, and return the encryption and decryption structure of the application data to the App.

[0234] The app can call a third function (such as CryptoFinal()) to pass a handle to a Class A register, so that the HCE-REE engine can release the Class A register that stores the app's working key in plaintext, such as clearing the data in the Class A register pointed to by the handle.

[0235] The App can call the second function multiple times to perform multiple application data encryption and decryption operations.

[0236] In the multi-hardware cryptographic engine system provided in this application embodiment, the multi-hardware cryptographic engine is implemented based on a self-developed SoC platform. The plaintext of the application key only appears within the hardware cryptographic engine, ensuring that the plaintext of all application keys does not leave the hardware. This prevents the plaintext of the application key from being exposed to the ACPU (Application CPU, A core), making it difficult for malicious applications using the ACPU to steal the application's plaintext key, thus improving the security of the application key. Furthermore, the HCE-REE engine can obtain the ciphertext of the application's working key encrypted by the HCE-TEE engine or inSE, and decrypt it to obtain the plaintext of the working key. Additionally, applications in the REE environment can call HiCrypto CA through the SDK interface, directly operating the HCE-REE engine without going through other engines. This allows for encryption and decryption of application data using the plaintext of the working key within the HCE-REE engine. This enables the encryption and decryption process of application data to be implemented within the REE environment without switching to TEE or SEE, reducing path performance loss and improving encryption and decryption performance. Therefore, the multi-hardware cryptographic engine system in this application embodiment can balance high application security and high encryption and decryption performance.

[0237] It should be noted that, Figure 1 The hardware abstraction layer, kernel layer, and components included in the hardware layer shown do not constitute a specific limitation on the multi-hardware cryptographic engine system of the embodiments of this application. In other embodiments of this application, the system may include more or fewer components than shown, or combine some components, split some components, or have different component arrangements.

[0238] for Figure 1 Multiple hardware cryptographic engines within the security subsystem of the SoC. Figure 3 A schematic diagram illustrating the interaction process between multiple hardware cryptographic engines in an embodiment of this application is shown as an example.

[0239] like Figure 3 As shown, considering that the HCE-TEE engine and inSE have some of the same functions, for ease of understanding, the same modules and functions between the HCE-TEE engine and inSE are shown in the same block diagram.

[0240] It should be noted that, in one possible implementation, the SoC's multi-hardware cryptographic engine may include an HCE-REE engine and an HCE-TEE engine. Figure 3 The HCE-TEE engine / inSE module shown is used to represent the HCE-TEE engine.

[0241] In one possible implementation, the SoC's multi-hardware cryptographic engine may include an HCE-REE engine, an HCE-TEE engine, and inSE. Figure 3 The HCE-TEE engine / inSE module shown is used to represent inSE, then in Figure 3 The HCE-TEE engine is not shown.

[0242] It should be noted that, Figure 4a , Figure 8 , Figure 9 The HCE-TEE engine / inSE module shown is related to... Figure 3 The HCE-TEE engine / inSE modules shown represent similar engines, but different hardware engines can be expressed in different implementations.

[0243] like Figure 3 As shown, the security subsystem may include an AO (Always On) register (also known as a SessionKey register), which is hardwired to the HCE-TEE engine, HCE-REE engine, and inSE (in the case of multiple hardware engines including inSE) (a chip-level connection).

[0244] The AO register is written to once during the initialization of the multi-hardware cryptographic engine system. Furthermore, the AO register is not powered off, is not readable by software, and is write-locked, for example, with a size of 256 bits.

[0245] like Figure 3 As shown, the HCE-TEE engine may include TRNG and KM (Key Management) encryption modules.

[0246] For example, TRNG can be used to generate random numbers.

[0247] The encryption algorithms used by the KM encryption module include, but are not limited to, AES (Advanced Encryption Standard, a symmetric encryption algorithm) and SM4 (SM4 algorithm, a symmetric block cipher algorithm), and may also include other symmetric block cipher algorithms with sufficient security strength.

[0248] For example, the KM encryption module can be used to perform encryption operations using the GCM mode of the AES or SM4 algorithm. However, the specific algorithm of the authentication encryption algorithm used by the KM encryption module is not limited to the GCM mode of AES or SM4, and can also be other authentication encryption algorithms.

[0249] Optionally, if the SoC includes inSE, 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.

[0250] like Figure 3 As shown, the HCE-REE engine may include a KM decryption module, a Class A register, and a data encryption / decryption module, such as... Figure 3 As shown by the dashed lines within the HCE-REE engine, the HCE-REE engine optionally includes a Class B register.

[0251] Figure 3 The dashed lines in the diagram are used to represent optional modules and operations of a multi-hardware cryptographic engine.

[0252] For example, the KM decryption module can be used to perform decryption operations using the GCM mode of the AES or SM4 algorithm. Similarly, the specific algorithm used by the KM decryption module in this application is not limited to the GCM mode of AES or SM4, but can be other authentication and decryption algorithms.

[0253] For example, a Class A register is used to set the ciphertext key entering the HCE-REE engine; it is neither readable nor writable by software. It should be noted that the data stored in the Class A register is the plaintext format of the ciphertext key. Figure 3 The key shown is in plaintext.

[0254] For example, the number of Class A registers can be one or more. For instance, the HCE-REE engine includes n Class A registers from Key slot 1 to Key slot n, where n is a positive integer. The specific value of n is not limited, and the number of Class A registers can be flexibly configured according to actual needs.

[0255] For example, a Class B register is used to set the plaintext key entering the HCE-REE engine; it is writable but not readable by software.

[0256] For example, there can be one or more Class B registers, and the specific number can be flexibly configured according to actual needs. When there are multiple Class B registers, each Class B register can be used to store plaintext keys (i.e., plaintext working keys) for different applications. The following explanation uses a single Class B register (e.g., Key slot 0) as an example.

[0257] In addition, such as Figure 3 As shown, the HCE-TEE engine, HCE-REE engine, and inSE can transmit data, instructions, or keys through the shared memory shared by these three hardware cryptographic engines.

[0258] For example, the implementation of shared memory may include, but is not limited to: DDR (DDR SDRAM, Double Data Rate Synchronous Dynamic Random Access Memory) and NVM (Non-volatile memory, memory that does not lose data when power is off or when disconnected).

[0259] for Figure 3 The internal modules of the three hardware cryptographic engines mentioned above can be executed by, respectively, as follows: Figure 2 The three hardware cryptographic engines shown are controlled by their respective software services.

[0260] Specifically, the CA can call the TA, which in turn calls the HCE-TEE driver to enable the HCE-TEE engine or inSE to execute. Figure 3 The process of the HCE-TEE engine execution shown is as follows; alternatively, the CA can call the SA, which in turn calls the SEE OS to enable inSE execution. Figure 3 The process executed by inSE is shown below.

[0261] Additionally, the CA can invoke the HCE-REE driver to enable the HCE-REE engine to execute. Figure 3 The process executed by the HCE-REE engine is shown.

[0262] To describe the technical solution of this application more clearly and concisely, the following text will not elaborate on the cryptographic services of the hardware cryptographic engine, or the specific process of controlling the hardware cryptographic engine through the control driver or the inSE operating system.

[0263] The following is about Figure 3 The working process of each internal module of the hardware cryptographic engine shown is briefly described.

[0264] First, the working process of the internal modules of the HCE-TEE engine is described:

[0265] During the initialization and startup phase of the multi-hardware cryptographic engine system, or during the initialization and startup phase of the host or terminal device where the multi-hardware cryptographic engine system is located, or when the multi-hardware cryptographic engine system is powered on, the TRNG inside the HCE-TEE engine can randomly generate a root key and set the root key directly into the AO register through hard-wired methods such as DMA (Direct Memory Access).

[0266] It should be noted that the root key described in this article is used to represent the encryption key of the application's working key.

[0267] Optionally, in one embodiment, the process performed by the TRNG can be triggered by software, for example, during the BootLoader startup phase of the terminal device, where the BootLoader controls... Figure 2 TA in Figure 2 The TA calls the HCE-TEE driver to trigger the TRNG to implement the above process, thereby improving the flexibility of the root key generation method.

[0268] Considering that during the bootloader phase of the terminal device, i.e., when the multi-hardware cryptographic engine system initializes, the TA calls the HCE-TEE driver to control the TRNG to generate the root key and controls the TRNG to write the root key into the AO register, the root key may enter the TEE's memory during the brief window of the terminal device's bootloader phase. Therefore, to improve root key security, alternatively, in another embodiment, the process of the TRNG generating the root key and setting the generated root key to the AO register can be configured to automatically generate the root key and write the root key to the AO register upon system power-up, without software triggering.

[0269] During the HCE-TEE engine's runtime phase, the KM encryption module within the HCE-TEE engine can read the root key from the AO register and use the root key to encrypt the application's working key plaintext (i.e., Figure 3 The key plaintext (as described in subsequent embodiments) is encrypted, and the encryption result of the key plaintext is sent to shared memory.

[0270] It should be noted that, Figure 3 The plaintext key in the HCE-TEE engine can be imported into the HCE-TEE engine by the application (with or without key encapsulation) or generated by the HCE-TEE engine. This application does not impose any restrictions on this.

[0271] Then, the working process of the internal modules of inSE is described:

[0272] During the initialization and startup phase of the multi-hardware cryptographic engine system, or during the initialization and startup phase of the host or terminal device where the multi-hardware cryptographic engine system is located, or when the multi-hardware cryptographic engine system is powered on, the TRNG inside the HCE-TEE engine can randomly generate a root key and directly set the root key into the AO register through a hard-wired method such as DMA.

[0273] It should be noted that the root key described in this article is used to represent the encryption key of the application's working key.

[0274] Optionally, in one embodiment, the process performed by the TRNG can be triggered by software, for example, during the BootLoader startup phase of the terminal device, where the BootLoader controls... Figure 2 TA in Figure 2 The TA calls the HCE-TEE driver to trigger the TRNG to implement the above process, thereby improving the flexibility of the root key generation method.

[0275] Alternatively, in another embodiment, the process of generating the root key for the TRNG and setting the generated root key to the AO register can be performed automatically by configuring the TRNG during system power-on without software triggering.

[0276] Since inSE has an independent CPU, the root key will not be released into the hardware, regardless of whether TRNG is controlled by software or executed automatically, thus ensuring the security of the root key and, consequently, the security of the application's working key.

[0277] During the inSE runtime, the KM encryption module in inSE can read the root key set by TRNG from the AO register and use the root key to process the application's working key plaintext (i.e., Figure 3 The key plaintext (as described in subsequent embodiments) is encrypted, and the encryption result of the key plaintext (which may be the ciphertext structure described below, or the ciphertext result of the key plaintext) is sent to shared memory.

[0278] It should be noted that, Figure 3 The plaintext key in inSE can be imported into inSE by the application (with or without key encapsulation) or generated by inSE. This application does not impose any restrictions on this.

[0279] Optionally, in scenarios where the SoC includes inSE, considering that the security of the HCE-TEE engine is lower than that of inSE, in order to improve security, it can be done according to... Figure 2 The process shown involves CA calling SA to trigger inSE execution. Figure 3 The process described above.

[0280] For example, in scenarios where the SoC does not include inSE, it can be done according to Figure 2 The process shown involves the CA calling the TA to trigger the HCE-TEE engine to execute. Figure 3 The process described above is designed to ensure a balance between performance and safety.

[0281] Finally, the working process of the internal modules of the HCE-REE engine is described:

[0282] The KM decryption module can be used to read the encrypted result of the key plaintext written by the inSE or HCE-TEE engine from shared memory, and to read the root key from the AO register, and to decrypt the encrypted result using the root key to obtain the key plaintext, and to send the key plaintext to the Class A register.

[0283] The data encryption / decryption module can be used to read the plaintext key from a Class A register; and to use the plaintext key to encrypt the plaintext data and generate ciphertext data; or to use the plaintext key to decrypt the ciphertext data and generate plaintext data.

[0284] Optionally, the HCE-REE engine in this embodiment of the application reserves a channel for setting the plaintext of the working key in a Class B register. This allows applications in the REE to pass the plaintext key to shared memory, and the CA can control the HCE-REE driver to read the plaintext key imported by the application from shared memory and write it to the Class B register. Then, the data encryption / decryption module in the HCE-REE engine can read the plaintext key from the Class B register and use the encrypted key to perform data encryption / decryption operations without switching the runtime environment to TEE or SEE, thus improving data encryption / decryption performance.

[0285] exist Figure 3 In the SoC, an AO register (unreadable, write-locked) hardwired connection (chip-level connection) can be provided for use by multiple hardware cryptographic engines. This allows the application's working key to be protected by a true random number randomly generated by the HCE-TEE engine or TRNG in inSE each time the terminal device is powered on when it is transmitted between multiple hardware cryptographic engines. This enables the working key to be transmitted securely between multiple hardware cryptographic engines, and the plaintext of the working key never leaves the hardware, thus improving key security.

[0286] In addition, apart from the secure AO register channel, the design of multiple hardware cryptographic engines can effectively decouple them and allow them to operate independently without affecting each other, which is conducive to maximizing performance.

[0287] In the above embodiments, the AO register can be used to store the root key (the encryption and decryption key of the application's working key), so that when the HCE-TEE engine, HCE-REE engine, and inSE transmit the root key through the AO register, the ACPU is not visible to it, achieving a level of security with hardware isolation.

[0288] The working process of the multi-hardware cryptographic engine system in this application embodiment will be described in detail below in combination with different application scenarios.

[0289] Key generation scenario.

[0290] Figure 4aAn exemplary flowchart of a multi-hardware cryptographic engine system in a key generation scenario is shown.

[0291] Figure 4b An exemplary timing diagram of the key encryption process of a multi-hardware cryptographic engine system is shown.

[0292] exist Figure 4a The document describes the system workflow of combining a key authentication scheme with the system architecture of the embodiments of this application. It should be noted that, in other application scenarios, the multi-hardware cryptographic engine system of the embodiments of this application can also include [specific hardware cryptographic engine components] according to business needs. Figure 4a The key authentication scheme described herein will not be elaborated on in detail for each scenario in the following text. Please refer to the authentication scheme described in this embodiment.

[0293] For example, the authentication encryption algorithm used in the key authentication scheme of this embodiment is GCM (Galois / Counter Mode, a block cipher algorithm mode), but this application does not impose specific restrictions on the authentication encryption algorithm.

[0294] For example, Figure 4a The authentication encryption algorithm used by the KM encryption module and KM decryption module can be GCM mode of AES or SM4 algorithm.

[0295] SM4's GCM mode can be used for authentication encryption to ensure the integrity of plaintext or other authenticated content. When encrypting, the following parameters may be included, but are not limited to: IV value, TAG, and optionally additional authentication data (AAD).

[0296] For example, AAD data can be used for authentication and anti-counterfeiting.

[0297] For example, in the GCM mode of AES, the length of the IV value can be 12 bytes, but this application does not limit the length of the IV value.

[0298] For example, TAG is a message authentication code in GCM mode, used to verify the integrity of encrypted data and AAD. The length of TAG in GCM mode is at least 12 bytes, preferably 16 bytes.

[0299] While encrypting the application's sensitive data (i.e., the plaintext data of the application to be encrypted), this system can also protect the integrity of data that needs to be protected but does not need to be confidential (such as program context data).

[0300] The following is combined Figure 2 Come to Figures 4a-4c Describe:

[0301] like Figure 4a As shown, the HCE-TEE engine and inSE have similar internal module functions when used for password generation; therefore, in Figure 4a The internal modules of the two hardware cryptographic engines are described in a block diagram for the reader's convenience. Figure 4b and Figure 4c Executed using the HCE-TEE engine Figure 4a The key generation and encryption process shown is illustrated using an example. However, it should be noted that inSE execution... Figure 4a The process shown is similar to that executed by the HCE-TEE engine, and can be referenced. Figure 4b and Figure 4c The descriptions will not be repeated hereafter.

[0302] Please refer to Figure 4a and Figure 4b The process of this embodiment may include the following steps:

[0303] S101, TA generates the root key by calling the HCE-TEE driver to control the HCE-TEE engine.

[0304] S103, the HCE-TEE engine generates the root key and writes the root key into the AO register.

[0305] For example, during the startup phase of a terminal device equipped with this system, the TRNG can generate a random number as the root key and write it to the AO register in a hard-wired manner, such as... Figure 3 The process described in the embodiments can be controlled by software (the implementation of S101 and S103 here is software controlled) or executed automatically by TRNG, and this application does not limit it in this regard.

[0306] Optionally, when the application's root key is written to the AO register under software control, the root key can be not only a random number generated by the TRNG, but also a root key derived from the hardware root key according to its derived components. For example, it can be... Figure 9 The hardware root key shown in (1) is derived (the derived component may be the same as or different from the derived component in 9(1)) to obtain the root key to be written into the AO register, etc. This application does not restrict the specific generation method of the root key to be written into the AO register.

[0307] S201, the App triggers a key generation request by calling the HUKS interface and sends the key generation request to the CA.

[0308] For example, after the app is launched, such as Figure 2As shown, the App can call the HUKS interface to call CA.

[0309] This application describes a single-step function call. Therefore, the first encryption request triggered by the App may include, but is not limited to: data to be encrypted / decrypted (taking data to be encrypted as an example, the data to be encrypted is...). Figure 4a Information (in plaintext) of the HCE-REE engine, optionally including AAD parameters.

[0310] For example, AAD parameters may include, but are not limited to: the App's application context data (including but not limited to the package name), key parameters of KeyAlias ​​and the App's working key, etc.

[0311] S202, in response to the key generation request, the CA sends a first call request to the TA.

[0312] S203, TA can respond to the first call request by calling the HCE-TEE driver to control the HCE-TEE engine to generate and encrypt the working key.

[0313] Optionally, during S202 and S203, the AAD parameter in the first call request can be written to the HCE-TEE engine via software control.

[0314] S204, the HCE-TEE engine generates the working key (i.e. Figure 4a The key in plaintext is used to obtain authentication parameters.

[0315] For example, such as Figure 4a As shown, the TRNG of the HCE-TEE engine can generate random numbers as working keys, i.e., plaintext keys.

[0316] Of course, this application does not limit the method of generating plaintext keys by the HCE-TEE engine to TRNG; other methods can also be used, and the specific method can be flexibly configured as needed.

[0317] For example, the authentication parameters here may include, but are not limited to: the IV value generated by TRNG in the HCE-TEE engine and the AAD parameters passed in by the application.

[0318] The S205 HCE-TEE engine can read the root key from the AO register and use the root key to encrypt the plaintext key to obtain the ciphertext structure.

[0319] For example, such as Figure 4aAs shown, the KM encryption module of the HCE-TEE engine can use GCM mode to encrypt the data to be encrypted (including the plaintext key) using the IV value and the root key read from the AO register, generating the ciphertext key; and the KM encryption module calculates the TAG from the ciphertext key and AAD. Finally, the ciphertext structure (including IV, ciphertext key, TAG, and AAD parameters) is obtained.

[0320] S2061, the HCE-TEE engine writes the encrypted structure to shared memory.

[0321] For example, shared memory may include a storage region that loses data when power is off (e.g., DDR) and a storage region that does not lose data when power is off (e.g., NVM).

[0322] For example, such as Figure 4a As shown, the KM encryption module can write the generated ciphertext structure into DDR.

[0323] For example, considering that data in DDR will be lost when power is off, such as Figure 4a As shown, the HCE-TEE engine is also configured with a HUK (Hardware Unique Key) encryption module. The HUK encryption module can be configured with a hardware unique key (i.e., the hardware root key). The HUK encryption module can then use a key derived from the hardware root key to encrypt the plaintext key and generate ciphertext key. Here, the ciphertext of the plaintext key is named ciphertext key for distinction. Figure 4a The key ciphertext within the DDR.

[0324] 'Key' is used to indicate the use of Figure 4a The HUK encryption module shown uses a key derived from the hardware root key as the encryption key to encrypt the plaintext key, resulting in the working key ciphertext.

[0325] And key ciphertext (e.g.) Figure 4a The key ciphertext in the DDR is used to represent the working key ciphertext after encrypting the key plaintext with the root key in the AO register as the encryption key.

[0326] This application provides two types of keys for encrypting and decrypting the plaintext of the working key: one is a root key randomly generated by TRNG, and the other is a key derived from the hardware root key. Using the random number generated by TRNG and written into the AO register as the root key provides higher security.

[0327] For example, such as Figure 4aAs shown, the HUK encryption module can write the generated key ciphertext into the NVM secure storage area, so that even after power failure, the HUK encryption module can still read the working key ciphertext from the NVM secure storage area for use in encrypting and decrypting application data, thereby improving the reliability of data encryption and decryption.

[0328] Alternatively, in one implementation, such as Figure 4a As shown, the HUK encryption module is not configured with authentication encryption algorithms such as GCM; it only uses a non-authentication encryption algorithm. Therefore, for authentication, if the system loses power, the HUK encryption module can read the ciphertext key from the NVM secure storage area and decrypt it using the hardware-unique key to obtain the plaintext key. This plaintext key is then encrypted in GCM mode by the KM encryption module and written to DDR.

[0329] Alternatively, in another implementation, the HUK encryption module can also be configured with authentication encryption algorithms including but not limited to GCM, so that the ciphertext structure generated by the HUK encryption module also contains authentication data (e.g., including IV, key ciphertext, TAG, AAD, etc.). After a system power failure, the ciphertext structure of the NVM secure storage area can be directly used to write to the HCE-REE engine.

[0330] Optionally, the write address of the encrypted structure in shared memory can be configured by CA as a parameter in the first call request of S202, and then passed to the HCE-TEE driver via S203 for control of the HCE-TEE engine.

[0331] Alternatively, the write address of the ciphertext structure in shared memory can be configured by the TA as a parameter in S203. After S205, the TA can return the address information of the ciphertext structure to the CA.

[0332] After generating a ciphertext structure bound to a specific program and its key, the ciphertext structure can be returned to the App as a handle.

[0333] Following S2061, the process also includes: S2062, where the CA, in response to the key generation request, returns the address information of the App's ciphertext structure in shared memory to the App.

[0334] For example, an app can read a ciphertext structure from shared memory based on this address information, which can be carried when requesting encryption or decryption of application data.

[0335] The application can trigger a key generation request to initiate execution. Figure 4bThe process involves encrypting the application's working key and returning the ciphertext structure of the working key as a response to the application. Without restarting the terminal device, the application can use this ciphertext structure to request encryption or decryption of application data via single-step or segmented function calls.

[0336] 1-1. One-step function call scenario.

[0337] exist Figure 4c In the example shown, an App uses a single function call to illustrate the timing diagram of the key usage process in a multi-hardware cryptographic engine system.

[0338] like Figure 4c As shown, the App uses... Figure 4b The process of requesting encryption of application data, which involves the ciphertext structure returned by the process, may include:

[0339] S215, the App triggers a data encryption request by calling the HUKS interface;

[0340] For example, the App can write the ciphertext structure into shared memory and include the address information of the ciphertext structure in the shared memory in the data encryption request.

[0341] For example, the App can write plaintext data into shared memory and include the address information of the plaintext data in the shared memory in the data encryption request.

[0342] S207, the CA can respond to data encryption requests by calling the HCE-REE driver to control the HCE-REE engine to read plaintext data from the App.

[0343] The S208 HCE-REE engine reads plaintext data from shared memory.

[0344] For example, the information of the plaintext data in the data encryption request can be the address information of the plaintext data (also known as the source address). The above-mentioned App in the REE environment can write the plaintext data into shared memory and carry the address of the plaintext data in shared memory (i.e., the source address) into 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.

[0345] S209, in response to a data encryption request, the CA controls the HCE-REE engine to read the ciphertext structure by calling the HCE-REE driver.

[0346] For example, the CA can obtain the address information of the ciphertext structure of the App 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 engine to read the ciphertext structure from the shared memory.

[0347] The S210 HCE-REE engine reads the ciphertext structure from shared memory.

[0348] For example, such as Figure 4a As shown, the KM decryption module in the HCE-REE engine can read the application's ciphertext structure (including IV, key ciphertext, TAG, and AAD parameters) from DDR.

[0349] S211, the HCE-REE engine reads the root key from the AO register, uses the root key to decrypt the ciphertext structure, and obtains the plaintext key.

[0350] For example, such as Figure 4a As shown, 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.

[0351] For example, the KM decryption module can be used to calculate TAG' and compare it with the TAG read from DDR. If they are the same, it means that the key plaintext and AAD are complete, so as to achieve application authentication and anti-counterfeiting.

[0352] The KM decryption module can calculate TAG' from the key ciphertext and AAD read from DDR, and compare TAG' with the TAG read from DDR. If they are the same, the authentication is successful; otherwise, the authentication fails.

[0353] If authentication is successful, 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 and obtain the key plaintext.

[0354] After the KM decryption module successfully decrypts the ciphertext of the key and successfully authenticates it, the plaintext of the key can be written into the Class A register mentioned above.

[0355] By setting authentication parameters when encrypting the working key of the app, authentication and anti-spoofing of upper-layer applications can be supported, preventing other applications from stealing the working key to decrypt the app's data.

[0356] S212, the HCE-REE engine uses the plaintext key to encrypt the plaintext data, thus obtaining the ciphertext data.

[0357] For example, such as Figure 4aAs shown, the data encryption / decryption module in the HCE-REE engine can use the plaintext key to encrypt the plaintext data of the App, obtaining ciphertext data. The encryption algorithm can include, but is not limited to, AES, SM4, etc.

[0358] S213, the HCE-REE engine writes encrypted data to shared memory.

[0359] For example, the data encryption request triggered by the App in S215 may also include a target address for writing ciphertext data.

[0360] The HCE-REE engine can respond to the data encryption request by writing the encrypted data to the target address in shared memory.

[0361] It should be noted that when the HCE-REE engine executes steps S211, S212, and S213, the CA responds to the data encryption request by calling the HCE-REE driver to control the execution of the HCE-REE engine.

[0362] S214, the App directly reads encrypted data from shared memory.

[0363] For example, since the target address is set by the App, the App can directly read encrypted data from the target address without going through the password service of this application embodiment.

[0364] If the terminal device is not restarted, the app can execute the request to encrypt or decrypt data again. Figure 4c The process involves the App sending its encrypted structure when triggering the request, allowing the CA to authenticate and decrypt the encrypted structure, and then use the authenticated and decrypted key plaintext for data encryption and decryption.

[0365] For example, such as Figure 4c As shown, if the terminal device is not restarted and the App triggers the aforementioned data encryption request again, the App can transmit the encrypted structure (in the execution) Figure 4b The process involves writing the encrypted structure returned by the CA to the App. Figure 4a The shared memory is used, and the address information of the ciphertext structure in the shared memory is carried as a parameter in the data encryption request in S215. Then, the CA can use the address information of the ciphertext structure passed by the App to call the HCE-REE driver to control the HCE-REE engine to read the ciphertext structure from the shared memory for data encryption and decryption in the REE environment.

[0366] In the above Figure 4aThe document describes the process by which the HCE-TEE engine or inSE generates working keys for an application in a key generation scenario, the process of encrypting the generated working keys, and the process by which the HCE-TEE engine uses the encrypted working keys to encrypt and decrypt application data through a single function call from the App.

[0367] exist Figure 4b The document describes the process by which the HCE-TEE engine or inSE generates working keys for an application in a key generation scenario, as well as the process of encrypting the generated working keys.

[0368] exist Figure 4c The document describes how an App sends encryption / decryption requests to the HCE-REE engine based on the ciphertext structure generated by the HCE-TEE engine or inSE through a single function call. The HCE-REE engine can then use this ciphertext structure to encrypt and decrypt the application data.

[0369] In this process, the App only needs to trigger a function call once for the system of this embodiment to encrypt and decrypt data for the App. Within a single boot of the terminal device (without restarting), the App's working key can remain unchanged. Therefore, after the App triggers a key generation request, the system can return the generated ciphertext structure to the App. When the App triggers data encryption / decryption through a single function call request, the App can use the ciphertext structure bound to the App and its working key to operate the HCE-REE engine for data encryption and decryption via CA and HCE-REE drivers. This eliminates the need to switch to TEE or SEE for data encryption and decryption, allowing the ciphertext structure to be used in the REE environment for data encryption and decryption, effectively reducing path performance loss and improving data encryption / decryption performance.

[0370] Moreover, every time the App triggers data encryption / decryption through a single function call request, the HCE-REE engine authenticates and decrypts the ciphertext structure passed in by the App, and uses the authenticated and decrypted working key to perform data encryption / decryption within the HCE-REE engine. This ensures that the working key achieves hardware-level security during use, and the use of the working key is completed only in the REE, without needing to switch to TEE or SEE, thus not affecting encryption / decryption performance.

[0371] For example, in the multi-hardware cryptographic engine system of this application embodiment, when performing data encryption and decryption, the HCE-REE engine in the REE environment can use the root key in the AO register to decrypt and authenticate the key ciphertext without the participation of the HCE-TEE engine and inSE. Then, the key plaintext that has passed decryption and authentication is written to the Class A register to perform encryption and decryption operations on the application data that needs to be encrypted and decrypted. This can avoid switching the execution environment from REE to TEE or SEE, effectively reduce path performance loss, and further improve the data encryption and decryption performance.

[0372] Understandably, within a single boot cycle, the app only needs to trigger a key generation request once to execute. Figure 4b This process ensures that the App does not need to execute the command again whenever it needs to encrypt or decrypt data. Figure 4b The process only requires a single function call to trigger execution. Figure 4c The data encryption and decryption can be performed using the same process.

[0373] In a single-function call scenario, the HCE-REE engine in this embodiment of the application needs to reread the ciphertext structure passed by the App from shared memory such as DDR each time it performs data encryption and decryption. After the ciphertext structure is decrypted and authenticated by the KM decryption module, the data encryption and decryption can be performed. This can authenticate the identity of the App and prevent other applications from stealing the working key of this App to perform data encryption and decryption.

[0374] Considering the chip area, in a single-function call scenario, each data encryption / decryption operation involves rewriting the plaintext key into a class A register. Therefore... Figure 4a The number of Class A registers can be 1 to reduce chip area.

[0375] It should be noted that in the context of a single-function call, Figure 4a The ciphertext structure in the DDR (examples may include IV, key ciphertext, TAG, AAD) is visible only to the application under the protection mechanism of the Linux kernel, and cannot be seen by other applications, thereby preventing other applications from encrypting or decrypting the data of this application.

[0376] 1-2. Three-stage function call scenario.

[0377] exist Figure 5 The diagram illustrates the workflow of a multi-hardware cryptographic engine system's cryptographic usage process, using an App's three-stage function call as an example.

[0378] Figure 6 and Figure 7A timing diagram illustrating the key usage process of a multi-hardware cryptographic engine system in a three-stage function call scenario is shown.

[0379] Figure 5 (1) and Figure 6 This illustrates the process of the first function call in a three-stage function call scenario.

[0380] Reference Figure 4a and Figure 4b According to the description of the embodiments, the App can obtain the ciphertext structure of the working key generated by the HCE-TEE engine or inSE by triggering a key generation request. The App can then use this information to... Figure 4b The encrypted structure returned by the process calls the first function (e.g., CryptoInit()) to pass the encrypted structure to the HCE-REE engine. The HCE-REE engine can decrypt the encrypted structure, write the obtained working key plaintext into a Class A register, and return a handle to the Class A register to the App. This handle can be used to identify the Class A register containing the working key plaintext.

[0381] like Figure 5 (1) and Figure 6 As shown, the processing of the first function may include:

[0382] S301, the App triggers the first function request by calling the HUKS interface.

[0383] For example, the first function request may include Figure 4b The encrypted structure returned to the App.

[0384] The App can write the encrypted structure into shared memory and carry the address information of the encrypted structure in the shared memory into the first function request.

[0385] For example, the function interface of the first function request could be CryptoInit().

[0386] For example, such as Figure 5 As shown in (1), the App can write the ciphertext structure of the working key (e.g., including IV, key ciphertext, TAG, AAD parameters) into the DDR.

[0387] S209, in response to the first function request, the CA controls the HCE-REE engine to read the ciphertext structure by calling the HCE-REE driver.

[0388] The S210 HCE-REE engine reads the ciphertext structure from shared memory.

[0389] For example, such as Figure 5As shown in (1), the KM decryption module in the HCE-REE engine can read the application's ciphertext structure (including, for example, IV, key ciphertext, TAG, and AAD parameters) from DDR.

[0390] S211, the HCE-REE engine reads the root key from the AO register, uses the root key to decrypt the ciphertext structure, and obtains the plaintext key.

[0391] For example, such as Figure 5 As shown in (1), 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.

[0392] For specific authentication solutions, please refer to the above-mentioned single-function call scenario. Figure 4c The specific description of S211 will not be repeated here.

[0393] S302, the HCE-REE engine writes the key in plaintext to a Class A register.

[0394] For example, such as Figure 5 As shown in (1), after the KM decryption module successfully decrypts the key ciphertext and successfully authenticates it, the key plaintext can be written into the Class A register mentioned above.

[0395] like Figure 5 As shown in (1), there are n Class A registers, including Key slot 1 to Key slot n, where n is a positive integer greater than 1. For example, the KM decryption module writes the plaintext key into Key slot 1.

[0396] It should be noted that when the HCE-REE engine executes S211 and S302, the HCE-REE driver is controlled by the CA, and the HCE-REE driver then controls the HCE-REE engine.

[0397] For example, in response to the first function request, the HCE-REE driver can select a target key slot register from n Class A registers to be allocated to the App, thereby controlling the KM decryption module to write the App's key plaintext into the target key slot register, for example... Figure 5 Key slot 1 in (1).

[0398] Additionally, it should be noted that each Class A register can be used to store one key plaintext.

[0399] When allocating Class A registers for a key in plaintext for an App, the HCE-REE driver can dynamically allocate Class A registers. For example, it can allocate an empty Class A register that does not store any data. Alternatively, it can allocate Class A registers according to the application. For example, each application can have a unique Class A register. Or, it can allocate Class A registers according to the application's business type. For example, different business types of the same application have different working keys, so the working keys of different businesses of the same application can be written to different Class A registers respectively.

[0400] The S303 HCE-REE driver can respond to the first function request by returning the handle information of the Class A registers to the App via CA.

[0401] For example, Figure 5 (1) The KM decryption module, controlled by the HCE-REE driver, writes the plaintext key into Key slot 1 and then returns a message to notify the HCE-REE driver that the data was successfully written to the register. The HCE-REE driver can then send the handle used to identify Key slot 1 in the HCE-REE engine to the App via the CA.

[0402] It should be noted that a handle to a Class A register can uniquely identify a Class A register.

[0403] Optionally, in one implementation, the handle can be a random number of a certain length, which may include a flag bit for identifying the Class A register and data bits (wherein the data bits are random data). When responding to a data encryption / decryption request from an App, the HCE-REE driver can determine the Class A register through the flag bit of the handle in the encryption / decryption request. Setting the data bits in the handle can increase the difficulty of stealing the working key.

[0404] Alternatively, in another implementation, the handle may not include the aforementioned flag bits and may include a random number. The HCE-REE driver can then store the correspondence between handles to Class A registers and the identification information of Class A registers. This correspondence can be used during the working key usage phase to determine the Class A register storing the plaintext key.

[0405] In addition, this application does not restrict the timing of the generation of the handle to the Class A register by the HCE-REE driver. The handle that can identify the target key slot register can be generated after the HCE-REE driver responds to the first function request and allocates the target key slot register to the App. Alternatively, the handle that can identify the target key slot register can be generated after the KM decryption module writes the plaintext key to the target key slot register.

[0406] go through Figure 5 (1) and Figure 6 The process involves the application triggering a call request for the first function, which configures the application's working key in the Class A register of the HCE-REE engine and returns the handle of the Class A register to the application for subsequent requests to encrypt and decrypt request data.

[0407] Figure 5 (2) and Figure 7 This illustrates the process of the second function call in a three-stage function call scenario.

[0408] During the second function call, the App can call the second function (e.g., CryptoUpdate()) to pass the handle of the Class A register and the data to be encrypted / decrypted to the HCE-REE engine. The HCE-REE engine can find the Class A register that stores the plaintext of the App's working key based on the handle, 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 / decrypted, and return the encryption / decryption structure of the application data to the App.

[0409] like Figure 5 (2) and Figure 7 As shown, the processing of the second function may include:

[0410] S401, the App triggers a second function request by calling the HUKS interface and sends the second function request to the CA.

[0411] For example, in Figure 6 After S303, the App can receive handle information to identify Key slot 1, and then the App can trigger a second function request according to business needs.

[0412] For example, the second function request may include, but is not limited to: data to be encrypted (e.g., Figure 5 (2) The source address of the plaintext data is used to identify the handle information of the Key slot 1.

[0413] S402, the CA can respond to the second function request by calling the HCE-REE driver to control the HCE-REE engine to read the plaintext data (i.e., the data to be encrypted) of the App.

[0414] The S208 HCE-REE engine reads plaintext data from shared memory.

[0415] For example, the second function request may carry the address information (also known as the source address) of the plaintext data. The aforementioned App in the REE environment can write the plaintext data into shared memory and carry the address of the plaintext data in shared memory (i.e., the source address) into the second function request, so that... Figure 5 (2) The data encryption and decryption module in the HCE-REE engine can be controlled by the HCE-REE driver to read plaintext data from the source address.

[0416] S403, CA can also respond to a second function request and control the HCE-REE driver to determine the target register based on the handle information.

[0417] For example, if the second function request carries a handle for identifying the Class A register Key slot 1, such as a handle including flag bits and data bits, then the HCE-REE driver can determine that the target register is the Class A register Key slot 1 based on the flag bits in the handle, thereby controlling the HCE-REE engine to execute S404.

[0418] The S404 HCE-REE engine can read the plaintext key from the target register.

[0419] For example, such as Figure 5 As shown in (2), the data encryption and decryption module in the HCE-REE engine can obtain the handle of the Key slot passed by the App through the HCE-REE driver control, and then read the plaintext key from Key slot 1 based on the handle of the Key slot.

[0420] S212, the HCE-REE engine uses the plaintext key to encrypt the plaintext data, thus obtaining the ciphertext data.

[0421] For example, such as Figure 5 As shown in (2), the data encryption / decryption module in the HCE-REE engine can use the plaintext key to encrypt the plaintext data of the App, obtaining ciphertext data. The encryption algorithm can include, but is not limited to, AES, SM4, etc.

[0422] S213, the HCE-REE engine writes encrypted data to shared memory.

[0423] For example, the second function request triggered by the App in S401 may also include a target address for writing ciphertext data.

[0424] The HCE-REE engine can respond to the second function request by writing the encrypted data to the target address in shared memory.

[0425] It should be noted that when the HCE-REE engine executes steps S404, S212, and S213, the CA can also control the execution of the HCE-REE engine by calling the HCE-REE driver in response to the second function request.

[0426] S214, the App directly reads encrypted data from shared memory.

[0427] For example, since the target address is set by the App, the App can directly read encrypted data from the target address without going through the password service of this application embodiment.

[0428] Optionally, such as Figure 5 As shown in (2), the data encryption / decryption module may include m data encryption / decryption modules, where m is a positive integer greater than 1. m and n may be the same or different, and this application does not impose any restrictions on this. The m data encryption / decryption modules have the same function, but the algorithms they use (including but not limited to AES and SM4) may be different.

[0429] For example, the m data encryption and decryption modules may include m1 data encryption and decryption modules using the AES algorithm and m2 data encryption and decryption modules using SM4, where m = m1 + m2. In this way, the HCE-REE engine can support switching between Chinese national cryptographic and international dual-algorithm systems.

[0430] When the HCE-REE engine executes multiple data encryption / decryption tasks simultaneously, m data encryption / decryption modules can operate in parallel to perform these tasks, supporting the use of multiple working keys. For example, these parallel encryption / decryption tasks may involve different applications or different services within the same application. The HCE-REE engine can improve data encryption / decryption performance through a multi-core approach with multiple data encryption / decryption modules. Furthermore, by setting up multiple Class A registers in the HCE-REE engine, when any of the m data encryption / decryption modules switches between encryption / decryption tasks, it needs to switch the plaintext key used. This can be achieved simply by switching the identifier (e.g., index) of the Class A register read by the data encryption / decryption module, thus reducing the key switching overhead of the data encryption / decryption modules through the use of multiple Class A registers.

[0431] In the above Figure 5 (2) and Figure 7 In the embodiments described, the process of encrypting and decrypting data using a working key is described. The App can trigger the second function request multiple times to perform multiple encryption and decryption operations on the application data.

[0432] The process of the third function call in a three-stage function call scenario is not shown in the attached figure.

[0433] In execution Figure 7 After the initial process, when the App no ​​longer needs to perform data encryption / decryption, it can trigger a third function request (e.g., CryptoFinal()) by calling the HUKS interface. This third function request can carry a handle to identify Key slot 1 of the Class A register, allowing the HCE-REE engine to clear the Class A register pointed to by the handle. Figure 5 (2) The data in Keyslot 1 is used to release a Class A register resource.

[0434] In the above Figures 5-7 In the embodiment, the process of encrypting application data by the App through a three-stage function call is described.

[0435] In the above embodiment, by triggering the first function call request through the application, the application's working key can be configured in the Class A register of the HCE-REE engine, and a handle identifying the Class A register is returned to the application. Then, without restarting the terminal device, when the application needs to perform data encryption and decryption multiple times, the application can trigger the second function call request multiple times, carrying the handle in each second function call request. This allows the HCE-REE engine to use the plaintext key in the Class A register identified by the handle for application data encryption and decryption. Compared to a single-stage function call scenario, in a segmented function call scenario, the HCE-REE engine does not need to read the ciphertext structure identifying the application and working key from shared memory each time it performs application data encryption and decryption, nor does it need to authenticate and decrypt the ciphertext structure each time. This significantly improves the data encryption and decryption performance of the HCE-REE engine.

[0436] In the key generation scenario of the above embodiments, if inSE is used to generate the working key of the application, since inSE has an independent on-chip CPU, the working key plaintext (i.e., key plaintext) can be kept entirely within the hardware and the key plaintext is not visible to the ACPU, achieving a pure hardware isolation level and improving the security of the working key.

[0437] In the key generation scenario of the above embodiments, if the HCE-TEE engine is used to generate the working key of the application, the working key plaintext may enter the TEE memory within a short time window of generating the working key plaintext, but the working key plaintext can be kept out of the TEE throughout the process, thus achieving the TEE security level.

[0438] Key import scenario.

[0439] 2-1. Scenarios where keys are imported into the HCE-TEE engine or inSE without encapsulation.

[0440] This key is imported into the HCE-TEE engine or inSE without encapsulation. It is used to express that the application's working key is imported into the HCE-TEE engine or inSE in plaintext by the application.

[0441] It is understandable that in scenarios where the key is imported into the HCE-TEE engine or inSE without encapsulation, the process described in the above embodiments of encrypting the plaintext of the application's working key to obtain the ciphertext structure and returning it to the App, as well as the process of the App using a one-piece or three-piece call to enable the HCE-TEE engine to encrypt and decrypt application data through the ciphertext structure, are also applicable. The principle is the same and will not be elaborated here.

[0442] Figure 8 An example is shown in the flowchart of a multi-hardware cryptographic engine system in a scenario where keys are imported without encapsulation.

[0443] exist Figure 8 The document describes the process by which the HCE-TEE engine or inSE encrypts the working key imported by the application in a scenario where the key is imported without encapsulation, and how the HCE-TEE engine uses the encrypted working key to encrypt and decrypt application data through a single function call from the App.

[0444] contrast Figure 4a and Figure 8 It can be seen that the execution process of the multi-hardware cryptographic engine system is basically the same between the scenario of importing keys without encapsulation into the HCE-TEE engine or inSE engine and the key generation scenario. The difference lies in the following: In the key generation scenario, the application's working key plaintext (i.e., the key plaintext) is generated by the TRNG within the HCE-TEE engine or inSE. In the scenario of importing keys without encapsulation into the HCE-TEE engine or inSE engine, the application's key plaintext is not generated by the TRNG within the HCE-TEE engine or inSE, but is indirectly imported into the HCE-TEE engine or inSE by the App. Regarding... Figure 8 For details, please refer to Figure 4a A detailed description of it is not required here.

[0445] For example, when the App imports the plaintext key into the HCE-TEE engine, it combines... Figure 2 and Figure 8 As can be seen, the App can call the CA by calling the HUKS interface, the CA then calls the TA, and the TA writes the plaintext key passed by the App into the HCE-TEE engine by calling the HCE-TEE driver.

[0446] For example, when the App imports the plaintext key into inSE, it combines... Figure 2 and Figure 8 As can be seen, the App can call the CA by calling the HUKS interface, the CA then calls the SA, and the SA writes the plaintext key passed by the App into inSE by calling SEE OS.

[0447] For example, in Figure 4b The diagram illustrates a timing diagram of a key encryption process in a key generation scenario.

[0448] In the scenario described in this application embodiment where the key is imported into the HCE-TEE engine without encapsulation, the multi-hardware cryptographic engine system can be based on... Figure 4b The described timing diagram is used to encrypt the imported working key.

[0449] It is important to note that when... Figure 4b In the context of this embodiment, in Figure 4b In S201, the App triggers a key import request by calling the HUKS interface. This key import request, compared to the parameters in the key generation request, can further include the plaintext key. Furthermore, in... Figure 4b In the context of this embodiment, in Figure 4b In S203 and S204, the TA only needs to control the HCE-TEE engine through the HCE-TEE driver to encrypt the plaintext key passed in the key import request, without needing to control the HCE-TEE engine to generate the working key.

[0450] In the above Figure 4b Except for the differences mentioned above, the contents described in the embodiments can all be applied to the scenario of importing unencapsulated keys into the HCE-TEE engine as described in the embodiments of this application.

[0451] exist Figure 4c In the example shown, an App uses a single function call to illustrate the timing diagram of the key usage process in a multi-hardware cryptographic engine system.

[0452] For example, in the scenario of unencapsulated key import into the HCE-TEE engine described in the embodiments of this application, the multi-hardware cryptographic engine system can be based on Figure 4c The sequence diagram described is used for encrypting application data. For the specific workflow of the multi-hardware cryptographic engine, please refer to [link / reference needed]. Figure 4c The description will not be repeated here.

[0453] In scenarios where keys are imported into the HCE-TEE engine or inSE without encapsulation, the HCE-TEE engine or inSE can encrypt the plaintext key imported by the application and return the generated ciphertext structure to the App. When the App needs to encrypt or decrypt application data, it can trigger a function call to utilize the HCE-REE engine for data encryption and decryption. Within a single boot of the terminal device (without reboot), the App's working key can remain unchanged. Therefore, after the App triggers a key import request, the system can return the generated ciphertext structure to the App. When the App triggers data encryption and decryption through a single function call request, the App can use the ciphertext structure bound to the App and its working key to operate the HCE-REE engine for data encryption and decryption via CA and HCE-REE drivers. This eliminates the need to switch to TEE or SEE for data encryption and decryption, allowing the ciphertext structure to be used for data encryption and decryption within the REE environment, effectively reducing path performance loss and improving data encryption and decryption performance.

[0454] Furthermore, when using the application's ciphertext structure to encrypt and decrypt data, the HCE-REE engine can authenticate and decrypt the ciphertext structure within the HCE-REE engine, and use the authenticated and decrypted working key to encrypt and decrypt data within the HCE-REE engine. This ensures that the working key achieves hardware-level security during use, and the use of the working key is completed only within the REE, without needing to switch to TEE or SEE, thus not affecting encryption and decryption performance.

[0455] Considering the chip area, in a single-function call scenario, each data encryption / decryption operation involves rewriting the plaintext key into a class A register. Therefore... Figure 8 The number of Class A registers in the chip can be one, in order to reduce the chip area.

[0456] It should be noted that in the context of a single-function call, Figure 8 The ciphertext structure in the DDR (examples may include IV, key ciphertext, TAG, AAD) is visible only to the application under the protection mechanism of the Linux kernel, and cannot be seen by other applications, thereby preventing other applications from encrypting or decrypting the data of this application.

[0457] Furthermore, in scenarios where the key is imported into the HCE-TEE engine or inSE without encapsulation, after the multi-hardware cryptographic engine system returns the generated ciphertext structure to the App, the App can also use a three-stage function call to enable the HCE-TEE engine to perform encryption and decryption operations on application data using this ciphertext structure. For details, please refer to [link / reference]. Figure 4c ,as well as Figure 6 and Figure 7 The description of the embodiments is omitted here.

[0458] In the scenario of importing unencapsulated keys into inSE in the above embodiment, if the application imports unencapsulated working key plaintext into inSE, since inSE has an independent on-chip CPU, the working key plaintext (i.e., key plaintext) can be kept entirely within the hardware and is not visible to CPU A, achieving a pure hardware isolation level and improving the security of the working key.

[0459] In the scenario of importing unencapsulated keys into the HCE-TEE engine in the above embodiment, if the application imports unencapsulated working key plaintext into the HCE-TEE engine, the working key plaintext may enter the TEE memory within a short time window during which the application imports the working key plaintext into the HCE-TEE engine. However, the working key plaintext can be kept entirely within the TEE, thus achieving the TEE security level.

[0460] 2-2 Scenarios where the key is encapsulated and imported into the HCE-TEE engine or inSE.

[0461] This key is used in scenarios where it is encapsulated and imported into the HCE-TEE engine or inSE, to express that the application's working key is imported into the HCE-TEE engine or inSE in encrypted form by the application.

[0462] It is understandable that in scenarios where the key is encapsulated and imported into the HCE-TEE engine or inSE, the same applies to the process described in the above embodiments where the HCE-TEE engine or inSE encrypts the plaintext of the obtained application working key to obtain the ciphertext structure and returns it to the App, as well as the process where the App uses a one-piece or three-piece call to enable the HCE-TEE engine to encrypt and decrypt application data through the ciphertext structure. The principle is the same, and will not be elaborated here.

[0463] Figure 9 An exemplary flowchart illustrates the process of importing the plaintext working key of a multi-hardware cryptographic engine system in a scenario where the key is encapsulated.

[0464] During the BootLoader startup phase of the terminal device, the TRNG in the HCE-TEE engine or inSE can generate the root key and hardwire it into the AO register. This step is a preliminary step, therefore, it is not included in the initial boot process. Figure 9 As shown, this step can also be controlled by software or the terminal device during the bootloader stage, with the HCE-TEE engine or the TRNG in inSE automatically executing the above process.

[0465] exist Figure 9 In this embodiment, the application (e.g., App1) is an application that needs to work with the cloud. Therefore, the cloud sends the application's working key ciphertext to inSE.

[0466] Please refer to Figure 9 (1) Exemplarily illustrates an execution process in a key-symmetric encapsulation import scenario.

[0467] SE (including on-chip inSE and external eSE) can achieve smart card security level certification (such as CC EAL4+ / 5+) and meet StrongBox security level. SE has an independent CPU and secure OS, on which a variety of applications (applets) can run, providing higher security and flexibility, and can be used for customized application scenarios of specific government and enterprise customers.

[0468] Let's take inSE as an example:

[0469] The KM key derivation module in inSE can receive both the hardware root key and the software-provided derivation components.

[0470] For example, the hardware root key can be configured in inSE, for instance, in a hardware component within inSE.

[0471] For example, the hardware root key is the hardware key of inSE, which can be HUK (Hardware Unique Key, one key per machine) or HGK (Hardware Global Key, a hardware key that can be used by multiple hardware cryptographic engines).

[0472] The derived components can be configured in the SA and input from the SA to the KM key derivation module.

[0473] For example, the derived components configured in the SA can be provided by a third-party key management center (such as PKI (Public Key Infrastructure)) before the system leaves the factory.

[0474] For example, PKI may provide the same or different derived components for different applications, and this application does not limit this.

[0475] Since the PKI is the key management center, it also stores the hardware root key configured in the inSE. Therefore, the PKI can utilize... Figure 9 (1) The same derived component and the above hardware root key in the inSE are used to derive the end-cloud shared root key, and the end-cloud shared root key is distributed offline to the cloud of App1.

[0476] In addition, the SA can control the components in the inSE that are configured with the hardware root key, and pass the hardware root key to the KM key derivation module.

[0477] The KM key derivation module can derive the hardware root key from the derived components based on eFuse (or OTP) to obtain the end-to-cloud shared root key. The derivation algorithm and key level can be flexibly developed and customized by SA.

[0478] The end-to-cloud shared root key generated by the KM key derivation module for App1 is the same as the end-to-cloud shared root key generated by PKI and distributed to the cloud for App1.

[0479] For example, HUK is derived to obtain SUK; HGK is derived to obtain SGK.

[0480] In addition, the KM key derivation module and Figure 9 (2) The KM encryption module can be one module or two independent modules, and this application does not restrict this.

[0481] App1's cloud can import the key ciphertext encapsulated using the aforementioned end-to-cloud shared root key into inSE.

[0482] Specifically, the SA running on inSE can receive the working key ciphertext from the application in the cloud (i.e., Figure 9 (1) The key ciphertext in SA can be imported into inSE.

[0483] For example, based on Figure 2 The architecture shown allows the cloud to call the CA via the HUKS interface, which in turn calls the SA. The SA then uses the SEE OS to transmit the encrypted working key (i.e., ...) from the cloud to the application. Figure 9 (1) The key ciphertext is passed to inSE.

[0484] The data interaction between the cloud and inSE described later is also Figure 2 The software control flow shown is used to achieve this, and will not be described in detail below.

[0485] In this example, the application needs to work with the cloud; therefore, the cloud sends the application's working key ciphertext.

[0486] Specifically, the cloud uses the derived end-cloud shared root key to encrypt the plaintext of the application's working key, resulting in the ciphertext of the working key (i.e., Figure 9 (1) key ciphertext).

[0487] The KM decryption module can use the shared root key between the client and cloud to decrypt the ciphertext of the key and obtain the plaintext key of the App.

[0488] Regarding the process of inSE encrypting the plaintext key and returning the ciphertext structure of the plaintext key to the App, and the App using a single-step or three-step function call to enable the HCE-REE engine to encrypt and decrypt the App's application data based on the ciphertext structure, please refer to the description in the above embodiments, and it will not be repeated here.

[0489] For example, the cloud can transmit video data to be decrypted to a mobile phone. The app installed on the mobile phone that works with the cloud can call the CA through the HUKS interface. The CA can control the HCE-REE engine through the HCE-REE driver to use the plaintext key obtained and decrypted from shared memory to decrypt the video data and obtain the plaintext video. The HCE-REE engine returns the plaintext data to the app through shared memory. The user can then browse the video data sent from the cloud in the app.

[0490] In this embodiment, distinguishing between UK and GK keys can meet different business needs. In some application scenarios, it may be necessary to distribute the same working key in a large-scale broadcast manner, while in other scenarios, more key derivation levels may be required. SA can be flexibly developed and customized according to customer needs.

[0491] Please refer to Figure 9 (2) Exemplarily illustrates an execution process in a key asymmetric encapsulation import scenario.

[0492] Let's take inSE as an example:

[0493] When the terminal device is powered on for the first time or the service is enabled for the first time, inSE's TRNG can generate a pair of asymmetric keys: public key plaintext KPub and private key plaintext Kpriv;

[0494] SA controls the Kpriv generated by TRNG to be passed to the KM encryption module. SA controls the KM encryption module to use the root key of the plaintext working key generated by TRNG to encrypt the Kpriv and write the encrypted result, such as the private key ciphertext, to the NVM secure storage area or DDR. SA also controls the KPub generated by TRNG to be sent to the cloud via secure transmission.

[0495] For example, when SA sends KPub to the cloud via secure transmission, it can be based on Figure 2 In the architecture shown, SA sends the KPub generated by inSE to CA, and CA then sends the KPub to the cloud. This process does not involve shared memory.

[0496] After KPub is stored in the cloud, the working key ciphertext of App1, which is packaged using KPub, can be imported.

[0497] like Figure 9As shown in (2), the cloud can send the key ciphertext to inSE. The specific process is as follows: the cloud sends the key ciphertext to CA by calling the HUKS interface, and CA calls SA to send the key ciphertext to inSE.

[0498] Specifically, the cloud uses the public key plaintext KPub to encrypt the working key plaintext of App1 (and the App1 used in conjunction with the cloud), resulting in the key ciphertext.

[0499] After inSE receives the key ciphertext from the cloud, SA can control the KM decryption module to read back the private key ciphertext, i.e., the Kpriv ciphertext, from the NVM secure storage area;

[0500] 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 private key ciphertext to obtain the private key plaintext Kpriv.

[0501] SA controls the PKE (Public Key Equipment) decryption module, using the private key plaintext Kpriv to decrypt the key ciphertext sent from the cloud, obtaining the App's key plaintext.

[0502] exist Figure 9 In (2), the KM encryption module and the KM decryption module can use, for example, the authentication encryption algorithm of GCM to encrypt and decrypt the key and authenticate the key.

[0503] Based on Figure 9 The process shown involves the HCE-TEE engine or inSE decrypting the application's working key ciphertext (i.e., key ciphertext) to obtain the key plaintext. The HCE-TEE engine or inSE can then encrypt the key plaintext and return the ciphertext structure of the key plaintext to the App. The process by which the App uses a single-step or three-step function call to enable the HCE-TEE engine to encrypt and decrypt the App's application data based on this ciphertext structure is described in the above embodiments and will not be repeated here.

[0504] In this embodiment, the multi-hardware cryptographic engine system can support the import of encapsulated keys. In the scenario of importing encapsulated keys into inSE, the plaintext of the application's working key can be kept entirely within the hardware, achieving hardware-level security.

[0505] The above example illustrates how to import a sealed key into inSE. However, the method is similar when importing a sealed key into the HCE-TEE engine, so it will not be repeated here.

[0506] It should be noted that, considering the HCE-TEE engine runs on the ACPU, while inSE runs on a separate CPU not shared with the ACPU, then in order to... Figure 9 (2) To ensure the security of the public key plaintext, the scenario of the key being encapsulated and imported can be applied to inSE to avoid the risk of the public key plaintext being stolen by malicious applications when it is applied to the HCE-TEE engine.

[0507] Furthermore, in scenarios where the key is encapsulated and imported into the HCE-TEE engine or inSE, the multi-hardware cryptographic engine system encrypts the application's working key plaintext (i.e., the key plaintext), generates a ciphertext structure, and returns the ciphertext structure to the App. The process by which the App uses a single-function call or a three-function call to enable the HCE-TEE engine to perform encryption and decryption operations on application data using this ciphertext structure can be referred to the descriptions of the specific embodiments of single-function calls and three-function calls in the above examples, and will not be repeated here.

[0508] 2-3. Scenarios of importing unencapsulated keys into the HCE-REE engine

[0509] This scenario, where the key is imported into the HCE-REE engine without encapsulation, indicates that the application's working key is imported into the HCE-REE engine in plaintext by the application.

[0510] like Figure 3 As shown, the HCE-TEE engine is configured with a Class B register for setting the plaintext of the working key passed by the application. By setting the Class B register, a channel can be reserved for multiple hardware cryptographic engine systems to use the plaintext of the working key passed by the application to directly encrypt and decrypt data in the REE environment without switching the operating environment to TEE or SEE, which can improve data encryption and decryption performance.

[0511] 2-3-1. The number of Class B registers in the HCE-REE engine is one.

[0512] Figure 10 An exemplary flowchart of a multi-hardware cryptographic engine system is shown in a scenario where the key is imported into the HCE-REE engine without encapsulation.

[0513] In the case where there is only one Class B register in the HCE-REE engine, such as Figure 10 As shown, if the Class B register is Key slot 0, then we can disregard the different scenarios of single-stage and three-stage function calls. The following will combine... Figure 2 , Figure 3 Come to Figure 10 The process is described as follows:

[0514] First, the App can call the HUKS interface to trigger a data encryption / decryption request. This request can include the plaintext key and the data to be encrypted / decrypted, such as plaintext data.

[0515] For example, the App can write the plaintext key and plaintext data into shared memory and carry the address information of the plaintext key and plaintext data in the data encryption / decryption request.

[0516] Then, in response to the data encryption / decryption request, the CA can call the HCE-REE driver to control the HCE-REE engine, read the plaintext key from shared memory, and write it into Key slot 0; then, the HCE-REE engine uses the data encryption / decryption module to read the plaintext data from shared memory, encrypts it using the plaintext key, and obtains the ciphertext data to be returned to the App.

[0517] The detailed process of data encryption and decryption performed by the HCE-REE engine is similar to that in the above embodiments, and will not be repeated here.

[0518] 2-3-2. The number of Class B registers in the HCE-REE engine is multiple.

[0519] Figure 11 An exemplary flowchart of a multi-hardware cryptographic engine system is shown in a scenario where the key is imported into the HCE-REE engine without encapsulation.

[0520] In the case where there are multiple Class B registers in the HCE-REE engine, such as Figure 11 As shown, the HCE-REE engine may include k Class B registers, namely Key slot 1 to Key slot k, where k is a positive integer greater than 1.

[0521] In scenarios involving segmented function calls, combined with Figure 2 , Figure 3 Come to Figure 11 The process is described as follows:

[0522] Please refer to Figure 11 (1):

[0523] First, the App can call the HUKS interface to trigger a key import request, which can include the plaintext of the key.

[0524] For example, the App can write the key in plaintext to shared memory and include the address information of the key in the key import request.

[0525] Then, in response to the key import request, the CA can invoke the HCE-REE driver, control the HCE-REE engine, read the key plaintext from shared memory, and write it into an idle Class B register, such as Key slot 1.

[0526] The HCE-REE driver can determine which of the k Class B registers is used to store the plaintext key of the App based on business requirements, application ID (e.g., package name), etc. For specific solutions, please refer to the above embodiment, which will not be repeated here.

[0527] Then, in response to the key import request, the HCE-REE driver returns the handle in the HCE-REE engine used to identify the Class B register (here, Key slot 1) to the App via CA.

[0528] Please refer to Figure 11 (2):

[0529] After receiving the handle used to identify the Class B register (Key slot 1 in this case), the App calls the HUKS interface according to business needs to trigger a data encryption / decryption request. This data encryption / decryption request can carry the handle used to identify the Class B register (Key slot 1 in this case) and the data to be encrypted / decrypted (e.g., plaintext data).

[0530] For example, the App can write the handle used to identify the Class B register (here, Key slot 1) and the plaintext data into shared memory, and carry the address information of the handle used to identify the Class B register (here, Key slot 1) and the address information of the plaintext data in the data encryption / decryption request.

[0531] Then, in response to the data encryption / decryption request, the CA can invoke the HCE-REE driver to control the HCE-REE engine, read the plaintext key from shared memory, and the handle used to identify the Class B register (here, Key slot 1); then, the HCE-REE engine's data encryption / decryption module reads the plaintext data from shared memory, and based on the handle used to identify the Class B register (here, Key slot 1), reads the plaintext key from the Class B register Key slot 1, and uses the plaintext key to encrypt the plaintext data, generating ciphertext data to be returned to the App.

[0532] The detailed process of data encryption and decryption performed by the HCE-REE engine is similar to the data encryption and decryption process described in the above embodiments, and will not be repeated here.

[0533] In scenarios where there are multiple Class B registers in the HCE-REE engine and a single-function call is used, each time the App triggers a data encryption / decryption request, it needs to carry the data to be encrypted / decrypted along with the plaintext key. The workflow of the HCE-REE engine is similar to... Figure 10 The solution is similar, so I won't go into details here.

[0534] In scenarios where keys are imported into the HCE-REE engine without encapsulation, considering that the application's working key is imported into the HCE-REE engine in plaintext and the application itself does not care about the security of the working key, the HCE-REE engine can be used to encrypt and decrypt data in scenarios where key security is low, thereby improving data encryption and decryption performance.

[0535] In one possible implementation, the multi-hardware cryptographic engine in the system of this application embodiment may include an HCE-REE engine and an HCE-TEE engine. The HCE-TEE engine encrypts the working key, the HCE-REE engine decrypts the working key, and the decrypted working key is used for data encryption and decryption, which can improve data encryption and decryption performance.

[0536] In one possible implementation, the multi-hardware cryptographic engine in the system of this application embodiment may include an HCE-REE engine and an inSE. The inSE encrypts the working key, the HCE-REE engine decrypts the working key, and the decrypted working key is used for data encryption and decryption, resulting in higher security of the working key.

[0537] In one possible implementation, the multi-hardware cryptographic engine in the system of this application embodiment may include an HCE-REE engine, an HCE-TEE engine, and an inSE. The root key in the AO register is generated by the inSE, and the working key is encrypted using the root key, which can improve key security. The HCE-REE engine and the HCE-TEE engine have similar functions. They can use the root key to decrypt the working key ciphertext and use the decrypted working key to encrypt and decrypt data.

[0538] The data encryption and decryption work is mainly implemented by the HCE-REE engine. When the HCE-REE engine is busy, or when the encryption and decryption algorithm configured in the HCE-REE engine is different from the encryption and decryption algorithm required for the data in this application, the HCE-TEE engine uses the root key to decrypt the working key ciphertext and uses the decrypted working key to perform data encryption and decryption.

[0539] For example, considering that the data encryption and decryption algorithms configured in the HCE-REE engine may not be able to support the data encryption and decryption needs of all upper-layer applications, if the data encryption and decryption algorithms configured in the HCE-REE engine do not support the current data encryption and decryption, the HCE-TEE engine can use its internally configured encryption and decryption algorithms that can support the current data encryption and decryption of the application to perform encryption and decryption operations on the application data, so as to improve the reliability of data encryption and decryption.

[0540] Although the root key in the AO register is configured by inSE, both the HCE-REE engine and the HCE-TEE engine can read the root key from the AO register to decrypt the working key ciphertext for data encryption and decryption.

[0541] In the various embodiments of this application, the security subsystem within the SoC may include multiple hardware cryptographic engines such as the HCE-REE engine, the HCE-TEE engine, and inSE. The HCE-REE engine can use the keys within the engine to encrypt and decrypt data without switching operating environments, resulting in higher data encryption and decryption performance. inSE contains an independent CPU, and when used for working key import / generation and working key encryption, the plaintext of the working key can achieve hardware-level security, offering higher security. Furthermore, inSE is programmable and can be flexibly customized. However, inSE runs in a SEE environment, and when transferring the working key to the HCE-REE engine, it requires switching CPUs and operating environments, resulting in poor performance. The HCE-TEE engine can run on an ACPU, so when using the HCE-TEE engine for working key import / generation and working key encryption, there is no need to switch operating environments. Its security and performance fall between the HCE-REE engine and inSE, highlighting a more balanced security advantage. The embodiments of this application can achieve collaborative work among multiple hardware cryptographic engines through the effective cooperation of cryptographic service components CA / TA / SA, supporting various scenarios such as secure key import, generation, and data encryption / decryption.

[0542] In the above embodiments of this application, inSE is used as an example to illustrate the hardware security module (SE) with independent CPU and secure OS in a multi-hardware cryptographic engine. However, the SE in a multi-hardware cryptographic engine is not limited to inSE located inside the SoC, but can also be extended to an independent external SE chip, i.e. eSE.

[0543] Furthermore, this application does not limit the number or combination of hardware cryptographic engines within the SoC, for example... Figure 1 The security subsystem may include multiple REE hardware cryptographic engines, multiple TEE hardware cryptographic engines, multiple inSE, multiple eSE, and various combinations of other hardware cryptographic engines not listed.

[0544] The following describes an apparatus provided by an embodiment of this application. For example... Figure 12 As shown:

[0545] Figure 12 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application. Figure 12As shown, the data processing device 500 may include: the HCE-TEE engine, HCE-REE engine, processor 501, transceiver 505, and optionally memory 502. Optionally, the data processing device may also include SE.

[0546] Optionally, the data processing device also includes an AO register, which is hardwired to the HCE-TEE engine, the HCE-REE engine, and the SE, respectively.

[0547] The transceiver 505, also known as a transceiver unit, transceiver, or transceiver circuit, is used to implement transceiver functions. The transceiver 505 may include a receiver and a transmitter. The receiver, also known as a receiver circuit, is used to implement the receiving function; the transmitter, also known as a transmitter or transmitting circuit, is used to implement the transmitting function.

[0548] The memory 502 may store computer programs, software code, or instructions 504, which may also be referred to as firmware. The processor 501 can control the MAC layer and PHY layer by running the computer programs, software code, or instructions 503 therein, or by calling the computer programs, software code, or instructions 504 stored in the memory 502, to implement the communication methods provided in the embodiments of this application. The processor 501 may be a central processing unit (CPU), and the memory 502 may be, for example, a read-only memory (ROM) or a random access memory (RAM).

[0549] The processor 501 and transceiver 505 described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc.

[0550] The data processing device 500 described above may also include an antenna 506. The modules included in the data processing device 500 are merely illustrative examples and are not intended to limit the scope of this application.

[0551] The structure of a data processing device can be independent of Figure 12 The data processing device can be a standalone device or part of a larger device. For example, the data processing device can be implemented as follows:

[0552] (1) A standalone integrated circuit IC, or chip, or chip system or subsystem; (2) A collection of one or more ICs, optionally including storage components for storing data or instructions; (3) A module that can be embedded in other devices; (4) Vehicle equipment, etc.; (5) Others, etc.

[0553] For cases where the data processing device is implemented as a chip or chip system, please refer to [link / reference]. Figure 13 The diagram shows the structure of the chip. Figure 13 The chip shown includes a processor 601 and an interface 602. There may be one or more processors 601, and multiple interfaces 602. Optionally, the chip or chip system may include a memory 603.

[0554] All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0555] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a computer to control the computer to implement the above-described method embodiments.

[0556] Based on the same technical concept, this application also provides a computer program, which, when executed by a terminal device, is used to implement the above-described method embodiments.

[0557] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0558] Based on the same technical concept, this application also provides a chip, including a network port controller and a processor. The network port controller and processor can implement the above-described method embodiments.

[0559] The steps of the methods or algorithms described in conjunction with the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can reside in an ASIC.

[0560] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0561] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A data processing system, characterized in that, It includes multiple hardware engines, a first storage unit, and a second storage unit that is always on and does not lose power (AO). The multiple hardware engines include a first hardware engine, a second hardware engine, and a third hardware engine. The second storage unit is hardwired to each of the multiple hardware engines and is not readable by software. The first hardware engine runs in a Secure Execution Environment (SEE), the second hardware engine runs in a Rich Execution Environment (REE), and the third hardware engine runs in a Trusted Execution Environment (TEE). The first hardware engine is used for: Read the first root key from the second storage unit; Based on the first key, the plaintext of the first key is encrypted to generate the ciphertext of the first key; Write the first key ciphertext into the first storage unit; The second hardware engine is used for: Read the first root key from the second storage unit; Read the first key ciphertext from the first storage unit; Based on the first key, the ciphertext of the first key is decrypted to generate the plaintext of the first key; Based on the first key plaintext, the first data is encrypted or decrypted to generate the second data; The second storage unit is used to store the first root key, and to be written to the first root key only once when the data processing system is powered on; The system is integrated into a system-on-a-chip (SoC). The third hardware engine is used for: Read the first root key from the second storage unit; Based on the first key, the ciphertext of the first key is decrypted to generate the plaintext of the first key; Based on the plaintext of the first key, the third data is encrypted or decrypted to generate the fourth data.

2. The system according to claim 1, characterized in that, The first hardware engine includes a first true random number generation module; The first true random number generation module is used to generate a first true random number during the initialization of the data processing system and to use the first true random number as the first root key.

3. The system according to claim 1, characterized in that, The first hardware engine is also used for: Generate the first key according to the first variable and the second key, where the second key is a preset key; Write the first root key into the second storage unit.

4. The system according to any one of claims 1 to 3, characterized in that, The second hardware engine also includes a first register, wherein the first register is software-unreadable and software-unwritable; The first register is used to store the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt application data, wherein the application data includes the first data.

5. The system according to any one of claims 1 to 4, characterized in that, The first hardware engine is specifically used for: Based on the key parameters and the first root key, the plaintext of the first key is encrypted to generate the first ciphertext data; Based on the first ciphertext data, obtain the verification data; The first key ciphertext includes the key parameters, the first ciphertext data, and the verification data; The second hardware engine is specifically used for: Based on the verification data in the first key ciphertext, the first ciphertext data is verified and authenticated; If the verification and authentication pass, the first ciphertext data is decrypted based on the key parameters and the first root key to obtain the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt the first data.

6. The system according to any one of claims 1 to 5, characterized in that, The data processing system further includes a first software program and a second software program, the second software program having a first interface, and the first application running in the REE; The first software program is used to control the first hardware engine to perform calculations and read / write operations; The second software program is used for: Control the second hardware engine to perform computation and read / write operations; Communicating with the first application through the first interface; Invoke the first software program.

7. A data processing method, characterized in that, The method is applied to a data processing system, which includes multiple hardware engines, a first storage unit, and a second storage unit (always-on, non-power-off AO). The multiple hardware engines include a first hardware engine, a second hardware engine, and a third hardware engine. The second storage unit is hardwired to each of the multiple hardware engines and is software-inaccessible. The first hardware engine runs in a Secure Execution Environment (SEE), the second hardware engine runs in a Rich Execution Environment (REE), and the third hardware engine runs in a Trusted Execution Environment (TEE). The method includes: The first hardware engine reads the first root key from the second storage unit; The first hardware engine encrypts the plaintext of the first key based on the first root key to generate the ciphertext of the first key; The first hardware engine writes the first key ciphertext into the first storage unit; The second hardware engine reads 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 decrypts the ciphertext of the first key based on the first key to generate the plaintext of the first key; The second hardware engine encrypts or decrypts the first data based on the first key plaintext to generate the second data; The second storage unit is used to store the first root key and to be written to the first root key only once when the data processing system is powered on. The system is integrated into a system-on-a-chip (SoC). After the first hardware engine writes the first key ciphertext into the first storage unit, the method further includes: The third hardware engine reads the first root key from the second storage unit; The third hardware engine decrypts the ciphertext of the first key based on the first root key to generate the plaintext of the first key; The third hardware engine encrypts or decrypts the third data based on the first key plaintext to generate the fourth data.

8. The method according to claim 7, characterized in that, Before the first hardware engine reads the first root key from the second storage unit, the method further includes: The first hardware engine generates a first true random number during the initialization of the data processing system, uses the first true random number as the first root key, and writes the first root key into the second storage unit.

9. The method according to claim 7, characterized in that, Before the first hardware engine reads the first root key from the second storage unit, the method further includes: The first hardware 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 key.

10. The method according to any one of claims 7 to 9, characterized in that, The second hardware engine also includes a first register, wherein the first register is software-unreadable and software-unwritable; After the second hardware engine decrypts the ciphertext of the first key based on the first root key to generate the plaintext of the first key, the method further includes: The second hardware engine writes the first key in plaintext into the first register.

11. The method according to any one of claims 7 to 10, characterized in that, The first hardware engine, based on the first root key, encrypts the plaintext of the first key to generate the ciphertext of the first key, including: The first hardware engine encrypts the first key plaintext based on the key parameters and the first root key to generate first ciphertext data, and obtains verification data based on the first ciphertext data; wherein, the first key ciphertext includes the key parameters, the first ciphertext data and the verification data. The second hardware engine, based on the first root key, decrypts the ciphertext of the first key to generate the plaintext of the first key, including: The second hardware engine verifies and authenticates the first ciphertext data 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 parameters and the first root key to obtain the first key plaintext, wherein the first key plaintext is used to encrypt or decrypt the first data.

12. The method according to any one of claims 7 to 11, characterized in that, The data processing system further includes a first software program and a second software program, the second software program having a first interface, the first application running in the REE, and the method further includes: The first software program controls the first hardware engine to perform computation and read / write operations; The second software program controls the second hardware engine to perform calculations and read / write operations, communicates with the first application through the first interface, and calls the first software program.

13. A data processing apparatus, characterized in that, The device includes multiple hardware engines, a first storage unit, and a second storage unit that is always on and does not lose power (AO). The multiple hardware engines include a first hardware engine, a second hardware engine, and a third hardware engine. The second storage unit is hardwired to each of the multiple hardware engines and is not readable by software. The first hardware engine runs in a Secure Execution Environment (SEE), the second hardware engine runs in a Rich Execution Environment (REE), and the third hardware engine runs in a Trusted Execution Environment (TEE). The data processing device is used to execute the method as described in any one of claims 7 to 12.

14. A chip, characterized in that, The device includes one or more interface circuits, one or more processors, multiple hardware engines, a first storage unit, and a second storage unit with a normally-on, non-power-off (AO) memory. The multiple hardware engines include a first hardware engine, a second hardware engine, and a third hardware engine. The second storage unit is hardwired to each of the multiple hardware engines and is not readable by software. The first hardware engine runs in a Secure Execution Environment (SEE), the second hardware engine runs in a Rich Execution Environment (REE), and the third hardware engine runs in a Trusted Execution Environment (TEE). The multiple hardware engines are used to execute the method of any one of claims 7 to 12.

15. A computer storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed on a computer or processor, causes the computer or processor to perform the method as described in any one of claims 7 to 12.

16. A computer program product, characterized in that, The computer program product includes a software program that, when executed by a computer or processor, causes the steps of the method described in any one of claims 7 to 12 to be performed.

Images