CN116545681A - Level2FIDO verifier based on trusted execution environment - Google Patents

Abstract

The invention relates to the technical field of identity verification, in particular to a Level2FIDO verifier based on a trusted execution environment, which comprises access equipment, a user side application and a verifier application, wherein the verifier application comprises a key module, a signature module and a storage module; the access device accesses the verifier into the user device, the key module generates a public key and a private key of a user by utilizing an encryption algorithm, the signature module executes signature operation on related data, the storage module stores the private key and authentication information of the user, the user side application ensures the integrity of the private key, the public key and the related authentication information of the extension information in the FIDO2 protocol, and ensures the security of signing the public key or the challenge value.

Description

A Level2 FIDO Authenticator Based on Trusted Execution Environment

technical field

The invention relates to the technical field of identity verification, in particular to a Level2 FIDO verifier based on a trusted execution environment.

Background technique

The USERNAME and PASSWORD of ordinary password authentication are easily leaked by hackers, leading to problems such as password theft, privacy theft, and online banking theft. In order to improve the problems existing in traditional password authentication methods, many non-password Authentication technology, such as: biometric fingerprint recognition, facial recognition and iris recognition scanning and other technologies; device verification technology that uses information such as the device's IMEI number and MAC address to confirm the identity of the device; single sign-on and other technologies. Therefore, passwordless authentication, as a more secure and convenient identity authentication method, is gradually being widely used.

FIDO2 is an emerging identity authentication protocol that adopts the idea of passwordless authentication. It uses public key encryption technology to achieve identity authentication security, and can implement high availability of identity authentication through multiple authentication methods. This provides a safe and usable passwordless authentication method that can replace the traditional USERNAME and PASSWORD methods.

The work of FIDO2 is mainly based on key encryption technology, using the public key and private key generated in the FIDO2 verifier to realize the two processes of identity registration and verification services. In the identity registration phase, the authenticator generates a public key and private key pair, the private key is stored locally, and the public key is transmitted to the server through the client, and the public key is stored on the server. In the verification phase, the verifier provides a private key to sign the verification information such as the challenge value, and the authentication response is transmitted to the server through the local end, which is used by the server to verify the user's identity and authorize the operation through the public key.

Although FIDO2 has become a relatively reliable security verification technology, it still has some problems. For example: Since the FIDO2 protocol needs to process the private key locally, if the private key is stored in an insecure environment, there will be a risk of the private key being stolen by hackers. If an attacker has control of the local environment, they can easily steal the private key of the FIDO2 authenticator in a normal environment, which in turn may be used to impersonate the user for authentication. As another example, FIDO2 authenticators in untrusted environments are vulnerable to hardware or software tampering. Hackers can implant malicious hardware or software in the FIDO2 verifier to obtain the user's private key and authentication information during transmission, or modify the signature or authentication request to make it look legitimate, and then attack.

Contents of the invention

The purpose of the present invention is to provide a Level2 FIDO verifier based on a trusted execution environment, aiming to solve the problem of security in traditional password verification methods.

To achieve the above object, the present invention provides a Level2 FIDO verifier based on a trusted execution environment, including an access device, a client application and a verifier application, and the verifier application includes a key module, a signature module and a storage module;

The access device is configured to connect the authenticator to the user equipment;

The client application calls the verifier through the OP-TEE Client API to ensure the integrity of the authentication information of the private key, public key and extended information in the FIDO2 protocol, and to ensure the security of signing the public key or challenge value ;

The key module generates the user's public and private keys through an encryption algorithm;

The signature module is used to perform a signature operation on relevant data;

The storage module is used to store the user's private key and authentication information.

Wherein, the interface and parameters of the client application and the verifier application include authentication proof output, authentication registration, authentication assertion output, authentication verification, navigation creation and navigation verification.

Wherein, the authentication certificate output is used for the user to request user registration from the verifier, and after the user passes the identity authentication and entry, a new set of key pairs and a certificate are generated. The API accepts a set of inputs and returns a " Prove" output.

Wherein, the authentication registration is used for the authenticator application to initiate a request to the authenticator application during registration, to generate a set of key pairs and a certificate in a trusted environment, and the authentication registration input parameters and return The value should be consistent with the authentication proof output described.

Wherein, the authentication assertion output is used for the user to request user identity verification from the authenticator. After the user passes the identity verification, the public key and the challenge information are signed with the private key. The API accepts a set of inputs and returns a " Assertion" output.

Wherein, the authentication verification is used for verifying that the client application of the verifier initiates a request to the verifier application, so that the public key and the challenge value information are signed with a private key in a trusted environment, and the authentication verification The input parameters and return value shall be consistent with the authentication assertion output.

Wherein, the navigation creation is used to request the user registration from the proxy APP to the user.

Wherein, the navigation verification is used to request user verification from the user on behalf of the APP.

Wherein, the user registration operation uploads the user information and the public key in the newly generated key pair to the server for registration, and stores the private key locally.

Wherein, the user verification operation will sign the challenge sent by the agent in the verifier, and return the signed information to the server, and the server uses the public key saved during registration to verify the information.

In the Level2 FIDO verifier based on a trusted execution environment of the present invention, the access device connects the verifier to the user device, the key module uses an encryption algorithm to generate the public and private keys of the user, and the signature module executes the verification of relevant data Signature operation, the storage module stores the user's private key and authentication information, and the client application ensures the integrity of the private key, public key and extended information in the FIDO2 protocol, ensuring that the public key or challenge value is Signature security, the verifier is based on ARM TrustZone's open source trusted execution environment - OP-TEE, using its security features, by creating a secure execution environment isolated from hardware and software to protect it from malware and attacks, it will The authenticator of FIDO2 is placed in the trusted execution environment, that is, the authenticator application, which isolates the authenticator from the ordinary execution environment, ensures the security of its operation and the security of key information storage, and solves the problem of traditional password authentication methods. There are security issues.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without creative work.

FIG. 1 is a schematic diagram of the overall architecture of the TEE-based FIDO2 provided by the present invention.

Fig. 2 is a structural diagram of the FIDO2 authenticator application (TA) provided by the present invention.

Fig. 3 is a schematic diagram of the relationship between the key module, the signature module and the storage module provided by the present invention.

Fig. 4 is a schematic diagram of the relationship between the signature module, the key module and the storage module provided by the present invention.

Fig. 5 is a schematic diagram of the relationship between the storage module, the key module and the signature module provided by the present invention.

Fig. 6 is a registration flow chart provided by the present invention.

Fig. 7 is a flow chart in TA during identity registration provided by the present invention.

Fig. 8 is a verification flowchart provided by the present invention.

Fig. 9 is a flow chart in TA during identity verification provided by the present invention.

In the figure: 1-access device, 2-client application, 3-verifier application, 4-key module, 5-signature module, 6-storage module.

Detailed ways

Embodiments of the present invention are described in detail below, examples of which are shown in the drawings, wherein the same or similar reference numerals designate the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the figures are exemplary and are intended to explain the present invention and should not be construed as limiting the present invention.

Referring to Figures 1 to 9, the present invention provides a Level2 FIDO authenticator based on a trusted execution environment, including an access device 1, a client application 2, and an authenticator application 3, the authenticator application 3 including a key module 4, signature module 5 and storage module 6;

The access device 1 is configured to connect the authenticator to the user equipment;

The client application 2 calls the verifier through the OP-TEE Client API to ensure the integrity of the private key, public key and extended information in the FIDO2 protocol, and to ensure the security of signing the public key or challenge value sex;

The key module 4 generates the user's public and private keys through an encryption algorithm;

The signature module 5 is configured to perform a signature operation on relevant data;

The storage module 6 is used to store the user's private key and authentication information.

In this embodiment, the client application 2 is referred to as CA, the authenticator application 3 is referred to as CT, the access device 1 connects the authenticator to the user equipment, and the key module 4 uses an encryption algorithm to generate the user's Public and private keys, specifically, when a user performs a registration operation, this module needs to be called to perform related operations. The validator CA transmits relevant information to the validator TA in the secure world, and the key module 4 of TA generates a set of key pairs, and transmits the private key to the storage module 6 for subsequent processing, and transmits the public key and other information to the Signature module 5 does follow-up processing;

The signature module 5 performs signature operations on relevant data. Specifically, this module is used to perform relevant operations when the user performs registration and verification operations. When registering, the module signs the new public key, generating a proof. During the verification phase, the signature module 5 will use the corresponding private key to sign the challenge value and other information to generate an assertion

The storage module 6 stores the user's private key and authentication information. Specifically, after the key module generates the public key and the private key, it will pass the private key to the storage module 6, and the storage module 6 will Safe storage; when verification needs to use the private key, the storage module 6 will carry out safe reading, find the private key and send it back to the verification module.

The client application 2 calls the FIDO2 authenticator TA under the trusted execution environment through the OP-TEE Client API to ensure the integrity of the private key, public key and extended information in the FIDO2 protocol, and ensure the integrity of the public key. The security of signing with key or challenge value;

The verifier is based on ARM TrustZone's open source trusted execution environment - OP-TEE, using its security features to create a hardware and software isolated secure execution environment to protect it from malware and attacks, and put the FIDO2 verifier in In the trusted execution environment, that is, the verifier application 3, the verifier is isolated from the common execution environment, ensuring the security of its operation and the security of key information storage, and solving the problem of security in traditional password verification methods question.

Further, the interfaces and parameters of the client application 2 and the verifier application 3 include authentication proof output, authentication registration, authentication assertion output, authentication verification, navigation creation and navigation verification.

In this embodiment, the authentication proof output authenticatorMakeCredential(...): an interface belonging to the CTAP2 part of the protocol, used for the user to request user registration from the authenticator, and generate a new set of keys after the user passes the identity authentication and entry pair and a proof, the API takes a set of inputs and returns a "proof" output;

The authentication registration Authentication_TA_create(...): belongs to the interface between the validator CA and TA, and is used for the validator when registering. The client application 2 initiates a request to the validator application 3 to generate a set of A key pair and a certificate, the input parameters and return value of which should be consistent with the output of the authentication certificate; the parameters are shown in Table 1.

Table 1

Return value. After successfully calling this interface, the attestation object and other information will be returned. The data structure is shown in Table 2.

Table 2

The authentication assertion output authenticatorGetAssertion(...): an interface belonging to the CTAP2 part of the protocol, used for the user to request user identity verification from the authenticator, and after the user passes the identity verification, use the private key to sign the information such as the public key and the challenge, The API takes a set of inputs and returns an "assertion" output;

The authentication verification Authentication_TA_create(...): When used for verification, the client application 2 of the verifier initiates a request to the verifier application 3, so that information such as the public key and the challenge value are signed with a private key in a trusted environment , its input parameters and return value should be consistent with authenticatorGetAssertion(…);

The parameters are shown in Table 3.

The return value in Table 3 will be the data structure shown in Table 4 after calling this interface successfully.

Table 4

The navigation creates navigator.credentials.create(...): an interface belonging to the webauthn part of the protocol, which is used to proxy APP to request user registration from the user; the parameters are shown in Table 5.

table 5

The navigation verification navigator.credentials.get(...): belongs to the interface of the webauthn part of the protocol, and is used to proxy the APP to request user verification from the user; the parameters are shown in Table 6

Table 6

Further, the user registration operation uploads the user information and the public key in the newly generated key pair to the server for registration, and stores the private key locally.

In this embodiment, the verifier is a FIDO2 verifier based on the trusted execution environment, so the private key and other security information are stored in the TEE environment. At the same time, the generation of the public-private key pair is also performed in this environment. When the user sends the registration information to the server, the authentication server will check whether the information is legal to determine whether the registration is successful, and return the result to the user. The specific process is shown in Figure 6:

The basic steps of FIDO2 registration are as follows:

(1) RP APP starts registration and submits a registration application to the server.

(2) The server generates a registration request message, and the server initiates a registration request to the client.

(3) The APP calls the FIDO2 client navigator.credentials.create() interface, and sends a PublicKeyCredentialCreationOptions type object, and the data includes rp information, user information, and credential type.

(4) The client processes the request information, selects the validator, and calls the validator interface

authenticatorMakeCredential(clientDataHash, rp, user, pubKeyCredParams).

(5) The FIDO2 authenticator CA calls the authenticator to collect user identity information, verifies the identity, and calls the Authentication_TA_create() interface after the user is authenticated, so that the authenticator TA completes the "registration" operation, as shown in Figure 7.

a. The authenticator TA key module 4 receives the incoming information.

b. Authenticator TA The key module 4 generates a set of key pairs, where the private key is passed to the storage module 6 .

c. The storage module 6 securely stores the private key.

d. The key module 4 packs the public key and the previously accepted information to the signature module 5 .

f. The signature module 5 signs information such as the public key with the verifier's own private key, generates an attestation object (certificate), and sends this certificate back to the verifier CA.

(6) The authenticator CA returns attestationobject (authdata, fmt, publickey) to the client.

(7) The client processes the information and sends AuthenticatorAttestationResponse to the RP APP. The structure includes clientData and attestationObject.

(8) RP APP returns a Response response to the server.

(9) The relying party server verifies the public key certificate, and stores the public key in the server-side database if the verification is successful.

(10) The server responds with the registration result.

Further, the user verification operation will sign the challenge sent by the agent in the verifier, and return the signed information to the server, and the server will use the public key saved during registration to verify the information.

The registration process is shown in Figure 8 in detail:

FIDO2 authentication authorization process, the process is as follows:

(1) RP APP starts verification and submits a verification application to the server.

(2) The server generates a verification request message, and the server initiates a registration request to the client.

(3) The APP calls the FIDO2 client navigator.credentials.get() interface, and sends a CredentialRequestOptions type object, and the data includes rp id information, user information, and credential type.

(4) The client processes the request information, selects an authenticator, and calls the authenticator interface authenticatorGetAssertion(rpId, clientDataHash).

(5) The FIDO2 authenticator CA calls the authenticator to collect user identity information, verifies the identity, and calls the Authentication_TA_get() interface after the user is verified, so that the authenticator TA completes the "verification" operation. The "verify" operation is shown in Figure 9.

a. The verifier TA signature module 5 receives the transmitted information.

b. The verifier TA signature module 5 queries the storage module 6 for the user's private key.

c. The storage module 6 securely reads the user's private key.

d. The storage module 6 sends the queried private key to the signature module 5 .

f. The signature module 5 signs the challenge and other information with the corresponding private key, generates an assertionObject (assertion), and sends the assertion back to the verifier CA.

(6) The authenticator CA returns assertionObject (credential, authData, signature) to the client.

(7) The client processes the information and sends AuthenticatorAssertionResponse to RP APP, the structure includes clientData, authenticatorData, signature.

(8) RP APP returns a Response response to the server.

(9) The relying party server verifies the assertion with the public key in the server.

(10) The server responds with the verification result.

What is disclosed above is only a preferred embodiment of the Level2 FIDO verifier based on the trusted execution environment of the present invention. Of course, it cannot be used to limit the scope of the present invention. Those of ordinary skill in the art can understand that all or all of the above embodiments can be implemented. Part of the process and the equivalent changes made according to the claims of the present invention still belong to the scope covered by the invention.

Claims (10)

1. A Level2 FIDO verifier based on a trusted execution environment, characterized in that, Including an access device, a client application and a verifier application, the verifier application including a key module, a signature module and a storage module; The access device is configured to connect the authenticator to the user equipment; The client application calls the verifier through the OP-TEE Client API to ensure the integrity of the authentication information of the private key, public key and extended information in the FIDO2 protocol, and to ensure the security of signing the public key or challenge value ; The key module generates the user's public and private keys through an encryption algorithm; The signature module is used to perform a signature operation on relevant data; The storage module is used to store the user's private key and authentication information. 2. The Level2 FIDO validator based on Trusted Execution Environment as claimed in claim 1, characterized in that, The client application and the authenticator application interfaces and parameters include authentication proof output, authentication registration, authentication assertion output, authentication verification, navigation creation, and navigation verification. 3. The Level2 FIDO validator based on Trusted Execution Environment as claimed in claim 2, characterized in that, The authentication certificate output is used for the user to request user registration from the verifier. After the user passes the identity authentication and entry, a new set of key pairs and a certificate are generated. The API accepts a set of inputs and returns a "certificate" Output. 4. The Level2 FIDO verifier based on the Trusted Execution Environment as claimed in claim 2, characterized in that, The authentication registration is used to initiate a request to the authenticator application from the client application of the authenticator during registration, and generate a set of key pairs and a certificate in a trusted environment. The input parameters and return value of the authentication registration should be Consistent with the authentication proof output described. 5. The Level2 FIDO verifier based on the Trusted Execution Environment as claimed in claim 2, characterized in that, The authentication assertion output is used for the user to request user identity verification from the authenticator. After the user passes the identity verification, the public key and the challenge information are signed with the private key. The API accepts a set of inputs and returns an "assertion" Output. 6. The Level2 FIDO verifier based on the Trusted Execution Environment as claimed in claim 2, characterized in that, The authentication verification is used for verifying that the client application of the verifier initiates a request to the verifier application, so that the private key is used to sign the public key and challenge value information in a trusted environment, and its input parameters and return values Should be consistent with the authentication assertion output described. 7. The Level2 FIDO verifier based on a trusted execution environment as claimed in claim 2, said authentication verification is characterized in that, Said navigation creation is used for proxy APP to request user registration from the user. 8. The Level2 FIDO verifier based on a trusted execution environment as claimed in claim 2, wherein: The navigation verification is used to request user verification from the user on behalf of the APP. 9. The Level2 FIDO validator based on the Trusted Execution Environment as claimed in claim 7, characterized in that, The user registration operation uploads the user information and the public key in the newly generated key pair to the server for registration, and stores the private key locally. 10. The Level2 FIDO verifier based on a trusted execution environment as claimed in claim 8, wherein: The user verification operation will sign the challenge sent by the agent in the verifier, and return the signed information to the server, and the server will use the public key saved during registration to verify the information.