In part 2 of this series we walked through the thought process around your digital ID. Once that’s established, you need to protect the keys and other secrets attached to this identity, such as passwords and cryptographic keys. In this blog post I will write about my own personal approach to this with some recommendations.
Different types of secrets
There are going to be different types of secrets that you’ll need to manage. I usually break it down to three main categories:
- Passwords to access online services, e.g. email or Facebook
- Private encryption keys, e.g. PGP and SSH keys (usually RSA cryptography)
- Private keys for cryptocurrency wallets, e.g. Ether or Bitcoin (usually elliptic curve cryptography)
Before we go into more detail of how to manage the above secrets, let’s go over a general “secrets strategy” to keep things safe, making a malicious compromise difficult.
Strategy to manage secrets
Firstly, as mentioned in part 1 of this series it’s important to be clear about your own threat model. That will help you decide how much and what kind of protection you need for all your secrets. The below strategy works well for my own scenario.
A secret, for example a password or private key, needs to be very long and complicated to guess by another parties. Since humans aren’t good at remembering long and complicated things, we need come up with an easy but secure way to store these secrets. Not only do we need to store them securely, the access to this storage should ideally be protected by multiple factors.
- Secure storage for the actual secret
- First factor of something you know, like a password, that protects the secure storage
- Second factor of something you possess, like a device, that also protects the secure storage
The secure storage will differ depending on what type of secrets you manage in it. Sometimes convenience and accessibility is more important than security.
It’s important to note that the first and second factor in this strategy refers to the protection of the actual secret itself, not the service for which the secret is used. A service, like Gmail, should also be protected by two factors, for example (1) the Gmail password itself and (2) the Google Authenticator device.
A note on cryptographic keys
As mentioned earlier, there are two very common types of cryptographic keys that many people need to manage (a) PGP and SSH keys for general encryption and resource access (b) keys for cryptocurrency wallets.
Cryptographic keys usually consist of a private and public part. The private part is very important to keep secret and secure. See my non-technical explanation of how encryption works for more details.
Because these kinds of private keys usually control very sensitive and/or valuable resources, storing them conveniently on your potentially insecure personal computer or in a cloud service won’t suffice. This is where physical hardware devices comes into play. These are simple devices that are designed for a single purpose — keeping private keys secure and physically separate from insecure environments.
1. Managing passwords
Secure storage: Padlock Cloud
First factor: a master password
Second factor: one-time approval of Padlock devices, via email of your possession
For often-used web services the convenience and accessibility of a password manager that syncs across devices is important. I can highly recommend Padlock that I blogged about earlier. With an open source password manager like this you get verifiable guarantees of how your secrets are managed. The only drawback with the hosted Padlock Cloud is that if you accidentally overwrite or delete a record the hosted service won’t let you recover it. But you can easily manage this by regularly export an encrypted backup of your Padlock data.
Alternatively you can use a proprietary or hosted password manager, such as LastPass. Proprietary services will often keep regular copies of all your passwords as a backup (hopefully encrypted, but you cannot know for sure since the source code is proprietary).
2. PGP and SSH keys
Secure storage: Yubikey hardware device
First factor: a passphrase (kept in your password manager)
Second factor: physical possession of the Yubikey device
I can highly recommend the Yubikey device. It’s well-known in the industry and works with a wide range of applications and scenarios. In this particular case we will use it to manage our PGP and SSH keys.
Instead of managing two separate keys for PGP and SSH, I prefer to generate a single PGP key directly on the Yubikey itself and use an SSH agent that works with this key. By generating the key directly on the Yubikey itself you ensure that it never gets exposed to potentially insecure computers.
Backing up your Yubikey is where it gets a little bit tricky (we don’t want to expose the private key to a potentially insecure environment). The way I prefer to manage this is to simply not take a backup, and instead keep a copy of the PGP revocation certificate for your key. This way, if you lose your key you can properly revoke it and generate a new one.
Important: When you don’t have a backup of your PGP key it’s crucial that you arrange your resources with other secure recovery options. In this scenario, don’t use your PGP key to encrypt important information that you might need to recover at some point. Encrypt this kind of data with keys stored in your password manager (that you have a separate backup of).
If not having a backup of your PGP is a no-go, then I would recommend something like the Airgap live USB to generate your key in a secure environment properly detached from the rest of the world.
How to configure your Yubikey
First, follow the guide for how to generate PGP keys directly on the Yubikey device. During the setup, when asked if you want to make an off-card backup answer “no” (for reasons mentioned earlier). After the setup is done, take note of the revocation certificate, the output will look something like this:
[...] gpg: revocation certificate stored as '/Users/dixon/.gnupg/openpgp-revocs.d/123example.rev' public and secret key created and signed.
Second, in your password manager, store the contents of the above certificate as well as the PIN and the passphrase you picked during the setup.
Third, follow this guide on Github for how to change your SSH agent such that it uses your PGP key on the Yubikey device instead.
Finally as a bonus, you can also configure your Git client to sign all your commits by telling it about the PGP key on your Yubikey.
3. Cryptocurrency keys
Secure storage: Trezor hardware wallet
First factor: a PIN number (kept in your password manager)
Second factor: Physical possession of the Trezor device
I really love the simplicity of the Trezor device. In fact, it’s so easy to set it up that I don’t need to explain the basics here, simply follow the instructions that are shipped with the device. The PIN that you generate during the setup should be stored in your password manager.
Something to emphasise with hardware wallets is that you should never make a digital copy of your private key (we don’t want to expose the private key to a potentially insecure environment). But since the ability to recover from a broken or lost Trezor device is crucial to not lose your funds, you should follow their instructions and write down the private key on a physical piece of paper. To store this paper backup securely, I have bought a waterproof and fire-resistant Master Lock.
This strategy will give you a secure way to manage your most important secrets by having (a) secure storage (b) first factor to protect the storage (c) second factor to protect the storage. Remember that these factors are for protecting your secrets store. I would encourage you to also use a second factor to protect the actual authentication to your various online services.