I installed Debian "Etch" (which is now the testing release of Debian) on a Thinkpad T42.
The installation went fine, no problems at all. I opted to encrypt my hard disk; I now have a 2GB swap (/dev/hda3) encrypted partition (overkill), a 128MB boot partition (/dev/hda1) that is unencrypted, and the rest encrypted (/dev/hda2).
On bootup, the system asks for a LUKS passphrase which is needed in order to decrypt the harddisk. However, an intruder could possibly alter the unencrypted /dev/hda1 partition, changing the kernel and/or initrd, thus having total control over the system. This could mean that this intruder installs a keylogger that captures the LUKS password, therefore rendering the encryption useless.
In order to avoid this, I bought an USB stick and installed the kernel and initrd there. Furthermore, a decryption key is on the stick, so that I do not longer have to enter a passphrase. This means that I never keep my laptop and this USB stick at the same place.
The first part of this document is dedicated to setting up Debian on a Thinkpad T42. The second part will deal with the USB-stick and encryption part, which should be suitable for any Debian-powered pc (or even any other GNU/Linux-system using dm_crypt), not only for Thinkpads.
I hope that you find this document useful. However, I did not carefully check for errors. If you want to send corrections, please do so, but I do not assume any responsibility for any errors in this document, or anything that goes wrong while following instructions in this document.
You use this document on your own risk.
Madwifi is still "beta software", its developers write:
THIS IS A BETA DISTRIBUTION. THIS SOFTWARE HAS KNOWN PROBLEMS
AND LIMITATIONS THAT WILL BE CORRECTED BEFORE A PRODUCTION
RELEASE. DON'T BLAME US IF THE SOFTWARE EATS YOUR SYSTEM,
DESTROYS YOUR DISK OR MAKES YOUR CORN-FLAKES SOGGY.
USE AT YOUR OWN RISK!
Remember: MAKE BACKUPS OF ALL YOUR DATA BEFORE DOING ANYTHING!
I have a Thinkpad T42 (to be precise, a 2373-A23).
Here is the lspci output:
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
02:00.0 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01)
02:00.1 CardBus bridge: Texas Instruments PCI4520 PC card Cardbus Controller (rev 01)
02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03)
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
This Thinkpad contains an Intel Pentium M processor (1.70 GHz), and 768 MB RAM.
This system has, as you can see in the lspci-output, an Atheros AR5212-chipset for Wireless LAN. Other Thinkpad T42 systems may have another chipset: while browsing the Internet, I came across Thinkpads needing the ipw2100-drivers numerous times. Be sure to check your lspci-output before wasting time installing the wrong drivers.
You'll need several packages to build the madwifi-drivers:
# apt-get install gcc-4.0 build-essential subversion
Get the latest snapshot of the madwifi-drivers:
$ svn checkout http://svn.madwifi.org/trunk madwifi
Build the driver:
$ cd madwifi
$ make CC="gcc-4.0"
Install the driver:
# make install
Load the driver:
# modprobe ath_pci
If you want the the driver to be loaded automatically when booting:
# echo ath_pci >> /etc/modules
In order to use WPA with the madwifi-driver you need wpa_supplicant. The one provided in the Debian repositories didn't work for me, probably because it is not compiled with madwifi-support. I got wpa_supplicant from here. I use version 0.4.8, which works.
You need the SSL development package in order to build it successfully:
# apt-get install libssl-dev
Unpack wpa_supplicant:
$ tar zxf wpa_supplicant-0.4.8.tar.gz
$ cd wpa_supplicant-0.4.8
Fire up your favorite editor and place a file named ".config" in this directory. The contents should be:
CONFIG_DRIVER_MADWIFI=y
CFLAGS += -I/home/jochem/wlan/madwifi-ng # or wherever your madwifi-sources are located
CONFIG_CTRL_IFACE=y
CONFIG_EAP_TLS=y
CONFIG_EAP_PEAP=y
Now build wpa_supplicant:
$ make
And install it:
# make install
Now create a configuration file for wpa_supplicant. What exactly should be in there, depends on your wireless network configuration. Again, the wpa_supplicant configuration provides details. If you have a simple wireless network (a default "home" network with WPA and a pre-shared key (PSK)), you can use the wpa_passphrase utility.
I have configured the "ath0" (wireless) interface coming up on bootup. My /etc/network/interfaces file:
auto lo ath0 eth0
iface lo inet loopback
iface eth0 inet dhcp
iface ath0 inet dhcp
pre-up sh -c "/usr/local/sbin/wpa_supplicant -c /etc/wpa_supplicant.conf -i ath0 -D madwifi &"
post-down sh -c "/usr/bin/killall wpa_supplicant"
The Pentium M processor is capable of speedstepping , saving power and generating less heat. In order to do this, I needed to use kernel modules "speedstep_centrino" and "cpufreq_userspace". These are included in the Debian Etch distribution.
Load the modules:
# modprobe speedstep_centrino
# modprobe cpufreq_userspace
In order to automatically load them at boot time:
# echo speedstep_centrino >> /etc/modules
# echo cpufreq_userspace >> /etc/modules
Install the PowerNOW! daemon (which does work for PowerNOW! but also for SpeedStep):
# apt-get install powernowd
Now SpeedStep should work! You can see the current processor speed by entering:
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
The minimum frequency for this CPU is 600000, and the maximum is 1700000.
If it does not, check that the following command displays "userspace":
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
If this is not the case, enter:
# echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
Sleep mode works. You need, however, to add the following option to your kernel options:
acpi_sleep=s3_bios
You can (and should, in order to keep this setting after a Linux upgrade)
do this by adding that in the /boot/grub/menu.lst, after "kopt=". Your
kopt-line may look like (before adding the acpi_sleep line):
kopt=root=/dev/hda2
Mine is the following:
kopt=root=/dev/mapper/crypt0 ro acpi_sleep=s3_bios
After doing this, run "update-grub" as root and reboot.
You can now enter sleep mode by entering:
# echo mem > /sys/power/state
Your screen may look corrupted. You can fix this by using:
# chvt 1 && echo mem > /sys/power/state && chvt 7
You can even put this in a script that is automatically executed when you close your
laptop lid. To do that, install acpid:
# apt-get install acpid
Create a file named /etc/acpi/events/lid containing:
event=button[ /]lid
action=sh -c "chvt 1 && echo mem > /sys/power/state && chvt 7"
If it does not work, make sure that acpid is started:
# /etc/init.d/acpid restart
This worked fine with Debian Etch at the time I didn't have my harddisk encrypted.
# echo disk > /sys/power/state
Since I now encrypt my swapspace with a random key, I cannot recover from a suspend. This is not a top priority for me.
However, if you encrypt your harddisk, do not use suspend unless your swapspace is encrypted as well; it would be pointless to encrypt your harddisk if you do not have encrypted swapspace as well.
As stated before, I have encrypted my harddisk. This basically means that intruders need to do (a lot) more work than just booting from a LiveCD such as Knoppix or Finnix and mounting the harddisk to view its contents. I believe that for a casual thief it is intractable to view the contents, and even more sophisticated attackers will have a more difficult job before they can look at the data. This can be important because you are paranoid (like me), or you have secrets that you do not want to reveal. Maybe you do not like the idea that a random person who obtains your computer can look at all your private files, or maybe you have trade secrets you don't want a competitor to see.
With the newest Debian "Etch" installer (I used "beta 3") it is quite straightforward to encrypt your harddisk. You can get this installer here. You might want to use the bt-dvd or bt-cd directories if you have BitTorrent client (if you do not, you can get one here, or you can apt-get install bittorrent-gui): this is probably faster and saves the Debian project bandwidth.
You probably want the first DVD if you have a DVD burner. If you don't, but you have an internet connection on the pc you are installing Debian on, you should be able use a "net installation", or using only the first CD and after installation getting other packages off the Internet (that's the way I installed it).
Make sure you encrypt your swapspace as well. If you do not, encrypting your root partition is nearly useless.
I recommend you encrypt all your partitions, not only your /home partition. All kinds of information "leak" from your /home partition to other partitions, such as /tmp and /var while using your computer. I do not notice any speed difference in daily use (although you will if you use a benchmark), so there is not really a reason to do otherwise (at least not for a single-user system such as mine).
BACKUP YOUR DATA before you begin! This is absolutely necessary; however make sure that you securily wipe the backup if your backup was unencrypted. Also, during the Debian installation, "shred" the harddisks (this is the default if I'm not mistaken) so that no old (unencrypted!) data is remaining on the harddisk.
When using an USB-stick with a key file, remember that you should remove the USB-stick at the earliest possible opportunity: after the disk has been mounted successfully and the "INIT: Version XXX loading" message appears. Making a habit out of this is necessary for security, if you forget it once and you leave your computer alone with your USB-stick nearby, intruders may use this to their advantage (i.e., gaining access to your harddisk).
Harddisk encryption is nice, but it is useless if you do not secure your software as well. If attackers gain access to your system (either having a regular user account, or having the root account), your data is no longer safe. Therefore, protect your system by using a firewall and always installing security updates. Use strong passwords.
I have made an USB-stick that is bootable and contains Linux (the kernel) and an "initrd" (an initial RAM disk). The initrd is used to set up things after Linux loaded, but before "init" starts. "init" is the "mother process" that starts all other processes, such as "xdm" and "acpid" (this is a simplification, but I hope the point is clear).
If you use the encryption provided by dm_crypt, the default for Debian Etch if you use encryption, the "initrd" that is provided asks you for your passphrase. After that, it mounts the root device and "init" starts. In order to use a key that is provided on an USB-stick, we must adapt a few things:
I use "initramfs". Make sure you have it by entering:
# apt-get install initramfs-tools
I created a file that takes care of the above four points.
Save this file to /usr/share/initramfs-tools/scripts/local-top/cryptroot, and make it executable by
entering:
chmod 755 /usr/share/initramfs-tools/scripts/local-top/cryptroot
I clearly marked my changes. You can review my changes, and/or use "diff" to check that there is nothing suspicious included.
You can use this file by entering:
# cp /boot/initrd-2.6.16-2-686 /boot/initrd-backup
# dpkg-reconfigure linux-image-2.6.16-2-686
Make sure the last command uses "initramfs", not "yaird". You can see this by watching the output
carefully.
(If you encounter problems during the next reboot , enter "e" at the GRUB prompt, move to the line beginning with "initrd", enter "c", and change it to "initrd /initrd-backup". If that does not work, use "initrd /boot/initrd-backup". This way you should always be able to boot, using your previous setup.)
Reboot, and check that this "initrd" image works. It should complain about not being able to mount the harddisk with the USB-stick, and then ask for your passphrase. After entering it, everything should be normal. This way, you can make sure that if something goes wrong with the key on your USB-stick, you should be able to boot using your passphrase.
Now, create a root.key file on your usb-stick:
# mount /dev/sda1 /mnt
# apt-get install sharutils
# dd if=/dev/urandom bs=1 count=4096 2>/dev/null | uuencode - | head -n 93 | tail -n 92 > /mnt/root.key
# chmod 400 /mnt/root.key
# cryptsetup luksAddKey /dev/hda2 /mnt/root.key
Now enter your passphrase twice; after that cryptsetup should give a "success" notice.
# umount /mnt
Reboot again. Make sure your USB-stick is inserted on time (when the GRUB-screen appears). The default script waits 10 seconds, this should be enough. If your USB-stick is not recognized as /dev/sda1, adapt /usr/share/initramfs-tools/scripts/local-top/cryptroot, enter dpkg-reconfigure linux-image-2.6.16-2-686 again, and try again.
After this, the USB-stick can be made bootable. You should never boot from your /boot-partition on your harddisk again: intruders may have altered this partition. If you keep your USB-stick safe, they must crack the encryption (probably not easy), use a hardware keylogger, or use other means (finding an unencrypted backup, sniffing unencrypted e-mail with sensitive data, torture, finding prints of the sensitive data, ...) to gain access to your data.
Copy the kernel and the initrd to your USB-stick:
# mount /dev/sda1 /mnt
# cp -a /boot/* /mnt
# touch /mnt/thisistheusbkey
# sync
# grub
.. wait for the grub prompt to appear ..
find /thisistheusbkey
... now a disk should appear, in my case it was (hd1,0)
root (hd1,0) # Adapt: if your disk was (hd3,0), make it (hd3,0), etc.
setup (hd1) # Adapt: if your disk was (hd3,0), make it (hd3), etc.
Reboot. Configure your BIOS so that it boots from the USB-stick, and try it. GRUB starts a little slower than usual, but it should work.
Once everything works, you can remove (or comment out by putting a # before it) the line in /etc/fstab containing your /boot partition. You no longer need it, it is only there for recovery purposes.
If you ever need to upgrade your kernel, first mount your USB-drive: mount /dev/sda1 /boot. That way, your USB-drive should contain the new kernel.
As a final step, you could remove your passphrase from the permitted keys. This is done as follows:
# cryptsetup luksDelKey /dev/hda2 0
I do not recommend it: your data now depends fully on the USB-stick. If you lose it, or it becomes damaged
or corrupt, I do not know of any way to recover your data.
If the USB-stick does not mount, check that it is recognized as /dev/sda and that it has only one partition. You can see this when it is detected during bootup: the kernel will inform you about the device that it has been assigned. When you know which device it is, adapt /usr/share/initramfs-tools/scripts/local-top/cryptroot and enter dpkg-reconfigure linux-image-2.6.16-2-686 and try again. Make sure that Linux has enough time to detect the stick, using the kernel option "waitusb=30" should help. Make sure the USB-stick has only one partition, and that partition should be formatted using "ext2" (mke2fs /dev/sda1 in my case)
If the USB-stick mounts, but decryption failed, check that there really is a root.key file on the disk.
Make sure that the key is added to the "keyring" of LUKS. You can see what keys are permitted by entering:
# cryptsetup luksDump /dev/hda2
You should have two keyslots enabled (one is your passphrase, one is your USB-stick).
If you lose your USB-stick, you have two choices:
Whatever you do, remove the key on the USB-stick from the list of keys. In my case, this would be key "1".
(My passphrase is key "0".):
# cryptsetup luksDelKey /dev/hda2 1
This way the attacker cannot use the USB-stick to gain access to your data.
If you decide to trust your boot-partition, delete the key as indicated before, and create a new key and a new bootable USB-stick.
For the paranoid: you can hash all files on your boot partition (using SHA-512 for example) and printing it, storing it somewhere safe. If you lose your USB-stick, check your boot partition for altered files by hashing them again and looking for differences. You can then decide if you want to trust your boot partition.
If you find your USB-stick, you cannot use it anymore to use your harddisk. You can format it and re-use it for any purpose.
If you lose your computer, securely wipe the root.key-file on your USB-stick. I prefer to wipe the whole stick because "smart" sticks may evade the wipe in order to prevent wearing out. After that, trash it completely, burn it, and flush it in pieces down different toilets, depending on your paranoia and the sensitivity of the data involved.
If you get your computer back, you can follow the instructions under "If you lose your USB-stick".
You can send questions, criticism and comments to j dot f dot berndsen AT student dot tue dot nl.
This document has been put in the public domain. If you use it in one way or another, I would like to be mentioned, but this is not obligatory.