At least until I found this very instructive article, “Disk Wiping – One pass is enough“. Don’t miss the second part which clarifies some points and gives more details.

In short, after one pass, every bit of the disk is filled with zero and there is simply no way to find out what the previous value was. Even the best tools out there have no clue to do it.

Then, there is a theory of physically restoring each bit using a magnetic force microscope. It has always came with a high error rate, and with modern high density disks it is even less reliable. Now, considering any real world data length, errors occurring on the restored bits would make it impossible to rebuild any usable data. There is obviously no chance for such a technique to recover a file.

So, in the future, I will not only save time doing one pass, but I will replace :

$ dd if=/dev/urandom of=/dev/sda

with

$ dd if=/dev/zero of=/dev/sda

Note that formating just reset the partition table. In no way it clears out every bit of the disk.

Hardware encryption is provided by a few laptop makers, generally on high-range an business models.

It has much less performance impact than software encryption, and protect the data independently from your system configuration and its partitions.

Full disk encryption is the so called hardware encryption technology used by Lenovo on my Thinkpad.

Mine comes with a Hitachi hard drive. Hitachi names its encryption technology “Bulk Data Encryption”.

I know at least Seagate provides the same kind of feature.

The bulk data encryption is based on the AES algorithm with a 128 bits key.

Actually, the encryption is not done by the laptop itself but by the hard-drive.

You need both the hard drive and the laptop supporting encryption , for the following reasons :

1. your motherboard must have a TPM chip, which is used for the encryption, as a unique source to derivate the encryption keys.
2. the BIOS must interface with the hard drive FDE, to set/unset the encryption and to prompt for the password before the real boot (actually, a small OS embedded on the drive take care of this authentication).

In reality, the encryption is always active and the password to access to the drive is just another security feature. There is no link between these two functions. That’s why the fact of setting a password is immediate : no reencryption is done because the password has nothing to do with encryption.

In case of authentication success, the system boots normally.

In case of failure, and if the maximum number of attempt is reached, the data is erased. Instead of initializing the content with 0, which would take a lot of time and could be interrupted by shutting down the machine, just the keys are destroyed within a few seconds.

Anyway, the content is supposed to be very hard to retrieve thanks to the effectiveness of the AES algorithm.

One important thing is that the key is not a derivate of the password you set.

The hard drive password is a feature that does not come necessarily with encryption.

It is just there to limit the access of the content, but not its confidentiality.

For instance, you could imagine that if the drive is stolen, someone opens physically the drive, change the ROM to pass over the password and read your data without any pain.

The con of that is the encryption keys generation is based on your hardware. A different hardware can’t decipher the drive.

If your motherboard breaks down, you won’t be able to read your data from another computer ! Make some good backups…

To go back to the main topic, is the cold boot attack a threat for this hardware encryption ?

No. The encryption algorithm is not in the user land, so no key is stored in RAM.

The key hashes are stored directly on the disk.

These documents from Hitachi provide more detailed information :

Bulk encryption white paper

HowTo guide for bulk data encryption

This Wikipedia article, underlining the main points of hardware encryption,  is also interesting.

I guess that at some point it would be possible to read some hash on the hard drive electronic board, but this is not going to be easy. You need to be a hardware expert in hard drives and for sure it can’t be done as quickly as with the RAM chip.

Of course, even the cold boot attack is extreme. Most of thief won’t care about your data, or won’t be the knowledge or the practical possibility to conduct a successful attack.

If you don’t have FDE support, you should continue to use an encryption solution like dm-crypt or Truecrypt and maybe consider turning off your computer more often.

It anyway remains an excellent solution for external disks, as it is normally not all the time attached to your computer.

Personally, as FDE offers more performance and transparency, I am using it on my laptop but I keep using dm-crypt on all my external drives.

Now the question is : what good workaround can be found to provide more secure software encryption ?

A team of researchers found a way to defeat all the most common disk encryption methods – including dm-crypt for Linux that I previously described on this blog.

A team of researchers found a way to defeat all the most common disk encryption methods – including dm-crypt for Linux that I previously described on this blog.

All systems are actually concerned, because the attack is low level. It is based on the RAM chips properties. After shutdown, and therefore no more electricity powering, a chip will still contain some readable information during a few seconds.

The data contained is deteriorating, but for example if you cool the chip enough, for example with a computer dry air dust cleaner, you can keep the data several minutes !

The problem concerning data encryption is that the decryption key is kept in RAM, and that way be stolen to read all your data.

The attack would not so easy in practice, if suspend-to-ram did not exist.

But as many users, including me, use heavily suspend-to-ram with their laptop, this issue is rather problematic…

The team provides a rather impressive video :

I no longer use dm-crypt since my Thinkpad provides hardware encryption, but I wonder now where the key is stored in my case. I don’t think it is in RAM, but I have to check it to make sure.I will do it tomorrow, since I need to rest now.

An external hard drive that I just bought (320 Gb) that allowed me to back up my entire /home partition and consider encrypting it.

I mainly used this tutorial, but I derived a little from it about the unlocking system : I did not want to input a password while the machine boots, I wanted it to be transparent while I log in. This how to provides more complete information, if needed.

So I will summarize here the actions to get an encrypted volume.

The tools

dmcrypt is a device mapper supported by the 2.6 Linux kernel. Roughly, this is an abstraction layer between the kernel and the real file system, doing all encrypting / decrypt operations. It is a replacement of cryptoloop, which created a loop device in a file within the file system. It can’t encrypt a whole partition and can be considered now as less reliable and secured.

The encryption is based on LUKS is a userland tool aiming to simplify the set-up of dm-crypt. It also stores some set-up information related to the encryption in the partition header, to make easy the transportation of the data from a machine to another, changing the passphrase without having to re-encode the entire partition, and even support having multi passphrases for the same device.

What to encrypt and why ?

The first thing is to decide what you will encrypt and how. Of course, I consider that your drive is rightly partitioned with, at least, the /, /home and swap having each a separated partition.

It is the case on my laptop. I chose to encrypt both the /home and the swap partitions.

In my case, there were little interest in encrypting the / partition. It contains only configuration files (without any password hardcoded), the /temp and applications – nothing to keep secret. But of course it might be different for you, depending on the security level you are looking for.

To the contrary, the /home partitions contains a lot of private data that I wouldn’t like anyone access in any case.

Then, it is rather important to encrypt the swap, because it is roughly a partial of you RAM and therefore contains all kind of information from your opened session. The annoying thing is that hibernation (suspend to disk) will not work anymore. It is anyway worth to be done, as it is well explained by this blogger.

Preparing the software

Using Debian Etch or Ubundu Festy/Gutsy, it is easy though the provided kernel (2.6) already supports device mapper, crypt target and AES cipher algorithm as modules :

$ apt-get install dmsetup cryptsetup libpam-mount

Encrypting swap

UPDATE 2008/04/13 : it is now possible to encrypt the swap in a way that preserve suspend-to-disk.

It is a good test to start with the swap, as there is no risk that you loose some valuable data.

First, let’s deactivate the current swap before any operation :

$ swapoff /dev/hda2

We suppose that hda2 is your swap partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda2

add this line to the /etc/crypttab file :

swap    /dev/hda2       /dev/urandom     swap

It means that we are going to create a mapper named swap for the /dev/hda2 device. It will use a random key as a passphrase for the encryption.

There is a choice to do between /dev/random and /dev/urandom. The latter is in theory a little bit less secure (the randomizing is inferior to the /dev/random, as it reuses the internal pool data for the generation), but it is preferable if you don’t want to be blocked at boot time, while the kernel is trying to get more entropy (you can shorten this by pressing some keys, though).

Now starts this script :

$ /etc/init.d/cryptdisks start

It will create a mapper named swap to the /dev/hda2 partition, as set in the crypttab file.
This is equivalent to this command :

$ cryptsetup -y create swap /dev/hda2

Now, we need to create the file system :

$ mkswap /dev/mapper/swap

Now we need to update the /etc/fstab file, commenting the old entry for hda2 and adding a new one for the mapped device :

/dev/hda2       none            swap    sw              0       0
/dev/mapper/swap        none    swap    sw      0       0

Now you are ready to test ! Just reboot, and without any user interaction, you should get an encrypted swap with a randomized key.

Encrypting /home

Now let’s encrypt the /home. Before doing anything, be SURE that you made a BACK UP of ALL your data. The entire /home will be ERASED !

We consider that hda3 is the /home partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/had
$ cryptsetup -y create home /dev/hda
$ mkfs.ext3 /dev/mapper/home

We won’t use neither the crypttab file or the fstab one, because we don’t want to be prompted at boot time for a password. And of course we can’t afford to crypt our data with a randomized key, changing at every boot !

What we want is the encryption to be done at log-in time, without prompting the user for another passphrase. Don’t we have enough passwords to memorize to add one more !?

We are going to use PAM, the Linux authentication mechanism, with its libpam-mount module. It is designed to mount some devices while the user log in, exactly what we need ! The user Linux password will be used as the encryption passphrase.

Of course, the security level will depend on your user password – take a good care on its length and complexity (though it must be already the case, encryption or not). A good compromise is probably an 8 digits password. Of course, if you are looking for the top level security, prefer the boot time passphrase prompting method…

To activate it, create or edit the /etc/security/pam-mount.conf.xml file and add this line :

<volume user="user" fstype="crypt" path="/dev/mapper/home" mountpoint="/home" options="fsck,relatime" />

Also add this at the end of the /etc/pam.d/common-auth file :

# cryptsetup
auth    optional        pam_mount.so use_first_pass

That’s done ! Testing is easy : log off, log in and check that your /home partition is well monted. It should not been mounted or readable for other users, including root.

Encrypting a removable device

We assume that you have a usb key (once again BACK UP your data) inserted, corresponding to the /dev/sda device :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sda1

We open manually the luks partition :

$ cryptsetup luksOpen /dev/sda1 usbkey

We format it with the filesystem of your choice (here ext3) :

$ mkfs.ext3 /dev/mapper/usbkey

We close the partition :

$ cryptsetup luksClose usbkey

Now every time you insert the key, you will be prompted for the password (at least by Gnome through the keyring manager box, though I haven’t tested yet with a different window manager).

Conclusion

This was a much easier experience than I previously thought. Much work has been made to hide the complex layers behind that, and it now takes only a few steps to get a pretty well secured hard drive.

However I think it really must become more user-friendly for the masses. Most of people will still be scared to open a terminal and type the commands above, so I am looking forward to seeing some graphical front-end to manage all that. Sure there are coming, and if you already know some project, please let me know.

About performance, if encryption must have a resource cost, I could not notice any slow down on a pretty modest hardware (celeron M 1,5 Ghz).

Just copy the lines from the link in your terminal (you are supposed to run Perl and don’t forget, as I did first, to adjust the path to your disk ;) ) :

Laptop with Hitachi 100 Mb, 7200 rpm (OpenSuse 10.2) :

Took 24.57s for 1500 seeks of /dev/hda (93 GB)
Mean: 16.4ms; Median: 14-15ms; Std dev: 10.6ms

real 0m27.479s
user 0m0.120s
sys 0m0.050s

Server with Hitachi 80 Gb and 120 Gb, 7200 rpm, 8 Mb of cache (Debian 4.0) :

Took 20.15s for 1500 seeks of /dev/hda (76 GB)
Mean: 13.4ms; Median: 12-13ms; Std dev: 5.64ms

real 0m20.184s
user 0m0.040s
sys 0m0.092s

Took 19.5s for 1500 seeks of /dev/hdb (115 GB)

Mean: 13ms; Median: 11-12ms; Std dev: 3.77ms

real 0m19.534s
user 0m0.044s
sys 0m0.076s

Conclusion : I am pretty satisfied by the performances of my laptop disk.

Thanks to the author for this nice script.

Mine was a terrible 4200 rpm Hitachi disk (Travelstar 4K120). Just terrible. My old desktop was often faster just thanks to its 7200 rpm disks.

Morever, I was not trustful anymore in its reliability. It produces an infamous click noise every time the head moves. Infamous, because there are many posts about that on many forums, concerning any laptop brand. It is not the kind of click when a disk dies, as it always did it. I have no evidence of that, but I am pretty sure it is the same model in all cases. It must be a common disk on cheap laptops. Anyway, for me no trick worked to kill this noise : on forums, laptop-mode tool was sometimes accused, and other times the ACPI setting of hdparm.

I looked for a Hitachi Travelstar 7K100 – 100 (~ 130 €). Why this brand ? I am used to it, I have been always buying this brand since they took over IBM and was never disapointed by their speed, their silence and their reliability.

Its main features are the 7200 rpm, a cache of 8 Mb, 10 ms access time and a maximum power consumption of 5,5 W (2 W for reading/writing and 0.5 W idle).

After having used it several days now, I have to say that I am extrimely satisfied.
It is not noisy at all despite its 7200 rpm. It is actually more silent than the 4200 and, very important, the click noise definitely dispeared !!!
About speed, the difference is big too. I don’t want to do a full benchmark here, but every program launches faster and all the system runs smoothly.
As an exemple, my Ubuntu starts in less than 30 s where it took 50 s before (from the BIOS to a fully operational Gnome).
One point I was worried about was its power consumption and its impact on the autonomy of the laptop. Normaly, a 7200 rpm needs more power than a 4200 one. I have been totally relieved now since I don’t see any change.
I was not expecting the last point : temperature. The 4K120 was rather hot : 42°C on normal charge, 50°C on full charge. The 7K100 impresses me : 33°C on normal charge, 39°C on full charge ! As good as the desktop models ! It is not only safer for the data, but it benefits to the whole laptop.

Finally, I recycled the old disk in a USB box. This one, Advance BX-2520, is very cheap (~ 12 €), small and does what it is done for very well.

To transfer the data, I first set up the new disk in the Advance usb box.
I copied the first partition (sda1 is mounted as /) :

$ sudo dd if=/dev/hda1 of=/dev/sda1

Then I resized sda1 to fit my new needs, made up the swap partition and the /home one with Gparted.
I just transfered my /home with a simple cp.
The issue I had was concerning the new way that Ubuntu Edgy addresses partitions (UUID instead of /dev/hdx) :

$ sudo vol_id -u /dev/hda2

or

ls -la /dev/disk/by-uuid/

The output looks like it :

087b3a57-6703-42eb-99d3-278d01618336

It gives you, for instance, the UUID of the swap partition.
I updated my fstab :

UUID=087b3a57-6703-42eb-99d3-278d01618336  none            swap    sw              0       0

Repeat this for all the partitions.
Concerning the swap, to keep the hibernation working, you have to edit /etc/initramfs-tools/conf.d/resume.
The line it contains must be :

RESUME=UUID=087b3a57-6703-42eb-99d3-278d01618336

Finally, to generate a new initramfs image, do :

$  sudo update-initramfs -u -k $(uname -r)

I sometimes back up my primary partition, where the system is set. If my drive crashed, I want to recover quickly a system without having to reinstall hundreds of applications. I have used several times Partimage and was satisfied. But now I tend to use dd, which basically do the same thing in just one line. The advantage is that it is by default on any Linux distribution.

To back it up on an usb disk :

$ sudo dd   if=/dev/hda1   |   gzip   -v   |   dd   of=/media/usbdisk/backup_hda1.gz

To backup my home and other data partitions, I just copy the files manually, it is faster and there is no need to backup such a thing as the boot sector. But of course you could use the same command above.

When you wish to restore the partition to a new hard drive, just :

$ zcat   /mnt/hdb5/sauvegarde.gz   |   dd   of=/dev/hda1

To do that, you will have probably booted on a live CD Linux as Knoppix to restore the crashed system. In any case, don’t overwrite the system you just booted on !

One tip if you want to back up only the boot sector :

$ sudo dd   if=/dev/hda   of=/home/secteur_boot.dd   bs=512   count=1

And to restore :

$ sudo dd   if=/home/secteur_boot.dd   of=/dev/hda   bs=512   count=1