# FIDO2 Facing Kleptographic Threats By-Design
## 2 Details of FIDO2
### WebAuthn  
WebAuthn 1 is depicted in Figure 5. It consists of registration and authentication procedures. Typically, the connection between the client and the server is over a secure TLS channel. The connection between the client and the authenticator is a local one. During Registration, an authenticator may use an attestation protocol--the choice depends on the server's attestation preferences and the authenticator's capabilities; see [27] Section 2.1, for more details. Figure 5 is borrowed from [21], where the attestation mode _basic_ is analyzed: the signature \(\sigma\) is generated with the attestation (private) key \(\mathit{ak}_{T}\), which is expected to be deployed on more than 100,000 authenticators (see [23], Section 3.2). The parameter \(\lambda\) defining the minimal bit length of random elements generated during protocol execution is currently set to 128. Accordingly, during Registration, the server generates an at least 128-bit long random string \(\mathit{rs}\) and 512-bit user id \(\mathit{uid}\). These random values and the server's identifier \(\mathit{id}_{S}\) are sent to the client as a server's challenge. The client parses the challenge and aborts if the received identifier \(\mathit{id}_{S}\) does not match the intended identifier \(\widehat{\mathit{id}}_{S}\). Then, the client hashes \(\mathit{rs}\) and sends the result together with \(\mathit{uid}\) and \(\mathsf{id}_{S}\) to the authenticator. The authenticator parses \(M_{r}\) and generates a fresh key pair \((\mathsf{pk},\mathsf{sk})\), which will be used in subsequent authentications to the server \(\mathit{id}_{S}\). Next, it sets the counter \(n\) to zero (the counter shall be incremented at each subsequent authentication session with \(\mathit{id}_{S}\)) and generates a random credential \(\mathit{cid}\) of at least \(\lambda\) bits. Then, the tuple \(\mathit{ad}\) is assembled by the authenticator, and (depending on the choice of attestation mode) a signature on \(\mathit{ad}\) and the hash value \(h_{r}=\mathsf{Hash}(\mathit{rs})\) is generated. Finally, \(\mathit{ad}\) and the generated signature \(\sigma\) are sent to the client, and the authenticator updates its registration context by inserting a record containing the server identifier \(\mathit{id}_{S}\), the user's identifiers \(\mathit{uid}\) and \(\mathit{cid}\), the private key \(\mathsf{sk}\), and the counter \(n\). The client passes \((\mathit{ad},\sigma)\) to the server; the server runs procedure \(\mathsf{rcheck}\) on it. If the checked conditions are satisfied (the signature is valid, etc. ), the server updates its registration context by inserting a record containing the identifiers \(\mathit{uid}\) and \(\mathit{cid}\), the public key \(\mathsf{pk}\), and the counter \(n\). During Authentication, the server chooses a string \(\mathit{rs}\) of length at least \(\lambda\) at random. Next, the server assembles a challenge \(\mathit{cr}\) consisting of \(\mathit{rs}\) and the server identifier \(\mathit{id}_{S}\). Then, \(\mathit{cr}\) is passed to the client. Then, similarly to the registration procedure, the client transforms the challenge by hashing \(\mathit{rs}\). The resulting message \(M_{a}\) is sent to the authenticator. The authenticator parses \(M_{a}\), retrieves \(\mathit{id}_{S}\) and finds a record with \(\mathit{id}_{S}\) created during registration. This record contains, among others, the counter and the dedicated signing key \(\mathsf{sk}\). Then, the authenticator increments the counter and creates a signature over \(\mathsf{Hash}(\mathit{id}_{S})\), the counter, and \(\mathsf{Hash}(\mathit{rs})\) using the key \(\mathsf{sk}\). Finally, the authenticator sends the response (including the signature) to the client and updates the stored record. In the last step, the server accepts if the signature is valid and the signed data matches the expectations. WebAuthn 2 has a richer set of options compared to WebAuthn 1.