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