HOWTO encrypt an existing filesystem with dmcrypt and dd

[Sadako]

I've been meaning to post this for a while.

Messing around with dd and dmcrypt, I discovered it was almost pathetically easy to encrypt an existing filesystem/partition.
I'm sure this is nothing new and quite obvious to some, but I've never seen it mentioned anywhere, so I thought in was worthy of a little howto.

If anything goes wrong, you could easily lose everything on the filesystem. This should go without saying, and cannot be stressed enough.
I've tested this with small filesystems I created just for this, and used it to convert a large existing filesystem (which I still have encrypted), and have encountered no problems.
I do believe this is a lot safer than trying to convert an existing filesystem to a different type (eg ext3 -> reiser4),
however you would be a fool to try this without backing up anything important to another device first.
If anything goes wrong, you'll know prettty much immediately. Once it has been successfully converted, then nothing else can really go wrong (apart from forgetting the keyphrase ).

I am still a novice at, well, everything, so if any more (or even less) experienced users have any reasons why this is a really bad idea and should not be attempted under any circumstances, please share them.

Prerequisites;
You'll need dmcrypt enabled in the kernel, as well as the ciphers you wish to use (aes, blowfish, etc).
In menuconfig, dmcrypt is under "Device Drivers --> Multi-device support (RAID and LVM) --> Crypt target support", you'll need Device Mapper support to make it available.
Under "Cryptographic options" select the ciphers you want to play with. "CBC support" should be selected for you, and you'll also need the SHA256 digest algorithm if you want essiv.
Apart from that the only thing you need is cryptsetup or cryptsetup-luks, both are in portage.

Okay, now that I've scared off just about anyone who tried to read this (through boredom mostly), lets get to the good stuff;

Replace ${INDEV} with the device you want to encrypt (eg /dev/sda4).
If you're lazy, you can just enter "INDEV=/dev/sda4" in a root shell, and then copy and paste the rest.
Also set DMDEV equal to the name of the dmcrypt device mapping (eg "INDEV=sda4_crypt").

First of all, shouldn't need to be said, but make absolutely sure the filesystem is not mounted;


Code:

umount ${INDEV}


For piece of mind, I strongly suggest making an md5sum of the partition to be encrypted;


Code:

INDEV_MD5=`md5sum ${INDEV}`


Next, create the dmsetup mapping, using whatever cryptsetup options you prefer;


Code:

cryptsetup -y -v -c aes-cbc-essiv:sha256 -s 256 create  ${DMDEV} ${INDEV}


Now copy from the plain partition to the dmcrypt mapping (of the same device) with dd (this is were the magick happens);


Code:

dd if=${INDEV} of=/dev/mapper/${DMDEV} bs=512 conv=notrunc


Once that has completed, check the md5sum of the new mapping against the one you made earlier;


Code:

md5sum /dev/mapper/${DMDEV} echo ${INDEV_MD5}


If these match, then everything went smoothly.
At this stage I'd recommend removing the cryptsetup mapping and setting it up again (to make sure you remember the right keyphrase), running fsck, and finally mounting your newly encrypted filesystem.


Code:

cryptsetup remove ${DMDEV} cryptsetup -v -c aes-cbc-essiv:sha256 -s 256 create  ${DMDEV} ${INDEV} fsck ${INDEV}


You can also compare the md5sum of the raw device (md5sum ${INDEV}) if you want, just to prove to yourself that it has changed.

The most obvious use of this is to encrypt previously unencrypted partitions/filesystems, however for those already using dmcrypt I can think of a couple of more uses;

It could be used to encrypt a already encrypted filesystem, but allowing you to change either the keyphrase (in case you decided it was too weak, or may have been compromised) or the cipher (changing from blowfish to aes or from cbc-plain to cbc-essiv, for example);

[nielchiano]

maybe just to note that this technique WILL NOT WORK with cryptsetup-luks; since the LUKS-part will overwrite the first few sectors of your disk.
This also means that your cryptsetup-luks-partition will be SMALLER than the original.

[Sadako]

[nielchiano]

[c4]

Thanks for a nice howto!
I've been thinking about a setup similar to this and your guide was just the inspiration I needed.
Got this running on a spare partition and it worked just fine.
_________________
AMD64 Gentoo Hardened server
AMD64 Xubuntu Desktop
X86 Dreamlinux Vaio laptop

[jkcunningham]

Nice howto.

Just out of curiosity, why is the dd step so slow? I'm in the middle of converting a 384G hard drive (day 2) and its going to take another 52 hours to finish. Its averaging 1.5 Mbps. But I'm converting a USB 2.0 hard drive partition, and I checked the rate on that previously - its registering at 480 Mbps according to usbview.

And if there's a power glitch (out here in the woods - not uncommon) I'm back to start all over again. Surely there's a faster way to do this? This was a blank disk to begin with.

--Jeff

[c4]

Took me something like 4 whole days to convert a 2TB raid partition, but it only contained 1.5 TB of old backups.
The box was a amd64-3800 with 1gb ram. I figured that the converting time had to do with both the reading&writing from the drive and then the additional time it took for the system to encrypt the files.

I have not tried to encrypt anything else besides this raid partition, but I would imagine that running such a task on a slower cpu would take more time to perform the encryption.
_________________
AMD64 Gentoo Hardened server
AMD64 Xubuntu Desktop
X86 Dreamlinux Vaio laptop

[jkcunningham]

Well I'm apparently encrypting an empty half-terabyte disk. I guess the reason it is necessary is to end up with an encrypted superblock, but it seems like there ought to be a way to encrypt that by itself in the case of a new partition. This process doesn't lend itself to doing it very often.

[fangorn]

This is a nice idea, but it has some downsides.

1. cryptsetup without the LUKS extensions is known to be weaker to cryptographic attacks.
2. for half empty partitions, you have only half the partition filled up with random data.

Nevertheless, I will keep that in mind when having to do the next reconfiguration of discmanager.
_________________
Video Encoding scripts collection | Project page

[Sadako]

[nielchiano]

[Sadako]

[Sadako]

Just a bump to tell you that I've just used this to convert 300 GB filesystem, changing from aes-cbc-essiv:sha256 to aes-lrw-benbi:sha256, and changing the key while I was at it.

It worked perfectly.

I only used a bs value of 512, and it took about 6 hours, with an average rate of 15 MB per second;

[avx]

I might have read 'man dd' wrong, but it says:

[Sadako]

[avx]

[h0mer`-]

just to clarify... is it possible to encrypt a root partition with the method described here?

[nielchiano]

[depontius]

[quote="Hopeless"]

[Sadako]

[Sadako]

[depontius]

[nielchiano]

I'm no LUKS expert either, but according to the info I read, LUKS is acting more like a "header" It occupies the first N blocks of the partition. The crypto-data starts at sector N+1.
You can check that by creating a non-LUKS cryptomap and compare the offsets in dmtable:

[avx]

[Sadako]