-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document prevention of attacks on privacy #899
Changes from 6 commits
10e12d0
6a83ec0
0b3e939
f97fb77
a510bbf
b789438
b136ba2
1e0471f
48d6579
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -147,6 +147,10 @@ spec: FIDO-Registry; urlPrefix: https://fidoalliance.org/specs/fido-v2.0-ps-2017 | |
type: dfn | ||
text: Section 3.6.2; url: public-key-representation-formats | ||
|
||
spec: Wikipedia-NaturalPerson; urlPrefix: https://en.wikipedia.org/wiki/Natural_person | ||
type: dfn | ||
text: natural person | ||
|
||
|
||
</pre> <!-- class=anchors --> | ||
|
||
|
@@ -4777,6 +4781,91 @@ which should make use of the existing browser permissions framework for the Geol | |
|
||
The privacy principles in [[!FIDO-Privacy-Principles]] also apply to this specification. | ||
|
||
|
||
## De-anonymization prevention measures ## {#sctn-privacy-attacks} | ||
|
||
[INFORMATIVE] | ||
|
||
Many aspects of the design of the [=Web Authentication API=] are motivated by privacy concerns. The main concern considered in | ||
this specification is the protection of the user's personal identity, i.e., the identification of a [=natural person=] or a | ||
correlation of separate identities as belonging to the same [=natural person=]. Although the [=Web Authentication API=] does not | ||
use or provide any form of global identity, the following kinds of potentially correlatable identifiers are used: | ||
|
||
- The user's [=credential IDs=] and [=credential public keys=]. | ||
|
||
These are registered by the [=[RP]=] and subsequently used by the user to prove possession of the corresponding [=credential | ||
private key=]. They are also visible to the [=client=] in the communication with the [=authenticator=]. | ||
|
||
- The user's identities specific to each [=[RP]=], e.g., usernames and [=user handles=]. | ||
|
||
These identities are obviously used by each [=[RP]=] to identify a user in their system. They are also visible to the | ||
[=client=] in the communication with the [=authenticator=]. | ||
|
||
- The user's biometric characteristic(s), e.g., fingerprints or facial recognition data [[ISOBiometricVocabulary]]. | ||
|
||
This is optionally used by the [=authenticator=] to perform [=user verification=]. It is not revealed to the [=[RP]=], but in | ||
the case of [=platform authenticators=], it might be visible to the [=client=] depending on the implementation. | ||
|
||
- The models of the user's [=authenticators=], e.g., product names. | ||
|
||
This is exposed in the [=attestation statement=] provided to the [=[RP]=] during [=registration=]. It is also visible to the | ||
[=client=] in the communication with the [=authenticator=]. | ||
|
||
- The identities of the user's [=authenticators=], e.g., serial numbers. | ||
|
||
This is possibly used by the [=client=] to enable communication with the [=authenticator=], but is not exposed to the | ||
[=[RP]=]. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wrt "The identities of the user's [=authenticators=]..." -- this confused me because it is separate from the immediately above models of authnrs revealed thru attestation, but this one does not mention attestation -- so is this referring to info that is revealed at he OS platform and transport layers which the [=client=] may see? if so, perhaps clarify? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe this is just a brain fart on my part - the WebAuthn spec says absolutely nothing about this, so I agree it's probably confusing to even bring it up. The OS may be able to see serial numbers and such on the device level (YubiKeys provide APIs for querying for it, for example), but it should never be exposed to the RP. So I'm thinking I'll just delete this bullet. That sound good? |
||
|
||
Some of the above information is necessarily shared with the [=[RP]=]. The following sections describe the measures taken to | ||
prevent malicious [=[RPS]=] from using it to discover a user's personal identity. | ||
|
||
|
||
## Anonymous, scoped, non-correlatable [=public key credentials=] ## {#sec-non-correlatable-credentials} | ||
|
||
[INFORMATIVE] | ||
|
||
Although [=Credential IDs=] and [=credential public keys=] are necessarily shared with the [=[RP]=] to enable strong | ||
authentication, they are designed to be minimally identifying and not shared between [=[RPS]=]. | ||
|
||
- [=Credential IDs=] and [=credential public keys=] are meaningless in isolation, as they only identify [=credential key pairs=] | ||
and not users directly. | ||
|
||
- Each [=public key credential=] is strictly bound to a specific [=[RP]=], and the [=client=] ensures that its existence is not | ||
revealed to other [=[RPS]=]. A malicious [=[RP]=] thus cannot ask the [=client=] to reveal a user's other identities. | ||
|
||
- The [=client=] also ensures that the existence of a [=public key credential=] is not revealed to the [=[RP]=] without [=user | ||
consent=]. This is detailed further in [[#sec-make-credential-privacy]] and [[#sec-assertion-privacy]]. A malicious [=[RP]=] | ||
thus cannot silently identify a user, even if the user has a [=public key credential=] registered and available. | ||
|
||
- [=Authenticators=] ensure that the [=credential IDs=] and [=credential public keys=] of different [=public key credentials=] are | ||
not correlatable as belonging to the same user. A pair of malicious [=[RPS]=] thus cannot correlate users between their | ||
systems without additional information, e.g., a willfully reused username or e-mail address. | ||
|
||
- [=Authenticators=] ensure that their [=attestation certificates=] are not unique enough to identify a single [=authenticator=] | ||
or a small group of [=authenticators=]. This is detailed further in [[#sec-attestation-privacy]]. A pair of malicious | ||
[=[RPS]=] thus cannot correlate users between their systems by tracking individual [=authenticators=]. | ||
|
||
Additionally, a [=public key credential=] with a [=Client-side-resident Credential Private Key=] can optionally include a [=user | ||
handle=] specified by the [=[RP]=]. The [=public key credential|credential=] can then be used to both identify and | ||
[=authentication|authenticate=] the user. This means that a privacy-conscious [=[RP]=] can allow the user to create an account | ||
without a traditional username, further improving non-correlatability between [=[RPS]=]. | ||
|
||
|
||
## Authenticator-local [=biometric recognition=] ## {#sec-biometric-privacy} | ||
|
||
[=Biometric authenticators=] perform the [=biometric recognition=] internally in the [=authenticator=] - though for [=platform | ||
authenticators=] the biometric data might also be visible to the [=client=], depending on the implementation. Biometric data is | ||
not revealed to the [=[RP]=]; it is used only locally to perform [=user verification=] authorizing the creation and | ||
[=registration=] of, or [=authentication=] using, a [=public key credential=]. A malicious [=[RP]=] therefore cannot discover the | ||
user's personal identity via biometric data, and a security breach at a [=[RP]=] cannot expose biometric data for an attacker to | ||
use for forging logins at other [=[RPS]=]. | ||
|
||
In the case where a [=[RP]=] requires [=biometric recognition=], this is achieved by the [=biometric authenticator=] setting the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. perhaps rephrase as: ... , this is performed locally by the [=biometric authenticator=] performing [=user verification=] and then signaling the result by setting the [=UV=] [=flag=] in the signed [=assertion=] response, instead of revealing the biometric data itself to the [=[RP]=]. I'm not sure about this part because there's going to be lots of RPs who "trust" webauthn assertions even though they do not verify attestations: The [=[RP]=] There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, that formulation looks very good!
That is true, and the assertion as a whole can indeed be reasonably trusted without verifying the attestation statement (since a MitM attack on it, while theoretically possible, would be extremely difficult to maintain). The RP can't trust that the authenticator provides any given level of protection for the private key, but it can trust that something on the client side has possession of a particular private key. However, this part is specifically concerned with the authenticity of the UV bit, which can only be trusted if there's a trusted attestation signature. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. agreed on most of the above, but...
well, i disagree with that -- trust is in the eye of the RP. If an RP leaves AttestationConveyancePreference defaulting to none, it's still totally their decision whether to "trust" the UV bit flag, and "how much" to trust it. Amongst RPs performing "risk based authn", "trust" is a continuum. Amongst less sophisticated long-tail RPs, even with ignoring attestation, webauthn/fido-based authn is WAY better than shared secret username/password. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, true. The point I'm trying to make is that this statement is in the context of "RP requires biometric recognition", which I would expect means a hard requirement that absolutely must be satisfied, and I would say risk-based authn falls outside that. But ok, perhaps the word "trust" is the issue here. Maybe something like one of these?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hm, it seems to me that "guaranteeing" that the value of the UV is "accurate" is multi-faceted, beyond simply the presence of verifiable attestation. Even if one has verified the attestation, retrieved the corresponding authnr metadata, verified metadata sigs, verified that the authnr metadata asserts that the authnr performs user verification, it is possible for the authnr to have non-negligible (for some definition of negligible) False Acceptance Rate (i.e., is a lousy UV impl). What the ecosystem has to (ostensibly) protect against the latter scenario are the FIDO authnr and biometric certification programs, so add "verifying that the authnr is certified (perhaps to some particular "level")" to the list of things for the RP to verify, but that still is not a 100% guarantee. Note also not all authnrs will be certified.
well, in practical terms there is some wiggle room even if one has "a hard requirement that absolutely must be satisfied" because no biometric recognition system will be perfect. See: https://drafts.fidoalliance.org/biometrics/requirements/latest/Biometrics-Requirements-v1.0-wd-20180524.html#FARReq I suspect that for simplistic low-value RPs (and possibly large RPs where user is involved in low-value interactions at that time), simply checking the assertion sig is valid and relying on UV flag value is Good Enough, whether or not the RP paid any attention to attestation. For high-value RPs (or more generally, RP where user is involved in a high-value interaction), they can perform all the above checks and assign a higher score to the value of the UV flag in their overall assessment of the state of the particular interaction. I'm not sure where we ought to document such detailed deployment considerations. And because "trust" is complex & subtle & RP-specific, I'm hesitant to make simplistic statements about it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh boy, this turned out to be a gnarly one, didn't it... :) Thanks, you are indeed right on all points. I feel like what you suggested in #899 (comment) might be the way to go in the end, and dodge the issue instead:
I would have liked to clearly point out how this is different from usual client side authentication, but that doesn't seem important enough to hold this up over if you still agree that deleting the last sentence is a reasonable way to go. I also notice that the first sentence does mention that the flag is signed over, so there's at least a hint of it still there. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
yep, fine by me, thanks.
yep. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done! |
||
[=UV=] [=flag=] in the signed [=assertion=] response, instead of revealing the biometric data itself to the [=[RP]=]. The [=[RP]=] | ||
can trust the authenticity of the [=UV=] [=flag=] as long as it trusts the security guarantees of the [=attestation certificate=] | ||
presented when the [=biometric authenticator=] was [=registration|registered=]. | ||
|
||
|
||
## Attestation Privacy ## {#sec-attestation-privacy} | ||
|
||
Attestation keys can be used to track users or link various online identities of the same user together. This can be mitigated | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #899 (comment) -- human being is fine, silly me. sorry/thx.