TLS protocol-based biological characteristic authentication extension method, system and product

Abstract

The invention discloses a biological characteristic authentication extension method, system and product based on a TLS protocol, and aims to solve the problems that the existing TLS protocol is widely applied to server identity authentication, but client authentication of the TLS protocol is complex in certificate management and easy to be attacked and the like. The identity authentication based on the upper layer has the problems of easy forgetting, single-point authentication, dependence on firmware, compatibility and the like. In order to solve the problems, TLS protocol extension is designed by utilizing the characteristic that a TLS protocol supports extension, biological characteristic information of a user serves as an identity authentication factor and is combined with the TLS, and non-inductive authentication on different devices in a handshake stage is achieved. Compared with the prior art, full-automatic certification is carried out through a Tamarin Prover tool, the security target of an extension protocol is verified, the security of client identity authentication is effectively improved through a Bio-TLS protocol, and a safer and more convenient authentication mode is provided for a user.

Description

Technical Field

[0001] The present invention belongs to the field of network protocol security technology and cryptography technology, and relates to a biometric authentication extension method, system and product, and specifically to a biometric authentication extension method, system and product based on the TLS protocol. Background Art

[0002] With the rapid development of the Internet, the number of Internet users around the world has reached an astonishing scale. Currently, there are nearly 4 billion users and 1 billion websites on the Internet, building a huge online community. Client identity authentication technology is used to confirm the real identity of the user and prevent unauthorized access, thereby protecting the user's Internet security. In recent years, network attacks and data leaks have occurred frequently, resulting in serious threats to user privacy and property security. As the first line of defense for network security, client identity authentication is crucial to protecting the entire network environment.

[0003] There are currently two main ways of client authentication: one is the certificate support provided by the Transport Layer Security (TLS), that is, client certificate authentication, where the client uses a certificate issued by a trusted third-party certificate authority to prove its identity; the other commonly used method is the upper application layer authentication method based on TLS, which combines traditional authentication methods and biometric authentication technology to provide stronger client authentication security.

[0004] Although the existing TLS protocol is widely used for server-side authentication, it has some security issues:

[0005] 1) Due to the complexity of certificate deployment and management, as well as considerations of user experience and convenience, the current TLS protocol mainly focuses on authenticating the identity of the server, while there are relatively few mandatory requirements for client identity authentication.

[0006] 2) Malicious users can bypass the client authentication of the TLS protocol by forging client certificates or other means, and conduct unauthorized access or man-in-the-middle attacks.

[0007] For the traditional identity authentication of the upper application layer based on TLS:

[0008] 1) Since traditional methods mainly rely on users’ knowledge and physical devices, high-frequency authentication needs can lead to security issues such as password reuse, easy cracking, easy loss and difficulty in management, as well as loss of physical devices that hinder identity authentication.

[0009] 2) Current identity authentication technology lacks unified standards and protocols. There are problems such as uneven quality of identity authentication schemes, independence of each scheme, and inability to interconnect data. This also limits the compatibility between different identity authentication products and increases the complexity of security analysis. Summary of the invention

[0010] In order to solve the security problem of client identity authentication, the present invention provides a biometric authentication extension method, system and product based on the TLS protocol, wherein fingerprint information is selected as an optional extension of TLS.

[0011] The technical solution adopted by the method of the present invention is: a biometric authentication extension method based on the TLS protocol, involving entities including a user, a smart device, a biometric processor set in the smart device, a client and a server installed in the smart device; characterized in that:

[0012] After the user completes the authentication on the smart device through a secure way using the original identity authentication method, the biometric feature is registered on the client, and the user's biometric feature information is collected through the biometric feature processor, and the collected biometric feature data is processed to generate a pair of biometric public and private keys (Fp sk ,Fp pk ) and biometric identifier F id , and (Fp sk ,Fp pk ) and F id stored in a trusted environment of the smart device;

[0013] When the user passes the biometric authentication on the client, the client establishes a TLS handshake connection with the server; the server generates materials for TLS handshake negotiation and identity authentication, generates challenge materials for biometric authentication, and forwards the challenge information to the smart device through the client;

[0014] The biometric processor responds to the challenge sent by the server, generates a biometric signature to prove the identity, sends it to the client together with the biometric public key and identifier, and forwards the response information to the server through the client; the client and server complete the identity authentication during the TLS handshake phase through the biometric challenge-response method.

[0015] Preferably, the biometric feature registration on the client includes two steps: unregistered user authentication failure and user registration; the specific implementation includes the following steps:

[0016] Step 1.1: The client and the server negotiate the parameters they both support;

[0017] The client first sends a ClientHello message and an extended message C-Extension, wherein the ClientHello message includes a temporary random number rc of TLS and a list of supported cipher suites, and the extended message C-Extension includes an "X_hold" string indicating that the client wants to perform biometric authentication;

[0018] The server responds with a ServerHello message and an extended message S-Extension if biometric authentication is supported. The ServerHello message includes a random number rs generated by the server, the selected cipher suite, and the TLS version. The extended message S-Extension includes an "X_accept" string indicating that the server accepts biometric authentication. At the same time, the server generates a round asymmetric key (SKrs0, PKrs0). The client receives the ServerHello message and the extended message S-Extension, and the parameter negotiation is completed.

[0019] Step 1.2: Verify the server identity;

[0020] The server sends a series of encrypted handshake messages, including the asymmetric round public key Authentication random number bior, Certificate, CertVerify and Finished messages; among them, Certificate contains the server's public key certificate; CertVerify contains the handshake record signed so far using the server's private key; Finished contains the hash value of the handshake record so far using the MAC key; after the client receives the encrypted handshake message, it authenticates the certificate, signature and message authentication code; if all authentications are successful, the client generates a round asymmetric key (SKrc0, PKrc0) according to the server-side round key Generate round shared secret

[0021] Step 1.3: User authenticates using biometrics:

[0022] The client sends the authentication random number bior to the biometric feasible environment where the biometric information is located, and the trusted environment signs it with the biometric private key With device identifier D id , biometric identifier F id , biometric public key Fp pkThe client sends the signature, PKrc0 and bior information encrypted with DHc0 as extended information to the server; the server decrypts the received information and obtains biometric related information from the extended information. If it is the first registration, there is no user information in the server's database, the server sends a warning message, the user authentication fails, and executes the following steps to register; if not, execute the following step 1.7;

[0023] Step 1.4: The client and the server negotiate the parameters they both support again;

[0024] The client first sends a ClientHello message and an extended message C-Extension, wherein the ClientHello message includes a temporary random number rc of TLS and a list of supported cipher suites, and the extended message C-Extension includes an "X_hold" string indicating that the client wants to perform biometric authentication;

[0025] The server responds with a ServerHello message and an extended message S-Extension if biometric authentication is supported. The ServerHello message includes a random number rs generated by the server, the selected cipher suite, and the TLS version. The extended message S-Extension includes an "X_accept" string indicating that the server accepts biometric authentication. At the same time, the server generates a round asymmetric key (SKrs1, PKrs1). The client receives the ServerHello message and the extended message S-Extension, and the parameter negotiation is completed.

[0026] Step 1.5: Verify the server identity;

[0027] The server generates a round key (SKrs1, PKrs1) and sends a series of handshake encryption messages, in which the extension contains the round asymmetric public key PKrs1, the biometric authentication random number bior' and "Enter UN, PS"; "Enter UN, PS" means that the server instructs the user to enter the username UN and password PW to register the biometric information because it is not registered;

[0028] Step 1.6: The user authenticates and registers using traditional methods;

[0029] After the client completes the authentication of the server, it forwards the authentication random number bior', the user enters the username and password, and generates this round of asymmetric keys (SKrc1, PKrc1); based on the received server round key PKrs1, it generates the round shared key The smart device prompts the user to enter a username and password, and the biometric processor signs it using the biometric private key And sign, F id , D id , UN, PW and Fp pk Send to the client; after receiving the message, the client sends the user information, signature, PKrc1 and bior' encrypted with DHc1 to the server; the server decrypts Finished, and after successfully authenticating the username and password, authenticates the signed biometric information and shared key;

[0030] Step 1.7: Authentication completed;

[0031] After authentication, the server sends a new session ticket NST. <F id ,D id ,Fp pk ,PKrc1,NST> and<UN,PW> Store it locally and create a user information table. After receiving NST, the client stores <(SKrc1,PKrc1),NST> locally for future session status responses.

[0032] As a preferred method, users who have completed biometric registration use biometrics to perform TLS handshake with the server. The process includes three steps: negotiating parameters, authenticating server identity, and authenticating user identity using biometrics. Before negotiation, both the client and the server have the DH round key from the previous round, which is used to generate and authenticate the DH key for this round.

[0033] Specifically, it includes the following sub-steps:

[0034] Step 2.1: The client and server first negotiate the parameters they both support, and then authenticate the server's identity. At this stage, the server generates the DH round key for this round and sends an encrypted extended message containing the asymmetric round public key.

[0035] Step 2.2: After the client receives the handshake message and successfully authenticates, it uses the server's round key Generate round shared secret Update round key (SKrc n ,PKrc n );

[0036] Step 2.3: Use biometric information to authenticate the user;

[0037] The client will F id , D id , and PKrc nThe information is used as an extended message and is encrypted together with the Finish message that the client needs to send and sent to the server at the same time; is the encryption function;

[0038] Step 2.4: The server authenticates the signed biometric information and shared key;

[0039] Using shared key DHs n Decrypted to get PKrc n ; After the certification is passed, <F id ,D id ,Fp pk ,PKrc n ,NST> is stored locally, the user information table is updated, and the NST is sent to the client;

[0040] Step 2.5: The client will also <(SKrc n ,PKrc n ),NST> is stored locally for future session state recovery.

[0041] As a preferred method, a ratchet algorithm is used to bind the legal devices; specifically, the following sub-steps are included:

[0042] Step 3.1: Initialization;

[0043] In the first round of TLS authentication, the client and server use the DH algorithm to generate a temporary DH key pair (skrc1, pkrc1) and (skrs1, pkrs1), use extended information to send their own DH public keys to each other, and both parties use their own private keys and the other party's public key to generate the first round of DH shared secret keys.

[0044] Step 3.2: The client completes a commitment using the biometric challenge value The server authenticates the commitment and completes the first round of temporary DH authentication; the client stores the temporary DH key pair of this round, and the server stores the client's DH public key for the next round of DH ratchet key generation;

[0045] Step 3.3: In the nth round of TLS handshake;

[0046] First, the client stores the last round of DH temporary round key pair (skrc n-1 ,pkrc n-1 ), the server stores the DH public key pkc sent by the client in the previous round n-1 ; After sending the ServerHello message, the server generates a temporary DH round key pair (skrs n ,pkrsn ), generate this round of DH shared key And send the public key pkrs in the extended information n To the client;

[0047] Step 3.4: Client receives pkrs n After that, generate the DH key DH ratchet step, update and generate a new ratchet key pair (skrc n ,pkrc n );Will Sent to the server; the server uses DHs n Decrypt to get the nth round DH public key pkrc after the client updates n , and stored locally for the next round of TLS handshake authentication.

[0048] As a preference, a user who has registered biometrics uses a new device for biometric authentication, including two steps: authentication failure of an unregistered device and registration of a new device;

[0049] Step 3.1: Use biometric authentication for TLS. The server finds that the device is not registered on the server and the authentication fails.

[0050] Step 3.2: Re-establish TLS handshake authentication and require the user to use password authentication;

[0051] Step 3.3: After authentication, the server will send the new device D id Add to the user information table for subsequent authentication.

[0052] As a preferred choice, we use the automated symbolic analysis tool Tamarin Prover to formally model Bio-TLS, extract the security goals in the specification, set new security goals for the extended protocol, conduct a comprehensive analysis of the extended protocol, and achieve fully automatic verification of the security goals;

[0053] The Tamarin Prover uses a multi-set rewriting rule modeling protocol. The rule runs on the system state, which is represented as a multi-set rule of facts, and the initial state is an empty set. In Tamarin Prover, a rule includes a name and three parts, each of which is a series of facts: left side, action, and right side. The rule can be executed only when all facts on the left side of the rule are available in the current state. When the rule is executed, it consumes the facts on the left side, that is, removes them from the state, and generates facts on the right side, that is, adds them to the state. Action facts do not affect the transition and are used to mark the transition. When the rule is triggered, the action is "recorded" as an observable fact on the path, which is used to define restrictions or express security properties. Facts can generally only be consumed once, but facts starting with the ! symbol are considered persistent facts and can be consumed any number of times. Three specific types of facts are built into Tamarin Prover, Fr(), Out(), and In() facts. Among them, Fr indicates that the fact represents the generation of a new random value, Out() indicates that a message is sent to a public channel, and In() indicates that a message is received from a public channel.

[0054] The technical solution adopted by the system of the present invention is: a biometric authentication extension system based on the TLS protocol, comprising:

[0055] one or more processors;

[0056] A storage device is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the biometric authentication extension method based on the TLS protocol.

[0057] The technical solution adopted by the product of the present invention is: a computer program product, including computer program instructions, when the computer program instructions are run on a computer, the computer executes the biometric authentication extension method based on the TLS protocol.

[0058] The present invention also provides a non-volatile computer-readable storage medium containing a computer program, which, when executed by one or more processors, enables the processors to execute the biometric authentication extension method based on the TLS protocol.

[0059] Compared with the prior art, the beneficial effects of the present invention can include:

[0060] (1) The present invention designs a biometric authentication extension (Bio-TLS) of the TLS handshake protocol. After the user completes the authentication through a secure channel (such as offline or short-term channel) using the original identity authentication method (such as a unique user ID, password), the biometric is registered. On the smart device, the user only needs to complete the identity authentication during the TLS handshake stage through the biometric challenge-response method. This authentication method allows users to complete seamless authentication on different devices without restriction, improving the overall convenience and security.

[0061] (2) The present invention designs a ratchet algorithm for binding legitimate devices. Each time a user performs identity authentication, the shared secret generated by the DH key exchange in the previous authentication process must be used. This means that even if an attacker steals the user's biometrics and device ID, he cannot impersonate the user to complete the identity authentication, thus ensuring the post-complex security (PCS) of biometric authentication.

[0062] (3) The present invention uses Tamarin Prover, an advanced automated symbolic analysis tool, to formally model Bio-TLS, extract security goals from the specification, set new security goals for the extended protocol, conduct a comprehensive analysis of the extended protocol, and achieve fully automatic verification of the security goals. It is proven that the extended TLS protocol is secure, and provides confidentiality, authenticity, and authentication properties of biometric information on the basis of ensuring the key properties of TLS itself, such as session confidentiality, integrity, and server authentication. In addition, in the case of powerful threat capabilities such as attackers remotely compromising user devices and user biometric information, the extended protocol guarantees the backward security properties of biometric authentication. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The technical solution of the present invention is further described below using embodiments and specific implementation methods. In addition, in the process of describing the technical solution, some drawings are also used. For those skilled in the art, other drawings and the intention of the present invention can also be obtained based on these drawings without paying creative work.

[0064] Figure 1 It is a method entity deployment diagram of an embodiment of the present invention;

[0065] Figure 2 A flowchart of a fingerprint registration process according to an embodiment of the invention;

[0066] Figure 3 A flowchart of a fingerprint authentication process according to an embodiment of the invention;

[0067] Figure 4 Flow chart of a new device registration process according to an embodiment of the invention. DETAILED DESCRIPTION

[0068] In order to facilitate ordinary technicians in the field to understand and implement the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the implementation examples described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0069] Although the existing TLS protocol is widely used for server identity authentication, its client authentication has problems such as complex certificate management and vulnerability to attacks; and the identity authentication based on the upper layer has problems such as easy forgetting, single-point authentication, firmware dependence and compatibility. In order to solve these problems, the TLS protocol supports extension features, and this embodiment designs a TLS protocol extension, which uses the user's biometric feature - fingerprint information as an identity authentication factor, and combines it with TLS to achieve seamless authentication on different devices during the handshake stage.

[0070] The TLS protocol is used to build a secure communication channel between the client and the server. This embodiment focuses on the handshake protocol, which defines the process of establishing a secure communication connection between the client and the server for the first time, providing integrity and confidentiality for the application data transmitted subsequently.

[0071] The handshake protocol is divided into three phases: negotiation parameters, authentication, and completion. Figure 1 As shown, the specific process is as follows.

[0072] (1) Negotiating parameters: First, both parties negotiate the parameters they both support. The client sends a ClientHello message, which mainly includes a random number and a list of supported cipher suites, and the server selects a suitable algorithm and sends a ServerHello.

[0073] (2) Authenticating the server: The server then sends four encrypted handshake messages to prove its identity: Extensions contains other parameters not sent in ServerHello; Certificate contains the server's public key certificate; CertVerify contains the signature of the handshake record to date using the server's private key; Finished contains the hash value of the handshake record to date using the MAC key. The Certificate and CertVerify messages are used to authenticate the server, while Finished provides confirmation of the key and record, following the classic Sign-and-MAC protocol design pattern in SIGMA. After this, the client responds and sends its own Finished message. Once the client sends Finished, the handshake phase is over. At this point, the client and server have generated a session key for subsequent encryption of application data.

[0074] (3) Exchange application data: Both parties use the session key to exchange application data.

[0075] This embodiment designs a biometric authentication extension (Bio-TLS, Biometrics-Authenticated TLS Ex-ten-sion) of the TLS handshake protocol, which includes three application scenarios: registering biometrics, adding new devices, and conventional authentication, and uses the DH ratchet algorithm to ensure the backward security of biometric authentication. After the user completes the authentication through a secure channel (such as offline or a short-term channel) using the original identity authentication method (such as a unique user ID, password), the biometric is registered. On smart devices, users only need to use the biometric challenge-response method to complete identity authentication during the TLS handshake stage. This authentication method allows users to complete seamless authentication on different devices without restrictions, improving the overall convenience and security.

[0076] The biometric features of this implementation include, but are not limited to: facial features, including features such as the shape and position of facial contours, eyes, nose, mouth and other parts. Fingerprint features, including features such as the texture of the skin at the end of the finger. Each person's fingerprint is unique. Iris features, including features such as the colored ring-shaped tissue between the pupil and the cornea in the eye. Each person's iris texture is also unique. Hand shape features, including features such as the shape, length, and width of the palm and fingers; voice features, including features such as the tone, volume, speed, and accent of pronunciation. Handwriting features, including features such as the font, size, tilt, and speed of writing. Auricle features, including features such as the shape, size, and position of the ear.

[0077] This embodiment further illustrates the solution of the present invention only through the biometric feature of fingerprint. The solution mainly includes the following 10 polynomial time algorithms:

[0078] (1) Fingerprint signature algorithm. Enter the user's current private key Fp sk And the random number bior to be signed, output the signature σ of the pair.

[0079] (2) Fingerprint authentication algorithm. Input signature σ, signed random number bior signature and user public key Fp pk , when it is a valid signature about σ, output 1, otherwise output 0.

[0080] (3) Certificate signature algorithm. Enter the server private key Sk s and message m, output the signature σ of m.

[0081] (4) Certificate generation algorithm. Input the server's long-term public and private keys Pk s and Sk s , output certificate Cert s .

[0082] (5)CertVerify Pks (ω,m), certificate authentication algorithm. Input signature σ, signature message m and server public key Pk s , when σ is a valid signature about m, output 1, otherwise output 0.

[0083] (6)Enc k (m), encryption algorithm. Input symmetric key k and message m, output ciphertext c.

[0084] (7) Mac k (m), message digest algorithm. Input key k and message m, output the hash value of message m.

[0085] (8)kdf(g xy ,rs,rc), handshake key derivation algorithm. Input temporary Diffie-Hellman shared key g xy , client random number rc and server random number rs, output handshake key hs.

[0086] (9) kdf(hs,log1), multiple key derivation algorithms. Input handshake key hs and handshake transcription log log1, output master key ms, client handshake encryption key Server-side handshake encryption key Client MAC key Server MAC Key

[0087] (10) kdf(ms,log4), application encryption key derivation algorithm. Input master key ms and handshake transcription log log4, output client application encryption key k c and the server-side encryption key k s .

[0088] Please see Figure 1 , a biometric authentication extension method based on the TLS protocol provided in this embodiment involves entities including a user, a smart device, a biometric processor set in the smart device, a client and a server installed in the smart device;

[0089] After the user completes the authentication on the smart device through a secure channel (such as offline or short-term channel) using the original identity authentication method (such as a unique user ID, password), the fingerprint is registered on the client, and the user's fingerprint information is collected through the biometric processor. The collected fingerprint data is processed to generate a pair of fingerprint public and private keys (Fp sk ,Fp pk ) and fingerprint identifier F id , and (Fp sk ,Fp pk ) and F id stored in a trusted environment of the smart device;

[0090] When the user passes the fingerprint authentication on the client, the client establishes a TLS handshake connection with the server; the server generates materials for TLS handshake negotiation and identity authentication, generates challenge materials for fingerprint authentication, and forwards the challenge information to the smart device through the client;

[0091] The biometric processor responds to the challenge sent by the server, generates a fingerprint signature to prove the identity, sends it to the client together with the fingerprint public key and identifier, and forwards the response information to the server through the client; the client and server complete the identity authentication during the TLS handshake stage through the fingerprint challenge-response method.

[0092] Please see Figure 2 In one implementation, the fingerprint registration process is specifically implemented as follows: the user registers the user's fingerprint on the TLS secure channel using a traditional authentication method (such as a password), which includes two steps: unregistered user authentication failure and user registration.

[0093] The specific steps are as follows:

[0094] Step 1.1: Both parties negotiate parameters;

[0095] The client first sends a ClientHello message and an extended message C-Extension, wherein the ClientHello message includes a temporary random number rc of TLS and a list of supported cipher suites, and the extended message C-Extension includes a "finger_hold" string indicating that the client is to perform fingerprint authentication;

[0096] The server replies with a ServerHello message and an extended message S-Extension if fingerprint authentication is supported. The ServerHello message includes a random number rs generated by the server, the selected cipher suite, and the TLS version. The extended message S-Extension includes a "finger_accept" string indicating that the server accepts fingerprint authentication. At the same time, the server generates a round asymmetric key (SKrs0, PKrs0). The client receives the ServerHello message and the extended message S-Extension, and completes the parameter negotiation.

[0097] Step 1.2: Verify the server's identity;

[0098] The server sends a series of encrypted messages, including: Extension, i.e. asymmetric round public key and fingerprint authentication random number bior; Certificate, CertVerify and Finished messages. After the client receives the encrypted handshake message, it authenticates the certificate, signature and message authentication code. If all authentications are successful, the client generates a round asymmetric key (SKrc0, PKrc0) according to the server round key in the extension sent by the server. Generate round shared secret

[0099] Step 1.3: User authenticates identity using fingerprint: The client sends the random number bior to the fingerprint environment where the fingerprint information is located, and the trusted environment signs it using the fingerprint private key With device identifier D id , biometric identifier F id , biometric public key Fp pk The client sends the signature, PKrc0, and bior encrypted with DHc0 as extensions to the server. The server decrypts the received information and obtains fingerprint-related information from the extension. However, since it is the first registration, the server database does not have the user's information, and Fid is not stored in the fingerprint database. Therefore, the server sends a warning message to inform the user that the authentication failed and asks him to register.

[0100] Step 1.4: Both parties negotiate parameters again: After authentication fails, re-establish the connection. And guide the user to complete authentication and fingerprint registration using the traditional username and password. The client sends ClientHello and an extended message, in which the extension contains the string "f_register" indicating that the client wants to register the fingerprint. After receiving the message, the server sends ServerHello and an extended message Extension, in which the extension contains the string "f_regacc" indicating that the server accepts fingerprint registration.

[0101] Step 1.5: Authentication of server identity: The server generates a round key (SKrs1, PKrs1) and sends a series of encrypted messages. The extension includes the round asymmetric public key PKrs1, the fingerprint authentication random number bior' and "Enter UN, PS"; "Enter UN, PS" means that the server instructs the user to enter the username UN and password PW to register the biometric information because it is not registered;

[0102] In any case, the protocol design assumes that the user's behavior is to use fingerprints for TLS handshake, and the server's behavior is determined by whether the user information and device ID have been registered. The server's behaviors include: agreeing to use fingerprints for client identity authentication, refusing users to use fingerprints for authentication and prompting users to register fingerprints, and refusing users to use fingerprints for authentication and prompting users to register new devices.

[0103] Step 1.6: User authenticates and registers using traditional methods: After the client completes the authentication of the server, it forwards the random number bior', prompts the user to enter the username and password, and generates the asymmetric key for this round (SKrc1, PKrc1). Based on the received server round key PKrs1, the round shared key is generated The device prompts the user to enter a username and password, and the processor signs it using the fingerprint private key And sign, F id , D id , UN, PW and Fp pk After receiving the message, the client sends the user information, signature, PKrc1 and bior' encrypted with DHc1 to the server. The server decrypts Finished, authenticates the user name and password successfully, and authenticates the fingerprint information of the signature and the shared key.

[0104] Step 1.7: Authentication completed: After authentication, the server sends a new session ticket NST (NewSessionTicket) <F id ,D id ,Fp pk,PKrc1,NST> and<UN,PW> Stored locally, and establish a user information table. After receiving NST, the client stores <(SKrc1,PKrc1),NST> locally for future session status replies. The new session ticket is an extension of TLS, used to provide session persistence and fast recovery during TLS sessions. The client can use this ticket in future connections to quickly restore the previous TLS session state.

[0105] New Session Ticket (NST) is an extension of TLS that is used to provide session persistence and fast resumption during a TLS session. The client uses this ticket in future connections to quickly resume the previous TLS session state.

[0106] Please see Figure 3 In one implementation, the fingerprint authentication process is specifically implemented as follows: the user who has completed fingerprint registration uses the fingerprint to perform a TLS handshake with the server. The process includes three steps: negotiating parameters, authenticating the server identity, and authenticating the user identity using the fingerprint. Different from the registration stage, before the negotiation, both parties have the DH round key of the previous round, which is used for the generation and authentication of the DH key of this round.

[0107] Step 2.1: Both parties first negotiate the parameters and then authenticate the server's identity. At this stage, the server generates the DH round key for this round. Extensions contains the asymmetric round public key.

[0108] Step 2.2: After the client receives the handshake message and successfully authenticates, it uses the server's round key Generate round shared secret Update round key (SKrc n ,PKrc n ).

[0109] Step 2.3: Use fingerprint information to authenticate the user. At this stage, the client will id , D id , and PKrc n The information is used as an extended message and is encrypted together with the Finish message that the client needs to send and sent to the server at the same time;

[0110] Step 2.4: The server authenticates the signed fingerprint information and shared key. Use the shared key DHs n Decrypted to get PKrc n After the certification is passed, <F id ,D id ,Fp pk ,PKrc n,NST> is stored locally, the user information table is updated, and the NST is sent to the client.

[0111] Step 2.5: The client will also <(SKrc n ,PKrc n ),NST> is stored locally for future session state recovery.

[0112] In one implementation, a DH ratchet algorithm is added to the extension, and the specific algorithm is defined as follows:

[0113] Step 3.1: Initialization: In the first round of TLS authentication, both parties use the DH algorithm to generate a temporary DH key pair (skrc1, pkrc1) and (skrs1, pkrs1), use the extension to send their own DH public key to the other party, and both parties use their own private key and the other party's public key to generate the first round of DH shared secret key

[0114] Step 3.2: The client completes a commitment using the fingerprint challenge value The server authenticates the commitment and completes the first round of temporary DH authentication. The client stores the temporary DH key pair of this round, and the server stores the client's DH public key for the next round of DH ratchet key generation.

[0115] Step 3.3: Use in the nth round of TLS handshake: First, the client stores the previous round of DH temporary round key pair (skrc n-1 ,pkrc n-1 ), the server stores the DH public key pkc sent by the client in the previous round n-1 After sending ServerHello, the server generates a temporary DH round key pair (skrs n ,pkrs n ), generate this round of DH shared key and send the public key pkrs in the extension n To the client.

[0116] Step 3.4: Client receives pkrs n After that, generate the DH key DH ratchet step, update and generate a new ratchet key pair (skrc n ,pkrc n ).Will Send to the server. The server can use DHs n Decrypt to get the nth round DH public key pkrc after the client updates n , and stored locally for the next round of TLS handshake authentication.

[0117] Please see Figure 4 ,In one implementation method, a user who has registered fingerprints uses a new device for fingerprint authentication, which includes two steps: the unregistered device authentication fails and the new device is registered;

[0118] Step 3.1: Use fingerprint authentication for TLS. The server finds that the device is not registered on the server side and the authentication fails.

[0119] Step 3.2: Re-establish TLS handshake authentication and require users to use password authentication

[0120] Step 3.3: After the authentication is passed, the server will add the new device Did to the user information table for subsequent authentication.

[0121] In one implementation, the automated symbolic analysis tool Tamarin Prover is used to formally model Bio-TLS, extract security goals from the specification, set new security goals for the extended protocol, conduct a comprehensive analysis of the extended protocol, and achieve fully automatic verification of the security goals. The extended TLS protocol is proven to be secure, and provides confidentiality, authenticity, and authentication properties of biometric information while ensuring key properties of TLS itself, such as session confidentiality, integrity, and server authentication. In addition, the extended protocol ensures the backward security properties of fingerprint authentication in the case of powerful threat capabilities such as attackers remotely compromising user devices and user fingerprint information.

[0122] Tamarin Prover is a tool for symbolic modeling and analysis of cryptographic protocols. It can automatically analyze whether the security properties of the protocol are satisfied. It has been widely used in the analysis of multiple real-world protocols, such as 5G, Bluetooth, and EMV protocols. Its verification algorithm is based on constraint solving and multi-set rewriting technology, allowing users to prove complex security properties in complex protocols with branches and loops, and includes a graphical user interface that enables visualization and interactive construction of proofs. It takes the modeling protocol and security properties to be proved as input, and outputs whether the modeling protocol satisfies the security properties, thereby proving whether the security properties are satisfied.

[0123] (1) Modeling protocol: Tamarin Prover uses multi-set rewriting rules to model the protocol. Rules operate on system states, which are represented as multi-set rules of facts, with the initial state being an empty set. In Tamarin Prover, a rule consists of a name and three parts, each of which is a series of facts: left side, action, and right side. The rule can only be executed if all facts on the left side of the rule are available in the current state. When the rule is executed, it consumes facts on the left side, i.e., removes them from the state, and generates facts on the right side, i.e., adds them to the state. Action facts do not affect transitions and are used to mark transitions. When the rule is triggered, the action is "recorded" as an observable fact on the path, which is used to define restrictions or express security properties. Facts can generally only be consumed once, but facts starting with the ! symbol are considered persistent facts and can be consumed any number of times. Three specific types of facts are built into Tamarin Prover, namely Fr(), Out(), and In() facts. Among them, Fr indicates that the fact represents the generation of a new (random) value, and Out() indicates that a message is sent to a public channel. In() indicates that a message is received from a public channel. Take the rule Example as an example:

[0124] Rule Examlpe:

[0125] [Fr(~k),Fr(~m)]

[0126] -[Send(~m)]→

[0127] [Out(senc(~m,~k))]

[0128] The name of this rule is Examlpe, with two Fr facts on the left, a custom fact Send as the action, and Out fact on the right. Tamarin Prover can use this rule to transfer states only when all the facts on the left appear in the current state. This rule defines that participants encrypt messages using symmetric encryption functions and keys and send ciphertexts to public channels.

[0129] (2) Security attributes: Security attributes are represented by a set of trajectories defined by first-order logic formulas based on action facts and time points. That is, the attribute specification of Tamarin Prover is a restricted fragment of multi-type first-order logic with time point types, which supports quantitative processing of messages and time points. Specifically, this set of logic allows the expression and verification of properties such as "a certain action occurred at a certain time point" or "a certain message was sent at a certain time point".

[0130] Take Lemma Secrecy as an example:

[0131] Lemma Secrecy:

[0132] "Allx#i.Secrect(x)@i

[0133] = >n ot(Ex#jK( x ) @ j)"

[0134] This lemma defines a simple confidentiality property stating that whenever the action Secret(x) occurs at time i, the adversary cannot obtain x at any time j.

[0135] (3) Attacker capabilities: Tamarin Prover uses the Dolev-Yao attacker model as a built-in attacker model. The attacker has full control over the network and can intercept, send, replay, and delete any message. The attacker can combine any previously learned information to construct new messages and send them to the network.

[0136] Tamarin Prover can enhance or weaken the attacker's capabilities by constructing additional attacker capabilities, such as allowing the compromise of long-term keys of protocol participants; constructing secure communication channels to weaken the attacker's capabilities.

[0137] (4) Proof: For a given property, the goal of Tamarin Prover is to find a model execution trace path that contradicts the property, or to verify that all possible model executions satisfy the property. If an execution path that violates the property can be found, it means that an attack exists and the lemma does not hold; otherwise, the lemma is proved to hold.

[0138] This embodiment also provides a biometric authentication extension system based on the TLS protocol, including:

[0139] one or more processors;

[0140] A storage device is used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the biometric authentication extension method based on the TLS protocol.

[0141] This embodiment also provides a non-volatile computer-readable storage medium containing a computer program. When the computer program is executed by one or more processors, the processors execute the biometric authentication extension method based on the TLS protocol.

[0142] This embodiment also provides a computer program product, including computer program instructions. When the computer program instructions are executed on a computer, the computer executes the biometric authentication extension method based on the TLS protocol.

[0143] The invention is further described below through experiments.

[0144] This experiment was completed in the operating system Ubuntu18.04, the processor was Intel Core i5-84002.8GHz, the memory was 8GB, and the verification tool was Tamarin Prover 1.8.0.

[0145] This experiment modeled and verified three scenarios, including registration and authentication, adding new devices and authentication, normal authentication, and authentication failure. Table 1 shows the authentication results of security attributes under all models. In Model 1 and Model 2, the security attributes required by TLS in the registration phase are considered, and the authentication phase includes the original security attributes of TLS and security attributes related to fingerprint authentication.

[0146] Table 1 Experimental results

[0147]

[0148] Note: C1 represents the confidentiality of the session key, C2 represents the confidentiality of the fingerprint information, and C3 represents the backward security of the session; A1 represents server-side authentication, A2 represents session consistency and uniqueness, and A3 represents the authentication of the fingerprint. √ indicates that the security attribute is satisfied, and ○ does not exist in this model, so no authentication is required.

[0149] The results show that: the extension does not reduce TLS security; secondly, all new security properties related to the extension are verified. Therefore, the experimental results prove that the TLS extension with biometric authentication is secure under 1-RTT.

[0150] The present invention designs a biometric authentication extension of the TLS protocol, which includes three application scenarios: fingerprint registration, adding new devices, and conventional authentication. A DH ratchet algorithm is designed to ensure the backward security of fingerprint authentication. All application scenarios are modeled using Tamarin Prover, and verification and analysis are carried out according to the security goals of the TLS1.3 protocol and the newly constructed security goals. The results show that the extended TLS protocol is secure, and provides the confidentiality, authenticity, and authentication properties of biometric information on the basis of ensuring the key properties of TLS itself, such as session confidentiality, integrity, and server authentication. In addition, the extended protocol guarantees the backward security properties of fingerprint authentication in the case of powerful threat capabilities such as attackers remotely compromising user devices and user fingerprint information. In future work, a wider range of TLS variant protocols will be considered, and efforts will be made to implement this extension in the TLS protocol library to realize the application of biometric information-based authentication on TLS.

[0151] It should be understood that the embodiments described above are part of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be combined with each other arbitrarily to form a feasible technical solution. Such combination is not restricted by the sequence of steps and / or the structural composition mode, but must be based on the ability of ordinary technicians in the field to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the protection scope required by the present invention.

[0152] It should be understood that the above description of the preferred embodiment is relatively detailed and cannot be regarded as limiting the scope of patent protection of the present invention. Under the enlightenment of the present invention, ordinary technicians in this field can also make substitutions or modifications without departing from the scope of protection of the claims of the present invention, which all fall within the scope of protection of the present invention. The scope of protection requested for the present invention shall be based on the attached claims.

Claims

1. A biometric authentication extension method based on the TLS protocol, involving entities including a user, a smart device, a biometric processor set in the smart device, a client and a server installed in the smart device; characterized in that: After the user completes the authentication on the smart device through a secure way using the original identity authentication method, the biometric feature is registered on the client, and the user's biometric feature information is collected through the biometric feature processor, and the collected biometric feature data is processed to generate a pair of biometric public and private keys (Fp sk ,Fp pk ) and biometric identifier F id , and (Fp sk ,Fp pk ) and F id stored in a trusted environment of the smart device; When the user passes the biometric authentication on the client, the client establishes a TLS handshake connection with the server; the server generates the information required for TLS handshake negotiation and identity authentication, generates challenge information for biometric authentication, and forwards the challenge information to the smart device through the client; The biometric processor responds to the challenge sent by the server, generates a biometric signature to prove the identity, sends it to the client together with the biometric public key and identifier, and forwards the response information to the server through the client; the client and server complete the identity authentication during the TLS handshake phase through the biometric challenge-response method.

2. The biometric authentication extension method based on the TLS protocol according to claim 1, characterized in that: The biometric feature registration on the client includes two steps: unregistered user authentication failure and user registration; The specific implementation includes the following steps: Step 1.1: The client and the server negotiate the parameters they both support; The client first sends a ClientHello message and an extended message C-Extension, wherein the ClientHello message includes a temporary random number rc of TLS and a list of supported cipher suites, and the extended message C-Extension includes an "X_hold" string indicating that the client wants to perform biometric authentication; The server responds with a ServerHello message and an extended message S-Extension if biometric authentication is supported. The ServerHello message includes a random number rs generated by the server, the selected cipher suite, and the TLS version. The extended message S-Extension includes an "X_accept" string indicating that the server accepts biometric authentication. At the same time, the server generates a round asymmetric key (SKrs0, PKrs0). The client receives the ServerHello message and the extended message S-Extension, and the parameter negotiation is completed. Step 1.2: Verify the server identity; The server sends a series of encrypted handshake messages, including the asymmetric round public key PK rs0 , authentication random number bior, Certificate, CertVerify and Finished messages; among them, Certificate contains the server's public key certificate; CertVerify contains the handshake record signed with the server's private key to date; Finished contains the hash value of the handshake record to date using the MAC key; after the client receives the encrypted handshake message, it authenticates the certificate, signature and message authentication code; if all authentications are successful, the client generates a round asymmetric key (SKrc0, PKrc0) according to the server-side round key PK rs0 , generate round shared key DHc0=PKrs0 SKrc0 ; Step 1.3: User authenticates using biometrics: The client sends the authentication random number bior to the biometric feasible environment where the biometric information is located, and the trusted environment signs it with the biometric private key. Fpsk (bior), with device identifier D id , biometric identifier F id , biometric public key Fp pk The client sends the signature, PKrc0 and bior information encrypted with DHc0 as extended information to the server; the server decrypts the received information and obtains biometric related information from the extended information. If it is the first registration, there is no user information in the server's database, the server sends a warning message, the user authentication fails, and executes the following steps to register; if not, execute the following step 1.7; Step 1.4: The client and the server negotiate the parameters they both support again; The client first sends a ClientHello message and an extended message C-Extension, wherein the ClientHello message includes a temporary random number rc of TLS and a list of supported cipher suites, and the extended message C-Extension includes an "X_hold" string indicating that the client wants to perform biometric authentication; The server responds with a ServerHello message and an extended message S-Extension if biometric authentication is supported. The ServerHello message includes a random number rs generated by the server, the selected cipher suite, and the TLS version. The extended message S-Extension includes an "X_accept" string indicating that the server accepts biometric authentication. At the same time, the server generates a round asymmetric key (SKrs1, PKrs1). The client receives the ServerHello message and the extended message S-Extension, and the parameter negotiation is completed. Step 1.5: Verify the server identity; The server generates a round key (SKrs1, PKrs1) and sends a series of handshake encryption messages, in which the extension contains the round asymmetric public key PKrs1, the biometric authentication random number bior' and "Enter UN, PS"; "Enter UN, PS" means that the server instructs the user to enter the username UN and password PW to register the biometric information because it is not registered; Step 1.6: The user authenticates and registers using traditional methods; After the client completes the authentication of the server, it forwards the authentication random number bior', the user enters the username and password, and generates this round of asymmetric keys (SKrc1, PKrc1); based on the received server round key PKrs1, the round shared key DHc1 = PKrs1 is generated SKrc 1. The smart device prompts the user to enter the username and password, and the biometric processor signs it using the biometric private key. Fpsk (bior'), and sign, F id , D id , UN, PW and Fp pk Send to the client; after receiving the message, the client sends the user information, signature, PKrc1 and bior' encrypted with DHc1 to the server; the server decrypts Finished, and after successfully authenticating the username and password, authenticates the signed biometric information and shared key; Step 1.7: Authentication completed; After authentication, the server sends a new session ticket NST. <F id ,D id ,Fp pk ,PKrc1,NST> and<UN,PW> Store it locally and create a user information table. After receiving NST, the client stores <(SKrc1,PKrc1),NST> locally for future session status responses.

3. The biometric authentication extension method based on the TLS protocol according to claim 2, characterized in that: Users who have completed biometric registration use biometrics to perform a TLS handshake with the server. The process includes three steps: negotiating parameters, authenticating the server identity, and authenticating the user identity using biometrics. Before negotiation, both the client and the server have the DH round key from the previous round, which is used to generate and authenticate the DH key for this round.

4. The biometric authentication extension method based on the TLS protocol according to claim 3 is characterized in that: Specifically, it includes the following sub-steps: Step 2.1: The client and server first negotiate the parameters they both support, and then authenticate the server's identity. At this stage, the server generates the DH round key for this round and sends an encrypted extended message containing the asymmetric round public key PKrs. n ; Step 2.2: After the client receives the handshake message and successfully authenticates, it uses the server's round key PK rsn , generate round shared key Update round key (SKrc n ,PKrc n ); Step 2.3: Use biometric information to authenticate the user; The client will F id , D id , and PKrc n The information is used as an extended message, encrypted together with the Finish message that the client needs to send, and sent to the server at the same time; is the encryption function; Step 2.4: The server authenticates the signed biometric information and shared key; Using shared key DHs n Decrypted to get PKrc n ; After the certification is passed, <F id ,D id ,Fp pk ,PKrc n ,NST> is stored locally, the user information table is updated, and the NST is sent to the client; Step 2.5: The client will also <(SKrc n ,PKrc n ),NST> is stored locally for future session state recovery.

5. The biometric authentication extension method based on the TLS protocol according to claim 4 is characterized in that: A ratchet algorithm is used to bind legitimate devices; Specifically, it includes the following sub-steps: Step 3.1: Initialization; In the first round of TLS authentication, the client and server use the DH algorithm to generate a temporary DH key pair (skrc1, pkrc1) and (skrs1, pkrs1), use extended information to send their own DH public keys to each other, and both parties use their own private keys and the other party's public key to generate the first round of DH shared secret keys. Step 3.2: The client completes a commitment using the biometric challenge value The server authenticates the commitment and completes the first round of temporary DH authentication; the client stores the temporary DH key pair of this round, and the server stores the client's DH public key for the next round of DH ratchet key generation; Step 3.3: In the nth round of TLS handshake; First, the client stores the last round of DH temporary round key pair (skrc n-1 ,pkrc n-1 ), the server stores the DH public key pkc sent by the client in the previous round n-1 ; After sending the ServerHello message, the server generates a temporary DH round key pair (skrs n ,pkrs n ), generate this round of DH shared key And send the public key pkrs in the extended information n To the client; Step 3.4: Client receives pkrs n After that, generate the DH key DH ratchet step, update and generate a new ratchet key pair (skrc n ,pkrc n );Will Sent to the server; the server uses DHs n Decrypt to get the nth round DH public key pkrc after the client updates n , and stored locally for the next round of TLS handshake authentication.

6. The biometric authentication extension method based on the TLS protocol according to any one of claims 1 to 5, characterized in that: When a user who has registered biometrics uses a new device for biometric authentication, it includes two steps: authentication failure of an unregistered device and registration of a new device; Step 3.1: Use biometric authentication for TLS. The server finds that the device is not registered on the server and the authentication fails. Step 3.2: Re-establish TLS handshake authentication and require the user to use password authentication; Step 3.3: After authentication, the server will send the new device D id Add to the user information table for subsequent authentication.

7. The biometric authentication extension method based on the TLS protocol according to any one of claims 1 to 5, characterized in that: We used the automated symbolic analysis tool Tamarin Prover to formally model Bio-TLS, extract the security goals in the specification, set new security goals for the extended protocol, and conduct a comprehensive analysis of the extended protocol, achieving fully automatic verification of the security goals. The Tamarin Prover uses a multi-set rewriting rule modeling protocol. The rule runs on the system state, which is represented as a multi-set rule of facts, and the initial state is an empty set. In Tamarin Prover, a rule includes a name and three parts, each of which is a series of facts: left side, action, and right side. The rule can be executed only when all facts on the left side of the rule are available in the current state. When the rule is executed, it consumes the facts on the left side, that is, removes them from the state, and generates facts on the right side, that is, adds them to the state. Action facts do not affect the transition and are used to mark the transition. When the rule is triggered, the action is "recorded" as an observable fact on the path, which is used to define restrictions or express security properties. Facts can generally only be consumed once, but facts starting with the ! symbol are considered persistent facts and can be consumed any number of times. Three specific types of facts are built into Tamarin Prover, Fr(), Out(), and In() facts. Among them, Fr indicates that the fact represents the generation of a new random value, Out() indicates that a message is sent to a public channel, and In() indicates that a message is received from a public channel.

8. A biometric authentication extension system based on TLS protocol, characterized in that: include: one or more processors; A storage device for storing one or more programs, which, when executed by the one or more processors, enables the one or more processors to implement the biometric authentication extension method based on the TLS protocol as described in any one of claims 1 to 7.

9. A non-volatile computer-readable storage medium containing a computer program, characterized in that: When the computer program is executed by one or more processors, the processors are enabled to execute the biometric authentication extension method based on the TLS protocol as described in any one of claims 1 to 7.

10. A computer program product comprising computer program instructions, characterized in that: When the computer program instructions are executed on a computer, the computer is enabled to execute the biometric authentication extension method based on the TLS protocol as claimed in any one of claims 1 to 7.

Images