[Madlug] Laptop encryption

Fri Jan 18 17:53:35 CST 2008

On Tue, 1 Jan 2008 18:19:32 -0500
Dan <dan-madlug at spamtrap.wide.net> wrote:

> I'd like to hear folks' thoughts on encrypting laptop drives.  In the 
> past I've done just my /home partition as that's usually the only place
> I store data I care about (browser passwords, ssh keys, blackmail photos
> of rizzo's mom, etc.)  But lately I've found that being able to suspend-
> to-disk is such a big productivity bonus that I'm willing to compromise
> the security of the encryption by leaving my X session running, and
> therefore /home mounted.  I realize how foolish this is but I'm much 
> more concerned that my laptop will be stolen out of my car than I am
> that spooky men wearing sunglasses at night will confiscate it in the
> name of National Security.  And since most thieves are too clueless to
> operate a Ubuntu system, let alone fish a session key out of the swap
> partition, I feel "secure enough" about the process.
> 
> But I'm sure there's a better way.  Anyone have any ideas we can kick
> around on the list?
> 
> (Interesting research thus far:
> 
> [0] http://www.saout.de/tikiwiki/tiki-index.php?page=LUKS
> [1] http://www.faqs.org/docs/Linux-HOWTO/Loopback-Encrypted-Filesystem-HOWTO.html
> [2] http://www.linuxjournal.com/article/7743 )
> 
> 
> --
> Dan
> _______________________________________________
> Madlug mailing list  -  Madlug at madisonlinux.org
> http://www.madisonlinux.org/mailman/listinfo/madlug

This might be out of date since the post was almost two weeks ago but,

I think that you are pretty safe just with the encrypted home drive as long as you lock the session before you suspend it. That way they have to turn it off to get passed xscreensaver.

You could use an encrypted swap so that once the computer was off they would have to decrypt the swap partition to gather any data from it. That might cause a performance hit on ubuntu if you have an older computer because I have heard that it is rather swappy by default.

If you really wanted to add an extra layer you could encrypt the entire drive. That would cover your swap root and everything else.

I have heard that there are some distros that support full disk encryption(fedora or suse maybe, not 100% sure).

A friend of mine uses full disk encryption on his laptop and has had really good luck with it. He wrote a quick guide that I'll post if you're interested. I haven't done it myself because my laptop is so old that I'm not sure how well it would deal with decrypting that much data. If you have a laptop that was made in the last two years you should be fine. If you have a two or more cores then you shouldn't even notice it.

The guide was made by and for gentoo users so I don't think you could follow it right off but it might be helpful for you as a reference as to one way to do it.

-MJ

REQUIRED PACKAGES:
	sys-fs/device-mapper
	sys-fs/cryptsetup-luks -dynamic
	sys-kernel/genkernel

##########################
### Part I: The Theory ###
##########################

The trick to this whole thing is to set up a boot partition (has to be its
own partition) that has an initramfs (a extremely minimalist os) that contains
all the things required to decrypt the drive.

What threw me for a loop for a while was that all 2.6 kernels (vice 2.4
kernels) get an initramfs by default.  Before you used to have to make one.
In SUSE and RedHat you can use mkinitrd to create one of your own. In Gentoo
you have to use the genkernel utility ( sys-kernel/genkernel ).

The easiest thing to do is start over from scratch.  However, I did transfer
over a working system, which is what I'll describe.

Now, you may see some guides that show you how to move an unencrypted
partition over to an encrypted partition on the same drive.  I really don't
recommend doing that.  Instead, use a separate disk for your back-up.  Modern
hard disk drivers are very difficult to boss around.  They make the actual
physical structure of most drives nearly opaque to the OS.  Consequently, you
can't be 100% sure that your data is actually being overwritten as long as the
drive thinks it's trying to preserve your filesystem structure.  It might try
to take shortcuts.  Once you clean your hard drive, it's best that nothing
unencrypted ever touch it again.

The biggest advantage of the setup I describe below is that your linux system
will never have access to writing encrypted data to an unencrypted partition.
Even if your hard disk controller tries to put data that the kernel thinks is
going on to an encrypted partition somewhere outside of the encrypted
partition, it will be encrypted.  Of course you'll still be able to write to
unencrypted media without problems.  One of the other advantages is that the
encryption once implemented will be transparent to you as a user.  Unless you
write it someplace in the clear, it will never be in the clear.

Using TrueCrypt may be preferable in some ways since it handles the decryption
and mounting process more transparently, but device-mapper and cryptsetup-luks
is more than adequate.  I could not figure out how to convince TrueCrypt to be
part of an initramfs.  They officially claim it cannot really be done.
Both cryptsetup and TrueCrypt use the advanced LRW mode which makes them a
better choice than cryptfs.

Making the backup... I used 

# rsync -avz --progress --exclude "/proc" --exclude "/var/tmp"  /src /destination

You don't want /proc since it's created on the fly by the kernel.  In a normal
file backup, you don't want /dev, since it's normally very similar to proc and
contains no information that you really want to preserve.  HOWEVER, if you're
backing up a whole system, you need the appropriate devices created in order
for any of your hardware to work.  If you for some reason destroy your /dev
you can recreate it by re-emerging udev and baselayout.

Make sure that if you choose some other backup mechanism that you preserve all
permissions.  There is no way to fix permissions on important things if you
screw them up.  You'll essentially have to start all over from scratch.

After you make the back up, it's probably unwise to mount it as read-write
unless you absolutely need to.

Leave out whatever other files you think would be quickly recreated.  I would
suggest forgetting any fancy partition scheme during the backup.  By putting
everything together on one single filesystem you avoid the problem of having
to mount several different partitions if you want to chroot into your old
system in order to help get the new one up and running.

Once you've backed-up your system, verify that it is complete.  That means
probably booting from a liveCD and chrooting into your backup to make sure it
works and that it has the files you think it should.

The next step is critical.  You MUST fill your disk with random data,
otherwise the encryption will be pointless: the original data, if not
overwritten, will be in the clear.  To do so, I used the shred utility (
sys-apps/coreutils ).  Normally shred wont actually securely delete files
because all journalled file systems cache data in random spots.  Also, most
disk drives shield the physical location of a file form the OS, so you never
really know where the file was physically in order to delete it.  In this case
however, I just used shred to dump a bunch of random data all over the entire
disk.  Send the entire device to shred, not just a partition (i.e., /dev/hda
not /dev/hda2).

# shred -n 1 -v /dev/hda

By default shred will try to do a DoD-quality overwrite of all your data and
then fill the entire drive with zeros.  Unless you are concerned about
forensic recovery of files, that's totally excessive.  Just one pass of random
data will be effective against a bit-for-bit dump of your hard drives contents
and, most importantly, will conceal the structure of the new encrypted file
system. (Good encryption is indistinguishable from random data.)  For the same
reason, you don't want it to zero out the drive, since that will just make it
obvious where there is encrypted data.  So, just a -n 1, rather than 25
passes will suffice.

The system I used, dm-crypt is sort of odd.  Basically, you will set up your
paritions, then use the cryptsetup utility to convert them into encrypted
partitions.  Mounting is a matter of passing the encrypted partition to
cryptsetup, entering the password, and telling it to make a new device
( /dev/mapper/newDevice ) which you will mount.  So, you wont mount /dev/hda2
anymore, instead you'll mount /dev/mapper/hda2.  It's important to note that
simply decrypting the partition does not mount it.  When doing disk
maintenance, like fsck or fdisk, you'll need to decrypt the paritition and
perform the maintenance operation on the /dev/mapper device instead of the
/dev/hda device.

It's also critical to encrypt your swap partition.  Gentoo, by default, is not
very swappy (tends not to send data to the swap partition).  Ubuntu, by
contrast, is incredibly swappy.  (
http://gentoo-wiki.com/FAQ_Linux_Memory_Management#Swappiness_.282.6_kernels.29
)  Interestingly, do this to get a feel for what is on your swap partition
(if, for instance your swap partition is /dev/hda3):

# dd if=/dev/hda3 | strings | less

With dm-crypt, you'll be able to pick your encryption algorithm.  I'd
recommend AES256 since it's fast and very secure as long as your password is
secure. Blowfish and twofish are also very solid, both designed by Bruce
Schneier. Bigger the keysize the better, obviously, but there is a limit to
sanity and to utility.  Try to make sure you're not using the MD4 hash
algorithm.  DM-crypt should default to MD5 which is fairly secure (SHA1 or
SHA256 would be better), but MD4 is no longer secure.

At a minimum in your kernel (I would make any adjustment to your kernel, use
module-rebuild to install any necessary modules, and then boot from it to make
sure it works) you need to have built-in (not as modules) anything necessary
for your system to work: filesystem drivers, hard disk drivers, encryption
algorithms, etc...).  The reason is that modules are, in general, stored on
your hard disk in /lib/modules.  So, your kernel would have to decrypt your
disk in order to access anything on the disk: chicken and egg problem.

Also you'll need.....

Device Drivers  --->
  Block devices  --->
      <*> Loopback device support
      < >   Cryptoloop Support
      (4096) Default RAM disk size (kbytes)
      [*]   Initial RAM disk (initrd) support
  Multi-device support (RAID and LVM)  --->
      <*>   Device mapper support
      <*>     Crypt target support

Now, the theory here while making your kernel and your initramfs is kind of
important.  Your initramfs will literally contain a basic filesystem
structure: /bin /sbin /dev /proc /sys /lib /usr /etc.  It will also have a
very basic shell, usually busybox that, like bash, can be used to execute
scripts.  Most importantly, it will have a copy of the cryptsetup binary which
will be what you use to decrypt your encrypted file system.

Gentoo, unlike most distributions, does what's called dynamic linking.  That
means that when you compile a binary in gentoo it doesn't normally include all
the libraries that the program will need in order to run.  Rather it includes
a pointer to the current location of that library.  That's why you need to run
revdep-rebuild whenever fundamental libraries are changed.  All that
revdep-rebuild does is use the ldd utility to find out what libraries are
dynamically linked in a binary.  If it finds a link that isn't there anymore,
it will suggest you recompile the program to reestablish those links.

In an initramfs, however, neither the kernel nor any executable will have
access to most of the libraries they would normally need.  Therefore, you have
to be sure to compile any of these required binaries without dynamic linking,
a.k.a. with static linking.

The cryptsetup-luks package should default to -dynamic, but if you have
dynamic in your make.conf it might not be.  You can verify that
/sbin/cryptsetup is statically linked if you get this output when you check it
for dynamic linking: 

# ldd /sbin/cryptsetup 
	not a dynamic executable

When you create an initramfs using genkernel, you'll need to tell it to
install the dm-crypt luks capability.  For once, RTFM will fail you.  If you
look at the man page for genkernel, you wont see any mention of dm-crypt or
luks.  However, checking the output of genkernel --help will tell you: 

# genkernel --help | grep luks
	--luks		Include LUKS support
			--> 'emerge cryptsetup-luks' with USE=-dynamic  

And, that's what you'll want to do when the time comes.

As far as partitioning scheme is concerned: at a minimum you'll need a boot
partition, a swap partition, and a root partition.  The swap and root will be
encrypted.  The boot will be unencrypted.  It is very possible to move the
boot partition off the hard disk entirely, such that you have to boot from a
usb flash drive or cdrom.  However, the benefits are questionable to me.  The
only real advantage to physically separating the kernel from the disk would be
if you chose a complex, impossible to remember key stored as a text file on
your boot media.  You would, of course, have to maintain physical control over
the boot media at all times then and have back-ups available somewhere for
when it fails or gets lost.  Otherwise, anyone could simply use any liveCD and
still get your comp to boot--most liveCDs have dm-crypt by default.  You might
be able to prevent anyone from tampering with your kernel, but I'll show you
how to quickly detect any tampering.  Also, if someone has physical access to
your drive like that, you have bigger issues to worry about, if you know what
I mean.

#############################
### Part II: The Practice ###
#############################

Assumptions:
1. Your hard disk is /dev/hda
2. Boot will be /dev/hda1
3. Swap will be /dev/hda2
4. Root will be /dev/hda3

I. Back-up your old stuff

  # rsync -avz --progress /source /destination

  - Leave out temp files like /proc and most of /var, but include /dev.

II. Prepare hard disk

  1. Boot from LiveCD (Gentoo minimal or Knoppix recommended)

  2. Don't mount anything

  3. # shred -n 1 -v /dev/hda

  4. Use fdisk to paritition the disk into /dev/hda1 /dev/hda2 /dev/hda3

  5. Use the appropriate mkfs to create the file system on your boot partition
  (recommend ext2 or ext3 since they're so stable and GRUB knows them well)

III. Create encrypted partition

  1. While booted from LiveCD, create encrypted root partition at /dev/hda3:

    # cryptsetup luksFormat /dev/hda3 --cipher aes-cbc-essiv:sha256

    You will be asked to supply a password.  If you choose to use a text
    file as a password, simply enter the path to the keyfile at the end of the
    line, like so:

    # cryptsetup luksFormat /dev/hda3 --cipher aes-cbc-essiv:sha256 \
           /path/to/keyfile.txt

  2. "Open" the now encrypted partition:

     # cryptsetup luksOpen /dev/hda3 root

     You will need to supply the password or keyfile (via --key-file) again.
     This will create a fake device at /dev/mapper/root which can be
     manipulated just like a disk drive.

  3. Format the root partition just like you would any other partition...

     # mke2fs -j /dev/mapper/root

IV. Transfer the backup to the encrypted partition

  1. While booted from LiveCD, mount the root partition.

     # mount /dev/mapper/root /mnt/gentoo

  2. Copy the backup to the new partition.  Again, I suggest using the rsync
  method.

     # mkdir /mnt/backup
     # mount /path/to/backup/device /mnt/backup
     # rsync -avz --progress /mnt/backup/ /mnt/gentoo

  3. Make your boot partition

     # mount /dev/hda2 /mnt/gentoo/boot
     # rsync -avz --progress /mnt/backup/boot /mnt/gentoo/boot

     Mounting /dev/hda2 over your already existing (and full) /boot directory
     will obscure what is normally there.

  4. Chroot into the encrypted partition.  No need to copy /etc/resolv.conf
  since your backup should have a working version, but if networking doesn't
  work, make sure that you have what you need there.

     # mount -o bind /dev /mnt/gentoo/dev
     # mount -t none /proc /mnt/gentoo/proc
     # chroot /mnt/gentoo /bin/bash
     # env-update && source /etc/profile

#######################
# Building the Kernel #
#######################

1. Genkernel does not gracefully handle manual kernel configuration.  The
   trick is to do a make menuconfig separately, saving the configuration
   someplace handy.  Then you can call genkernel with the --kernel-config=
   option to force it to grab your chosen config.

   Ensure that all the appropriate filesystem, hard disk hardware drivers, and
   crypto are built-in.  Also, use build-in the device-mapper capabilities.

2. Genkernel ( http://www.gentoo.org/doc/en/genkernel.xml )

   # cd /usr/src/linux
   # genkernel --kernel-config=customkernelconfig --luks all

   This will create the new kernel in your /boot directory as well as an
   initramfs file.

3. Update grub

   Example:

   # For booting Linux from encrypted partition
   title Encrypted Root Hardened Gentoo 2.6.21-r3-090607
   root (hd0,1)
   kernel (hd0,1)/kernel-genkernel-x86-2.6.21-hardened-r3 \
   video=vesa:ywrap,mtrr:3,1024x768 at 60 vga=791 pci=routeirq root=/dev/ram0 \
   crypt_root=/dev/hda6 ro
   initrd (hd0,1)/initramfs-genkernel-x86-2.6.21-hardened-r3

   The important thing is to send root=/dev/ram0 and
   crypt_root=/dev/for/encrypted/root to the kernel.  The crypt_root option
   tells it to try to open root with LUKS.  The root=/dev/ram0 option (never
   anything else) tells the kernel to use the initramfs.

   Be sure to include the initrd line with the path to the initramfs so that
   the kernel knows to use it.