Document prevention of attacks on privacy #899
Conversation
emlun
added
type:editorial
privacy-tracker
|
I'm starting to feel like many of these more "explainer" type sections might belong better in a separate appendix. The point of them is to make the spec more accessible and easier to understand - but the spec is already gigantic, and having them inline in the spec might just make it even more intimidating. What do others think? |
|
I understand your point about "explainer" sections, but moving them out of context to a different part of the spec makes it much less likely that implementers will read them and won't make the spec any smaller. Therefore, I'd keep them in-line. |
index.bs
Outdated
| [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 physical person or a |
There was a problem hiding this comment.
physical person -> human being (replace all occurrences)
index.bs
Outdated
| 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 physical person or a | ||
| correlation of separate identities as belonging to the same physical person. Although the [=Web Authentication API=] does not use | ||
| or provide and form of global identity, the following kinds of potentially correlatable identities are used: |
index.bs
Outdated
| private key=], and thus ownership of the [=public key credential=] identified by the [=credential ID=]. They are also visible | ||
| to the [=client=] in the communication with the [=authenticator=]. | ||
|
|
||
| - The user's identities specific to each [=[RP]=], e.g. usernames, [=user handles=] and similar aliases. |
There was a problem hiding this comment.
I have no idea what "similar aliases" refers to. Maybe just say "e.g., usernames and [=user handles=]. (Also note the comma after "e.g.".
index.bs
Outdated
| - The user's biometric information, e.g., fingerprints or facial recognition data. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Add the missing comma after "[=platform authenticators=].
index.bs
Outdated
| 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. |
There was a problem hiding this comment.
A comma is always required after "e.g.". Please add it to all uses.
index.bs
Outdated
|
|
||
| - 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. |
There was a problem hiding this comment.
Add a comma between "user" and "even".
index.bs
Outdated
| 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 having the same [=managing authenticator=]. A pair of malicious [=[RPS]=] thus cannot correlate users |
There was a problem hiding this comment.
The phrase "are not correlatable as having the same [=managing authenticator=]" is awkward and hard to understand. Do you mean "are not correlatable as belonging to the same [=authenticator=]"? Or perhaps "are not correlatable as belonging to the same user"?
There was a problem hiding this comment.
Done; I went with "correlatable as belonging to the same user".
index.bs
Outdated
| 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 |
There was a problem hiding this comment.
I don't see any target in the spec that "[=client-side-resident credential private key=]" refers to. Please review the uses of "[= ... =]" in this PR and ensure that all of them refer to locations with matching locations.
There was a problem hiding this comment.
The reference did resolve successfully, but other links to it capitalize each of the (non-hyphenated) words, so I changed to that here too.
|
@selfissued Please re-review! |
|
@equalsJeffH Please review |
| [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 |
There was a problem hiding this comment.
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.
Shall I also add that as a non-normative definition reference?
There was a problem hiding this comment.
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.
- I'm nervous about using legal terms unless a lawyer has reviewed them.
- "Historically, a human being was not necessarily a natural person in some jurisdictions where slavery existed (subject of a property right) rather than a person." makes me think we'd prefer "human being" here anyway.
There was a problem hiding this comment.
Valid points. @equalsJeffH What do you think, do we revert this?
There was a problem hiding this comment.
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.
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.
index.bs
Outdated
| 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 identities are used: |
There was a problem hiding this comment.
hm, I'd tend to term these things below as "identifiers" rather than "identities" -- i.e., an identity is a collection of attributes where identifiers are among the attributes.
index.bs
Outdated
| - 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=], and thus ownership of the [=public key credential=] identified by the [=credential ID=]. They are also visible |
There was a problem hiding this comment.
suggest:
s/ ownership of / correlation with /
There was a problem hiding this comment.
It's not clear to me how that would improve this sentence - care to explain what you mean?
There was a problem hiding this comment.
well... "ownership" has connotations of physical possession. however, the public key is handed to the RP who can do with it what they will. It correlates to the cred source and the cred private key therein. such correlation is proved by verifying signatures produced by the cred priv key, using the cred pub key held by the verifier.
so to me, we're using the notion of "ownership" inappropriately here. (and in computer/internet world in general we often misuse the notion of "own")
There was a problem hiding this comment.
Ok. I think the word "correlation" makes it feel like this has something to do with the non-correlatability we talk about elsewhere, which might be confusing.
Would it perhaps be better to just remove the whole ", and thus ownership [...]" subordinate clause?
There was a problem hiding this comment.
ok, yeah wrt "correlation".
Would it perhaps be better to just remove the whole ", and thus ownership [...]" subordinate clause?
works for me, thx.
index.bs
Outdated
| 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 information, e.g., fingerprints or facial recognition data. |
There was a problem hiding this comment.
s/ biometric information / biometric characteristic(s) /
cf. [ISOBiometricVocabulary] http://standards.iso.org/ittf/PubliclyAvailableStandards/c055194_ISOIEC_2382-37_2012.zip
index.bs
Outdated
| [INFORMATIVE] | ||
|
|
||
| Although [=Credential IDs=] and [=credential public keys=] are necessarily shared with the [=[RP]=] to enable strong | ||
| authentication, the [=public key credentials=] employed in this specification are designed to be minimally identifying and never |
There was a problem hiding this comment.
suggest:
s/ the [=public key credentials=] employed in this specification / they /
s/ never / not /
index.bs
Outdated
| and not users directly. | ||
|
|
||
| - Each [=public key credential=] is strictly bound to a specific [=[RP]=], and the [=client=] ensures that its existence is never | ||
| revealed to other [=[RPS]=]. A malicious [=[RP]=] thus cannot ask the [=client=] to reveal other identities owned by the user. |
There was a problem hiding this comment.
suggest:
s/ to reveal other identities owned by the user / to reveal a user's other identities /
index.bs
Outdated
|
|
||
| [=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 only used as an additional layer of security for unlocking use of the [=authenticator=]. A |
There was a problem hiding this comment.
hm, for "it is only used as an additional layer of security for unlocking use of the [=authenticator=]", suggest:
it is used only locally to obtain [=user consent=] to create and [=registration|register=], or [=authentication|authenticate=] using, a [=public key credential=].
There was a problem hiding this comment.
Hm, I think that formulation might be inaccurate, though - biometrics are not only used to obtain consent, but also as an additional authentication factor. That may not be relevant in this section, but I wouldn't like to suggest that they're used only as a way to obtain user consent (which could be interpreted to just mean "user presence").
But I like the initial rewording "it is used only localy", at least.
There was a problem hiding this comment.
well, yeah, that formulation is dancing around the "first multi-factor" aka "first factor" (of a multi-factor authn) notions (which themselves are something else to clean up and clarify in the spec, cf. issue #462). our dfn for user consent does link off to further terms and leads to user verification.
So here's a reformulation using user verification instead:
... it is used only locally to perform [=user verification=] authorizing the creation and [=registration=] of, or [=authentication=] using, a [=public key credential=].
WDYT?
There was a problem hiding this comment.
Ok, that looks good to me.
index.bs
Outdated
| 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 only used as an additional layer of security for unlocking use of the [=authenticator=]. 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 a different [=[RP]=]. |
There was a problem hiding this comment.
suggest:
/ at a different [=[RP]=] / at other [=[RPS]=] /
index.bs
Outdated
| 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 a different [=[RP]=]. | ||
|
|
||
| In the case where a [=[RP]=] requires [=biometric recognition=], this is instead achieved by the [=biometric authenticator=] |
There was a problem hiding this comment.
hm, i'm not sure why you're using the word "instead" here? IIUC, the [=UV=] [=flag=] is set by an authnr whenever it successfully performs user verification?
There was a problem hiding this comment.
Hm, good point. What I meant was that the authenticator sets the (verifiably authentic) UV flag instead of sending the biometric data to the server, but you're right that the right hand side of that "instead" isn't clear enough.
There was a problem hiding this comment.
I reformulated this a bit, does that look better?
There was a problem hiding this comment.
I'm also considering perhaps mentioning the uvi and uvm extensions here, what do you think about that?
There was a problem hiding this comment.
I hesitate to mention those extensions here, mostly due to being unsure of whether they will be implemented (?).
index.bs
Outdated
| cannot expose biometric data for an attacker to use for forging logins at a different [=[RP]=]. | ||
|
|
||
| In the case where a [=[RP]=] requires [=biometric recognition=], this is instead achieved by the [=biometric authenticator=] | ||
| setting the [=UV=] [=flag=] in the signed [=assertion=] response. The [=[RP]=] can trust the authenticity of this bit as long as |
There was a problem hiding this comment.
yes, however, if an RP is not checking attstn, then it is "trusting" the entire contraption here, and certainly "can" do that. Am not sure how to rephrase this. Perhaps it does not really need to be said?
There was a problem hiding this comment.
I think it's worthwhile to point out how this is dfferent from the usual kind of (completely worthless) client-side authentication. And if the RP is not checking attestation, then the RP cannot trust that the UV flag is authentic, whether or not the RP chooses to act upon its value anyway. If the RP actually requires UV, then the RP MUST verify the attestation statement - otherwise that requirement is nothing more than wishful thinking.
There was a problem hiding this comment.
see thread below #899 (review) for resolution
|
@emlun Please merge |
|
There are still a few more unresolved discussion points in #899 (review). |
index.bs
Outdated
| 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.
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]=]
+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=].
There was a problem hiding this comment.
Thanks, that formulation looks very good!
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:
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.
agreed on most of the above, but...
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.
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.
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?
- The RP can verify that the UV flag is authentic if the RP trusts the biometric authenticator's attestation certificate, presented when the credential was registered.
- The UV flag is guaranteed to be accurate if the RP trusts the biometric authenticator's attestation certificate, presented when the credential was registered.
- The biometric authenticator's attestation certificate, presented when the credential was registered, can attest to the accuracy of the UV flag.
There was a problem hiding this comment.
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.
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...
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.
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:
Perhaps it does not really need to be said?
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.
you still agree that deleting the last sentence is a reasonable way to go
yep, fine by me, thanks.
the flag is signed over, so there's at least a hint of it still there.
yep.
| - 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.
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.
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?
index.bs
Outdated
| 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 a different [=[RP]=]. | ||
|
|
||
| In the case where a [=[RP]=] requires [=biometric recognition=], this is instead achieved by the [=biometric authenticator=] |
There was a problem hiding this comment.
I hesitate to mention those extensions here, mostly due to being unsure of whether they will be implemented (?).
There was a problem hiding this comment.
i think this has come out really well @emlun -- just one new comment above. I also replied in a couple of our threads from yesterday on the prior state of this.
index.bs
Outdated
|
|
||
| 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]=]. The [=[RP]=] can trust the authenticity of the [=UV=] [=flag=] as |
There was a problem hiding this comment.
so we'll delete this final sentence?
index.bs
Outdated
| [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 |
There was a problem hiding this comment.
see #899 (comment) -- human being is fine, silly me. sorry/thx.
There was a problem hiding this comment.
I think this would resolve issue 382. I'm less sure that it resolves 743 - do we need "things implementers might need to do"? More generally: wow, this is verbose. But I don't really have a problem with it. I'm going to mark it as approved, since it doesn't seem to do any harm
See discussion in #899 (comment)
This reverts commit a510bbf.
Fixes #743. Fixes #382.
#140 is related, but requires a normative requirement that authenticators make credential IDs look like opaque random data.
Preview | Diff