Type names, attribute names and element names are written as code
.
String literals are enclosed in “”, e.g. “UAF-TLV”.
In formulas we use “|” to denote byte wise concatenation operations.
UAF specific terminology used in this document is defined in
[[FIDOGlossary]].
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as
described in [[RFC2119]].
Key Words
In certain environments the overall security of the explicit authentication (as provided by FIDO) is less important, as it might be supplemented with a high degree of implicit authentication or the application doesn’t even require a high level of authentication strength.
The FIDO U2F protocol [[U2FOverview]] supports a more constrained set of Authenticator capabilities. It shares the same security goals as UAF, with the exception of [SG-14] Transaction Non- Repudiation. The UAF protocol has the following security goals:For a definition of the phrases printed in italics, refer to [[QuestToReplacePasswords]] and to [[PasswordAuthSchemesKeyIssues]]
Particular implementations of FIDO Clients, Authenticators, Servers and participating applications may not implement all of these security measures (e.g. Secure Display, [SM-10] Transaction Confirmation) and they also might (and should) implement add itional security measures.
The U2F protocol lacks support for [SM-5] Secure Display, [SM-10] Transaction Confirmation, has only server-supplied [SM-8] Protocol Nonces, and [SM-3] Authenticator Class Attestation is implicit as there is only a single class of device.
Security Goal | Supporting Security Measures |
---|---|
[SG-1] Strong User Authentication | [SM-1] Key Protection [SM-12] Channel Binding [SM-14] Trusted Facet List [SM-15] Signature Counter |
[SG-2] Credential Guessing Resilience | [SM-1] Key Protection [SM-6] Cryptographically Secure Verifier Database |
[SG-3] Credential Disclosure Resilience | [SM-1] Key Protection [SM-9] Authenticator Certification [SM-15] Signature Counter |
[SG-4] Unlinkability | [SM-2] Unique Authentication Keys [SM-3] Authenticator Class Attestation |
[SG-5] Verifier Leak Resilience | [SM-2] Unique Authentication Keys [SM-6] Cryptographically Secure Verifier Database |
[SG-6] Authenticator Leak Resilience | [SM-9] Authenticator Certification [SM-15] Signature Counter |
[SG-7] User Consent | [SM-1] Key Protection [SM-5] User Consent [SM-7] Secure Channel with Server Authentication [SM-10] Transaction Confirmation (WYSIWYS) |
[SG-8] Limited PII | [SM-2] Unique Authentication Keys |
[SG-9] Attestable Properties | [SM-3] Authenticator Class Attestation [SM-4] Authenticator Status Checking [SM-9] Authenticator Certification |
[SG-10] DoS Resistance | [SM-8] Protocol Nonces |
[SG-11] Forgery Resistance | [SM-7] Secure Channel with Server Authentication [SM-8] Protocol Nonces [SM-11] Round Trip Integrity [SM-12] Channel Binding |
[SG-12] Parallel Session Resistance | [SM-7] Secure Channel with Server Authentication [SM-8] Protocol Nonces [SM-11] Round Trip Integrity [SM-12] Channel Binding |
[SG-13] Forwarding Resistance | [SM-7] Secure Channel with Server Authentication [SM-8] Protocol Nonces [SM-11] Round Trip Integrity [SM-12] Channel Binding |
[SG-14] Transaction Non-Repudiation | [SM-1] Key Protection [SM-2] Unique Authentication Keys [SM-8] Protocol Nonces [SM-9] Authenticator Certification [SM-10] Transaction Confirmation (WYSIWYS) [SM-11] Round Trip Integrity [SM-12] Channel Binding |
[SG-15] Respect for Operating Environment Security Boundaries | [SM-13] Key Handle Access Token [SM-14] Trusted Facet List |
FIDO can also provide only limited protections when a user chooses to deliberately violate [SA-5], e.g. by roaming a USB authenticator to an untrusted system like a kiosk, or by granting permissions to access all authentication keys to a malicious app in a mobile environment. Transaction Confirmation can be used as a method to protect against compromised FIDO user devices.
In to components such as the FIDO Client, Server, Authenticators and the mix of software and hardware modules they are comprised of, the end-to-end security goals also depend on correct implementation and adherence to FIDO security guidance by other participating components, including web browsers and relying party applications. Some configurations and uses may not be able to meet all security goals. For example, authenticators may lack a secure display, they may be composed only of unattestable software components, they may be deliberately designed to roam between untrusted operating environments, and some operating environments may not provide all necessary security primitives (e.g., secure IPC, application isolation, modern TLS implementations, etc.)
T-1.1.1 | Homograph Mis-Registration | Violates |
---|---|---|
AC3 | The user registers a FIDO authentication key with a fraudulent
web site instead of the genuine Relying Party.
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 user's 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. |
SG-1 |
T-1.2.1 | FIDO Client Corrpution | Violates |
---|---|---|
AC3 | Attacker gains ability to execute code in the security context of the FIDO Client.
Consequences: Violation of [SA-5]. 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. |
SA-5 |
T-1.2.2 | Logical/Physical User Device Attack | Violates |
---|---|---|
AC3 / AC5 | Attacker gains physical access to the FIDO user device but not the FIDO Authenticator.
Consequences: Possible violation of [SA-5] 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-5] 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) |
SA-5 |
T-1.2.3 | User Device Account Access | Violates |
---|---|---|
AC3 / AC4 | Attacker gains access to a user's login credentials on the FIDO user device.
Consequences: Authenticators might be remotely abused, or weakly-verifying authenticators might be locally abused, violating [SG-1] Strong User Authentication and [SG-13] Transaction Non-Repudiation. Possible violation of [SA-5] 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. |
SG-1, SG-13; SA-5 |
T-1.2.4 | App Server Verification Error | Violates |
---|---|---|
AC3 | A client application fails to properly validate the remote sever identity, accepts
forged or stolen credentials for a remote server, or allows weak or missing cryptographic
protections for the secure channel.
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. |
SG-11, SG-12, SG-13 |
T-1.2.5 | RP Web App Corruption | Violates |
---|---|---|
An attacker is able to obtain malicious execution in the security context of the Relying
Party application (e.g. via Cross-Site Scripting) or abuse the secure channel
or session identifier after the user has successfully authenticated.
Consequences: The attacker is able to control the user's session, violating [SG-14] Transaction Non-Repudiation. Mitigations: The server can employ [SM-10] Transaction Confirmation to gain additional assurance for high value operations. |
SG-14 |
T-1.2.6 | Fingerprinting Authenticators | Violates |
---|---|---|
A remote adversary is able to uniquely identify a FIDO user device using the fingerprint
of discoverable configuration of its FIDO Authenticators.
Consequences: The exposed information violates [SG-8] Limited PII, allowing an adversary to violate [SG-7] User Consent by strongly authenticating 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. |
SG-4, SG7, SG-8 |
T-1.2.7 | App to FIDO Client full MITM attack | Violates |
---|---|---|
AC3 | Malicious software on the FIDO user device is able to read, tamper with, or spoof
the endpoint of inter-process communication channels between the FIDO Client
and browser or Relying Party application.
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 arriving on 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 would see the relevant AppID and transaction text and decide whether or not to accept an action. |
SA-2 |
T-1.2.8 | Authenticator to App Read-Only MITM attack | Violates |
---|---|---|
AC3 | An adversary is able to obtain an authenticator's signed protocol response message.
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. |
SG-1, SG-12, SG-13 |
T-1.2.9 | Malicious App | Violates |
---|---|---|
AC3 | A user installs an application that represents itself as being associated with to
one Relying Party application but actually initiates a protocol conversation with a
different Relying Party and attempts to abuse previously registered authentication
keys at that Relying Party.
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] Trusted Facet List. |
SG-7 |
T-1.2.10 | Phishing Attack | Violates |
---|---|---|
A Phisher convinces the user to enter his PIN used for user verification into an application /
web site disclosing the PIN to the Phisher. In the traditional username/password world
this enables the attacker to successfully impersonate the user (to the relying party).
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. |
T-1.3.1 | Malicious FIDO Client | Violates |
---|---|---|
AC3 | Attacker convinces users to install and use a malicious FIDO Client.
Consequences: Violation of [SA-5] 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. When using [SM-10] Transaction Confirmation, the user sees the real AppIDs and transaction text and can decide to accept or reject the action. |
SA-5 |
T-1.4.1 | Malicious Authenticator | Violates |
---|---|---|
AC2 | Attacker convinces users to use a maliciously implemented authenticator.
Consequences: The fake authenticator does not implement any appropriate security measures and is able to violate all security goals of FIDO. Mitigations: A user may be unable to distinguish a malicious authenticator, but a Relying Party can use [SM-3] Authenticator Class Attestation to identify and only allow registration of reliable authenticators that have passed [SM-9] Authenticator Certification A Relying Party can additionally rely on [SM-4] Authenticator Status Checking to check if an attestation presented by a malicious authenticator has been marked as compromised. |
SG-1 |
T-1.4.2 | Uauth.priv Key Compromise | Violates |
---|---|---|
AC2 | Attacker succeeds in extracting a user's cryptographic authentication key for use in a
different context.
Consequences: The attacker could impersonate the user with a cloned authenticator that does not do trustworthy user verification, violating [SG-1]. Mitigations: [SM-1] Key Protection measures are intended to prevent this. Relying Parties can check [SM-9] Authenticator Certification attributes to determine the type of key protection in use by a given authenticator class. Relying Parties can additionally verify the [SM-15] Signature Counter and detect that an authenticator has been cloned if it ever fails to advance relative to the prior operation. |
SG-1 |
T-1.4.3 | User Verification By-Pass | Violates |
---|---|---|
AC3 | Attacker could use the cryptographic authentication key (inside the authenticator)
either with or without being noticed by the legitimate user.
Consequences: Attacker could impersonate user, violating [SG-1]. Mitigations: A user can only register and a Relying Party only allow authenticators that perform [SM-1] Key Protection with an appropriately secure user verification process. Does not apply to Silent Authenticators. |
SG-1 |
T-1.4.4 | Physical Authenticator Attack | Violates |
---|---|---|
AC5 / AC6 | Attacker could get physical access to FIDO Authenticator (e.g. by stealing it).
Consequences: Attacker could launch offline attack in order to use the authentication key. If this offline attack succeeds, the attacker could successfully impersonate the user, violating [SG-1] Strong User Authentication. Attacker can introduce a low entropy situation to recover an ECDSA signature key (or optherwise extract the Uauth.priv key), violating [SG-9] Attestable Properties if the attestation key is targeted or [SG-1] Strong User Authentication if a user key is targeted. Mitigations: [SM-1] Key Protection includes requirements to implement strong protections for key material, including resistance to offline attacks and low entropy situations. Relying Parties should use [SM-3] Authenticator Class Attestation to only accept Authenticators implementing a sufficiently strong user verification method. |
SG-1 |
T-1.4.6 | Fake Authenticator | Violates |
---|---|---|
Attacker is able to extract the authenticator attestation key from an authenticator,
e.g. by neutralizing physical countermeasures in a laboratory setting.
Consequences: Attacker can violate [SG-9] Attestable Properties by creating a malicious hardware or software device that represents itself as a legitimate one. Mitigations: 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. |
SG-9 |
T-1.4.7 | Transaction Confirmation Display Overlay Attack | Violates |
---|---|---|
Attacker is able to subvert [SM-5] Secure Display functionality (WYSIWYS), perhaps
by overlaying the display with false information.
Consequences: Violation of [SG-14] Transaction Non-Repudiation. Mitigations: Implementations must take care to protect [SA-4] in their implementation of a secure display, e.g. by implementing a distinct hardware display or employing appropriate privileges in the operating environment of the user device to protect against spoofing and tampering. [SM-9] Authenticator Certification will provide Relying Parties with metadata about the nature of a transaction confirmation display information that can be used to assess whether it matches the assurance level and risk tolerance of the Relying Party for that particular transaction. |
SG-14 |
T-1.4.8 | Signature Algorithm Attack | Violates |
---|---|---|
AC2 | A cryptographic attack is discovered against the public key cryptography system
used to sign data by the FIDO authenticator.
Consequences: Attacker is able to use messages generated by the client to violate [SG-2] Credential Guessing Resistance Mitigations: [SM-8] Protocol Nonces, including client-generated entropy, limit the amount of control any adversary has over the internal structure of an authenticator. [SM-1] Key Protection for non-silent authenticators requires user interaction to authorize any operation performed with the authentication key, severely limiting the rate at which an adversary can perform adaptive cryptographic attacks. |
SG-2 |
T-1.4.9 | Abuse Functionality | Violates |
---|---|---|
It might be possible for an attacker to abuse the Authenticator functionality by sending
commands with invalid parameters or invalid commands to the Authenticator.
Consequences: This might lead to e.g. user verification by-pass or potential key extraction, v Mitigations: Proper robustness (e.g. due to testing) of the Authenticator firmware. |
SG-1 |
T-1.4.10 | Random Number prediction | Violates |
---|---|---|
It might be possible for an attacker to get access to information allowing the prediction of RNG data.
Consequences: This might lead to key compromise situation (T-1.4.2) when using ECDSA (if the k value is used multiple times or if it is predictable). Mitigations: Proper robustness of the Authenticator's RNG and verification of the relevant operating environment parameters (e.g. temperature, ...). |
SG-1 |
T-1.4.11 | Firmware Rollback | Violates |
---|---|---|
Attacker might be able to install a previous and potentially buggy version of the firmware.
Consequences: This might lead to successful attacks, e.g. T-1.4.9. Mitigations: Proper robustness firmware verification method. |
SG-1 |
T-1.4.12 | User Verification Data Injection | Violates |
---|---|---|
AC3, AC6 | Attacker might be able to inject pre-captured user verification data into the
Authenticator. For example, if a password is used as user verification method, the attacker
could capture the password entered by the user and then send the correct password
to the Authenticator (by-passing the expected keyboard/PIN pad). Passwords could
be captured ahead of the attack e.g. by convincing the user to enter the password into
a malicious app (“phishing”) or by spying directly or indirectly the password data.
In another example, some malware could play an audio stream which would be recorded by the microphone and used by a Speaker-Recognition based Authenticator. Consequences: This might lead to successful user impersonation (if the attacker has access to valid user verification data). Mitigations: Use a physically secured user verification input method, e.g. Fingerprint Sensor or Trusted-User-Interface for PIN entry which cannot be by-passed by malware. |
SG-1 |
T-1.4.13 | Verification Reference Data Modification | Violates |
---|---|---|
AC3, AC6 | The Attacker gained logical or physical access to the Authenticator and modifies
Verification Reference Data (e.g. hashed PIN value, fingerprint templates) stored in the Authenticator and
adds reference data known to or reproducible by the attacker.
Consequences: The attacker would be recognized as the legitimate User and could impersonate the user. Mitigations: Proper protection of the the verification reference data in the Authenticator. |
SG-1 |
T-1.4.14 | Read access to captured user verification data | Violates |
---|---|---|
AC3, AC6 | The Attacker gained read access to the captured user verification dat (e.g. PIN, fingerprint image, ...).
Consequences: The attacker gets access to PII and could disclose it violating SG-8. Mitigations: Limiting access to the user verification data to the Authenticator exclusively. |
SG-8 |
T-2.1.1 | FIDO Server DB Read Attack | Violates |
---|---|---|
Attacker could obtains read-access to FIDO Server registration database.
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 Resiliance 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 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. |
SG-2, SG-5 |
T-2.1.2 | FIDO Server DB Modification Attack | Violates |
---|---|---|
Attacker gains write-access to the FIDO Server registration database.
Consequences: Violation of [SA-7] 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-7]. |
SA-7 |
T-2.2.1 | WebApp Malware | Violates |
---|---|---|
Attacker gains ability to execute code in the security context of the Relying Party
web application or FIDO Server.
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 to the user's computing environment |
SG-1, SG-9, SG-10 |
T-3.1.1 | TLS Proxy | Violates |
---|---|---|
The FIDO user device is administratively configured to connect through a proxy that terminates
TLS connections. The client trusts this device, but the connection between
the user and FIDO server is no longer end-to-end secure.
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] |
SG-11, SG-12, SG-13 |
T-3.1.2 | Fraudulent TLS Server Certificate | Violates |
---|---|---|
An attacker is able to obtain control of a certificate credential for a Relying Party,
perhaps from a compromised Certification Authority or poor protection practices
by the Relying Party.
Consequences:As for [T-1.2.4]. Mitigations:As for [T-1.2.4]. |
T-3.1.3 | Protocol level real-time MITM attack | Violates |
---|---|---|
An adversary can intercept and manipulate network packages sent from the relying party to the client.
The adversary uses this capability to (a) terminate the underlying TLS session from the client at
the adversary and to (b) simultaneously use another TLS session from the adversary to the relying party.
In the traditional username/password world, this allows the adversary to intercept the username
and the password and then successfully impersonate the user at the relying party.
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. |
T-4.1.1 | Manufacturer Level Attestation Key Compromise | Violates |
---|---|---|
Attacker obtains control of an attestation key or attestation key issuing key.
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. |
SG-9 |
T-4.1.2 | Malicious Authenticator HW | Violates |
---|---|---|
FIDO Authenticator manufacturer relies on hardware or software components
that generate weak cryptographic authentication key material or contain backdoors.
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. |
SA-1 |
T-4.2.1 | Vendor Level Trust Anchor Injection Attack | Violates |
---|---|---|
Attacker adds malicious trust anchors to the trust list shipped by a FIDO Server
vendor.
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-7]. Relying Parties can their trust list against definitive data published by the FIDO Alliance. |
SA-7 |
T-4.3.1 | Metadata Service Signing Key Compromise | Violates |
---|---|---|
The attacker gets access to the private Metadata signing key.
Consequences: The attacker could sign invalid Metadata. The attacker could
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. |
SG-9 |
T-4.3.2 | Metadata Service Data Injection | Violates |
---|---|---|
The attacker injects malicious Authenticator data into the Metadata source.
Consequences: The attacker could make the Metadata Service operator sign invalid Metadata. The attacker could
Mitigations: The Metadata Service operator could carefully review the delta between the old and the new Metadata. Authenticator vendors could verify the published Metadata related to their Authenticators. |
SG-9 |
T-5.1.1 | Error Status Side Channel | Violates |
---|---|---|
Relying parties issues an authentication challenge to an authenticator and can infer
from error status if it is already enrolled.
Consequences: U2F authenticators not requiring user interaction may be used to track users without their consent by issuing a pre-authentication challenge to a U2F token, revealing the identity of an otherwise anonymous user. Users would be identifiable by relying parties without their knowledge, violating [SG-7] Mitigations: The U2F specification recommends that browsers prompt users whether to allow this operation using mechanisms similar to those defined for other privacy sensitive operations like Geolocation. |
SG-7 |
T-5.1.2 | Malicious RP | Violates |
---|---|---|
Malicious relying party mounts a cryptographic attack on a key handle it is storing.
Consequences: U2F does not have a protocol-level notion of [SG-14] Transaction Non-Repudiation but If the Relying Party is able to recover the contents of the key handle it might forge logs of protocol exchanges to associate the user with actions he or she did not perform. If the Relying Party is able to recover the key used to wrap a key handle, that key is likely shared, and might be used to decrypt key handles stored with other Relying Parties and violate [SG-1] Strong User Authentication. Mitigations: None. U2F depends on [SA-1] to hold for key wrapping operations. |
T-5.1.3 | Physical U2F Authenticator Attack | Violates |
---|---|---|
Attacker gains physical access to U2F Authenticator (e.g., by stealing it).
Consequences: Same as for T-1.4.4 A U2F authenticator has weak local user verification. If the attacker can guess the username and password/PIN, they can impersonate the user, violating [SG-1] Strong User Authentication Mitigations: Relying Parties can use strong additional factors. Relying Parties should provide users a means to revoke keys associated with a lost device. |
SG-1 |