## 2 Related Work
### The FIDO2 Registration and Login Process
#### 2.2.2 Login Phase  
Figure 2 depicts the authentication architecture of FIDO2. During the authentication process, the user selects a previously registered security key for identity verification. When the user wants to log in using the FIDO2 security key, the RP Server generates a challenge and sends it to the authenticator device. The authenticator device verifies the user's identity using methods such as biometrics or a PIN. Upon successful authentication, the device uses its private key to sign the challenge and sends it back to the RP Server. The RP Server then verifies the signature using the corresponding public key and checks if the request is from an authorized user. Below is a description of the eight steps based on the login process diagram. Step 1. Login request:  
When a user requests to log in, the browser initiates a login request and sends the UserAccount to the RP Server. Step 2. PublicKeyCredentialRequestOptions:  
The RP Server creates a PublicKeyCredentialRequestOptions and returns it to the browser, which includes the challenge, allowCredentials, and other parameters. Among them, allowCredentials lists the previously registered credential list to perform the authentication process, as shown in Table 4. \begin{table}
\begin{tabular}{l l} \hline \hline
**id** & Credential ID. \\  & attestationObject: It contains the authenticator data and attestation statement. \\  & clientData: Data transmitted from the client to the authenticator for generating the credential. \\
**type** & Type is public key. \\ \hline \hline \end{tabular}
\end{table} 
Table 3: The parameter list for PublicKeyCredential in FIDO2 registration. Step 3. Verifying origin:  
When the browser receives the relevant information, it verifies whether the rPId in RP Info matches the origin. If the verification is successful, then the browser generates clientData, which is data generated by the browser and has the same content as the one generated during registration. clientData includes origin, challenge, and type. After generating clientData, it is hashed, and then rPId and clientDataHash, along with other information, are passed to the authenticator. Step 4. Verifying user identity:  
During the identity verification process, the authenticator searches for a Credential that matches the rPId and performs user authentication through methods such as biometric verification. Once the authentication is successful, the authenticator creates a new assertion. The authenticator uses the private key generated during registration for this account to sign the clientDataHash and authenticatorData. Step 5. Returning the signed information to the browser:  
The authenticator sends the authenticatorData, clientDataHash, and the signature to the browser. The signature is generated by signing the concatenation of the authenticatorData and clientDataHash. Step 6. Generating PublicKeyCredential: \begin{table}
\begin{tabular}{l p{227.6 pt}} \hline \hline
**id** & The CredentialID is obtained during registration. \\
**type** & The type of the credential, which is public key. \\
**transports** & Specifies the transport methods to be used, such as USB, Bluetooth, or NFC. \\ \hline \hline \end{tabular}
\end{table} 
Table 4: The parameter list for allowCredentials in FIDO2 login. Figure 2: FIDO2 authentication architecture diagram. The browser parses the authenticatorData, clientDataHash, and signature and constructs a PublicKeyCredential object. This object is then returned to the RP Server for verification. The PublicKeyCredential differs from the one used during registration in that it includes the signature but does not include the public key. Refer to Table 5 for the structure of the PublicKeyCredential. Step 7. Parsing and verification:  
The RP Server retrieves the public key from its database and performs signature verification. Also, it confirms whether the challenge signed by the authenticator matches the challenge generated by the RP Server, and verifies whether the rpld matches the expected value. Step 8.