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
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!

Image from Flikr by Melvin Schlubman


David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

SPAM posters

Anonymous's picture

Looks like Linux Journal needs some software to help clean up the spam posters who have taken over posting comments -

About dd speed...

Chris Gonnerman's picture

I've discovered, when using dd to erase disks, that using a blocksize of 10k or more leads to much better performance. I'm assuming that mirror-copying would be similarly improved. I did objective tests on SATA hard drives on several different Intel mainboards using block sizes from 1k to 20k; there wasn't much improvement from 10k to 20k, but I saw a two- to three-fold improvement from 1k to 10k.

no, it worked right

Anonymous's picture

As Bruce Schneier says, bits are bits. There's no way to prevent you from copying the bits. What TPM and ecryption can do is control who and how those bits can be understood. That's what happened here. dd pulled the bits from one disk (without interpreting them), and plopped them down on the new disk (without interpreting them). Read bit, write bit. Lather, rinse, repeat. However, if you had tried to read the disk in another computer, it probably would not have been read, because the key is in the TPM module on your system.

TPM what again?

mario___'s picture

I've never heard of LUKS/dmcrypt employing TPM features to this date. Albeit there are sketchy means to utilize it, that's unlikely to be a default in Fedora:

don't forget SIGUSR1

Anonymous's picture

if dd takes a long time to run (as it is in this case), then background it and track its PID. Then "kill -SIGUSR1 PID" to get current transfer stats.


Anonymous's picture

But wait, I had a TMP protected

Should be TPM


BlueSTAR's picture

Isn't formatting the new disk useless when using dd to clone the whole disk?

LUKS/dm-crypt needs append ability

jhansonxi's picture

Instead of having to use LVM2 it would be easier if an encrypted partition could be extended by appending one crypt volume after another using the same key.


Zach's picture

If you configured TPM properly the only benefit it should give is preventing the HDDs use in another computer. The key to this encrypted drive should be stored within your TPM module. I haven't tested it myself but I've included a reference. Would you be able to put that HDD in another computer and give us the results?

If you want to know when the turkey is done...

jmt's picture

If you want to know how long the copying will take, do the following:

source disk: /dev/sdX
target disk: /dev/sdY

1. attach the disks to one of you other Linux machines (you do have several, don't you)

2. find out the source disk size using "fdisk -l /dev/sdX"

3. if the "pv" program is not already installed, do it now

4. dd if=/dev/sdX | pv -s disksize | dd of=/dev/sdY

or you can try:

dd if=/dev/sdX | pv -s `fdisk -l /dev/sdX|head -2|tail -1|awk '{print $5}'` | dd of=/dev/sdY

This makes the "pv" program tell you when the turkey is done.


Anonymous's picture

thank you for the interesting comments.
one of the suggestions seemed unusually risky if i understood it correctly.

dd if=/dev/sdX | pv -s `fdisk -l /dev/sdX|head -2|tail -1|awk   '{print $5}'` | dd of=/dev/sdY

pardon my inexperience, i think one of the best things about *nix is the pipelines but i'm just thinking worst case here --
power loss or signal corruption in the middle of lengthy invocations of fdisk -- [am i reading that right? of course the dd would likely suffer too].

fdisk -l is harmless enough by itself i would think, but unattended?
stuff happens. could that put both partition tables at risk?
or am i over-reacting?

only once

jmt's picture

You are indeed overreacting. fdisk is executed only once in this pipeline. The command in the back ticks (`cmd`) is executed in a sub-shell and the output (the disk size) is given as a parameter to the pv command. If anything should go wrong, the worst thing that can happen is that you have run the command again (and put another turkey in the oven).

By the way, I'm just running a similar command to clean up and test an old drive that I'm going to use.

dd if=/dev/zero bs=4M | pv -s xxxxxxxx | if=/dev/sdb bs=4M

I did, however, pick the disk size from the output of the fdisk command using simple cut and paste.

As mentioned elsewhere in the comments, the bs (block size) parameter makes a lot of difference. On this particular disk the time is cut into approximately one fourth. 16 hours vs. 4 hours makes a difference on your turkey.


pkoutoupis's picture

If it is extra verbosity that is needed, ddrescue is a great cloning alternative. It works on top of the same logic as dd but contains extra and much needed features for the case where you may be copying from a bad hard disk device.

ddrescue is pretty good and displaying the amount of data read/written, the amount of errors seen and the rate at which I/O is performing, all in real time.

Message link

sid hymes's picture

On my Fedora 12/13 boxes, the file is located at /var/log/messages (log is singular). Hope this helps someone.

That explains it!

David Lane's picture

I wondered why I could not access my log files. Thanks, I have corrected it.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

Protections provided by TPM

Kevin Granade's picture

I'm not sure TPM provides some of the things you expect it to provide, and some others it may be able to provide, but wasn't configured to do.

1. Prevent you from doing I/O with external disks.
While in some security contexts it is advisable to do this (and similar things like locking down networking), I would be really surprised if most systems did this by default. Specifically the way TPM would help with this is if TPM is used to validate the firmware and OS, and is configured to only allow an OS that disallows these features to boot. This would of course mean that your laptop would never have these features, and you would also be unable to boot your laptop from a live CD (unless it were also configured specifically to boot from that live CD). The bottom line is it is up to the end user or system administrator to use TPM as a tool to provide this kind of functionality. You might be able to find a distribution that does this automatically, but I don't have any specifics. Also this isn't necessarily what you want/need, see below.

2. Prevent you from copying the hard drive data in a usable form.
It is debatable whether this happened or not, if the drive is full-disk encrypted and your bootup is set up properly, that drive (and any copy of it) should be practically useless unless you have access to the system with the TPM chip that has the keys AND your password/passphrase/other authentication that you use to authenticate yourself to TPM. I'm not saying you were fully protected, I don't have the details, but the details you have provided haven't proven that you were not protected either.

The fact that you were able to use your laptop to do the copy is orthogonal to the problem, if you have physical access to the drive, you can copy it with some other system and the TPM can't help you. The protection is that if you stuck that drive (or any copy) into another system, it *should* be unable to boot from it and decrypt your data since the decryption keys are stored on the TPM in your laptop. Additionally, the OS should have support for you authenticating yourself to the TPM during boot, so that someone that is not you cannot access the data even if they have the laptop. You might want to try to boot a different system with the drive or a copy, if you can there is definitely a problem.

Final note, I found the term "cage" confusing. After some thought I can only guess that you mean an external usb drive, but I'm unfamiliar with calling that a "cage".


David Lane's picture

Essentially it is a device that you can put an internal disk into that has the right pins and power to have your disk run external to your mother board via USB. I use Rocket Fish and they call them enclosures.

They have been around a long time and come in both PETA and SATA models. About $50 at your local PC shop.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack


Jerry McBride's picture

If you dd drive "a" to drive "b", doesn't that copy drive "a"'s partition table over to drive "b"?

I've never done this, but it would look like you would run into problems sooner or later...


---- Jerry McBride

1) "a" and "b" are DOS

Anonymous's picture

1) "a" and "b" are DOS conventions.
2) Floppy drives do not contain partition tables.

Copying over the partition table...

pkoutoupis's picture


You are correct in that assumption. Utilizing dd in such a fashion would copy over the entire partition table. If the new drive contains extra storage space, I can see the user create a new partition and mount that separately from /. But as for resizing the existing and encrypted partition, maybe we need a tutorial to cover that. ;-)

I guess it all boils down to the type of encryption utilized. That is, are we using the dm-crypt module found in the device-mapper infrastructure? If so and the volume already exists on a layer of LVM2 mappings, it shouldn't be too hard to append a new partition to an existing volume group.


David Lane's picture

Which is what I did.

David Lane, KG4GIY is a member of Linux Journal's Editorial Advisory Panel and the Control Op for Linux Journal's Virtual Ham Shack

What do you need TPM for?

JorgeGV's picture

When using Fedora, for example: select "encrypted disk" during install, input your passphrase and voila, all disk is encrypted. You can take it to another machine (sure! but that's a feature, not a bug!), you can freely clone it with dd, grow it after being cloned in a bigger one, etc.

If you don't know the passphrase, you can not access the disk in any way. THe only partition that is unencrypted is /boot, something pretty standard for all Fedora installations, and pretty much identical for all of them.

All laptops in my company are encrypted this way, and we feel pretty comfortable.

Modifying DD block transfer size

pkoutoupis's picture

To help the copying process move a bit faster, dd allows the user to define a transfer size with the bs option. By default, it is defined to 512 bytes (that is a single sector). This will take forever on large volumes.

So for instance, if I want to sequentially transfer data from one large volume to another at 1 MB transfers, I would define dd with the following additional argument:

dd if=[source drive] of=[destination drive] bs=1M

This should help the process move much faster.

The following assumes that both disk devices appear as SCSI disks on the host system:

An optimal sequential transfer size for a single device in Linux is 4 MB. This relates to the SCSI Subsystem as typically (although I haven't checked this recently) Linux’s scatter gather lists can handle up to a 4 MB chunk transfer (I am not sure if this is the maximum though; need to check the kernel source). This was validated through a protocol analyzer.

The purpose of the scatter gather lists is to coalesce all sequential read/write operations; upon entering the SCSI subsystem and just prior to the transfer(s) being sent to the SCSI-based media (i.e. SCSI, SAS, fibre channel disk devices, etc.).


JShuford's picture

Thank you.

...I'm not just a "troll", but also a subscriber!