Over the years, Amazon has repeatedly recommended that customers who care about the security of their data should consider encrypting information stored on disks, whether ephemeral storage (/mnt) or EBS volumes. This, even though they take pains to ensure that disk blocks are wiped between uses by different customers, and they implement policies which restrict access to disks even by their own employees.
There are a few levels where encryption can take place:
File level. This includes tools like GnuPG, freely available on Ubuntu in the
gnupgpackage. If you use this approach, make sure that you don’t store the unencrypted information on the disk before encrypting it.File system level. This includes useful packages like
encfswhich transparently encrypt files before saving to disk, presenting the unencrypted contents in a virtual file system. This can even be used on top of ans3fsfile system letting you store encrypted data on S3 with ease.Block device level. You can place any file system you’d like on top of the encrypted block interface and neither your application nor your file system realize that the hardware disk never sees unencrypted data.
The rest of this article presents a simple way to set up a level of encryption at the block device level using cryptsetup/LUKS. It has been tested on the 32-bit Ubuntu 9.10 Jaunty server AMI listed on http://alestic.com and should work on other Ubuntu AMIs and even other distros with minor changes.
This walkthrough uses the /mnt ephemeral storage, but you can replace /mnt and /dev/sda2 with appropriate mount point and device for 64-bit instance types or EBS volumes.
Setup
Install tools and kernel modules:
sudo apt-get update
sudo apt-get install -y cryptsetup xfsprogs
for i in sha256 dm_crypt xfs; do
sudo modprobe $i
echo $i | sudo tee -a /etc/modules
done
Before you continue, make sure there is nothing valuable on /mnt because we’re going to replace it!
sudo umount /mnt
sudo chmod 000 /mnt
Encrypt the disk and create your favorite file system on it:
sudo luksformat -t xfs /dev/sda2
sudo cryptsetup luksOpen /dev/sda2 crypt-sda2
Remember your passphrase! It is not recoverable!
Update /etc/fstab and replace the /mnt line (or create a new line for an EBS volume):
fstabentry='/dev/mapper/crypt-sda2 /mnt xfs noauto 0 0'
sudo perl -pi -e "s%^.* /mnt .*%$fstabentry%" /etc/fstab
Mount the file system on the encrypted block device:
sudo mount /mnt
You’re now to free to place files on /mnt knowing that the content will be encrypted before it is written to the hardware disk.
After reboot, /mnt will appear empty until you re-mount the encrypted partition, entering your passphrase:
sudo cryptsetup luksOpen /dev/sda2 crypt-sda2
sudo mount /mnt
Notes
See “man cryptsetup” for info on adding keys and getting information from the LUKS disk header.
It is possible to auto-mount the encrypted disk on reboot if you are willing to put your passphrase in the root partition (almost ruins the point of encryption). See the documentation on crypttab and consider adding a line like:
crypt-sda2 /dev/sda2 /PASSPHRASEFILE luks
Study the cryptsetup documentation carefully so that you understand what is going on. Keeping your data private is important, but it’s also important that you know how to get it back in the case of problems.
This article does not attempt to cover all of the possible security considerations you might need to take into account for data leakage on disks. For example, sensitive information might be stored in /tmp, /etc, or log files on the root disk. If you have swap enabled, anything in memory could be saved in the clear to disk whenever the operating system feels like it.
How do you solve your data security challenges on EC2?
This article was based on a post made on the EC2 Ubuntu group.



Follow Eric Hammond on Twitter
What performance cost does this kind of block level encryption has?
orensol: I doubt the performance implications can be given as a single value for all applications. Fortunately, it's easy to try things cheaply on EC2.
Security through encryption is not going to come free in terms of performance or management. For example, the above approach requires you to manually enter passphrases when disks are mounted.
Each customer is going to have to make the call as to whether the added safety is worth the costs. For a lot of applications, Amazon's existing storage security measures will continue to be acceptable.
Forgive me, if I'm asking a stupid question, but I just would like to double check my understanding.
When you are using block device encryption; as I understand it the encrypt/decrypt operations happens within the server and not at the EBS level. Or phrased in another way; the data traffic between the EC2 instance and the EBS instance is always encrypted.
Is this a correct interpretation?
jens: Your understanding is correct. The encryption is performed before the data is sent to EBS and decryption is performed on the host after receiving the encrypted block from EBS.
Any particular reason why you used XFS for this ?
rockingturtle:
My reasons for XFS include the ones I list in this article: http://ec2ebs-mysql.notlong.com
I've an encrypted volume that I'm trying to mount from a script running over SSH on an EC2 instance. By default the script is running as "ec2-user" user. However, cryptsetup and mount commands have to be run as root.
I can successfully run this script by opening a terminal to the EC2 instance, but I have to automate this step.
What'd be the options to do that.
Thanks,
Evgeni
evgenist:
Since you have an "ec2-user", I'm guessing you're using Amazon Linux (I'm using Ubuntu). I believe that the ec2-user user should have passwordless sudo access, so you could try sticking "sudo" in front of the cryptsetup and mount commands you are using.
I'd like to automate this process in my userdata file so that the encrypted volume is mounted and ready to go with no human interaction.
I'm using instance store and really don't care what the pass-phrase ends up being as the data on the instance would not need to be saved. (Wanting to use encryption to satisfy paranoia about what happens to data on Amazon's disks/memory after instance destruction)
Having trouble using luksformat in a non-interactive fashion.
eric.smalling:
You could try using "cryptsetup luksFormat" and "mkfs" separately as the former can take a key file. As long as you're ok with the key being on a (different) disk it should work.