This is excellent news. I think I’ll finally be able to get rid of my functional but complicated YubiKey OpenPGP applet + gpg-agent setup, while retaining the benefits of hardware isolation and touch for user presence—and upgrading to ECDSA in the process.
More importantly, this may also be what it takes to get some of my friends, who haven’t yet made the leap to hardware token-backed SSH keys, to upgrade their security. Especially since it should work with not just the expensive YubiKey 4/5, but also cheaper U2F-only keys as well.
This is excellent news. I think I’ll finally be able to get rid of my functional but complicated YubiKey OpenPGP applet + gpg-agent setup
I would love that too, but I use my GPG hardware key (NitroKey Start, which runs the gnuk firmware) for the pass password manager, as well as signing git tags sometimes. But I agree that with the low prices of U2F keys, it may be enough to convince friends and colleagues to a hardware token. Also, they can serve as an extra factor for PAM-based logins, which is nice.
On the contrary, generating on the token is safer (if it’s implemented correctly — YubiKey had a bug in a chip once), since the key can’t be extracted from it.
I think one does not exclude the other. E.g. ESP has eFuses for storing encryption keys, which can be read-projected (only readable by the hardware encryption support): https://github.com/espressif/esptool/wiki/espefuse
There are probably more secure elements that support this mode of operation.
there is some concern that one has to “trust” Infineon, the maker of the cpu/chip that:
there is no NIST/NSA style backdoor for their generated keys
there is no way to exfiltrate or extract a private key without your knowledge (e.g. confiscated & copied by evil agent at airport security, but on-key validation doesn’t show that this happened
That said, I’m happier with an ECC yubikey than a filesystem password protected private key.
It was not possible to enable U2F keys using the existing SSH ECDSA key format because, despite U2F devices using ECDSA for signatures, the signature format differs from the plain signatures used in SSH by including some additional fields.
I noticed that, but I didn’t understand why those additional fields are there, or why it would cause a problem.
My best guess now, after seeing ClashTheBunny’s reply, is that 1) the additional fields allow for at least the signature counter, and 2) the existing signature validation mechanism doesn’t tolerate unknown, additional fields (which would be a reasonable choice, really.)
In most crypto schemes the thing that is signed is actually a digest of some more complex byte structure. That they don’t match here is not surprising. U2F for example requires adding origin (domain name) and a challenge. Even if the required data were the same the binary encoding could be different and that alone would make the signatures incompatible.
It does seem that there is attestation PROTOCOL.u2f:
U2F also offers a number of features that are attractive in the context of SSH authentication. They can be configured to require indication of “user presence” for each signature operation (typically achieved by requiring the user touch the key). They also offer an attestation mechanism at key enrollment time that can be used to prove that a given key is backed by hardware. Finally the signature format includes a monotonic signature counter that can be used (at scale) to detect concurrent use of a private key, should it be extracted from hardware.
This is excellent news. I think I’ll finally be able to get rid of my functional but complicated YubiKey OpenPGP applet + gpg-agent setup, while retaining the benefits of hardware isolation and touch for user presence—and upgrading to ECDSA in the process.
More importantly, this may also be what it takes to get some of my friends, who haven’t yet made the leap to hardware token-backed SSH keys, to upgrade their security. Especially since it should work with not just the expensive YubiKey 4/5, but also cheaper U2F-only keys as well.
This is excellent news. I think I’ll finally be able to get rid of my functional but complicated YubiKey OpenPGP applet + gpg-agent setup
I would love that too, but I use my GPG hardware key (NitroKey Start, which runs the gnuk firmware) for the
passpassword manager, as well as signing git tags sometimes. But I agree that with the low prices of U2F keys, it may be enough to convince friends and colleagues to a hardware token. Also, they can serve as an extra factor for PAM-based logins, which is nice.Who generates the key in this case - the host or the token?
Token.
Thx. I’d much more prefer to generate it on an (offline) computer.
On the contrary, generating on the token is safer (if it’s implemented correctly — YubiKey had a bug in a chip once), since the key can’t be extracted from it.
Not just once.
That’s why I think an air-gapped computer running an open source crypto implementation is better.
I think one does not exclude the other. E.g. ESP has eFuses for storing encryption keys, which can be read-projected (only readable by the hardware encryption support): https://github.com/espressif/esptool/wiki/espefuse
There are probably more secure elements that support this mode of operation.
there is some concern that one has to “trust” Infineon, the maker of the cpu/chip that:
That said, I’m happier with an ECC yubikey than a filesystem password protected private key.
Anyone know why this would be the case? I was hoping the keypair could just be presented to the server as a regular ECDSA key.
I noticed that, but I didn’t understand why those additional fields are there, or why it would cause a problem.
My best guess now, after seeing ClashTheBunny’s reply, is that 1) the additional fields allow for at least the signature counter, and 2) the existing signature validation mechanism doesn’t tolerate unknown, additional fields (which would be a reasonable choice, really.)
In most crypto schemes the thing that is signed is actually a digest of some more complex byte structure. That they don’t match here is not surprising. U2F for example requires adding origin (domain name) and a challenge. Even if the required data were the same the binary encoding could be different and that alone would make the signatures incompatible.
I get the question now.
I wonder if it is to “promise” that the secret key material is on a hardware store and not a software store?
It does seem that there is attestation PROTOCOL.u2f:
nice followup: :)