question about pubkey and passphrase

Damien Miller djm at mindrot.org
Wed Feb 12 08:59:28 AEDT 2020


On Tue, 11 Feb 2020, Jochen Bern wrote:

> On 02/10/2020 11:59 PM, Damien Miller wrote:
> > However, the new U2F/FIDO key types about to be released in openssh-8.2
> > do offer some features that might solve your problem. These include
> > optionally writing an "attestation certificate" that can be used to
> > prove that a key was unexportably stored in hardware, and signature-
> > time flags that indicate whether a user explicitly authorised the
> > signature (by touching the security token).
> > 
> > In the future, it will be possible to PIN-protect FIDO keys and have
> > this fact attested to in the signature too. I.e. a sshd will be able
> > to check and optionally refuse authentication by keys that are were not
> > unlocked by a PIN. I hope to get to this not long after openssh-8.2 is
> > done.
> 
> What would be the authority that the sshd would need to trust in these
> scenarios, some sorta-CA run by the token manufacturer?

Yes, the token manufacturers include a per-device attestation key that
is, in turn, signed by a manufacturer CA.

> Or would this
> require the user to present his token to a registration desk of the
> servers' admins beforehand, thus proving that the keypair going to issue
> the signatures *is* on a tamper-proof token?

The public key and the associated attestation certificate are the only
things that you need to present, not the physical key itself.

> Can't "all be in the connection", because "the client could lie" applies
> here just as well ...

Well, the attestation certificate isn't sent over the connection for
privacy reasons - we don't think users would like to disclose the vendor
and batch number of their hardware.

As for the lying part: you'd be trusting the device manufacturer's
certificate as proof that the attested key is on their hardware.

> ... oh, and which clock would the time-of-signature info be based on?

There isn't need for time of signature in this system.

-d


More information about the openssh-unix-dev mailing list