OpenBSD CVS

CVS log for src/usr.bin/ssh/sk-api.h


[BACK] Up to [local] / src / usr.bin / ssh

Request diff between arbitrary revisions


Default branch: MAIN


Revision 1.15 / (download) - annotate - [select for diffs], Wed Jul 20 03:29:14 2022 UTC (21 months, 4 weeks ago) by djm
Branch: MAIN
CVS Tags: OPENBSD_7_5_BASE, OPENBSD_7_5, OPENBSD_7_4_BASE, OPENBSD_7_4, OPENBSD_7_3_BASE, OPENBSD_7_3, OPENBSD_7_2_BASE, OPENBSD_7_2, HEAD
Changes since 1.14: +4 -2 lines
Diff to previous 1.14 (colored)

when enrolling a resident key on a security token, check 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

Revision 1.14 / (download) - annotate - [select for diffs], Tue Nov 2 22:56:40 2021 UTC (2 years, 6 months ago) by djm
Branch: MAIN
CVS Tags: OPENBSD_7_1_BASE, OPENBSD_7_1
Changes since 1.13: +3 -2 lines
Diff to previous 1.13 (colored)

Better handle FIDO keys on tokens that provide user 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

Revision 1.13 / (download) - annotate - [select for diffs], Thu Oct 28 02:54:18 2021 UTC (2 years, 6 months ago) by djm
Branch: MAIN
Changes since 1.12: +4 -2 lines
Diff to previous 1.12 (colored)

When downloading resident keys from a FIDO token, pass 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

Revision 1.12 / (download) - annotate - [select for diffs], Thu Feb 18 02:15:07 2021 UTC (3 years, 2 months ago) by djm
Branch: MAIN
CVS Tags: OPENBSD_7_0_BASE, OPENBSD_7_0, OPENBSD_6_9_BASE, OPENBSD_6_9
Changes since 1.11: +2 -2 lines
Diff to previous 1.11 (colored)

make names in function prototypes match those in definition
from https://github.com/openssh/openssh-portable/pull/225
by ZenithalHourlyRate

Revision 1.11 / (download) - annotate - [select for diffs], Wed Sep 9 03:08:01 2020 UTC (3 years, 8 months ago) by djm
Branch: MAIN
CVS Tags: OPENBSD_6_8_BASE, OPENBSD_6_8
Changes since 1.10: +4 -2 lines
Diff to previous 1.10 (colored)

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@

Revision 1.10 / (download) - annotate - [select for diffs], Thu Aug 27 01:08:19 2020 UTC (3 years, 8 months ago) by djm
Branch: MAIN
Changes since 1.9: +3 -2 lines
Diff to previous 1.9 (colored)

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

Revision 1.9 / (download) - annotate - [select for diffs], Tue Apr 28 04:02:29 2020 UTC (4 years ago) by djm
Branch: MAIN
CVS Tags: OPENBSD_6_7_BASE, OPENBSD_6_7
Changes since 1.8: +2 -2 lines
Diff to previous 1.8 (colored)

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@

Revision 1.8 / (download) - annotate - [select for diffs], Sat Jan 25 23:13:09 2020 UTC (4 years, 3 months ago) by djm
Branch: MAIN
Changes since 1.7: +2 -1 lines
Diff to previous 1.7 (colored)

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@

Revision 1.7 / (download) - annotate - [select for diffs], Mon Jan 6 02:00:46 2020 UTC (4 years, 4 months ago) by djm
Branch: MAIN
Changes since 1.6: +15 -8 lines
Diff to previous 1.6 (colored)

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@

Revision 1.6 / (download) - annotate - [select for diffs], Mon Dec 30 09:24:45 2019 UTC (4 years, 4 months ago) by djm
Branch: MAIN
Changes since 1.5: +6 -1 lines
Diff to previous 1.5 (colored)

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@

Revision 1.5 / (download) - annotate - [select for diffs], Mon Dec 30 09:23:28 2019 UTC (4 years, 4 months ago) by djm
Branch: MAIN
Changes since 1.4: +4 -4 lines
Diff to previous 1.4 (colored)

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@

Revision 1.4 / (download) - annotate - [select for diffs], Mon Dec 30 09:21:16 2019 UTC (4 years, 4 months ago) by djm
Branch: MAIN
Changes since 1.3: +12 -1 lines
Diff to previous 1.3 (colored)

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@

Revision 1.3 / (download) - annotate - [select for diffs], Mon Dec 30 09:19:52 2019 UTC (4 years, 4 months ago) by djm
Branch: MAIN
Changes since 1.2: +3 -1 lines
Diff to previous 1.2 (colored)

basic support for generating FIDO2 resident keys

"ssh-keygen -t ecdsa-sk|ed25519-sk -x resident" will generate a
device-resident key.

feedback and ok markus@

Revision 1.2 / (download) - annotate - [select for diffs], Tue Nov 12 19:32:30 2019 UTC (4 years, 6 months ago) by markus
Branch: MAIN
Changes since 1.1: +8 -4 lines
Diff to previous 1.1 (colored)

update sk-api to version 2 for ed25519 support; ok djm

Revision 1.1 / (download) - annotate - [select for diffs], Thu Oct 31 21:16:20 2019 UTC (4 years, 6 months ago) by djm
Branch: MAIN

U2F/FIDO middleware interface

Supports enrolling (generating) keys and signatures.

feedback & ok markus@

This form allows you to request diff's between any two revisions of a file. You may select a symbolic revision name using the selection box or you may type in a numeric name using the type-in text box.