Comment by comprev
5 months ago
Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.
5 months ago
Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.
Yeah, that is why you should not [always (depends on your use case)] generate it on a YubiKey.
You need to have:
- an offline master private key backup (air-gapped)
- primary YubiKey (daily use)
- backup YubiKey (locked away)
- revocation certificate (separate storage) (it is your kill-switch)
Having a second YubiKey enrolled is the standard practice.
What people do wrong is:
- They generate directly on YubiKey
- They only use one device
- They do not create a revocation certificate
- They have no offline backups
You generate your GPG keys on a secured system, load the subkeys (not the master because it is not used for daily cryptography) into the YubiKeys, and then remove the secret keys from this system where you generated the keys.
> Yeah, that is why you should not generate it on a YubiKey
No. You should ALWAYS generate on the Yubikey. That's the whole point.
Your backup is one (or more) other keys.
A lot of absolutes are being thrown around in the comments here, unfortunately. It really depends on your scenario.
Generating keys exclusively in (non-backup-able) secure hardware is great if your scenario readily supports multiple keys per server/domain you're authenticating in.
Creating an airgapped backup and loading that into a "daily driver" Yubikey marked as non-exportable can be perfectly fine if that's not the case and you don't want to notify the world every time you're adding or retiring a new Yubikey (for reasons other than key compromise).
Depends on your use case, and you will still have to generate your master key offline even if you want the subkeys generated directly on each YubiKey, which then you sign with the master key.
It is only slightly less secure if you pre-generate subkeys on an offline machine if you want identical subkeys on multiple devices (and if you want exact backups). Sometimes this is exactly what people want.
Ultimately it really depends on your use case.
BTW, please check the parent comments to which I responded.
PS. I think it would be useful for others if you elaborated on your statements (for educational purposes).
I can understand revocation for GPG, but is revocation ever used for SSH? I could understand it if SSH certificates are used, but honestly I've never encountered an org using SSH's cert system.
Well, OpenSSH has a built-in key revocation mechanism (KRL which is just SSH revocation), and there are SSH certificates (with a CA) and certificate revocation, and there is ad-hoc "revocation" by removing keys from the "authorized_keys" file.
If you use your GPG key for SSH, the servers that have your public key do not automatically know that your GPG key was revoked, and SSH authentication will proceed unless you remove the public key from the server OR the server uses an SSH CA/KRL model.
All in all, SSH supports real revocation, but it must be enforced by the server. It is different from GPG where revocation follows the key, not the server.
I have not used KRL myself, but I sort of know how it works. You can generate a new empty KRL, then add keys to revoke, and then to distribute the KRL to servers by configuring OpenSSH to use the KRL file, by adding "RevokedKeys /etc/ssh/revoked_keys.krl" to "/etc/ssh/sshd_config".
The pros of KRL is that they scale better than manual removal for multiple servers, and you can revoke entire CA ranges instead of individual keys if using SSH certificates which is recommended for large setups.
I hope I could clear some things up. Let me know if you have any questions though!
Does OpenSSH's `sshd` even support GPG key revocation? (Assuming you're talking about using the GnuPG card application of Yubikeys, since the newer "native" FIDO security key implementation of OpenSSH does not support importing existing keys to my knowledge.)
I elaborated on sshd + GPG key revocation here: https://news.ycombinator.com/item?id=46026415
Short answer is that it does not.
I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.
Do you have a good guide/video/write up on this?
I’ve been putting off remaking my GPG and SSH keys using a Yubikey.
This guide [1] mostly follows the practices the previous poster outlined.
[1] https://github.com/drduh/YubiKey-Guide
2 replies →
You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
I know the difference, thank you for your concern.
Which makes yubikey impossible to use with geographically distributed backups. You need the backup available at all times for when you want to register with any new service.
This is why you should use a device which allows exporting the seed, like e.g. multi purpose hardware crypto wallets.
This is true for passkeys/webauthn/u2f, which is why it’s trash and a completely flawed and not fit for purpose standard (of course the primary purpose is vendor lock-in, not reliable and disaster-proof authentication).
But SSH allows you to export the public key and then you can enroll it on as many hosts as you want without needing access to the private key, so the backup key can remain in a safe, ideally forever as you should never need it.
I agree that it's inconvenient in many cases, but what vendor am I being locked into, exactly? My primary hardware key can be from a completely different vendor than the backup one, so I don't quite buy the conspiracy angle.
There's also no technical obstacle preventing anyone from creating "paired" hardware authenticators that share the same internal root derivation key and can as such authenticate to all services (at least if they don't demand resident credentials) that were registered to any of the keys in the set.
The fact that these keys don't exist on the market (I believe Yubikey looked into them a while ago) more is evidence for the lack of demand, and less for the existence of a cabal, in my view.
5 replies →
Not true. If you use YubiKeys to store your GPG key, it's not a problem. You can have multiple YubiKeys with the same private key, or you can encrypt to multiple recipients.
Are you talking about SSH or a different setting?
With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.
No I got distracted by the word yubikey. Arguably not the same subject. :)
1 reply →
> You need the backup available at all times for when you want to register with any new service.
Not for SSH (at least using the OpenSSH sk implementation).
> Which makes yubikey impossible to use with geographically distributed backups.
Huh ?
You do know you can wrap a symmetric key with multiple asymmetric keys, right ?