Key Management Based on Ownership of Multiple Authenticators in Public Key Authentication

We define the requirements in such a way that our proposal does not interfere with what public key authentication described in Section 1, which we call PKA, can achieve during public key registration (Rolf Lindemann, 2018; FIDO Alliance, 2021).

First, our proposed method should not rely on trusted third parties for proving the owner of authenticators except for verifying attestations and establishing secure channels. In PKA, users can register public keys via a trusted channel established when registering a new account or established by registered authenticators.

Second, our proposed method must prevent services from correlating their account by using the proof of the owner of authenticators. In PKA, users can register different public keys with each service to protect user privacy against services seeking to correlate their accounts based on registered public keys.

Third, in our proposed method, services should verify the attestation of the public key requested to be registered. Services can calculate the trustworthiness of the public key by verifying the attestation generated by the authenticator that has the corresponding private key.

Finally, our proposed method should minimize the number of times a user operates multiple authenticators at the same time for convenience. Operating multiple authenticators at the same time whenever registering a new public key annoys a user.

We explain our proposal using Fig. 3, which shows a case where a user has two authenticators, A and B. A user registers a new account with service $\alpha$ using Authenticator A at first, and then she accesses the service using Authenticator B. Note that we assume that messages between authenticators and the service have protected in terms of service authentication, confidentiality, and integrity (e.g., via TLS).

The two authenticators agree in advance on the following parameters and the identifier of service $\alpha$ ($sid_{\alpha}$).

• •

  s: The seed value shared among authenticators (\scriptsize1⃝)

• •

  N: The number of authenticators sharing the same seed (equal to the number of her authenticators)

• •

  The public key cryptographic algorithm for an OVK

• •

  KDF: The key derivation function that takes a seed and a random value as inputs and outputs pseudorandom numbers of the length required for an OVSK

• •

  MAC: The message authentication code function that takes an OVSK as a key

First, the user registers a new account with service $\alpha$ using Authenticator A. Authenticator A generates a new key pair ($sk_{A},pk_{A}$) and an attestation of the public key (\scriptsize2⃝ in Fig. 3). At the same time, Authenticator A derives an OVPK and the corresponding metadata and registers them in addition to the public key ($pk_{A}$) with service $\alpha$. The derivation consists of the following three steps.

1. \scriptsize\theenumi⃝

   Generate a random number ($R_{\alpha}$).

2. \scriptsize\theenumi⃝

   Calculate an OVSK ($OVSK_{\alpha}=\mathtt{KDF}(\mathtt{s},R_{\alpha})$) and the corresponding OVPK ($OVPK_{\alpha}$). If the authenticator cannot derive validate OVSK using the random number ($R_{\alpha}$), start over from \scriptsize3⃝.

3. \scriptsize\theenumi⃝

   Register $OVPK_{\alpha}$ and the corresponding metadata consisting the following three values.

   • •

     $R_{\alpha}$: The generated random number

   • •

     $M_{\alpha}$: The message authentication code ($\mathtt{MAC}(OVSK_{\alpha},R_{\alpha}+sid_{\alpha})$)

   • •

     N

Now, the user has registered a new account with service $\alpha$. The service binds the public key ($pk_{A}$), $OVPK_{\alpha}$, and the corresponding metadata ($R_{\alpha},M_{\alpha},N$) to the new account.

Second, the user access service $\alpha$ using unregistered Authenticator B. When the service returns a challenge for public key authentication by replying to an authentication request, it also returns the metadata ($R_{\alpha}$ and $M_{\alpha}$). Authenticator B starts on seamless registration of a new public key because B has no public key for signing in to service $\alpha$. Authenticator B generates a new key pair ($sk_{B},pk_{B}$) and the attestation of the public key (\scriptsize8⃝ in Fig. 3). Authenticator B signs the public key ($pk_{B}$) by $OVSK_{\alpha}$ so that service $\alpha$ verifies whether the owner of Authenticator B storing the corresponding private key ($pk_{B}$) is the same as the owner of registered authenticators. To derive $OVSK_{\alpha}$ from the received metadata, the following two steps are performed.

1. \scriptsize\theenumi⃝

   Derive $OVK_{\alpha}$ using the received metadata $R_{\alpha}$ in the same way as \scriptsize4⃝.

2. \scriptsize\theenumi⃝

   Verify the received metadata $M_{\alpha}$ using the derived $OVSK_{\alpha}$. If this verification failed, the derived OVSK or the received metadata is not for service $\alpha$.

Service $\alpha$ registers the public key ($pk_{B}$) if the attestation (\scriptsize8⃝) and the signature (\scriptsize9⃝) is valid and the number of the registered public keys is not more than N.

Authenticators can derive different OVKs per service because of generating different random numbers (R) per service. Fig. 4 shows a situation where the user registers with Services $\alpha$ and $\beta$. It is impossible to determine the seed value of an OVSK because of the properties of a key derivation function (KDF). By using a different random number for each service ( $R_{\alpha}$ for Service $\alpha$ and $R_{\beta}$ for Service $\beta$), authenticators can register unlinkable OVPKs with different services.

Authenticators only need to remember the value of the seed. This is because authenticators store random numbers R to services in a verifiable format. Moreover, even though the number of registered services increases, a user does not have to operate multiple authenticators to share a new OVSK. This is convenience for a user.

A user operates multiple authenticators and makes them communicate to share a seed. There are various kinds of short-range communication protocols (e.g., Bluetooth, NFC, and generating and reading QR codes), each of which has its different characteristics in the security of the communication channel. We define the following requirement to be independent of specific communication protocols.

• •

  Assuming no security features of communication channels

This requires that attackers cannot calculate a seed using only the information that authenticators send to the channel (resistance to eavesdropping). This also requires that authenticators can validate whether the received information is generated by the legitimate authenticator to be resistant to tampering.

Fig. 5 shows the case where a user has two authenticators. Two authenticators agree on the same seed based on the Diffie-Hellman key agreement algorithm. They encrypt DH public keys using an authenticated encryption based on a password set by the user to ensure the confidentiality of DH public keys and verify the authenticity.

The authenticators agree on the following parameters in advance.

• •

  pw: The password set by the user (\scriptsize1⃝)

• •

  DH: A Diffie-hellman key agreement algorithm

• •

  The list of authenticated encryption algorithms for encrypting DH public keys (Each algorithm has assigned an identifier)

• •

  The list of password-based encryption algortihms (Each algorithm has assigned an identifier)

First, the user operates Authenticator A.

1. \scriptsize\theenumi⃝

   Generate a DH key pair ($SK_{A},PK_{A}$).

2. \scriptsize\theenumi⃝

   Generate a random number called a Content Encryption Key ($CEK_{A}$).

3. \scriptsize\theenumi⃝

   Encrypt the DH public key ($PK_{A}$) using $CEK_{A}$. Authenticator A determines the authenticated encryption algorithm from the list.

4. \scriptsize\theenumi⃝

   Encrypt $CEK_{A}$ using the password (pw). Authenticator A determines the password-based algorithm from the list.

Authenticator A sends the generated ciphertexts and the algorithm identifiers (at \scriptsize4⃝ and \scriptsize5⃝) to Authenticator B.

In the same way, Authenticator B generates a DH key pair ($(SK_{B},PK_{B})$ at \scriptsize6⃝) and a random number ($CEK_{B}$ at \scriptsize7⃝), encrypts the DH public key ($PK_{B}$) using $CEK_{B}$, and encrypts $CEK_{B}$ using the password (pw). Note that $CEK_{B}$ is not necessarily the same as $CEK_{A}$ generated by Authenticator A.

Authenticator A receives the ciphertexts from Authenticator B.

1. \scriptsize\theenumi⃝

   Decrypt a received CEK ($CEK_{B}$) using the password (pw). Authenticator A identifies the password-based algorithm by the received identifier.

2. \scriptsize\theenumi⃝

   Decrypt a received DH public key ($PK_{B}$) using the decrypted CEK ($CEK_{B}$). Authenticator A identifies the authenticated encryption algorithm by the received identifier.

3. \scriptsize\theenumi⃝

   Agree the same seed using the Diffie-hellman key agreement algorithm.

When a user has three or more authenticators, the authenticators share a seed like the situation in Fig. 6. Fig. 6 uses the algorithm (Steiner et al., 1996). All authenticators agree on the following parameters in advance in addition to the agreement for two authenticators.

• •

  Each authenticator identifier (These identifiers are temporary identifiers used only to share a seed)

• •

  The partner authenticator identifier of each authenticator (Each authenticator receives calculated DH public keys from the same authenticator, called the partner authenticator, every step. The user assigns identifiers without overlap.)

The user operates authenticators according to the following steps. In each step, encryption means that an authenticator generates a CEK, encrypts a DH public key using the CEK, and encrypts the CEK using the password set by a user.

Step1:

Generate a DH key pair on each authenticator.

Step2:

• •:

  Authenticator A sends the DH public key ($PK_{A}$) to Authenticator B with encryption.

• •:

  B sends the DH public key ($PK_{B}$) to C with encryption.

• •:

  C sends the DH public key ($PK_{C}$) to A with encryption.

Step3:

• •:

  Authenticator A sends the calculated DH public value ($SK_{A}*PK_{C}$) using its DH private key ($SK_{A}$) and received DH public key ($PK_{C}$) to Authenticator B with encryption.

• •:

  B sends the calculated DH public value ($SK_{B}*PK_{A}$) using its DH private key ($SK_{B}$) and received DH public key ($PK_{A}$) to C with encryption.

• •:

  C sends the calculated DH public value ($SK_{C}*PK_{B}$) using its DH private key ($SK_{C}$) and received DH public key ($PK_{B}$) to A with encryption.

Step4:

• •:

  Authenticator A calculates the DH public value ($SK_{A}*(SK_{C}*PK_{B})$) and agrees the same seed.

• •:

  B calculates the DH public value ($SK_{B}*(SK_{A}*PK_{C})$) and agrees the same seed.

• •:

  C calculates the DH public value ($SK_{C}*(SK_{B}*PK_{A})$) and agrees the same seed.

When a user has more than three authenticators ($N$: the number of her authenticators), she processes the above Step1 to Step $N+1$ with repeating the above Step3.

We assume the following for this proposal.

1. (1)

   Attackers can operate the seed and the private keys corresponding to registered public keys stored in a stolen authenticator.

2. (2)

   It takes time for attackers to gain control of a stolen authenticator.

Assumption 2 is reasonable when authenticators protect the seed and private keys by local authentication like PIN or biometric. In Section 6.4, we consider the case where authenticators have no local authentication, or where local authentication is immediately passed.

Authenticators share a new seed as described in Section 3.3. They hold the previous seed along with a new one without erasing the previous one. They notify a service of updating an OVK by sending an updating message described in Section 3.5.3 when a user signs in for the first time after re-sharing the new seed. The service that receives updating messages waits for some period (OVK migration period) and accepts the new OVPK from the most trustworthy updating message. A service calculates the trustworthiness of each updating message in the way described in Section 3.5.4. The service re-binds public keys to the user’s account by verifying with the new OVPK and revokes the public key bound only to the previous OVPK.

We describe how an authenticator generates an updating message for a new OVK in Fig. 9.

1. \scriptsize\theenumi⃝

   The authenticator receives the metadata from the service to derive OVKs from seeds. There are two kinds of received metadata. The first one is the metadata ($R^{1},M^{1}$) for the previously registered OVK ($OVK^{1}$). The second one is the metadata ($[(R^{2}_{i},M^{2}_{i})]$) for OVK ($OVK^{2}$) candidates that other authenticators have registered as new OVKs. The authenticator receives the second one as a list because attackers can also generate a malicious updating message derived from a seed by using a stolen authenticator.

2. \scriptsize\theenumi⃝

   The authenticator derives the previously registered OVK ($OVK^{1}$) from the received metadata ($R^{1},M^{1}$) and the previous seed ($s^{1}$) as described in Section 3.2. The authenticator uses the same key derivation function (KDF) as the one used in Section 3.2. The authenticator verifies whether the derived OVK ($OVK^{1}$) is legitimate by comparing calculated MAC value with $M^{1}$. If the verification fails, the authenticator aborts this update process.

3. \scriptsize\theenumi⃝

   The authenticator derives the new OVK ($OVK^{2}$) from the received metadata ($[(R^{2}_{i},M^{2}_{i})]$) and the newly shared seed ($s^{2}$). If the metadata is not an empty list, the authenticator derives the new OVK from the legitimate metadata ($(R^{2},M^{2})=(R^{2}_{l},M^{2}_{l})$) with which the authenticator can verify the MAC value ($M^{2}_{l}==MAC(s^{2},R^{2}_{l}+sid)$). If the metadata is an empty list or the metadata has no legitimate metadata, the authenticator generates a new random value ($R^{2}$) and then derives a new OVK. Note that the previously registered OVK ($OVK^{1}$) is not used to derive the new OVK ($OVK^{2}$), but used to generate an updating message.

4. \scriptsize\theenumi⃝

   The authenticator signs the new OVPK ($OVPK^{2}$) by the OVSK ($OVSK^{1}$) corresponding to the previously registered OVPK ($OVPK^{1}$). The authenticator sends the signature as an updating message when signing in. Because the updating message is signed by the private key corresponding to the registered public key, the service can identify the authenticator sending the updating message.

In the above explanation, we assume that authenticators have two shared seeds. However, authenticators may have more than two seeds because users change their authenticators many times. Users replace their authenticators when purchasing new devices and may lose their authenticators more than once. We explain that authenticators can generate the correct updating message even when they have more than two seeds. Authenticators select the latest seed as the new seed. As the seed corresponds to registered OVPK, authenticators can select the seed successfully by verifying the MAC value of the received metadata. From the above, authenticators can send a legitimate updating message to services even when they have more than two seeds.

When a service receives an updating message from a registered authenticator, it enters the OVK migration period. In this migration period, no authenticators can register a new public key by the registered OVK. If the same updating message comes from more than half of the registered authenticators during the period, the service trusts the message. Otherwise, the service trusts the updating message sent from the most registered authenticators at the end of the period. If there is more than one message sent by the most registered authenticators, the service trusts the earliest received message.

As described in Section 3.2.3, an authenticator can derive many different OVKs for different services from a seed. An authenticator can update OVKs multiple times without consuming a lot of storage space. However, the secure storage space that an authenticator has is limited. Therefore, we propose two methods for limiting the number of seeds that an authenticator holds.

1. (1)

   Set a limit on the number of seeds that an authenticator holds. If the number of seeds exceeds the limit, it deletes the oldest seed with the consent of the user.

2. (2)

   Set an expiration date for a seed. If an authenticator has a seed that is about to expire, it prompts a user to share a new seed and update OVKs. It deletes any seed that has expired.

The first method is easier to implement because a user decides whether to delete seeds. The first method does not require a user to renew OVKs periodically, even though she continues to use the same authenticators. On the other hand, in the second method, since a seed has an expiration date, OVKs also have the same expiration date. This means that a service can know when to update a seed. In the second method, a service can send security notifications to reduce operational risks such as forgetting to update OVKs.

Both have their advantages, and both can reduce disadvantages by setting limits to a large value in the first method or a longer expiration date in the second method. The choice of either method depends on a user’s preference or the limitations of authenticators.

Fig. 10 illustrates the implementation of an authenticator based on data flow diagrams (Bruza and van der Weide, 1993). In this figure, an ellipse represents a process, an entity between an upper line and a lower line represents a data store, and an arrow represents data flow.

SeedGenerator implements Section 3.2. Seed stores shared seeds. The bit length of each seed is 256. We statically define the following parameters required in Section 3.2 and a service identifier as the origin of the service URL.

• •

  The algorithm of an OVK is elliptic curve cryptography (Daniel R. L. Brown, 2009) with secp256r1 (Daniel R. L. Brown, 2010). An OVK is calculated using a KDF output as pseudorandomly selected an integer d of Section 3.2.1 in (Daniel R. L. Brown, 2009).

• •

  The key derivation function (KDF) is HMAC (Krawczyk et al., 1997) using SHA-256 (National Institute of Standards and Technology, 2015).

• •

  The MAC function (MAC) is HMAC (Krawczyk et al., 1997) using SHA-256 (National Institute of Standards and Technology, 2015).

SeedNegotiator implements Section 3.3 except for encrypting and decrypting a DH public key by a CEK and a CEK by a password, and sending and receiving ciphertexts. Device implements these exceptions instead of SeedNegotiator. SeedNegotiator stores an ephemeral private key for the DH key agreement algorithm in EDH.

EDH stores the seed calculated as a result of the key agreement in Seed and deletes the ephemeral private key. We statically define the following parameters required in Section 3.3. We also use JSON Web Encryption Compact Serialization (Jones and Hildebrand, 2015) to serialize ciphertexts and algorithm identifiers.

• •

  The key agreement algorithm (DH) is elliptic curve diffie-hellman based on elliptic curve cryptography (Daniel R. L. Brown, 2009) with secp256r1 (Daniel R. L. Brown, 2010).

• •

  The authenticated encryption algorithm is AES using 128 bit key (National Institute of Standards and Technology, 2001) in Galois/Counter Mode (GCM) (National Institute of Standards and Technology, 2007).

• •

  The password-based encryption algorithm is Password Based Encryption Scheme 2 (Moriarty et al., 2017) using AES-KW (Housley and Schaad, 2002) and SHA-256 (National Institute of Standards and Technology, 2015).

SeedUpdater implements Section 3.5. Only this process and SeedGenerator can access Seed.

Device is the process of generating key pairs and attestations and managing them based on an OVK. Credential stores generated key pairs. Attestation stores the attestation private key and the certificate of the corresponding attestation public key. Negotiating stores data used for Section 3.3 like a password. Device generates an attestation for these type of keys: public keys stored in Credential, OVPKs generated by SeedGenerator, and DH public keys calculated by SeedNegotiator.

UI is the process of communicating ciphertexts generated by Device with other authenticators and interacting with a user. We use reading and generating QR codes as the communication channel among authenticators used for Section 3.3. FetchAPI communicates with a service via a secure channel established by TLS.

Fig. 11 illustrates the implementation of a service based on data flow diagrams.

StartAuthn accepts authentication requests from a user. It receives the account name of the user and responds with a challenge bound to the account and, if registered, public keys, an OVPK, and the metadata of OVPK.

Register accepts requests for registering a new account and a new public key bound to an account as described in Section 3.2. When registering a new account, a user sends a new public key, an OVPK, and the metadata of the OVPK. The user also sends an attestation of the public key and, if requested, an attestation of the OVPK. A service verifies attestations to determine whether it accepts the registration.

Authn accepts challenge responses for authentication. We use elliptic curve digital signature algorithm (Daniel R. L. Brown, 2009) with secp256r1 (Daniel R. L. Brown, 2010) for authentication. It also receives an updating message as described in Section 3.5. Update processes updating OVKs.

CredManager manages the bindings of public keys and OVPKs to accounts. Creds stores public keys bound to OVPKs. OVKM stores OVPKs and the corresponding metadata bound to accounts. Updating stores updating messages when processing updating OVPKs.

We enumerate the assets to be protected in this proposal.

1. (1)

   Private keys stored in authenticators

2. (2)

   Public keys managed by services

3. (3)

   The attestation key stored in each authenticator

4. (4)

   The key signing attestation certificates managed by each authenticator manufacturer

5. (5)

   The trusted root certificate and policy for services to validate attestations

6. (6)

   The TLS private key managed by services

7. (7)

   The trusted root certificate and policy for authenticators to validate TLS certificates

8. (8)

   The seed stored in authenticators

9. (9)

   The OVPK and corresponding metadata stored in services

10. (10)

    The ephemeral DH private key generated by authenticators for sharing a seed

11. (11)

    The temporary password stored in authenticators for sharing a seed

We enumerate the goals to achive in our proposal. We define the following goals while referring to goals in (Rolf Lindemann, 2018).

SG-1:

Strong User Authentication: Services can authenticate users based on public key authentication.

SG-2:

Unlinkability: Services cannot correlate their accounts.

SG-3:

Credential Binding: Services can bind public keys to legitimate accounts.

SG-4:

Attestable Properties: Services and authenticators can validate public keys by verifying attestations.

SG-5:

Forgery Resistance: Be resilient from attempting to modify intercepted communications to masquerade as legitimate users.

We enumerate the assumptions about the environment where our proposal works.

SA-1:

The processes and data stores surrounded by the trusted boundary represented by the inner dotted line in Fig. 10 are isolated from other processes on the authenticator. The authenticator requires local authentication before accessing these processes and data stores.

SA-2:

The cryptographic algorithms used can achieve the objectives of each algorithm.

SA-3:

A service can correctly validate the certificate chain of attestations.

SA-4:

A service and an authenticator can establish a secure channel for service authentication, confidentiality for message, and integrity for messages (like TLS).

In Fig. 10, a dotted line represents a trusted boundary. We focus on data flows across trusted boundaries and enumerate the threats in each of them.

First, threats arising between a user and UI include the following.

Homograph Mis-Registration:

A malicious service pretends a legitimate service to make the user believes it is legitimate. It prompts the user to register a new public key seamlessly, and sends metadata stolen from other services. The malicious service correlates OVPKs by whether the user requests a new public key registration or not. This threat violates SG-2 because the malicious service can correlate different OVPKs generated for different services. Our proposal addresses this threat because authenticators verify the MAC value of the received metadata. The data protected by the MAC value contains the identifier of the service that the authenticator communicates. Because Assumption SA-4 allows authenticators to trust the communicating service identifier, authenticators can detect spoofing of services by malicious actors.

User Verification By-pass:

An attacker can operate the authenticator, or an attacker can bypass the local authentication of the authenticator to operate it. This threat violates SG-1 because the attacker can masquerade as the legitimate user. Our proposal addresses this threat by transferring it to SA-1. We consider the case where this SA-1 assumption is not satisfied during the OVK update in Section 6.4.

Threats arising between a service and FetchAPI include the following.

Service Verification Error:

The authenticator cannot properly authenticate services, thus it cannot correctly identify services. As a result, an attacker can eavesdrop and tamper with the communication channel. This threat violates SG-1 and SG-5 because the attacker can hijack the authenticated session. This threat also violates SG-2 because the authenticator fails to address the threat Homograph Mis-Registration described above. Our proposal addresses this threat by transferring it to SA-4.

Threats arising between another authenticator and UI include the following.

Malicious Authenticator Linking:

An attacker’s authenticator participates in sharing a seed. The attacker gets the seed value itself. The attacker can use this authenticator to register a new public key with any service that a legitimate user has registered. This threat violates SG-3. Our proposal addresses this threat because a user protects sharing a seed with a password. Users are required to use passwords that are not guessable during sharing a seed.

Weak Authenticator:

A user allows a weak authenticator to participate in sharing a seed. The weak authenticator does not securely protect a seed, so, when an attacker compromises the weak authenticator, the seed may be leaked. This threat violates SG-3 because the attacker can register a new public key of the attacker’s authenticator by generating the OVK with the compromised seed. Our proposal addresses this threat because each authenticator validates the security properties of other authenticators through attestations when sharing a seed.

Threats arising between Device and UI include the following.

Malicious Authenticator:

A user uses a malicious authenticator. Because a user cannot rely on the malicious authenticators, this threat violates any goals. It is difficult for users to determine whether it is a legitimate authenticator from a trusted manufacturer. Our proposal addresses this threat because services maintain a list of attestation certificates of trusted manufacturers.

Threats to the authenticator include the following.

Side Channel Attack:

Access to the data store that is not described in Fig. 10 compromises assets to be protected. This threat violates SG-1 if key pairs are compromised and SG-2 and SG-3 if seeds are compromised. This threat also arises another threat like Malicious Authenticator Linking if a temporary password for sharing a seed is compromised. Our proposal addresses this threat by transferring it to SA-1.

Bad Cryptography Primitives:

An authenticator uses a compromised cryptographic algorithm or a weak pseudo-random number generator in the process. This threat violates SG-3 if an attacker derives the OVK. This threat also violates SG-2 if an attacker gets the seed. Our proposal addresses this threat by transferring it to SA-2.

In Fig. 11, we focus on data flows across trusted boundaries and enumerate the threats in each of them.

Threats arising between an authenticator and StartAuthn include the following.

Linking OVPK:

An attacker can obtain the OVPK and metadata associated with the account. The attacker receives OVPKs and corresponding metadata from many services and attempts to derive corresponding OVSKs. The attacker also attempts to correlate collected OVPKs by checking whether OVPKs are derived from the same seed. This threat violates SG-2 and SG-3. Our proposal addresses this threat by transferring it to SA-2.

Threats arising between an authenticator and Register include the following.

Malicious Authenticator Registration:

An attacker attempts to register a new public key of his authenticator to a legitimate user account. This threat violates SG-3. Our proposal addresses this threat because an attacker cannot get the OVSK corresponding to the OVPK bound to the account. An attacker cannot also get the seed corresponding to the OVPK. The service can verify that trusted authenticators store a seed and OVSKs by verifying OVPK attestations. Even if a seed is compromised, our proposal mitigates this threat because the number of authenticators that can be registered is restricted. After a user registers public keys of her all authenticators an attacker cannot register his public keys.

Threats arising between an authenticator and Authn include the following.

Updating Malicious OVPK:

An attacker attempts to update to an OVPK derived from the seed held by his authenticator. This threat violates SG-3 because the attacker can register his public keys. This threat also violates SG-1 because the attacker can revoke the user’s public keys. Our proposal addresses this threat because an attacker cannot know the seed corresponding to the registered OVPK. We consider the case where this SA-1 assumption is not satisfied during updating an OVK in Section 6.4. We disscuss whether our proposal mitigates this threat even if the seed is compromised in Section 6.4.