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
webauthn is a standard for using FIDO keys in web browsers. webauthn
signatures are a slightly different format to plain FIDO signatures - this
support allows verification of these. Feedback and ok markus@
OpenBSD-Commit-ID: ab7e3a9fb5782d99d574f408614d833379e564ad
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
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
"ssh-keygen -t ecdsa-sk|ed25519-sk -x resident" will generate a
device-resident key.
feedback and ok markus@
OpenBSD-Commit-ID: 8e1b3c56a4b11d85047bd6c6c705b7eef4d58431
by Ron Frederick
document certifiate private key format
correct flags type for sk-ssh-ed25519@openssh.com keys
OpenBSD-Commit-ID: fc4e9a1ed7f9f7f9dd83e2e2c59327912e933e74
better match 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.
OpenBSD-Commit-ID: 53d88d8211f0dd02a7954d3af72017b1a79c0679
djm@openbsd.org
dtucker@openbsd.org
naddy@openbsd.org
markus@openbsd.org