Clarify meaning of UVI

[rlin1]

to make it less opaque and easier to understand

[rlin1]

new proposal: The user verification index (UVI) is a value uniquely identifying a user verification data record. The purpose of the UVI is to let a FIDO Server understand whether an authentication was authorized by the exact same biometric data as the initial key generation / makeCredential. This allows the detection and prevention of "friendly fraud".

Requirements for the UVI: Privacy preserving. The UVI may not leak any sensitive information which could be used as a correlation handle. More specifically, the UVIs used for different AppIDs must be uncorrelated, so that RP1 cannot make sense of the UVI values received by RP2. This also means that it must not be possible to derive/re-construct the biometric data from the UVI. Uniquely linked to one biometric and key. 2a: If two UVI values for one public key are identical, this MUST mean that exactly the same user verification data record was used for unlocking the key). 2b: If two values are different it MUST mean that the biometrics (or the key) are different. As a consequence of 2a, a UVI value used for one key can never be re-used for a different biometric, e.g. if UVI for the left index finger is X, then this X might not be re-used for any other finger - regardless of how often the user deletes and enrolls fingers (without irreversibly destroying the related private key).

We recommend computing the UVI as follows: UVI = SHA256(PublicKey | rawUVI), where publicKey is the related public key of the scoped credential generated by the authenticator and where rawUVI is derived from the biometric reference data such that different biometric reference data leads to different rawUVI values and identical biometric reference data for the related user lead to identical rawUVI values. It is important that the authenticator doesn’t leak the rawUVI as it is a global correlation handle.

Notes (won't go into the specs): Why not just returning an enrollment counter of the biometric (e.g. 1 for the first enrolled finger, 2 for the second one etc.)? It is not guaranteed that the user doesn’t enroll one finger twice, e.g. at position 1 and 2, violating requirement 2a (same biometric must lead to same UVI for same key). The user could enroll some fingers, then delete the first one and re-enroll the finger originally enrolled for at position 1. Violating requirement 2a (same biometric must lead to same UVI for same key). The UVI in this case would be an enrollment counter leaking some bits of entropy for correlating users. Violating requirement 1.

[vijaybh]

One issue with the above - in a lot of cases, the biometric reference data itself is not stable over time. Lots of implementations will refine the reference data after each successful identification, to track small changes in the biometric over time and reduce false rejects (e.g. as your hair grows longer or grayer, the skin on your fingers gets thinner and dryer, etc.). So in practice rawUVI would not be stable either and this would be asking to create some kind of record GUID for each biometric record. This turns out to be non-trivial to do well, because the record identifier would then be disconnected from the reference data leading to all sorts of corner cases.

[rlin1]

Just as a FYI: This UVI is already implemented in millions of UAF enabled devices. So it is obviously possible to separate the biometric reference part into a "stable part" and into incremental enhancements.

[rlin1]

What if we define rawUVI as follows: ... and where rawUVI is derived from (or uniquely linked to) the biometric reference data such that different biometric reference data leads to different rawUVI values and identical biometric reference data for the related user lead to identical rawUVI values.

The authenticator implementer can decide whether to use a stable part of the verification reference data or some GUID for it.

[rlin1]

One question: can you give some example for corner cases? Note that the GUID would have to be stable for a specific key (only). They could be re-used for different keys.

[gmandyam]

@rlin1

Thanks for putting this together. Some questions/comments:

a) "Privacy preserving. The UVI may not leak any sensitive information ...". IMO is requirement is not a "may" but a "MUST". Note that certification programs will likely take adherence to privacy guidelines such as those from IDESG [1] into account.

b) "the UVIs used for different AppIDs must be uncorrelated". I don't think we are contemplating AppID in this specification (although it could have some relevance to the intersection of Webauthn and installable apps, e.g. Apache Cordova). Recommend sticking to RP ID.

c) "If two UVI values for one public key are identical" - similar comment as b). The UVI values should be scoped to the RP ID. Two UVI values should never be identical across RP ID's even if they correspond to the same biometric. The public keys generated for a given biometric will not be identical across RP ID's as per the spec, but the UVI text should restate this fact in order to prevent confusion.

d) "We recommend computing the UVI as follows: UVI = SHA256(PublicKey | rawUVI)," Why not make this a normative requirement rather than a recommendation? It will make certification/interop more feasible, and ensure that personally-identifiable info isn't being packed into the UVI.

e) In addition, I think we should provide rules for generating rawUVI beyond "rawUVI is derived from (or uniquely linked to) the biometric reference data such that different biometric reference data leads to different rawUVI values and identical biometric reference data for the related user lead to identical rawUVI values." We should at least plan for the day when SHA256 hashes can be cracked. Providing normative guidelines on the calculation of rawUVI so that it doesn't leak linkable personally identifiable information is a possibility. One suggestion: rawUVI = RPID |( Biometric mode GUID), where (Biometric mode GUID) is never leaked from authenticator. We can also place rules around generation of a GUID to allow for cancellable biometrics, i.e. re-enrollment always results in a generation of a new GUID even if it is for the same user re-enrolling the same biometric.

[1] https://workspace.idesg.org/kws/public/download/83/IDEF-Baseline-Requirements-v1.0-FINAL-10152015.pdf&wg_abbrev=idesg_document

[vijaybh]

@rlin - Not all authenticators do dynamic update of biometric reference data, but there are a significant number that do.

Even in the absence of dynamic update, some corner cases arise. For example, a user who has enrolled a particular finger and been using it, and then decided to delete and redo the enrollment (perhaps because it is not working so well any more). The system has no way of knowing this is exactly the same finger from the biometric reference data alone (since this will be slightly different each time the enrollment is done).

Perhaps it is okay in such corner cases to fail closed - i.e. if any disruptive change happens in the reference data, the authenticator just changes the UVI instead of trying to tell whether the change was benign. I guess I'm mostly unsure about what the RP should do in this case, and how the issue gets remediated. For instance, in case of a UVI mismatch, does the RP ask the user to proof up? What happens the next time the user comes in with the "new" UVI? These are all RP questions of course, but it would be nice to think through one plausible flow.

At a higher level still, I'm still not sure how to ensure this does not become a way for the authenticator to pass 32 bytes of whatever it wants to the RP, since the client has no way to tell if the value returned by the authenticator is a UVI or say an encrypted GPS coordinate. In this regard UVM seems more tractable.

[rlin1]

Quick responses (to Giri's comments): regarding a) Agreed. Changed that in the branch. regarding b) Agreed. Changed that in the branch. regarding c) This is already stated in requirement 1: "More specifically, the UVIs used for different rpIds must be uncorrelated". Identical values are correlated. regarding d) I am not sure that this webauthn spec is the right place to mandate a specific implementation as this cannot be verified by the Web Browser, nor the calling app. But since this proposal uses a rawUVI value which could be computed in an implementation specific way, requiring this furmula doesn't effectively restrict implementations either (IMHO). For crypto agility reasons, I would just say "secure crypto hash algorithm" instead of mandating SHA256. Applicable security certification schemes will typically mandate those. regarding e) This is the part which (IMHO) is relevant for implementation flexibility. There are implementations which use fully static biometric templates are ot least some derived data that is static (see e.g. https://www.cs.bu.edu/~reyzin/fuzzy.html for details). In those cases the "derived from the biometric reference data" is feasible.
Vijay describes other implementation options in which the biometric reference data is dynamically updated and hence doesn't allow the derivation of static (i.e. stable) values. In such cases some GUID which is randomly generated but then linked to a verification reference data record could be used. This is what I mean with "(or uniquely linked to)".

[rlin1]

Response to Vijay's comments:

a) For example, a user who has enrolled a particular finger and been using it, and then decided to delete and redo the enrollment (perhaps because it is not working so well any more). Approaches like https://www.cs.bu.edu/~reyzin/fuzzy.html claim that in most (not all) cases re-enrolling the same biometric would lead to the same rawUVI. There might be some that don't, in which case it is up to the RP to decide how to handle that. (There will still be other authenticators not supporting UVI at all, so the RP needs a way to handle non-matching+missing UVIs).

b) For instance, in case of a UVI mismatch, does the RP ask the user to proof up? In most existing deployments there is still a username+password (or a user's PIN), But using FIDO is significantly more convenient. If the RP is interested in knowing whether I (or my son playing with my device) is triggering a high value transaction, they might ask be for a password/PIN if UVI doesn't match/isn't supported. In a low value transaction they might just increase some internal risk score in which it finally depends on other parameters whether additional verification measrues will be requested.

I think understanding at least one possible flow is important, I am not sure we want to add such to the web authn spec.

c) At a higher level still, I'm still not sure how to ensure this does not become a way for the authenticator to pass 32 bytes of whatever it wants to the RP I share this concern. But what's the alternative? Security certification schemes might include controls for that.

[rlin1]

see branch rolf-UVI-improvement-156 for a consolidated draft reflecting the discussion so far.

[gmandyam]

@rlin1

" I am not sure that this webauthn spec is the right place to mandate a specific implementation as this cannot be verified by the Web Browser, nor the calling app. But since this proposal uses a rawUVI value which could be computed in an implementation specific way, requiring this furmula doesn't effectively restrict implementations either (IMHO). "

The impetus (at least in part) for proposing a new def.'n of UVI was to demonstrate that UVI was not opaque data and inscrutable from the browser perspective. Assuming UVI is derived from a strong hash of values into which the browser has no insight, the UVI is for all intents and purposes opaque. This proposed definition does not change that. So IMO a viable alternative is to define a specific method for generating rawUVI. UVI opaqueness will still be an issue, but an authenticator would presumably not be able to stuff rawUVI with whatever it wants and survive scrutiny (e.g. by 3rd-party certification or perhaps legal means - see [1]).

@vijaybh "I'm still not sure how to ensure this does not become a way for the authenticator to pass 32 bytes of whatever it wants to the RP, since the client has no way to tell if the value returned by the authenticator is a UVI or say an encrypted GPS coordinate. In this regard UVM seems more tractable."

I agree that this is an issue with UVI, but we has a discussion on the list several months ago [1] and seemed to come to a consensus that an authenticator that is doing something it has claimed it would not do can result in potential action by the client vendor. Nevertheless, as long as we do not define a specific method for generating rawUVI, the authenticator could potentially overload it and claim to be in compliance with the specification.

[1] https://lists.w3.org/Archives/Public/public-webauthn/2016May/0297.html

[rlin1]

So IMO a viable alternative is to define a specific method for generating rawUVI. UVI opaqueness will still be an issue, but an authenticator would presumably not be able to stuff rawUVI with whatever it wants and survive scrutiny (e.g. by 3rd-party certification or perhaps legal means - see [1]).

1. I don't see a substantial difference in (a) specifying a requirement for computing the rawUVI (to no violate privacy etc.) and (b) specifying a concrete formula for computing the rawUVI External applications cannot verify whether an authenticator is honest about (a) or (b) (or does something else). Security certification schemes will be able to do so.
2. I am not sure we can find a way to specify rawUVI formula which is sufficiently generic to be used for all kinds of biometric modalities and implementations.
3. Given the proposed formula for UVI being UVI = HASH(publicKey, rawUVI), I don't know how any rawUVI value could be misused as a side-channel (unless HASH is cryptographically broken).

[gmandyam]

@rlin1

"External applications cannot verify whether an authenticator is honest about (a) or (b) (or does something else). Security certification schemes will be able to do so."

I don't see how security certification schemes can verify anything without knowing how the authenticator generates the UVI.

"I am not sure we can find a way to specify rawUVI formula which is sufficiently generic to be used for all kinds of biometric modalities and implementations."

Implementations that do not find the pre-registered UVI extension acceptable should be able to register their own proprietary formats when a registry is formally established by the group.

"Given the proposed formula for UVI being UVI = HASH(publicKey, rawUVI), I don't know how any rawUVI value could be misused as a side-channel (unless HASH is cryptographically broken)."

And what is to prevent an authenticator vendor from agreeing with an RP on an inband protocol and using a broken hash function so that the RP can peek into the data?

I appreciate the effort to provide a clarifying definition of UVI, but I think we are back to the original issue - UVI is inscrutable from the browser perspective and can be abused. Maybe we should stick to the original definition of UVI as it is currently in the spec (which boils down to a max 32-byte opaque payload) and add a note that UVI can be prone to misuse and therefore the user agent should only allow this extension to pass if the authenticator has achieved certification from a trusted 3rd party.

[nadalin]

I really think that verification is out of scope for our effort, if this is something FIDO wants to so that is fine but it should not be our goal.

[nadalin]

@rlin1 @selfissued is this still valid ?

[selfissued]

It's not clear to me what practical interoperable value UVI has. What are RPs expected to do when UVI matches a previous version? What are they expected to do when they don't match?

If this is already clearly explained by a publicly available FIDO UAF document, please provide a URL and the relevant section numbers.

Unless this is going to be useful and used, we should consider deleting the UVI extension and closing this issue.

[rlin1]

1) What are RPs expected to do when UVI matches a previous version? If it matches a set of previously seen UVI values that are tied to the legitimate user, the RP has strong assurance that the same user approved the action. So all RPs (including the ones that care about "friendly fraud") could accept the action.

2) What are they expected to do when they don't match? RPs that care about "friendly fraud" should be aware that it is likely a different person that has authorized the action on the device which is also used by the legitimate user.

Note: RPs can use the "user identity binding" approaches (that are also used for the initial authenticator registration) to allow users "registering" multiple UVI values.

[rlin1]

As decided on the webauthn call: close.