History log of /openssh-portable/sk-usbhid.c (Results 1 – 25 of 33)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: V_8_6_P1, V_8_5_P1
# 34c5ef6e 17-Feb-2021 djm@openbsd.org

upstream: make names in function prototypes match those in

definition from https://github.com/openssh/openssh-portable/pull/225 by
ZenithalHourlyRate

OpenBSD-Commit-ID: 7c736307bf3f2c7cb24d6f82f244

upstream: make names in function prototypes match those in

definition from https://github.com/openssh/openssh-portable/pull/225 by
ZenithalHourlyRate

OpenBSD-Commit-ID: 7c736307bf3f2c7cb24d6f82f244eee959485acd

show more ...


# 816036f1 18-Oct-2020 djm@openbsd.org

upstream: use the new variant log macros instead of prepending

__func__ and appending ssh_err(r) manually; ok markus@

OpenBSD-Commit-ID: 1f14b80bcfa85414b2a1a6ff714fb5362687ace8


# e5ed753a 02-Oct-2020 djm@openbsd.org

upstream: want time.h here too

OpenBSD-Commit-ID: fafee8f1108c64ad8b282f9a1ed5ea830d8c58a7


Revision tags: V_8_4_P1
# c7677352 08-Sep-2020 djm@openbsd.org

upstream: when writing an attestation blob for a FIDO key, record all

the data needed to verify the attestation. Previously we were missing the
"authenticator data" that is included in the signature

upstream: when writing an attestation blob for a FIDO key, record all

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

show more ...


# c1c44eee 01-Sep-2020 pedro martelletto

configure.ac: fix libfido2 back-compat

- 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.


# 39e88aef 30-Aug-2020 djm@openbsd.org

upstream: Add RCS IDs to the few files that are missing them; from

Pedro Martelletto

OpenBSD-Commit-ID: 39aa37a43d0c75ec87f1659f573d3b5867e4a3b3


# ce178be0 27-Aug-2020 Damien Miller

tweak back-compat for older libfido2


# b969072c 27-Aug-2020 djm@openbsd.org

upstream: skip a bit more FIDO token selection logic when only a

single token is attached.

with Pedro Martelletto

OpenBSD-Commit-ID: e4a324bd9814227ec1faa8cb619580e661cca9ac


# bbcc858d 26-Aug-2020 Damien Miller

degrade semi-gracefully when libfido2 is too old


# b649b3da 26-Aug-2020 djm@openbsd.org

upstream: preserve verify-required for resident FIDO keys

When downloading a resident, verify-required key from a FIDO token,
preserve the verify-required in the private key that is written to
disk.

upstream: preserve verify-required for resident FIDO keys

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

show more ...


# 642e06d0 26-Aug-2020 djm@openbsd.org

upstream: major rework of FIDO token selection logic

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

upstream: major rework of FIDO token selection logic

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

show more ...


# 9b8ad938 26-Aug-2020 djm@openbsd.org

upstream: support for user-verified FIDO keys

FIDO2 supports a notion of "user verification" where the user is
required to demonstrate their identity to the token before particular
operations (e.g.

upstream: support for user-verified FIDO keys

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

show more ...


Revision tags: V_8_3_P1
# d7d753e2 13-May-2020 deraadt@openbsd.org

upstream: we are still aiming for pre-C99 ...

OpenBSD-Commit-ID: a240fc9cbe60bc4e6c3d24d022eb4ab01fe1cb38


# 2ad7b7e4 13-May-2020 djm@openbsd.org

upstream: Enable credProtect extension when generating a resident

key.

The FIDO 2.1 Client to Authenticator Protocol introduced a "credProtect"
feature to better protect resident keys. This option

upstream: Enable credProtect extension when generating a resident

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

show more ...


# 1e70dc32 13-May-2020 djm@openbsd.org

upstream: always call fido_init(); previous behaviour only called

fido_init() when SK_DEBUG was defined. Harmless with current libfido2, but
this isn't guaranteed in the future.

OpenBSD-Commit-ID:

upstream: always call fido_init(); previous behaviour only called

fido_init() when SK_DEBUG was defined. Harmless with current libfido2, but
this isn't guaranteed in the future.

OpenBSD-Commit-ID: c7ea20ff2bcd98dd12015d748d3672d4f01f0864

show more ...


# c0dfd18d 30-Apr-2020 Damien Miller

wrap sha2.h inclusion in #ifdef HAVE_SHA2_H


# 59d2de95 28-Apr-2020 djm@openbsd.org

upstream: when signing a challenge using a FIDO toke, perform the

hashing in the middleware layer rather than in ssh code. This allows
middlewares that call APIs that perform the hashing implicitly

upstream: when signing a challenge using a FIDO toke, perform the

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

show more ...


Revision tags: V_8_2_P1
# 24c0f752 28-Jan-2020 djm@openbsd.org

upstream: changes to support FIDO attestation

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-o

upstream: changes to support FIDO attestation

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

show more ...


# 59d01f1d 25-Jan-2020 djm@openbsd.org

upstream: improve the error message for u2f enrollment errors by

making ssh-keygen be solely responsible for printing the error message and
convertint some more common error responses from the middl

upstream: improve the error message for u2f enrollment errors by

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

show more ...


# 3cc60c89 05-Jan-2020 djm@openbsd.org

upstream: missing else in check_enroll_options()

OpenBSD-Commit-ID: e058fb918fda56ddbbf0bee910101004cec421d4


# ff5784e2 05-Jan-2020 djm@openbsd.org

upstream: fix error message

OpenBSD-Commit-ID: 1eb52025658eb78ea6223181e552862198d3d505


# c312ca07 05-Jan-2020 djm@openbsd.org

upstream: Extends the SK API to accept a set of key/value options

for all operations. These are intended to future-proof the API a little by
making it easier to specify additional fields for without

upstream: Extends the SK API to accept a set of key/value options

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

show more ...


# 43ce9642 30-Dec-2019 djm@openbsd.org

upstream: translate and return error codes; retry on bad PIN

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 p

upstream: translate and return error codes; retry on bad PIN

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

show more ...


# c54cd189 30-Dec-2019 djm@openbsd.org

upstream: SK API and sk-helper error/PIN passing

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 bac

upstream: SK API and sk-helper error/PIN passing

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

show more ...


# 14cea36d 30-Dec-2019 djm@openbsd.org

upstream: resident keys support in SK API

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 suppor

upstream: resident keys support in SK API

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

show more ...


12