summaryrefslogtreecommitdiffstats
path: root/usr.bin/ssh/sk-usbhid.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* make names in function prototypes match those in definitiondjm2021-02-181-2/+2
| | | | | from https://github.com/openssh/openssh-portable/pull/225 by ZenithalHourlyRate
* use the new variant log macros instead of prepending __func__ anddjm2020-10-181-3/+3
| | | | appending ssh_err(r) manually; ok markus@
* want time.h here toodjm2020-10-031-1/+2
|
* when writing an attestation blob for a FIDO key, record all the datadjm2020-09-091-1/+12
| | | | | | | | 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@
* Add RCS IDs to the few files that are missing them;djm2020-08-311-0/+1
| | | | from Pedro Martelletto
* skip a bit more FIDO token selection logic when only a single tokendjm2020-08-271-1/+8
| | | | | | is attached. with Pedro Martelletto
* preserve verify-required for resident FIDO keysdjm2020-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
* major rework of FIDO token selection logicdjm2020-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@
* support for user-verified FIDO keysdjm2020-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@
* we are still aiming for pre-C99 ...deraadt2020-05-131-2/+2
|
* Enable credProtect extension when generating a resident key.djm2020-05-131-0/+57
| | | | | | | | | 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
* always call fido_init(); previous behaviour only called fido_init() whendjm2020-05-131-6/+11
| | | | | SK_DEBUG was defined. Harmless with current libfido2, but this isn't guaranteed in the future.
* when signing a challenge using a FIDO toke, perform the hashing in thedjm2020-04-281-3/+32
| | | | | | middleware layer rather than in ssh code. This allows middlewares that call APIs that perform the hashing implicitly (including Microsoft's AFAIK). ok markus@
* changes to support FIDO attestationdjm2020-01-281-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@
* improve the error message for u2f enrollment errors by makingdjm2020-01-251-72/+27
| | | | | | | | | | | | 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@
* missing else in check_enroll_options()djm2020-01-061-1/+1
|
* fix error messagedjm2020-01-061-2/+1
|
* Extends the SK API to accept a set of key/value options for alldjm2020-01-061-42/+152
| | | | | | | | | | | | | | | | | | 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@
* translate and return error codes; retry on bad PINdjm2019-12-301-17/+32
| | | | | | | | | | 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@
* SK API and sk-helper error/PIN passingdjm2019-12-301-5/+5
| | | | | | | | | | | 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@
* resident keys support in SK APIdjm2019-12-301-6/+232
| | | | | | | | | | 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@
* basic support for generating FIDO2 resident keysdjm2019-12-301-2/+8
| | | | | | | "ssh-keygen -t ecdsa-sk|ed25519-sk -x resident" will generate a device-resident key. feedback and ok markus@
* add the missing WITH_OPENSSL ifdefs after the ED25519-SK addition; ok djm@naddy2019-11-181-0/+12
|
* fix typos in sk_enrollmarkus2019-11-151-5/+5
|
* remove most uses of BN_CTXdjm2019-11-151-8/+7
| | | | | We weren't following the rules re BN_CTX_start/BN_CTX_end and the places we were using it didn't benefit from its use anyway. ok dtucker@
* rewrite c99-ismderaadt2019-11-151-2/+2
|
* U2F tokens may return FIDO_ERR_USER_PRESENCE_REQUIRED when probed todjm2019-11-151-0/+4
| | | | | see if they own a key handle. Handle this case so the find_device() look can work for them. Reported by Michael Forney
* correct function name in debug messagedjm2019-11-151-1/+1
|
* directly support U2F/FIDO2 security keys in OpenSSH by linkingdjm2019-11-141-0/+692
against the (previously external) USB HID middleware. The dlopen() capability still exists for alternate middlewares, e.g. for Bluetooth, NFC and test/debugging.
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.