from response
Now that all FIDO signing calls attempt first without PIN and then
fall back to trying PIN only if that attempt fails, we can remove the
hack^wtrick that removed the UV flag from the keys returned during
enroll.
By Corinna Vinschen
OpenBSD-Commit-ID: 684517608c8491503bf80cd175425f0178d91d7f
explicitly test whether the token performs built-in UV (e.g. biometric
tokens) and enable UV in that case. From Pedro Martelletto via GHPR#388
OpenBSD-Commit-ID: 007eb7e387d27cf3029ab06b88224e03eca62ccd
If no FIDO device was explictly specified, then prefer the
windows://hello FIDO device. An exception to this is when
probing resident FIDO keys, in which case hardware FIDO
devices are preferred.
probing for a FIDO resident key or not. Unused here, but will make like
easier for portable
OpenBSD-Commit-ID: 432c8ff70e270378df9dbceb9bdeaa5b43b5a832
Cygwin now comes with libfido2 1.11.0, so this workaround
isn't required anymore.
This reverts commit 242c044ab1.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
WinHello via libfido2 performs user verification by default.
However, if we stick to that, there's no way to differentiate
between keys created with or without "-O verify-required".
Set FIDO2 uv attribute explicitely to FIDO_OPT_FALSE, then check
if user verification has been requested.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Up to libfido 1.10.0, WinHello advertises "clientPin" rather
than "uv" capability. This is fixed in 1.11.0. For the time
being, workaround it here.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
it conveys useful information, such as the supplied pin being wrong.
Part of GHPR329 from Pedro Martelletto
OpenBSD-Commit-ID: c0647eb9290f793add363d81378439b273756c1b
if a credential with matching application and user ID strings already exists.
if so, prompt the user for confirmation before overwriting the credential.
patch from Pedro Martelletto via GHPR329
NB. cranks SSH_SK_VERSION_MAJOR, so any third-party FIDO middleware
implementations will need to adjust
OpenBSD-Commit-ID: e45e9f1bf2b2f32d9850669e7a8dbd64acc5fca4
of manually hashing data outselves. Saves a fair bit of code and makes life
easier for some -portable platforms.
OpenBSD-Commit-ID: 351dfaaa5ab1ee928c0e623041fca28078cff0e0
keys a little more: ask the token whether a particular key belongs to it in
cases where the token support on-token user- verification (e.g. biometrics)
rather than just assuming that it will accept it.
Will reduce spurious "Confirm user presence" notifications for key
handles that relate to FIDO keys that are not currently inserted in at
least some cases.
Motivated by bz3366; by Pedro Martelletto
OpenBSD-Commit-ID: ffac7f3215842397800e1ae2e20229671a55a63d
verification (UV) on the device itself, including biometric keys.
Query the token during key creation to determine whether it supports
on-token UV and, if so, clear the SSH_SK_USER_VERIFICATION_REQD flag
in the key so that ssh(1) doesn't automatically prompty for PIN later.
When making signatures with the key, query the token's capabilities
again and check whether the token is able (right now) to perform user-
verification without a PIN. If it is then the PIN prompt is bypassed
and user verification delegated to the token. If not (e.g. the token
is biometric capable, but no biometric are enrolled), then fall back
to user verification via the usual PIN prompt.
Work by Pedro Martelletto; ok myself and markus@
NB. cranks SSH_SK_VERSION_MAJOR
OpenBSD-Commit-ID: e318a8c258d9833a0b7eb0236cdb68b5143b2f27
back the user ID that was used when the key was created and append it to the
filename the key is written to (if it is not the default).
Avoids keys being clobbered if the user created multiple
resident keys with the same application string but different
user IDs.
feedback Pedro Martelletto; ok markus
NB. increments SSH_SK_VERSION_MAJOR
OpenBSD-Commit-ID: dbd658b5950f583106d945641a634bc6562dd3a3
prior to passing it to libfido2, which does expect a hash.
There is no effect for users who are simply generating FIDO keys using
ssh-keygen - by default we generate a random 256 bit challenge, but
people building attestation workflows around our tools should now have
a more consistent experience (esp. fewer failures when they fail to
guess the magic 32-byte challenge length requirement).
ok markus@
OpenBSD-Commit-ID: b8d5363a6a7ca3b23dc28f3ca69470472959f2b5
the data needed to verify the attestation. Previously we were missing the
"authenticator data" that is included in the signature.
spotted by Ian Haken
feedback Pedro Martelletto and Ian Haken; ok markus@
OpenBSD-Commit-ID: 8439896e63792b2db99c6065dd9a45eabbdb7e0a
When downloading a resident, verify-required key from a FIDO token,
preserve the verify-required in the private key that is written to
disk. Previously we weren't doing that because of lack of support
in the middleware API.
from Pedro Martelletto; ok markus@ and myself
OpenBSD-Commit-ID: 201c46ccdd227cddba3d64e1bdbd082afa956517
When PINs are in use and multiple FIDO tokens are attached to a host, we
cannot just blast requests at all attached tokens with the PIN specified
as this will cause the per-token PIN failure counter to increment. If
this retry counter hits the token's limit (usually 3 attempts), then the
token will lock itself and render all (web and SSH) of its keys invalid.
We don't want this.
So this reworks the key selection logic for the specific case of
multiple keys being attached. When multiple keys are attached and the
operation requires a PIN, then the user must touch the key that they
wish to use first in order to identify it.
This may require multiple touches, but only if there are multiple keys
attached AND (usually) the operation requires a PIN. The usual case of a
single key attached should be unaffected.
Work by Pedro Martelletto; ok myself and markus@
OpenBSD-Commit-ID: 637d3049ced61b7a9ee796914bbc4843d999a864
FIDO2 supports a notion of "user verification" where the user is
required to demonstrate their identity to the token before particular
operations (e.g. signing). Typically this is done by authenticating
themselves using a PIN that has been set on the token.
This adds support for generating and using user verified keys where
the verification happens via PIN (other options might be added in the
future, but none are in common use now). Practically, this adds
another key generation option "verify-required" that yields a key that
requires a PIN before each authentication.
feedback markus@ and Pedro Martelletto; ok markus@
OpenBSD-Commit-ID: 57fd461e4366f87c47502c5614ec08573e6d6a15
key.
The FIDO 2.1 Client to Authenticator Protocol introduced a "credProtect"
feature to better protect resident keys. This option allows (amone other
possibilities) requiring a PIN prior to all operations that may retrieve
the key handle.
Patch by Pedro Martelletto; ok djm and markus
OpenBSD-Commit-ID: 013bc06a577dcaa66be3913b7f183eb8cad87e73
fido_init() when SK_DEBUG was defined. Harmless with current libfido2, but
this isn't guaranteed in the future.
OpenBSD-Commit-ID: c7ea20ff2bcd98dd12015d748d3672d4f01f0864
hashing in the middleware layer rather than in ssh code. This allows
middlewares that call APIs that perform the hashing implicitly (including
Microsoft's AFAIK). ok markus@
OpenBSD-Commit-ID: c9fc8630aba26c75d5016884932f08a5a237f37d
Allow writing to disk the attestation certificate that is generated by
the FIDO token at key enrollment time. These certificates may be used
by an out-of-band workflow to prove that a particular key is held in
trustworthy hardware.
Allow passing in a challenge that will be sent to the card during
key enrollment. These are needed to build an attestation workflow
that resists replay attacks.
ok markus@
OpenBSD-Commit-ID: 457dc3c3d689ba39eed328f0817ed9b91a5f78f6
making ssh-keygen be solely responsible for printing the error message and
convertint some more common error responses from the middleware to a useful
ssherr.h status code. more detail remains visible via -v of course.
also remove indepedent copy of sk-api.h declarations in sk-usbhid.c
and just include it.
feedback & ok markus@
OpenBSD-Commit-ID: a4a8ffa870d9a3e0cfd76544bcdeef5c9fb1f1bb
for all operations. These are intended to future-proof the API a little by
making it easier to specify additional fields for without having to change
the API version for each.
At present, only two options are defined: one to explicitly specify
the device for an operation (rather than accepting the middleware's
autoselection) and another to specify the FIDO2 username that may
be used when generating a resident key. These new options may be
invoked at key generation time via ssh-keygen -O
This also implements a suggestion from Markus to avoid "int" in favour
of uint32_t for the algorithm argument in the API, to make implementation
of ssh-sk-client/helper a little easier.
feedback, fixes and ok markus@
OpenBSD-Commit-ID: 973ce11704609022ab36abbdeb6bc23c8001eabc
Define some well-known error codes in the SK API and pass
them back via ssh-sk-helper.
Use the new "wrong PIN" error code to retry PIN prompting during
ssh-keygen of resident keys.
feedback and ok markus@
OpenBSD-Commit-ID: 9663c6a2bb7a0bc8deaccc6c30d9a2983b481620
Allow passing a PIN via the SK API (API major crank) and let the
ssh-sk-helper API follow.
Also enhance the ssh-sk-helper API to support passing back an error
code instead of a complete reply. Will be used to signal "wrong PIN",
etc.
feedback and ok markus@
OpenBSD-Commit-ID: a1bd6b0a2421646919a0c139b8183ad76d28fb71
