summaryrefslogtreecommitdiffstats
path: root/sk-usbhid.c
AgeCommit message (Collapse)Author
2023-07-18conditionalise stdint.h inclusion on HAVE_STDINT_HDamien Miller
fixes build on AIX5 at least
2023-03-28upstream: Remove compat code for OpenSSL < 1.1.*dtucker@openbsd.org
since -portable no longer supports them. OpenBSD-Commit-ID: ea2893783331947cd29a67612b4e56f818f185ff
2022-09-14upstream: sk_enroll: never drop SSH_SK_USER_VERIFICATION_REQD flagdjm@openbsd.org
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
2022-09-02upstream: sk-usbhid: fix key_lookup() on tokens with built-in UVdjm@openbsd.org
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
2022-08-19upstream: remove incorrect check that can break enrolling adjm@openbsd.org
resident key (introduced in r1.40) OpenBSD-Commit-ID: 4cab364d518470e29e624af3d3f9ffa9c92b6f01
2022-08-17on Cygwin, prefer WinHello FIDO deviceDamien Miller
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.
2022-08-17upstream: add an extra flag to sk_probe() to indicate whether we'redjm@openbsd.org
probing for a FIDO resident key or not. Unused here, but will make like easier for portable OpenBSD-Commit-ID: 432c8ff70e270378df9dbceb9bdeaa5b43b5a832
2022-08-12Revert "check_sk_options: add temporary WinHello workaround"Corinna Vinschen
Cygwin now comes with libfido2 1.11.0, so this workaround isn't required anymore. This reverts commit 242c044ab111a37aad3b0775727c36a4c5f0102c. Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
2022-08-12fido_dev_is_winhello: return 0, not "false"Corinna Vinschen
"false" is not used anywhere in OpenSSH, so return 0 like everywhere else. Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
2022-08-08Give unused param a name.Darren Tucker
Fixes builds on platforms that do have fido2 but don't have fido_dev_is_winhello.
2022-08-05sk_sign: set FIDO2 uv attribute explicitely for WinHelloCorinna Vinschen
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>
2022-08-05check_sk_options: add temporary WinHello workaroundCorinna Vinschen
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>
2022-08-05compat code for fido_dev_is_winhello()Corinna Vinschen
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
2022-07-20upstream: sk-usbhid: preserve error code returned by key_lookup()djm@openbsd.org
it conveys useful information, such as the supplied pin being wrong. Part of GHPR329 from Pedro Martelletto OpenBSD-Commit-ID: c0647eb9290f793add363d81378439b273756c1b
2022-07-20upstream: when enrolling a resident key on a security token, checkdjm@openbsd.org
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
2022-04-29upstream: Don't leak SK device. Patch from Pedro Martelletto viadtucker@openbsd.org
github PR#316. ok djm@ OpenBSD-Commit-ID: 17d11327545022e727d95fd08b213171c5a4585d
2022-02-07fix typos in previouspedro martelletto
2022-02-07compat code for fido_assert_set_clientdata()Damien Miller
2022-02-07upstream: use libfido2 1.8.0+ fido_assert_set_clientdata() insteaddjm@openbsd.org
of manually hashing data outselves. Saves a fair bit of code and makes life easier for some -portable platforms. OpenBSD-Commit-ID: 351dfaaa5ab1ee928c0e623041fca28078cff0e0
2021-12-20upstream: better error message for FIDO keys when we can't matchdjm@openbsd.org
them to a token OpenBSD-Commit-ID: 58255c2a1980088f4ed144db67d879ada2607650
2021-12-03upstream: improve the testing of credentials against inserted FIDOdjm@openbsd.org
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
2021-12-03upstream: move check_sk_options() up so we can use it earlierdjm@openbsd.org
OpenBSD-Commit-ID: 67fe98ba1c846d22035279782c4664c1865763b4
2021-11-06upstream: Many downstreams expect ssh to compile as non-C99...deraadt@openbsd.org
OpenBSD-Commit-ID: e6aa3e08bda68e5fb838fc8a49b1d2dfc38ee783
2021-11-03upstream: Better handle FIDO keys on tokens that provide userdjm@openbsd.org
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
2021-10-28upstream: When downloading resident keys from a FIDO token, passdjm@openbsd.org
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
2021-10-01fix FIDO key support for !OPENSSL_HAS_ECC caseDamien Miller
ok dtucker
2021-10-01upstream: unbreak FIDO sk-ed25519 key enrollment for OPENSSL=no builds;djm@openbsd.org
ok dtucker@ OpenBSD-Commit-ID: 6323a5241728626cbb2bf0452cf6a5bcbd7ff709
2021-05-31upstream: Hash challenge supplied by client during FIDO key enrollmentdjm@openbsd.org
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
2021-02-18upstream: make names in function prototypes match those indjm@openbsd.org
definition from https://github.com/openssh/openssh-portable/pull/225 by ZenithalHourlyRate OpenBSD-Commit-ID: 7c736307bf3f2c7cb24d6f82f244eee959485acd
2020-10-18upstream: use the new variant log macros instead of prependingdjm@openbsd.org
__func__ and appending ssh_err(r) manually; ok markus@ OpenBSD-Commit-ID: 1f14b80bcfa85414b2a1a6ff714fb5362687ace8
2020-10-03upstream: want time.h here toodjm@openbsd.org
OpenBSD-Commit-ID: fafee8f1108c64ad8b282f9a1ed5ea830d8c58a7
2020-09-09upstream: when writing an attestation blob for a FIDO key, record alldjm@openbsd.org
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
2020-09-02configure.ac: fix libfido2 back-compatpedro martelletto
- HAVE_FIDO_CRED_PROD -> HAVE_FIDO_CRED_PROT; - check for fido_dev_get_touch_begin(), so that HAVE_FIDO_DEV_GET_TOUCH_BEGIN gets defined.
2020-08-31upstream: Add RCS IDs to the few files that are missing them; fromdjm@openbsd.org
Pedro Martelletto OpenBSD-Commit-ID: 39aa37a43d0c75ec87f1659f573d3b5867e4a3b3
2020-08-27tweak back-compat for older libfido2Damien Miller
2020-08-27upstream: skip a bit more FIDO token selection logic when only adjm@openbsd.org
single token is attached. with Pedro Martelletto OpenBSD-Commit-ID: e4a324bd9814227ec1faa8cb619580e661cca9ac
2020-08-27degrade semi-gracefully when libfido2 is too oldDamien Miller
2020-08-27upstream: preserve verify-required for resident FIDO keysdjm@openbsd.org
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
2020-08-27upstream: major rework of FIDO token selection logicdjm@openbsd.org
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
2020-08-27upstream: support for user-verified FIDO keysdjm@openbsd.org
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
2020-05-27upstream: we are still aiming for pre-C99 ...deraadt@openbsd.org
OpenBSD-Commit-ID: a240fc9cbe60bc4e6c3d24d022eb4ab01fe1cb38
2020-05-27upstream: Enable credProtect extension when generating a residentdjm@openbsd.org
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
2020-05-27upstream: always call fido_init(); previous behaviour only calleddjm@openbsd.org
fido_init() when SK_DEBUG was defined. Harmless with current libfido2, but this isn't guaranteed in the future. OpenBSD-Commit-ID: c7ea20ff2bcd98dd12015d748d3672d4f01f0864
2020-05-01wrap sha2.h inclusion in #ifdef HAVE_SHA2_HDamien Miller
2020-05-01upstream: when signing a challenge using a FIDO toke, perform thedjm@openbsd.org
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
2020-01-29upstream: changes to support FIDO attestationdjm@openbsd.org
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
2020-01-26upstream: improve the error message for u2f enrollment errors bydjm@openbsd.org
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
2020-01-06upstream: missing else in check_enroll_options()djm@openbsd.org
OpenBSD-Commit-ID: e058fb918fda56ddbbf0bee910101004cec421d4
2020-01-06upstream: fix error messagedjm@openbsd.org
OpenBSD-Commit-ID: 1eb52025658eb78ea6223181e552862198d3d505
2020-01-06upstream: Extends the SK API to accept a set of key/value optionsdjm@openbsd.org
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