Denis Altudov's Blog

Amazon EC2 allows you to prepay a reservation fee in exchange for much lower hourly instance rates. Savings abound.

However, there’s a little problem – if you decide to upgrade to a beefier instance, change the availability zone, or leave AWS altogether, the fee is non-refundable, and you can’t resell your reservation to someone else. So should you pre-pay or not?

I have a simple answer for you: if you’re likely to be using your Linux box for about 8.5 months or more, you should prepay for 3 years, because that’s how many months it takes for the cost of the reservation to amortize through the lower hourly rates. The same threshold for a Windows box is about 7 months.

The whole breakdown can be found in this Google Spreadsheet, which also has other data such as TCO and the 1-year reservation math.

I found that “months-to-breakeven” is a number that’s much easier to grasp than the accurate but rather dry pricing data on Amazon’s pricing page. Hopefully Amazon will add it there, or at least provide their prices as a public dataset so that I don’t need to copy-paste the relevant data together.

TL/DR.

Openssl (a payment-free, GUI-free, setup-free tool) can be used to perform asymmetric encryption on large files without hassle. Rather unexpectedly, one needs to use the SMIME command with DEM encoding to achieve the desired result.

Problem.

A sysadmin wants to perform his duty[1] to encrypt the off-site backups in his care, and he wishes for a solution which is reliable and easy to use. In particular:

1. Resilient against hackers.
2. Resilient against accidental leaks and human errors, even if leaks are partial. People make mistakes.
3. Resilient against key loss, which equates data loss and obviously defeats the purpose of doing the backup.
4. No messy software to install on the server. Ideally, that would be just an extra line in the backup script and maybe a binary which can be simply copied during deployment.
5. No configuration hassles on per-server basis. Obviously, no GUIs to click through for each machine. Ideally, no configuration at all, so scripts can be simply copied directly form the source control to a bare machine.
6. It shouldn’t cost and an arm and a leg.
7. The data formats should not become obsolete and unsupported.

The most simple, obvious, and wrong solution.

Symmetric encryption is easy to use – the user comes up with the “symmetric key”, generally a text pass-phrase[2], and that key is then used to both encrypt the data during backups and decrypt it during restore. Popular free tools as 7-Zip or Openssl make it easy to encrypt backups, and then to decrypt them back (optionally compressing them as well):

7za a myfile.7z myfile.bkp -pPassPhrase
7za e myfile.7z -pPassPhrase

openssl enc -aes-256-cbc -salt -in myfile.bkp -out myfile.bkp.enc -pass pass:PassPhrase
openssl enc -d -aes-256-cbc -in myfile.bkp.enc -out myfile.bkp.unenc -pass pass:PassPhrase

And yet it’s the wrong approach. The problem with symmetric encryption is in its very definition – the same key that is used to encrypt can be used to decrypt.

• If the key is stored in the source of the script, a source code leak will automatically compromise all backups taken previously.
• If the key is not stored in the source of the script it has to be provisioned when the server is being setup, hence no simple copy-deployment is possible. Either a manual intervention is required or a separate key-management procedure must be set up and followed diligently.
• If a machine that is doing periodic backups of itself is compromised, not only that machine’s current data set is compromised, which is generally inevitable[3], but many other backups are compromised too – past backups of the data assumed to be long gone made on the same machine, and all backups made on other machines with the same key.
• To partially mitigate the previous problem different keys could be used for different servers and during different time periods, but that will lead to explosion in the number of keys which need to be remembered and correctly applied in order to restore the backups. A key-management database will become inevitable at this point.

The right solution.

Asymmetric encryption is a much better alternative for the backup encryption problem – the encryption key is split in two parts, and one part can only be used to encrypt the data, while the other can also decrypt it. The latter is called “private key”, while the former is known as “public key” – there is no risk in exposing it, and so one doesn’t need to worry about any of the problems mentioned in the previous chapter. One would normally be restoring the backups several orders of magnitude less frequently than creating them, and so separating keys needed to encrypt and decrypt the data offers substantial improvement in security and manageability.

The easiest way this author found to implement such solution in practice is to use a free and open-source tool called Openssl. Many systems already have it installed, and if not, the binary can be copied without any installation. [4]

The first step is to generate the private and public keys [5]. This only needs to be done once.

openssl req -x509 -nodes -days 100000 -newkey rsa:2048 -keyout MyCompanyBackupsPRIVATE.pem -out MyCompanyBackupsPublicCert.pem -subj ‘/’

The private key is placed into the file MyCompanyBackupsPRIVATE.pem, and the public key is in MyCompanyBackupsPublicCert.pem. The two keys can now be used to encrypt the valuable data:

openssl smime -encrypt -aes256 -in ImportantFile.bkp -binary -outform DEM -out ImportantFile.bkp.openssl_smime_dem MyCompanyBackupsPublicCert.pem

and to decrypt it:

openssl smime -decrypt -in ImportantFile.bkp.openssl_smime_dem -binary -inform DEM -inkey MyCompanyBackupsPRIVATE.pem -out ImportantFile.bkp.decrypted

That is all there is to know – the three simple commands, and the fact that the private key should be stored in a safe place until a backup needs to be restored.

Closing remarks.

A script implementing such scheme would do well to link back to this page for the benefit of the subsequent mantinainers.

It is possible to specify more than one private key in the encryption command and thus encrypt the data with several keys using very little extra space. This would be practical if one key is used for regular every day operations and is replaced regularly, while another “failsafe” key is kept by the company executives in case of emergency and is never changed.

Downloading: http://www.google.com/search?q=openssl+download

Coming up next: the simplest script to take a set of files, compress them, slice, encrypt, and upload to Amazon S3 for safekeeping.

Footnotes.

[1] Why encrypt? Data is like DNA – once it spills, the residue is nearly impossible to erase, and so it’s best to keep both neatly contained in the first place. “Secure erase” becomes a fiction when remapped sectors, untrained interns, drifting organizational responsibilities, and cost-efficient third-party cloud storage providers enter the picture. Maintaining privacy of a comparatively small set of keys is a lot easier than doing the same for a large set of backup data.

[2] Actual encryption is performed using a binary key, but most tools provide a way to generated one from an easy to remember text string, a “pass-phrase”, so for this discussion we can assume the two to be equivalent. It needs to be noted however, that there is more than one way to translate a text pass-phrase into a binary key, so it is important to use the same tool to decrypt the data that was used to encrypt it.

[3] Leaving aside the TPM-based solutions, which don’t seem to have gained much traction.

[4] Unlike, say, GPG which requires installation and a somewhat involved key import/export procedure.

[5] Technically, this command is generating a private key and a certificate that has the public key inside of it. The distinction, however, is immaterial in this case. Strangely, SMIME command is the easiest way to get asymmetric encryption using Openssl, and it requires a certificate.