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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
