Re: OpenSSH U2F/FIDO support in base
Ross L Richardson: > Question: Given that the private key file contains only a "key handle", > what's the significance of setting a passphrase for it? Is there enough > information in it for that to be considered a "factor" in multi-factor auth? TL;DR: In practice, yes. A U2F authenticator does not hold a single key pair. Instead it can issue numerous authentication key pairs. The handle is required so the authenticator can retrieve the relevant private key. How exactly it does this is up to the implementor. Each time a key pair is requested, an authenticator could stash the private key in an array in internal storage and return a simple index as key handle. This would allow all private key indices to be enumerated. An attacker in possession of both the authenticator and the public key could re-create the key handle by trying all private keys until finding the one matching the public key. A different approach allows supporting an unlimited number of key pairs without requiring any internal storage. The authenticator can use a device-internal secret and the key handle to rederive the private key each time a signature is requested. For instance, the key handle could contain the actual private key encrypted with the authenticator's master key. This is explicitly mentioned in the U2F spec. In such a case, possession of the authenticator alone would be worthless without the SSH private key file. I expect the latter scheme to be the norm, but I can't be certain what kind of U2F authenticators are out there. The key handle returned by the Yubico Security Key is a 64-byte blob. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: OpenSSH U2F/FIDO support in base
On Fri, Nov 15, 2019 at 08:45:23AM +1100, Damien Miller wrote: > Hi, >[...] > Please test this thoroughly - it's a big change that we want to have > stable before the next release. > > -d > Works well for me with an old (ECDSA-SK-only) Yubico Security Key. Observation: I guess it's unavoidable, but the behaviour of the "Confirm user presence" [ssh-askpass] dialog seems a little odd, insomuch as "Cancel" has the same effect as "OK" (AFAICT). Question: Given that the private key file contains only a "key handle", what's the significance of setting a passphrase for it? Is there enough information in it for that to be considered a "factor" in multi-factor auth? Thanks, Ross
Re: OpenSSH U2F/FIDO support in base
On Fri, 15 Nov 2019 08:45:23 +1100 (AEDT), Damien Miller wrote: > Please test this thoroughly - it's a big change that we want to have > stable before the next release. Tested with a Solo key. Initially it had the firmware 2.0.0 and it didn't work but updating to 3.0.0 made it work. Cheers, Daniel
Re: OpenSSH U2F/FIDO support in base
Testing as requested on amd64: OpenBSD 6.6-current (GENERIC.MP) #467: Fri Nov 15 11:40:42 MST 2019 Using: uhidev0 at uhub0 port 4 configuration 1 interface 0 "Yubico Security Key by Yubico" rev 2.00/4.27 addr 7 Auth is working great with the key plugged in. With the key missing the error reporting is somewhat suboptimal: % ssh localhost Confirm user presence for key ECDSA-SK SHA256:25FkQCOsI334w5FTpWWm/djRUVhcqVFKhzS4GPnH/FQ sign_and_send_pubkey: signing failed: unexpected internal error greg@localhost: Permission denied (publickey,keyboard-interactive). Waiting for the user to plug (one of?) the keys in would be awesome provided enough API flexibility exists for that to work. Thanks Greg -- nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0 Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
OpenSSH U2F/FIDO support in base
Hi, I just committed all the dependencies for OpenSSH security key (U2F) support to base and tweaked OpenSSH to use them directly. This means there will be no additional configuration hoops to jump through to use U2F/FIDO2 security keys. Hardware backed keys can be generated using "ssh-keygen -t ecdsa-sk" (or "ed25519-sk" if your token supports it). Many tokens require to be touched/tapped to confirm this step. You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time. So, stealing a copy of the private key file without also stealing your security key (or access to it) should not give the attacker anything. Once you have generated a key, you can use it normally - i.e. add it to an agent, copy it to your destination's authorized_keys files (assuming they are running -current too), etc. At authentication time, you will be prompted to tap your security key to confirm the signature operation - this makes theft-of-access attacks against security keys more difficult too. Please test this thoroughly - it's a big change that we want to have stable before the next release. -d
