For Compliance, Keep Control of Your Encryption and Don’t Lose Your Head (Or Your Header)!

Cloud providers tend to be quite good at data integrity and availability. For confidentiality, not so much. IaaS services may provide you with good tools, but you will need to take advantage of them to achieve confidentiality in ways that will satisfy compliance audits.

As I mentioned recently, Google’s new ”by default” storage encryption isn’t going to hurt anything, but just like Amazon’s server-side encryption, it doesn’t provide you with the visibility required to prove that your archived data has been encrypted.

In Learning Tree’s Cloud Security Essentials course we show you how the far more helpful client-side encryption works for Amazon’s S3 and Glacier storage services, and in a hands-on exercise you learn how to encrypt EBS storage used with IaaS.

We use the Linux kernel’s encryption modules to protect the file system confidentiality for long-term archiving. It’s a nice design, its default behavior is probably what you want. The key is generated by processing the passphrase with PBKDF2 (Password-Based Key Derivation Function 2), the current standard also used in WPA and WPA2, Microsoft Windows Data Protection API, Apple’s OS X and iOS, Android file system encryption, and Cisco IOS, among others.

The data encryption is done with AES in Cipher Block Chaining mode, with the initialization vectors created with ESSIV or Encrypted Salt-Sector Initialization Vector. This makes the IV highly unpredictable, frustrating something called a ”watermark attack” in which some of the original information leaks into the ciphertext.

After you feel like you’re reasonably comfortable with a utility, go back and browse through its manual page. I usually notice useful new things when I do that.

With the recent revelations of possible backdoors in standardized ciphers, it might be tempting to find how to specify using a different cipher. You can, although this probably isn’t what you really need to do:

# cryptsetup -y --cipher blowfish luksFormat /dev/xvdf

But what you should really do is take the advice of the cryptsetup Frequently Asked Questions author and read the Backup and Data Recovery section. You can permanently lose all your data if you lose or corrupt the header information. That is surprisingly easy to do when you’re messing with your storage volumes. It’s a classic trade-off: increasing confidentiality often decreases availability. The harder you work to keep something secret, the more likely you will lose the information.

The encrypted volume starts with a header — follow their recommendations and make, test, and store a backup of the header. Reliable long-term archiving, that sounds like a job for AWS Glacier.

We show you enough in the Cloud Security Essentials course to get started, but take it a step further by backing up your encrypted volume headers!

Bob Cromwell

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.