question about pubkey and passphrase

Jochen Bern Jochen.Bern at binect.de
Tue Feb 11 20:24:01 AEDT 2020


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

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

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

(Personally, I'ld rather try fitting a server-issued challenge nonce
into the protocol than tackling the unruly beast of authenticating
timing sources ... any news from ntp's next-gen (v5) auth yet? :-S )

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4278 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20200211/6eca4be0/attachment.p7s>


More information about the openssh-unix-dev mailing list