W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2016

Re: [webauthn] Clarify meaning of UVI

From: Rolf Lindemann via GitHub <sysbot+gh@w3.org>
Date: Fri, 05 Aug 2016 14:42:43 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-237869041-1470408161-sysbot+gh@w3.org>
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 

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.

GitHub Notification of comment by rlin1
Please view or discuss this issue at 
using your GitHub account
Received on Friday, 5 August 2016 14:44:47 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:22 UTC