A user identity verification method and system

Abstract

An embodiment of the present application discloses a user identity verification method and system. This method generates a set of asymmetric security keys for the identity verification link in the service 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. The identity credential is decrypted by the security private key in the trusted execution environment of the second terminal device. Finally, the legitimacy of the user identity is determined by verifying the consistency of the identity credentials held by the two device terminals. Through this method, an attacker must break through both device terminals simultaneously to succeed in the attack, greatly increasing the difficulty of the attack.

Description

Technical Field

[0001] The present invention relates to the technical field of trusted execution environments, 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 himself, 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 on 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 passes, the blockchain data is rewritten to complete the business operation. However, in the above process, there is a risk that the private key may be 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. A first public key, a first private key, an initial key, and a second public key of a second terminal device are stored in a first trusted execution environment of the first terminal device, and a second private key is stored in a second trusted execution environment of the second terminal device; the method includes:

[0005] In response to a signature request made by a user, obtain business data;

[0006] Generate a one-time first password in the first trusted execution environment using the initial key, and encrypt the first password with the second public key to obtain a password encryption result;

[0007] Send 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;

[0008] Obtain the second password sent by the second terminal device, and verify the consistency between the second password and the first password in the first trusted execution environment;

[0009] 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.

[0010] As an optional implementation manner of the method described in the first aspect, the method further includes:

[0011] In response to a first asymmetric key pair generation request from a user, generate the first public key and the first private key in the first trusted execution environment;

[0012] Store the first public key and the first private key in the first trusted execution environment.

[0013] As an alternative implementation of the method described in the first aspect, the method further includes:

[0014] Obtain the second public key sent by the second terminal device;

[0015] Authenticate the user identity;

[0016] After the authentication passes, store the second public key in the first trusted execution environment.

[0017] As an alternative implementation of the method described in the first aspect, the method further includes:

[0018] Calculate a digest of the service data in the first trusted execution environment, and encrypt the digest using the second public key to obtain a digest encryption result;

[0019] Send 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;

[0020] Display the digest sent by the second terminal and the second password to the user;

[0021] In response to the user's confirmation of the digest and the second password, execute a verification process for the second password.

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

[0023] As an alternative implementation of the method described in the first aspect, sending the password encryption result to the second terminal device specifically includes:

[0024] Display a two-dimensional code of the password encryption result to the user;

[0025] By the user's operation of scanning and parsing the two-dimensional code of the password encryption result using the second terminal device, send the password encryption result to the second terminal device.

[0026] Second aspect, another user identity verification method is provided, which is applicable to a second terminal device. 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 includes:

[0027] In response to obtaining a password encryption result sent by the first terminal device based on a business data signature requirement, decrypt 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 a first password using the second public key in the first trusted execution environment;

[0028] Send the second password to the first terminal device, so that the first terminal device verifies the consistency between the second password and the first password in the first trusted execution environment, and confirms the legitimacy of the user identity based on the consistency verification result.

[0029] As an optional implementation manner of the method described in the second aspect, sending the second password to the first terminal device specifically includes:

[0030] Display the second password to the user;

[0031] Through the user's password input operation on the first terminal device, input the second password into the first terminal device.

[0032] As an optional implementation manner of the method described in the second aspect, the method further includes:

[0033] In response to a user's request for generating a second asymmetric key pair, generate the second public key and the second private key in the second trusted execution environment;

[0034] Store the second public key and the second private key in the second trusted execution environment.

[0035] Specifically, storing the second public key and the second private key in the second trusted execution environment specifically includes:

[0036] Authenticate the user identity;

[0037] After the authentication passes, store the second public key and the second private key into the second trusted execution environment.

[0038] As an optional implementation manner of the method described in the second aspect, the method further includes:

[0039] Display a two-dimensional code of the second public key to the user;

[0040] The second public key is sent to the first terminal device through an operation in which the user scans and analyzes the QR code of the second public key using the first terminal device.

[0041] As an optional implementation manner of the method described in the second aspect, the method further includes:

[0042] In response to obtaining the encrypted digest result sent by the first terminal device, the encrypted digest result is decrypted using the second private key in the second trusted execution environment to obtain a digest; the encrypted digest result is obtained by the first terminal device encrypting the digest of service data using the second public key in the first trusted execution environment;

[0043] The digest and the second password are presented to the user;

[0044] Through an operation in which the user inputs the second password into the first terminal device after confirming the digest, the first terminal device executes a verification process for the second password.

[0045] In a third aspect, a user identity verification system is provided, including a first terminal device and a second terminal device. The first public key, the first private key, the initial key of the first terminal device, and the second public key of the second terminal device are stored in the first trusted execution environment of the first terminal device, and the second private key of the second terminal device is stored in the second trusted execution environment of the second terminal device;

[0046] The first terminal device is configured to, in response to a signature request made by a user, obtain service data; generate a one-time first password using the initial key in the first trusted execution environment, 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 between the second password and 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 service data using the first private key in the first trusted execution environment.

[0047] 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.

[0048] 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, it implements the above-mentioned user identity verification method, or executes the above-mentioned another user identity verification method.

[0049] In a fifth aspect, an electronic device is provided, including:

[0050] One or more processors; and a memory associated with the one or more processors, where the memory is used to store program instructions, and when the program instructions are read and executed by the one or more processors, the above-mentioned user identity verification method or another user identity verification method is executed.

[0051] The beneficial effect of the user identity verification method described in one or more embodiments of this specification is that this method generates a set of asymmetric security keys for the identity verification link in the service process, stores the security public key among them in the trusted execution environment of the first terminal device, and stores the security private key among them in the trusted execution environment of the second terminal device. When performing identity verification, the identity credential is encrypted with 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. The identity credential is decrypted with the security private key in the trusted execution environment of the second terminal device. Finally, the legitimacy of the user identity is determined by verifying the consistency of the identity credentials held by the two device terminals. Through this method, an attacker must break through both device terminals simultaneously to succeed in the attack, greatly increasing the difficulty of the attack.

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

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

[0054] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of this specification. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

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

[0056] Figure 2 It is a schematic structural diagram of a user identity verification system provided by one or more embodiments of this specification.

[0057] Figure 3Flowchart of a user identity verification method provided for one or more embodiments of this specification.

[0058] Figure 4 Flowchart of another user identity verification method provided for one or more embodiments of this specification.

[0059] Figure 5 Schematic diagram of the process of the user identity verification method provided for one or more embodiments of this specification in a specific scenario.

[0060] Figure 6 Schematic diagram of the structure of an electronic device provided for one or more embodiments of this specification. Detailed implementation manners

[0061] First, 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 "said" used in the embodiments of the present invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0062] 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 with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described here without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, the descriptions of well-known functions and structures are omitted below.

[0063] It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily executed 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 also be combined into a single step for description in other embodiments.

[0064] 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, stored in a mobile terminal), and the public key is made public (usually stored in the blockchain). When conducting business (such as digital asset transfer), the user signs with the private key on the terminal and then sends the signed data to the blockchain. The public key is used on the blockchain to verify the signature. After the signature verification passes, the blockchain data is rewritten to complete the business operation. However, since the private key is stored in the user's held terminal, 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 being stolen during the use of the private key.

[0065] Please refer to Figure 1 , Figure 1 which shows the flow diagram of an existing identity authentication method based on an asymmetric encryption algorithm in an application scenario.

[0066] As Figure 1 shown, the above-mentioned identity authentication method based on an asymmetric encryption algorithm is implemented by a business application terminal, a security application terminal, and a business server. The business application terminal deploys the 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, and this dynamic password has timeliness and will expire after reaching a predetermined duration.

[0067] Figure 1 The method shown mainly includes two stages: the asymmetric key generation stage and the signature stage.

[0068] The process of the asymmetric key generation stage specifically includes:

[0069] 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.

[0070] Step 2: The application APP responds to the user operation and generates an asymmetric business key.

[0071] 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.

[0072] Step 4: The business server responds to the TOTP key generation request, generates a TOTP key, and saves the TOTP key.

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

[0074] Step 6: The APP generates a QR code of the TOTP key and presents the QR code to the user.

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

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

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

[0078] Step 10: The TOTP generator shows the user that the saving of the TOTP key is completed through the secure application terminal.

[0079] Step 11: After learning 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.

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

[0081] Step 13: The user operates the secure application terminal to send an OTP password reading request to the TOTP generator.

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

[0083] Step 15: The secure application terminal shows the OTP password generated by the TOTP generator to the user.

[0084] Step 16: The user reads the OTP password shown on the secure application terminal and inputs the read OTP password into the APP of the business application terminal.

[0085] Step 17: The APP sends the OTP password input by the user to the business server for verification. The business server generates an OTP password according to the TOTP key and the current timestamp, and checks the consistency between the generated OTP password and the received OTP password. If the two OTP passwords are consistent, the verification is determined to pass; otherwise, the verification is determined to fail.

[0086] Step 18: When the business server verifies the OTP password input by the user and passes, the business server sends a verification passed message to the APP.

[0087] Step 19: The APP saves the asymmetric service key.

[0088] Step 20: The application APP shows the user that the creation of the asymmetric service key is completed.

[0089] The process of the signature phase specifically includes:

[0090] Step 21: The user initiates a signature request for the service data in the application APP.

[0091] Step 22: The application APP initiates the signature process, specifically including obtaining the signed service data and the relevant service public key.

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

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

[0094] Step 25: The TOTP generator generates the OTP password according to the TOTP key and the timestamp.

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

[0096] Step 27: The user reads the OTP password shown on the secure application terminal and enters the OTP password into the OTP password verification page of the application APP.

[0097] Step 28: The application APP sends the OTP password to the application server for verification. The application server will generate an OTP password according to 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, it is determined that the verification is passed; otherwise, it is determined that the verification fails.

[0098] Step 29: When the business server verifies the OTP password entered by the user and passes, the business server sends a verification passed message to the application APP.

[0099] Step 30: The application APP signs the service data using the service private key.

[0100] Step 31: The application APP shows the user the information that the signature service is completed.

[0101] The above is Figure 1 the specific process of the identity authentication method based on the asymmetric encryption algorithm shown. From this process, it can be seen that Figure 1 the method shown mainly has the following defects:

[0102] (1) The TOTP key is stored in the business server. If the business server is attacked, there is a risk of large-scale leakage of the TOTP key it stores.

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

[0104] (3) The user's private key signature process is also completed in the REE environment. During this process, there may be a risk that the application app is compromised and the attacker bypasses the OTP verification and directly calls the relevant interface to sign.

[0105] It can be seen that in the current identity authentication process of Web3.0 applications based on asymmetric encryption, there is a risk of private key theft in multiple links.

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

[0107] 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.

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

[0109] Please refer to Figure 2 , Figure 2 shows a user identity verification system, which includes a first terminal device 201 and a second terminal device 202. Among them, the first public key, first private key, 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.

[0110] In Figure 2 In the shown user identity verification system, the first terminal device 201 is configured to perform the following steps:

[0111] In response to a signature request made by the user, obtain service data;

[0112] In the first trusted execution environment, generate a one-time first password using the initial key, and encrypt the first password with the second public key to obtain a password encryption result;

[0113] Send the encrypted password result to the second terminal device 202;

[0114] Obtain the second password sent by the second terminal device 202, and verify the consistency between the second password and the first password in the first trusted execution environment;

[0115] In response to verifying that the second password is consistent with the first password, sign the service data with the first private key in the first trusted execution environment.

[0116] In Figure 2 In the user identity verification system shown, the second terminal device 202 is configured to perform the following steps:

[0117] In response to obtaining the encrypted password result sent by the first terminal device 201, decrypt the encrypted password result with 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 201.

[0118] It can be seen that in Figure 2 In 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, are used to ensure the confidentiality of the user identity credential (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, store the second public key in the trusted execution environment of the first terminal device 201, and store the second private key in the trusted execution environment of the second terminal device 202, so that the attacker must break through two device terminals at the same time to succeed in the attack, greatly increasing the attack difficulty for the attacker. Second, use the second public key to encrypt the identity credential and the second private key to decrypt the identity credential, ensuring that the transmission process of the identity credential is encrypted, and the second private key is not transmitted alone during the entire transmission process of the identity credential. Third, the encryption process of the identity credential is executed in the trusted execution environment of the first terminal device 201, and the decryption process of the identity credential is executed in the trusted execution environment of the second terminal device 202, making the entire identity credential encryption and decryption process an atomic operation, ensuring that even if the device terminal is broken, the attacker cannot call the relevant TA interface for signing.

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

[0120] The following will elaborate on the specific working processes of the first terminal device 201 and the second terminal device 202 in the above user identity verification system in combination with specific implementation manners.

[0121] Please refer to Figure 3 , Figure 3Flowchart of a user identity verification method proposed in one or more embodiments of this specification. Figure 3 The method described above is applicable to the first terminal device 201. The first terminal device 201 completes the verification of the legality of the user's identity through interaction with the second terminal device 202. Before Figure 3 executing the user identity verification method shown above, it is necessary to initialize the first terminal device 201. 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.

[0122] In some embodiments, the specific process for the first terminal device 201 to obtain the first public key and the first private key may be as follows: 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 for generating the first asymmetric key pair.

[0123] In some more specific embodiments, before storing the first public key and the first private key in the first trusted execution environment of the first terminal device 201, the identity of the user may also be authenticated. For example, the identity of the user operating the first terminal device 201 may be verified through authentication methods such as account password login and face recognition. 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, thus completing the service of generating the first asymmetric key pair.

[0124] In some embodiments, for obtaining the initial key, the first terminal device 201 may obtain the initial key from a trusted institution by means of secure transmission, or directly generate the initial key in the first executable environment, or directly use the first private key generated above as the initial key. In this embodiment, the method for the first terminal device 201 to obtain the initial key is not limited, as long as it is ensured that 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.

[0125] In some embodiments, for obtaining the second public key of the second terminal device 202, the following method may be adopted:

[0126] First, the user makes a request for generating the second asymmetric key pair on the second terminal device 202. The second terminal device 202 generates the second public key and the second private key in the second trusted execution environment in response to the user's request for generating the second asymmetric key pair, and stores at least the second private key.

[0127] In some embodiments, before generating and storing the second public key and the second private key in the second trusted execution environment of the second terminal device 202, the user identity may also be authenticated. For example, the identity of the user operating the second terminal device 202 may be verified through authentication methods such as account 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 public key and the second private key, or only store the second private key, thereby completing the generation service of the second asymmetric key pair.

[0128] 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.

[0129] In some embodiments, before the first terminal device 201 stores the second public key in the first trusted execution environment, the user identity may also be authenticated. For example, the identity of the user operating the first terminal device 201 may be verified through authentication methods such as account password login, face recognition, etc. After the authentication is passed, the first trusted execution environment of the first terminal device 201 will store the second public key.

[0130] 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.

[0131] S300: In response to the signature request made by the user, obtain the service data.

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

[0133] S302: Use the initial key to generate a one-time first password in the first trusted execution environment, and encrypt the first password with the second public key to obtain the password encryption result.

[0134] In some embodiments, the TOTP algorithm can be used to generate the first password in the first trusted execution environment. The TOTP (Time-Based One-Time Password) algorithm is a time-based single password algorithm used to generate one-time passwords (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 time-based, usually valid for a period of time (for example, 30 seconds), and then the dynamic password will automatically expire.

[0135] The process of generating the first password based on the TOTP algorithm is as follows:

[0136] Calculate the initial key and timestamp through a hashing algorithm (usually HMAC-SHA1) to obtain a hash value;

[0137] According to the regulations of the hash value, intercept a part of the hash value 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.

[0138] Finally, use the first public key to encrypt the first password in the first trusted execution environment of the first terminal device 201 to obtain the password encryption result.

[0139] The trusted execution environment TEE (Trusted Execution Environment) 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 attackers cannot obtain the first password by attacking the encryption process of the first password.

[0140] S304: Send the password encryption result to the second terminal device 202, so that the second terminal device 202 can use the second private key to decrypt the password encryption result in the second trusted execution environment to obtain the second password.

[0141] In some embodiments, the first terminal device 201 can generate a two-dimensional code of the password encryption result, and then display the two-dimensional code of the password encryption result to the user. The user uses the second terminal device 202 to scan and parse the two-dimensional code of the password encryption result to obtain the password encryption result.

[0142] As can be seen from the above initialization process, the second private key of the second terminal device 202 is stored in the second trusted execution environment 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.

[0143] Based on the fact that the second public key and the second private key are a pair of asymmetric keys, therefore, the second private key can be used to decrypt the password encryption result, and the password encryption result is recorded as the second password.

[0144] 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 attackers cannot obtain the second password by attacking the decryption process of the password encryption result.

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

[0146] Correspondingly, the second terminal device 202 may also, in response to obtaining the digest encryption result sent by the first terminal device 201, decrypt the digest encryption result with the second private key in the second trusted execution environment to obtain the digest. Then the second terminal device 202 presents the digest and the second password to the user, allowing the user to clearly understand the purpose of this signature before entering the second password to prevent misoperation. After the user confirms the digest, the second password is input into the first terminal device 201.

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

[0148] Specifically, before verifying the consistency between the second password and the first password, it is necessary to first verify whether the second password is valid. If it is valid, then compare the second password with the first password for consistency. If it is invalid, feedback information indicating that the password has expired to the user.

[0149] If the second password is consistent with the first password, it is determined that the verification passes, indicating that the user identity is legal. If the second password is inconsistent with the first password, it is determined that the verification fails.

[0150] S308: In response to verifying that the second password is consistent with the first password, sign the service data with the first private key in the first trusted execution environment.

[0151] When it is verified that the second password is consistent with the first password, it indicates that the user identity is legal. At this time, the first terminal device 201 only signs the service data with the first private key in the first trusted execution environment. In this step S308, the first private key used for signing is stored 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 device is lost or stolen, the first private key cannot be maliciously exported. In addition, this step S308 also sets the signature operation to be completed in the first trusted execution environment, which is essentially an atomic operation, making it impossible for an attacker to obtain the first private key by attacking the signature process.

[0152] Next, please refer to Figure 4 , Figure 4 which is a flowchart of another user identity verification method proposed in one or more embodiments of this specification. Figure 4The method described above is applicable to the second terminal device 202. The second terminal device 202 completes the verification of the user identity legality through the interaction with the first terminal device 201. Before executing Figure 4 the user identity verification method shown, it is necessary to initialize the second terminal device 202. Specifically, a second private key is stored in the second trusted execution environment of the second terminal device 202.

[0153] In some embodiments, storing the second private key in the second trusted execution environment of the second terminal device 202 can be specifically implemented in the following manner:

[0154] First, the user makes a request for generating a second asymmetric key pair on the second terminal device 202. In response to the user's request for generating a second asymmetric key pair, the second terminal device 202 generates a second public key and a second private key in the second trusted execution environment, and stores at least the second private key.

[0155] In some more specific embodiments, before storing the second private key, the second trusted execution environment of the second terminal device 202 can also authenticate the user identity. For example, the identity of the user operating the second terminal device 202 can be verified through authentication methods such as account password login and face recognition. After the authentication passes, the second trusted execution environment of the second terminal device 202 will store the second private key, thereby completing the service of generating the second asymmetric key pair.

[0156] 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.

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

[0158] 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.

[0159] In some embodiments, the first terminal device 201 can also send the digest encryption result of the business data while sending the password encryption result. The digest encryption result is obtained by the first terminal device 201 encrypting the digest of the business data using the second public key in the first trusted execution environment.

[0160] Correspondingly, the second terminal device 202 can also respond to obtaining the digest encryption result sent by the first terminal device 201, decrypt the digest encryption result in the second trusted execution environment using the second private key to obtain the digest. Then the second terminal device 202 presents the digest and the second password to the user, allowing the user to clearly understand the purpose of this signature and then input the second password to prevent misoperation. After the user confirms the digest, the second password is input into the first terminal device 201.

[0161] S402: Send the second password to the first terminal device 201 for verifying the legitimacy of the user identity.

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

[0163] Specifically, the first terminal device 201 first verifies whether the second password is valid. If it is valid, the consistency between the second password and the first password is further verified. If it is invalid, a password invalidation message is sent to the user.

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

[0165] For the identity verification method implemented through the interaction between the first terminal device 201 and the second terminal device 202, the following will be combined with Figure 5 for specific description.

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

[0167] In Figure 5 the scenario shown, it mainly includes the first terminal device 201 and the second terminal device 202. Among them, the first terminal device 201 is used as a business application terminal, and an application APP and a business key management TA are deployed. The business key management TA is an application program running in the TEE environment of the business application terminal. The second terminal device 202 is used as a security application terminal, and a security key APP and a security key management TA are deployed. The full key management TA is an application program running in the TEE environment of the security application terminal. Different from traditional application programs, the TA runs in a restricted security environment and is isolated from the operating system and other application programs. This isolation can protect the code and data of the TA from threats of malware and attackers.

[0168] As Figure 5 described above, the user identity verification method mainly includes two stages: the asymmetric key generation stage and the service key signature stage.

[0169] The asymmetric key generation stage mainly includes the following steps:

[0170] Step 501: The user operates on the application APP of the service application terminal to request the application APP to generate an asymmetric service key pair (service public key and service private key).

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

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

[0173] 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 (security public key and security private key).

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

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

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

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

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

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

[0180] Step 511: The user's authentication is passed.

[0181] Step 512: The application APP scans the security public key QR code.

[0182] Step 513: The application APP analyzes the security public key QR code to obtain the security public key.

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

[0184] Step 515: The service key management TA feeds back information indicating that the security public key has been saved.

[0185] The business key signature phase mainly includes the following steps:

[0186] Step 516: The user initiates a signature request for business data in the application APP.

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

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

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

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

[0191] Step 521: The secure key app parses the QR code of the password encryption result and the QR code of the digest encryption result to obtain the password encryption result and the digest encryption result.

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

[0193] Step 523: The secure key management TA decrypts the password encryption result and the digest encryption result with the secure private key to obtain the OTP password and the digest of the business data.

[0194] Step 524: The secure key management TA shows the OTP password and the digest of the business data to the user.

[0195] Step 525: After the user confirms the content of this signature, the user inputs the OTP password shown by the secure key management TA into the application APP of the business application terminal.

[0196] Step 526: The application APP sends the obtained OTP password to the business key management TA and requests to verify the legitimacy of the user's identity.

[0197] Step 527: The business key management TA verifies whether the generated OTP password is consistent with the received OTP password. If they are consistent, it determines that the user's identity is legal. At this time, the business key management TA signs the business data with the business private key. If they are not consistent, it determines that the user's identity is illegal. At this time, the business key management TA rejects the signature.

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

[0199] Step 529: The application APP feeds back to the user that the signature service is completed.

[0200] According to Figure 5 the method shown above, the user identity verification method described in this embodiment has at least the following advantages:

[0201] 1. By using the method of running security applications (security key APP and security key management TA) on an independent terminal for verification, the security applications are on different terminals from the user's business applications (application APP and business key management TA), which improves the security of the applications. An attacker must have both terminals and be able to pass the authentication of the terminals to succeed in the attack.

[0202] 2. Completely decentralized, the user's key is independently controllable and does not rely on any cloud service / backend server, which can avoid security problems such as data leakage in the cloud / backend server.

[0203] 3. By using TEE and TA technologies, a secure private key storage and signature process is realized: the user's private key is stored in the TEE secure storage to prevent malicious export, and TA ensures the atomicity of OTP verification and signature, ensuring that even if the app is compromised, relevant TA interfaces cannot be called for signature.

[0204] 4. Prevent fraud and accidental operations through the service digest data generated within TA: within the service key management TA, the encrypted data includes not only the OTP password but also the service digest data. After these encrypted data are decrypted in the security key management TA, they are presented to the user in text form together with the OTP password, allowing the user to clearly understand the purpose of this signature before entering the OTP password to prevent accidental operations.

[0205] 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 the above-mentioned user identity verification method, or implements the above-mentioned another user identity verification method.

[0206] A computer-readable storage medium includes permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The 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 technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0207] This embodiment also provides an electronic device, including:

[0208] One or more processors; and a memory associated with the one or more processors, where the memory is used to store program instructions, and when the program instructions are read and executed by the one or more processors, the above-mentioned user identity verification method is implemented, or another user identity verification method is implemented.

[0209] Please refer to Figure 6 , Figure 6 , which shows a schematic structural diagram of the above-mentioned electronic device. The electronic device includes a bus 601, a processor 602, a memory 603, and a communication interface 604. A computer program is stored in the memory 603, and when the computer program runs on the processor 602, the processor 602 executes the specific steps in the above-mentioned user identity verification method. It should be understood that the number of processors and memories in the electronic device is not limited in this application.

[0210] The bus 601 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 601 can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, Figure 6 only one line is shown in , but it does not mean that there is only one bus or one type of bus. The bus 601 can 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).

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

[0212] 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).

[0213] 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 communication networks.

[0214] Those skilled in the art should understand that the above-mentioned modules or steps of the present invention 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. Optionally, they can be implemented by program codes executable by the computing device. Thus, 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 from here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module to implement. In this way, the present invention is not limited to any specific combination of hardware and software.

[0215] Each embodiment in this specification is described in a progressive manner. The same or similar parts among the embodiments can be referred to each other, and the key point of each embodiment is to illustrate 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.

[0216] 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.

[0217] 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. In the first trusted execution environment of the first terminal device, a first public key, a first private key, an initial key, and a second public key of a second terminal device are stored. In the second trusted execution environment of the second terminal device, a second private key is stored. The first public key and the first private key are generated in the first trusted execution environment by the first terminal device in response to a first asymmetric key pair generation request from a user. The method includes: In response to a signature request from a user, obtain service data; In the first trusted execution environment, generate a one-time first password using the initial key, and encrypt the first password with the second public key to obtain a password encryption result. Also, in the first trusted execution environment, calculate a digest of the service data, and encrypt the digest with the second public key to obtain a digest encryption result; Send the password encryption result and the digest encryption result to the second terminal device, so that the second terminal device decrypts the password encryption result and the digest encryption result using the second private key in the second trusted execution environment to obtain a second password and the digest; Display the digest and the second password sent by the second terminal device to the user; In response to the user's confirmation of the digest and the second password, verify the consistency between the second password and 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 service data using the first private key in the first trusted execution environment.

2. The method according to claim 1, the method further includes: Obtain the second public key sent by the second terminal device; Authenticate the user identity; After the authentication passes, store the second public key in the first trusted execution environment.

3. 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.

4. The method according to claim 1, sending the password encryption result to the second terminal device specifically includes: Display a two-dimensional code of the password encryption result to the user; Send the password encryption result to the second terminal device through an operation where the user scans and analyzes the two-dimensional code of the password encryption result using the second terminal device.

5. A user identity verification method, applicable to a second terminal device. In the second trusted execution environment of the second terminal device, a second private key of the second terminal device is stored. The second public key of the second terminal device is stored in the first trusted execution environment of the first terminal device. The second public key and the second private key are generated in the second trusted execution environment. The method includes: In response to obtaining the password encryption result and the digest encryption result sent by the first terminal device based on the service data signature requirement, decrypt the password encryption result and the digest encryption result using the second private key in the second trusted execution environment to obtain a second password and a digest; The password encryption result is obtained by the first terminal device encrypting the first password with the second public key in the first trusted execution environment; the digest encryption result is obtained by the first terminal device calculating the digest of the service data in the first trusted execution environment and encrypting the digest with the second public key; Send the second password and the digest to the first terminal device, so that the first terminal device displays the digest and the second password sent by the second terminal device to the user, and in response to the user's confirmation of the digest and the second password, verify the consistency between the second password and the first password in the first trusted execution environment, and confirm the legality of the user's identity based on the consistency verification result.

6. The method according to claim 5, wherein sending the second password to the first terminal device specifically includes: Display the second password to the user; Input the second password into the first terminal device through the user's password input operation on the first terminal device.

7. The method according to claim 5, the method further includes: In response to the user's second asymmetric key pair generation request, generate the second public key and the second private key in the second trusted execution environment; Store the second public key and the second private key in the second trusted execution environment.

8. The method according to claim 7, storing the second public key and the second private key in the second trusted execution environment specifically includes: Authenticate the user's identity; After the authentication passes, store the second public key and the second private key in the second trusted execution environment.

9. The method according to claim 5, the method further includes: Display the QR code of the second public key to the user; Send the second public key to the first terminal device through the user's operation of scanning and parsing the QR code of the second public key using the first terminal device.

10. A user identity verification system, including a first terminal device and a second terminal device. The first public key, the first private key, the initial key of the first terminal device and the second public key of the second terminal device are stored in the first trusted execution environment of the first terminal device. The second private key of the second terminal device is stored in the second trusted execution environment of the second terminal device; the first public key and the first private key are generated by the first terminal device in the first trusted execution environment in response to the user's first asymmetric key pair generation request; The first terminal device is configured to, in response to a signature request made by the user, obtain service data; generate a one-time first password using the initial key in the first trusted execution environment, encrypt the first password with the second public key to obtain a password encryption result, and calculate a digest of the service data in the first trusted execution environment and encrypt the digest with the second public key to obtain a digest encryption result; send the password encryption result and the digest encryption result to the second terminal device; Present the digest and the second password sent by the second terminal device to the user, and in response to the user's confirmation of the digest and the second password, verify the consistency between the second password and the first password in the first trusted execution environment; in response to verifying that the second password is consistent with the first password, use the first private key to sign the service data in the first trusted execution environment. The second terminal device is configured to, in response to obtaining the password encryption result and the digest encryption result sent by the first terminal device, decrypt the password encryption result and the digest encryption result using the second private key in the second trusted execution environment to obtain the second password and the digest, and send the second password and the digest to the first terminal device.

11. A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the method according to any one of claims 1 to 4, or executes the method according to any one of claims 5 to 9.

12. An electronic device, comprising: One or more processors; And a memory associated with the one or more processors, the memory is used to store program instructions, and when the program instructions are read and executed by the one or more processors, it executes the method according to any one of claims 1 to 4, or executes the method according to any one of claims 5 to 9.

Images