But first, why would you want to do this? Good question! Bear in mind that by using EC2 and storing any data there, you're putting a considerable amount of trust in Amazon already. They own the hardware and the hypervisor. They are running a modified Linux/Xen kernel that you cannot even audit, if you wanted to. They haven't released the sourced to that modified Linux kernel, so don't deceive yourself -- their instrumented kernels could be logging your every keystroke. Hopefully not. But you don't know that.
So what can you do? What good is eCryptfs here? Well, if you transparently read and write your data through an eCryptfs encryption/decryption layer, you can add a measurable amount of confidence and security that your data will at least be encrypted when it's at rest, once it lands on a spinning hard disk somewhere in an Amazon data center. In this world of cloud trust, you're explicitly trusting Amazon to "do the right thing" and take reasonable precautions. Amazon is huge, and has a tremendous amount to lose by acting deceptively. But you can't say the same for every single individual between you and your data. In other words, you don't necessarily trust every individual that might brush past your data. Hard disks get stolen and sold on eBay, they're returned to the manufacturer for repair, donated to Goodwill or schools, recycled, repurposed, and reused. So if you could trivially ensure that your bytes are encrypted before being written to disk, would you? Well, as you see below, it's not quite trivial yet, but it is very much possible. Stay tuned here and watch this area of technology evolve. In the meantime, give this a shot...
First, start an Ubuntu VM in EC2. I use the cloud-sandbox command from lp:bikeshed. I'm sure you have your own methods.
Next, SSH into your new VM and install ecryptfs-utils.
sudo apt-get install ecryptfs-utils
Next, you must set a login password for the Ubuntu user. Note that you do not have to enable PasswordAuthentication in /etc/ssh/sshd_config (though you might choose to). As always, make sure you choose a strong passphrase. I recommend at the very least 12 characters, with upper case, lower case, and numbers. You know how to choose a good password. The more important it is that your data stay private, the better the password should be ;-)
sudo passwd ubuntu
Exit byobu, or any other programs you might be running as your ubuntu user, and change out of your $HOME directory, and migrate your home directory. However, if you've encrypted all of your $HOME, you MUST move your .ssh directory out, so that your authorized keys file is not encrypted!!! Make sure you run all of the following commands sequentially, and without terminating your SSH connection, or else you might find yourself locked out of your instance :-)
cd / ; sudo ecryptfs-migrate-home -u ubuntu
If that completes successfully, we can clean up our backup of our unencrypted home directory.sudo ln -s /home/.ecryptfs/ubuntu/.ssh $HOME/su - ubuntuecryptfs-mount-private cd $HOME mv $HOME/.ssh /home/.ecryptfs/ubuntu/ln -s /home/.ecryptfs/ubuntu/.ssh $HOME/
sudo rm -rf /home/ubuntu.*
Alternatively, might might choose just to encrypt one private directory, instead of migrating all of your home. To do so, use:
ecryptfs-setup-private
Finally, we will want to be prompted for our login password at every login to automatically mount our home directory, so let's also create a ".profile" in our unencrypted home directory.
ecryptfs-umount-private echo "ecryptfs-mount-private; . $HOME/.profile; cd" | sudo tee $HOME/.profile ecryptfs-mount-private
Alright! At this point, we should be able to exit all of our shells and SSH back into our EC2 instance. The SSH public key authentication will get us onto the machine, and then our .profile script should prompt us for our login passphrase and automatically mount our encrypted home directory.
The data that actually gets written to your root ext4 filesystem on /dev/xvda1 are the files that you can find in /home/.ecryptfs/ubuntu/.Private/, which should look something like this:
ubuntu@ip-10-194-246-143:~$ ll /home/.ecryptfs/ubuntu/.Private/ total 68 drwx------ 3 ubuntu ubuntu 4096 Dec 22 18:54 ./ drwxr-xr-x 5 ubuntu ubuntu 4096 Dec 22 18:46 ../ lrwxrwxrwx 1 ubuntu ubuntu 124 Dec 22 18:42 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHi1R07VV4a9quAsP3ATb2JK--- -> ECRYPTFS_FNEK_ENCRYPTED.FYbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiSRA-6SgbLQ.LtWP2pwGZY57PtU2wAgzLn-ECMilfrp9dp0YUYlTDNwY6P764.gPo -rw-r--r-- 1 ubuntu ubuntu 12288 Dec 1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHi9KCXyAtK1PsV4KirBxb8fk-- drwx------ 2 ubuntu ubuntu 4096 Dec 22 17:32 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHicFvfubbvnebsd2N8jh9vRU--/ -rw-r--r-- 1 ubuntu ubuntu 12288 Dec 1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHifCuJCnlfaXjU4QlrUWfhIU-- -rw-r--r-- 1 ubuntu ubuntu 12288 Dec 1 12:50 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiNgxmEEQUk9nI3uOlsQkCHk-- lrwxrwxrwx 1 ubuntu ubuntu 104 Dec 22 18:42 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHipvXKHoAMUybcfPOQYgm1WE-- -> ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHif.b7-V31EJPzRLnx.vfW9dIwfbnZuIcdSIqqNTvonyo- lrwxrwxrwx 1 root root 104 Dec 22 18:54 ECRYPTFS_FNEK_ENCRYPTED.FWbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHisXvcg5obbXbibbufq7QjyE-- -> ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHiGNrAq2Ud8N9P5xVz2YssSWo-.u4wRtBbZLQLIeG-0I2- -rw-r--r-- 1 ubuntu ubuntu 8192 Dec 22 17:32 ECRYPTFS_FNEK_ENCRYPTED.FXbSgDSRezlYtETTxmAwbGjiN4WOMkt-2hHivZ3-rM86jHHkrHcJAXqMkfoOaMkowIPainVLMFWajCg-
This is what you're hoping your attacker, the unsavory individual who comes into contact with one of those magic cloud hard drives containing your data, sees. These are the encrypted file names, and the file contents are just as unreadable without the necessary keys!
Enjoy,
:-Dustin
