Gpg Backup Keys
Kathleen Denson
I've recently bought two Yubikeys Neo which I'd like to use primarily for encryption and authentification by using the smartcard feature with GnuPG. I've read a few how-to on the subject (most notably here and here) and I've managed to generate and export to the Yubikey a keyring with the 3 subkeys for signing, encrypting and authenticating. Using these, I was able en encrypt a file using my public key that I could only decrypt by pluging in the Yubikey. Great.
Now I want to duplicate this setup on the other Yubikey to act as a backup in case I lose my main device. Since gpg's "keytocard" command deletes the local keys I was only able to export the same keys to the other Yubikey by making and restoring a backup of my .gnupg directory (which doesn't seem right), and even so, when I try to decrypt my test file, gpg asks specifically for the key with some serial number and it won't decrypt with the backup key.
Is there a way to use two different Yubikeys as a backup like this? If not, what is the best way to proceed to achieve this? (meaning : keeping a backup key that I can use to decrypt my files in case I lose the main key).
found this blurb which says that theres a command you can run which will essentially tell your local gpg app to scan the new card and use that instead if things gel. so in the case of using a backup card, not the worst case to run an "init" to make it work.
The trick was to not try to export the same subkeys to the two Yubikeys (gpg doesn't like that) but to generate different subkeys. In my keyring I have 6 subkeys : 3 for the main Yubikey (Sign, Encrypt, Auth) and 3 for the backup Yubikey. I exported the corresponding private keys to the Yubikeys, which this time didn't need the hack to restore a backup of .gnupg. Finally, I encrypt my files using both public keys, so I can decrypt them with either Yubikeys :
Don't forget the exclamation mark at the end of each key id. Otherwise, for some reason, gpg will understand that for each recipient you want "some key in the same keyring" and will select the same key twice by default.
Now gpg will accept either private key to decrypt the file. In case of Yubikeys, it will ask you to plug the first one, and if you cancel, it will ask for the second one, so you can use either one. I specified the main key in the first -r so gpg directly ask for the main Yubikey and won't bother me with the backup one. To make things simpler, I aliased the whole gpg command with both keyids to yk_encrypt.
GPG is asking for the specific card because after it moves the key to the card it stores a key stub on your system, which ties that key to that card. If you delete the key from gpg (e.g. gpg --delete-secret-and-public-key ABCD1234) and the reference (One of potentially many in e.g.
I am planning to do a fresh install of ubuntu 11.10 in my system. Before that i have setuped key based ssh authentication in this machine. Is it possible to take backup of those ssh keys, so that i can use that in my new installation. Or else i must setup keybased ssh authentication again? If i can take backup, what are the files i need to copy? Can someone explain it in detail pls. Thanks in advance.
The id_rsa.pub file contains the public key used to authenticate. But there are other files to keep - all of them, really, such as known_hosts for example. The MOST IMPORTANT is id_rsa (note the lack of .pub) as this is your private key. Back up each user. For example, if you set up SSH for root, get /root/.ssh as well. And so on for as many accounts as you have for this reason.
You certainly want to backup all private and public keys. We call the machine in question home and the user user@home. Same person has an account user@remote and uses key-based login in both directions. What would happen if you loose any of the key files:
A: Many of our customers actually purchase several spares for maximum security and peace of mind. This is not a bad idea when guarding extremely critical accounts. Starting off, you should be fine with 1-2 spare keys.
A: Nope, this is not necessary. There is nothing wrong with purchasing a backup key that is a different form factor than your primary key. It will work the same as long as it is from the same YubiKey series.
First of all, before we begin, in the commands below, [email protected] should be replaced with the specific identifier of your GPG key. You can use your email address associated with the key, the long form of the key ID, or the short form.
These commands are intended to export your keys and trust level. Public and private keys are used for encryption/decryption, and the trust level determines how much you trust other keys in your keyring.
On the other hand, exporting keys and trust level, as I explained above, allows for more controlled and secure data management. This approach minimizes risks and makes the process more reliable and predictable.
Depending on the circumstances, you might not immediately realize that your backup has been stolen or lost. Exporting keys separately gives you a window to respond and revoke the keys on your own terms before they can be misused. This allows you to control when and how to revoke them, giving you time to notify contacts and take other necessary steps in a controlled manner.
If revocation certificates are readily available in the stolen backup, a malicious actor could instantly revoke your keys, causing more disruption and potentially catching you off guard. By not including revocation certificates in your backup, you minimize the potential damage if the backup is compromised.
Normally, domain users encrypt DPAPI-protected data using keys that are derived from their own passwords. However, if the user forgets their password, or if their password is administratively reset or reset from another device, the previously encrypted data can no longer be decrypted using the new keys derived from the user's new password.
When this occurs, the data can still be decrypted using the Backup keys stored on the Active Directory domain controllers. They can then be re-encrypted with the user's new password-derived key. This means that anyone who has the DPAPI Backup keys for a domain will be able to decrypt DPAPI-encrypted data for any domain user, even after the user's password is changed.
Due to the sensitive nature of these keys, it is imperative that access to these keys be protected and regarded as one of the most highly confidential pieces of information in the entire Active Directory domain. By default, access to these keys is restricted to domain administrators.
There currently is no officially supported way of changing or rotating these DPAPI backup keys on the domain controllers. In accordance with the document MS-BKRP, 3rd parties have the ability to develop an application or script that creates a new DPAPI Backup key and sets the new key to be the preferred key for the domain. However, these 3rd party solutions would be unsupported by Microsoft.
Should the DPAPI Backup keys for the domain be compromised, the recommendation is to create a new domain and migrate users to that new domain. If a malicious actor is able to gain access to the DPAPI backup keys, it's likely that they have acquired domain administrator-level access to the domain and have full access to its resources. An attacker may also install other backdoor systems in the domain with the level of access that they now have, hence the recommendation to migrate to a new domain.
Active Directory administration best practices are the defense against this scenario. When granting domain access to users, provide the minimum level of access users need. It's also critical to protect Active Directory backups with as much vigilance as you protect the domain controllers themselves.
newbie to restic, only concern is how secure when you store a hashed key in remote backup location along with all the data, is it possible to keep the key local instead(e.g. use the key locally and encrypt data, then send it to backup location)?
while scrypt is fairly safe, is it possible for people get the hash then crack it on a different more powerful machine and totally bypass the scrypt path? e.g. copy /etc/shadow to another machine and crack the password there(e.g. some bitcoin machines are good at those)
Almost all data in a restic repository is encrypted with a master key. The master key is chosen randomly when the repository is initialized. The password entered at initialization time is used (together with the Key Derivation Function scrypt) to derive a key for that password. The master key is then encrypted for the key derived from the password, the encrypted master key (together with some other data needed for scrypt) is saved to a file in the keys/ subdir in the repo.
When restic is run and the user supplies a password, restic downloads all the files in the keys subdir in the repository. For each file it then derives the password key by running scrypt with the password and the parameters from the file, and then tries to decrypt the data field. If that works, the password is correct and restic can decrypt all other content stored in the repository with the master key.
While it would be possible to store the key file not in the repository, but only on the local machine, but we decided against that to improve robustness. The risk that attackers are able to find the password needs to be balanced against users losing access to their backups because the key file is only kept locally and the SSD failed, then everything is lost.
when I init the repo(or adding more passwords later), all the key-generation, decrypt/encrypt happen at local machine correct? do they ever run on the remote machine(so others can steal it from memory if they really want it).
FYI: The situation that attackers have access to the files in the repository (e.g. because the files are saved on a shared server somewhere) is explicitly mentioned in the threat model, this is something restic is built to protect against.
64591212e2