6 ms·

What are the biggest advantages/improvements over generating a "classic" private/public keypair with for example a Yubikey [1]? [1] https://github.com/drduh/Yu

What are the biggest advantages/improvements over generating a "classic" private/public keypair with for example a Yubikey [1]? [1] https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide

vifon 7y ago
For starters, the "classic" approach needs a dongle with explicit support for OpenPGP. With the U2F support one could use the cheaper U2F-only ones.
HHad3 7y ago
- The administrator can enforce use of hardware-backed keys [1] - U2F Tokens cost $8-$25 and are significantly cheaper than full-blown Yubikeys - U2F Tokens do not have a key limit, which enables using a unique public key per server for privacy/anonymity [1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f#L92 https://github.com/openssh/openssh-portable/blob/master/PROT...
- eeZah7Ux 7y ago
  Importantly, there are fully open source implementations of U2F hardware tokens. On top of that, U2F tokens have no memory. This makes them more durable and make the chipset even smaller.
  - sowbug 7y ago
    They do have a device counter, incremented on every usage, to help detect cloning. It's up to the server whether to enforce the constraint that the counter increase on every usage. Unfortunately this means that the token does need a little bit of memory. I don't know whether FIDO2 has the same design.
    - zaarn 7y ago
      FIDO2 has, it's an expansion of u2f to allow for more and wider use cases.
- mtgx 7y ago
  I predict some Chinese companies will soon start to offer very cheap or free U2F keys to western companies as a "bonus" for other deals they may have. Free U2F keys! What could possibly go wrong?
- harshreality 7y ago
  > U2F Tokens do not have a key limit They must have some limit. EC Keys are roughly 32 (256 bit) or 48 (384 bit) bytes (x2 to store the public half, right?), and most of these devices don't have MB of storage afaik... I think they have security chips with like 64-256kb of secure storage. So once you get into the range of thousands of sites, wouldn't you run out of room? ETA: thanks akerl, I didn't realize that's what they (or most of them) were doing; I didn't even realize deterministically generating an EC key from a seed was efficient enough to do it quickly on a tiny embedded chip.
  - akerl_ 7y ago
    In theory, yes. In practice, the way that most U2F tokens (for example, Yubikeys) work is to storage a single device-specific secret key on the token, which never changes. Then, when “adding” a key for a site, they take the provided details from the server as inputs, along with the secret key, to derive a new, site-specific private key, which is used for U2F. That allows them to “store” an unlimited number of site keys. Note that this method isn’t mandated by the U2F spec, so it’s not guaranteed that any key which implements U2F will do so in this way. The OpenSSH protocol doc alludes to this requirement when they talk about why U2F needed a custom method for interfacing with SSH: the site’s handle needs to be provided as input to the key, so that it can re-derive the site-specific private key, and that communication channel didn’t already exist in ssh-agent.
    - tialaramex 7y ago
      Critically this isn't quite correct. The handle (IIRC the FIDO spec calls it a cookie but that doesn't matter) is NOT chosen by the relying party (in this case a SSH server you're logging into). It's chosen by the token itself during the enrollment process and given to the relying party with the other results of enrollment to be stored. The token will use local random data in addition to random data supplied by the relying party for choosing a private key (and thus in the design you describe, the handle). This is a common design choice in cryptographic systems because it means if either Alice OR Bob really used random numbers the results are truly random, things only go badly if both parties defect. In WebAuthn this means if you use your token to enroll with Google, and Facebook, and say Twitter, so long as the people who built the token did a good job it won't matter if both Google and Facebook are trying to betray you and deliberately didn't use random data, they can't attack your Twitter account this way. Edit: refer to the device as a "token" not a key for clarity
- Leace 7y ago
  > - The administrator can enforce use of hardware-backed keys [1] This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestation.html https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html https://developers.yubico.com/PGP/Attestation.html
Freak_NL 7y ago
Being able to use a standard U2F-compliant token means a much simpler setup to get things working. There is no need to setup anything on the key itself, beyond the standard new key registration procedure. Existing U2F keys used to authenticate with web services (WebAuthn) can be reused. U2F security keys are cheaper too.
akerl_ 7y ago
The principle security improvement is that it’s borderline impossible to mess up provisioning a U2F token, regardless of the technical acumen of the user, in such a way that you can successfully log in but you’ve got an insecure config. By contrast, GPG is full of footguns. To pick an arbitrary example: many guides walk you through generating the GPG key on your regular computer and then importing it to the the Yubikey, and at best there’s a note suggesting you remove the key afterwards. At worst, there’s not.
- waste_monk 7y ago
  There was a good reason for creating key material external to the token though, even though it's objectively more secure to let the token generate it. In the past(and possibly this is still the case) most sites had flawed U2F implementations, in the sense that you could only register one U2F key to an account (or rather, you could normally only pick one instance of any supported 2FA method e.g. SMS). If your U2F token was lost or damaged it would thus permenantly render your accounts inaccessible (depending on whether or not account recovery bypasses U2F), and the best practice to avoid that was to have two tokens initialised with the same key material and to keep one in a safe place at home / bank safe-deposit box / other secure location. Then, if you needed to regain control you still had a valid U2F token. As U2F gains traction more sites are implementing it properly with multi token support, which renders this method obsolete, but that's the historical reasoning.
  - akerl_ 7y ago
    I’m not sure I understand the case you’re making. The fact that many sites have horrible implementations of MFA, where you can only enroll a single U2F device, couldn’t possibly have been the “good reason for creating key material external to the token”, because creating key material external to the token isn’t a feature of mainstream U2F tokens, it’s something that has been historically supported by GPG hardware devices. Yes, those sites should implement U2F support better, but the question was about why U2F is more secure than GPG, and ~“because it’s harder to mishandle the private key during setup” is pretty solidly an accurate answer.
acdha 7y ago
Not having to support the OpenSSH / OpenSC / GPG stack is a big one for me. The built-in support shipped on MacOS just works[1], Putty-CAC just works on Windows, but the OpenSC + GPG setup is semi-stable and will randomly fail in ways which require you to stop what you're working on to kill daemons or unplug/replug the device to get it working again. I would not want to support anything involving that stack. 1. The Yubikey docs describe the pre-Sierra process — https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372 has what most people will want to use after 2016. See https://github.com/Yubico/developers.yubico.com/issues/197 https://github.com/Yubico/developers.yubico.com/issues/197.
- GhettoMaestro 7y ago
  This! Setting up a yubikey via gpg to be an agent for ssh was such a pain at least 2 years ago.
  - zchrykng 7y ago
    Still is. Just randomly fails.
  - knorker 7y ago
    The PIV/OpenSC way work absolutely perfectly for me. Even on Windows.
    - GhettoMaestro 7y ago
      Interesting. I had so many issues with the SC daemon on Mac that I eventually just gave up and reverted to keeping my local ssh key in ~/.ssh/ with a passphrase on it.

vifon 7y ago

For starters, the "classic" approach needs a dongle with explicit support for OpenPGP. With the U2F support one could use the cheaper U2F-only ones.

HHad3 7y ago

- The administrator can enforce use of hardware-backed keys [1] - U2F Tokens cost $8-$25 and are significantly cheaper than full-blown Yubikeys - U2F Tokens do not have a key limit, which enables using a unique public key per server for privacy/anonymity [1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f#L92 https://github.com/openssh/openssh-portable/blob/master/PROT...

eeZah7Ux 7y ago
Importantly, there are fully open source implementations of U2F hardware tokens. On top of that, U2F tokens have no memory. This makes them more durable and make the chipset even smaller.
- sowbug 7y ago
  They do have a device counter, incremented on every usage, to help detect cloning. It's up to the server whether to enforce the constraint that the counter increase on every usage. Unfortunately this means that the token does need a little bit of memory. I don't know whether FIDO2 has the same design.
  - zaarn 7y ago
    FIDO2 has, it's an expansion of u2f to allow for more and wider use cases.
mtgx 7y ago
I predict some Chinese companies will soon start to offer very cheap or free U2F keys to western companies as a "bonus" for other deals they may have. Free U2F keys! What could possibly go wrong?
harshreality 7y ago
> U2F Tokens do not have a key limit They must have some limit. EC Keys are roughly 32 (256 bit) or 48 (384 bit) bytes (x2 to store the public half, right?), and most of these devices don't have MB of storage afaik... I think they have security chips with like 64-256kb of secure storage. So once you get into the range of thousands of sites, wouldn't you run out of room? ETA: thanks akerl, I didn't realize that's what they (or most of them) were doing; I didn't even realize deterministically generating an EC key from a seed was efficient enough to do it quickly on a tiny embedded chip.
- akerl_ 7y ago
  In theory, yes. In practice, the way that most U2F tokens (for example, Yubikeys) work is to storage a single device-specific secret key on the token, which never changes. Then, when “adding” a key for a site, they take the provided details from the server as inputs, along with the secret key, to derive a new, site-specific private key, which is used for U2F. That allows them to “store” an unlimited number of site keys. Note that this method isn’t mandated by the U2F spec, so it’s not guaranteed that any key which implements U2F will do so in this way. The OpenSSH protocol doc alludes to this requirement when they talk about why U2F needed a custom method for interfacing with SSH: the site’s handle needs to be provided as input to the key, so that it can re-derive the site-specific private key, and that communication channel didn’t already exist in ssh-agent.
  - tialaramex 7y ago
    Critically this isn't quite correct. The handle (IIRC the FIDO spec calls it a cookie but that doesn't matter) is NOT chosen by the relying party (in this case a SSH server you're logging into). It's chosen by the token itself during the enrollment process and given to the relying party with the other results of enrollment to be stored. The token will use local random data in addition to random data supplied by the relying party for choosing a private key (and thus in the design you describe, the handle). This is a common design choice in cryptographic systems because it means if either Alice OR Bob really used random numbers the results are truly random, things only go badly if both parties defect. In WebAuthn this means if you use your token to enroll with Google, and Facebook, and say Twitter, so long as the people who built the token did a good job it won't matter if both Google and Facebook are trying to betray you and deliberately didn't use random data, they can't attack your Twitter account this way. Edit: refer to the device as a "token" not a key for clarity
Leace 7y ago
> - The administrator can enforce use of hardware-backed keys [1] This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestation.html https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html https://developers.yubico.com/PGP/Attestation.html

Freak_NL 7y ago

Being able to use a standard U2F-compliant token means a much simpler setup to get things working. There is no need to setup anything on the key itself, beyond the standard new key registration procedure. Existing U2F keys used to authenticate with web services (WebAuthn) can be reused. U2F security keys are cheaper too.

akerl_ 7y ago

The principle security improvement is that it’s borderline impossible to mess up provisioning a U2F token, regardless of the technical acumen of the user, in such a way that you can successfully log in but you’ve got an insecure config. By contrast, GPG is full of footguns. To pick an arbitrary example: many guides walk you through generating the GPG key on your regular computer and then importing it to the the Yubikey, and at best there’s a note suggesting you remove the key afterwards. At worst, there’s not.

waste_monk 7y ago
There was a good reason for creating key material external to the token though, even though it's objectively more secure to let the token generate it. In the past(and possibly this is still the case) most sites had flawed U2F implementations, in the sense that you could only register one U2F key to an account (or rather, you could normally only pick one instance of any supported 2FA method e.g. SMS). If your U2F token was lost or damaged it would thus permenantly render your accounts inaccessible (depending on whether or not account recovery bypasses U2F), and the best practice to avoid that was to have two tokens initialised with the same key material and to keep one in a safe place at home / bank safe-deposit box / other secure location. Then, if you needed to regain control you still had a valid U2F token. As U2F gains traction more sites are implementing it properly with multi token support, which renders this method obsolete, but that's the historical reasoning.
- akerl_ 7y ago
  I’m not sure I understand the case you’re making. The fact that many sites have horrible implementations of MFA, where you can only enroll a single U2F device, couldn’t possibly have been the “good reason for creating key material external to the token”, because creating key material external to the token isn’t a feature of mainstream U2F tokens, it’s something that has been historically supported by GPG hardware devices. Yes, those sites should implement U2F support better, but the question was about why U2F is more secure than GPG, and ~“because it’s harder to mishandle the private key during setup” is pretty solidly an accurate answer.

acdha 7y ago

Not having to support the OpenSSH / OpenSC / GPG stack is a big one for me. The built-in support shipped on MacOS just works[1], Putty-CAC just works on Windows, but the OpenSC + GPG setup is semi-stable and will randomly fail in ways which require you to stop what you're working on to kill daemons or unplug/replug the device to get it working again. I would not want to support anything involving that stack. 1. The Yubikey docs describe the pre-Sierra process — https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372 has what most people will want to use after 2016. See https://github.com/Yubico/developers.yubico.com/issues/197 https://github.com/Yubico/developers.yubico.com/issues/197.

GhettoMaestro 7y ago
This! Setting up a yubikey via gpg to be an agent for ssh was such a pain at least 2 years ago.
- zchrykng 7y ago
  Still is. Just randomly fails.
- knorker 7y ago
  The PIV/OpenSC way work absolutely perfectly for me. Even on Windows.
  - GhettoMaestro 7y ago
    Interesting. I had so many issues with the SC daemon on Mac that I eventually just gave up and reverted to keeping my local ssh key in ~/.ssh/ with a passphrase on it.