Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

Nick Frymann Daniel Gardham Franziskus Kiefer [email protected] [email protected] [email protected] Surrey Centre for Cyber Security Surrey Centre for Cyber Security Wire Swiss GmbH University of Surrey University of Surrey Berlin, Germany Guildford, UK Guildford, UK Emil Lundberg Mark Manulis Dain Nilsson [email protected] [email protected] [email protected] Yubico AB Surrey Centre for Cyber Security Yubico AB Stockholm, Sweden University of Surrey Stockholm, Sweden Guildford, UK ABSTRACT 1 INTRODUCTION WebAuthn, forming part of FIDO2, is a W3C standard for strong In recent years, the desire to move away from -based authentication, which employs digital signatures to authenticate authentication on the web has become more pronounced due to web users whilst preserving their privacy. Owned by users, WebAu- the amount of damage caused to individuals, organisations, and thn generate attested and unlinkable public-key industry through attacks, compromised web servers, bad credentials for each to authenticate users. Since the password choices, frequent password reuse, and poor password loss of authenticators prevents users from accessing web services, management [11]. usable recovery solutions preserving the original WebAuthn design Popular web-based federated identity and single-sign on pro- choices and security objectives are urgently needed. tocols, such as SAML [9] and OIDC [33], partly mitigate against We examine Yubico’s recent proposal for recovering from the some of these problems by using a trusted identity provider to loss of a WebAuthn by using a secondary backup help authenticate users on behalf of other web services (relying authenticator. We analyse the cryptographic core of their proposal parties). These solutions improve usability by reducing the need by modelling a new primitive, called Asynchronous Remote Key for password management as users may use their existing online Generation (ARKG), which allows some primary authenticator to accounts, with Google and Facebook, for example, to authentic- generate unlinkable public keys for which the backup authenticator ate to countless web services. Despite this, they still represent a may later recover corresponding private keys. Both processes occur single point of attack and failure, with their security depending on asynchronously without the need for authenticators to export or the underlying mechanism through which the identity provider share secrets, adhering to WebAuthn’s attestation requirements. We authenticates users. prove that Yubico’s proposal achieves our ARKG security properties The need to end reliance on as the only authentication under the discrete logarithm and PRF-ODH assumptions in the factor, driven by new regulations such as the Payment Services random oracle model. To prove that recovered private keys can Directive 2 (PSD2) [2], led to the rise of two-factor authentication be used securely by other cryptographic schemes, such as digital (2FA). Many 2FA solutions employ one-time passcodes (OTPs), such signatures or encryption schemes, we model compositional security as HOTP [27] and TOTP [28], which are sent to users over out-of- of ARKG using composable games by Brzuska et al. (ACM CCS 2011), band channels, email or SMS for instance, or generated locally, extended to the case of arbitrary public-key protocols. either in software (e.g., Google Authenticator) or hardware (e.g., As well as being more general, our results show that private keys RSA SecurID, YubiKey). However, as well as being less usable and generated by ARKG may be used securely to produce unforgeable convenient [16], OTP-based solutions have also been shown to be signatures for challenge-response protocols, as used in WebAuthn. susceptible to various types of attacks [12, 26] and account providers We conclude our analysis by discussing concrete instantiations often rely on static and predictable security questions for account behind Yubico’s ARKG protocol, its integration with the WebAuthn recovery as the fallback authentication method [32]. standard, performance, and usability aspects. Stronger 2FA and multi-factor authentication (MFA) methods for web authentication using public key have started to emerge in recent years—rooted in specifications from the FIDO CCS CONCEPTS Alliance1, consisting of major web technology vendors and organ- • Security and privacy → Key management; Multi-factor au- isations. Their FIDO U2F () [34] specification thentication; Pseudonymity, anonymity and untraceability. was designed to extend the widely-used password-over-TLS ap- proach with signature-based challenge-response authentication as a second factor. The signing keys for each web service are typically KEYWORDS WebAuthn; web authentication; key generation; composability 1https://fidoalliance.org/ 1 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

6 returning the public key, signed challenge, and attestation to the 4 Relying Party Server browser . The browser returns these to the client-side application, which sends it back to the server 5 . The server verifies these and 1 5 stores the new public key.

RP’s JavaScript Application For authentication, the RP sends a challenge in the authentication request to the client-side application 1 , which relays the request WebAuthn API through the browser to the authenticator 2 . The authenticator Browser signs the challenge 3 and returns it to the browser 4 . The browser 2 4 returns this to the client-side application which sends it back to the server 5 . The server verifies the data and grants access 6 . Authenticator Steps 2 and 4 are defined by the CTAP specification, whereas 3 the others are defined by the WebAuthn standard. The WebAuthn API is used to facilitate communication between the browser—and Figure 1: WebAuthn components and message flow for regis- the authenticator by extension—and the RP’s JavaScript application. tration and authentication [3]. The following aspects of WebAuthn’s design are particularly important for security and privacy: the unlinkability of registered public keys and authenticator attestations: stored on some physical device, an authenticator, owned by the Non-correlateable and unlinkable keys. To guarantee user pri- user who can unlock their use for signature generation through vacy, WebAuthn requires that all public key credentials output by some simple action or gesture, such as pressing a button. The FIDO the same authenticator remain unlinkable such that no RP can de- UAF (Universal Authentication Framework) [23] specification was termine whether they were created by a single authenticator. This designed to remove reliance on passwords and protect the unlocking property prevents malicious RPs from correlating users between of signing keys with other factors, typically biometric. These early their systems without additional information such as a wilfully FIDO specifications have evolved into the2 W3C Web Authentic- reused username or email address [3, §14.2]. ation (WebAuthn) standard [3] for interaction between the user’s client (e.g., a ) and web server. WebAuthn, recently Attestation. WebAuthn authenticators are equipped with attest- endorsed by the World Economic Forum [37], specifies an abstract ation keys and certificates to provide assurance about their proven- authenticator model—of which the most well-known implementa- ance. By signing new public keys with its attestation private key tion is the FIDO Client-to-Authenticator Protocol (CTAP) [1]. CTAP and supplying its attestation certificate to the RP, the authenticator includes two protocols: CTAP1 for U2F authenticators and CTAP2 can prove its make and model and provide assurance about, for for WebAuthn authenticators, offering a passwordless experience. example, how strongly it protects generated private keys. Attest- WebAuthn and CTAP2 are known together as FIDO2. ation can further help the RP to establish trust in the client-side verification of additional authentication factors (e.g., biometrics) 1.1 WebAuthn overview and key properties in CTAP2 authenticators. These capabilities are required for high- 3,4 In WebAuthn, the user authenticates to a relying party (RP) us- security certification levels of the authenticators. To preserve ing an authenticator, which manages the user’s keys and employs privacy, WebAuthn describes a set of mechanisms that can be used asymmetric cryptography to prove their possession. WebAuthn is for attestation. FIDO UAF [23], for example, mandates that attest- a decentralised web authentication mechanism since no third party ation keys are used for at least 100,000 authenticator devices. As is required for a user to register with and authenticate to an RP, discussed in the standard [3, §14.4.1], using ECDAA [22] is another and there is no central location to store user information. option for privacy-preserving attestation. The authenticator creates a unique private-public key pair for Internal and remote key storage. WebAuthn authenticators may each RP and supplies the RP with the generated public key. The have an internal symmetric wrapping key. Upon registration, for authenticator may be integrated in a or laptop with a each generated key pair, the authenticator can use this key to en- secure element, or may exist as a separate hardware token, com- crypt the private key and include its ciphertext in the credential that municating with the user’s device using CTAP over a USB, NFC, or is sent to and stored by the RP, instead of storing the private key Bluetooth connection. Most of today’s authenticators implement locally. During authentication, the RP returns this credential as part CTAP1/U2F to strengthen conventional passwords, whilst newer of its challenge, allowing the authenticator to decrypt the private authenticators implement CTAP2 and may perform client-side veri- key. This allows for secure management of WebAuthn private keys fication of a PIN or biometric input. without consuming storage space on the authenticator. As shown in Fig. 1, WebAuthn adopts a similar message flow for the registration and authentication procedures. During registration, 1.2 Authenticator loss the server sends user information and a challenge to the client-side A problem that remains unresolved in WebAuthn, and is currently JavaScript application 1 , which is relayed to the authenticator by under discussion within the W3C working group [17], is how a the browser 2 . The authenticator generates a new private-public key pair, signs the challenge, and generates attestation data 3 , 3https://fidoalliance.org/certification/authenticator-certification-levels/ 4https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator- 2https://www.w3.org/ security-requirements-v1.3-fd-20180905.html 2 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn user may securely regain access to an account if an authenticator is 1.3 Contribution lost or damaged, and therefore any private keys managed by it are Our main contribution is a modular analysis of the cryptographic also lost. A recent study by Lyastani et al. [25] showed that losing core behind Yubico’s proposal [24] for recovering access to online authenticators is one of the biggest fears affecting the adoption of accounts after losing WebAuthn authenticators. As a first step, we WebAuthn by users. Although a user may register multiple authen- explain the protocols from the proposal by modelling them as a ticators for each RP and use one as a backup in case another is lost, new cryptographic primitive, Asynchronous Remote Key Genera- this currently requires that the backup authenticator be present at tion (ARKG), capturing the core properties behind remote genera- the time of its registration. Since users need to keep the backup tion and registration of public keys and later recovery of private authenticator on hand, they risk losing it as well—which defeats keys. We define ARKG security under various trust assumptions on the purpose of having the backup authenticator. Registering mul- the involved parties. We then view Yubico’s protocol as an instance tiple authenticators also requires additional user interaction and of our general ARKG scheme for which we prove security under generally cannot be expected from the user. the discrete logarithm and PRF-ODH assumptions. As a second step, we model composition of ARKG with arbitrary 1.2.1 Challenges. The attestation and unlinkability properties of asymmetric protocols to establish sufficient conditions under which WebAuthn impose some design restrictions on solutions for regain- the keys can be used securely. We repurpose the framework of com- ing account access. Further restrictions apply for a solution to be posed games by Brzuska et al. [8] to handle the case of asymmetric widely interoperable and implementable by resource-constrained ARKG keys and public-key protocols. We prove that the general authenticators. ARKG scheme can be composed with all public-key protocols which Attestation restricts how keys may be shared. It should not be rely on the DL assumption and use keys with matching distribu- possible to circumvent an RP’s attestation policy by registering one tion. Taking into account the adopted instances of cryptographic authenticator and then transferring private key material to a differ- algorithms in Yubico’s proposal, our analysis implies that recovered ent authenticator. Transferring keys between similar authenticators private keys can be securely used in WebAuthn’s signature-based (e.g., same brand or series) may be acceptable in some cases, but challenge-response protocol. We note that our model for ARKG and interoperability would likely suffer since resource-constrained au- its composability with asymmetric protocols might be of independ- thenticators cannot feasibly verify attestation signatures for more ent interest, applied not only to authentication but also public-key than a few kinds of authenticator. encryption. As part of an extended discussion, we address the imple- Unlinkability restricts how keys may be generated. In particu- mentation, efficiency, integration, and usability aspects of Yubico’s lar, different keys must be used for each new account at eachRP. proposal. This means, for example, that one cannot simply generate a static backup public key to be included in each new registration since the Organisation. Section 2 explains Yubico’s proposal and highlights user could then be tracked using that static public key. Additionally, its cryptographic core. The ARKG primitive is modelled in Section 3. resource-constrained authenticators typically rely on remote key Section 4 presents a generalised ARKG scheme and proves its se- storage and have limited internal storage space. For example, gen- curity. ARKG composability with arbitrary asymmetric protocols, erating large numbers of key pairs in advance is not feasible, since based on composed games, is modelled and proven in Section 5. this would require large amounts of storage locally or introduce The extended discussion is provided in Section 6 and other related dependency on a remote third party. work is addressed in Section 7. We conclude in Section 8.

1.2.2 Yubico’s proposal. A recent proposal by Lundberg and Nils- 2 YUBICO’S PROPOSAL FOR WEBAUTHN son [24] from Yubico, a FIDO Alliance member and a global vendor ACCOUNT RECOVERY of hardware authenticators known as YubiKeys, aims to address Here we describe Yubico’s proposal [24], which allows users to these challenges. Their approach assumes that, in addition to a securely regain access to an account after losing an authenticator. primary authenticator that is used on a regular basis for WebAuthn registration and authentication, the user has a backup authentic- ator. After an initial setup procedure, the primary authenticator 2.1 Overview can start registering unlinkable public keys with RPs on behalf of We focus on the cryptographic core which involves three parties: the backup authenticator, in addition to its own public keys. If the the primary authenticator (PA), backup authenticator (BA), and primary authenticator is lost, the backup authenticator, following WebAuthn relying party (RP). In a nutshell, PA remotely generates interaction with an RP, can recover the private key to access the and registers a fresh public key 푃 at some RP for which BA may account at the RP. An important property of Yubico’s proposal is recover the corresponding private key 푝 at a later time to regain that registration of public keys by the primary authenticator and re- access to the account. Crucially, PA and BA do not share any secrets, covery of private keys by the backup authenticator does not require the registration of 푃 does not require interaction with BA, and any interaction between the authenticators after setting them up, recovery of 푝 does not require the presence of PA. nor any transfer or sharing of secrets, thus respecting restrictions Yubico’s specification can be split into three main stages, de- on attestation. Although the proposal specifies the protocols and scribed in the following (see also Fig. 2), whilst adopting the ori- their integration with WebAuthn, it remains unclear whether it ginal notations: LEFT(푎,푏) returns the first 푏 bytes of byte array 푎 meets the security and privacy objectives for use in WebAuthn due and DROP_RIGHT(푎,푏) returns the byte array 푎 without the last to the lack of analysis. 푏 bytes. Elliptic curve operations are performed on the NIST P-256 3 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson curve [29], generated by 퐺 with order 푛. ECDH [10] is used along preserve WebAuthn user privacy by ensuring that registered public with key derivation functions KDF1 and KDF2, based on HKDF keys 푃 and key handles 퐸 remain unlinkable—that is, no RP can [21], and MAC, based on HMAC [14]. Instantiations are discussed decide whether they were registered for the same or different BAs. further in Section 6.1. In our analysis, we use the setup stage, along with both proced- 3 MODELLING ASYNCHRONOUS REMOTE ures specified in Fig. 2, as part of a new cryptographic primitive KEY GENERATION which we call Asynchronous Remote Key Generation (ARKG) and In this section, we model the general Asynchronous Remote Key model in Section 3. By proving compositional security of ARKG with Generation (ARKG) protocol and define its security and privacy arbitrary public-key protocols in Section 5, we implicitly show that properties. As discussed in Section 2, we use ARKG as a new prim- it is safe to use the key pair (푝, 푃) established through the above itive for the modular analysis of Yubico’s proposal by considering stages with the standard WebAuthn signature-based challenge- public key registration by PA and private key recovery by BA sep- response authentication protocol. arately from this key pair’s usage in the authentication procedure, Setup. BA generates a private-public key pair (푠, 푆) and transfers for which we adopt a compositional approach in Section 5. its public key 푆 to PA. This 푆 will be used by PA to derive new public keys on BA’s behalf, whilst the private key 푠 will be stored 3.1 Syntax of ARKG by BA and used for account recovery purposes. In our analysis, ARKG functionality. ARKG allows arbitrary public keys pk′ to we assume that this phase is trusted as it is performed locally by be derived from an original pk, with corresponding sk′ being cal- the owner of both authenticators. Therefore, it does not involve culated at a later time—requiring private key sk for the key pair interaction with the relying party and as such it is outside the scope (sk, pk) and credential cred. of WebAuthn. In Section 6, we discuss implementing the transfer of 푆 in a possible CTAP extension. Definition 3.1 (ARKG). The remote key generation and recovery scheme ARKG B (Setup, KGen, DerivePK, DeriveSK, Check) con- Registration. When registering with RP, identified by rpId, PA sists of the following algorithms: registers its own public key as in the WebAuthn standard, but also • Setup(1휆) generates and outputs public parameters pp = generates a key handle 퐸, derives a public key 푃 using 퐸 and 푆, ((G,푔, 푞), MAC, KDF1, KDF2) of the scheme for the security and sends cred (containing 퐸) to RP as shown in Fig. 2a. PA will parameter 휆 ∈ N. ( ) generate an independent pair 푃, cred for each BA with which it • KGen(pp), on input pp, computes and returns a private- has completed the setup stage and send this to RP. public key pair (sk, pk). Recovery. At a later time, BA can request cred from RP and use • DerivePK(pp, pk, aux) probabilistically returns a new public ′ ′ 푠 to derive 푝 (Fig. 2b). The user provides an identifier for their key pk together with the link cred between pk and pk , for account at RP, which can then retrieve all cred associated with the inputs pp, pk and auxiliary data aux. The input aux is the account. BA processes all received cred—if it finds a cred that always required but may be empty. was registered on its behalf, it may then use the generated 푝 to • DeriveSK(pp, sk, cred), computes and outputs either the new ′ ′ authenticate with RP, which holds 푃, to regain access to the account private key sk , corresponding to the public key pk using using the WebAuthn authentication procedure as normal. cred, or ⊥ on error. • Check(pp, sk′, pk′), on input (sk′, pk′), returns 1 if (sk′, pk′) 2.2 Intuitive security and privacy goals forms a valid private-public key pair, where sk′ is the cor- pk′ We now motivate the desirable security and privacy goals for Yu- responding private key to public key , otherwise 0. bico’s proposal, preparing for our formal analysis in later sections. Correctness. An ARKG scheme is correct if, ∀휆 ∈ N, pp ← ( 휆) [ ( ′ ′) = ] = Security goals. Intuitively, the scheme needs to ensure that no Setup 1 , the probability Pr Check pp, sk , pk 1 1 if adversary can gain access to the user’s account without knowledge (sk, pk) ← KGen(pp); of BA’s private key 푠, since multiple public keys 푃 for BA may be ′ (pk , cred) ← DerivePK(pp, pk, ·); registered by PA on its behalf at different RPs. Consequently, the ′ secrecy of recovered keys 푝 must be guaranteed for all 푃 registered sk ← DeriveSK(pp, sk, cred). by PA before its loss. An adversary with access to PA may learn its internal secrets and try to use them to break secrecy of the keys 3.2 Security definitions registered earlier. In general, we assume that, during the registration For an ARKG scheme we define two properties: the secrecy ofa phase, any RP can be compromised and the attacker may learn derived private key and its initial private key, and the unlinkability public keys 푃 and key handles 퐸 in cred as registered by PA. An of derived public keys to an initial public key. adversary may further compromise an RP during the recovery phase Adversaries and oracles. An adversary A, used in our security and use either these honestly generated keys, or maliciously modify experiments, is modelled as a probabilistic polynomial time (PPT) them when interacting with BA, to obtain information that would algorithm and is allowed to call any of the public procedures defined allow it to gain backup access to user accounts with other RPs. in Section 3.1 with the parameters to which it is given access. The Privacy goals. In addition to the security against impersonation adversary A may make a polynomial number of queries to the attacks on BA and secrecy of recovered keys 푝, the proposal should following oracles: 4 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

Register 1 : PA(푆) RP(rpId) rpId 2 :

3 : (푒, 퐸) ←$ KGen

4 : 푘cred ← KDF1 (ECDH(푒, 푆))

5 : 푘mac ← KDF2 (ECDH(푒, 푆)) 6 : if 푘cred ≥ order of P256 then goto 3

7 : 푃 ← (푘cred · 퐺) + 푆 8 : if 푃 = 0 then goto 3

9 : cred ← 퐸 ∥LEFT(MAC(푘mac, 퐸 ∥rpId), 16) 푃, cred 10 :

11 : store 푃, cred

(a) Registration of backup credentials.

Recover 1 : BA(푠) RP(rpId) 2 : retrieve cred cred, rpId 3 :

4 : 퐸 ← DROP_RIGHT(cred, 16) 5 : if 퐸 = 0 then abort

6 : 푘cred ← KDF1 (ECDH(푠, 퐸))

7 : 푘mac ← KDF2 (ECDH(푠, 퐸)) 8 : if cred ≠ 퐸 ∥LEFT(MAC(푘mac, 퐸 ∥rpId), 16) then abort

9 : 푝 ← 푘cred + 푠 mod 푛

(b) Key recovery using backup authenticator.

Figure 2: Yubico’s protocols for registration/recovery of WebAuthn backup credentials [24].

• Derived public key oracle Opk′ (pk, ·): Opk′ is parameterised We consider four variants of private-key security, modelled using ks ( ) ks ∈ {mwKS hwKS msKS with public key pk. This oracle returns the result of calling the experiment ExpARKG,A 휆 in Fig. 3 with , , , DerivePK(pp, pk, aux) on input aux. It records the resulting hsKS}. ′ ′ ( ) ← ∪ ( ) ′ pk , cred in PKList: PKList PKList pk , cred . PKList Adversary A is always given access to Opk and must find a is initialised as PKList ← Ø. (sk★, pk★, cred★) triple for a provided pk. 푏 푏 • O ′ (푏, sk , pk ) O ′ Challenge oracle pk 0 0 : pk is parameterised The malicious (m) and honest (h) variants result from the omis- with a bit 푏 and fixed key pair (sk0, pk0), and takes no inputs. sion or presence of the PKList check on line 8, respectively, which When called, the oracle either returns (sk′, pk′) derived us- ensures that the triple is for an honestly-generated pk (modelled ing the initial pk0, when 푏 = 0, or a freshly-generated key using Opk′ ) if present. The weak (w) and strong (s) variants depend pair sampled from a distribution D, when 푏 = 1. on whether A has access to the private key derivation oracle Osk′ . • O ′ (sk, ·) cred (·, cred) ′ ★ Private key oracle sk : on input , where If A has access to Osk , trivially querying it with cred is prevented ∈ PKList, Osk′ outputs the result of DeriveSK(pp, sk, cred) through the SKList check on line 7. and updates SKList ← SKList ∪ cred. SKList is initialised as SKList ← Ø. If (·, cred) ∉ PKList, the oracle aborts, other- wise it returns sk′ without giving access to sk. Definition 3.2 (SK-security). An ARKG scheme provides private- key security with ks ∈ {mwKS, hwKS, msKS, hsKS} if the following advantage is negligible in 휆:

SK-security. The private-key security property ensures that for an initial public key pk, an adversary A cannot derive a valid key h i ★ ★ ★ ks ( ) ks ( ) pair (sk , pk ) along with corresponding cred (see Section 2.2). AdvARKG,A 휆 B Pr ExpARKG,A 휆 = 1 5 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

ks ( ) ExpARKG,A 휆 Definition 3.3 (PK-unlinkability). An ARKG scheme provides PK- 휆 1 : pp ← Setup(1 ) unlinkability if the following advantage is negligible in 휆: 2 : (sk, pk) ← KGen(pp) pku h pku i 1 ★ ★ ★ Opk′, Osk′ Adv (휆) B Pr Exp (휆) = 1 − 3 : (sk , pk , cred ) ← A (pp, pk) ARKG,A ARKG,A 2 ′ ★ 4 : sk ← DeriveSK(pp, sk, cred ) ★ ★ ? Remark 2. Definition 3.3 provided here is designed to allow secure 5 return Check(sk , pk ) = : 1 composability with asymmetric protocols, however we also capture ′ ★ ? 6 : ∧ Check(sk , pk ) = 1 a weaker useful property that any two derived public keys cannot ★ 7 : ∧ cred ∉ SKList be linked, which gives the name for this property. As a result, any ★ ★ RP that stores derived public keys cannot link any two of them to a 8 : ∧ (pk , cred ) ∈ PKList common PA, even with knowledge of the derived secret key—which pku ( ) would most likely not be the case for real-world applications. This can ExpARKG,A 휆 휆 be seen by arguing that if no derived key pair can be distinguished 1 : pp ← Setup(1 ) from a random sample from a distribution D, then neither can any 2 : (sk0, pk0) ← KGen(pp) two derived key pairs that are distributed with respect to D. 3 : 푏 ←$ {0, 1} O푏 ′ pk′ 4 AN ARKG SCHEME FOR DL-BASED KEYS 4 : 푏 ← A (pp, pk0) ? ′ 5 : return 푏 = 푏 We present a general ARKG construction in a cyclic group G of order 푞 based on DL keys (sk, pk) = (푥,푔푥 ) for a generator 푔 ∈ G Figure 3: Security experiments for ARKG. The presence or and 푥 ∈ Z푞. Note that we use multiplicative notation for group omission of boxes results in the four variants of the ks ∈ operations. In addition we require the following building blocks. {mwKS, hwKS, msKS, hsKS} experiment. Presence of the dashed Pseudorandom Function (PRF) . boxes gives the strong variants of ks (msKS and hsKS), the [15] A pseudorandom function PRF(푘,푚) takes high-entropy key 푘 and message 푚 and produces presence of the dotted box gives the honest variants (hwKS an output that is, for a PPT adversary A, indistinguishable from a and hsKS), and the omission of all boxes gives mwKS. uniformly-sampled bitstring of the same length. A has access to oracle OPRF (·) which cannot be queried with 푚 and returns either PRF(푘, ·) or 푓 (·), with 푓 being a truly random function. It is easy to see that msKS ⇒ mwKS ⇒ hwKS and msKS ⇒ hsKS ⇒ hwKS msKS hwKS Key Derivation Function (KDF) [18]. A key generation function , making the strongest and the weakest SK-security ′ properties. KDF(푘, 푙) takes source key 푘 and label 푙 and returns a new key 푘 . KDF It is secure if the advantage AdvA (휆) is negligible in 휆 for a PPT Remark 1. An even stronger ks flavour can be defined by drop- adversary A to distinguish derived keys from uniformly-sampled ping the (·, cred) ∉ PKList restriction in the Osk′ oracle of msKS. We bitstrings of the same length. In this paper we consider KDF1 (푘) = mention this here for completeness as such property would be too KDF(푘, 푙1) and KDF2 (푘) = KDF(푘, 푙2), where KDF1 : G → Z푞, ∗ strong for the envisioned use of ARKG in practice, as it would allow KDF2 : G → {0, 1} and 푙1, 푙2 are fixed labels. the attacker to query the user’s BA on arbitrary inputs, bypassing security mechanisms of WebAuthn. This property is not satisfied by Message Authentication Code (MAC) [4]. A message authentica- Yubico’s proposal. tion code MAC = (KGen, Tag, Verify) consists of three algorithms. 휆 휆 KGen(1 ) outputs secret key mk ←$ {0, 1} for security parameter PK-unlinkability. This property ensures that derived key pairs 휆. Tag(mk,푚) outputs tag 휇 for input key mk and message 푚, and cannot be distinguished from a sample of a distribution D and Verify(mk,푚, 휇) outputs 1 if 휇 is valid for 푚 under mk, otherwise 0. also prevents an adversary from linking a derived public key to a MAC satisfies its correctness property iff, ∀(mk,푚), Verify(mk,푚, MAC long-term public key. This models the required unlinkable privacy Tag(mk,푚)) = 1. MAC is unforgeable if the advantage AdvA (휆) goal of WebAuthn, given in Section 2.2. is negligible in 휆 for a PPT adversary A to find, without mk, a valid ★ ★ The unlinkability between public keys pk and derived public tag 휇 for a new message 푚 . A is given access to oracle OTag (·), ′ pku ( ) ≠ ★ ( ) keys pk is defined using ExpARKG,A 휆 . The game chooses a bit which on input message 푚 푚 returns the result of Tag mk,푚 . 푏 ∈ {0, 1} and generates a key pair (sk0, pk0). A is given access 푏 푏 O ′ pp pk O ′ to oracle pk , public parameters , and 0. When called, pk 4.1 The ARKG scheme ′ ′ returns a derived key pair (sk , pk ), which is derived from pk0 if The algorithms of our ARKG scheme for DL-based keys are specified 푏 = 0, otherwise, for 푏 = 1, it samples and returns key pair (sk′, pk′) in Fig. 4. Note that DerivePK generates an ephemeral key pair (푒, 퐸), ′ according to a distribution D. It is able to corrupt any derived key, which is used to derive pk using KDF1, which gives the credential for which corresponding sk′ is output. The adversary A wins the key ck. Integrity checking is provided by MAC for cred. DeriveSK 푏 ′ game if it is able to determine whether O ′ is instantiated with may compute sk using 퐸, recorded in cred, using the property pk 푒 푠 푏 = 0 or 푏 = 1. that 푆 = 퐸 for key pairs (푠, 푆) and (푒, 퐸). This also ensures the correctness property of the scheme holds. 6 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

( 휆) Setup 1 nnPRF-ODH ExpA (휆) return pp = ((G,푔, 푞), MAC, KDF1, KDF2) 1 : 푢, 푣 ←$ Z푞 푢 푣 KGen(pp) 2 : pp ← (G,푔,푔 ,푔 ) ∗ 3 : pick challenge label 푥 ∈ {0, 1} 푥 ←$ Z푞 ← ( 푢푣 ) return (sk, pk) = (푥,푔푥 ) 4 : 푦0 PRF 푔 , 푥 휆 5 : 푦1 ←$ {0, 1} ′ ′ Check(pp, sk = 푥, pk = 푋) 6 : 푏 ←$ {0, 1} 푥 ? ′ OODH return 푔 = 푋 7 : 푏 ← A (pp, 푦푏, 푥) ? ′ 8 : return 푏 = 푏 DerivePK(pp, pk = 푆, aux) 1 : (푒, 퐸) ← KGen(pp) OODH (·) where (·) = (푆, 푥ˆ) 푒 푣 2 : ck ← KDF1 (푆 ) 1 : if 푆 ∉ G ∨ (푆, 푥ˆ) = (푔 , 푥) then 푦 ← ⊥ 푒 푢 3 : mk ← KDF2 (푆 ) 2 : else 푦 ← PRF(푆 , 푥) ck 4 : 푃 ← 푔 · 푆 3 : return 푦 5 : 휇 ← MAC(mk, (퐸, aux)) ′ Figure 5: The lrPRF-ODH security experiment and its OODH 6 : return pk = 푃, cred = (퐸, aux, 휇) oracle. nnPRF-ODH is given by the exclusion of the dashed box and snPRF-ODH by its inclusion. DeriveSK(pp, sk = 푠, (퐸, aux, 휇)) 푠 1 : ck ← KDF1 (퐸 ) 푠 2 : mk ← KDF2 (퐸 ) and snPRF-ODH is implied by the hardness of the Strong Diffie- 3 : if 휇 = MAC(mk, (퐸, aux)) then Hellman assumption [31] (also known as the Gap Diffie-Hellman ′ assumption) and a random oracle, whereas nnPRF-ODH is implied 4 : return sk = ck + 푠 mod 푞 from DDH and existence of a pseudorandom function. This latter 5 : else return ⊥ reduction is given in the standard model.

Figure 4: Algorithms of the ARKG scheme. Theorem 4.1. The ARKG scheme satisfies PK-unlinkability given the nnPRF-ODH and DL assumptions hold in G.

4.2 Security analysis G pku ( ) Proof. 0 is defined exactly by ExpARKG,A 휆 . Thus In this section we define the hardness assumptions and prove se- h i h i G푏 = = pku ( ) = curity of the proposed ARKG scheme. Pr 0 1 Pr ExpARKG,A 휆 1 Discrete logarithm (DL) assumption. For a cyclic group G of order We immediately begin by combining, when the challenge bit b 푞 and a generator 푔 ∈ G, the discrete logarithm is hard if there exists is set to 0, the secret key derivation performed by the DeriveSK al- no polynomial time adversary that, when given 푋 ←$ G, is able to gorithm with DerivePK performed by the oracle. This is a semantic compute 푥 ∈ Z such that 푋 = 푔푥 . change and hence there is no loss of advantage to the adversary as the outputs of the oracle are indistinguishable. We now define a The lrPRF-ODH assumption [6]. We require several intractability H푏 H푏 G H푏 H푏 series of hybrid games 푖 such that 0 B 0 and 푖 as 푖−1 but assumptions introduced by Brendel et al. [6], with the generic form 푏 with the exception that, in the 푖th oracle call to O ′ , computation written as lrPRF-ODH. Its instances have successfully been used to pk ck 푝 analyse security of the Extended Access Control (EAC) [5] and the of 푃 is replaced with ‘푝 ←$ Z푞, 푃 ←$ 푔 푖 푔 ’. Note that 푝 is now TLS 1.3 [6] protocols. We will use two variants of this assumption. returned as sk′. The adversary is unable to distinguish between ∈ 푏 푏 푏 Let G be a cyclic group of order 푞 with generator 푔 G. Let H푖 and H − as the random sample of ck푖 in H − ensures the ∗ ∗ 푖 1 푖 1 PRF : G × {0, 1} → {0, 1} be a pseudorandom function that on distribution of (푝푖, 푃푖 ) is uniformly random in both games, giving ∗ ∗ input a key 퐾 ∈ G and a label 푋 ∈ {0, 1} outputs 푦 ∈ {0, 1} . h i h i Hˆ 푏 = = Hˆ 푏 = For the complete range of variants given in [6], the adversary Pr 푘 1 Pr 푘−1 1 O has access to left and right ODH oracles. The number of queries Next, we continue by defining another series of hybrid games is bound by the values for 푙 and 푟, where the possible values are H˜ 푏 where H˜ 푏 B G . Game H˜ 푏 is defined to be game H˜ 푏 , 푛 = none, 푠 = single and 푚 = many. We only need to consider snPRF- 푗 0 1 푗 푗−1 with the exception that the execution of DerivePK in the 푗th or- ODH, which allows a single call to one oracle, and nnPRF-ODH, acle call is altered when the challenge bit is set to 0. We replace where the adversary cannot make any calls. In our description of the ′ 푢 ‘휇 ← MAC(mk푗 , (퐸, aux))’ with ‘휇 ← MAC(mk푗 , (퐸, aux))’, where oracle, we omit the element 푈 = 푔 as input since it is implicit from ′ the game. The PRF-ODH assumption holds if the advantage of the mk푗 is a uniformly sampled MAC key independent from mk푗 . The H˜ 푏 H˜ 푏 adversary in Fig. 5 is negligible. As proven by Brendel et al. [6], the adversary is able to distinguish between the games 푗 and 푗−1 hardness of the snPRF-ODH implies the hardness of nnPRF-ODH, if it is able to forge the MAC key mk푗 , where mk푗 is the MAC key 7 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

˜ 푏 from H푗 . We show that the adversary’s ability to do this is bounded 5 COMPOSITION OF ARKG WITH GENERIC by the nnPRF-ODH property of KDF2. PUBLIC KEY PROTOCOLS B The adversary , against the nnPRF-ODH game, plays the role As a next step in our analysis, we model and prove composition of H˜ 푏 A of challenger in 푗 for . It invokes its own game, receiving the general ARKG scheme with arbitrary public key protocols using G, 푔, 푆 ← 푔푠 , and the nnPRF-ODH challenge (퐸 = 푔푒,푦★), and the framework of composed games from Brzuska et al. [8], which sets the challenge label 푥 as the label for KDF2. It wins its own has been used to prove composition of key exchange protocols with ˜ 푏 game if it can decide whether 푏 = 0 or 푏 = 1. B invokes H푗 and symmetric key protocols [7, 13]. In this work, we reuse and adopt 푏 their general modelling techniques to the case of asymmetric key sets pk0 ← 푆, sk0 ← ⊥. It answers the 푗th oracle query to O ′ pk pairs generated by ARKG and generic public key protocols. We will honestly except it sets pk = 퐸, sk = ⊥, and mk ← 푦★, which is 1 1 푗 푗 model their composition by means of a composed protocol whose ˜ 푏 the output of KDF2 in game H푗 . It then waits for A to output a security is defined via a composed game, in which an adversary is bit 푏. It forwards 푏 as the answer to its own nnPRF-ODH game and challenged to mount a successful attack against the generic pro- ˜ 푏 wins with probability equal to that of A distinguishing H푗 from tocol 훱 that uses keys generated by ARKG. Note that the goal of ˜ 푏 this adversary is to break security of the higher-level protocol 훱 H − . Thus, we have 푗 1 and not of the ARKG scheme. Intuitively, this is because the com- h i h i ˜ 푏 ˜ 푏 nnPRF-ODH posed protocol ARKG; 훱 adopts the functionality of the higher-level Pr H푗 = 1 − Pr H푗−1 = 1 ⩽ Adv 푖 (휆) KDF2,B protocol and thus also adopts its security requirements. Our composition result proves that any key pair (sk′, pk′) gen- We define G푏 H˜ 푏 , where 푞 is the number of queries made 2 B 푞표 표 erated by ARKG can be used in any public-key protocol that is O푏 to the pk′ oracle. Next, we define a third series of hybrid games compatible with the structure of ARKG keys, i.e., DL-based keys Hˆ 푏 Hˆ 푏 G푏 Hˆ 푏 Hˆ 푏 generated by our ARKG scheme in Section 4. 푘 where 0 B 2 . Game 푘 is defined to be game 푘−1, with the exception that the execution of DerivePK in the 푘th oracle call 푒 is altered. We replace ‘ck ← KDF1 (푆 )’ with ‘ck ←$ {0, 1}’. The Hˆ 푏 Hˆ 푏 5.1 Modelling ARKG composition advantage of the adversary distinguishing 푘 from 푘−1 is also bound by the nnPRF-ODH in an argument almost identical to that Recall that ARKG is defined as ARKG B (SetupARKG, KGenARKG, H˜ 푏 Hˆ 푏 DerivePK, DeriveSK, Check) of 푗 and 푗−1. It is omitted here for brevity. Thus we have and, for any generic public-key pro- tocol, we have the key generation phase and the protocol phase, h i h i Pr Hˆ 푏 = 1 − Pr Hˆ 푏 = 1 ⩽ AdvnnPRF-ODH (휆) henceforth written as 훱 B (KGen훱 , 훴훱 ). We consider a combined 푘 푘−1 KDF푖 ,B 1 protocol ARKG; 훱 B (KGenARKG;훱 , 훴ARKG;훱 ), defined in Fig. 6. Since the composed protocol 훴 generates the long-term user keys We define G푏 B Hˆ 푏 and analyse the advantage of A in distin- ARKG;훱 3 푞표 KGen KGen 훱 guishing between 푏 = 0 and 푏 = 1. Since the game is independent for the ARKG protocol we set ARKG;훱 B ARKG. If also Setup of 푏, and the distributions of (푝, 푃) are identical, it follows that has a setup phase, we denote this by 훱 . Security for the com- posed protocol is defined by the security of 훱 with respect to a h i 1 game Exp (휆). We denote the security game for the composed pro- Pr G푏 = 1 = 훱 3 ( ) 2 tocol as ExpARKG;훱 휆 . As this game depends on the properties of Thus the advantage of A is bounded by 훱, we define a behaviour that describes an adversary’s interaction with the composed game. pku   Adv (휆) ⩽ 푞 · AdvnnPRF-ODH (휆) + AdvnnPRF-ODH (휆) Exp (휆) is constructed from queries and states from both ARKG,A 표 KDF1,B KDF2,B ARKG;훱 ARKG and 훱 and the behaviour allows us to describe certain oracle By assumption that KDF1 and KDF2 are nnPRF-ODH secure, the calls explicitly, whilst allowing any protocol-specific queries to be ( ) advantage of their adversaries is negligible and hence the advantage generically handled by Exp훱 휆 . Furthermore, it restricts sharing of the adversary against PK-unlinkability is also negligible. □ state information between ARKG and 훱 to only necessary informa- ( ) tion, as given by Exp훱 휆 , to ensure the adversary does not trivially Next, we analyse all flavours of SK-security showing that its ma- win its game. We allow the adversary A to interact with multiple, licious variants (mwKS, msKS) can be reduced to the aforementioned simultaneous, and distinct executions of the composed protocol snPRF-ODH assumption [6] (requiring the random oracle model), where some may be running the ARKG algorithm as well. Note that whereas its honest variants (hwKS, hsKS) can be reduced directly to A wins if it breaks the security property of 훱 only and that the A ( ) ( ) the DL assumption in the standard model. advantage of against ExpARKG;훱 휆 is given by AdvARKG;훱,A 휆 . In order to enable interaction between the two protocols, Brzuska Theorem 4.2. The ARKG construction is: et al. [8] define a set of generic states to store variables specific to (1) msKS-secure given the snPRF-ODH assumption holds in G. the security game, as well as values used in the execution of the (2) mwKS-secure given the snPRF-ODH assumption holds in G. protocol. Although the authors propose composition with symmet- (3) hsKS-secure given the DL assumption holds in G. ric protocols, the generic nature behind their modelling of states (4) hwKS-secure given the DL assumption holds in G. lends itself to the composition with public-key protocols, for which we can define general experiments. We use the following internal Proof. All proofs for Theorem 4.2 are given in Appendix A. □ states: 8 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

• Local Session Identifier (LSID). The set of all local session SetupARKG;훱 (휆) 2 identifiers of the form (푖, 푗) ∈ Z , where 푖 and 푗 are polyno- 1 : pp1 ← SetupARKG (휆) mial in 휆 and represent the number of main authenticators 2 : pp2 ← Setup훱 (휆) and derived public keys (i.e., BAs), respectively. 3 : return pp = (pp1, pp2) • Session State (SST). For a given lsid ∈ LSID, SST(lsid) gives the session state for that local session. It includes protocol 훴ARKG;훱 (SSTARKG;훱 (lsid), msg) specific information and will include user information such ′ ′ 1 : Parse SSTARKG;훱 (lsid) as (pk , sk , sk, cred) as derived keys and the corresponding long-term keys from ′ ′ 2 : 훾 ← check(sk , pk ) which they were derived. We also allow additional informa- tion to be stored in an auxiliary variable, aux. The game may 3 : if 훾 ≠ accept then ′ ′ ′ access the session state as SST(lsid).(sk, pk, sk , pk , aux). 4 : sk ← ARKG(sk, cred) ′ • Local Session State (LST). LST(lsid) returns the local state 5 : if sk = ⊥ then abort ′ ′ for lsid, which includes game-relevant variables. We store 6 SST (lsid).sk ← sk ′ : ARKG;훱 a boolean 훿 that records whether a pk is corrupt, that is if ′ 7 : return (SST , 훴 (sk ,푚)) the adversary has knowledge of its corresponding sk′. ARKG;훱 훱 • Execution Session State (EST). EST contains global informa- Figure 6: Algorithms of the composed protocol. tion for the execution of the protocol, i.e., it does not depend on local session identifiers. In our composed game, this will hold long-term keys of users stored as EST(푖).(sk, pk). of an adversary against any restrictions made by the game, for ex- • Model Session State (MST). The model state is used to store ample, in our composed protocol, we capture the scenario where an non-session-specific game-relevant information, such as the adversary submits an Oexecute query on behalf of a user without a challenge bit in an indistinguishability game. In the com- defined key, that is, sk = ⊥ or the message msg is empty. The valid- posed game, we do not define MST as it will depend on the ity predicate returns false and the query is aborted. The Ocorrupt ( ) ′ ′ security game Exp훱 휆 . oracle checks that pk exists and that pk does not already have an existing derived secret key, otherwise it aborts. The composed game must keep track of all states for ARKG and 훱. The session state function for the composed game is simply given Setup phase. This phase initialises the execution and game vari- ( ) by the union of the ARKG and 훱 session states, thus SSTARKG;훱 B ables for the composed game ExpARKG;훱 휆 , which are handled by SSTARKG ∪ SST훱 , and the local state of the composed game is sim- the two setup algorithms, SetupG and SetupE, respectively. For the ilarly defined to be both local session states of the composed pro- generic protocol, SetupE sets all values to be undefined, as they tocols, LSTARKG;훱 B LSTARKG ∪ LST훱 . For the execution session are set during interaction with the adversary. SetupG initialises state, we have ESTARKG;훱 = ESTARKG as the execution state for the the model and local session states for the game G훱 , which, due composing protocol is always undefined because the game execu- to the generality of the model, is unknown and therefore not spe- tion state depends on the protocol 훱, which is not defined here. We cified here. The setup phase for the composed protocol consists of also have MSTARKG;훱 = MST훱 since the security game is only with running all setup algorithms for ARKG and 훱 as shown in Fig. 6. respect to 훱 and hence the model state for the key recovery is also not defined. The adversary interacts with the composed protocol 5.2 Analysis of ARKG composition via a behaviour 휒ARKG;훱 , described in Fig. 7, which answers queries In this section, we show that our ARKG scheme can replace the for oracles related to this phase of the protocol, otherwise forward- KGen algorithm for any secure public-key protocol that uses DL- ing the query to the protocol phase and relaying the reply to A. based keys. Our main composability result is stated in Theorem 5.1. The behaviour separates states to limit protocol-specific variables, Intuitively, one might expect that secure composition holds un- allowing only derived key pairs to be passed from ARKG to 훱. der the assumption that it is hard to recover a private key cor- We consider two relevant oracles, Ocorrupt, which upon input of a responding to a public key, as captured by SK-security properties derived public key returns the corresponding derived secret key, from Section 3.2. However, there is a nuance to what Theorem 5.1 and Oexecute, which runs the protocol for ARKG keys. Any other claims. It says that composing our ARKG with any compatible protocol-specific oracle would not need special treatment and thus asymmetric protocol is at least as secure as the unmodified protocol is forwarded to the game for 훱. itself, given the hardness assumptions hold. Theorem 5.1 makes no claims over the security of the protocol itself. It is the security Winning predicate. The state of the adversary is evaluated by a of the protocol 훱 that is reduced to key secrecy of its key genera- predicate P that encodes the winning condition for the game. For tion algorithm, and hence we show that, given that the hardness the composed protocol, the winning condition is precisely that of assumptions hold, ARKG offers key secrecy such that it maybe the generic protocol’s game G훱 . composed with all asymmetric protocols that require secrecy of their DL-based private keys. We have shown in Section 4 that key Validity predicates. Evaluations on the input of each oracle call secrecy for ARKG, modelled via different SK-security flavours, can are achieved by corresponding validity predicates. If true is re- be achieved under different assumptions from the PRF-ODH family. turned, the oracle answers the query, otherwise the query is abor- To achieve our result, we require that public keys generated by ted. Validity predicates are used to capture the correct behaviour ARKG remain indistinguishable from randomly sampled keys 푑 9 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

휒ARKG;훱 (query, (LSID, (SSTARKG, SST훱 ), (LSTARKG, LST훱 ), ESTARKG, MST훱 )) 1 : if query = corrupt then

2 : Parse query into Ocorrupt (lsid) ′ ′ 3 : ((SSTARKG, LSTARKG, ESTARKG, ⊥), response) ← corrupt(lsid, (LSID, SSTARKG, LSTARKG, ESTARKG)) ′ ′ ′ 4 : SST훱 ← SST훱 , LST훱 ← LST훱 , MST훱 ← MST훱 ′ ′ ′ ′ 5 : return ((SSTARKG;훱 , LSTARKG;훱 , ESTARKG, MST훱 ), response) 6 : if query = execute then

7 : Parse query into Oexecute (lsid, msg) ′ 8 : SSTARKG;훱 ← SSTARKG;훱 ′ 9 : (SSTARKG;훱 (lsid), response) ← 훴ARKG;훱 (SSTARKG;훱 (lsid), msg) ′ 10 : return ((SSTARKG;훱 , LSTARKG;훱 , ESTARKG, MST훱 ), response) 11 : else ′ ′ ′ 12 : ((SST훱 , LST훱 , ⊥, MST훱 ), response) ← 휒훱 (query, (LSID, SST훱 , LST훱 , ⊥, MST훱 ), msg) ′ ′ ′ 13 : SSTARKG ← SSTARKG, LSTARKG ← LSTARKG, ESTARKG ← ESTARKG ′ ′ ′ ′ 14 : return ((SSTARKG;훱 , LSTARKG;훱 , ESTARKG, MST훱 ), response)

Figure 7: Behaviour for the composed protocol.

D 푞표 ,D ( ) of the same distribution . This property is implied by the PK- Lemma 2 shows that the success probability against ExpARKG;훱 휆 unlinkability property of ARKG from Section 3.2. In order to use is bound by the advantage of B against the security of 훱 with re- it in our proof, we first ensure notational compatibility of PK- ( ) ( ) spect to Exp훱,B 휆 . As 훱 is secure with respect to Exp훱,B 휆 , then unlinkability with the framework of composed games and the gen- ARKG ( ) ; 훱 is secure with respect to ExpARKG;훱,B 휆 . □ eric public-key protocol by rewriting it using the notions of states and predicates as defined by Brzuska et al. [8], which we present Remark 3. In Theorem 5.1, generic protocol 훱 may rely on further in Appendix B. hardness assumptions to satisfy its own security properties. In WebAu- Theorem 5.1. For an ARKG that provides PK-unlinkability and thn, 훱 is a challenge-response protocol with DL-based signature keys. outputs keys with distribution D, let 훱 be a secure protocol with re- For our ARKG, the DL property of its keys is implied by any vari- ( ) D ant of SK-security (from Theorem 4.2). We would only require the spect to Exp훱 휆 . If the KGen of 훱 outputs keys푑 with distribution , then the composition ARKG; 훱 is secure with respect to Exp (휆). additional snPRF-ODH assumption in cases that allow for a stronger ARKG;훱 adversary. Proof. The adversary interacts with the game GARKG;훱 via be- Lemma 1. For an ARKG that provides PK-unlinkability and outputs haviour 휒ARKG , defined in Fig. 7. Oracle descriptions are given in ;훱 D Appendix C. keys with respect to the distribution , and a protocol 훱 that uses D = To prove the theorem, we begin by using Remark 2 to swap long- DL-based keys with distribution , we have, for all 휅 1, . . . , 푞표 and any PPT adversary A: term public keys of backup authenticators from pk푖 to pk0, which ( ) 휅,푑 휅−1,푑 pku means restricting LSID entries to be of the form 0, 푗 . The strategy G G 푞표 Exp (휆) Adv ARKG;훱 (휆) − Adv ARKG;훱 (휆) ⩽ · Adv ARKG,A (휆) is to define a set of hybrid games where each key is replaced with ARKG,A ARKG,A 푝 ARKG,A pk0 in turn. The advantage of a distinguishing adversary is bound by the success probability of an adversary against PK-unlinkability Lemma 2. For an ARKG that provides PK-unlinkability, let 훱 be and, as the detail is almost identical to the proof of Theorem 4.1, is a DL-based protocol whose keys have distribution D. For any PPT omitted here. adversary A, we have Next, we define a set of hybrid games where we replace the 푞 ,퐷 G 표 Exp (휆) ARKG;훱 ( ) 훱 ( ) output of ARKG with a randomly-sampled key pair 푑 also from AdvARKG,A 휆 ⩽ Adv훱,B 휆 휅,D distribution D. We define a game G by the game GARKG;훱 , ARKG;훱 The proofs for Lemmas 1 and 2 may be found in Appendix A. but where the first 휅 sessions generate derived keys from a random This composability result shows that, for any generic protocol sample of the distribution D for use in the protocol 훱 along with that uses DL keys, we can instead use the keys generated by ARKG the addition of a variable 휅★, initially set to 0. The behaviour of D securely provided that the nnPRF-ODH assumption holds in G. The G휅, , given by 휒★ , is defined as 휒 except upon an ARKG;훱 ARKG;훱 ARKG;훱 security of a signature scheme is reduced to the DL structure of its O O execute query, where instead it performs executeA as described in key pairs, and thus we require ARKG to offer some flavour of SK- G0,D = G Appendix C. Note that Lemma 1 gives us ARKG;훱 ARKG;훱 , thus security for use in WebAuthn. Our composition modelling supports we have up to the strongest notion, msKS, as it can handle corruption queries G0,푑 G푞표 ,푑 2 pku ( ) ARKG;훱 ARKG;훱 푞표 ExpARKG,A 휆 of honest parties, which is what our msKS property captures for Adv (휆) − Adv (휆) ⩽ · Adv (휆) ARKG;훱,A ARKG;훱,A 푝 ARKG,B ARKG and is required in typical unforgeability games. As shown 10 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn in Section 4, this is achieved under the snPRF-ODH assumption in Table 1: Impact of ARKG on WebAuthn operation run times, the random oracle model. given in milliseconds per operation for 10,000 invocations for a software implementation. 6 EXTENDED DISCUSSION We discuss how Yubico’s proposal [24] instantiates our ARKG Registration Authentication scheme and can be integrated with the WebAuthn standard. We Scheme № of BAs Mean Max Mean Max address the attestation requirements, performance, and usability. WebAuthn only 0 2.1 3.9 1.1 1.4 6.1 Yubico’s ARKG instance WebAuthn with 1 5.3 8.2 2.2 4.2 Instead of generic building blocks from Section 4, Yubico’s proposal ARKG 5 18.0 23.0 6.4 9.6 uses standards-based cryptographic algorithms. 10 34.0 41.0 12.0 15.0 For compatibility with WebAuthn [3], all operations in G are based on Elliptic Curve Cryptography (ECC) [10] on the P-256 curve and the ECDSA standard [29] is used as a signature algorithm. The standards-based HKDF [21] is used with SHA-256 [14] to allow RP to reject 푃 on creation, before PA is lost. If the attestation instantiate the KDF functions, which offers the necessary PRF-ODH metadata 퐴 is maliciously modified, it may cause a false-positive security [8, 19]. In DerivePK, only the 푥-coordinate of ECDH(푒, 푆), rejection of 푃 but cannot bypass RP’s attestation policy. where 푒 is the private key of the ephemeral key pair (푒, 퐸) and 푆 This metadata consists of the 128-bit authenticator attestation is the public key of the backup authenticator, is used as input to GUID (aaguid). The same aaguid may be shared between authen- HKDF−Extract. HKDF−Expand uses HKDF−Extract’s 256-bit pseu- ticator models with the same firmware or capabilities. An attesta- dorandom key output and two separate fixed “info” arguments, and tion certificate chain is also provided, using X.509 certificates. Note returns 푘cred and 푘mac as 256 bits of keying material per invocation. that the attestation data are not unique to an authenticator. DeriveSK uses the same instantiations as DerivePK. HMAC-SHA-256 [20] is used to instantiate MAC. The auxiliary 6.2.3 CTAP. The setup stage of ARKG would not form part of the input aux to the DerivePK algorithm is defined as the SHA-256 hash WebAuthn extension, instead falling under CTAP’s remit as this of the RP’s identifier rpId, which becomes part of the credential is a procedure involving two authenticators and no RPs. Yubico’s cred. proposal specifies the required extensions to CTAP in order to setup an authenticator so that it may generate and register keys on behalf 6.2 Integration with WebAuthn of other authenticators. It proposes a method to transfer this seed 6.2.1 WebAuthn’s extensions interface. Yubico’s ARKG instance key 푆 to a PA using an intermediate host device, the client. The can be integrated with WebAuthn using the existing extensions CTAP extension [24], which applies to the operations authenticators interface [3, §9]. In particular, the generate action can invoke can perform with clients, adds the exportSeed and importSeed DerivePK on PA, which generates a credential for BA and signs it operations. Using a client supporting this CTAP extension, the user with the PA’s private key. The recover action can invoke DeriveSK first exports 푆 from BA and then imports it into PA, most likely on BA when recovering access to an account at some RP. According over USB. to the proposal [24], this integration would not require any changes to WebAuthn. 6.3 Performance evaluation 6.2.2 Attestation requirements. Yubico’s proposal respects WebAu- ARKG as specified in Section 4, is extremely efficient: DerivePK thn’s attestation framework by using the backup key pair (푝, 푃) as uses three exponentiations, one group operation, and two KDF a single-use key used by BA to authenticate registration of a new calls, and DeriveSK uses one exponentiation, and two KDF calls. In key pair to replace PA’s key pair. BA can then provide attestation practice, some further optimisations can be performed to further as usual for this new key. reduce the computation. In the setup stage, BA transfers 푆 to PA together with some attest- Each WebAuthn registration procedure requires one key genera- ation metadata 퐴. During registration, PA generates and registers tion and one signing operation and each authentication procedure its own authentication key pair (푘, 퐾). It also derives a public key 푃 requires one signing operation. Assuming only P-256 keys are used, from 푆, uses 푘 to sign (푃, 퐴) and includes (퐾, 푃, 퐴) and the signature these are dominated by two P-256 exponentiations and one expo- in the registration. When BA later derives the private key 푝, it also nentiation, respectively. We thus estimate the WebAuthn registra- creates a new key pair (푘 ′, 퐾 ′) as it would for a normal registration. tion procedure, with execution of DerivePK, to take approximately It signs 퐾 ′ using both 푝 and its attestation key, stores 푘 ′, discards 150 % longer per backup public key 푆 associated with PA and au- 푝, and registers 퐾 ′ as a replacement for 퐾 and 푃. The RP can now thentication, with execution of DeriveSK, to take approximately verify BA’s attestation per its usual attestation policy. 100 % longer per cred for which BA must process before finding a This creates a signature chain from PA’s key 퐾, via the single- matching MAC. use backup key 푃, to BA’s new key 퐾 ′. Note that at the time 푃 is Table 1 shows run times for the standard WebAuthn operations registered, the attestation metadata 퐴 is not signed by BA. The RP’s and those using ARKG to generate private and public keys, meas- attestation policy is enforced when BA creates (푘 ′, 퐾 ′). However, ured on a single-threaded Python implementation, published to- since this is assumed to happen after PA is lost, 퐴 is provided to gether with [24], on an AMD Ryzen 7 3700X processor. 11 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

The WebAuthn-only results use abstracted WebAuthn - loss problem since it assumes that the user still has access to the tions: registration generates a P-256 key pair and an ECDSA sig- authenticator to be replaced. nature; authentication only generates a signature. Registration for Takakuwa [35] proposes two protocols for solving the authen- WebAuthn with ARKG requires PA to generate a P-256 key pair, ticator loss problem: Preemptively Synced Keys (PSK) and Online run DerivePK for each BA’s 푆, and generate a signature for its key Recovery Storage (ORS). PSK does not require a third party as the pair. Authentication for WebAuthn with ARKG requires BA to run backup device instead generates a number of key pairs and transfers DeriveSK for all received cred until one returns successfully, then public keys to the primary authenticator. ORS requires the storage generate a signature with the derived private key. Since one PA of recovery information for every registration at a third party and may be associated with several BAs, and a user may have more connectivity during registration and recovery procedures. Both than one BA, run times are presented for one, five, and ten BAs. For protocols have caveats that make them impractical for resource- these measurements, the successful cred is always found last. constrained authenticators: PSK requires large amounts of storage The results in Table 1 show that using ARKG to generate public space for preemptively generated keys, and ORS requires that the and private key pairs for WebAuthn, for the expected case of an authenticator can connect to the internet. average user having one BA for a PA, gives an increase in compu- tation time over standard WebAuthn for registration and recovery 8 CONCLUSION of 152 % and 100 %, respectively. We proved security of Yubico’s recent proposal [24] for account For comparison, the average run time for standard WebAuthn recovery in WebAuthn. To model the cryptographic core of Yu- authentication with a P-256 key on a YubiKey 5 token, was measured bico’s proposal, we presented a new cryptographic primitive, called to be 94 ms over 1,000 invocations, including USB communication ARKG, which allows for asynchronous and remote generation of overheads. Registration could not be measured since it is dominated public keys, for which private keys may be derived later by the by a mandatory physical user gesture. owner of the key pair. Yubico’s proposal instantiates ARKG with DL-based keys and enables primary authenticators to remotely 6.4 Usability generate and register public keys for a backup authenticator. Our Combining ARKG with WebAuthn would allow PA to register keys analysis proves that Yubico’s ARKG can be securely composed for BAs on behalf of the user without requiring BAs to be present— with public-key protocols, such as WebAuthn’s signature-based this means users do not need to carry their BAs with them when challenge-response protocol, assuming the hardness of the DL and registering to web services. PRF-ODH assumptions in the random oracle model. This requires users to have performed the setup procedure be- We discussed the integration of ARKG with WebAuthn and the forehand for the transfer of 푆. Additionally, mobile devices may usability aspects of such an integration, as well as the concrete be able to add support for this as many are suitable as both au- instantiations recommended in the proposal. Our experimental res- thenticator devices, thanks to their secure elements, and clients ults show that performance overhead of ARKG for a single backup for additional external authenticators. The proposal also discusses authenticator, when combined with WebAuthn, increases the run the user experience for registering backup credentials and account time of the registration and authentication/recovery procedures by recovery, including the messages that will be shown and the ac- 152 % and 100 %, respectively. tions an RP should perform. For example, the proposal recommends Finally, by decoupling ARKG into a separate, yet composable that RPs explicitly inform users of registered recovery credentials building block, our modelling technique prepares ground for further and that clients should display details about the authenticators instantiations and utilisation of the scheme. Of particular interest for which it may register keys. Overall, the core usability benefit is a post-quantum secure instance of ARKG for the time when of the proposal is that users do not need to manage their backup WebAuthn begins adoption of new quantum-safe cryptographic authenticators manually by having them present and registering standards. Another interesting research objective is to utilise ARKG them by hand when creating accounts. to allow users to delegate access to their WebAuthn accounts to other users. 7 OTHER RELATED WORK Finally, we mention several other approaches that have been pro- ACKNOWLEDGMENTS posed for the recovery of WebAuthn accounts. Nishimura et al. [30] Researchers from the Surrey Centre for Cyber Security were sup- propose identity-based key sharing in the context of WebAuthn ported by the UK’s National Cyber Security Centre. using a third party to mediate the sharing of keys amongst devices. The third party authenticates the user at each device to ensure keys REFERENCES are not shared to other users. [1] FIDO Alliance. 2018. Client to Authenticator Protocol (CTAP). Technical Takakuwa et al. discuss the issue of replacing authenticators [36], Report. https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to- presenting a protocol for the transfer of account details from one authenticator-protocol-v2.0-id-20180227.html [2] European Banking Authority. 2018. Payment services and electronic money. Tech- authenticator to another over an assumed secure channel. The nical Report. https://eba.europa.eu/regulation-and-policy/payment-services- primary application of this protocol is to allow users to transfer and-electronic-money authenticator data from an old device to a new one, so that they [3] Dirk Balfanz, Alexei Czeskis, Jeff Hodges, J.C. Jones, Michael B. Jones, Akshay Kumar, Angelo Liao, Rolf Lindemann, and Emil Lundberg. 2019. Web Authen- need not re-register with the new device for online accounts. Al- tication: An API for accessing Public Key Credentials Level 1. Technical Report. though a related problem, this is not applicable to the authenticator https://www.w3.org/TR/webauthn 12 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

[4] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. 1996. Keying Hash Functions [30] Hideo Nishimura, Yoshihiko Omori, Takao Yamashita, and Satoru Furukawa. for Message Authentication. In Advances in Cryptology – CRYPTO ’96. Springer 2018. Secure authentication key sharing between mobile devices based on owner Berlin Heidelberg, 1–15. https://doi.org/10.1007/3-540-68697-5_1 identity. In 2018 Fourth International Conference on Mobile and Secure Services [5] Jacqueline Brendel and Marc Fischlin. 2017. Zero Round-Trip Time for the (MobiSecServ). IEEE. https://doi.org/10.1109/mobisecserv.2018.8311436 Extended Access Control Protocol. In Computer Security – ESORICS 2017. Springer [31] Tatsuaki Okamoto and David Pointcheval. 2001. The Gap-Problems: A New International Publishing, 297–314. https://doi.org/10.1007/978-3-319-66402-6_18 Class of Problems for the Security of Cryptographic Schemes. In Public Key [6] Jacqueline Brendel, Marc Fischlin, Felix Günther, and Christian Janson. 2017. Cryptography, Kwangjo Kim (Ed.). PRF-ODH: Relations, Instantiations, and Impossibility Results. In Advances in [32] Ariel Rabkin. 2008. Personal knowledge questions for fallback authentication. Cryptology – CRYPTO 2017. Springer International Publishing, 651–681. https: In Proceedings of the 4th symposium on Usable privacy and security - SOUPS ’08. //doi.org/10.1007/978-3-319-63697-9_22 ACM Press. https://doi.org/10.1145/1408664.1408667 [7] C. Brzuska, M. Fischlin, N. P. Smart, B. Warinschi, and S. C. Williams. 2013. Less [33] N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, and C. Mortimore. 2014. OpenID is More: Relaxed yet Composable Security Notions for Key Exchange. Int. J. Inf. Connect 1.0. Technical Report. https://openid.net/connect/ Secur. (2013). https://doi.org/10.1007/s10207-013-0192-y [34] Sampath Srinivas, Dirk Balfanz, and Eric Tiffany. 2014. Universal 2nd Factor (U2F) [8] Christina Brzuska, Marc Fischlin, Bogdan Warinschi, and Stephen C. Williams. Overview. Technical Report. https://fidoalliance.org/specs/fido-u2f-v1.0-ps- 2011. Composability of Bellare-Rogaway Key Exchange Protocols. In Proceedings 20141009/fido-u2f-overview-ps-20141009.html of the 18th ACM Conference on Computer and Communications Security (CCS ’11). [35] Alex Takakuwa. 2019. Moving from Passwords to Authenticators. Ph.D. Disserta- ACM Press, 51–62. https://doi.org/10.1145/2046707.2046716 tion. http://hdl.handle.net/1773/44147 [9] Scott Cantor, John Kemp, Rob Philpott, and Eve Maler. 2005. Assertions and Pro- [36] Alex Takakuwa, Tadayoshi Kohno, and Alexei Czeskis. 2017. The Transfer Access tocols for the OASIS Security Assertion Markup Language (SAML) V2.0. Technical Protocol—Moving to New Authenticators in the FIDO Ecosystem. Technical Report. Report. https://www.oasis-open.org/standards#samlv2.0 http://dada.cs.washington.edu/research/tr/2017/06/UW-CSE-17-06-01.pdf [10] Certicom Research. 2009. SEC 1: Elliptic Curve Cryptography. Technical Report. [37] World Economic Forum. 2020. Passwordless Authentication: The next breakthrough http://www.secg.org/sec1-v2.pdf in secure digital transformation. Technical Report. http://www3.weforum.org/ [11] Dipankar Dasgupta, Arunava Roy, and Abhijit Nag. 2017. Multi-Factor Authen- docs/WEF_Passwordless_Authentication.pdf tication. In Infosys Science Foundation Series. Springer International Publishing, 185–233. https://doi.org/10.1007/978-3-319-58808-7_5 [12] Alexandra Dmitrienko, Christopher Liebchen, Christian Rossow, and Ahmad- A ADDITIONAL SECURITY PROOFS Reza Sadeghi. 2014. On the (In)Security of Mobile Two-Factor Authentication. In Financial Cryptography and Data Security. Springer Berlin Heidelberg, 365–383. Here we present the additional proofs from Section 4.2 and Sec- https://doi.org/10.1007/978-3-662-45472-5_24 tion 5.2. [13] Benjamin Dowling, Marc Fischlin, Felix Günther, and Douglas Stebila. 2015. A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications A.1 Proof of Theorem 4.2 (1) Security (CCS ’15). Association for Computing Machinery. https://doi.org/10. msKS Proof. G0 is defined exactly by the experiment Exp (휆). 1145/2810103.2813653 ARKG,A Thus [14] D. Eastlake and T. Hansen. 2006. US Secure Hash Algorithms (SHA and HMAC- h i SHA). Technical Report. https://doi.org/10.17487/rfc4634 msKS Pr [G0 = 1] = Pr Exp (휆) = 1 [15] Oded Goldreich, Shafi Goldwasser, and Silvio Micali. 1986. How to construct ARKG,A random functions. Journal of the ACM 33, 4 (aug 1986), 792–807. https://doi.org/ Define G1 as G0 with the exception that line 4 of DerivePK is 10.1145/6490.6503 ck 푟 ′ [16] Nancie Gunson, Diarmid Marshall, Hazel Morton, and Mervyn Jack. 2011. User replaced with 푟 ←$ Z푝, 푃 ← 푔 ·푔 during the oracle call Opk . The perceptions of security and usability of single-factor and two-factor authentic- adversary B keeps an internal list List that contains elements of the ation in automated telephone banking. Computers & Security 30, 4 (jun 2011), form (퐸, 푒, 푟). If A queries Osk′ with cred ∋ 퐸 such that 퐸 ∈ List 208–220. https://doi.org/10.1016/j.cose.2010.12.001 ′ [17] Jeff Hodges. 2018. Recovering from Device Loss. https://github.com/w3c/ then it replaces line 4 of DeriveSK run by Osk′ with ‘return sk = webauthn/issues/931 ck + 푟’ where 푟 is obtained from the matching 퐸 entry in List. This [18] Hugo Krawczyk. 2010. Cryptographic Extraction and Key Derivation: The HKDF ′ Scheme. In Advances in Cryptology – CRYPTO 2010. Springer Berlin Heidelberg, ensures that sk output from the oracle still passes Check when 631–648. https://doi.org/10.1007/978-3-642-14623-7_34 called on a corresponding public key obtained from Opk′ . As both 푠 [19] Hugo Krawczyk. 2010. Cryptographic Extraction and Key Derivation: The HKDF and 푟 are uniformly sampled from the same space, the two games Scheme. In Advances in Cryptology – CRYPTO 2010, Tal Rabin (Ed.). Springer Berlin Heidelberg. are indistinguishable. Hence [20] H. Krawczyk, M. Bellare, and R. Canetti. 1997. HMAC: Keyed-Hashing for Message Authentication. Technical Report. https://doi.org/10.17487/rfc2104 Pr [G1 = 1] = Pr [G0 = 1] [21] H. Krawczyk and P. Eronen. 2010. HMAC-based Extract-and-Expand Key Deriva- B tion Function (HKDF). Technical Report. https://doi.org/10.17487/rfc5869 We then construct an adversary for the snPRF-ODH game [22] Rolf Lindemann. 2018. FIDO ECDAA Algorithm. Technical Re- from an adversary that is able to win at G1. That is, break msKS port. https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-ecdaa-algorithm- security of ARKG. v2.0-id-20180227.html [23] Rolf Lindemann, Davit Baghdasaryan, and Eric Tiffany. 2014. FIDO UAF Protocol The adversary B gets the challenge 푆 from its snPRF-ODH game. Specification v1.0. Technical Report. https://fidoalliance.org/specs/fido-uaf-v1.0- It sets up the game as described except it sets sk ← ⊥, pk ← 푆, and ps-20141208/fido-uaf-protocol-v1.0-ps-20141208.html the label of KDF to be the challenge label 푥 from its own game. It [24] Emil Lundberg and Dain Nilsson. 2019. Webauthn recovery extension. https: 1 //github.com/Yubico/webauthn-recovery-extension/ challenges A to create a forgery on 푆 and is able to answer oracle [25] S. Ghorbani Lyastani, M. Schilling, M. Neumayr, M. Backes, and S. Bugiel. 2020. queries honestly. Then, A outputs the tuple (sk★, pk★, cred★), from Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study B of FIDO2 Passwordless Authentication. In 2020 IEEE Symposium on Security and which can create a successful answer to the snPRF-ODH chal- ★ ★ Privacy (SP). IEEE Computer Society, Los Alamitos, CA, USA, 842–859. https: lenge (푔, 푆, 퐸,푦ˆ ). It extracts 퐸 from cred and uses the single 푂퐷퐻 //doi.org/10.1109/SP40000.2020.00047 oracle query in the snPRF-ODH game to get ck = 푦 ← PRF(푔푠푒, 푥). [26] Ariana Mirian, Joe DeBlasio, Stefan Savage, Geoffrey M. Voelker, and Kurt Thomas. 2019. Hack for Hire: Exploring the Emerging Market for Account B can then compute the secret key as 푠 = sk − ck mod 푞. With Hijacking. In WWW 2019. ACM, 1279–1289. knowledge of 푠 it is trivial for B to compute 푦 = PRF(퐸ˆ푠, 푥) and [27] D. M’Raihi, M. Bellare, F. Hoornaert, D. Naccache, and O. Ranen. 2005. HOTP: An make the comparison 푦 =? 푦★. If they are equal, then 푏 = 0, other- HMAC-Based One-Time Password Algorithm. Technical Report. https://doi.org/ 10.17487/rfc4226 wise 푏 = 1. The event that A queries 퐸 = 퐸ˆ (which would cause [28] D. M’Raihi, S. Machani, M. Pei, and J. Rydell. 2011. TOTP: Time-Based One-Time the experiment to abort) happens with probability 푞표 /푝 where 푝 Password Algorithm. Technical Report. https://doi.org/10.17487/rfc6238 [29] National Institute of Standards and Technology. 2013. Digital Signature Standard is the size of G and 푞표 is the number of oracle queries made by A. (DSS). Technical Report. https://doi.org/10.6028/nist.fips.186-4 This probability is negligible as 푝 is large. 13 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

A msKS ( ) B G Thus, the advantage of in ExpARKG,A 휆 is bound by an ad- ARKG. The adversary sets up the game as described in 1, except versary B against the snPRF-ODH assumption, giving that on line 2 it replaces ‘(sk, pk) ← KGen’ with ‘pk ← 푌, sk ← ⊥’, B B 푝 − 푞표 where 푌 is ’s challenge from the DL game. The challenger AdvmsKS (휆) ⩽ · Adv푠푛푃푅퐹−푂퐷퐻 (휆) ARKG,A 푝 G,B chooses one query to the oracle where it guesses A will use the derived pk′ as part of its forgery. For this query, it can answer If the snPRF-ODH assumption is hard in G then ARKG is msKS oracles calls to O ′ using the DL challenge S, and cannot answer secure. □ pk Osk′ queries. In the event this oracle is queried, the experiment B A.2 Proof of Theorem 4.2 (2) aborts. For all other queries, can answer oracle queries made by A as B generates the ephemeral key pair (푒, 퐸) and can extract the G mwKS ( ) Proof. 0 is defined exactly by the experiment ExpARKG,A 휆 . value 푟 from List. Thus B A ′ h i Then, waits for to output a successful forgery sk with [G ] mwKS ( ) ★ ★ Pr 0 = 1 = Pr ExpARKG,A 휆 = 1 credential cred . Using 퐸 from cred , B is able to locate 퐸 in List and find the corresponding 푒. This allows B to recompute ck from We immediately construct an adversary B for the snPRF-ODH 푒 푠 ′ KDF1 (푆 ) and compute an 푠 such that 푔 = 푆 as 푠 = sk −푐푘 mod 푞. game from an adversary that is able to win at G0. That is, break B is guaranteed that 퐸 ∈ List as a successful forgery in the hsKS mwKS security of ARKG. game requires (pk★, cred★) ∈ PKList which can only happen if B The adversary B gets the challenge 푆 from its snPRF-ODH game. generated 퐸 during an oracle call from A. However, the simulation It sets up the game as described except on line 2 where instead it sets ′ fails if A queries Osk′ on pk that embeds the DL challenge, which ‘sk ← ⊥, pk ← 푆’, and sets the label of KDF1 to be the challenge (푞 − )/푞 A label 푥 from its own game. It challenges A to create a forgery on happens with probability 표 1 표 . Thus, the advantage of in ExphsKS (휆) is bound by an adversary B against the discrete 푆 and is able to answer oracle queries honestly. Then, A outputs ARKG,A the tuple (sk★, pk★, cred★), from which B can create a successful logarithm assumption, giving answer to the snPRF-ODH challenge (푔, 푆, 퐸,푦ˆ ★). It extracts 퐸 from 1 hwKS ( ) 퐷퐿 ( ) ★ AdvARKG,A 휆 ⩽ AdvG,B 휆 cred and uses the single 푂퐷퐻 oracle query in the snPRF-ODH 푞표 game to get ck = 푦 ← PRF(푔푠푒, 푥). B can then compute the secret key as 푠 = sk★ − ck. With knowledge of the secret key 푠 it is trivial By assumption, the DL problem is hard in G and thus ARKG is ? hsKS for B to compute 푦 = PRF(퐸ˆ푠, 푥) and make the comparison 푦 = 푦★. secure. □ If they are equal, then 푏 = 0, otherwise 푏 = 1. The event that A queries 퐸 = 퐸ˆ (which would cause the experiment to abort) happens A.4 Proof of Theorem 4.2 (4) / G hwKS ( ) with probability 푞표 푝 where 푝 is the size of G and 푞표 is the number Proof. 0 is defined exactly by the experiment ExpARKG,A 휆 . of oracle queries made by A. This probability is negligible as 푝 is Thus h i large. Pr [G = 1] = Pr ExphwKS (휆) = 1 A msKS ( ) 0 ARKG,A Thus, the advantage of in ExpARKG,A 휆 is bounded by an adversary B against the snPRF-ODH assumption, giving We immediately construct an adversary B for the DL game from G 푝 − 푞표 an adversary that is able to win at 0. That is, break hwKS security AdvmwKS (휆) ⩽ Adv푠푛푃푅퐹−푂퐷퐻 (휆) ARKG,A 푝 G,B of ARKG. The adversary B sets up the game as described in the experiment, except that on line 2 it replaces ‘(sk, pk) ← KGen’ If the snPRF-ODH assumption is hard in G then ARKG is mwKS with ‘pk ← 푌, sk ← ⊥’, where 푌 is B’s challenge from the DL secure. □ game. It can answer oracle queries made by A as B generates the ( ) 푠 푒 A.3 Proof of Theorem 4.2 (3) ephemeral key pair 푒, 퐸 and thus can compute 퐸 as 푆 in lines 1 and 2 of DerivePK, and the rest can be executed without knowledge G hsKS ( ) Proof. 0 is defined exactly by the experiment ExpARKG,A 휆 . of the exponent. Thus In particular, A is unable to do this as it does not have knowledge h i [G ] hsKS ( ) A B ( ) Pr 0 = 1 = Pr ExpARKG,A 휆 = 1 of 푒. When does make an oracle call, stores the key pair 푒, 퐸 in a list List. Then, B waits for A to output a successful forgery Define G1 as G0 with the exception that line 4 of DerivePK is ′ ★ ★ ck 푟 sk with credential cred . Using 퐸 from cred , B is able to locate 퐸 replaced with 푟 ←$ Z , 푃 ← 푔 · 푔 during the oracle call O ′ . If 푝 pk in List and find the corresponding 푒. This allows it to recompute ck A queries Osk′ with cred ∋ 퐸 such that 퐸 ∈ List, then it replaces 푒 푠 ′ ′ from KDF1 (푆 ) and compute an 푠 such that 푔 = 푆 as 푠 = sk − 푐푘 line 4 of DeriveSK executed by O ′ with ‘return sk = ck + 푟’ sk mod 푞. B is guaranteed that 퐸 ∈ List as a successful forgery in the 푟 퐸 List where is obtained from the matching entry in . This ensures hwKS game requires (pk★, cred★) ∈ PKList which can only happen sk′ Check that output from the oracle still passes when called on if B generated 퐸 during an oracle call from A. a corresponding public key obtained from O ′ . As both 푠 and 푟 pk Thus, the advantage of A in ExphwKS (휆) is bounded by an are uniformly sampled from the same space, the two games are ARKG,A adversary B against the DL assumption, giving indistinguishable. Hence AdvhwKS (휆) Adv퐷퐿 (휆) Pr [G1 = 1] = Pr [G0 = 1] ARKG,A ⩽ G,B We then construct an adversary B for the DL game from an By assumption, the DL problem is hard in G and thus ARKG is adversary that is able to win at G1. That is, break hsKS security of hwKS secure. □ 14 Asynchronous Remote Key Generation: An Analysis of Yubico’s Proposal for W3C WebAuthn

B ( ) A.5 Proof of Lemma 1 protocol, then forwards the query to Exp훱 휆 and forwards the A G휅−1,D response to A. If the query is to the ARKG phase of the protocol, Proof. Given an adversary against ARKG;훱 , we construct an adversary B against the PK-unlinkability property of ARKG. To then B uses its internal simulated states, that is SSTARKG, LSTARKG, start, B honestly simulates the 훱 stage of the composition, using ESTARKG, and MSTARKG, to answer A. Since B and G훱 run the same pk algorithms as in the composed game, the simulation is perfect. keys from the PK-unlinkability game Exp (휆). To allow B to ARKG,A Eventually, A will terminate, at which point B also stops. The simulate the 훱 stage, it simulates the lists SST , LST and the 훱 훱 success probability A is lower bound for the success probability of variable 휅★. It also keeps track of corrupt keys by maintaining and B against its game. Thus updating the list LSTARKG. Upon execution, it sets up the game: 푞 ,퐷 G 표 Exp (휆) (SST , EST ) ← SetupE (LSID, ARKG.KGen, 휅) ARKG;훱 ( ) 훱 ( ) 훱 훱 훱 AdvARKG,A 휆 ⩽ Adv훱,B 휆 ( ) ← ( ) LST훱 , MST훱 SetupG훱 LSID, SST훱 , EST훱 , 휅 □ 휅★ ← 0 ∀lsid ∈ LSID, LST (lsid).훿 ← honest 훱 B REWRITING PK-UNLINKABILITY B A The adversary now invokes . It is able to make oracle quer- Here we rewrite the PK-unlinkability property defined in Section 3.2 B O O ies, which answers as described by executeB and corrupt in using the framework from Brzuska et al. [8]. We stress that we Appendix C. capture the same winning conditions for the adversary. The frame- A O The probability that issues a corrupt query against a simu- work allows us to separate the session and game states for PK- 푞 /푝 lated key in the PK-unlinkability game is bounded by 0 . Notice unlinkability from that of a generic protocol, which allows us to that, if the challenge oracle in the PK-unlinkability game returns a address security of their composition. The algorithms and oracles B G휅−1,D real key, then perfectly simulates ARKG,훱 . If a simulated key is are given in Fig. 8. G휅,D A returned, then it perfectly simulates ARKG,훱 . If wins against the We now define the states that formally capture this security composed game, B sends the query Oguess (1), otherwise it sends experiment, but note that we do not make use of the local session Oguess (0). Therefore, the difference in success probability of A state LSTARKG for this security property. Furthermore, for readability, pk provides a lower bound for the success of B against Exp (휆). we omit the subscript for all states in this section, as this only ARKG,A pertains to a property for ARKG, all states have an implicit ARKG That is, we have subscript, i.e., SST = SSTARKG. The setup algorithms are run first to 휅−1,푑 h pk i G Pr Exp 0 (휆) = 0 = Adv ARKG;훱 (휆) set up the experiment. The states, algorithms, oracles and predicates ARKG,A ARKG,A required are: 휅,푑 h pk i G • 1 ( ) = = ARKG;훱 ( ) Game Execution State. The execution state comprises of a Pr ExpARKG,A 휆 1 AdvARKG,A 휆 key pair (sk0, pk0) from which derived keys are computed. Which gives the following bound, where negl is a negligible • Session State. The session state SST is indexed by a local function in the security parameter 휆, session identifier lsid ∈ LSID, which is derived from a user’s pk Exp (휆) h pk i h pk i long-term key and an integer in 1 ⩽ 푖 ⩽ 푛, where 푛 is Adv ARKG,A (휆) = Pr Exp 0 (휆) = 0 − Pr Exp 1 (휆) = 1 ARKG,A ARKG,A ARKG,A the number of derived key pairs per user in the game. In

G휅,푑 G휅−1,푑 this game, there is only one user, namely that with key pair = Adv ARKG;훱 (휆) − Adv ARKG;훱 (휆) negl(휆) ARKG,A ARKG,A ⩽ (sk , pk ). Initially set to undefined, it is populated with a 0 0 key pair (sk′, pk′) when computed by the challenge oracle. □ • Model Session State. The model state MST stores two values ′ A.6 Proof of Lemma 2 (푏,푏 ). The challenge bit 푏 is sampled and set during the start of the game, and 푏′, which is the adversary’s guess at B G Proof. Let be a PPT adversary against 훱 that simulates the 푏, is initially set to undefined and updated by the adversary G푞표,D composed game ARKG;훱 . Since the keys used in the protocol stage before its termination. are independent of those used in the ARKG phase, B can answer • Setup. The algorithm SetupE is used to initialise all long- A’s queries to the ARKG stage using its simulated composed game, term keys for all users. Each session is initialised with the whilst forwarding A’s queries to the protocol stage to G훱 . The correct key pair and all other variables are initially set to be outputs of B to A are distributed exactly as A expects to play undefined. SetupG picks the challenge bit 푏 ∈ {0, 1}. against. • Queries. For PK-unlinkability, we allow the adversary one To construct the simulation, B internally defines and maintains oracle—the challenge oracle. The oracle responds with the ′ ′ SSTARKG, LSTARKG, ESTARKG, and MSTARKG as in the composed game. tuple ((SST, LST, EST, MST), pk , sk ) when queried. That is, To generate these variables, B runs: it updates the appropriate session states and outputs a po- tentially derived key pair (sk′, pk′). (SSTARKG, ESTARKG) ← SetupEARKG (LSID, KGen, 휆) • Predicate. The guess predicate defines the winning condition (LST , MST ) ← SetupG (LSID, SST, EST, 휆) ARKG ARKG ARKG of the adversary. That is, the predicate evaluates the output ′ ? Then, B invokes A, which can query oracles offered by the of the Oguess oracle, where the predicate evaluates 푏 = 푏, composed game. If the query is to the 훱 phase of the composed with equality indicating a win for the adversary. 15 Nick Frymann, Daniel Gardham, Franziskus Kiefer, Emil Lundberg, Mark Manulis, and Dain Nilsson

SetupE(LSID, KGen, 휆) SetupG(LSID, SST, EST) Opk푏′ (LSID, SST, EST, EST, MST, 휆) ′ 1 : EST.(sk0, pk0) ← KGen(휆) 1 : MST.푏 ←$ {0, 1} 1 : SST ← SST ′ ? 2 : for (★) ∈ LSID 2 : MST.푏 ← ⊥ 2 : if MST.푏 = 0 then ′ 3 : SST(pk0, ★) ← (⊥, ⊥) 3 : return (LST, MST) 3 : pk ← DerivePK(EST.pk0) ′ ′ 4 : return (SST, EST) 4 : sk ← DeriveSK(pk , EST.sk0) ′ ′ 5 : else (sk , pk ) ←$ D ′ ′ ′ 6 : SST (lsid).pk ← pk P(LSID, SST, LST, EST, MST) Oguess (SST, LST, EST, MST,푏) ′ ′ ′ 7 SST (lsid).sk ← sk ? ′ ′ ′ ′ : 1 : return MST.푏 = MST.푏 1 : MST ← MST, MST .푏 ← 푏 ′ ′ ′ 8 : return ((SST , LST, EST, MST), pk , sk ) ′ 2 : return (SST, LST, EST, MST )

Figure 8: Algorithms and oracles for remodelling PK-unlinkability in Section 3.2.

OexecuteB (lsid, msg) OexecuteA (lsid, msg) ′ ′ ′ ′ 1 : if LST(lsid).훿 = corrupt then sk ← SST(lsid).sk 1 : if LST(lsid).훿 = corrupt then sk ← SST(lsid).sk ★ ★ 2 : elseif 휅 < 휅 2 : elseif 휅 < 휅 ′ ′ ′ ′ 3 : (sk , pk ) ←$ D 3 : (sk , pk ) ←$ D ′ ′ ′ ′ ′ ′ ′ ′ 4 : SST훱 (lsid).(sk , pk ) ← (sk , pk ) 4 : SSTARKG;훱 (lsid).(sk , pk ) ← (sk , pk ) ★ ★ ★ ★ 5 : 휅 = 휅 + 1 5 : 휅 = 휅 + 1 ★ ★ 6 : elseif 휅 ≥ 휅 6 : elseif 휅 = 휅 ′ ′ 7 ← ( ) 7 ( ) ← O : pk DerivePK pk0 : SSTARKG;훱 lsid .pk pk푏 ′ ′ ′ 8 : sk ← corrupt(pk ) 8 : SSTARKG;훱 (lsid).sk ← ODeriveSK (lsid) ′ ′ ′ ′ ★ ★ 9 : SST훱 (lsid).(sk , pk ) ← (sk , pk ) 9 : 휅 = 휅 + 1 ★ ★ ★ 10 : 휅 = 휅 + 1 10 : elseif 휅 > 휅 ′ ′ ′ ′ 11 : return (휒훱 (sk , pk , msg), (SSTARKG;훱 , MSTARKG;훱 , LSTARKG;훱 , 11 : pk ← DerivePK(LSTARKG;훱 (lsid).pk) ′ 12 : ESTARKG;훱 ) 12 : sk ← corrupt(lsid) ′ ′ ′ ′ 13 : SSTARKG;훱 (lsid).(sk , pk ) ← (sk , pk ) ′ O ( ( )) ★ ★ corrupt lsid, SSTARKG;훱 , MSTARKG;훱 , LSTARKG;훱 , ESTARKG;훱 14 : 휅 = 휅 + 1 ′ 1 : LST (lsid) ← LST ′ ′ 15 : return (휒훱 (sk , pk , msg), SSTARKG;훱 , MSTARKG;훱 , ′ 2 ( ) ← : LST lsid .훿 corrupt 16 : LSTARKG;훱 , ESTARKG;훱 ) ′ ′ ′ 3 : return (LST (lsid).sk , (SSTARKG;훱 , MSTARKG;훱 , LSTARKG;훱 , 4 : ESTARKG;훱 ))

Figure 9: Additional oracles for Theorem 5.1.

C ADDITIONAL ORACLES The OexecuteA oracle is used in the proof of Theorem 5.1 to swap In Fig. 9, we give the additional oracles for the proof of Theorem 5.1. each derived key pair for a random sample of distribution D. It is 휅★ O The Ocorrupt oracle, upon input of a session identifier lsid, executes implicitly indexed by the value of . The executeB oracle is used and returns DeriveSK as sk′ and updates LST(lsid).훿 ← corrupt. It in the proof of Lemma 1. It embeds a PK-unlinkability challenge in 휅★ is used as the Ocorrupt oracle in Theorem 5.1 and in Lemmas 1 and 2. the session . Again, this oracle is also implicitly indexed by the value of 휅★.

16