google / OpenSK / 39790196061

97%

2.1: 97%

Build Type

push

github

Committed by web-flow

Commit Message

Accept built-in UV tokens without a PIN in MakeCredential/GetAssertion (#822)

* Accept built-in UV tokens without a PIN in MakeCredential/GetAssertion

With the fingerprint feature, getPinUvAuthTokenUsingUvWithPermissions
issues a pinUvAuthToken through built-in UV without any PIN set. But
MakeCredential and GetAssertion reject every pinUvAuthParam with
CTAP2_ERR_PIN_NOT_SET when no PIN is set (CTAP 2.0 logic), so that
token can never be used.

Platforms prefer the token path whenever pinUvAuthToken is advertised,
so an authenticator with built-in UV and no PIN fails every UV-required
request (e.g. Chrome: "operation timed out or not allowed").

Keep the 2.0 check, but only reject when no form of user verification
is configured: neither a PIN nor an enrolled built-in UV method.

* Apply the user verification check to all "protected by some form of UV" steps

Move has_user_verification to storage and use it wherever CTAP 2.1
says "protected by some form of user verification" but OpenSK only
checked for a PIN: the discoverable-credential check in MakeCredential
(makeCredUvNotRqd), authenticatorLargeBlobs set, and
authenticatorConfig.

The remaining pin_hash checks are PIN-specific by the spec: clientPin
in getInfo, the zero-length pinUvAuthParam response, setPin/changePin,
forceChangePin, and blocking built-in UV when the PIN is blocked.

* Update comments for the user verification check

CTAP2.1 does cover a pinUvAuthParam on an authenticator without any form
of user verification, and the rk check now depends on any form of user
verification, not only a PIN.

Coverage Stats

168 of 168 new or added lines in 4 files covered. (100.0%)

1 existing line in 1 file now uncovered.

14690 of 15073 relevant lines covered (97.46%)

3975.16 hits per line