Biometric authentication extension method, system and product based on tls protocol

Abstract

The application discloses a kind of biological characteristic authentication extension methods, system and product based on TLS protocol, although existing TLS protocol is widely applied to server identity authentication, but its client authentication exists certificate management complex, is vulnerable to attack and so on;And based on the identity authentication of upper layer exists easy to forget, single-point authentication, dependent firmware and compatibility and so on.Problems are solved, using the characteristics of TLS protocol support extension, the TLS protocol extension is designed, the biological characteristic information of user is used as identity authentication factor, is combined with TLS, realizes in handshake phase on different equipment without feeling authentication is completed.By Tamarin Prover tool is fully automatic proof, the security target of extension protocol is verified, Bio-TLS protocol effectively improves the security of client identity authentication, provides a more secure, convenient authentication mode for 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 global internet users has reached an astonishing scale. Currently, there are nearly 4 billion users and 1 billion websites on the internet, forming a vast online community. Client-side authentication technology is used to verify the user's true identity and prevent unauthorized access, thereby protecting users' online security. In recent years, frequent cyberattacks and data leaks have posed serious threats to user privacy and financial security. As the first line of defense in network security, client-side authentication is crucial to safeguarding the entire network environment.

[0003] Currently, there are two main methods for client authentication: one is the certificate support provided by the Transport Layer Security (TLS) protocol, that is, client certificate authentication, in which 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 with 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 TLS client authentication by forging client certificates or other means, thereby gaining unauthorized access or performing man-in-the-middle attacks.

[0007] For traditional identity authentication at 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 issues existing in 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 installed in the smart device, and a server; characterized by:

[0012] After the user completes the authentication on the smart device through the original identity authentication method in a secure way, the biometric feature is registered on the client, and the biometric feature processor collects the user's biometric feature information, 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 TLS handshake negotiation and identity authentication materials, generates biometric authentication challenge materials, 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 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 identity authentication during the TLS handshake phase through a 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 server negotiate mutually supported parameters;

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

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

[0019] Step 1.2: Verify the server's 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 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 verifies 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 using 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 information from the extended information. If it is the first registration, the server database does not have the user information, and the server sends a warning message, indicating that the user authentication has failed. The server then performs the following steps to register. If not, it performs the following step 1.7.

[0023] Step 1.4: The client and server negotiate mutually supported parameters again;

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

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

[0026] Step 1.5: Verify the server's identity;

[0027] The server generates round keys (SKrs1, PKrs1) and sends a series of handshake encrypted messages, which include the round asymmetric public key PKrs1, the biometric authentication random number bior', and "Enter UN, PS". "Enter UN, PS" indicates that the server instructs the user to enter the username UN and password PW to register the biometric information because the user has not registered yet.

[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 the asymmetric key for this round (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 Sent 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, authenticates the user name and password successfully, and then authenticates the signed biometric information and shared key;

[0030] Step 1.7: Authentication completed;

[0031] After authentication is passed, 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] Preferably, users who have completed biometric registration use their biometrics to perform a TLS handshake with the server. This process includes three steps: negotiating parameters, authenticating the server's identity, and authenticating the user's identity using biometrics. Before the negotiation, both the client and the server have the previous DH round key stored, which is used to generate and authenticate the current DH key.

[0033] Specifically including 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 will use 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 sent to the server as an extended message, encrypted together with the Finish message that the client needs to send. is the encryption function;

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

[0039] Using shared secret DHs n Decrypted to get PKrc n ; After the authentication 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] During 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 the extended information 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.

[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 for this round, and the server stores the client's DH public key for use in generating the next round of DH ratchet keys.

[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 the DH temporary 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 to generate a new ratchet key pair (skrc n ,pkrc n );Will Sent to the server; the server uses DHs n Decrypted 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, users who have registered their biometrics use a new device for biometric authentication, including the two steps of authentication failure of an unregistered device and registration of a new device;

[0049] Step 3.1: Using biometric authentication for TLS, the server finds that the device is not registered with 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 the authentication is passed, the server will send the new device D id Add to the user information table for subsequent authentication.

[0052] As a preferred option, we used the automated symbolic analysis tool Tamarin Prover to formally model Bio-TLS, extract the security goals from the specification, set new security goals for the extended protocol, and conduct a comprehensive analysis of the extended protocol, achieving fully automated verification of the security goals.

[0053] Tamarin Prover uses a multi-set rewriting rule modeling 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: a left-hand side, an action, and a right-hand side. A rule can be executed only if all facts on the left-hand side of the rule are available in the current state. When a rule is executed, it consumes facts on the left-hand side, i.e., removes them from the state, and generates facts on the right-hand side, i.e., adds them to the state. Action facts do not affect transitions and are used to mark transitions. When a rule is triggered, the action is "recorded" as an observable fact on the path, which can be 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(). Fr indicates that the fact generates 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, which, when executed by the one or more processors, enable the one or more processors to 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, which, when executed on a computer, enable the computer to execute 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 include:

[0060] (1) The present invention designs a biometric authentication extension (Bio-TLS, Biometrics-Authenticated TLS Extension) 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 phase through the biometric challenge-response method. This authentication method allows users to complete non-sensing authentication on different devices without restriction, improving the overall convenience and security.

[0061] (2) This invention designs a ratchet algorithm for binding legitimate devices. Each time a user authenticates, the shared secret generated by the DH key exchange during the previous authentication round must be used. This means that even if an attacker steals the user's biometrics and device ID, they cannot impersonate the user to complete the authentication, thus ensuring the backward security (PCS) of biometric authentication.

[0062] (3) This paper 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 proves that the extended TLS protocol is secure. On the basis of ensuring the key properties of TLS itself, such as session confidentiality, integrity, and server authentication, it provides the confidentiality, authenticity, and authentication properties of biometric information. In addition, under the powerful threat capabilities of attackers who can remotely compromise user devices and user biometric information, the extended protocol ensures the backward security properties of biometric authentication. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0065] Figure 2 A flowchart of the 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 Flowchart of a new device registration process according to an embodiment of the invention. DETAILED DESCRIPTION

[0068] In order to facilitate ordinary technicians in this field to understand and implement the present invention, the present invention is further described in detail below with reference to the accompanying drawings and examples. 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] While the existing TLS protocol is widely used for server authentication, its client authentication suffers from complex certificate management and vulnerability to attacks. Upper-layer authentication, on the other hand, suffers from issues such as easy forgetfulness, single-point authentication, firmware dependency, and compatibility. To address these issues, this embodiment utilizes the TLS protocol's extended support. This implementation utilizes a TLS protocol extension that incorporates the user's biometric fingerprint as an authentication factor, integrating it with TLS to enable seamless authentication across different devices during the handshake phase.

[0070] The TLS protocol is used to establish a secure communication channel between a client and a server. This example 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 subsequent application data transmission.

[0071] The handshake protocol is divided into three phases: negotiation parameters, authentication and completion phase, such as 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. The server selects an appropriate algorithm and sends a ServerHello message.

[0073] (2) Authenticating the server: The server then sends four encrypted handshake messages to prove its identity: Extensions contains additional parameters not sent in ServerHello; Certificate contains the server's public key certificate; CertVerify contains the signature of the handshake record so far using the server's private key; Finished contains the hash value of the handshake record so far 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), he registers the biometric. On smart devices, users only need to use the biometric challenge-response method to complete identity authentication in the TLS handshake stage. This authentication method allows users to complete seamless authentication on different devices without restriction, improving 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, etc. Fingerprint features, including features such as the texture of the skin at the end of the finger, and each person's fingerprint is unique. Iris features, including features such as the colored ring-shaped tissue located between the pupil and cornea in the eye, and 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, speaking 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 using fingerprint as a biometric feature. 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 , output 1 when it is a valid signature about σ, 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 , output 1 when σ is a valid signature about m, 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), applies the encryption key derivation algorithm. Input the master key ms and the handshake transcription log log4, and output the client application encryption key k c and the server-side encryption key k s .

[0088] Please see Figure 1 This embodiment provides 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 installed in the smart device, and a server;

[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 unique user identification, password), the fingerprint is registered on the client, the user's fingerprint information is collected through the biometric processor, and 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 fingerprint authentication challenge materials, 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 identity authentication during the TLS handshake phase through the fingerprint challenge-response method.

[0092] Please see Figure 2 In one embodiment, 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. The ClientHello message includes a temporary random number rc for TLS and a list of supported cipher suites. The extended message C-Extension includes a "finger_hold" string indicating that the client wants to perform fingerprint authentication.

[0096] If fingerprint authentication is supported, the server responds with a ServerHello message and an S-Extension message. The ServerHello message includes the random number rs generated by the server, the selected cipher suite, and the TLS version. The S-Extension message includes the "finger_accept" string indicating that the server accepts fingerprint authentication. The server also generates a round asymmetric key (SKrs0, PKrs0). The client receives the ServerHello message and the S-Extension message, completing 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 The client then generates the round asymmetric key (SKrc0, PKrc0) and 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 then sends the signature, PKrc0, and bior encrypted using DHc0 as an extension to the server. The server decrypts the received information and obtains the fingerprint-related information from the extension. However, since this is the first registration, the server database does not have the user's information, and the Fid is not stored in the fingerprint database. Therefore, the server sends a warning message to the user, informing him that the authentication failed and requesting registration.

[0100] Step 1.4: Both parties negotiate parameters again. After authentication fails, the connection is reestablished. The user is guided to complete authentication and fingerprint registration using a traditional username and password. The client sends a ClientHello message and an extension message containing the string "f_register" indicating that the client wishes to register a fingerprint. Upon receiving this message, the server sends a ServerHello message and an extension message containing the string "f_regacc" indicating that the server accepts fingerprint registration.

[0101] Step 1.5: Authenticate the server: The server generates round keys (SKrs1, PKrs1) and sends a series of encrypted messages. The extension includes the asymmetric round public key PKrs1, the fingerprint authentication random number bior', and "Enter UN, PS". "Enter UN, PS" indicates that the server instructs the user to enter the username UN and password PW to register their biometric information, as they have not yet registered.

[0102] In all cases, the protocol design assumes that the user will use fingerprints for the TLS handshake. The server's behavior is determined by the user information and whether the device ID has been registered. The server's behavior can be: agree to use fingerprints for client authentication, deny fingerprint authentication and prompt the user to register a fingerprint, or deny fingerprint authentication and prompt the user to register a new device.

[0103] Step 1.6: User authenticates and registers using traditional methods: After the client completes authentication with 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 using DHc1 to the server. The server decrypts Finished and, after successfully authenticating the username and password, authenticates the signed fingerprint information and shared key.

[0104] Step 1.7: Authentication completed: After the authentication is passed, the server sends a new session ticket NST (NewSessionTicket) <F id ,D id ,Fp pk,PKrc1,NST> and<UN,PW> The client stores the NST locally and creates a user information table. After receiving the NST, the client stores <(SKrc1,PKrc1),NST> locally for future session state responses. The new session ticket is a TLS extension that provides session persistence and fast resumption during TLS sessions. The client can use this ticket in future connections to quickly resume the previous TLS session state.

[0105] New Session Ticket (NST) is an extension of TLS that provides 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 as follows: After completing fingerprint registration, the user uses their fingerprint to perform a TLS handshake with the server. This process includes three steps: parameter negotiation, server authentication, and user authentication using fingerprints. Unlike the registration phase, both parties have access to the previous DH round key before negotiation, which is used to generate and authenticate the current DH key.

[0107] Step 2.1: The two parties first negotiate parameters and then authenticate the server's identity. At this stage, the server generates the DH round key for this round. Extensions contain 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 sent to the server as an extended message, encrypted together with the Finish message that the client needs to send.

[0110] Step 2.4: The server authenticates the signed fingerprint information and shared key. Use shared key DHs n Decrypted to get PKrc n After the authentication 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 embodiment, the DH ratchet algorithm is added to the extension, and the specific algorithm is defined as follows:

[0113] Step 3.1: Initialization: During 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, completing the first round of temporary DH authentication. The client stores the temporary DH key pair for this round, and the server stores the client's DH public key for use in generating the next round of DH ratchet keys.

[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 to generate a new ratchet key pair (skrc n ,pkrc n ).Will Send to the server. The server can use DHs n Decrypted 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 a fingerprint uses a new device for fingerprint ,authentication, which includes two steps: the unregistered device fails in authentication and the ,registration of a new device;

[0118] Step 3.1: Using 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 authentication is successful, the server adds the new device Did to the user information table for subsequent authentication.

[0121] In one implementation, the automated symbolic analysis tool Tamarin Prover was used to formally model Bio-TLS, extract security goals from the specification, set new security goals for the extended protocol, and conduct a comprehensive analysis of the extended protocol, achieving fully automated verification of the security goals. The extended TLS protocol was proven to be secure, providing confidentiality, authenticity, and authentication properties for biometric information while maintaining the key TLS properties of session confidentiality, integrity, and server authentication. Furthermore, the extended protocol ensures the backward security properties of fingerprint authentication, even in the face of powerful threats such as remote compromise of user devices and user fingerprint information.

[0122] Tamarin Prover is a tool for symbolic modeling and analysis of cryptographic protocols. It automatically analyzes whether a protocol's security properties are satisfied. It has been widely used in the analysis of multiple real-world protocols, such as 5G, Bluetooth, and EMV. Its verification algorithm, based on constraint solving and multi-set rewriting techniques, allows users to prove complex security properties in complex protocols with branches and loops. It includes a graphical user interface for visualizing and interactively constructing proofs. It takes as input the modeled protocol and the security property to be proved, and outputs a statement indicating whether the modeled protocol satisfies the security property, thereby proving whether the security property is satisfied.

[0123] (1) Modeling protocol: Tamarin Prover uses a multi-set rewriting rule modeling protocol. Rules operate on the system state, which is represented as a multi-set rule 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: a left side, an action, and a right side. The rule can only be executed if all the 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, 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 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. 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. Take the rule Example as an example:

[0124] rule Examlpe:

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

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

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

[0128] This rule is named Examlpe. It has two Fr facts on the left, a custom "Send" action, and an "Out" fact on the right. Tamarin Prover can only use this rule to transition to a new state if all the facts on the left are present in the current state. This rule requires participants to encrypt messages using a symmetric encryption function and key and then send the ciphertext to a public channel.

[0129] (2) Security properties: Security properties are represented by a set of trajectories defined by first-order logic formulas based on action facts and time points. That is, Tamarin Prover's property specification is a restricted fragment of multi-type first-order logic with time point types. This logic supports quantification of messages and time points. Specifically, this 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 its built-in attacker model. The attacker has complete control over the network and can intercept, send, replay, and delete any message. The attacker can also 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 the long-term keys of protocol participants; and 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, which, when executed by the one or more processors, enable the one or more processors to 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 is caused to execute 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 Ubuntu 18.04, the processor was Intel Core i5-8400 2.8 GHz, the memory was 8 GB, and the verification tool was Tamarin Prover 1.8.0.

[0145] This experiment modeled and verified three scenarios: registration and authentication, adding a new device and authenticating it, normal authentication, and authentication failure. Table 1 shows the verification results for security attributes under all models. Models 1 and 2 consider the security attributes required by TLS during the registration phase, while the authentication phase includes the original TLS security attributes 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 fingerprint authentication. √ indicates that the security property is satisfied, while ○ indicates that this property does not exist in this model and authentication is not required.

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

[0150] The present invention designs a biometric authentication extension for the TLS protocol, which includes three application scenarios: registering fingerprints, adding new devices, and conventional authentication. A DH ratchet algorithm is also designed to ensure the backward security of fingerprint authentication. All application scenarios are modeled using Tamarin Prover, and are verified and analyzed based on 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 while ensuring the 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. 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 only some of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention may be arbitrarily combined with each other to form a feasible technical solution. Such combination is not restricted by the order of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is mutually inconsistent or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection claimed 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 protection of the patent of the present invention. Under the guidance 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 by 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 provided in the smart device, a client installed in the smart device, and a server; characterized by: After the user completes the authentication on the smart device through the original identity authentication method in a secure way, the biometric feature is registered on the client, and the user's biometric feature information is collected through the biometric feature processor. The collected biometric feature data is processed to generate a pair of biometric public and private keys. and biometric identifiers , and and 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 biometric authentication challenge information, 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 identity, and sends it to the client together with the biometric public key and identifier. The client then forwards the response information to the server. The client and server complete identity authentication during the TLS handshake phase through a biometric challenge-response method. The biometric 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 server negotiate mutually supported parameters; The client first sends a ClientHello message and an extended message C-Extension. The ClientHello message includes a temporary random number for TLS. and a list of supported cipher suites, the extended message C-Extension including an "X_hold" string indicating that the client wants to perform biometric authentication; The server responds with a ServerHello message and an S-Extension message if it supports biometric authentication. The ServerHello message includes a random number generated by the server. , the selected cipher suite, 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 The client receives the ServerHello message and the extended message S-Extension, completing the parameter negotiation. Step 1.2: Verify the server's identity; The server sends a series of encrypted handshake messages, including the asymmetric round public key , authentication random number , 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 verifies the certificate, signature and message authentication code; if all authentications are successful, the client generates a round asymmetric key , according to the server-side round key , generate round shared key ; Step 1.3: User authenticates using biometrics: The client will authenticate the random number Sent to the biometric feasible environment where the biometric information is located, and the trusted environment signs it using the biometric private key , with the device identifier , biometric identifiers , biometric public key Send it to the client together; the client will sign, and use Encrypted The information is sent to the server as extended information. The server decrypts the received information and obtains the biometric information from the extended information. If it is the first registration, the server database does not have the user information, and the server sends a warning message, indicating that the user authentication has failed. The server then performs the following steps to register. If not, the server performs the following step 1.

7. Step 1.4: The client and server negotiate mutually supported parameters again; The client first sends a ClientHello message and an extended message C-Extension. The ClientHello message includes a temporary random number for TLS. and a list of supported cipher suites, the extended message C-Extension including an "X_hold" string indicating that the client wants to perform biometric authentication; The server responds with a ServerHello message and an S-Extension message if it supports biometric authentication. The ServerHello message includes a random number generated by the server. , the selected cipher suite, 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 The client receives the ServerHello message and the extended message S-Extension, completing the parameter negotiation. Step 1.5: Verify the server's identity; Generate round keys on the server And send a series of handshake encrypted messages, where the extension contains the round asymmetric public key , biometric authentication random number and "Enter UN, PS"; "Enter UN, PS" means the server instructs the user to enter a user name because there is no registration. and password to register biometric information; 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 , the user enters the username and password, and generates this round of asymmetric keys ; Based on the server-side round key received , generate round shared key The smart device prompts the user to enter their username and password, and the biometric processor signs it using the biometric private key. , and sign, 、 and Send to the client; after receiving the message, the client will send the user information, signature, and use Encrypted Send to the server; the server decrypts Finished, authenticates the username and password successfully, and then authenticates the signed biometric information and shared key; Step 1.7: Authentication completed; After authentication is passed, the server sends a new session ticket NST. and Stored locally, and establish a user information table; after the client receives the NST, Stored locally for future session state replies.

2. The biometric authentication extension method based on the TLS protocol according to claim 1, characterized in that: After completing biometric registration, users use their biometrics to perform a TLS handshake with the server. The process includes three steps: negotiating parameters, authenticating the server's identity, and authenticating the user's identity using biometrics. Before negotiation, both the client and the server store the previous DH round key, which is used to generate and authenticate the current DH key.

3. The biometric authentication extension method based on the TLS protocol according to claim 2, characterized in that: Specifically 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. ; Step 2.2: After the client receives the handshake message and successfully authenticates, it will use the server's round key , generate round shared key , update the round key ; Step 2.3: Use biometric information to authenticate the user; The client will and The information is sent to the server as an extended message, encrypted together with the Finish message that the client needs to send. is the encryption function; Step 2.4: The server authenticates the signed biometric information and shared key; Using a shared secret Decrypted ; After the authentication is passed, Store locally, update the user information table, and send NST to the client; Step 2.5: The client will also Stored locally for future session state restoration.

4. The biometric authentication extension method based on the TLS protocol according to claim 3, characterized in that: Use ratchet algorithm to bind legal devices; Specifically includes the following sub-steps: Step 3.1: Initialization; During the first round of TLS authentication, the client and server use the DH algorithm to generate a temporary DH key pair. and , use the extended information to send your 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 ; 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 previous DH temporary round key pair The server stores the DH public key sent to it by the client in the previous round ; After sending the ServerHello message, the server generates a temporary DH key pair for this round. , generate this round of DH shared key , and send the public key in the extended information To the client; Step 3.4: Client receives After that, generate the DH key ;DH ratchet step, update and generate a new ratchet key pair ;Will Sent to the server; the server uses Decrypt to get the nth round DH public key after the client updates , and stored locally for the next round of TLS handshake authentication.

5. The biometric authentication extension method based on the TLS protocol according to any one of claims 1 to 4, characterized in that: When a user who has registered biometrics uses a new device for biometric authentication, the authentication process includes two steps: authentication failure of an unregistered device and registration of a new device. Step 3.1: Using biometric authentication for TLS, the server finds that the device is not registered with 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 the authentication is passed, the server will Add to the user information table for subsequent authentication.

6. The TLS-based biometric authentication extension method according to any one of claims 1 to 4, characterized in that: We used Tamarin Prover, an automated symbolic analysis tool, to formally model Bio-TLS, extract security goals from the specification, set new security goals for the extended protocol, and conducted a comprehensive analysis of the extended protocol, achieving fully automated verification of the security goals. The Tamarin Prover uses a multi-set rewriting rule modeling protocol. Rules operate on system states, which are represented as multi-set rules of facts, with an empty set as the initial state. In Tamarin Prover, a rule consists of a name and three parts, each of which is a series of facts: a left side, an action, and a right side. The rule can be executed only 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 a 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. Fr indicates that the fact represents the generation of a new random value, Out() indicates sending a message to a public channel, and In() indicates receiving a message from a public channel.

7. A biometric authentication extension system based on the 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 6.

8. 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 perform the biometric authentication extension method based on the TLS protocol according to any one of claims 1 to 6.

9. A computer program product comprising computer program instructions, characterized in that: When the computer program instructions are executed on a computer, the computer is caused to execute the biometric authentication extension method based on the TLS protocol according to any one of claims 1 to 6.

Images