Age | Commit message (Collapse) | Author |
|
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
|
|
- 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.
|
|
Pedro Martelletto
OpenBSD-Commit-ID: 39aa37a43d0c75ec87f1659f573d3b5867e4a3b3
|
|
|
|
single token is attached.
with Pedro Martelletto
OpenBSD-Commit-ID: e4a324bd9814227ec1faa8cb619580e661cca9ac
|
|
|
|
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
|
|
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
|
|
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
|
|
OpenBSD-Commit-ID: a240fc9cbe60bc4e6c3d24d022eb4ab01fe1cb38
|
|
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
|
|
fido_init() when SK_DEBUG was defined. Harmless with current libfido2, but
this isn't guaranteed in the future.
OpenBSD-Commit-ID: c7ea20ff2bcd98dd12015d748d3672d4f01f0864
|
|
|
|
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
|
|
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
|
|
OpenBSD-Commit-ID: e058fb918fda56ddbbf0bee910101004cec421d4
|
|
OpenBSD-Commit-ID: 1eb52025658eb78ea6223181e552862198d3d505
|
|
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
|
|
"ssh-keygen -t ecdsa-sk|ed25519-sk -x resident" will generate a
device-resident key.
feedback and ok markus@
OpenBSD-Commit-ID: 8e1b3c56a4b11d85047bd6c6c705b7eef4d58431
|
|
addition; ok djm@
OpenBSD-Commit-ID: a9545e1c273e506cf70e328cbb9d0129b6d62474
|
|
OpenBSD-Commit-ID: faa9bf779e008b3e64e2eb1344d9b7d83b3c4487
|
|
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@
OpenBSD-Commit-ID: ea9ba6c0d2e6f6adfe00b309a8f41842fe12fc7a
|
|
OpenBSD-Commit-ID: d0c70cca29cfa7e6d9f7ec1d6d5dabea112499b3
|
|
probed to see if they own a key handle. Handle this case so the find_device()
look can work for them. Reported by Michael Forney
OpenBSD-Commit-ID: 2ccd5b30a6ddfe4dba228b7159bf168601bd9166
|
|
OpenBSD-Commit-ID: 2482c99d2ce448f39282493050f8a01e3ffc39ab
|
|
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
|