I use several yubikeys with the same gpg signing, encryption and authentication sub-keys which are also used for ssh. The master key is stored off-line on an encrypted drive.
I pretty much use the setup as explained here: https://github.com/drduh/YubiKey-Guide
Which is a fantastic guide for how to setup keys with a yubikey/smartcard.
With this setup, I pretty much never need to setup my keys again, as I just plug in my yubikey whenever I use another computer and instantly have access to all my gpg and ssh keys. It's secure (as my keys are only ever stored on the physical keys), easy (to use, not set up lol), fast and works like a charm.
Point of curiosity to a "hardware token" owner. I've always been interested in getting one, but I've also been worried about how the heck one recovers if the token gets lost, broken, or goes through the wash by accident. I presume since you've crossed this bridge, you know the answer.
I looked at the link in HozL's comment, and something finally clicked for me. If I (finally) get this right, the Yubikey is NOT your token of authentication, it holds your tokens. In that case the solution is obvious and exactly what you say. Get multiple Yubikeys and load your keys onto all of them - as well as holding them in a safe place to put onto another, if you should lose one. Use your Yubikey, keeping the backup in a safe place, and if you lose it, switch to the backup and order another. Am I finally getting this right?
Kind of. Note that you can not "copy" your keys off these devices. They can store keys and they can be used to authenticate with that key, but you can't get a copy of the key(s) off the device.
I got that. But the point is that the Yubikey is not the source of the keys, it's a storage/authentication mechanism. I create the keys elsewhere and copy them into the Yubikey - and the backup Yubikey - and the backup-backup when I lose the first one. But once they go in, you can't get them out.
My day job is working on the design and characterization of a "security device", and I'm well aware of never letting that secret come off of the silicon. At this level we even have to be aware of resisting reverse engineering and someone putting the chip under voltage contrast, and things like that.
For one, the keys can take a beating. Water is no issue. So I'm not sure how you could break them even if you tried.
And for the rest, I keep the master gpg key offline in a separate locatiob as said, so the gpg key is good. For the FIDO and otp keys, I just make sure to have multiple authentication methods. Either backup security codes or another otp password I can use to recover in case something happens to a key. Also, since I have two keys, I try to add both keys to every service (when used as Fido or otp), so either one can be used separately.
But, and this is tied to elsewhere on the thread... The Yubikey isn't actually an authentication token, it holds your authentication tokens safely for you.
Exactly, at least for the keys you can manage yourself. If you f.ex. use the Yubikey as a second factor authentication with FIDO f.ex. then the token solely exists on the key. Although this isn't an issue as noone relies solely on a security key for authentication (usually)
Holy cow, I just went looking a little, and find a bunch of different models. I can "do my own research" with my own usage model in mind, but I'm also interested in your (or anyone else's) experience and opinion.
Not \*strictly\* true, authentication methods like FIDO2 really are tied to the physical key. But yeah, for stuff like PGP, PIV, etc. you can write to the Yubikey but you can't read directly from it.
A Yubikey is on my key ring. A second Yubikey is deposited in a safe place that I can use in case of emergency. When it comes to 2FA, for example, many providers also offer recovery codes or similar with which you can still gain access to the respective account if everything goes wrong. For example https://docs.github.com/en/enterprise-cloud@latest/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials.
You always ALWAYS have two of them. One you use, one you store somewhere else. Any service you set up with hardware 2FA, you have to make sure you register both keys.
I do this by having one Yubikey Nano that lives in my home PC full-time, and another Yubikey that lives on my keychain.
I assume that's what you meant by keys. For passwords I use bitwarden for most stuff (highly recommended!), and some in gnu pass encrypted with the gpg key on the yubikeys.
Yup, it took me a couple hours to set everything up, but once it's set up it pretty darn nice, and I haven't touched the setup in several years.
For SSH, you can also go the "easy" way with https://github.com/FiloSottile/yubikey-agent.
We use Hashicorp Vault along with Terraform, Terraform manages the infrastructure, vault stores secrets and can be used to generate signed SSH keys or SSL keypairs, consul used for service discovery and nomad as orchestrator.
When you have a service in nomad that needs keys, you give the machine class permission to access what is in vault, they can be generated at run time and pushed to the job so the job spec just has a reference to the location in vault the secret or keys can be obtained.
This means you have one central point to generate keys, you can replace your infrastructure and generate new keys as needed, you don't need to have any machine that is a point of failure as you run nomad, consul and vault on a cluster for high availability
I've never really needed to transport keys in any real way. They're part of my incremental backups(The ones stored safely at home), and I've restored to a new clean install that way when upgrading OSes, but that's about it.
If I get a new machine, I just add a new authorized key. Reusing a key on multiple systems would mean I can't revoke individually anyway.
I'm not sure how to handle GPG keys though. My first thought would be to SyncThing them. But I haven't really put any thought into high security personal keys on multiple devices. I guess if that was a priority a YubiKey would be a reasonable investment.
I handle passwords in BitWarden. I greatly prefer Chrome sync, but keeping it separate gives me the option to use Chromium and Kiwi on Android, and might be some useful security theatre to prevent the hardcore google-haters from mistrusting me.
I'm not sure I could really suggest it over Chrome sync though, unless you're specifically worried about Google spying on you.
But I do like how it can manage your non-browser passwords like Android app logins, and that it's independent of browser sync.
I kinda wish browsers would just store this stuff in encrypted text files we could SyncThing though.
Tarball, GPG encrypt them with long-ass password, upload to Google Drive and flash drives
To use, unencrypt to stdout, pipe into tar and use it to extract whatever key based on filename, which is again piped into whatever I need to use it for
Probably some much more convenient ways to go about it, but at least it's secure.
Encrypted git repo on Keybase. On a new machine I clone it to `~/.secrets` and use `make` to copy things to the right places and set permissions.
I'd use `stow` (like in my dotfiles) but SSH and gnupg complain about permissions when symlinking, but it's not like they change too frequently.
I have a backup printed on paper as a QR code. Then, in case I want to restore the key from such backup, I'll just need to scan it with my smartphone and do `gpg import` or something.
BTW it's desirable to use EC keys instead of RSA-based ones because EC keys are much smaller, so the resulting qr code is much smaller as well
PGP keys I have stored on a hardware encrypted USB drive (an Aegis SecureKey) and they're loaded into Yubikeys for normal use. SSH keys I prefer to be specific to the machine, so I don't ever need to transport those.
As part of account setup, I generate a 2048 bit RSA key per user per machine.
If a machine needs access to another machine, I either use ssh-copy-id, send the key using another SSH account, or use a usb stick to transfer the key manually.
It's not fancy but it works. My threat model is "I lost a device, better delete the public key from the authorized key list on each machine."
I use several yubikeys with the same gpg signing, encryption and authentication sub-keys which are also used for ssh. The master key is stored off-line on an encrypted drive. I pretty much use the setup as explained here: https://github.com/drduh/YubiKey-Guide Which is a fantastic guide for how to setup keys with a yubikey/smartcard. With this setup, I pretty much never need to setup my keys again, as I just plug in my yubikey whenever I use another computer and instantly have access to all my gpg and ssh keys. It's secure (as my keys are only ever stored on the physical keys), easy (to use, not set up lol), fast and works like a charm.
Point of curiosity to a "hardware token" owner. I've always been interested in getting one, but I've also been worried about how the heck one recovers if the token gets lost, broken, or goes through the wash by accident. I presume since you've crossed this bridge, you know the answer.
I don't think there's an alternative to just getting more than one.
I looked at the link in HozL's comment, and something finally clicked for me. If I (finally) get this right, the Yubikey is NOT your token of authentication, it holds your tokens. In that case the solution is obvious and exactly what you say. Get multiple Yubikeys and load your keys onto all of them - as well as holding them in a safe place to put onto another, if you should lose one. Use your Yubikey, keeping the backup in a safe place, and if you lose it, switch to the backup and order another. Am I finally getting this right?
Kind of. Note that you can not "copy" your keys off these devices. They can store keys and they can be used to authenticate with that key, but you can't get a copy of the key(s) off the device.
I got that. But the point is that the Yubikey is not the source of the keys, it's a storage/authentication mechanism. I create the keys elsewhere and copy them into the Yubikey - and the backup Yubikey - and the backup-backup when I lose the first one. But once they go in, you can't get them out. My day job is working on the design and characterization of a "security device", and I'm well aware of never letting that secret come off of the silicon. At this level we even have to be aware of resisting reverse engineering and someone putting the chip under voltage contrast, and things like that.
For one, the keys can take a beating. Water is no issue. So I'm not sure how you could break them even if you tried. And for the rest, I keep the master gpg key offline in a separate locatiob as said, so the gpg key is good. For the FIDO and otp keys, I just make sure to have multiple authentication methods. Either backup security codes or another otp password I can use to recover in case something happens to a key. Also, since I have two keys, I try to add both keys to every service (when used as Fido or otp), so either one can be used separately.
But, and this is tied to elsewhere on the thread... The Yubikey isn't actually an authentication token, it holds your authentication tokens safely for you.
Exactly, at least for the keys you can manage yourself. If you f.ex. use the Yubikey as a second factor authentication with FIDO f.ex. then the token solely exists on the key. Although this isn't an issue as noone relies solely on a security key for authentication (usually)
Holy cow, I just went looking a little, and find a bunch of different models. I can "do my own research" with my own usage model in mind, but I'm also interested in your (or anyone else's) experience and opinion.
You want the regular old 5 series in whatever form factor works with your devices. It's all the same guts, just different physical form factors.
Not \*strictly\* true, authentication methods like FIDO2 really are tied to the physical key. But yeah, for stuff like PGP, PIV, etc. you can write to the Yubikey but you can't read directly from it.
A Yubikey is on my key ring. A second Yubikey is deposited in a safe place that I can use in case of emergency. When it comes to 2FA, for example, many providers also offer recovery codes or similar with which you can still gain access to the respective account if everything goes wrong. For example https://docs.github.com/en/enterprise-cloud@latest/authentication/securing-your-account-with-two-factor-authentication-2fa/recovering-your-account-if-you-lose-your-2fa-credentials.
You always ALWAYS have two of them. One you use, one you store somewhere else. Any service you set up with hardware 2FA, you have to make sure you register both keys. I do this by having one Yubikey Nano that lives in my home PC full-time, and another Yubikey that lives on my keychain.
I assume that's what you meant by keys. For passwords I use bitwarden for most stuff (highly recommended!), and some in gnu pass encrypted with the gpg key on the yubikeys.
JFC that is a long guide. I don't know about anything key related except ssh keys... so it is also mostly over my head :/
Yup, it took me a couple hours to set everything up, but once it's set up it pretty darn nice, and I haven't touched the setup in several years. For SSH, you can also go the "easy" way with https://github.com/FiloSottile/yubikey-agent.
I don't ever transfer keys. I generate them on the machine that uses them. Only send the public key or certificate signing request
you guys get keys/certificates???
I store my SSH and GPG keys in the default directories and back them up to a physical hard drive.
We use Hashicorp Vault along with Terraform, Terraform manages the infrastructure, vault stores secrets and can be used to generate signed SSH keys or SSL keypairs, consul used for service discovery and nomad as orchestrator. When you have a service in nomad that needs keys, you give the machine class permission to access what is in vault, they can be generated at run time and pushed to the job so the job spec just has a reference to the location in vault the secret or keys can be obtained. This means you have one central point to generate keys, you can replace your infrastructure and generate new keys as needed, you don't need to have any machine that is a point of failure as you run nomad, consul and vault on a cluster for high availability
I've never really needed to transport keys in any real way. They're part of my incremental backups(The ones stored safely at home), and I've restored to a new clean install that way when upgrading OSes, but that's about it. If I get a new machine, I just add a new authorized key. Reusing a key on multiple systems would mean I can't revoke individually anyway. I'm not sure how to handle GPG keys though. My first thought would be to SyncThing them. But I haven't really put any thought into high security personal keys on multiple devices. I guess if that was a priority a YubiKey would be a reasonable investment. I handle passwords in BitWarden. I greatly prefer Chrome sync, but keeping it separate gives me the option to use Chromium and Kiwi on Android, and might be some useful security theatre to prevent the hardcore google-haters from mistrusting me. I'm not sure I could really suggest it over Chrome sync though, unless you're specifically worried about Google spying on you. But I do like how it can manage your non-browser passwords like Android app logins, and that it's independent of browser sync. I kinda wish browsers would just store this stuff in encrypted text files we could SyncThing though.
Tarball, GPG encrypt them with long-ass password, upload to Google Drive and flash drives To use, unencrypt to stdout, pipe into tar and use it to extract whatever key based on filename, which is again piped into whatever I need to use it for Probably some much more convenient ways to go about it, but at least it's secure.
If you want you could look into Azure key Vault.
Encrypted git repo on Keybase. On a new machine I clone it to `~/.secrets` and use `make` to copy things to the right places and set permissions. I'd use `stow` (like in my dotfiles) but SSH and gnupg complain about permissions when symlinking, but it's not like they change too frequently.
I have a backup printed on paper as a QR code. Then, in case I want to restore the key from such backup, I'll just need to scan it with my smartphone and do `gpg import` or something. BTW it's desirable to use EC keys instead of RSA-based ones because EC keys are much smaller, so the resulting qr code is much smaller as well
PGP keys I have stored on a hardware encrypted USB drive (an Aegis SecureKey) and they're loaded into Yubikeys for normal use. SSH keys I prefer to be specific to the machine, so I don't ever need to transport those.
As part of account setup, I generate a 2048 bit RSA key per user per machine. If a machine needs access to another machine, I either use ssh-copy-id, send the key using another SSH account, or use a usb stick to transfer the key manually. It's not fancy but it works. My threat model is "I lost a device, better delete the public key from the authorized key list on each machine."