# FIDO2 Facing Kleptographic Threats By-Design
## 4 Linking Attacks with Discrete Logarithm Signatures
### Attack 2: Identity Sieve via Rejection Sampling Attack prerequisites:
### Second Attack Phase

For the sake of simplicity, first, we describe the general attack idea and disregard some technical TLS issues. In Section 9.3, we explain the attack in a real setting. During the authentication procedure, the server generates a random string \(rs\) and sends it in an encrypted form to the client. The malicious implementation on the server's side changes the procedure in such a way that the first \(\lambda\) bits of encrypted \(rs\) will carry covert message \(M\) to the adversary Adv:

1. Generate the TLS bit stream \(S\) to be xor-ed with the plaintext to yield the ciphertext portion corresponding to \(rs\) within the AEAD cipher. 2. Generate a separate ciphertext \(C=\mathsf{Enc}_{K}(M)\) of length \(\lambda\) encrypted with the key \(K\) shared with Adv. 3. If \(rs\) is to have length \(m>\lambda\), then generate a string \(C^{\prime}\) of length \(m-\lambda\) at random. 4. Set \(rs=(C||C^{\prime})\times\mathsf{xor}\,S\). Note that in this way, the TLS traffic will contain \(C\) at a certain position, and Adv will be able to derive \(M=\mathsf{Dec}_{K}(C)\). The rest of WebAuth is executed according to the original specification. The client will obtain the same \(rs\), and that \(rs\) looks random for the client. Note that the adversary does not need to know the content of the TLS payload. It suffices to guess that the TLS traffic encapsulates FIDO2 traffic, and guess the location of \(C\) in the traffic and decrypt it with the key \(K\). In the case of FIDO2 registration, the number of bits to embed the ciphertext is even larger: apart from \(rs\) one can use the random string \(uid\) of length \(4\lambda\). ### Low-Level Details for TLS 1.3 Ciphertext and Base64 url Encoding

According to the programming interface documentation of Web Authentication Protocol ([35], Section 5), the server communicates with the client's browser through a JavaScript Application run on the client's side. The key point is that the objects containing the strings \(rs\) and \(uid\) are encoded as base64 url strings. The problem to solve is how to encode the ciphertext \(C\) for the adversary Adv in an innocent-looking stream ciphertext of the base64 url codes of \(rs\) and \(uid\). The base64 url encoding maps 64 characters to octets. Namely, it maps the following:

* A, B,..., Z to 01000001, 01000010,..., 01011010;
* a, b,..., z to 01100001, 01100010,..., 01111010;
* 0, 1,..., 9 to 00110000, 00110001,..., 00111001;
* and _ to 00101101, 01011111. Note that in this way, only 64 octets out of 256 are utilized as base64 url codes. The encoding creates a challenge for the malicious server: one cannot use the next byte \(b\) of a ciphertext \(C\) and simply set the next byte of the TLS ciphertext to \(b\). Namely, after decryption with the TLS key (already fixed by the TLS handshake), the resulting octet might be invalid as a base64 url code. Moreover, this would occur in 75% cases. The embedding of bits of a ciphertext \(C\) must be based only on what the adversary Adv can see during the TLS transmission. Below, we sketch a method that embeds one bit per base64 url character but with a small error probability. Our method focuses on the least significant bit (lsb) of the base64 url codes. One can check that 0 occurs on the lsb position 31 times, while 1 occurs there 33 times. (And for no position of base64 url codes is there a perfect balance between the numbers of zeroes and ones.) Let \(B_{0}\) denote the set of base64 url codes with the least significant bit equal to 0, and let \(B_{1}\) be the set of the remaining base64 url codes.