# FIDO2 Facing Kleptographic Threats By-Design
## 4 Linking Attacks with Discrete Logarithm Signatures
### Attack 2: Identity Sieve via Rejection Sampling Attack prerequisites:
In Section 6, we already demonstrated how to utilize the construction from [44]. ### Ephemeral-Ephemeral DH Protocol

We assume that server \(S\) is aware of the hidden functionality implemented by some authenticators and colludes with them. \(S\) initiates the execution of the covered DH protocol by sending a crafted _uid_ during registration. Fortunately, _uid_ can be long enough (\(\leq 4\lambda\)) to accommodate the DH protocol component \(g^{k_{S}}\). However, _uid_ encodes uniformly distributed bit strings; hence, the kleptographic key agreement must utilize some method hiding the real properties of the content of _uid_. If \(\mathsf{Auth}_{U}\) is not malicious, it will treat _uid_ as a purely random value, unaware of its hidden meaning. #### 8.2.1 Discrete Logarithm Signatures Used for Authentication

Apart from sending \(g^{k_{S}}\) in _uid_, the domain parameters corresponding to \(g^{k_{S}}\) must be somehow agreed upon between the server and the authenticator. For this purpose, the preference list discussed in Section 8.3 can be used. According to [35] (Section 5.3), \"the client makes a best-effort to create the most preferred credential that it can\". Of course, the server chooses the domain parameters that are supported by the malicious authenticators. Thus, the first item on the server's list of preferences is a convenient place to indicate the domain parameters corresponding to \(g^{k_{S}}\). In response, \(\mathsf{Auth}_{U}\) generates signature keys for these domain parameters. Later, when authenticating for the first time to this server, it passes its DH component as the ephemeral key \(g^{k}\) included in the signature. While the described procedure enables the colluding server and authenticator to derive a secret shared key, the question is whether an auditor can detect whether the covert execution of DH protocol is running. Let us examine this issue for signatures based on elliptic curves. In the above procedure, \(g^{k_{S}}\) encoded in _uid always_ belongs to the elliptic curve indicated by the first item on the list of server's preferences. Consequently, the authenticator will use the same curve to generate the keys. Assume for a moment that the \(x\)-coordinate of the elliptic curve point \(g^{k_{S}}\) is encoded with the help of PBRM. As a result, _uid_ will be generated so that it will appear to have a uniform distribution among bit strings of the given length. We must assume that the auditor will nevertheless try different ways of examining _uid_ to check that it does not carry hidden information (such an approach resembles, for example, searching for irregularities in the randomness of generated RSA moduli in the attack [8]). Therefore, the auditor may also try to decode _uid_ in the same way that a malicious authenticator would. Unfortunately, there is a feature that distinguishes our encoding of elliptic curve points from truly random strings: to test if _uid_ may carry the \(x\)-coordinate of a point of a curve, it suffices to substitute the tested value \(x\) into the right-hand side of the equation defining the curve. For random values \(x\), we obtain a quadratic residue on the right-hand side of the equation with probability very close to \(\frac{1}{2}\). However, if the auditor analyzes several user registration processes on the same malicious server, they will detect that for _every_ such registration, the tested \(x\) yields a quadratic residue on the right-hand side (RHS) of the curve's equation. Thus, the above key agreement procedure must be modified to fool the auditor. Since the domain parameters are determined by the signature scheme for which the authenticator generates its ephemeral key \(g^{k}\), the Elligator Squared [34] might be used together with PBRM, that is, the two-stage procedure discussed above might be applied by the server. For 256-bit elliptic curves, the final values \(V\) representing \(g^{k_{S}}\) will still fit into \(4\lambda=512\) bits.