## 2 Related Work
### The FIDO2 Registration and Login Process
#### 2.2.1 Registration Phase  
As shown in Figure 1, FIDO2's registration process involves the user sending a registration request to the RP Server, which then sends a challenge to the authenticator. After biometric verification, the authenticator generates a new key pair and signs the challenge using the private key. The signed challenge and public key are then returned to the RP Server for verification and storage. Authenticators can be biometric devices, smart cards, USB keys, or mobile devices used for identity verification, while the RP Server is responsible for registering and authenticating user identities. ECDSA is used in this process, providing efficient and secure digital signatures based on elliptic curve cryptography [11; 12; 13]. Below is a description of the eight steps based on the registration process diagram. Step 1. Registration request:  
When a user wants to register an authenticator, the browser initiates a registration request and sends the UserAccount to the RP Server. During this process, it is recommended to collect aliases for the authenticators. Aliases can help users easily identify them when multiple authenticators are registered. Step 2. Generating PublicKeyCredentialCreationOptions:  
Upon receiving the registration request from the browser, the RP Server generates a challenge and creates an empty object called PublicKeyCredentialCreationOptions. This object contains information related to User Info, RP Info, and the required credential types. _User Info_ includes relevant data about the user account, where the userAccount can be associated with the credential by the authenticator. This association enables the verification of the user's identity when using the same userAccount and authenticator for future authentication purposes. RP Info refers to the organization or service responsible for registering and authenticating users. Step 3. Generating clientData:  
When the browser receives the relevant information, it verifies whether the rPId in RP Info matches the origin (original URL). If the verification is successful, then the browser generates clientData, which is a piece of data generated by the browser, as shown in Table 1. It includes the origin, challenge, and type. Its significance lies in preventing phishing attempts and replay attacks. After generating clientData, it is hashed, and then the RP Info, User Info, and clientDataHash are passed to the authenticator. Step 4. Verifying user identity:  
After receiving the RP Info, User Info, and clientDataHash, the authenticator performs biometric authentication on the user. Once the authentication is successful, the authenticator creates a new pair of asymmetric keys and stores the private key within the authenticator. The public key becomes part of the attestation. The private key is then used to sign the clientDataHash and attestation. Step 5. Returning attestationObject and clientData to the browser:  
After generating the PublicKey, CredentialID, and other attestation data, they are combined to form the _attestationObject_, which is then sent to the browser along with the clientDataHash. The contents of the attestationObject are shown in Table 2. \begin{table}
\begin{tabular}{l p{227.6 pt}} \hline \hline
**challenge** & Randomly generated random value. \\
**origin** & The origin string must be verified to match the origin of the application. \\
**type** & Verify if the string matches “webauth.create”. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The parameter list for clientData in FIDO2 registration. Figure 1: FIDO2 registration architecture diagram. Step 6. Generating PublicKeyCredential:  
The browser parses the clientDataHash and attestationObject, and generates the PublicKeyCredential, which is then returned to the RP Server for verification. During the registration phase, the _PublicKeyCredential_ is created using the \"publicKey\" option, allowing for the creation of a new Credential. The structure of the PublicKeyCredential is shown in Table 3.  
Step 7.