The Move To Linux - Encrypted Disk Issues

One of the standards that has become normal in the US federal sector is the requirement that all mobile devices, such as laptops, have encrypted drives. This was a direct result of a number of laptop thefts earlier in the decade that resulted in the supposed leaking of personal information. As a former federal contractor, I watched a number of successful and not so successful methodologies implemented and deployed. Some resulted in real data protection and some resulted in wonderful bricks. In some cases on a regular (read daily) basis.
One of the more successful tools is the Trust Platform Module (TPM) chip. When properly implemented, it allows you to improve encryption, ensure that even if your disk is removed from your laptop, it is still secure and greatly enhances security. So, imagine my surprise, upon rejoining the private sector that my new company does not have a policy for encrypting laptops, even though almost every individual in the company has one.
I was issued a brand-new Dell, with a TPM chip and Windows XP on it. Of course, the first thing I did was download a copy of Fedora and set about reformatting the machine, including setting up the TPM and installing ext4 and enabling Linux disk encryption and went along my merry way, not really thinking about it. That was six months ago.
Like most laptop users, when disk space gets low, you have two options. Replace the disk with a larger one and reinstall or clone the disk to a larger one. After only six months, I was in no mood to do a reinstall, so I decided I would go the clone route. But wait, I had a TMP protected, encrypted disk. How was I supposed to do this? Surely this was a routine sort of thing. So I set out to the Internet and did some research. And was underwhelmed with what I discovered. Essentially, while there are a number of sites that will tell you how to clone your disk (something I am very familiar with), there are almost none that talk about the issues of encryption. Which left me in a bit of a quandary.
Finally, I decided to give it a shot and hope that I could make it work. The first question was what tool to use. I decided to go with dd because it does a bit for bit copy, rather than needing access to the file system. This is important because the disk, for the most part, is encrypted.
The other decision I made was to remove the disk from the machine and put it in a cage and put the second disk in a cage as well. I then booted the diskless machine with a LiveCD (I used Fedora 14 desktop) and connected the disks. Sure enough my encrypted disk popped up and I got an warning indicating that it was encrypted. I canceled the option to type in my password and connected my second disk and set to work doing the copy.
I was moving some 150 GB of disk from one machine to another, via USB. It took close to ten hours to do this successfully. So while dd worked, there are probably faster alternatives. Your mileage may vary.
After the copy was successful, I installed the new disk, pushed the power button and crossed my fingers. I am happy to report that the drive fired up, and after a successful password, decrypted itself and I was back in business.
But wait a minute.... Yes, what about the TPM chip? Remember that one of the things a TPM chip is supposed to do is prevent me from reading a disk not attached to the motherboard. I should not only not have been able to read it once mounted in the cage, I should not have been able to copy it at all - at least not to any sort of usable form. And I did. Why? Well, my leading thought is I did not set up the module correctly or that Dell has not set it up correctly to add the additional level of protection to the disk. It is also possible I did not install Linux in such a way to take advantage of the chip. In either case, while I am getting security through the Linux-based disk encryption, I am not getting any additional protection from the TPM chip.
The takeaways then are this. You can use dd to copy Linux-encrypted disks successfully. And never assume you are secure unless you test your security. Better yet, have someone else test it. Chances are you are not as secure as you think you are.

Using dd to clone an encrypted disk

These instructions assume you are using similar drive types (such as SATA), have access to a pair of cages or disk carriers, and a significant amount of time to copy the data.

1) Remove the disk you want to copy from the system and place it in a cage. This step is optional.

2) Set up your secondary disk in a cage.

3) Boot your system with a LiveCD. This will allow you to unmount the disks you are planning to clone, which is critical to a successful clone.

4) Open a couple of terminals. In one terminal su to root or execute the following command with sudo:

tail -f /var/log/messages

This will open a running window from your messages file, which is important for determining what disks are where as well as any error messages that are not logged to the console during the dd process. /var/log/messages is the default location for most OSs. Double check to see if it is the same for you.

5) Plug in your source drive and watch the log file for the name assigned to it. For example, if it is a SATA drive, and there are no other drives connected it will most likely pop up as /dev/sdb. (If you did not remove your drive, it is likely /dev/sda.)

6) Plug in the second drive and note its name. In my case it was /dev/sdc.

7) If you need to format your new drive, now is the time. Create a single partition, and make sure you choose ext4 as the file type. Once the disk is prepared, unmount both disks.

8) In a terminal, as root, run the following:

dd if=source drive of=destination drive

So:

dd if=/dev/sdb of=/dev/sdc

Go and prepare Thanksgiving dinner (and possibly get a leg up on Christmas dinner if you have a large disk).

9) Once the copy is complete (and you will know because the command prompt will come back), install your new disk into your machine and boot it up.

Best of luck!