Client application authentication and data transmission method and system in trusted environment
By employing digital certificate authentication and key splitting technology in both REE and TEE environments, trusted identity authentication and encrypted data transmission between the REE and TEE sides are achieved, solving the problems of REE side stealing information and transmitting data in plaintext to TEE side, thus improving security and controllability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-15
- Publication Date
- 2026-04-14
AI Technical Summary
In a trusted execution environment, client applications (CAs) on the REE side are prone to stealing sensitive information from the TEE side. Furthermore, the lack of encryption in the REE-TEE interaction channel leads to plaintext data transmission, posing a risk of attackers intercepting and tampering with the data.
A digital certificate authentication system is used to issue certificates for applications on the REE and TEE sides. Key splitting and collaborative signature technologies are used to generate signature private keys for trusted identity authentication. Session keys are generated on the TEE side for encrypted data transmission. SM2, SM3 and SM4 national cryptographic algorithms are used for secure negotiation and decryption.
It implements application authentication in REE and TEE environments, ensuring that only authorized applications can access the system, protecting the confidentiality and integrity of communication data, preventing private key leakage and man-in-the-middle attacks, and improving the security and controllability of data transmission.
Smart Images
Figure CN121864437A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of confidential computing and domestically produced commercial cryptographic applications, specifically to a method and system for trusted authentication of client applications and secure transmission of important data under a TEE system. This application is applicable to enabling various CAs (client applications) running on the REE (Rich Execution Environment) side and TAs (Trusted Applications) on the TEE side to mutually authenticate, communicate, and collaborate, jointly completing local encryption and decryption operations on important data without invoking external encryption devices / systems (such as encryption machines). It is particularly suitable for data circulation scenarios, achieving the effect of data being usable but invisible. Background Technology
[0002] Hardware-secure Trusted Execution Environments (TEEs) are a crucial technological means for protecting data security and privacy. A TEE requires a device to simultaneously possess two complete operating environments: a rich execution environment (REE) and a trusted execution environment (TEE). Applications running in the REE are called client applications, responsible for handling business processes with high performance and functional requirements. Applications running in the TEE are called trusted applications, responsible for handling business processes with high security and confidentiality requirements. These two operating environments coexist on the same device while remaining securely isolated. Regarding application authentication, cross-environment interaction between REE and TEE applications can lead to application identity forgery. If the CA on the REE side is rooted or has its privileges elevated, it can easily gain unauthorized access to the TA, thereby stealing sensitive information from the TEE side. In terms of secure data transmission, plaintext transmission and the MITM (Mixed-Text Detection and Misinterpretation) phenomenon exist. Because the REE-TEE interaction channel is unencrypted, attackers can intercept, tamper with data, and even change response results.
[0003] Therefore, there is an urgent need to study a client application authentication and data transmission method in a trusted execution environment. On the one hand, it needs to have access control capabilities to ensure that only authorized client applications can access the corresponding trusted applications. On the other hand, the channel between trusted applications needs to ensure the confidentiality and integrity of the communication data, so that other trusted applications cannot obtain the information of the communication itself except for the authorized trusted applications. Summary of the Invention
[0004] To address the technical problem of REE-side CA stealing sensitive information from TEE-side devices in existing technologies, this invention proposes a client application authentication and data transmission method and system in a trusted environment.
[0005] In a first aspect, embodiments of this application provide a client application authentication and data transmission method in a trusted environment, applied to secure data transmission between a client application CA on the Rich Execution Environment (REE) side and a trusted application TA on the Trusted Execution Environment (TEE) side. The method includes:
[0006] Trusted identity authentication steps: A digital certificate authentication system is used to issue digital certificates to both applications and generate signature private keys for both applications. Specifically, the trusted application (TA) on the TEE side directly performs signature operations using its signature private key; the client application (CA) on the REE side uses key splitting for its signature private key and a collaborative signature method for its signature operation. The signature operation results are then combined on the TEE side to form the final private key signature value; the trusted application (TA) and the client application (CA) mutually sign and verify each other.
[0007] Secure data transmission steps: The client application CA and the trusted application TA, which have completed trusted identity authentication, negotiate a key. The negotiated session key is generated by the TEE side and then sent to the client application CA. After two decryptions, the client application CA obtains the session key. The two applications then use the session key to securely transmit encrypted data.
[0008] In this embodiment of the invention, the above-mentioned trusted identity authentication step includes:
[0009] Certificate issuance steps: Both applications initiate a trusted service request to the digital certificate authentication system to apply for an application certificate based on the SM2 algorithm. The digital certificate authentication system is responsible for issuing digital certificates to both applications.
[0010] TEE Trusted Application Authentication Steps: Perform a signature operation using your own private key factor, and send the signature result to the client application for verification;
[0011] REE-side client application authentication steps: The REE-side client application CA generates a signing private key for the client application independently in both environments based on collaborative signature technology, and stores them securely. Neither party can obtain the complete signing private key. The signing private key of the client application CA includes: the client application REE-side private key factor and the TEE-side private key factor.
[0012] Each side uses its own private key factor to perform the signature operation, and the signature result of the client application on the REE side is finally synthesized into the final signature value on the TEE side.
[0013] Trusted Applications (TAs) verify the signature value, the validity of the digital certificate message, and the trust chain, and then return the verification result to the client application, allowing or denying the client application's access to the CA.
[0014] In this embodiment of the invention, the above-mentioned secure data transmission step further includes:
[0015] Key negotiation steps: The client application CA and the trusted application TA negotiate a key before transmitting important data, using a one-session-one-key security mechanism; the session key is generated by the trusted application TA and encrypted using the client application CA's encryption certificate;
[0016] Collaborative decryption steps: The Trusted Application (TA) uses a collaborative decryption mechanism to securely distribute the session key to the client application (CA). First, it performs a first decryption using the encryption private key factor of the client application (CA) on the TEE side. The result of the first decryption is forwarded to the client application (CA) on the REE side. Then, it performs a second decryption using the encryption private key factor of the REE side to obtain the session key.
[0017] During data transmission, based on the session key, the client application CA uses encryption mode to transmit the data to be transmitted in encrypted form to the trusted application TA.
[0018] In this embodiment of the invention, the above-mentioned application certificate issuance step includes:
[0019] TEE-side TA certificate issuance steps: The Trusted Application TA is generated and sent to the Digital Certificate Authentication System to apply for a Trusted Application Certificate. The Digital Certificate Authentication System issues and returns the Trusted Application Certificate.
[0020] REE-side CA certificate issuance steps: The REE-side CA obtains the encrypted certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; based on security parameters, the REE-side CA generates key material to calculate the local key component S1 and public key component P1; using the encrypted certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA; the TA calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate.
[0021] In this embodiment of the invention, the above steps for REE-side CA to verify TEE-side TA are as follows: REE-side CA initiates an authentication request; TEE-side TA generates a random number as a challenge code; TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; TA returns the challenge code and signature value to REE-side CA; REE-side verifies the validity of the signature and the validity of the TA certificate. If the verification is successful, it indicates that TA is a trusted application, and the CA's verification of TA is completed.
[0022] The above TEE-side TA verification steps for the REE-side CA are as follows: For the challenge code, the REE side signs it using its locally stored private key component S1; the REE side sends the client application signature to the TEE side; the TEE side signs it using another private key component S2 of the client application; the signatures from both ends are aggregated to generate the final signature value; the TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA verification of the CA is completed.
[0023] In this embodiment of the invention, the key negotiation step includes:
[0024] Key encryption key splitting steps: The TEE side generates a key encryption key KEK, splits the session encryption key, and splits the original KEK into independent key shares S1, S2, S3. After splitting, it meets two rules, including: minimum threshold requirement and security constraints.
[0025] The key distribution steps are as follows: the split key share S1 is distributed to the CA application on the REE side, the key share S2 is distributed to the TA application on the TEE side, and the key share S3 is encrypted and stored on the TEE side.
[0026] In this embodiment of the invention, the above-mentioned collaborative decryption step includes:
[0027] Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key. The trusted application on the TEE side requests a trusted service, generates a session key, and encrypts it using the key encryption key KEK. The trusted application on the TEE side decrypts the encrypted session key using its own key component S2. The intermediate result of the decryption on the TEE side is then passed to the REE-side client application. The REE-side client application decrypts the data using its own key component S1 to finally obtain the session key. The REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA. The TEE-side TA decrypts the session key using components S2 and S3. Based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0028] Secondly, embodiments of this application provide a client application authentication and data transmission system in a trusted environment. Employing the aforementioned client application authentication and data transmission method in a trusted environment, it is applied to secure data transmission between a client application CA on the Rich Execution Environment (REE) side and a trusted application TA on the Trusted Execution Environment (TEE) side. The system includes:
[0029] Trusted Identity Authentication Module: Employing a digital certificate authentication system, digital certificates are issued to both applications. Based on collaborative signature technology, signature private keys are generated for both applications. Each application uses its signature private key to perform signature operations. Specifically, the trusted application TA on the TEE side directly performs signature operations using its signature private key. The client application CA on the REE side uses key splitting for its signature private key and collaborative signature for its signature operations. The signature operation results are then combined on the TEE side to form the final private key signature value. The trusted application TA and the client application CA mutually sign and verify each other, completing the trusted identity authentication of both applications.
[0030] Secure data transmission module: The client application and the trusted application that have completed trusted identity authentication negotiate the key. After the negotiated session key is generated by the TEE side, the session key is sent to the client application using a collaborative decryption mechanism. The session key is obtained after two decryptions. The two applications use the session key to perform secure transmission of encrypted data.
[0031] Thirdly, embodiments of this application provide a client application CA on the Rich Execution Environment (REE) side, the client application CA being configured to execute steps including:
[0032] REE-side CA certificate issuance steps: The REE-side CA obtains the encryption certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; the REE-side application generates key material based on security parameters to calculate the local key component S1 and public key component P1; using the encrypted certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA; the TA calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate.
[0033] The steps for REE-side CA to verify TEE-side TA are as follows: REE-side CA initiates an authentication request; TEE-side TA generates a random number as a challenge code; TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; TA returns the challenge code and signature value to REE-side CA; REE-side verifies the validity of the signature and the validity of the TA certificate. If the verification is successful, it indicates that TA is a trusted application, and the CA's verification of TA is completed.
[0034] Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0035] Fourthly, embodiments of this application provide a Trusted Application (TA) on the Trusted Execution Environment (TEE) side, wherein the Trusted Application (TA) is configured to execute steps including:
[0036] TEE-side TA certificate issuance steps: The trusted application generates and sends a trusted application certificate application to the digital certificate authentication system, and the digital certificate authentication system issues and returns the trusted application certificate;
[0037] The steps for TEE-side TA to verify REE-side CA are as follows: For the challenge code, the REE side signs the code using its locally stored private key component S1; the REE side sends the client application signature to the TEE side; the TEE side signs the code using another private key component S2 of the client application; the signatures from both ends are aggregated to generate the final signature value; the TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA verification of the CA is completed.
[0038] Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0039] Compared with existing technologies, it has the following outstanding advantages:
[0040] 1) The method and system of this invention propose to use the SM2, SM3 and SM4 national cryptographic algorithms in the cross-environment application interaction between REE and TEE, and to use cryptographic technology at the application layer for application authentication and authorization, and negotiate encryption keys for data encryption transmission, thereby improving the security protection effect.
[0041] 2) The method and system of this invention propose key security safeguards: TEE side: The private key is stored in the TEE secure zone throughout the process and is not exposed to the REE side; CSR signature and certificate storage are both protected by TEE hardware security capabilities to prevent tampering; REE side: After the private key is split, no single custodian can obtain the complete private key, reducing the risk of private key leakage; Public key aggregation and share transmission are both encrypted to prevent man-in-the-middle attacks.
[0042] 3) The method and system of this invention propose a core mechanism of "challenge-signature-verification" to achieve two-way authentication for dual-environment applications. The authentication objectives are: to confirm the legitimacy of the TA on the TEE side and the integrity of the platform, to confirm the legitimacy of the CA on the REE side and the validity of the key share, while ensuring the confidentiality, integrity and non-repudiation of identity information during the authentication process.
[0043] 4) The method and system of this invention propose collaborative decryption, which splits the decryption authority into multiple independent shares. Only when multiple shares that meet the preset conditions participate collaboratively can the decryption key be fully restored or the decryption operation be completed directly. Essentially, it is an encryption and unlocking mechanism of "distributed control + collaborative verification". The core objective is to ensure the security of the key components on the REE side by splitting the decryption key, thereby improving the security, controllability and fault tolerance of decryption. Attached Figure Description
[0044] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0045] Figure 1 This is a schematic diagram of the client application authentication and data transmission method in a trusted environment according to the present invention;
[0046] Figure 2 This is a schematic diagram of the overall framework of an embodiment of the present invention;
[0047] Figure 3 This is a schematic diagram illustrating the certificate issuance process in an embodiment of the present invention;
[0048] Figure 4 This is a schematic diagram of the mutual authentication process between the two sides of the REE-TEE in an embodiment of the present invention;
[0049] Figure 5 This is a schematic diagram of an important data transmission encryption process in an embodiment of the present invention;
[0050] Figure 6 This is a schematic diagram of the client application authentication and data transmission system under a trusted environment according to the present invention. Detailed Implementation
[0051] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.
[0052] It should also be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.
[0053] It should also be understood that, in various embodiments of the present invention, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0054] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0055] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0056] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0057] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0058] To make the above-mentioned features and effects of the present invention clearer and easier to understand, specific embodiments are described below in conjunction with the accompanying drawings. This specification discloses one or more embodiments incorporating the features of the present invention. The disclosed embodiments are merely illustrative. The scope of protection of the present invention is not limited to the disclosed embodiments, but is defined by the appended claims.
[0059] The following are system embodiments corresponding to the above method embodiments. This embodiment can be implemented in conjunction with the above embodiments. The relevant technical details mentioned in the above embodiments are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the above embodiments.
[0060] This invention is applicable to enabling various CAs (client applications) running on the REE (Rich Execution Environment) side and TAs (Trusted Applications) on the TEE (Trusted Execution Environment) side to mutually authenticate, communicate, and collaborate, jointly completing local encryption and decryption operations on important data without calling external encryption devices / systems (such as encryption machines). It is especially suitable for data circulation scenarios, achieving the effect of data being usable but invisible.
[0061] The system of this application embodiment will be described in detail below with reference to specific embodiments:
[0062] like Figure 1 and Figure 2 As shown, this invention relates to client application authentication and data transmission in a trusted execution environment. In cross-environment application interaction between REE and TEE, this invention employs the SM2, SM3, and SM4 national cryptographic algorithms, uses cryptographic techniques at the application layer for application authentication, and negotiates encryption keys for encrypted data transmission, thereby improving security.
[0063] like Figure 1 As shown, this invention proposes a client application authentication and data transmission method in a trusted environment, applied to secure data transmission between a client application CA on the Rich Execution Environment (REE) side and a trusted application TA on the Trusted Execution Environment (TEE) side. The method includes:
[0064] Trusted identity authentication step 101: A digital certificate authentication system is used to issue digital certificates to both applications and generate signature private keys for each application based on collaborative signature technology. Each application uses its signature private key to perform a signature operation. Specifically, the trusted application TA on the TEE side directly performs the signature operation using its signature private key. The client application CA on the REE side uses key splitting for its signature private key and performs the signature operation using collaborative signature. The signature operation results are then combined on the TEE side to form the final private key signature value. The trusted application TA and the client application CA mutually sign and verify each other to complete the trusted identity authentication of both applications.
[0065] Specifically, in the specific embodiments of the present invention, the trusted identity authentication step 101 of the above two environmental applications specifically includes:
[0066] Application certificate services are provided using a digital certificate authentication system (which can be operated by a third-party CA or a self-built CA). Application certificates are issued for both client applications and trusted applications, and full lifecycle management of the certificates is provided. To ensure key security in the rich execution environment (TEE), collaborative signature technology is used. The client application's signing private key on the REE side consists of two parts: a CA-side private key factor and a TA (Trusted Agent) private key factor. These two keys are generated independently in their respective environments and stored securely, preventing either party from obtaining the complete signing private key. During signature computation, both applications use their own private key factors for the signature operation, and the final signature value is synthesized on the TEE side. Finally, the TA application verifies the signature value, the existence of a message in the digital certificate, and the trust chain, thereby ensuring that the client application is a client application with the necessary access permissions and can use other trusted service capabilities.
[0067] Secure data transmission step 102: The client application CA and the trusted application TA, which have completed trusted identity authentication, negotiate a key. The negotiated session key is generated by the TEE side and then sent to the client application CA. After two decryptions, the client application CA obtains the session key. The two applications then use the session key to securely transmit encrypted data.
[0068] Specifically, in a specific embodiment of the present invention, the secure data transmission step 102 of the above two environmental applications specifically includes:
[0069] Before transmitting important data, client applications and trusted applications first negotiate a key using a "one session, one key" security mechanism. The session key is securely generated by the TEE side and encrypted using the client application's encryption certificate. Then, a collaborative decryption mechanism is used to securely distribute the key to the client application. First, the key is decrypted using the TEE side's encryption private key factor. The result of this first decryption is forwarded to the corresponding client application on the REE side, where it is then decrypted a second time using the REE side's encryption private key factor to obtain the session key.
[0070] During data transmission, the session key is used to transmit the data in encrypted form using the SM4 GCM mode.
[0071] In this embodiment of the invention, the above-mentioned trusted identity authentication step 101 includes:
[0072] Certificate issuance steps: Both applications initiate a trusted service request to the digital certificate authentication system to apply for an application certificate based on the SM2 algorithm. The digital certificate authentication system is responsible for issuing digital certificates to both applications.
[0073] TEE-side Trusted Application (TA) authentication steps: Perform a signature operation using your own signature private key factor, and send the signature result to the client application (CA) for verification.
[0074] REE-side client application CA authentication steps: The REE-side client application CA's signing private key uses key splitting, and the REE-side client application CA performs signing operations using collaborative signing. The signing operation results are synthesized into the final private key signature value on the TEE side. Based on collaborative signing technology, the REE-side client application CA independently generates the client application's signing private key in both environments, and stores them securely, ensuring that neither party can obtain the complete signing private key. The signing private key of the client application CA includes: the client application REE-side private key factor and the TEE-side private key factor.
[0075] The Trusted Application (TA) verifies the signature value, the validity of the digital certificate message, and the trust chain, and returns the verification result to the client application, allowing or denying the client application's CA access.
[0076] In this embodiment of the invention, the above-mentioned secure data transmission step 102 further includes:
[0077] Key negotiation steps: The client application CA and the trusted application TA negotiate a key before transmitting important data, using a one-session-one-key security mechanism; the session key is generated by the trusted application TA and encrypted using the client application CA's encryption certificate;
[0078] Collaborative decryption steps: The Trusted Application (TA) uses a collaborative decryption mechanism to securely distribute the session key to the client application (CA). First, it performs a first decryption using the encryption private key factor of the client application (CA) on the TEE side. The result of the first decryption is forwarded to the client application (CA) on the REE side. Then, it performs a second decryption using the encryption private key factor of the REE side to obtain the session key.
[0079] During data transmission, based on the session key, the client application CA uses encryption mode to transmit the data to be transmitted in encrypted form to the trusted application TA.
[0080] In this embodiment of the invention, the above-mentioned application certificate issuance step includes:
[0081] TEE-side TA certificate issuance steps: The Trusted Application TA is generated and sent to the Digital Certificate Authentication System to apply for a Trusted Application Certificate. The Digital Certificate Authentication System issues and returns the Trusted Application Certificate.
[0082] REE-side CA certificate issuance steps: The REE-side CA obtains the encrypted certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; based on security parameters, the REE-side CA generates key material to calculate the local key component S1 and public key component P1; using the encrypted certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA; the TA calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate.
[0083] Specifically, such as Figure 3 As shown in the specific embodiment of the present invention, the issuance of the application certificate specifically includes:
[0084] To enable trusted applications on the TEE side to perform trusted identity authentication of client applications on the REE side, a digital certificate authentication system (either a third-party operated CA or a self-built CA) is required to issue a digital certificate identifying the application's identity.
[0085] Overall approach: The TA on the TEE side directly generates key pairs and applies for digital certificates compliant with the X.509 standard, relying on the TEE's hardware security capabilities to ensure the confidentiality and integrity of the keys and the application process; the CA on the REE side uses key splitting technology (splitting the private key into two shares) to generate key materials, and synthesizes the P10 request for the client application on the TA side, balancing ease of use and key security; both parties submit certificate applications to a unified digital certificate authentication system, and after the CA completes the verification, it signs and issues the application certificate, and finally distributes the certificates to the secure storage on the TEE side and the designated storage location on the REE side.
[0086] The application certificate application process for trusted applications in a TEE environment is as follows:
[0087] Step 1: The trusted application generates an ECC (256) asymmetric key pair through the hardware secure random number generator (HRNG) provided by the TEE kernel, and the private key is stored directly in the TEE secure storage area;
[0088] Step 2: Generate an X.509 Certificate Request (CSR) and sign the CSR using your own private key;
[0089] Step 3: Submit the CSR to the digital certificate authentication system;
[0090] Step 4: The digital certificate authentication system verifies the signature validity of the CSR and checks the identity information of the TA;
[0091] Step 5: After successful verification, the digital certificate authentication system uses its own certificate to sign the public key in the CSR and generate a standard X.509 certificate.
[0092] Step 6: Return the application certificate and certificate trust chain issued by the digital certificate authentication system to the TA application;
[0093] Step 7: After receiving the certificate, the TA verifies the validity of the CA signature. If the verification is successful, the certificate is stored in the secure storage area of the TEE.
[0094] The application certificate application process for client applications in an REE environment is as follows:
[0095] Step 1: For REE-side applications, first obtain the encryption certificate of the trusted application and store it locally;
[0096] Step 2: The REE-side application calculates the local key share S1 and the public key share P1 based on security parameters;
[0097] Step 3: Using the trusted application's encryption certificate, send the client's public key component P1 and security parameters to the TA side;
[0098] Step 4: First, calculate the client application key share S2 and public key share P2 on the TA side, then calculate the aggregate public key P = P1⊕ P2 on the TA side, and generate a Certificate Issuance Request (CSR).
[0099] Step 5: Submit the CSR to the digital certificate authentication system;
[0100] Step 6: The digital certificate authentication system verifies the signature validity of the CSR and checks the identity information of the client application;
[0101] Step 7: After verification, the digital certificate authentication system uses its own certificate to sign the public key in the CSR and generate a standard X.509 certificate;
[0102] Step 8: Return the application certificate and certificate trust chain issued by the digital certificate authentication system to the client application;
[0103] Step 9: After receiving the certificate, the client application verifies the validity of the CA signature. If the verification is successful, the certificate is stored in the secure storage area of the REE.
[0104] Key security safeguards:
[0105] TEE side: Private keys are stored in the TEE secure zone throughout the process and are not exposed to the REE side; CSR signatures and certificate storage are protected by TEE hardware security capabilities to prevent tampering.
[0106] On the REE side: After the private key is split, no single custodian can obtain the complete private key, reducing the risk of private key leakage; public key aggregation and share transmission are both encrypted to prevent man-in-the-middle attacks.
[0107] In this embodiment of the invention, the above steps for REE-side CA to verify TEE-side TA are as follows: REE-side CA initiates an authentication request; TEE-side TA generates a random number as a challenge code; TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; TA returns the challenge code and signature value to REE-side CA; REE-side verifies the validity of the signature and the validity of the TA certificate. If the verification is successful, it indicates that TA is a trusted application, and the CA's verification of TA is completed.
[0108] The steps for TEE-side TA to verify REE-side CA are as follows: For the challenge code, the REE side uses its locally stored private key component S1 to sign; the REE side sends the client application signature to the TEE side; the TEE side uses another private key component S2 of the client application to sign; the signatures from both ends are aggregated to generate the final signature value; the TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA verification of the CA is completed.
[0109] Specifically, such as Figure 4As shown in the specific embodiment of the present invention, the above-mentioned application of trusted identity authentication includes:
[0110] After the application certificate is issued, client application identity authentication is performed based on asymmetric cryptography technology, which can perform one-way or two-way authentication.
[0111] This process is based on the X.509 standard digital certificate already obtained by the Trusted Application (TA) on the TEE side and the key-segmented digital certificate already obtained by the Client Application (CA) on the REE side. It employs a core mechanism of "challenge-signature-verification" to achieve two-way authentication between the two environments. The authentication objectives are: to confirm the legitimacy of the TA on the TEE side and the integrity of the platform; to confirm the legitimacy of the CA on the REE side and the validity of the key share; and to ensure the confidentiality, integrity, and non-repudiation of identity information during the authentication process. The authentication process is as follows:
[0112] Phase 1: REE-side CA verification and TEE-side TA verification
[0113] Step 1: The CA on the REE side initiates an authentication request;
[0114] Step 2: The TEE side TA generates a random number as the challenge code (ensuring uniqueness and unpredictability);
[0115] Step 3: The TEE-side TA uses its own application signing certificate private key to sign and generate a signature value;
[0116] Step 4: The TA returns the challenge code and signature value to the CA on the REE side;
[0117] Step 5: The REE side verifies the validity of the signature and the TA certificate. If the verification is successful, it indicates that the TA is a trusted application, and the CA's verification of the TA is completed.
[0118] Phase Two: TEE-side TA verification and REE-side CA verification
[0119] Step 1: For the challenge code mentioned above, the REE side first uses the locally stored private key share S1 to sign it;
[0120] Step 2: Send the client application signature from the REE side to the TEE side;
[0121] Step 3: The TEE uses another private key share from the client application to perform an S2 signature;
[0122] Step 4: Aggregate the signatures from both ends to generate the final signature value;
[0123] Step 5: The TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA's verification of the CA is completed.
[0124] This completes the two-way authentication.
[0125] In this embodiment of the invention, the key negotiation step includes:
[0126] Key encryption key splitting steps: The TEE side generates a key encryption key KEK, splits the session encryption key, and splits the original KEK into independent key shares S1, S2, S3. After splitting, it meets two rules, including: minimum threshold requirement and security constraints.
[0127] The key distribution steps are as follows: the split key share S1 is distributed to the CA application on the REE side, the key share S2 is distributed to the TA application on the TEE side, and the key share S3 is encrypted and stored on the TEE side.
[0128] Specifically, in specific embodiments of the present invention, the above-mentioned collaborative decryption application specifically includes:
[0129] The core principle of collaborative decryption is to divide the decryption authority into multiple independent shares. Only when multiple shares that meet the preset conditions participate collaboratively can the decryption key be fully restored or the decryption operation be completed directly. In essence, it is an encryption and unlocking mechanism of "decentralized control + collaborative verification". The core goal is to ensure the security of the key components on the REE side by splitting the decryption key, thereby improving the security, controllability and fault tolerance of decryption.
[0130] 1. Key encryption and key splitting
[0131] The TEE side is responsible for securely generating the key encryption key (KEK), and then using the Shamir's Secret Sharing (SSS) algorithm, the session encryption key is split into three independent "key shares" (S1, S2, S3). After splitting, two core rules are met:
[0132] ① Minimum threshold requirement: At least 2 shares are required to restore KEK (i.e., using the "(3,2) threshold scheme");
[0133] ② Security constraint: With fewer than two shares, no valid information about the KEK can be obtained. (This ensures the security of the REE-side key components).
[0134] 2. Shared key distribution
[0135] After splitting, S1 is distributed to the CA application on the REE side, S2 is distributed to the TA application on the TEE side, and S3 is encrypted and stored on the TEE side.
[0136] In this embodiment of the invention, the above-mentioned collaborative decryption step includes:
[0137] Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key. The trusted application on the TEE side requests a trusted service, generates a session key, and encrypts it using the key encryption key KEK. The trusted application on the TEE side decrypts the encrypted session key using its own key component S2. The intermediate result of the decryption on the TEE side is then passed to the REE-side client application. The REE-side client application decrypts the data using its own key component S1 to finally obtain the session key. The REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA. The TEE-side TA decrypts the session key using components S2 and S3. Based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0138] Specifically, such as Figure 5 As shown in the specific embodiment of the present invention, dynamic collaborative decryption specifically includes:
[0139] When data is transmitted between the REE-side CA application and the TEE-side TA application, key negotiation is performed using a one-session-one-key approach. The session key is securely distributed after being encrypted and protected by a Key Encryption Key (KEK). The following is a process design example of important data transmission from the REE-side CA application to the TEE-side TA application. The specific process is as follows: Figure 5 As shown.
[0140] Prerequisites:
[0141] The key encryption key KEK has been split into 3 independent "key shares" (S1, S2, S3). After the split, S1 is distributed to the CA application on the REE side, S2 is distributed to the TA application on the TEE side, and S3 is encrypted and stored on the TEE side.
[0142] Step 1: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key;
[0143] Step 2: The trusted application on the TEE side requests the trusted service, generates a session key, and encrypts it with KEK;
[0144] Step 3: The trusted application on the TEE side first uses its own key component S2 to decrypt the encrypted session key;
[0145] Step 4: Pass the intermediate results of the TEE-side decryption to the REE-side client application;
[0146] Step 5: The REE-side client application uses its own key component S1 to decrypt and finally obtain the session key;
[0147] Step 6: The REE-side client application uses the session key to encrypt important data, employing the SM4 national cryptographic algorithm in GCM mode.
[0148] Step 7: The REE-side client application transmits the encrypted data to the TEE trusted application;
[0149] Step 8: Trusted application on the TEE side decrypts the session key using S2 and S3 components;
[0150] Step 9: Decrypt the ciphertext data based on the session key to obtain the original data.
[0151] Then, important data can be encrypted and calculated on the TEE side, and finally the TEE side returns the calculation result to the REE side client application.
[0152] As described above, the method of the present invention can be implemented well.
[0153] Compared with the prior art, the present invention has the following outstanding advantages and beneficial effects:
[0154] This invention innovatively proposes a method and system that employs SM2, SM3, and SM4 national cryptographic algorithms in cross-environment application interactions between REE and TEE. It uses cryptographic technology at the application layer for application authentication and authorization, and negotiates encryption keys for encrypted data transmission, thereby improving security protection.
[0155] Secondly, such as Figure 6 As shown, this application provides a client application authentication and data transmission system in a trusted environment. It employs the aforementioned client application authentication and data transmission method in a trusted environment, applied to secure data transmission between a client application CA on the Rich Execution Environment (REE) side and a trusted application TA on the Trusted Execution Environment (TEE) side. The system includes:
[0156] Trusted Identity Authentication Module 201: Employs a digital certificate authentication system to issue digital certificates to both applications and generate signature private keys for both applications based on collaborative signature technology; each application uses its signature private key to perform signature operations, and the signature operation results are synthesized into a final signature value on the TEE side; the trusted application completes trusted identity authentication of both applications by verifying the signature value and the digital certificate.
[0157] Secure data transmission module 202: The client application and the trusted application that have completed trusted identity authentication negotiate a key. After the negotiated session key is generated by the TEE side, the session key is sent to the client application using a collaborative decryption mechanism. The session key is obtained after two decryptions. The two applications use the session key to perform secure transmission of encrypted data.
[0158] Thirdly, embodiments of this application provide a client application CA on the Rich Execution Environment (REE) side, the client application CA being configured to execute steps including:
[0159] REE-side CA certificate issuance steps: The REE-side CA obtains the encryption certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; the REE-side application generates key material based on security parameters to calculate the local key component S1 and public key component P1; using the encrypted certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA; the TA calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate.
[0160] The steps for REE-side CA to verify TEE-side TA are as follows: REE-side CA initiates an authentication request; TEE-side TA generates a random number as a challenge code; TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; TA returns the challenge code and signature value to REE-side CA; REE-side verifies the validity of the signature and the validity of the TA certificate. If the verification is successful, it indicates that TA is a trusted application, and the CA's verification of TA is completed.
[0161] Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0162] Fourthly, embodiments of this application provide a Trusted Application (TA) on the Trusted Execution Environment (TEE) side, wherein the Trusted Application (TA) is configured to execute steps including:
[0163] TEE-side TA certificate issuance steps: The trusted application generates and sends a trusted application certificate application to the digital certificate authentication system, and the digital certificate authentication system issues and returns the trusted application certificate;
[0164] The steps for TEE-side TA to verify REE-side CA are as follows: For the challenge code, the REE side signs the code using its locally stored private key component S1; the REE side sends the client application signature to the TEE side; the TEE side signs the code using another private key component S2 of the client application; the signatures from both ends are aggregated to generate the final signature value; the TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA verification of the CA is completed.
[0165] Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
[0166] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0167] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A method for client application authentication and data transmission in a trusted environment, characterized in that, The method for secure data transmission between a client application (CA) on the Rich Execution Environment (REE) side and a trusted application (TA) on the Trusted Execution Environment (TEE) side includes: Trusted identity authentication steps: A digital certificate authentication system is used to issue digital certificates to both applications and generate signature private keys for both applications. Each application uses its signature private key to perform signature operations. The trusted application (TA) and the client application (CA) mutually sign and verify each other to complete the trusted identity authentication of both applications. Secure data transmission steps: The client application CA and the trusted application TA, which have completed trusted identity authentication, negotiate a key. The negotiated session key is generated by the TEE side and then sent to the client application CA. After two decryptions, the client application CA obtains the session key. Based on the session key, the two applications perform secure transmission of encrypted data.
2. The client application authentication and data transmission method in a trusted environment according to claim 1, characterized in that, The trusted identity authentication steps include: Certificate issuance steps: Both applications initiate a trusted service request to the digital certificate authentication system to apply for an application certificate based on the SM2 algorithm. The digital certificate authentication system is responsible for issuing digital certificates to both applications. TEE-side Trusted Application (TA) authentication steps: Perform a signature operation using your own signature private key factor, and send the signature result to the client application (CA) for verification. REE-side client application CA authentication steps: The REE-side client application CA's signing private key uses key splitting, and the REE-side client application CA performs signing operations using collaborative signing. The signing operation results are synthesized into the final private key signature value on the TEE side. Based on collaborative signing technology, the REE-side client application CA independently generates the client application's signing private key in both environments, and stores them securely, ensuring that neither party can obtain the complete signing private key. The signing private key of the client application CA includes: the client application REE-side private key factor and the TEE-side private key factor. The trusted application (TA) verifies the signature value, the validity of the digital certificate message, and the trust chain, and returns the verification result to the client application, allowing or denying the client application's CA access.
3. The client application authentication and data transmission method in a trusted environment according to claim 1, characterized in that, The secure data transmission step further includes: Key negotiation steps: The client application CA and the trusted application TA negotiate a key before transmitting important data, using a one-session-one-key security mechanism; the session key is generated by the trusted application TA and encrypted using the client application CA's encryption certificate; Collaborative decryption steps: The Trusted Application (TA) uses a collaborative decryption mechanism to securely distribute the session key to the Client Application (CA). First, it performs a first decryption using the encryption private key factor of the Client Application (CA) on the TEE side. The result of the first decryption is forwarded to the Client Application (CA) on the REE side. Then, it performs a second decryption using the encryption private key factor of the REE side to obtain the session key. During data transmission, encrypted transmission is performed based on the session key, and the client application CA uses the SM4 algorithm to transmit the data to be transmitted in encrypted form with the trusted application TA.
4. The client application authentication and data transmission method in a trusted environment according to claim 2, characterized in that, The application certificate issuance steps include: TEE-side TA certificate issuance steps: The Trusted Application TA generates and sends a Trusted Application Certificate application to the Digital Certificate Authentication System, and the Digital Certificate Authentication System issues and returns the Trusted Application Certificate; The REE-side CA certificate issuance steps are as follows: The REE-side CA obtains the encryption certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; based on security parameters, the REE-side CA generates key material to calculate the local key component S1 and the public key component P1; using the encryption certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA side; the TA side calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate.
5. The client application authentication and data transmission method in a trusted environment according to claim 2, characterized in that, The TEE Trusted Application TA authentication steps are as follows: The REE-side CA initiates an authentication request; TEE side TA generates a random number as the challenge code; The TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; The TA returns the challenge code and signature value to the CA on the REE side; The REE side verifies the validity of the signature and the TA certificate. If the verification is successful, it indicates that the TA is a trusted application, and the CA's verification of the TA is completed. The CA authentication steps for the REE-side client application are as follows: For the challenge code, the REE side uses the locally stored private key component S1 to sign it; and sends the REE-side client application signature to the TEE side. TEE uses another private key component from the client application to perform S2 signing; Aggregate the signatures from both ends to generate the final signature value; The TEE-side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, thus completing the TA's verification of the CA.
6. The client application authentication and data transmission method in a trusted environment according to claim 3, characterized in that, The key negotiation step includes: Key encryption key splitting steps: The TEE side generates a key encryption key KEK, splits the session encryption key, and splits the original KEK into independent key shares S1, S2, S3. After splitting, it meets two rules, including: minimum threshold requirement and security constraints. The key distribution steps are as follows: the split key share S1 is distributed to the CA application on the REE side, the key share S2 is distributed to the TA application on the TEE side, and the key share S3 is encrypted and stored on the TEE side.
7. The client application authentication and data transmission method in a trusted environment according to claim 3, characterized in that, The collaborative decryption step includes: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key. The trusted application on the TEE side requests a trusted service, generates a session key, and encrypts it using the key encryption key KEK. The trusted application on the TEE side decrypts the encrypted session key using its own key component S2. The intermediate result of the decryption on the TEE side is then passed to the REE-side client application. The REE-side client application decrypts the data using its own key component S1 to finally obtain the session key. The REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA. The TEE-side TA decrypts the session key using components S2 and S3. Based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
8. A client application authentication and data transmission system in a trusted environment, employing the client application authentication and data transmission method in a trusted environment as described in any one of claims 1-7, characterized in that, A system for secure data transmission between a client application (CA) on the Rich Execution Environment (REE) side and a trusted application (TA) on the Trusted Execution Environment (TEE) side, comprising: Trusted Identity Authentication Module: Employing a digital certificate authentication system, digital certificates are issued to both applications. Based on collaborative signature technology, signature private keys are generated for both applications. Each application uses its signature private key to perform signature operations. Specifically, the trusted application TA on the TEE side directly performs signature operations using its signature private key. The client application CA on the REE side uses key splitting for its signature private key and collaborative signature for its signature operations. The signature operation results are then combined on the TEE side to form the final private key signature value. The trusted application TA and the client application CA mutually sign and verify each other, completing the trusted identity authentication of both applications. Secure data transmission module: The client application and the trusted application that have completed trusted identity authentication negotiate a key. The negotiated session key is generated by the TEE side and then sent to the client application using a collaborative decryption mechanism. The session key is obtained after two decryptions. The two applications then perform secure transmission of encrypted data based on the session key.
9. A client application CA on the REE (Rich Execution Environment) side, characterized in that, The client application CA is configured to perform the following steps: REE-side CA certificate issuance steps: The REE-side CA obtains the encryption certificate of the trusted application (TA); the REE-side CA uses key splitting technology to split the private key into S1 and S2 components; the REE-side application generates key material based on security parameters to calculate the local key component S1 and public key component P1; using the encrypted certificate of the trusted application, the client's public key component P1 and security parameters are sent to the TA; the TA calculates the aggregate public key of the client's public key components P1 and P2, generates a certificate issuance request, and submits it to the digital certificate authentication system; the digital certificate authentication system issues and returns the client application certificate. The steps for REE-side CA to verify TEE-side TA are as follows: REE-side CA initiates an authentication request; TEE-side TA generates a random number as a challenge code; TEE-side TA uses its own application signing certificate private key to sign and generate a signature value; TA returns the challenge code and signature value to REE-side CA; REE-side verifies the validity of the signature and the validity of the TA certificate. If the verification is successful, it indicates that TA is a trusted application, and the CA's verification of TA is completed. Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.
10. A Trusted Application (TA) on the Trusted Execution Environment (TEE) side, characterized in that, The trusted application (TA) is configured to perform the following steps: TEE-side TA certificate issuance steps: The trusted application generates and sends a trusted application certificate application to the digital certificate authentication system, and the digital certificate authentication system issues and returns the trusted application certificate; The steps for TEE-side TA to verify REE-side CA are as follows: For the challenge code, the REE side signs it using its locally stored private key component S1; the REE side sends the client application signature to the TEE side; the TEE side signs it using another private key component S2 of the client application; the signatures from both ends are aggregated to generate the final signature value; the TEE side application verifies the validity of the signature and the CA certificate. If the verification is successful, it indicates that the CA is a trusted application, and the TA verification of the CA is completed. Data transmission steps: Before sending important data to the trusted application on the TEE side, the REE-side client application requests a session key; the trusted application on the TEE side requests a trusted service to generate a session key and encrypts it with a key encryption key (KEK); the trusted application on the TEE side decrypts the encrypted session key using its own key component S2; the intermediate result of the decryption on the TEE side is then transmitted to the REE-side client application; the REE-side client application decrypts the data using its own key component S1 to finally obtain the session key; the REE-side client application uses the session key to encrypt important data, encrypts the important data using the national cryptographic algorithm, and transmits the ciphertext data to the TEE-side TA; the TEE-side TA decrypts the session key using components S2 and S3; based on the session key, it decrypts the ciphertext data to obtain the original data and returns the calculation result to the REE-side CA.