User identity verification method and system

Abstract

The embodiment of the invention discloses a user identity verification method and system. According to the method, a group of asymmetric security keys are generated for an identity verification link in a service process, a security public key in the security keys is stored in a trusted execution environment of first terminal equipment, and a security private key in the security keys is stored in a trusted execution environment of second terminal equipment. When identity verification is carried out, the identity credential is encrypted through the security public key in the trusted execution environment of the first terminal device, then the encrypted identity credential is sent to the second terminal device, and the identity credential is decrypted through the security private key in the trusted execution environment of the second terminal device. And finally, the legality of the user identity is determined by verifying the consistency of the identity certificates held by the two equipment terminals. Through the method, an attacker must simultaneously break through two equipment terminals to successfully attack, so that the attack difficulty is greatly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of trusted execution environment, and in particular to a user identity verification method and system. Background Art

[0002] In Web3.0 applications, an asymmetric encryption algorithm is usually used to generate a pair of public and private keys. The private key is usually stored in the business application terminal held by the user, and the public key is made public (usually stored on the blockchain). When conducting business, the user uses the private key to sign the business data in the business application terminal, and the signed data is sent to the blockchain. The public key is used to verify the signature on the blockchain. After the signature verification is passed, the blockchain data is rewritten to complete the business operation. However, in the above process, there is a risk of the private key being stolen. Summary of the invention

[0003] One or more embodiments of this specification provide a user identity verification method and system, which can effectively reduce the risk of private key theft in the identity authentication stage of Web3.0 applications based on asymmetric encryption.

[0004] In a first aspect, a user identity verification method is provided, which is applicable to a first terminal device, wherein a first public key, a first private key, and an initial key of the first terminal device are stored in a first trusted execution environment of the first terminal device, and a second public key of a second terminal device is stored in a second trusted execution environment of the second terminal device; the method includes: Responding to a signature request from a user, obtaining business data; Generate a one-time first password using the initial key in the first trusted execution environment, and encrypt the first password using the second public key to obtain a password encryption result; Sending the password encryption result to the second terminal device, so that the second terminal device decrypts the password encryption result using the second private key in the second trusted execution environment to obtain a second password; Obtaining the second password sent by the second terminal device, and verifying the consistency of the second password with the first password in the first trusted execution environment; In response to verifying that the second password is consistent with the first password, the business data is signed using the first private key in the first trusted execution environment.

[0005] As an optional implementation manner of the method of the first aspect, the method further includes: In response to a user's request to generate a first asymmetric key pair, generating the first public key and the first private key in the first trusted execution environment; The first public key and the first private key are stored in the first trusted execution environment.

[0006] As an optional implementation manner of the method of the first aspect, the method further includes: Obtaining the second public key sent by the second terminal device; Authenticate the user's identity; After authentication is passed, the second public key is stored in the first trusted execution environment.

[0007] As an optional implementation manner of the method of the first aspect, the method further includes: Calculating a digest of the business data in the first trusted execution environment, and encrypting the digest using the second public key to obtain a digest encryption result; Sending the digest encryption result to the second terminal device, so that the second terminal device decrypts the digest encryption result using the second private key in the second trusted execution environment to obtain the digest; showing the digest and the second password sent by the second terminal to the user; In response to the user's confirmation of the digest and the second password, a verification process for the second password is performed.

[0008] As an optional implementation manner of the method described in the first aspect, the first password is generated based on the initial key and the timestamp, and the first password is valid within a preset time period.

[0009] As an optional implementation manner of the method of the first aspect, sending the password encryption result to the second terminal device specifically includes: Displaying the QR code of the password encryption result to the user; The password encryption result is sent to the second terminal device through the user's operation of scanning and parsing the QR code of the password encryption result using the second terminal device.

[0010] In a second aspect, another user identity verification method is provided, which is applicable to a second terminal device, wherein a second private key of the second terminal device is stored in a second trusted execution environment of the second terminal device, and a second public key of the second terminal device is stored in a first trusted execution environment of the first terminal device; the method includes: In response to obtaining the password encryption result sent by the first terminal device based on the business data signature requirement, decrypting the password encryption result using the second private key in the second trusted execution environment to obtain a second password; the password encryption result is obtained by the first terminal device encrypting the first password using the second public key in the first trusted execution environment; The second password is sent to the first terminal device, so that the first terminal device verifies the consistency of the second password with the first password in the first trusted execution environment, and confirms the legitimacy of the user identity based on the consistency verification result.

[0011] As an optional implementation manner of the method according to the second aspect, sending the second password to the first terminal device specifically includes: displaying the second password to the user; The second password is input into the first terminal device through a password input operation by a user on the first terminal device.

[0012] As an optional implementation manner of the method of the second aspect, the method further includes: In response to a user's request to generate a second asymmetric key pair, generating the second public key and the second private key in the second trusted execution environment; The second public key and the second private key are stored in the second trusted execution environment.

[0013] Specifically, storing the second public key and the second private key in the second trusted execution environment specifically includes: Authenticate the user's identity; After authentication is passed, the second public key and the second private key are stored in the second trusted execution environment.

[0014] As an optional implementation manner of the method of the second aspect, the method further includes: Displaying the QR code of the second public key to the user; The second public key is sent to the first terminal device through an operation in which a user uses the first terminal device to scan and parse the QR code of the second public key.

[0015] As an optional implementation manner of the method of the second aspect, the method further includes: In response to obtaining the digest encryption result sent by the first terminal device, decrypting the digest encryption result using the second private key in the second trusted execution environment to obtain a digest; the digest encryption result is obtained by encrypting the digest of the business data by the first terminal device using the second public key in the first trusted execution environment; presenting the summary and the second password to the user; After the user confirms the summary, the user inputs the second password into the first terminal device, so that the first terminal device executes a verification process for the second password.

[0016] In a third aspect, a user identity verification system is provided, including a first terminal device and a second terminal device, wherein a first public key, a first private key, an initial key and a second public key of the first terminal device are stored in a first trusted execution environment of the first terminal device, and a second private key of the second terminal device is stored in a second trusted execution environment of the second terminal device; The first terminal device is configured to obtain business data in response to a signature request made by a user; generate a one-time first password using the initial key in the first trusted execution environment, and encrypt the first password using the second public key to obtain a password encryption result; send the password encryption result to the second terminal device; obtain the second password sent by the second terminal device, and verify the consistency of the second password with the first password in the first trusted execution environment; in response to verifying that the second password is consistent with the first password, sign the business data using the first private key in the first trusted execution environment.

[0017] The second terminal device is configured to, in response to obtaining the password encryption result sent by the first terminal device, decrypt the password encryption result using the second private key in the second trusted execution environment to obtain the second password, and send the second password to the first terminal device.

[0018] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the computer program implements one of the above-mentioned user identity verification methods, or executes another of the above-mentioned user identity verification methods.

[0019] In a fifth aspect, an electronic device is provided, including: One or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, execute one of the above-mentioned user identity verification methods, or execute another of the above-mentioned user identity verification methods.

[0020] The beneficial effect of the user identity verification method described in one or more embodiments of this specification is that the method generates a set of asymmetric security keys for the identity verification link in the business process, stores the security public key in the trusted execution environment of the first terminal device, and stores the security private key in the trusted execution environment of the second terminal device. When performing identity verification, the identity credential is encrypted by the security public key in the trusted execution environment of the first terminal device, and then the encrypted identity credential is sent to the second terminal device, and the identity credential is decrypted by the security private key in the trusted execution environment of the second terminal device, and finally the legitimacy of the user identity is determined by verifying the consistency of the identity credentials held by the two device terminals. With this method, the attacker must simultaneously break into two device terminals in order to successfully attack, which greatly increases the difficulty of the attack.

[0021] In addition, the entire identity verification process of the above-mentioned user identity verification method is completed in the trusted execution environment of the two device terminals, which is essentially an atomic operation, ensuring that even if the device terminal is compromised, the attacker cannot call the relevant TA interface for signing.

[0022] The identity verification system described in the embodiments of this specification also has the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0024] Figure 1 It is a flowchart of an existing identity authentication method based on an asymmetric encryption algorithm in an application scenario.

[0025] Figure 2 A schematic diagram of the structure of a user identity verification system provided for one or more embodiments of this specification.

[0026] Figure 3 A flowchart of a user identity verification method provided for one or more embodiments of this specification.

[0027] Figure 4 A flowchart of another user identity verification method provided for one or more embodiments of this specification.

[0028] Figure 5 A flowchart of a user identity verification method provided in one or more embodiments of this specification in a specific scenario.

[0029] Figure 6 A schematic diagram of the structure of an electronic device provided for one or more embodiments of this specification. DETAILED DESCRIPTION

[0030] First of all, it should be noted that the terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the present invention. The singular forms "a", "the" and "the" used in the embodiments of the present invention and the appended claims are also intended to include plural forms, unless the context clearly indicates otherwise.

[0031] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0032] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0033] In Web3.0 applications, asymmetric encryption algorithms (such as RSA, ECC, etc.) are usually used to generate a pair of public and private keys. The user keeps the private key himself (for example, in a mobile terminal) and makes the public key public (usually stored in the blockchain). When conducting business (such as digital asset transfer), the user signs with the private key at the terminal, and then sends the signature data to the blockchain. The signature is verified using the public key on the blockchain. After the signature is verified, the blockchain data is rewritten to complete the business operation. However, since the private key is stored in the terminal held by the user, once the terminal is lost, the private key may be stolen. In other areas of Web3.0, such as decentralized identity, since users also need to keep their own private keys, there is also a risk of theft during the use of private keys.

[0034] Please refer to Figure 1 , Figure 1 A schematic diagram of the process of an existing identity authentication method based on an asymmetric encryption algorithm in an application scenario is shown.

[0035] like Figure 1 As shown, the above-mentioned identity authentication method based on asymmetric encryption algorithm is implemented by a business application terminal, a security application terminal and a business server. The business application terminal deploys an application APP. A TOTP generator is deployed in the security application terminal. The TOTP generator is used to generate a one-time dynamic password using the TOTP algorithm. The basic principle of the TOTP algorithm is to combine an initial key and a timestamp to generate a dynamic password. This dynamic password has a time limit and expires after a predetermined period of time.

[0036] Figure 1 The method shown mainly comprises two phases: an asymmetric key generation phase and a signing phase.

[0037] The process of asymmetric key generation phase includes: Step 1: The user operates on the application APP of the business application terminal to request the application APP to generate an asymmetric business key.

[0038] Step 2: The application APP generates an asymmetric business key in response to the user operation.

[0039] Step 3: The application APP generates a TOTP key (that is, the initial key used to implement the TOTP algorithm) generation request and sends the TOTP key generation request to the business server of the application APP.

[0040] Step 4: The service server generates a TOTP key in response to the TOTP key generation request and saves the TOTP key.

[0041] Step 5: The business server sends the TOTP key to the application APP.

[0042] Step 6: Use the APP to generate a QR code for the TOTP key and display the QR code to the user.

[0043] Step 7: The user scans the QR code of the TOTP key through the TOTP generator on the secure application terminal.

[0044] Step 8: The TOTP generator obtains the QR code of the TOTP key.

[0045] Step 9: The TOTP generator parses the QR code of the TOTP key and saves the obtained TOTP key.

[0046] Step 10: The TOTP generator shows the user through the secure application terminal that the TOTP key has been saved.

[0047] Step 11: After the user learns that the TOTP generator has successfully saved the TOTP key, the user closes the QR code of the TOTP key displayed on the business application terminal.

[0048] Step 12: The service application terminal sends an OTP password verification request to the user.

[0049] Step 13: The user submits an OTP password reading request to the TOTP generator by operating the security application terminal.

[0050] Step 14: The TOTP generator generates an OTP password based on the TOTP secret key and the current timestamp.

[0051] Step 15: The security application terminal displays the OTP password generated by the TOTP generator to the user.

[0052] Step 16: The user reads the OTP password displayed by the security application terminal and enters the read OTP password into the application APP of the business application terminal.

[0053] Step 17: The application sends the OTP password entered by the user to the business server for verification. The business server will generate an OTP password based on the TOTP key and the current timestamp, and verify the consistency of the generated OTP password and the received OTP password. If the two OTP passwords are consistent, the verification is determined to be successful, otherwise, the verification is determined to be unsuccessful.

[0054] Step 18: After the business server verifies the OTP password entered by the user, the business server sends a verification success message to the application APP.

[0055] Step 19: Use the APP to save the asymmetric business key.

[0056] Step 20: The application APP shows the user that the creation of the asymmetric business key is complete.

[0057] The signing phase includes: Step 21: The user initiates a signature request for business data in the application APP.

[0058] Step 22: The application APP starts the signing process, which specifically includes obtaining the signed business data and related business public keys.

[0059] Step 23: The application APP jumps to the OTP password verification page.

[0060] Step 24: The user sends a request to the TOTP generator to obtain the OTP password by operating the security application terminal.

[0061] Step 25: The TOTP generator generates an OTP password based on the TOTP secret key and timestamp.

[0062] Step 26: The TOTP generator displays the OTP password to the user through the secure application terminal.

[0063] Step 27: The user reads the OTP password displayed by the security application terminal and enters the OTP password into the OTP password verification page of the application APP.

[0064] Step 28: The application APP sends the OTP password to the application server for verification. The application server will generate an OTP password based on the TOTP key and the current timestamp, and verify the consistency of the generated OTP password and the received OTP password. If the two OTP passwords are consistent, the verification is determined to be successful, otherwise, the verification is determined to be unsuccessful.

[0065] Step 29: After the business server verifies the OTP password entered by the user, the business server sends a verification success message to the application APP.

[0066] Step 30: The application APP uses the business private key to sign the business data.

[0067] Step 31: The application APP displays the signature service completion information to the user.

[0068] The above is Figure 1 The specific process of the identity authentication method based on the asymmetric encryption algorithm is shown in FIG. 1 . From this process, it can be seen that: Figure 1 The method shown has the following main drawbacks: (1) The TOTP key is stored in the business server. If the business server is attacked, the TOTP key stored in it will be at risk of large-scale leakage.

[0069] (2) The user's business private key is stored in the REE environment, which refers to the environment in which traditional operating systems and applications run, also known as the normal execution environment. In the REE environment, applications and operating systems run in the same execution environment, so they are exposed to threats from operating system vulnerabilities, malware, and attackers, and there is a risk that the business private key may be directly stolen.

[0070] (3) The user's private key signature process is also completed in the REE environment. During this process, there is a risk that the application app may be hacked and the attacker may bypass the OTP verification and directly call the relevant interface signature.

[0071] It can be seen from this that in the current Web3.0 application's asymmetric encryption-based identity authentication process, there is a risk of private key theft in multiple links.

[0072] In summary, there is an urgent need for an effective user identity verification solution in the prior art, so as to effectively resist attacks on user keys in the identity authentication link of Web3.0 applications.

[0073] In view of this, one or more embodiments of this specification propose a user identity verification method and device, which can effectively reduce the risk of private key theft in the identity authentication stage of Web3.0 applications based on asymmetric encryption.

[0074] The user identity verification method and device described in one or more embodiments of this specification will be further described in detail below in conjunction with the drawings and specific embodiments of the specification, but this detailed description does not constitute a limitation on the embodiments of this specification.

[0075] Please refer to Figure 2 , Figure 2 A user identity verification system is shown, which includes a first terminal device 201 and a second terminal device 202. The first public key, the first private key, the initial key of the first terminal device 201 and the second public key of the second terminal device 202 are stored in the first trusted execution environment of the first terminal device 201. The second private key of the second terminal device 202 is stored in the second trusted execution environment of the second terminal device 202.

[0076] exist Figure 2 In the user identity verification system shown, the first terminal device 201 is configured to perform the following steps: Responding to a signature request from a user, obtaining business data; Generate a one-time first password using an initial key in the first trusted execution environment, and encrypt the first password using a second public key to obtain a password encryption result; Send the password encryption result to the second terminal device 202; Obtaining a second password sent by the second terminal device 202, and verifying the consistency of the second password with the first password in the first trusted execution environment; In response to verifying that the second password is consistent with the first password, the business data is signed using the first private key in the first trusted execution environment.

[0077] exist Figure 2 In the user identity verification system shown, the second terminal device 202 is configured to perform the following steps: In response to obtaining the password encryption result sent by the first terminal device 201 , the password encryption result is decrypted using the second private key in the second trusted execution environment to obtain the second password, and the second password is sent to the first terminal device 201 .

[0078] It can be seen that in Figure 2In the user identity verification system shown, a set of asymmetric security keys, namely the second public key and the second private key of the second terminal device 202, is used to ensure the confidentiality of the user identity certificate (that is, the first password and the second password) verification process. It mainly improves the anti-attack ability of the entire identity verification process in three aspects. First, the second public key is stored in the trusted execution environment of the first terminal device 201, and the second private key is stored in the trusted execution environment of the second terminal device 202, so that the attacker must break into two device terminals at the same time to successfully attack, which greatly increases the difficulty of the attacker's attack. Second, the identity certificate is encrypted by the second public key and the second private key is decrypted by the identity certificate, which ensures that the transmission process of the identity certificate is encrypted, and the second private key is not transmitted separately during the transmission process of the entire identity certificate. Third, the encryption process of the identity certificate is executed in the trusted execution environment of the first terminal device 201, and the decryption process of the identity certificate is executed in the trusted execution environment of the second terminal device 202, so that the entire identity certificate encryption and decryption process is an atomic operation, ensuring that even if the device terminal is broken, the attacker cannot call the relevant TA interface for signing.

[0079] Therefore, by implementing the above-mentioned user identity verification system, it is possible to effectively resist attacks on user keys by attackers in different links of identity authentication of Web3.0 applications.

[0080] The specific working process of the first terminal device 201 and the second terminal device 202 in the above user identity verification system will be described below in conjunction with specific implementation methods.

[0081] Please refer to Figure 3 , Figure 3 This is a flowchart of a user identity verification method proposed in one or more embodiments of this specification. Figure 3 The method is applicable to the first terminal device 201, and the first terminal device 201 completes the verification of the legitimacy of the user identity through interaction with the second terminal device 202. Figure 3 Before the user identity verification method shown, the first terminal device 201 needs to be initialized. Specifically, the first public key, the first private key, the initial key of the first terminal device 201 and the second public key of the second terminal device 202 are stored in the first trusted execution environment of the first terminal device 201.

[0082] In some implementations, the specific process for the first terminal device 201 to obtain the first public key and the first private key may be: the first terminal device 201 generates and stores the first public key and the first private key in the first trusted execution environment in response to the user's request to generate a first asymmetric key pair.

[0083] In some more specific implementations, the first trusted execution environment of the first terminal device 201 may also authenticate the user identity before storing the first public key and the first private key. For example, the identity of the user operating the first terminal device 201 may be verified by account and password login, face recognition, or other verification methods. After the authentication is passed, the first trusted execution environment of the first terminal device 201 will store the first public key and the first private key, thereby completing the first asymmetric key pair generation service.

[0084] In some implementations, for obtaining the initial key, the first terminal device 201 may obtain the initial key from a trusted institution by means of confidential transmission, or may directly generate the initial key in the first executable environment, or may directly use the first private key generated as the initial key. In this embodiment, there is no restriction on the way the first terminal device 201 obtains the initial key, as long as the initial key is only held by the first terminal device 201 and stored in the trusted execution environment of the first terminal device 201.

[0085] In some implementations, the second public key of the second terminal device 202 may be obtained in the following manner: First, the user makes a request to generate a second asymmetric key pair on the second terminal device 202. In response to the user's request to generate a second asymmetric key pair, the second terminal device 202 generates a second public key and a second private key in a second trusted execution environment and stores at least the second private key.

[0086] In some embodiments, before the second public key and the second private key are generated and stored in the second trusted execution environment of the second terminal device 202, the user identity can also be authenticated. For example, the identity of the user operating the second terminal device 202 can be verified by account and password login, face recognition, or other verification methods. After the authentication is passed, the second trusted execution environment of the second terminal device 202 will store the second public key and the second private key, or only store the second private key, thereby completing the second asymmetric key pair generation service.

[0087] Next, the second terminal device 202 sends the second public key to the first terminal device 201, and the first terminal device 201 stores the second public key in the first trusted execution environment.

[0088] In some embodiments, before the first terminal device 201 stores the second public key in the first trusted execution environment, the user identity can also be authenticated. For example, the identity of the user operating the first terminal device 201 can be verified by account and password login, face recognition, or other verification methods. After the authentication is passed, the first trusted execution environment of the first terminal device 201 will store the second public key.

[0089] After the initialization is completed, the first terminal device 201 executes the above-mentioned user identity verification method, which specifically includes steps S300 to S308.

[0090] S300: Acquire business data in response to a signature request from a user.

[0091] The above-mentioned business data refers to data that needs to be signed, and the business data is usually in plain text. The first terminal device 201 can obtain the business data in any manner, and this embodiment does not limit this.

[0092] S302: Generate a one-time first password using an initial key in the first trusted execution environment, and encrypt the first password using a second public key to obtain a password encryption result.

[0093] In some embodiments, a TOTP algorithm may be used in the first trusted execution environment to generate the first password. The TOTP (Time-Based One-Time Password) algorithm is a time-based single-time password algorithm used to generate a one-time password (OTP). The basic principle of the TOTP algorithm is to combine an initial key and a timestamp to generate a dynamic password. The validity period of the dynamic password is based on time, usually valid for a period of time (e.g., 30 seconds), and then the dynamic password will automatically expire.

[0094] The process of generating the first password based on the TOTP algorithm is as follows: The initial key and timestamp are calculated using a hash algorithm (usually HMAC-SHA1) to obtain a hash value. According to the provisions of the hash value, a part of the hash value is intercepted as the initial dynamic password. This initial dynamic password can be directly used as the first password, or the initial dynamic password can be further processed, such as formatting and padding operations, to generate the final first password.

[0095] Finally, the first public key is used to encrypt the first password in the first trusted execution environment of the first terminal device 201 to obtain a password encryption result.

[0096] Trusted Execution Environment (TEE) is a secure environment that provides a trusted execution environment to protect sensitive data and perform sensitive operations. In this step S302, the encryption process of the first password is completed in the first trusted execution environment of the first terminal device 201, so that an attacker cannot obtain the first password by attacking the encryption process of the first password.

[0097] S304: Send the password encryption result to the second terminal device 202, so that the second terminal device 202 decrypts the password encryption result using the second private key in the second trusted execution environment to obtain the second password.

[0098] In some implementations, the first terminal device 201 may generate a QR code of the password encryption result and then display the QR code of the password encryption result to the user. The user uses the second terminal device 202 to scan and parse the QR code of the password encryption result to obtain the password encryption result.

[0099] It can be seen from the above initialization process that the second trusted execution environment of the second terminal device 202 stores the second private key of the second terminal device 202. By using the secure storage of the trusted execution environment TEE, it is ensured that even if the user's device is lost or stolen, the second private key cannot be maliciously exported.

[0100] Since the second public key and the second private key are a pair of asymmetric keys, the second private key can be used to decrypt the password encryption result, and the password encryption result is recorded as the second password.

[0101] In this step S304, the decryption process of the password encryption result is completed in the second trusted execution environment of the second terminal device 202, so that an attacker cannot obtain the second password by attacking the decryption process of the password encryption result.

[0102] In some implementations, the first terminal device 201 may also send a digest encryption result of the service data while sending the password encryption result. The digest encryption result is obtained by encrypting the service data digest using the second public key in the first trusted execution environment by the first terminal device 201.

[0103] Correspondingly, the second terminal device 202 can also obtain the digest encryption result sent by the first terminal device 201, and decrypt the digest encryption result using the second private key in the second trusted execution environment to obtain the digest. Then the second terminal device 202 displays the digest and the second password to the user, so that the user knows the purpose of the signature before entering the second password to prevent misoperation. After the user confirms the digest, he enters the second password into the first terminal device 201.

[0104] S306: Obtain the second password sent by the second terminal device 202, and verify the consistency of the second password with the first password in the first trusted execution environment.

[0105] Specifically, before verifying the consistency of the second password with the first password, it is necessary to first verify whether the second password is valid. If valid, the second password is compared with the first password for consistency. If invalid, the user is fed back information that the password has expired.

[0106] If the second password is consistent with the first password, the verification is determined to be successful, indicating that the user's identity is legal. If the second password is inconsistent with the first password, the verification is determined to be unsuccessful.

[0107] S308: In response to verifying that the second password is consistent with the first password, signing the business data using the first private key in the first trusted execution environment.

[0108] When it is verified that the second password is consistent with the first password, it indicates that the user's identity is legitimate. Only then will the first terminal device 201 use the first private key to sign the business data in the first trusted execution environment. In this step S308, the first private key used for signing is saved in the first trusted execution environment of the first terminal device 201. By using the secure storage of the trusted execution environment TEE, it is ensured that even if the user's device is lost or stolen, the first private key cannot be maliciously exported. In addition, this step S308 also sets the signing operation to be completed in the first trusted execution environment, which is essentially an atomic operation, so that attackers cannot obtain the first private key by attacking the signing process.

[0109] Please refer to the following Figure 4 , Figure 4 This is a flow chart of another user identity verification method proposed in one or more embodiments of this specification. Figure 4 The method is applicable to the second terminal device 202, and the second terminal device 202 completes the verification of the legitimacy of the user identity through interaction with the first terminal device 201. Figure 4 Before the user identity verification method is shown, the second terminal device 202 needs to be initialized. Specifically, the second private key is stored in the second trusted execution environment of the second terminal device 202.

[0110] In some implementations, the second private key is stored in the second trusted execution environment of the second terminal device 202, specifically in the following manner: First, the user makes a request to generate a second asymmetric key pair on the second terminal device 202. In response to the user's request to generate a second asymmetric key pair, the second terminal device 202 generates a second public key and a second private key in a second trusted execution environment and stores at least the second private key.

[0111] In some more specific implementations, the second trusted execution environment of the second terminal device 202 may also authenticate the user identity before storing the second private key. For example, the identity of the user operating the second terminal device 202 may be verified by account and password login, face recognition, etc. After the authentication is passed, the second trusted execution environment of the second terminal device 202 will store the second private key, thereby completing the second asymmetric key pair generation service.

[0112] After the initialization is completed, the second terminal device 202 executes the above-mentioned another user identity verification method, which specifically includes steps S400 to S402.

[0113] S400: In response to obtaining the cryptographic encryption result sent by the first terminal device 201 based on the business data signature requirement, decrypting the cryptographic encryption result using the second private key in the second trusted execution environment to obtain a second password.

[0114] The above password encryption result is obtained by the first terminal device 201 encrypting the first password using the second public key in the first trusted execution environment.

[0115] In some implementations, the first terminal device 201 may also send a digest encryption result of the service data while sending the password encryption result. The digest encryption result is obtained by encrypting the service data digest using the second public key in the first trusted execution environment by the first terminal device 201.

[0116] Correspondingly, the second terminal device 202 can also obtain the digest encryption result sent by the first terminal device 201, and decrypt the digest encryption result using the second private key in the second trusted execution environment to obtain the digest. Then the second terminal device 202 displays the digest and the second password to the user, so that the user knows the purpose of the signature before entering the second password to prevent misoperation. After the user confirms the digest, he enters the second password into the first terminal device 201.

[0117] S402: Send the second password to the first terminal device 201 to verify the legitimacy of the user identity.

[0118] After the second terminal device 202 sends the second password to the first terminal device 201, the first terminal device 201 verifies the consistency of the second password with the first password in the first trusted execution environment, and confirms the legitimacy of the user identity based on the consistency verification result.

[0119] Specifically, the first terminal device 201 first checks whether the second password is valid, and if so, continues to check the consistency between the second password and the first password. If not, sends a password expiration message to the user.

[0120] If the second password is consistent with the first password, it is determined that the verification is successful and the user identity is legitimate. At this time, the first terminal device 201 can use the first private key to perform a signing operation in the first trusted execution environment.

[0121] Regarding the identity verification method implemented by the interaction between the first terminal device 201 and the second terminal device 202, the following will be combined with Figure 5 To provide a specific description.

[0122] Please refer to Figure 5 , Figure 5 A flowchart of a user identity verification method proposed in one or more embodiments of this specification in a specific scenario.

[0123] exist Figure 5 The scenario shown mainly includes a first terminal device 201 and a second terminal device 202. The first terminal device 201 is used as a business application terminal, and is deployed with an application APP and a business key management TA. The business key management TA is an application running in the TEE environment of the business application terminal. The second terminal device 202 is used as a security application terminal, and is deployed with a security key APP and a security key management TA. The full key management TA is an application running in the TEE environment of the security application terminal. Unlike traditional applications, TA runs in a restricted security environment and is isolated from the operating system and other applications. This isolation can protect TA's code and data from malware and attackers.

[0124] like Figure 5 The user identity verification method mainly includes two stages: an asymmetric key generation stage and a business key signing stage.

[0125] The asymmetric key generation phase mainly includes the following steps: Step 501: The user operates on the application APP of the business application terminal to request the application APP to generate an asymmetric business key pair (business public key and business private key).

[0126] Step 502: The application APP requests the service key management TA to generate a service key pair.

[0127] Step 503: The service key management TA generates a service key pair and saves the service key pair.

[0128] Step 504: The user operates on the security key APP of the security application terminal to request the security key APP to generate an asymmetric security key pair (a security public key and a security private key).

[0129] Step 505: The security key APP generates a security key pair and stores the security key pair in the security key management TA.

[0130] Step 506: The security key management TA sends the security public key to the security key APP.

[0131] Step 507: The security key APP generates a security public key QR code.

[0132] Step 508: The security key APP displays the security public key QR code to the user.

[0133] Step 509: The user obtains the security public key QR code through the application APP of the business application terminal.

[0134] Step 510: The application APP initiates authentication to the user and obtains the user's authentication information.

[0135] Step 511: User authentication is passed.

[0136] Step 512: Use the APP to scan the security public key QR code.

[0137] Step 513: Use the APP to parse the security public key QR code to obtain the security public key.

[0138] Step 514: The application APP saves the security public key to the business key management TA.

[0139] Step 515: The business key management TA feeds back security public key storage completion information.

[0140] The business key signing phase mainly includes the following steps: Step 516: The user initiates a signature request for business data in the application APP.

[0141] Step 517: The application APP obtains the service data and requests a signature from the service key management TA.

[0142] Step 518: The business key management TA generates an OTP password based on the pre-stored initial key, and encrypts the OTP password with the secure public key to obtain a password encryption result. In addition, the business key management TA can also summarize the business data, and then encrypt the summary with the secure public key to obtain a summary encryption result.

[0143] Step 519: The business key management TA displays the QR code of the password encryption result and the QR code of the digest encryption result to the user.

[0144] Step 520: The user scans the QR code of the password encryption result and the QR code of the digest encryption result through the security key app of the security application terminal.

[0145] Step 521: The security key app parses the QR code of the password encryption result and the QR code of the summary encryption result to obtain the password encryption result and the summary encryption result.

[0146] Step 522: The security key app sends the password encryption result and the digest encryption result to the security key management TA and requests decryption.

[0147] Step 523: The security key management TA uses the security private key to decrypt the password encryption result and the summary encryption result to obtain the summary of the OTP password and the service data.

[0148] Step 524: The security key management TA displays the summary of the OTP password and service data to the user.

[0149] Step 525: After the user confirms the content of this signature, he / she enters the OTP password displayed by the security key management TA into the application APP of the business application terminal.

[0150] Step 526: The application APP sends the obtained OTP password to the service key management TA and requests verification of the legitimacy of the user identity.

[0151] Step 527: The business key management TA verifies whether the generated OTP password is consistent with the received OTP password. If they are consistent, the user identity is determined to be legitimate, and the business key management TA signs the business data using the business private key. If they are inconsistent, the user identity is determined to be illegal, and the business key management TA refuses to sign.

[0152] Step 528: The business key management TA sends the signature to the application APP.

[0153] Step 529: The application APP provides feedback to the user that the signing service is completed.

[0154] according to Figure 5 It can be seen from the method shown that the user identity verification method described in this embodiment has at least the following advantages: 1. By using an independent terminal to run a security application (security key APP and security key management TA) for verification, the user's business application (application APP and business key management TA) is on a different terminal, which improves the security of the application. The attacker must have two terminals at the same time and be able to pass the terminal authentication to successfully attack.

[0155] 2. Complete decentralization, user keys are autonomous and controllable, and do not rely on any cloud service / backend server, which can avoid security issues such as data leakage in the cloud / backend server.

[0156] 3. Using TEE and TA technology, a secure private key storage and signing process is implemented: the user's private key is stored in TEE secure storage to prevent malicious export. TA ensures the atomicity of OTP verification and signature, ensuring that even if the app is hacked, the relevant TA interface cannot be called for signing.

[0157] 4. Prevent fraud and misoperation through the business summary data generated in the TA: In the business key management TA, the encrypted data includes not only the OTP password but also the business summary data. After these encrypted data are decrypted in the security key management TA, they are displayed to the user in the form of text together with the OTP password, so that the user can clearly understand the purpose of this signature before entering the OTP password to prevent misoperation.

[0158] This embodiment also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, it implements one of the above-mentioned user identity verification methods, or implements another of the above-mentioned user identity verification methods.

[0159] Computer-readable storage media include permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmitting media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0160] This embodiment also provides an electronic device, including: One or more processors; and a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, implement one of the above-mentioned user identity verification methods, or implement another of the above-mentioned user identity verification methods.

[0161] Please refer to Figure 6 , Figure 6 A schematic diagram of the structure of the electronic device is shown. The electronic device includes a bus 601, a processor 602, a memory 603 and a communication interface 604. The memory 603 stores a computer program, and when the computer program runs on the processor 602, the processor 602 executes the specific steps in the user identity verification method. It should be understood that the present application does not limit the number of processors and memories in the electronic device.

[0162] The bus 601 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus 601 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus 601 is represented by only one line, but it does not mean that there is only one bus or one type of bus. The bus 601 may include a path for transmitting information between various components of the terminal device (for example, the processor 602, the memory 603 and the communication interface 604).

[0163] The processor 602 may include any one or more of a processor such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0164] The memory 603 may include a volatile memory, such as a random access memory (RAM). The memory 603 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0165] The communication interface 604 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the electronic device and other devices or a communication network.

[0166] It should be understood by those skilled in the art that the modules or steps of the present invention described above can be implemented by a general-purpose computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, and optionally, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order than that here, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present invention is not limited to any specific combination of hardware and software.

[0167] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0168] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0169] It should be noted that the above examples are only specific embodiments of the present invention, and the present invention is obviously not limited to the above examples, and there are many similar variations. All variations directly derived or associated from the contents disclosed by the technicians in this field should fall within the protection scope of the present invention.

Claims

1. A user identity verification method, applicable to a first terminal device, wherein a first public key, a first private key, and an initial key of the first terminal device are stored in a first trusted execution environment of the first terminal device, and a second public key of a second terminal device is stored in a second trusted execution environment of the second terminal device; the method comprises: Responding to a signature request from a user, obtaining business data; Generate a one-time first password using the initial key in the first trusted execution environment, and encrypt the first password using the second public key to obtain a password encryption result; Sending the password encryption result to the second terminal device, so that the second terminal device decrypts the password encryption result using the second private key in the second trusted execution environment to obtain a second password; Obtaining the second password sent by the second terminal device, and verifying the consistency of the second password with the first password in the first trusted execution environment; In response to verifying that the second password is consistent with the first password, the business data is signed using the first private key in the first trusted execution environment.

2. The method according to claim 1, further comprising: In response to a user's request to generate a first asymmetric key pair, generating the first public key and the first private key in the first trusted execution environment; The first public key and the first private key are stored in the first trusted execution environment.

3. The method according to claim 1, further comprising: Obtaining the second public key sent by the second terminal device; Authenticate the user's identity; After authentication is passed, the second public key is stored in the first trusted execution environment.

4. The method according to claim 1, further comprising: Calculating a digest of the business data in the first trusted execution environment, and encrypting the digest using the second public key to obtain a digest encryption result; Sending the digest encryption result to the second terminal device, so that the second terminal device decrypts the digest encryption result using the second private key in the second trusted execution environment to obtain the digest; showing the digest and the second password sent by the second terminal to the user; In response to the user's confirmation of the digest and the second password, a verification process for the second password is performed.

5. The method according to claim 1, wherein: The first password is generated according to the initial key and a timestamp, and the first password is valid within a preset time period.

6. The method according to claim 1, sending the password encryption result to the second terminal device, specifically comprising: Displaying the QR code of the password encryption result to the user; The password encryption result is sent to the second terminal device through the user's operation of scanning and parsing the QR code of the password encryption result using the second terminal device.

7. A user identity verification method, applicable to a second terminal device, wherein a second private key of the second terminal device is stored in a second trusted execution environment of the second terminal device, and a second public key of the second terminal device is stored in a first trusted execution environment of a first terminal device; the method comprises: In response to obtaining the password encryption result sent by the first terminal device based on the business data signature requirement, decrypting the password encryption result using the second private key in the second trusted execution environment to obtain a second password; the password encryption result is obtained by the first terminal device encrypting the first password using the second public key in the first trusted execution environment; The second password is sent to the first terminal device, so that the first terminal device verifies the consistency of the second password with the first password in the first trusted execution environment, and confirms the legitimacy of the user identity based on the consistency verification result.

8. The method according to claim 7, sending the second password to the first terminal device, specifically comprising: displaying the second password to the user; The second password is input into the first terminal device through a password input operation by a user on the first terminal device.

9. The method according to claim 7, further comprising: In response to a user's request to generate a second asymmetric key pair, generating the second public key and the second private key in the second trusted execution environment; The second public key and the second private key are stored in the second trusted execution environment.

10. The method according to claim 9, storing the second public key and the second private key in the second trusted execution environment, specifically comprising: Authenticate the user's identity; After authentication is passed, the second public key and the second private key are stored in the second trusted execution environment.

11. The method according to claim 7, further comprising: Displaying the QR code of the second public key to the user; The second public key is sent to the first terminal device through an operation in which a user uses the first terminal device to scan and parse the QR code of the second public key.

12. The method according to claim 7, further comprising: In response to obtaining the digest encryption result sent by the first terminal device, decrypting the digest encryption result using the second private key in the second trusted execution environment to obtain a digest; The digest encryption result is obtained by encrypting the digest of the service data by the first terminal device using the second public key in the first trusted execution environment; presenting the summary and the second password to the user; After the user confirms the summary, the user inputs the second password into the first terminal device, so that the first terminal device executes a verification process for the second password.

13. A user identity verification system, comprising a first terminal device and a second terminal device, wherein a first public key, a first private key, an initial key and a second public key of the first terminal device are stored in a first trusted execution environment of the first terminal device, and a second private key of the second terminal device is stored in a second trusted execution environment of the second terminal device; The first terminal device is configured to obtain business data in response to a signature request made by a user; generate a one-time first password using the initial key in the first trusted execution environment, and encrypt the first password using the second public key to obtain a password encryption result; and send the password encryption result to the second terminal device; Obtaining a second password sent by the second terminal device, and verifying the consistency of the second password with the first password in the first trusted execution environment; in response to verifying that the second password is consistent with the first password, signing the business data using the first private key in the first trusted execution environment; The second terminal device is configured to, in response to obtaining the password encryption result sent by the first terminal device, decrypt the password encryption result using the second private key in the second trusted execution environment to obtain the second password, and send the second password to the first terminal device.

14. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program implements the method according to any one of claims 1 to 6, or executes the method according to any one of claims 7 to 12.

15. An electronic device, comprising: one or more processors; And a memory associated with the one or more processors, the memory being used to store program instructions, which, when read and executed by the one or more processors, execute the method according to any one of claims 1 to 6, or execute the method according to any one of claims 7 to 12.

Images