Consequences: The fraudulent site may convince the user to disclose a set of non-FIDO credentials sufficient to allow the attacker to register a FIDO Authenticator under its own control, at the genuine Relying Party, on the users' behalf, violating [SG-1] Strong User Authentication.

Mitigations: Disclosure of non-FIDO credentials is outside of the scope of the FIDO security measures, but Relying Parties should be aware that the initial strength of an authentication key is no better than the identity-proofing applied as part of the registration process.

Consequences: The FIDO subsystem will determine that either (a) no FIDO authenticator has been registered with the fraudulent site or (b) it will use the FIDO Uauth key registered to the fraudulent site - which is different from the Uauth key for the relying party's site.

Mitigations: FIDO inherently ties keys to the relying party (formally identified by the AppID/RP ID, and authenticated by TLS and the CA infrastructure).

Consequences: Violation of [SA-4].

Mitigations: When the operating environment on the FIDO user device allows, the FIDO Client should operate in a privileged and isolated context under [SA-2] to protect itself from malicious modification by anything outside of the Trusted Computing Base.

Consequences: Possible violation of [SA-4] by installing malicious software or otherwise tampering with the FIDO user device.

Mitigations: [SM-1] Key Protection prevents the disclosure of authentication keys or other assets during a transient compromise of the FIDO user device.

A persistent compromise of the FIDO user device can lead to a violation of [SA-4] unless additional protection measures outside the scope of FIDO are applied to the FIDO user device. (e.g. whole disk encryption and boot-chain integrity).

Consequences: Authenticators might be remotely abused, or weakly-verifying authenticators might be locally abused, violating [SG-1] Strong User Authentication and [SG-14] Transaction Non-Repudiation.

Possible violation of [SA-4] by the installation of malicious software.

Mitigations: Relying Parties can use [SM-9] Authenticator Certification and [SM-3] Authenticator Class Attestation to determine the nature of authenticators and not rely on weak, or weakly-verifying authenticators for high value operations.

Consequences: An active network adversary can modify the Relying Party's authenticator policy and downgrade the client's choice of authenticator to make it easier to attack.

An active network adversary can intercept or view FIDO messages intended for the Relying Party. It may be able to use this ability to violate [SG-12] Parallel Session Resistance, [SG-11] Forgery Resistance or [SG-13] Forwarding Resistance.

Mitigations: The server can verify [SM-8] Protocol Nonces to detect replayed messages and protect from an adversary that can read but not modify traffic in a secure channel.

The server can mandate a channel with strong cryptographic protections to prevent message forgery and can verify a [SM-12] Channel Binding to detect forwarded messages.

Consequences: The attacker is able to control the users' session, violating [SG-14] Transaction Non-Repudiation.

Mitigations: The server can employ [SM-10] Transaction Confirmation to gain additional assurance for high value operations.

Consequences: The exposed information violates [SG-8] Limited PII, allowing an adversary to violate [SG-7] User Consent by strongly identfying the user without their knowledge and [SG-4] Unlinkablity by sharing that fingerprint.

Mitigations: [SM-3] Authenticator Class Attestation ensures that the fingerprint of an Authenticator will not be unique.

For web browsing situations where this threat is most prominent, user agents may provide additional user controls around the discoverability of FIDO Authenticators.

Consequences: Adversary is able to subvert [SA-2].

Mitigations: On platforms where [SA-2] is not strong the security of the system may depend on preventing malicious applications from being loaded onto the FIDO user device. Such protections, e.g. app store policing, are outside the scope of FIDO.

When using [SM-10] Transaction Confirmation, the user will be presented with the relevant AppID/RP ID and transaction text and will be able to evaluate whether or not to consent to the transaction.

Consequences: The attacker attempts to replay the message to authenticate as the user, violating [SG-1] Strong User Authentication, [SG-13] Forwarding Resistance and [SG-12] Parallel Session Resistance.

Mitigations: The server can use [SM-8] Protocol Nonces to detect replay of messages and verify [SM-11] Round Trip Integrity to detect modified messages.

Consequences: Adversary is able to violate [SG-7] User Consent by misrepresenting the target of authentication.

Other consequences equivalent to [T-1.2.5]

Mitigations: If a [SM-5] Transaction Confirmation Display is present, the user may be able to verify the true target of an operation.

If the malicious application attempts to communicate directly with an Authenticator that uses [SM-13] KeyHandleAccessToken, it should not be able to access keys registered by other FIDO Clients.

If the operating environment on the FIDO user device supports it, the FIDO client may be able to determine the application's identity and verify if it is authorized to target that Relying Party using a [SM-14] AppID/RP ID Separation.

Consequences: None as the phisher additionally would need access to the Authenticator in order to pass user verification [SM-1]. In FIDO, the user verification PIN (if user verification is done via PIN) is not known to the relying party and hence isn't sufficient for user impersonation. If user verification is done using an alternative user verification method, this applies accordingly.

Mitigations: In FIDO, the Uauth.priv key is used to sign a relying party supplied challenge. without (use) access to that key, no impersonation is possible.

Consequences: Violation of [SA-4]. The malicious FIDO Client could trigger the use of any Uauth key in the context of the related AppID/RP ID. User Verification / User Presence Check will be performed by the Authenticator as indicated.

Mitigations: Mitigating malicious software installation is outside the scope of FIDO.

If an authenticator implements [SM-1] Key Protection, the user may be able to recover full control of their registered authentication keys by removing the malicious software from their user device.

If it is a bound authenticator, then [SM-13] might help distinguishing the original FIDO Client (i.e. the one used at registration time) from the malicious one.

When using [SM-10] Transaction Confirmation, the user sees the claimed AppIDs/RP IDs and transaction text and can decide to accept or reject the action.

Platforms implementing FIDO can filter communication to FIDO Authenticators. Depending on the platform such filter mechanisms may limit access to white-listed Apps.

Consequences: Violation of [SA-4]. The malicious App could trigger the use of any Uauth key in the context of the AppID/RP ID (related to that key). User Verification / User Presence Check will be performed by the Authenticator as indicated.

Mitigations: Mitigating malicious software installation is outside the scope of FIDO.

If an authenticator implements [SM-1] Key Protection, the user may be able to recover full control of their registered authentication keys by removing the malicious software from their user device.

If it is a bound authenticator, then [SM-13] might help distinguishing the original FIDO Client (i.e. the one used at registration time) from the malicious one.

When using [SM-10] Transaction Confirmation, the user sees the claimed AppIDs/RP IDs and transaction text and can decide to accept or reject the action.

Platforms implementing FIDO can filter communication to FIDO Authenticators. Depending on the platform such filter mechanisms may limit access to white-listed Apps.

Consequences: Violation of [SA-4]. The malicious device could trigger the use of any Uauth key in the context of the AppID/RP ID (related to that key). User Verification / User Presence Check will be performed by the Authenticator as indicated.

Mitigations: FIDO expects each transport protocol (i.e. the communication between client and FIDO Authenticator) to provide a secure link (e.g. see section 8.3.3 in [FIDOCTAP].

When using [SM-10] Transaction Confirmation, the user sees the claimed AppIDs/RP IDs and transaction text and can decide to accept or reject the action.

Consequences: May undermine [SG-4], [SG-5], [SG-7], [SG-8].

Mitigations: This threat is mitigated by [SM-10], [SM-13].

Consequences: When combined with T-1.3.3 it may undermine [SG-1] if an "external" user verification method (e.g. authenticatorClientPIN) is being used [FIDORegistry].

Mitigations: This threat is mitigated by [SM-1], more specifically by the ability for authenticators to either implement "internal" user verification methods [FIDORegistry] or to encrypt the communication to the authenticator using PIN/UV Auth Protocol One/Two [FIDOCTAP].

Consequences: Attacker can access all cryptographic key handles and authenticator characteristics associated with a username. If an authenticator or combination of authenticators is unique, they might use this to try to violate [SG-2] Unlinkability.

Attacker attempts to perform factorization of public keys by virtue of having access to a large corpus of data, violating [SG-5] Verifier Leak Resilience and [SG-2] Credential Guessing Resilience.

Mitigations: [SM-2] Unique Authentication Keys help prevent disclosed key material from being useful against any other Relying Party, even if successfully attacked.

The use of an [SM-6] Cryptographically Secure Verifier Database helps assure that it is infeasible to attack any leaked verifier keys.

[SM-9] Authenticator Certification along with [SM-16] should help prevent authenticators with poor entropy from entering the market, reducing the likelihood that even a large corpus of key material will be useful in mounting attacks.

Consequences: Violation of [SA-6]

The attacker may inject a key registration under its control, violating [SG-1] Strong User Authentication.

Mitigations: Mitigating such attacks is outside the scope of the FIDO specifications. The Relying Party must maintain the integrity of any information it relies up on to identify a user as part of [SA-6].

Consequences: Attacker is able to violate [SG-1], [SG-10], [SG-9] and any other Relying Party controls.

Mitigations: The consequences of such an incident are limited to the relationship between the user and that particular Relying Party by [SM-1], [SM-2], and [SM-5].

Even within the Relying Party to user relationship, a user can be protected by [SM-10] Transaction Confirmation if the compromise does not include the users' computing environment.

Consequences: May undermine [SG-1], [SG-4].

Mitigations: This threat is mitigated by [SM-1], [SM-2], [SM-5], [SM-23].

Consequences: May undermine [SG-11], [SG-12], [SG-13], [SG-14].

Mitigations: This threat is mitigated by proper implementation of protocol nonces, see [SM-8]. It is important that either the server challenges are (1) never repeated, or (2) repeated with sufficiently low probability (e.g. only one in 2 to the power of 112 cases).

Consequences: Gives potential attackers more time to compute hash collisions and exploit them. This attack seems rather theoretical as (a) collision resistant hash functions are being used and (b) other meaningful data fields are being added to compute the finalChallenge (UAF) / clientData (FIDO2).

Mitigations: Not required as long as server challenges are sufficiently unlikely to be repeated and the hash function is collision resistant.

Consequences: Any such proxies introduce a new party into the protocol. If this party is untrustworthy, consequences may be as for [T-1.2.4].

Mitigations: Mitigations for [T-1.2.4] apply, except that the proxy is considered trusted by the client, so certain methods of [SM-12] Channel Binding may indicate a compromised channel even in the absence of an attack. Servers should use multiple methods and adjust their risk scoring appropriately. A trustworthy client that reports a server certificate that is unknown to the server and does not chain to a public root may indicate a client behind such a proxy. A client reporting a server certificate that is unknown to the server but validates for the server's identity according to commonly used public trust roots is more likely to indicate [T-3.1.2].

Consequences: As for [T-1.2.4].

Mitigations: As for [T-1.2.4].

Consequences: None if FIDO channelBinding [SM-12] or transaction confirmation [SM-10] are used.

Mitigations: In the case of channelBinding [SM-12], the FIDO server will detect the MITM in the TLS channel by comparing the channel binding information provided by the client and the channel binding information retrieved locally by the server.

In the case of transaction confirmation [SM-10], the user verifies and approves a particular transaction. The adversary could modify the transaction before approval. This would lead to rejection by the user. Alternatively, the adversary could modify the transaction after approval. This will break the signature in the transaction confirmation response. The FIDO Server will not accept it as a consequence.

HTTP Public Key Pinning (RFC7469) can also be used to mitigate this attack (outside the FIDO stack).

Consequences: Same as [T-1.4.6]: Attacker can violate [SG-9] Attestable Properties by creating a malicious hardware or software device that represents itself as a legitimate one.

Mitigations: Same as [T-1.4.6]: Relying Parties can use [SM-4] Authenticator Status Checking to identify known-compromised keys. Identification of such compromise is outside the strict scope of the FIDO protocols.

Consequences: Effective violation of [SA-1] in the context of such an Authenticator.

Mitigations: The process of [SM-9] Authenticator Certification may reveal a subset of such threats, but it is not possible that all such can be revealed with black box testing and white box examination may be is economically infeasible. Users and Relying Parties with special concerns about this class of threat must exercise their own necessary caution about the trustworthiness and verifiability of their vendors and supply chain. [SM-24] builds confidence that an Authenticator is not malicious or poorly implemented.

Consequences: Attacker can deploy fake Authenticators which Relying Parties cannot detect as such, which do not implement any appropriate security measures, and is able to violate all security goals of FIDO.

Mitigations: This type of supply chain threat is outside the strict scope of the FIDO protocols and violates [SA-6]. Relying Parties can verify their trust list against the data published by the FIDO Alliance Metadata Service [FIDOMetadataService] (see https://fidoalliance.org/mds).

Consequences: The attacker could sign invalid Metadata. The attacker could

• make trustworthy authenticators look less trustworthy (e.g. by increasing FAR).
• make weak authenticators look strong (e.g. by changing the key protection method to a more secure one)
• inject malicious attestation trust anchors, e.g. root certificates which cross-signed the original attestation trust anchor and the cross-signed original attestation root certificate. This malicious trust anchors could be used to sign attestation certificates for fraudulent authenticators, e.g. authenticators using the AAID of trustworthy authenticators but not protecting their keys as stated in the metadata.

Mitigations: The Metadata Service operator should protect the Metadata signing key appropriately, e.g. using a hardware protected key storage.

Relying parties could use out-of-band methods to cross-check Metadata Statements with the respective vendors and cross-check the revocation state of the Metadata signing key with the provider of the Metadata Service.

Consequences: The attacker could make the Metadata Service operator sign invalid Metadata Statements. The attacker could

• make trustworthy authenticators look less trustworthy (e.g. by increasing FAR).
• make weak authenticators look strong (e.g. by changing the key protection method to a more secure one)
• inject malicious attestation trust anchors, e.g. root certificates which cross-signed the original attestation trust anchor and the cross-signed original attestation root certificate. This malicious trust anchors could be used to sign attestation certificates for fraudulent authenticators, e.g. authenticators using the AAID of trustworthy authenticators but not protecting their keys as stated in the metadata.

Mitigations: The Metadata Service operator could carefully review the delta between the old and the new Metadata Statements. Authenticator vendors could verify the published Metadata Statements related to their Authenticators.