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