Cross-device calling method, device and equipment based on swan gap system and medium

Abstract

The invention relates to a cross-device calling method, device, equipment and medium based on a swan gap system, and relates to the technical field of cross-device calling, and the method comprises the steps: generating a signature certificate key pair in a trusted execution environment, receiving an encrypted certificate key pair encrypted and packaged by a server, recovering the encrypted certificate key pair through a key negotiation mechanism, and sending the recovered encrypted certificate key pair to a server; the recovered encrypted certificate key pair is stored in a trusted execution environment; and receiving to-be-processed data sent by the gap client through the established secure connection with the gap client, and performing signature or decryption operation on the to-be-processed data through the signature certificate key pair and the recovered encryption certificate key pair stored in the trusted execution environment. According to the application, the private key source for identity authentication and signature is ensured to be pure, the private key never leaves a trusted execution environment, and the special key management requirement in a national and cryptographic dual-certificate scene is met.

Description

Technical Field

[0001] This application relates to the field of cross-device invocation technology, specifically to a cross-device invocation method, apparatus, device, and medium based on the HarmonyOS system. Background Technology

[0002] With the rapid development of information technology, information security has become a crucial cornerstone for national security, social stability, and economic development. The National Commercial Cryptography Management System (hereinafter referred to as "National Cryptography") has become a rigid requirement for security compliance in key areas such as government affairs, finance, and the Internet of Things. Using National Cryptography algorithms such as SM2, SM3, and SM4 for identity authentication, data encryption, and signature verification is a necessary means to ensure information security in these areas. Meanwhile, the HarmonyOS operating system, with its unique distributed architecture, breaks down barriers between devices, providing a solid operating system foundation for seamless collaboration and data flow across multiple devices such as mobile phones, tablets, and PCs. However, within the HarmonyOS ecosystem, how to both meet the high compliance requirements of National Cryptography algorithms and leverage the advantages of distributed systems to achieve secure storage and secure cross-device access to "National Cryptography dual certificates" (i.e., signature certificates and encryption certificates) has become a pressing technical challenge.

[0003] Existing solutions are mainly device authentication and communication encryption schemes based on PKI systems. These schemes typically install digital certificates on mobile devices, establish a trust relationship by verifying the certificate chain of the other party with the PC, and then use key negotiation algorithms to derive session keys to establish end-to-end encrypted communication channels.

[0004] While this solution effectively addresses the issues of device authentication and communication channel encryption, it fails to meet the specific key management requirements of the "national cryptographic dual certificate" scenario (especially the problem of how to securely import such keys into the mobile trusted execution environment (TEE). Summary of the Invention

[0005] In view of this, this application provides a cross-device invocation method, apparatus, device and medium based on HarmonyOS system. The main purpose is to solve the technical problems of how existing solutions, although they effectively solve the problems of identity authentication and communication channel encryption between devices, cannot meet the special key management requirements in the "national cryptographic dual certificate" scenario (especially the encryption private key is generated by the server) and how to securely import such keys into the mobile trusted execution environment (TEE).

[0006] Firstly, this application provides a cross-device invocation method based on the HarmonyOS system, executed by the HarmonyOS device, including: Generate a signature certificate key pair in the Trusted Execution Environment (TEE), receive an encrypted certificate key pair that is encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the TEE. Establish a secure connection with the HarmonyOS client; Through the secure connection, the system receives data to be processed sent by the HarmonyOS client, performs signing or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and returns the result of the signing or decryption operation to the HarmonyOS client through the secure connection.

[0007] Secondly, this application provides a cross-device invocation device based on the HarmonyOS system, applied to HarmonyOS devices, including: The recovery module is used to generate a signature certificate key pair in the trusted execution environment, receive an encrypted certificate key pair that is encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the trusted execution environment. Establish a module to create a secure connection with the HarmonyOS client; The receiving module is configured to receive data to be processed sent by the HarmonyOS client through the secure connection, perform signing or decryption operations on the data to be processed using the signing certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and return the result of the signing or decryption operation to the HarmonyOS client through the secure connection.

[0008] Thirdly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the cross-device invocation method based on the HarmonyOS system described in the first aspect.

[0009] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the cross-device invocation method based on the HarmonyOS system described in the first aspect. By employing the above technical solutions, this application provides a cross-device invocation method, apparatus, device, and medium based on the HarmonyOS system. Compared with existing technologies, this application generates a signature certificate key pair in a trusted execution environment, receives an encrypted certificate key pair encapsulated by the server, recovers the encrypted certificate key pair through a key negotiation mechanism, and stores the recovered encrypted certificate key pair in the trusted execution environment; establishes a secure connection with the HarmonyOS client; receives data to be processed sent by the HarmonyOS client through the secure connection, performs signature or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encrypted certificate key pair, and returns the result of the signature or decryption operation to the HarmonyOS client through the secure connection.

[0010] Using the above technical solution, this application employs a separate key generation strategy, generating the signature certificate key pair within the Trusted Execution Environment (TEE) of the HarmonyOS device. This ensures the purity of the private key source used for authentication and signing, guaranteeing it never leaves the TEE and meeting the requirement of absolute privacy for the signature private key. Receiving the encrypted certificate key pair generated and encapsulated by the server preserves the server's control over the encryption key, complying with industry-specific key lifecycle management standards. HarmonyOS uses a key negotiation protocol supported by national cryptographic standards (such as SM2 key exchange), allowing the device and server to negotiate a shared key over a secure channel for encrypting the transmitted encrypted certificate key pair. The negotiation process is based on mutual certificate authentication, ensuring identity legitimacy and meeting the specific key management requirements of the "national cryptographic dual-certificate" scenario.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a cross-device invocation method based on the HarmonyOS system provided in this application embodiment; Figure 2A flowchart illustrating a secure download method using dual national cryptographic certificates is provided as an embodiment of this application. Figure 3 A schematic diagram of a cross-device certificate application process based on StarFlash is provided for an embodiment of this application; Figure 4 This is a schematic diagram of a cross-device calling device based on the HarmonyOS system, provided as an embodiment of this application. Detailed Implementation

[0015] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0016] The following description, with reference to the accompanying drawings, describes a cross-device invocation method, apparatus, device, and medium based on the HarmonyOS system according to embodiments of this application.

[0017] This application provides a cross-device invocation method, apparatus, device, and medium based on the HarmonyOS system. The main purpose is to solve the technical problems of how existing solutions, while effectively solving the problems of identity authentication and communication channel encryption between devices, cannot meet the special key management requirements in the "national cryptographic dual certificate" scenario (especially the encryption private key being generated by the server) and how to securely import such keys into the mobile trusted execution environment (TEE).

[0018] This application provides a cross-device invocation method based on the HarmonyOS system. This method utilizes the Trusted Execution Environment (TEE) of the HarmonyOS device to ensure the security of the certificate key, and implements secure invocation of the mobile device's certificate from the PC side through the StarFlash protocol. Figure 1 As shown, the method specifically includes the following steps: Step 101: Generate a signature certificate key pair in the Trusted Execution Environment (TEE), receive the encrypted certificate key pair encapsulated by the server, recover the encrypted certificate key pair through the key negotiation mechanism, and store the recovered encrypted certificate key pair in the TEE.

[0019] The execution subject of this application is a HarmonyOS device (such as a HarmonyOS phone). This step aims to securely complete the generation and storage of the key pair of national cryptographic dual certificates (i.e., signature certificate and encryption certificate) on the HarmonyOS device, ensuring that the private key never leaves the Trusted Execution Environment (TEE).

[0020] For the embodiments of this application, such as Figure 2As shown, user authentication and request initiation can be performed first. In response to the user's identity authentication completed in the application on the HarmonyOS device (such as a HarmonyOS phone), a request for dual national cryptographic certificates is sent to the server. In this embodiment, user identity authentication methods may include various authentication means such as facial biometrics and SMS verification codes. After successful authentication, the HarmonyOS device application can send a request for dual national cryptographic certificates to the server.

[0021] After receiving the application request for dual national cryptographic certificates, the server can generate a temporary ECC key pair (denoted as tempPubKeyPair) and return the public key of the temporary ECC key pair to the HarmonyOS device.

[0022] After receiving the public key of the temporary ECC key pair, the HarmonyOS device can call the TEE interface (such as the HUKS interface of the HarmonyOS system) to perform the following operations: Generate an SM2 signature certificate key pair (denoted as signKeyPair) in a Trusted Execution Environment (TEE); Construct a certificate signing request (i.e., a PKCS#10 certificate signing request, dual certificate P10) that includes the public key of the SM2 signed certificate key pair and the public key of the temporary ECC key pair returned by the server. At the same time, an import key pair (denoted as unwrapKeyPair_C) for the HarmonyOS client to be used for subsequent key import is generated in the Trusted Execution Environment (TEE). The HarmonyOS device can send the certificate signing request constructed above, along with the public key of the imported key pair from the HarmonyOS client, to the server.

[0023] After receiving the certificate signing request and the public key of the imported key pair from the HarmonyOS client, the server can perform the following processing: The certificate signing request is submitted to a Certificate Authority (CA), which issues a signing certificate (denoted as SignCert) and an encryption certificate (denoted as EncCert). Simultaneously, the encryption certificate key pair (denoted as encKeyPair) is created and stored by the CA, encrypted using the aforementioned temporary ECC key pair, and returned to the server along with the signing certificate and encryption certificate. The server can use the private key of the temporary ECC key pair to decrypt and obtain the plaintext encrypted certificate key pair. The server can also generate a server-side import key pair (denoted as unwrapKeyPair_S). Based on the Elliptic Curve Diffie-Hellman (ECDH) key negotiation algorithm, a shared key (e.g., an AES-256 key) can be derived using the private key of the key pair imported by the server and the public key of the key pair imported by the HarmonyOS client. According to the HarmonyOS TEE key import specification, the plaintext encrypted certificate key pair (encKeyPair) is encapsulated into a keyMaterial structure, and the keyMaterial structure is encrypted using the derived shared key to form the encrypted key material. The public key of the key pair imported by the server and the encrypted key material are then returned to the HarmonyOS device.

[0024] The HarmonyOS device receives the public key and encrypted key material of the imported key pair from the server. Recovery and storage operations are then performed within the trusted execution environment. Specifically, in the trusted execution environment of the HarmonyOS device, the private key of the imported key pair of the HarmonyOS client and the public key of the imported key pair of the server can be used to execute the Elliptic Curve Diffie-Hellman Protocol (ECDH) again, thereby deriving the same shared key as the server. The received key material is decrypted using the shared key. After verifying that the format is correct, the decrypted encryption certificate key is securely imported into the trusted execution environment for storage.

[0025] The signing certificate and encryption certificate are public security parameters that can be saved to the application's private file directory.

[0026] Step 102: Establish a secure connection with the HarmonyOS client.

[0027] In this embodiment, "HarmonyOS client" can refer to a HarmonyOS PC, and "HarmonyOS device" refers to a HarmonyOS mobile phone holding the aforementioned national cryptographic dual certificates. This step establishes a communication link between the two via the StarFlash protocol, and the specific process is as follows: like Figure 3 As shown, firstly, in the lifecycle callback (such as aboutToAppear) after the business page (e.g., a bank transfer page) on the HarmonyOS client has finished loading, the StarShine service interface (e.g., ssap.createServer()) can be called to create a StarShine service instance and configure the corresponding service properties, which may include parameters such as Service ID and Property. After configuration, the broadcast start interface (e.g., advertising.startAdvertising()) can be called to start broadcasting, making the HarmonyOS client discoverable and waiting for mobile phone connections.

[0028] After broadcasting is enabled, the HarmonyOS client screen can display prompts such as "Please open the XX application on your phone to assist in completing security authentication" to guide the user to perform the operation.

[0029] Users can open the designated HarmonyOS device app as prompted and activate the StarScan function. The HarmonyOS device app discovers the StarScan service broadcast by the HarmonyOS client through scanning and establishes a secure StarScan connection with the HarmonyOS client based on the StarScan protocol.

[0030] Step 103: Receive the data to be processed sent by the HarmonyOS client through a secure connection. Perform signing or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair. Return the results of the signing or decryption operations to the HarmonyOS client through the secure connection.

[0031] This application enables remote invocation of HarmonyOS client services to the security capabilities of HarmonyOS devices, specifically including the following process: like Figure 3 As shown, firstly, the HarmonyOS client can send the data to be processed required for business operations to the HarmonyOS device through the established StarFlash secure connection. In this embodiment, the data to be processed includes at least transaction information and ciphertext to be decrypted. For example, when performing a transfer operation, the data to be processed is a transaction summary; in a data decryption scenario, the data to be processed is ciphertext.

[0032] After receiving the data to be processed, the HarmonyOS device can pass it to the Trusted Execution Environment (TUI). The TUI then displays the transaction information to the user for verification. This transaction information includes, but is not limited to, key data such as transaction amount, payee, and operation type.

[0033] The system waits for confirmation from the user based on the trusted user interface. Only after the user confirms that the transaction information is correct and enters the confirmation command will subsequent operations be executed.

[0034] After obtaining user authorization, the system uses the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair to invoke the corresponding algorithm to perform cryptographic operations on the data to be processed. Specifically, in a signing scenario, the signature certificate key pair is used to perform an SM2 signing operation; in a decryption scenario, the encryption certificate key pair is used to perform an SM2 decryption operation.

[0035] Finally, the HarmonyOS device can return the operation result (such as the SM2 signature value or the decrypted plaintext) to the HarmonyOS client via the StarFlash secure connection. After receiving the operation result, the HarmonyOS client and the client can securely disconnect the StarFlash connection, release communication resources, and complete this cross-device security authentication process.

[0036] The method provided in this embodiment effectively solves the problem that the HarmonyOS client cannot perform high-intensity national cryptographic operations when it lacks a local hardware security module. At the same time, by utilizing the trusted execution environment on the HarmonyOS device and the high security of the StarFlash protocol, it ensures that the private key does not leave the trusted execution environment and that operations require user confirmation, which greatly improves the security of financial-grade services and user experience.

[0037] In summary, according to the cross-device invocation method based on the HarmonyOS system provided in this application, compared with the existing technology, this application can generate a signature certificate key pair in a trusted execution environment, receive an encrypted certificate key pair encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the trusted execution environment; establish a secure connection with the HarmonyOS client; receive the data to be processed sent by the HarmonyOS client through the secure connection, perform signature or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encrypted certificate key pair, and return the result of the signature or decryption operation to the HarmonyOS client through the secure connection.

[0038] Using the above technical solution, this application employs a separate key generation strategy, generating the signature certificate key pair within the Trusted Execution Environment (TEE) of the HarmonyOS device. This ensures the purity of the private key source used for authentication and signing, guaranteeing it never leaves the TEE and meeting the requirement of absolute privacy for the signature private key. Receiving the encrypted certificate key pair generated and encapsulated by the server preserves the server's control over the encryption key, complying with industry-specific key lifecycle management standards. HarmonyOS uses a key negotiation protocol supported by national cryptographic standards (such as SM2 key exchange), allowing the device and server to negotiate a shared key over a secure channel for encrypting the transmitted encrypted certificate key pair. The negotiation process is based on mutual certificate authentication, ensuring identity legitimacy and meeting the specific key management requirements of the "national cryptographic dual-certificate" scenario.

[0039] Based on the above Figure 1 The specific implementation of the method shown in this embodiment provides a cross-device invocation device based on the HarmonyOS system, applied to HarmonyOS devices, such as... Figure 4 As shown, the device includes: a recovery module 31, a setup module 32, and a receiving module 33; The recovery module 31 is used to generate a signature certificate key pair in the trusted execution environment, receive an encrypted certificate key pair that is encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the trusted execution environment. Establish module 32, used to establish a secure connection with the HarmonyOS client; The receiving module 33 is used to receive the data to be processed sent by the HarmonyOS client through the secure connection, perform a signing or decryption operation on the data to be processed using the signing certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and return the operation result of the signing or decryption operation to the HarmonyOS client through the secure connection.

[0040] In a specific application scenario, recovery module 31 is specifically used to respond to user authentication completed by the user in the HarmonyOS device application, initiate a national cryptographic dual certificate application request to the server; receive the public key of the temporary ECC key pair generated by the server according to the national cryptographic dual certificate application request; generate an SM2 signature certificate key pair in the trusted execution environment, construct a certificate signing request containing the public key of the SM2 signature certificate key pair and the public key of the temporary ECC key pair, and generate the import key pair of the HarmonyOS client in the trusted execution environment; send the certificate signing request and the import key pair of the HarmonyOS client to the server, and receive the public key of the server import key pair and the encrypted key material returned by the server, wherein the encrypted key material is obtained by the server encapsulating the encrypted certificate key pair using a shared key negotiated based on the elliptic curve Diffie-Hellman protocol.

[0041] In a specific application scenario, the recovery module 31 is specifically used in the trusted execution environment to derive a shared key by using the private key of the imported key pair of the HarmonyOS client and the public key of the imported key pair of the server; to decrypt the key material using the shared key; and to store the decrypted encryption certificate key pair in the trusted execution environment.

[0042] In a specific application scenario, module 32 is specifically used to call the StarShine service interface to create a StarShine service instance and call the start broadcast interface to start broadcasting in the lifecycle callback after the business page of the HarmonyOS client is loaded; by starting StarShine scanning, the broadcast service of the HarmonyOS client is scanned, and a StarShine secure connection is established with the HarmonyOS client through the broadcast service.

[0043] In a specific application scenario, module 32 is established to receive data to be processed sent by the HarmonyOS client through the StarFlash secure connection. The data to be processed includes at least transaction information and encrypted text to be decrypted.

[0044] In a specific application scenario, the receiving module 33 is specifically used to display the transaction information to the user through the trusted user interface. The transaction information includes at least one of the following: transaction amount, payee, and operation type. After receiving a confirmation instruction input by the user based on the transaction information through the trusted user interface, the receiving module performs SM2 signing or SM2 decryption on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair. The receiving module then returns the result of the SM2 signing or SM2 decryption operation to the HarmonyOS client through the StarFlash secure connection and disconnects the StarFlash secure connection.

[0045] It should be noted that other corresponding descriptions of the functional units involved in the cross-device invocation device based on the HarmonyOS system provided in this embodiment can be found in [reference]. Figure 1 The corresponding descriptions in [the document] will not be repeated here.

[0046] Based on the above, Figure 1 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 The method shown.

[0047] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0048] Based on the above, Figure 1 The method shown, and Figure 4 To achieve the above objectives, the present application also provides an electronic device, comprising a storage medium and a processor; the storage medium for storing a computer program; and the processor for executing the computer program to implement the above-described virtual device embodiments. Figure 1 The method shown.

[0049] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0050] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0051] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting cross-device invocation of programs based on the HarmonyOS system, as well as the execution of other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, and to communicate with other hardware and software in the cross-device invocation physical device based on the HarmonyOS system.

[0052] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the prior art, this application can generate a signature certificate key pair in a trusted execution environment, receive an encrypted certificate key pair encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the trusted execution environment; establish a secure connection with the HarmonyOS client; receive the data to be processed sent by the HarmonyOS client through the secure connection, perform signature or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encrypted certificate key pair, and return the result of the signature or decryption operation to the HarmonyOS client through the secure connection.

[0053] Using the above technical solution, this application employs a separate key generation strategy, generating the signature certificate key pair within the Trusted Execution Environment (TEE) of the HarmonyOS device. This ensures the purity of the private key source used for authentication and signing, guaranteeing it never leaves the TEE and meeting the requirement of absolute privacy for the signature private key. Receiving the encrypted certificate key pair generated and encapsulated by the server preserves the server's control over the encryption key, complying with industry-specific key lifecycle management standards. HarmonyOS uses a key negotiation protocol supported by national cryptographic standards (such as SM2 key exchange), allowing the device and server to negotiate a shared key over a secure channel for encrypting the transmitted encrypted certificate key pair. The negotiation process is based on mutual certificate authentication, ensuring identity legitimacy and meeting the specific key management requirements of the "national cryptographic dual-certificate" scenario.

[0054] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0055] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A cross-device invocation method based on the HarmonyOS system, characterized in that, Executed by the HarmonyOS device, the method includes: Generate a signature certificate key pair in the Trusted Execution Environment (TEE), receive an encrypted certificate key pair that is encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the TEE. Establish a secure connection with the HarmonyOS client; Through the secure connection, the system receives data to be processed sent by the HarmonyOS client, performs signing or decryption operations on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and returns the result of the signing or decryption operation to the HarmonyOS client through the secure connection.

2. The method according to claim 1, characterized in that, The step of generating a signature certificate key pair in a trusted execution environment and receiving an encrypted certificate key pair encrypted and encapsulated by the server includes: In response to the user's identity authentication completed in the HarmonyOS device application, a request for dual national cryptographic certificates is initiated to the server. Receive the public key of the temporary ECC key pair generated by the server based on the national cryptographic dual certificate application request; In the trusted execution environment, an SM2 signature certificate key pair is generated, a certificate signing request is constructed containing the public key of the SM2 signature certificate key pair and the public key of the temporary ECC key pair, and the import key pair of the HarmonyOS client is generated in the trusted execution environment. The certificate signing request and the import key pair of the HarmonyOS client are sent to the server, and the server returns the public key of the server import key pair and the encrypted key material. The encrypted key material is obtained by the server encapsulating the encrypted certificate key pair with a shared key negotiated based on the elliptic curve Diffie-Hellman protocol.

3. The method according to claim 2, characterized in that, The step of recovering the encryption certificate key pair through a key negotiation mechanism and storing the recovered encryption certificate key pair in the trusted execution environment includes: In the trusted execution environment, the private key of the imported key pair of the HarmonyOS client and the public key of the imported key pair of the server are used to execute the elliptic curve Diffie-Hellman protocol to derive a shared key. The shared key is used to decrypt the key material, and the decrypted encryption certificate key pair is stored in the trusted execution environment.

4. The method according to claim 1, characterized in that, The establishment of a secure connection with the HarmonyOS client includes: In the lifecycle callback after the business page of the HarmonyOS client is loaded, the StarShine service interface is called to create a StarShine service instance, and the start broadcast interface is called to start broadcasting; By initiating StarScan, the broadcast service of the HarmonyOS client is scanned, and a StarScan secure connection is established with the HarmonyOS client through the broadcast service.

5. The method according to claim 4, characterized in that, The process of receiving pending data sent by the HarmonyOS client through the secure connection includes: Through the StarFlash secure connection, the system receives pending data sent by the HarmonyOS client, wherein the pending data includes at least transaction information and encrypted text to be decrypted.

6. The method according to claim 5, characterized in that, The process of performing a signature or decryption operation on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and returning the result of the signature or decryption operation to the HarmonyOS client through the secure connection, includes: The transaction information is displayed to the user through the trusted user interface; After receiving a confirmation instruction from the user through the trusted user interface based on the transaction information, the system performs SM2 signing or SM2 decryption on the data to be processed using the signature certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair. The result of the SM2 signing or SM2 decryption operation is returned to the HarmonyOS client through the StarSpark secure connection, and then the StarSpark secure connection is disconnected.

7. The method according to claim 6, characterized in that, The transaction information includes at least one of the following: transaction amount, payee, and operation type.

8. A cross-device invocation device based on the HarmonyOS system, characterized in that, Applied to HarmonyOS devices, including: The recovery module is used to generate a signature certificate key pair in the trusted execution environment, receive an encrypted certificate key pair that is encrypted and encapsulated by the server, recover the encrypted certificate key pair through a key negotiation mechanism, and store the recovered encrypted certificate key pair in the trusted execution environment. Establish a module to create a secure connection with the HarmonyOS client; The receiving module is configured to receive data to be processed sent by the HarmonyOS client through the secure connection, perform signing or decryption operations on the data to be processed using the signing certificate key pair stored in the trusted execution environment and the recovered encryption certificate key pair, and return the result of the signing or decryption operation to the HarmonyOS client through the secure connection.

9. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the cross-device invocation method based on HarmonyOS as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the cross-device invocation method based on the HarmonyOS system as described in any one of claims 1 to 7.

Images