Sunday March 26, 2006 at 22:31
Subject: Encrypted file-systems.
Keywords:
Encryption, Linux, Technical
Posted by: Sean Reifschneider
Related entries:Early impressions about encrypted home. by Sean Reifschneider, Thursday March 30, 2006 at 21:47
2 Weeks of Encrypted Filesystem by Sean Reifschneider, Sunday April 09, 2006 at 20:28
Setting Up Encrypted root Partition on Fedora 7. by Sean Reifschneider, Sunday August 26, 2007 at 01:37
Recipe for setting up Encrypted root+swap on Fedora 8. by Sean Reifschneider, Saturday November 24, 2007 at 15:37
You keep hearing about lost or stolen laptops and the data that goes
with them being compromised. The encryption seems to be pretty solid in
Linux now, so with the migration to Fedora Core 5 I'm also trying a /home
partition that is fully encrypted. There are a few FAQs on this, but one
of the better ones is complicated by being written for many different
versions, without a good design for the layout. Here's some information
I've found...
Matthias Hensler's
crypto home page is a pretty good HOWTO for making your home directory
be encrypted. Since I split off my /home several years ago, this is a good
fit for what I wanted, with a few exceptions I'll mention later. Kevin
also found this page about doing encrypted root directories.
Encrypted root directories under Fedora Core 5 don't seem to be
particularly well supported. You have to manually create initrds with the
appropriate tools and scripts. However, the above page makes it look a
little harder than it really is. You can use "/etc/sysconfig/mkinitrd" to
make sure that any newly-created initrds have the required modules. That
would at least get you started without having to manually copy the modules
over.
You could make it so that future initrds are created automatically by
changing the mkinitrd script so that it copies over the cryptsetup tools,
and does other changes that the page above recommends making manually.
Sadly, there just aren't enough places to plug in other customizations, so
you have to modify the mkinitrd script.
However, for an encrypted /home file-system, it's pretty easy. Based
on what Matthias Hensler has, I did the following steps:
(Post Reply)
-
Backup of my /home directory. Since I was migrating from another
disc, I didn't really even feel that I had to verify my normal
backups... I have at least two copies of my old home directory (the
original disc and my nightly backups).
Initialize LUKS on the new partition for /home (hda4) with:
cryptsetup --key-size 256 --verbose --verify-passphrase
--cipher aes-cbc-essiv:sha256 luksFormat /dev/hda4
Start up the encrypted file-system with: cryptsetup luksOpen
/dev/hda4 home
Format with: mke2fs -j /dev/mapper/home
Add a line for /home to /etc/fstab. I used: /dev/mapper/home
/home ext3 defaults 1 3
Mount up the encrypted /home and copy data to it.
#!/bin/sh
#
# Get home ready to mount
HOMEPARTITION=/dev/hda4
echo
echo 'Starting home directory:'
/sbin/modprobe dm_crypt
/sbin/modprobe aes-i586
/sbin/modprobe sha256
while true
do
/sbin/cryptsetup luksOpen "$HOMEPARTITION" home
/sbin/cryptsetup status home | grep -q 'is active' && break
echo -n 'Do you want to try again? '
read line
[ ! -z "$line" ] && ( [ -z "${line##n*}" ] || [ -z "${line##N*}" ] ) && break
done
This file needs to be "chmod +x" for the boot process to use it. You
will need to change the HOMEPARTITION line if yours exists elsewhere.
With this script in place, early in the boot process the crypto
modules will be loaded, and you will be asked for a password for "/home".
If you fat-finger it you will be given the opportunity to try again, but if
you don't have the password or have a munged /home directory you can skip
it with the second part. I added this because early on I forgot my
passphrase and couldn't boot at all, even into single user mode. I had to
use the "init=/bin/sh" trick...
Remember, backup are incredibly important now, because your
file-system is even more fragile than it was before. Bad blocks or
corrupted data may render large parts of your data unusable. Backups: Just
do them!
A quick word on performance... I ran some tests and on my 1.8GHz
Pentium M I was getting around 35MB/sec writing a file from /dev/zero.
That was at 100% CPU. I have lots of CPU to spare usually, so not a big
deal. I also copied my home directory over, which was around 60GB. That
wasn't running at 100% CPU, so I don't think that CPU was the limiting
factor there. It took a couple of hours to copy across, about what I would
expect on a normal disc.
So, I'll probably get more of an idea as I use it over the coming
weeks, but for the moment it doesn't look like a huge deal. If you have a
slower laptop, or already have poor performance, this may be an issue for
you. For example, Evelyn stresses her laptop pretty hard, and I would call
her performance unacceptable without encryption, so encryption isn't going
to help. She runs with like 100 tabs open though, which I think is just
killing her performance.
(Post Reply)
| Comment |
Author:
Daniel Webb Subject: Filesystem encryption and robustness |
I'm curious just how much more fragile encryption makes a partition. I'm also using the dm-crypt AES encryption for some drives, and so far it seems to be solid. I'm curious how a bit of corruption would affect the drive. Would you lose 1k (assuming a 1k blocksize)? More?
| Comment |
Author:
Sean Reifschneider Subject: Corruption of AES data. |
The I would imagine it's something like 4KB that would be corrupted. I imagine it's doing block-based encryption, so that independant blocks of the file or file-system could be re-written. However, if that corruption occurs in the inode map or block map, it could damage much more information.
Sean
| Comment |
Author:
Sean Reifschneider Subject: For CentOS 4.x... |
For CentOS, you need to get a recent SRPM of cryptsetup-luks, build and install it. You will probably need to "rpm -e cryptsetup" before you can install cryptsetup-luks.
Then the command for cryptsetup needs to be:
modprobe aes dm_crypt cryptsetup --key-size 256 --verbose --verify-passphrase -fcipher aes-plain luksFormat /dev/hda4The rest of the commands will work as they are. Sean