| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
appending ssh_err(r) manually; ok markus@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
| |
his tinderbox tests
|
|
|
|
| |
revocation list: ssh-keygen -lQf /path bz#3132; ok dtucker
|
|
|
|
| |
feedback and ok markus@
|
|
|
|
|
|
|
|
|
| |
This is populated during signature verification with additional fields
that are present in and covered by the signature. At the moment, it is
only used to record security key-specific options, especially the flags
field.
with and ok markus@
|
|
|
|
|
|
|
|
|
|
|
| |
U2F signatures.
Don't use sshsk_ecdsa_sign() directly, instead make it reachable via
sshkey_sign() like all other signature operations. This means that
we need to add a provider argument to sshkey_sign(), so most of this
change is mechanically adding that.
Suggested by / ok markus@
|
|
|
|
|
| |
include various system headers (mostly stdlib.h); include them
explicitly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and memory sidechannel attacks like Spectre, Meltdown, Rowhammer and
Rambleed. This change encrypts private keys when they are not in use
with a symmetic key that is derived from a relatively large "prekey"
consisting of random data (currently 16KB).
Attackers must recover the entire prekey with high accuracy before
they can attempt to decrypt the shielded private key, but the current
generation of attacks have bit error rates that, when applied
cumulatively to the entire prekey, make this unlikely.
Implementation-wise, keys are encrypted "shielded" when loaded and then
automatically and transparently unshielded when used for signatures or
when being saved/serialised.
Hopefully we can remove this in a few years time when computer
architecture has become less unsafe.
been in snaps for a bit already; thanks deraadt@
ok dtucker@ deraadt@
|
|
|
|
| |
using SHA256/base64 key fingerprints; ok markus@
|
|
|
|
|
| |
check that the negotiated algorithm matches the type in the
signature (only matters for RSA SHA1/SHA2 sigs). ok markus@
|
|
|
|
|
|
| |
are handled safely, and there also is no need for preallocation dances.
Future changes in this area will be less error prone.
Review and one bug found by markus
|
| |
|
|
|
|
|
| |
rather than pulling <sys/param.h> and unknown namespace pollution.
ok djm markus dtucker
|
|
|
|
|
|
|
| |
verification length was being incorrectly calculated, multiple
signatures were being incorrectly processed and a NULL dereference
that occurred when signatures were verified.
Reported by Carl Jackson
|
|
|
|
| |
ok djm@
|
|
|
|
|
| |
based on draft-rsa-dsa-sha2-256-03.txt and draft-ssh-ext-info-04.txt;
with & ok djm@
|
|
|
|
|
|
| |
codes being returned due to != having higher precedence than =.
ok deraadt@ markus@
|
| |
|
| |
|
|
|
|
| |
without scoping to a particular CA; ok markus@
|
|
|
|
| |
ok markus
|
|
|
|
| |
ok djm markus
|
| |
|
|
|
|
| |
ok djm markus
|
|
|
|
| |
feedback and ok markus
|
|
|
|
|
| |
mostly debug output tweaks, a couple of error return value changes
and some other minor stuff
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interfaces. Refactor the generic key loading API to not require
pathnames to be specified (they weren't really used).
Fixes a few other things en passant:
Makes ed25519 keys work for hostbased authentication (ssh-keysign
previously used the PEM-only routines).
Fixes key comment regression bz#2306: key pathnames were being lost as
comment fields.
ok markus@
|
|
|
|
|
|
|
| |
fingerprints. Default changes from MD5 to SHA256 and format
from hex to base64.
Feedback and ok naddy@ markus@
|
|
|
|
| |
ok markus@
|
|
|
|
| |
found using Michal Zalewski's afl fuzzer
|
|
|
|
|
|
|
|
|
|
|
| |
We would generate an invalid KRL when revoking certs by serial
number for multiple CA keys due to a section being written out
twice.
Also extend the regress test to catch this case by having it
produce a multi-CA KRL.
Reported by peter AT pean.org
|
|
|
|
|
|
|
|
|
| |
existing API is offered as a set of wrappers.
with and ok markus@
Thanks also to Ben Hawkes, David Tomaschik, Ivan Fratric, Matthew
Dempsky and Ron Bowes for a detailed review a few months ago.
|
|
|
|
|
|
|
| |
serial number ranges could be serialised to an invalid format.
Readers of a broken KRL caused by this bug will fail closed, so no
should-have-been-revoked key will be accepted.
|
|
|
|
|
| |
callers that futzing with it will futz with the actual buffer
contents
|
|
|
|
| |
ok djm dtucker
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
skip serial lookup when cert's serial number is zero
(now with 100% better comment)
|
|
|
|
| |
ok djm@ via dlg@
|
| |
|
| |
|
| |
|
| |
|