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
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
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
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
messages.
This replaces "security key" in error/usage/verbose messages and
distinguishes between "authenticator" and "authenticator-hosted key".
ok djm@
OpenBSD-Commit-ID: 7c63800e9c340c59440a054cde9790a78f18592e
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
Adds a sk_load_resident_keys() function to the security key
API that accepts a security key provider and a PIN and returns
a list of keys.
Implement support for this in the usbhid middleware.
feedback and ok markus@
OpenBSD-Commit-ID: 67e984e4e87f4999ce447a6178c4249a9174eff0
This extracts and refactors the client interface for ssh-sk-helper
from ssh-agent and generalises it for use by the other programs.
This means that most OpenSSH tools no longer need to link against
libfido2 or directly interact with /dev/uhid*
requested by, feedback and ok markus@
OpenBSD-Commit-ID: 1abcd3aea9a7460eccfbf8ca154cdfa62f1dc93f
better match ec25519-sk keys. Discussed with markus@ and Sebastian Kinne
NB. if you are depending on security keys (already?) then make sure you
update both your clients and servers.
OpenBSD-Commit-ID: 53d88d8211f0dd02a7954d3af72017b1a79c0679
linking against the (previously external) USB HID middleware. The dlopen()
capability still exists for alternate middlewares, e.g. for Bluetooth, NFC
and test/debugging.
OpenBSD-Commit-ID: 14446cf170ac0351f0d4792ba0bca53024930069
security key enrollment - these are possible for tokens that only offer self-
attestation. This also needs support from the middleware.
ok markus@
OpenBSD-Commit-ID: 135eeeb937088ef6830a25ca0bbe678dfd2c57cc
djm@openbsd.org
Damien Miller
markus@openbsd.org
naddy@openbsd.org
Darren Tucker