5 ms·

Nice repo. For those starting from scratch with a YubiKey I always recommend this guide: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiK

Nice repo. For those starting from scratch with a YubiKey I always recommend this guide: https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide Then they know how this stuff works and how to fix it when it breaks.

trishankdatadog 7y ago
That guide is great --- really helped me out when I started! Then I realized why no one uses GPG in practice: this stuff is way too hard even for security experts. That's why I believe in making things as easy and usable as possible w/o sacrificing security.
- tanderson92 7y ago
  But you already succeeded at sacrificing security, because there is no note about performing key generation not in an internet-connected machine, ideally a live cd / usb image boot. From the drduh guide: > It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
  - trishankdatadog 7y ago
    To the best of my knowledge, if you trust the YubiKey firmware, and assuming that it behaves correctly, the private keys are generated on the YubiKey itself, and cannot be exported.
    - tanderson92 7y ago
      This is assuming the binary you are running on your internet-connected computer is doing what you expect.
      - trishankdatadog 7y ago
        The GPG applet is inside the YubiKey and running entirely on there, to the best of my knowledge. Update: new YKs with new firmware are apparently able to provide proofs that the keys were generated on hardware. https://news.ycombinator.com/item?id=21523354 https://news.ycombinator.com/item?id=21523354
        tanderson92 7y ago
        Oh that's great, alleviates my concerns, which was like, how do you know you're even asking the yubikey to do key generation rather than a malicious actor generating a private key and placing it on the yubikey. Thanks!
        trishankdatadog 7y ago
        If you don't trust the hardware, then don't use it. I'm not sure what solution would fit your threat model, other than building your own.
        tanderson92 7y ago
        I didn't say I distrusted the hardware, I said the very opposite. I said I didn't see how, before this attestation feature, you could guarantee your computer software even asked the hardware to generate the key.
    - waldfee 7y ago
      Which means you have no backup...
      - Florin_Andrei 7y ago
        Well, you have no backup for your brain either, yet here we are.
      - trishankdatadog 7y ago
        It's trivial to make backup YubiKeys. Just takes another 5m, and storing it in a secure place. I'll make a note in our README that we do do this.
    - xorcist 7y ago
      "Trust" isn't really that binary. I trust smart cards and key fobs much more with not leaking key material than generating said keys in a safe fashion. That specific best practice might not be the most important for most people to follow, compared to other things on the list, but it is definitively a good idea and has saved me before. Random number generators on embedded devices aren't always the best.
    - Leace 7y ago
      Yes but do mind hardware bugs that affected YubiKeys such as https://magicofsecurity.com/roca-critical-vulnerability-in-infineon-security-chips/ https://magicofsecurity.com/roca-critical-vulnerability-in-i... Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.
      - trishankdatadog 7y ago
        We're aware of hardware vulns like ROCA (we used to check the exact version of the YK, now we support only the major version 5). We're taking the risk anyway because the benefits of having the private keys generated and stored entirely on the YK is entirely worth it. We're also not primarily using the YK to encrypt messages. If continuing to decrypt shared messages in the future is critical, I'd personally look into HSMs which offers key-wrapped backup.
        Boulth 7y ago
        Do you know a HSM that use key wrapping and are OpenPGP compatible? I've seen only X.509 compatible ones.
QualityReboot 7y ago
I just got a yubikey and found this guide today. It's quite good. One thing that I still haven't found a good answer for that's not mentioned in the guide: what's KDF for? The new yubikey firmware has release notes here: https://support.yubico.com/support/solutions/articles/15000027139-yubikey-5-2-3-enhancements-to-openpgp-3-4-support https://support.yubico.com/support/solutions/articles/150000... This is the bit that has me lost: > To remove the transmission and on-card storage of OpenPGP PINs in plain text, the YubiKey supports the Key Derived Function (KDF) functionality. With the KDF function enabled, the PIN is stored as a hash on the YubiKey. When entering the PIN to the OpenPGP Smart Card, the OpenPGP client will only pass the hashed value, never passing the PIN directly. KDF functionality is set on the card itself, and communicated to the client; it is transparent to the user. Should the KDF functionality not be enabled, the PIN function will work as previously. The KDF function is listed in section 4.3.2 of the OpenPGP Smart Card 3.4 spec. Can someone explain to me how KDF matters at all here? It seems like the keys are encrypted on the yubikey via pin, or at least protected in hardware via pin, and that the pin is stored on the device. KDF seems to take that plain text pin and replace it with a hashed pin. If you steal my yubikey, it looks like KDF would prevent you from... dumping the PIN? But if you could dump the pin, wouldn't you just dump the key instead? I can't seem to figure out the threat model for this feature.
- LIV2 7y ago
  I'm guessing it's to protect against MITM of the USB interface
  - QualityReboot 7y ago
    How would that help though? If you have a compromised USB interface, and you're entering your pin on that machine, you could just capture the keyboard input anyway.
    - LIV2 7y ago
      That's a good point!, it has to be for another reason. Interested to hear what it's for

trishankdatadog 7y ago

That guide is great --- really helped me out when I started! Then I realized why no one uses GPG in practice: this stuff is way too hard even for security experts. That's why I believe in making things as easy and usable as possible w/o sacrificing security.

tanderson92 7y ago
But you already succeeded at sacrificing security, because there is no note about performing key generation not in an internet-connected machine, ideally a live cd / usb image boot. From the drduh guide: > It is recommended to generate cryptographic keys and configure YubiKey from a secure operating system and using an ephemeral environment
- trishankdatadog 7y ago
  To the best of my knowledge, if you trust the YubiKey firmware, and assuming that it behaves correctly, the private keys are generated on the YubiKey itself, and cannot be exported.
  - tanderson92 7y ago
    This is assuming the binary you are running on your internet-connected computer is doing what you expect.
    - trishankdatadog 7y ago
      The GPG applet is inside the YubiKey and running entirely on there, to the best of my knowledge. Update: new YKs with new firmware are apparently able to provide proofs that the keys were generated on hardware. https://news.ycombinator.com/item?id=21523354 https://news.ycombinator.com/item?id=21523354
      - tanderson92 7y ago
        Oh that's great, alleviates my concerns, which was like, how do you know you're even asking the yubikey to do key generation rather than a malicious actor generating a private key and placing it on the yubikey. Thanks!
        trishankdatadog 7y ago
        If you don't trust the hardware, then don't use it. I'm not sure what solution would fit your threat model, other than building your own.
        tanderson92 7y ago
        I didn't say I distrusted the hardware, I said the very opposite. I said I didn't see how, before this attestation feature, you could guarantee your computer software even asked the hardware to generate the key.
  - waldfee 7y ago
    Which means you have no backup...
    - Florin_Andrei 7y ago
      Well, you have no backup for your brain either, yet here we are.
    - trishankdatadog 7y ago
      It's trivial to make backup YubiKeys. Just takes another 5m, and storing it in a secure place. I'll make a note in our README that we do do this.
  - xorcist 7y ago
    "Trust" isn't really that binary. I trust smart cards and key fobs much more with not leaking key material than generating said keys in a safe fashion. That specific best practice might not be the most important for most people to follow, compared to other things on the list, but it is definitively a good idea and has saved me before. Random number generators on embedded devices aren't always the best.
  - Leace 7y ago
    Yes but do mind hardware bugs that affected YubiKeys such as https://magicofsecurity.com/roca-critical-vulnerability-in-infineon-security-chips/ https://magicofsecurity.com/roca-critical-vulnerability-in-i... Also I'd strongly encourage generating encryption subkey in software (offline, air-gapped machine) and then copying it to Yubikeys. If you lose your Yubikey (or mistype 3 times the PIN) you wouldn't be able to decrypt your secret data.
    - trishankdatadog 7y ago
      We're aware of hardware vulns like ROCA (we used to check the exact version of the YK, now we support only the major version 5). We're taking the risk anyway because the benefits of having the private keys generated and stored entirely on the YK is entirely worth it. We're also not primarily using the YK to encrypt messages. If continuing to decrypt shared messages in the future is critical, I'd personally look into HSMs which offers key-wrapped backup.
      - Boulth 7y ago
        Do you know a HSM that use key wrapping and are OpenPGP compatible? I've seen only X.509 compatible ones.

QualityReboot 7y ago

I just got a yubikey and found this guide today. It's quite good. One thing that I still haven't found a good answer for that's not mentioned in the guide: what's KDF for? The new yubikey firmware has release notes here: https://support.yubico.com/support/solutions/articles/15000027139-yubikey-5-2-3-enhancements-to-openpgp-3-4-support https://support.yubico.com/support/solutions/articles/150000... This is the bit that has me lost: > To remove the transmission and on-card storage of OpenPGP PINs in plain text, the YubiKey supports the Key Derived Function (KDF) functionality. With the KDF function enabled, the PIN is stored as a hash on the YubiKey. When entering the PIN to the OpenPGP Smart Card, the OpenPGP client will only pass the hashed value, never passing the PIN directly. KDF functionality is set on the card itself, and communicated to the client; it is transparent to the user. Should the KDF functionality not be enabled, the PIN function will work as previously. The KDF function is listed in section 4.3.2 of the OpenPGP Smart Card 3.4 spec. Can someone explain to me how KDF matters at all here? It seems like the keys are encrypted on the yubikey via pin, or at least protected in hardware via pin, and that the pin is stored on the device. KDF seems to take that plain text pin and replace it with a hashed pin. If you steal my yubikey, it looks like KDF would prevent you from... dumping the PIN? But if you could dump the pin, wouldn't you just dump the key instead? I can't seem to figure out the threat model for this feature.

LIV2 7y ago
I'm guessing it's to protect against MITM of the USB interface
- QualityReboot 7y ago
  How would that help though? If you have a compromised USB interface, and you're entering your pin on that machine, you could just capture the keyboard input anyway.
  - LIV2 7y ago
    That's a good point!, it has to be for another reason. Interested to hear what it's for