FIDO2-based hardware-free password-free authentication extension system

Abstract

The invention belongs to the technical field of identity authentication, and particularly relates to an FIDO2-based hardware-free password-free authentication extension system, which comprises a user, a Web browser, a relying party, an applet and an MQTT broker, and further comprises a user interaction module, a communication establishment module, a mutual authentication module, an interface display module, a certificate generation module and an assertion generation module. According to the method, the browser application supporting the WebAuthn protocol is integrated, and the browser can generate the two-dimensional code containing the specified information, so that an applet can scan the code to establish a communication channel. In the communication process, the MQTT protocol is applied to the communication process of the browser and the applet, and the scheme realizes the password-free authentication process of the external authenticator without the dependence of hardware equipment. In the scheme, the two-dimensional code is generated when the browser is registered and logged in, and the applet scans the two-dimensional code and subscribes the specified MQTT theme, so that a unique and safe MQTT communication channel is established for the two parties, and the two parties are ensured to receive messages sent by each other.

Description

Technical Field

[0001] The present invention relates to the technical field of identity authentication, and in particular to a hardware-free and password-free authentication extension system based on FIDO2. Background Art

[0002] In an increasingly interconnected information society, identity authentication plays a vital role in protecting personal information and digital assets. FIDO2 (Fast Identity Online), as a password-free authentication standard, has begun to be widely used in various online services. In existing FIDO2 solutions, external authenticators are usually used for registration and login, such as USB security keys, BLE-enabled smartphone applications, and NFC-enabled proximity cards to help achieve password-free identity authentication. These external authenticators can store the user's private key and prove the user's identity to the server through secure communication between devices when the user logs in.

[0003] The prior art has the following defects or problems:

[0004] The FIDO2 solution has major flaws when using external authenticators: First, FIDO2 relies on hardware devices such as USB security keys, BLE-enabled smartphones, or NFC cards when using external authenticators. However, many older devices may not support these modern communication interfaces, causing users to face compatibility issues when using these devices. Secondly, users need to carry additional hardware authenticators with them and must authenticate through the authenticator every time they log in. This approach may increase the complexity of users' operations and bring inconvenience to the user experience. Finally, the core of the external authenticator is to securely store the user's private key. If the authenticator device is lost or stolen, the user's private key may be at risk of being leaked. Moreover, once the authenticator is lost or stolen, the user's private key may not be able to be recovered, posing a security risk.

[0005] It should be noted that the above contents belong to the technical knowledge of the inventor and do not necessarily constitute prior art. Summary of the invention

[0006] In view of the deficiencies in the prior art, the present invention provides a hardware-free and password-free authentication extension system based on FIDO2, which solves the current problems.

[0007] To achieve the above-mentioned object, the present invention provides the following technical solutions: a hardware-free and password-free authentication extension system based on FIDO2, comprising a user, a web browser, a relying party, a mini-program, and an MQTT broker;

[0008] The above architecture also includes a user interaction module, a communication establishment module, a mutual authentication module, an interface display module, a credential generation module and an assertion generation module, wherein:

[0009] The user interaction module is used to process the registration / login request initiated by the user in the browser, scan the code using the mini program, and authenticate the relevant user information according to the prompts in the mini program;

[0010] Establish a communication module to establish communication. The browser and the authenticator need to establish an MQTT channel through the MQTT broker, and the two parties communicate through the publish / subscribe mode;

[0011] The mutual authentication module is used to complete the mutual authentication between the browser and the applet, ensuring the identities of both parties to achieve secure data exchange;

[0012] The interface display module includes a mini-program display module and a browser display module. The browser needs to generate a QR code during the registration / login process and display it on the interface. The mini-program needs to display the operation progress during the registration / authentication process, and provide operation prompts to the user and notify the user of the operation results.

[0013] The credential generation module is used to process the parameters passed by the applet during the registration process, store the relevant data in the database and generate credentials;

[0014] The assertion generation module is used to process the parameters passed by the applet during the login process, read the information stored in the database and generate assertions.

[0015] In some of these embodiments, the user interacts with the extension system, initiates a registration / login request at the beginning of the registration / login authenticator, scans a QR code through the authenticator during the registration / login to start the communication process between the browser and the mini-program, and thereafter completes the identity authentication according to the prompts;

[0016] In some of these embodiments, the FIDO client is specifically a web browser, which is responsible for interacting with the user and serving as an intermediary for initiating and completing the FIDO2 authentication process.

[0017] In some embodiments, during the registration and identity authentication process of the user, the relying party generates parameters and sends them to the WEB browser via the TLS protocol, and then the relying party receives and verifies the credentials and assertions, and after successful verification, securely stores the necessary data for identity authentication, and returns the result of the browser verification;

[0018] Mini-program, as part of FIDO2 identity authentication, is responsible for scanning the QR code generated by the browser and subscribing to the MQTT topic for secure communication. It is also responsible for interacting with the browser to forward authentication requests and responses. The mini-program provides a user-friendly interface, through which users can learn about the registration / login process;

[0019] The mini program calls an API to request to connect to the mini program backend server, which is responsible for processing the mini program backend request, including generating credentials / assertions and securely managing and storing data.

[0020] In some of the embodiments, the MQTT broker is used to forward data, control client connections, and ensure the security of data transmission between IoT devices and applications.

[0021] In some embodiments, the user interaction module involves multiple interactive operations between the user and the system at different stages, and the implementation steps are as follows:

[0022] 1) The user accesses the application page in the browser;

[0023] If you want to register an authenticator, the user must first log in to the application with the user name and password, and select Mini Program Registration in the Register Authenticator interface; if you need to use the Mini Program for passwordless login, the user must select Use Mini Program for Passwordless Authentication Login during login. The browser will send the user's request to the relying party, which will generate the corresponding parameters based on the user's request and return them to the browser.

[0024] 2) When the user registers / logs in using the mini program, the user uses the code scanning function to read the QR code generated by the browser and parse the QR code content. According to the root topic in the QR code, a communication channel is established with the browser through the MQTT broker, and subscribes to subtopic 2. Different subtopics are used to distinguish the communication direction and provide support for subsequent interactions.

[0025] 3) The mini program receives the parameters published by the browser under sub-topic 1, and decides whether to prompt the user to complete identity authentication based on the parameters. The identity authentication methods also include fingerprint recognition and face recognition. After the user completes the identity authentication according to the prompt, the mini program passes the verification result and related data to the mini program server to provide support for subsequent credential / assertion generation.

[0026] In some embodiments, the interface display module is responsible for presenting information and feedback during the user process, and its implementation steps are as follows:

[0027] 1) After the user initiates a registration and login request, the browser display module receives the parameters returned by the relying party, generates a QR code including the root topic through the third-party library qrcode, and displays it on the interface in real time, prompting the user to scan the code using the mini program;

[0028] 2) The mini program display module displays the operation progress after scanning the QR code and displays the website information of the current operation. In the identity verification phase, the mini program prompts the user to perform fingerprint and face recognition according to the browser parameters, and displays the registration and login results after the verification is completed;

[0029] The steps for establishing the communication module are as follows:

[0030] 1) The browser initiates a connection request to the MQTT broker, and the MQTT broker agrees to the connection;

[0031] 2) The browser generates a root topic based on the userid, rpid, and current timestamp, and subscribes to subtopic 1 under the root topic. After the subscription is successful, the QR code is displayed;

[0032] 3) After the mini program scans the code, it initiates a connection request to the MQTT broker. After the broker agrees, the mini program subscribes to sub-topic 2.

[0033] In some embodiments, the relevant authentication module implementation steps are specifically as follows:

[0034] 1) After subscribing to the subtopic, the applet sends a request to the public server through the GET method to access the / GenKeyPair interface to obtain the key pair<skA,pkA> , and publish pkA to subtopic 1;

[0035] 2) The browser calls the / FCaction interface with the parameter pkA through the post method to obtain pkC, skC, k and the data verifydata used for verification. The browser publishes verifydata and pkC to subtopic 2 for verification by the mini program.

[0036] 3) The applet calls the / VerifyData interface through the post method with parameters verifydata, pkA, skA, and pkC to verify the browser identity and obtain the negotiated parameter k;

[0037] 4) After the applet obtains the parameter k, it calls the / EncryptMsg interface through the Post method with the parameter ms agreed by both parties to encrypt the data ms. It obtains the encrypted message msg and sends it to the browser;

[0038] 5) After receiving the message msg, the browser uses the Post method to carry the parameters msg,k to call the / DecryptMsg interface to decrypt the message to obtain the decrypted ms;

[0039] 6) The browser verifies whether the parameters are agreed upon with the applet. If so, the communication between the two parties will be encrypted and decrypted using the negotiated key k.

[0040] In some embodiments, the steps of implementing the credential generation module are as follows:

[0041] 1) Get the data passed by the applet, including RP Info, User Info, attestation specifies whether to generate an attestation certificate and the certificate type, userVerification specifies whether the user needs to be verified, and the algorithm type supported by RP--pubKeyCredParams;

[0042] 2) Determine whether to request user authentication based on the value of userVerification. If user authentication is required, the applet should first prompt the user to authenticate their identity to the applet as required. After successful authentication, update the flags value. flags is an 8-bit flag that defines the status of the authenticator during authentication. Bit 0 indicates whether the user is present (UP), bit 2 indicates whether the user has been authenticated (UV), bit 6 indicates whether the CredData object (AT) is included, bit 7 indicates whether there is extended data (ED), and the rest are reserved bits;

[0043] 3) Generate an asymmetric public-private key pair<pkCre,skCre> , decide whether to generate a certificate and the type of certificate based on the RP's attestation parameter;

[0044] 4) Construct a CredData object including aaguid (authenticator identifier, padded with 0), credlength (length of credentialId), credentialId (credential identifier), credentialPublicKey (public key in COSE format);

[0045] 5) Construct the authData object, including rpidHash (hash value of rpId), flags, CredData, signCount (counter, set to 0 when registering and incremented when logging in), and save the necessary data such as private key, credentialId, etc. to the database;

[0046] 6) The mini program server combines fmt (indicating the format of the proof, including packed, none, etc.), attStmt (proof object), and authData into an object, and then encodes it into attObj through CBOR encoding and base64 encoding, and sends it to the mini program;

[0047] 7) The applet encrypts the attObj object using the negotiated key k and sends the encrypted message to subtopic 1.

[0048] In some embodiments, the assertion generation module implements the following steps:

[0049] 1) Get the parameters passed by the applet, including userVerification, rpId relying party ID. If not specified, the current domain name is used by default, and allowCredentials is a list of credential identifiers allowed by the relying party. If the authenticator can recognize the credentials in the list, it will prompt the user to start the assertion generation process;

[0050] 2) Construct the clientDataJSON object, including the challenge value, the origin credential request source, usually https: / / +rpId), type during registration is "webauthn.create", during authentication is "webauthn.get", and generate its hash value FCHash;

[0051] 3) Determine whether to request user authentication based on the value of userVerification. Update the value of flags based on whether the user has been authenticated, whether the user is present, and whether there is extended data. If the flags does not contain a CredData object during the authentication process, set it to No;

[0052] 4) Search the database for the private key that matches the credential ID in the allowed credential identifier list one by one, set the CredData object to null, and construct the authData object;

[0053] 5) Use the private key skCre to<authData,FCHash> Sign to get the signature value S, return authData, S, userHandle (optional parameter, user ID when creating credentials), and clientDataJSON to the mini program.

[0054] Compared with the prior art, the present invention provides a hardware-free and password-free authentication extension system based on FIDO2, which has the following beneficial effects:

[0055] This is a hardware-free and password-free authentication extension system based on FIDO2. By using the mini-program and its background as external authenticators and integrating a browser application that supports the WebAuthn protocol, a platform is built that supports users to use the mini-program to scan the code to register the authenticator, and use the mini-program to log in without password authentication during the login stage; the MQTT protocol is applied to the communication process between the browser and the mini-program, and this solution realizes the password-free authentication process of the external authenticator without hardware. In this solution, the browser generates a QR code when registering and logging in, and the mini-program scans the QR code and subscribes to the specified MQTT topic, thereby establishing a unique MQTT communication channel between the two parties to ensure that both parties can receive messages sent by each other. The communicating parties encrypt and decrypt messages by negotiating keys to ensure the security of information. This solution enables any device that supports QR code scanning and MQTT subscription and publishing to act as a FIDO2 external authenticator, thereby greatly expanding the scope of application of the device. In addition, this solution is seamlessly integrated with the QR code scanning operation used by users in daily life, greatly improving the convenience of user operation. More importantly, user data is stored in a trusted database, and even if the device is lost, users can easily restore account information, ensuring data security. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 It is the overall flow chart of the expansion system of the present invention;

[0057] Figure 2 This is a schematic diagram of a user interaction module of the present invention;

[0058] Figure 3 A schematic diagram of the communication module flow chart is established for the present invention;

[0059] Figure 4 This is a schematic diagram of the mutual authentication module flow of the present invention;

[0060] Figure 5 This is a schematic diagram of the flow of the voucher generation module of the present invention;

[0061] Figure 6 This is a schematic diagram of the assertion generation module flow of the present invention. DETAILED DESCRIPTION

[0062] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0063] It should be understood that the step numbers used in this article are only for the convenience of description and are not intended to limit the order in which the steps are executed.

[0064] It should be understood that the terms used in the present specification are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the present specification and the appended claims, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" are intended to include plural forms.

[0065] The terms “include” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0066] The term "and / or" means and includes any and all possible combinations of one or more of the associated listed items.

[0067] See also Figure 1-6 ,In this implementation: a FIDO2-based hardware-free and password-free authentication extension system includes a user, a web browser, a relying party, an applet, and an MQTT broker;

[0068] The above architecture also includes a user interaction module, a communication establishment module, a mutual authentication module, an interface display module, a credential generation module and an assertion generation module, wherein:

[0069] The user interaction module is used to process the registration / login request initiated by the user in the browser, scan the code using the mini program, and authenticate the relevant user information according to the prompts in the mini program;

[0070] Establish a communication module to establish communication. The browser and the authenticator need to establish an MQTT channel through the MQTT broker, and the two parties communicate through the publish / subscribe mode;

[0071] The mutual authentication module is used to complete the mutual authentication between the browser and the applet, ensuring the identities of both parties to achieve secure data exchange;

[0072] The interface display module includes a mini-program display module and a browser display module. The browser needs to generate a QR code during the registration / login process and display it on the interface. The mini-program needs to display the operation progress during the registration / authentication process, and provide operation prompts to the user and notify the user of the operation results.

[0073] The credential generation module is used to process the parameters passed by the applet during the registration process, store the relevant data in the database and generate credentials;

[0074] The assertion generation module is used to process the parameters passed by the applet during the login process, read the information stored in the database and generate assertions.

[0075] In this embodiment, the user interacts with the extended system, initiates a registration / login request at the beginning of the registration / login authenticator, scans the QR code through the authenticator during the registration / login to start the communication process between the browser and the mini-program, and then completes the identity verification according to the prompts;

[0076] The FIDO client is a web browser that interacts with the user and acts as an intermediary to initiate and complete the FIDO2 authentication process.

[0077] During the user registration and identity authentication process, the relying party generates parameters and sends them to the WEB browser via the TLS protocol. The relying party then receives and verifies the credentials and assertions. After successful verification, it securely stores the necessary data for identity authentication and passes the verification results to the browser.

[0078] Mini Program: As part of FIDO2 authentication, the Mini Program is responsible for scanning the QR code generated by the browser and subscribing to the MQTT topic for secure communication. It is also responsible for interacting with the browser to forward authentication requests and responses. The Mini Program provides a user-friendly interface, through which users can learn about the registration / login process.

[0079] The mini program calls the API to request to connect to the mini program backend server, which is responsible for processing the mini program backend request, including generating credentials / assertions and securely managing and storing data.

[0080] MQTT broker is used to forward data, control client connections, and ensure the security of data transmission between IoT devices and applications.

[0081] The user interaction module involves multiple interactions between the user and the system at different stages. The implementation steps are as follows:

[0082] 1) The user accesses the application page in the browser;

[0083] If you want to register an authenticator, the user must first log in to the application with the user name and password, and select Mini Program Registration in the Register Authenticator interface; if you need to use the Mini Program for passwordless login, the user must select Use Mini Program for Passwordless Authentication Login during login. The browser will send the user's request to the relying party, which will generate the corresponding parameters based on the user's request and return them to the browser.

[0084] When a user registers or logs in to a mini program, the user uses the QR code scanning function to read the QR code generated by the browser and parse the QR code content. According to the root topic in the QR code, a communication channel is established with the browser through the MQTT broker, and subscribes to subtopic 2. Different subtopics are used to distinguish communication directions and provide support for subsequent interactions.

[0085] The mini program receives the parameters published by the browser under sub-topic 1, and decides whether to prompt the user to complete identity authentication based on the parameters. The identity authentication methods also include fingerprint recognition and face recognition. After the user completes the identity authentication according to the prompt, the mini program transmits the verification result and related data to the mini program server to provide support for subsequent credential / assertion generation;

[0086] The interface display module is responsible for presenting information and feedback during the user process. Its implementation steps are as follows:

[0087] 1) After the user initiates a registration and login request, the browser display module receives the parameters returned by the relying party, generates a QR code including the root topic through the third-party library qrcode, and displays it on the interface in real time, prompting the user to scan the code using the mini program;

[0088] 2) The mini program display module displays the operation progress after scanning the QR code and displays the website information of the current operation. In the identity verification phase, the mini program prompts the user to perform fingerprint and face recognition according to the browser parameters, and displays the registration and login results after the verification is completed;

[0089] The specific steps to establish a communication module are as follows:

[0090] 1) The browser initiates a connection request to the MQTT broker, and the MQTT broker agrees to the connection;

[0091] 2) The browser generates a root topic based on the userid, rpid, and current timestamp, and subscribes to subtopic 1 under the root topic. After the subscription is successful, the QR code is displayed;

[0092] 3) After scanning the QR code, the mini program initiates a connection request to the MQTT broker. After agreeing, the mini program subscribes to sub-topic 2;

[0093] The implementation steps of the relevant authentication modules are as follows:

[0094] 1) After subscribing to the subtopic, the applet sends a request to the public server through the GET method to access the / GenKeyPair interface to obtain the key pair<skA,pkA> , and publish pkA to subtopic 1;

[0095] 2) The browser calls the / FCaction interface with the parameter pkA through the post method to obtain pkC, skC, k and the data verifydata used for verification. The browser publishes verifydata and pkC to subtopic 2 for verification by the mini program.

[0096] 3) The applet calls the / VerifyData interface through the post method with parameters verifydata, pkA, skA, and pkC to verify the browser identity and obtain the negotiated parameter k;

[0097] 4) After the applet obtains the parameter k, it calls the / EncryptMsg interface through the Post method with the parameter ms agreed by both parties to encrypt the data ms. It obtains the encrypted message msg and sends it to the browser;

[0098] 5) After receiving the message msg, the browser uses the Post method to carry the parameters msg,k to call the / DecryptMsg interface to decrypt the message to obtain the decrypted ms;

[0099] 6) The browser verifies whether the parameters are agreed upon with the applet. If so, the communication between the two parties is encrypted and decrypted using the negotiated key k;

[0100] The implementation steps of the credential generation module are as follows:

[0101] 1) Get the data passed by the applet, including RP Info, User Info, attestation specifies whether to generate an attestation certificate and the certificate type, userVerification specifies whether the user needs to be verified, and the algorithm type supported by RP--pubKeyCredParams;

[0102] 2) Determine whether to request user authentication based on the value of userVerification. If user authentication is required, the applet should first prompt the user to authenticate their identity to the applet as required. After successful authentication, update the flags value. flags is an 8-bit flag that defines the status of the authenticator during authentication. Bit 0 indicates whether the user is present (UP), bit 2 indicates whether the user has been authenticated (UV), bit 6 indicates whether the CredData object (AT) is included, bit 7 indicates whether there is extended data (ED), and the rest are reserved bits;

[0103] 3) Generate an asymmetric public-private key pair<pkCre,skCre> , decide whether to generate a certificate and the type of certificate based on the RP's attestation parameter;

[0104] 4) Construct a CredData object including aaguid (authenticator identifier, padded with 0), credlength (length of credentialId), credentialId (credential identifier), credentialPublicKey (public key in COSE format);

[0105] 5) Construct the authData object, including rpidHash (hash value of rpId), flags, CredData, signCount (counter, set to 0 when registering and incremented when logging in), and save the necessary data such as private key, credentialId, etc. to the database;

[0106] 6) The mini program server combines fmt (indicating the format of the proof, including packed, none, etc.), attStmt (proof object), and authData into an object, and then encodes it into attObj through CBOR encoding and base64 encoding, and sends it to the mini program;

[0107] 7) The applet encrypts the attObj object using the negotiated key k and sends the encrypted message to subtopic 1;

[0108] The steps to implement the assertion generation module are as follows:

[0109] 1) Get the parameters passed by the applet, including userVerification, rpId relying party ID. If not specified, the current domain name is used by default, and allowCredentials is a list of credential identifiers allowed by the relying party. If the authenticator can recognize the credentials in the list, it will prompt the user to start the assertion generation process;

[0110] 2) Construct the clientDataJSON object, including the challenge value, the origin credential request source, usually https: / / +rpId), type during registration is "webauthn.create", during authentication is "webauthn.get", and generate its hash value FCHash;

[0111] 3) Determine whether to request user authentication based on the value of userVerification. Update the value of flags based on whether the user has been authenticated, whether the user is present, and whether there is extended data. If the flags does not contain a CredData object during the authentication process, set it to No;

[0112] 4) Search the database for the private key that matches the credential ID in the allowed credential identifier list one by one, set the CredData object to null, and construct the authData object;

[0113] 5) Use the private key skCre to<authData,FCHash> Sign to get the signature value S, return authData, S, userHandle (optional parameter, user ID when creating credentials), and clientDataJSON to the mini program.

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

[0115] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art can still modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein by equivalents. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A hardware-free and password-free authentication extension system based on FIDO2, characterized in that: Includes users, web browsers, relying parties, applets, and MQTT brokers; The above architecture also includes a user interaction module, a communication establishment module, a mutual authentication module, an interface display module, a credential generation module and an assertion generation module, wherein: The user interaction module is used to process the registration / login request initiated by the user in the browser, scan the code using the mini program, and authenticate the relevant user information according to the prompts in the mini program; Establish a communication module to establish communication. The browser and the authenticator establish an MQTT channel through the MQTT broker, and both parties communicate through the publish / subscribe mode. The mutual authentication module is used to complete the mutual authentication between the browser and the applet, ensuring the identities of both parties to achieve secure data exchange; The interface display module includes a mini-program display module and a browser display module. The browser needs to generate a QR code during the registration / login process and display it on the interface. The mini-program needs to display the operation progress during the registration / authentication process, and provide operation prompts to the user and notify the user of the operation results. The credential generation module is used to process the parameters passed by the applet during the registration process, store the relevant data in the database and generate credentials; The assertion generation module is used to process the parameters passed by the applet during the login process, read the information stored in the database and generate assertions.

2. According to claim 1, a FIDO2-based hardware-free and password-free authentication extension system is characterized in that: The user interacts with the extended system, initiates a registration / login request at the beginning of the registration / login authenticator, scans the QR code through the authenticator during registration / login to start the communication process between the browser and the mini-program, and then completes the identity authentication according to the prompts.

3. According to claim 1, a FIDO2-based hardware-free and password-free authentication extension system is characterized in that: The FIDO client is specifically a web browser, which is responsible for interacting with the user and serves as an intermediary to initiate and complete the FIDO2 identity authentication process.

4. According to claim 1, a FIDO2-based hardware-free and password-free authentication extension system is characterized in that: During the registration and identity authentication process of the user, the relying party generates parameters and sends them to the WEB browser via the TLS protocol. The relying party then receives and verifies the credentials and assertions. After successful verification, the necessary data is securely stored for identity authentication and the browser verification result is returned. Mini-program, which is part of the external authenticator for FIDO2 authentication. It is responsible for scanning the QR code generated by the browser and subscribing to the MQTT topic for secure communication. It is also responsible for interacting with the browser to forward authentication requests and responses. The mini-program provides a user-friendly interface, through which users can understand the registration / login process; The mini program calls an API to request to connect to the mini program backend server, which is responsible for processing the mini program backend request, including generating credentials / assertions and securely managing and storing data.

5. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The MQTT broker is used to forward data, control client connections, and ensure the security of data transmission between IoT devices and applications.

6. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The user interaction module involves multiple interactive operations between the user and the system at different stages, and its implementation steps are as follows: 1) The user accesses the application page in the browser; If you are registering an authenticator, the user first needs to log in to the application with the username and password, and select Mini Program Registration in the Register Authenticator interface; if you need to use the Mini Program for passwordless login, the user needs to select Use Mini Program for passwordless authentication login when logging in; the browser will send the user's request to the relying party, and the relying party will generate the corresponding parameters based on the user's request and return them to the browser. 2) When the user registers / logs in using the mini program, the user uses the code scanning function to read the QR code generated by the browser and parse the QR code content. According to the root topic in the QR code, a communication channel is established with the browser through the MQTT broker, and subscribes to subtopic 2. Different subtopics are used to distinguish the communication direction and provide support for subsequent interactions. 3) The mini program receives the parameters published by the browser under sub-topic 1, and decides whether to prompt the user to complete identity authentication based on the parameters. The identity authentication methods also include fingerprint recognition and face recognition. After the user completes the identity authentication according to the prompt, the mini program passes the verification result and related data to the mini program server to provide support for subsequent credential / assertion generation.

7. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The interface display module is responsible for presenting information and feedback during the user process, and its implementation steps are as follows: 1) After the user initiates a registration / login request, the browser display module receives the parameters returned by the relying party, generates a QR code including the root topic through the third-party library qrcode, and displays it on the interface in real time, prompting the user to scan the code using the mini program; 2) The mini program display module displays the operation progress after scanning the QR code and displays the website information of the current operation. In the identity verification phase, the mini program prompts the user to perform fingerprint and face recognition according to the browser parameters, and displays the registration and login results after the verification is completed; The steps for establishing the communication module are as follows: 1) The browser initiates a connection request to the MQTT broker, and the MQTT broker agrees to the connection; 2) The browser generates a root topic based on the userid, rpid, and current timestamp, and subscribes to subtopic 1 under the root topic. After the subscription is successful, the QR code is displayed; 3) After the mini program scans the code, it initiates a connection request to the MQTT broker. After the broker agrees, the mini program subscribes to sub-topic 2.

8. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The relevant authentication module implementation steps are as follows: 1) After subscribing to the subtopic, the applet sends a request to the public server through the GET method to access the / GenKeyPair interface to obtain the key pair<skA,pkA> , and publish pkA to subtopic 1; 2) The browser calls the / FCaction interface with the parameter pkA through the post method to obtain pkC, skC, k and the data verifydata used for verification. The browser publishes verifydata and pkC to subtopic 2 for verification by the mini program. 3) The applet calls the / VerifyData interface through the post method with parameters verifydata, pkA, skA, and pkC to verify the browser identity and obtain the negotiated parameter k; 4) After the applet obtains the parameter k, it calls the / EncryptMsg interface through the Post method with the parameter ms agreed upon by both parties to encrypt the data ms. It obtains the encrypted message msg and sends it to the browser; 5) After receiving the message msg, the browser uses the Post method to carry the parameters msg,k to call the / DecryptMsg interface to decrypt the message to obtain the decrypted ms; 6) The browser verifies whether the parameters are agreed upon with the applet. If so, both parties use the negotiated key k for encryption and decryption after communication.

9. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The steps for implementing the credential generation module are as follows: 1) The mini program backend obtains the data transmitted by the mini program, including RP Info, User Info, attestation specifies whether a certificate needs to be generated and the certificate type, userVerification specifies whether the user needs to be verified, and the algorithm type supported by the RP-pubKeyCredParams; 2) Determine whether to request user authentication based on the value of userVerification. If user authentication is required, the applet should first prompt the user to authenticate their identity to the applet as required. After successful authentication, update the flags value. flags is an 8-bit flag that defines the status of the authenticator during authentication. Bit 0 indicates whether the user is present (UP), bit 2 indicates whether the user has been authenticated (UV), bit 6 indicates whether the CredData object (AT) is included, bit 7 indicates whether there is extended data (ED), and the rest are reserved bits; 3) Generate an asymmetric public-private key pair<pkCre,skCre> , decide whether to generate a certificate and the type of certificate based on the RP's attestation parameter; 4) Construct a CredData object including aaguid (authenticator identifier, padded with 0), credlength (length of credentialId), credentialId (credential identifier), credentialPublicKey (public key in COSE format); 5) Construct the authData object, including rpidHash (hash value of rpId), flags, CredData, signCount (counter, set to 0 when registering and incremented when logging in), and save the necessary data such as private key, credentialId, etc. to the database; 6) The mini program server combines fmt (indicating the format of the proof, including packed, none, etc.), attStmt (proof object), and authData into an object, and then encodes it into attObj through CBOR encoding and base64 encoding, and sends it to the mini program; 7) The applet encrypts the attObj object using the negotiated key k and sends the encrypted message to subtopic 1.

10. The FIDO2-based hardware-free and password-free authentication extension system according to claim 1, characterized in that: The steps for implementing the assertion generation module are as follows: 1) Get the parameters passed by the applet, including userVerification, rpId relying party ID. If not specified, the current domain name is used by default, and allowCredentials is a list of credential identifiers allowed by the relying party. If the authenticator can recognize the credentials in the list, it will prompt the user to start the assertion generation process; 2) Construct the clientDataJSON object, including the challenge value, the origin credential request source, usually https: / / +rpId), type during registration is "webauthn.create", during authentication is "webauthn.get", and generate its hash value FCHash; 3) Determine whether to request user authentication based on the value of userVerification. Update the value of flags based on whether the user has been authenticated, whether the user is present, and whether there is extended data. If the flags does not contain a CredData object during the authentication process, set it to No; 4) Search the database for the private key that matches the credential ID in the allowed credential identifier list one by one, set the CredData object to null, and construct the authData object; 5) Use the private key skCre to<authData,FCHash> Sign to get the signature value S, return authData, S, userHandle (optional parameter, user ID when creating credentials), and clientDataJSON to the mini program.

Images