-
Notifications
You must be signed in to change notification settings - Fork 169
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 all 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 |
---|---|---|
|
@@ -4777,6 +4777,90 @@ 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 human being or a correlation | ||
of separate identities as belonging to the same human being. 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 performed locally by the [=biometric authenticator=] | ||
perfoming [=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]=]. | ||
|
||
|
||
## 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.
nit: i suggest the term "natural person" rather than "human being"
https://en.wikipedia.org/wiki/Natural_person
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.
Shall I also add that as a non-normative definition reference?
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.
sure :)
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.
Done; I'm not sure it belongs in the bibliography, though, so I didn't add it to there.
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.
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.
Valid points. @equalsJeffH What do you think, do we revert this?
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.
oh geeze.... I'd still use natural person but just not link it to wikipedia, or sure, use human being....
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.
after grovelling in the spec on another PR, i note that we use "human" in other terms/phrases, such as human-palatable, so I'm thinking "human being" is fine. silly me.