summaryrefslogtreecommitdiffstats
path: root/usr.bin/ssh/ssh-sk.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* a bit more debugging behind #ifdef DEBUG_SKdjm2021-02-261-2/+7
|
* unbreak SK_DEBUG buildsdjm2021-02-181-3/+3
| | | | | from https://github.com/openssh/openssh-portable/pull/225 by ZenithalHourlyRate
* use the new variant log macros instead of prepending __func__ anddjm2020-10-181-45/+42
| | | | appending ssh_err(r) manually; ok markus@
* when writing an attestation blob for a FIDO key, record all the datadjm2020-09-091-14/+30
| | | | | | | | 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@
* preserve verify-required for resident FIDO keysdjm2020-08-271-2/+3
| | | | | | | | | 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
* when signing a challenge using a FIDO toke, perform the hashing in thedjm2020-04-281-12/+2
| | | | | | middleware layer rather than in ssh code. This allows middlewares that call APIs that perform the hashing implicitly (including Microsoft's AFAIK). ok markus@
* return correct error in sshsk_ed25519_sig; ok djmmarkus2020-03-061-2/+2
|
* better error message when trying to use a FIDO key function anddjm2020-02-281-1/+5
| | | | SecurityKeyProvider is empty
* Replace "security key" with "authenticator" in program messages.naddy2020-02-061-14/+12
| | | | | | | This replaces "security key" in error/usage/verbose messages and distinguishes between "authenticator" and "authenticator-hosted key". ok djm@
* changes to support FIDO attestationdjm2020-01-281-5/+5
| | | | | | | | | | | | | 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-2/+4
| | | | | | | | | | | | 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@
* Extends the SK API to accept a set of key/value options for alldjm2020-01-061-17/+104
| | | | | | | | | | | | | | | | | | 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-3/+18
| | | | | | | | | | 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@
* improve some error messages; ok markus@djm2019-12-301-11/+11
|
* SK API and sk-helper error/PIN passingdjm2019-12-301-14/+17
| | | | | | | | | | | 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-4/+112
| | | | | | | | | | 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@
* Factor out parsing of struct sk_enroll_responsedjm2019-12-301-37/+64
| | | | | | We'll reuse this for extracting resident keys from a device. feedback and ok markus@
* use ssh-sk-helper for all security key signing operationsdjm2019-12-131-2/+2
| | | | | | | | | 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@
* remove stray semicolon after closing brace of function;djm2019-11-271-3/+3
| | | | from Michael Forney
* adjust on-wire signature encoding for ecdsa-sk keys to better matchdjm2019-11-191-5/+5
| | | | | | | 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.
* add the missing WITH_OPENSSL ifdefs after the ED25519-SK addition; ok djm@naddy2019-11-181-1/+15
|
* tweak debug messagedjm2019-11-161-2/+2
|
* a little debug() in the security key interfacedjm2019-11-161-1/+8
|
* directly support U2F/FIDO2 security keys in OpenSSH by linkingdjm2019-11-141-1/+16
| | | | | | against the (previously external) USB HID middleware. The dlopen() capability still exists for alternate middlewares, e.g. for Bluetooth, NFC and test/debugging.
* fix check for sig_s; noted by qsa at qualys.commarkus2019-11-131-2/+2
|
* allow an empty attestation certificate returned by a security keydjm2019-11-121-2/+3
| | | | | | | enrollment - these are possible for tokens that only offer self- attestation. This also needs support from the middleware. ok markus@
* remove extra layer for ed25519 signature; ok djm@markus2019-11-121-38/+27
|
* check sig_r and sig_s for ssh-sk keys; ok djmmarkus2019-11-121-1/+13
|
* update sk-api to version 2 for ed25519 support; ok djmmarkus2019-11-121-7/+14
|
* implement sshsk_ed25519_assemble(); ok djmmarkus2019-11-121-4/+54
|
* implement sshsk_ed25519_inner_sig(); ok djmmarkus2019-11-121-6/+53
|
* rename sshsk_ecdsa_sign() to sshsk_sign(); ok djmmarkus2019-11-121-2/+2
|
* factor out sshsk_ecdsa_inner_sig(); ok djm@markus2019-11-121-20/+43
|
* factor out sshsk_ecdsa_assemble(); ok djm@markus2019-11-121-37/+59
|
* U2F/FIDO middleware interfacedjm2019-10-311-0/+375
Supports enrolling (generating) keys and signatures. feedback & ok markus@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.