Backup Keypair
There will be a time when you have to move important files that need to stay private, but there are no secure methods to send this data.
What's a private key?
A private Key is used for authentication and a symmetric key exchange...đĩâđĢ Whaaaaa? This topic is beyond this article and from this point on I'm working under the assumption you have basic knowledge of SSH key pairs, GPG key pairs, signing certificates and how these relate to their public and private nature. You can read the doc I wrote on GPG key and sub-key generation here. Actually, its that post which sparked the writing of this document because of something I said in it.
If storing your key offline remember that all media fails and this key should be backed up in multiple places. If you are not testing your backups
|you have no backup.
The takeaway keep your private key private, multiple places, tested which is easier said than done in most cases. Even large corporations loose their private keys and can bullocks a whole security system embedded into millions of devices.
Where to store?
Where should you store these private keys? The simple and not helpful answer is safely and in multiple places. What could that look like? USB drive in a safe, safety deposit box on a piece of paper (not convenient but a real option), air gapped computer in your basement, encrypted on cloud storage, burned to a CD. Each of these options have their pros and cons, but the one constant is that all media fails and 0 âŠī¸ 1 bit flips are real.
How to store
The real answer is ZFS hot storage, in multiple locations, encrypted, and a failsafe in the case of your early demise.
Isn't that overkill?
How important is all your families data? Old physically scanned family photos, backed up CDs for those nostalgic playlists, every digitized home VHS tapes?
Why ZFS
ZFS when configured correctly gives you a redundant, error correcting filesystem that supports native encryption. If that wasn't good enough đ¤¯ ZFS native encryption allows you to send and store encrypted data on remote systems that do not posses your encryption keys or require them to be loaded into memory. This prevents hostile remote servers from being able to read your data even if they can mount your datasets it will just be streams of encrypted bits.
Encrypting Your Keys
When you need to encrypt
Scenario
You were asked to help a friends employer with a computer problem. When you arrive they take you to the "IT closet" and point at a new rack server that was recently installed and let you know "It comes "configured" from head office but it's not setup for auto switch". The letter that came with the server informs you to move the web proxy configuration and certificates from the old server to the new one, and restart the services. The acting manager will be present during this process, their username and password can be supplied to complete these tasks. Files can be uploaded to the new server via ftp port that is open on the new box.
ftp yup we heard that correctly, 'fingers crossed' its setup with explicit security. You are able to connect ethernet to your laptop no extra security measures, do a quick port scan and indeed port: 21 is all thats open. This would probably indicate no ZFS since SSH doesn't seem to be enabled. But whats this? Its just a huge flat network, no separation for any users... đ¤ We should test that this ftp is encrypted before we go sending private certificates.
Open the console on the old server tower, login and check for the presence of any SSH keys or SSL certificates... Not a one present (outside of the ones that need transferring) đ Quick grep over bash history shows us nothing, so we poke the /var/log/lastlog to see who's been doing maintenance. Elevate to that user su - foouser and check their history... Yup just been sending private data over ftp, no encryption. We will need to encrypt these certificates before sending them. Thankfully GPG is present on the system, and funny enough openssl too... Yet unencrypted ftp đ¤Ŗ we were so close lol.
Gather Artifacts
I checked for the web server running and looked at the running config in /etc/nginx. Certificates are stored in /etc/ssl and there are no extra certificates in the nginx directory. But there is a .htpasswd file which will need to be encrypted with the certificates. Although the nginx directory should be safe to send we should at least password protect that archive. tar doesn't support it so we can use PGP or openssl to encrypt it. At this point lets just skip using tar to archive and use gpgtar.
Answer
Create the encrypted tar archive
sudo gpgtar -c -o nginx.gpg /etc/nginx
sudo gpgtar -c -o ssl.gpg /etc/ssl
ftp those archives over to the new server and you hop onto the console for the new server. Once you look at the running processes you see the nginx service has failed to start, missing certificate files. Looks like the web server is already up just failing to start, so I don't need the whole nginx backup, just that .htaccess file and the /etc/ssl directory.
Decrypt the nginx directory to your users home to get the files you need gpgtar -d -C ./nginx-original nginx.gpg. You can see there is no /etc/ssl directory yet so just decrypt it where it goes sudo gpgtar -d -C /etc/ssl ssl.gpg.