Thursday 9 February 2012

Quickpost: Disassociating the Key From a TrueCrypt System Disk

TrueCrypt allows for full disk encryption of a system disk. I use it on my Windows machines.

You probably know that the TrueCrypt password you type is not the key. But it is, simply put, used to decrypt the master key that is in the volume header.

On a system drive, the volume header is stored in the last sector of the first track of the encrypted system drive (TrueCrypt 7.0 or later). Usually, a track is 63 sectors long and a sector is 512 bytes long. So the volume header is in sector 62.

When this header is corrupted or modified, you can no longer decrypt the disk, even with the correct password. You need to use the TrueCrypt Rescue Disk to restore the volume header. This rescue disk was created when you encrypted the disk.

I’m using Tiny Hexer on the Universal Boot CD For Windows to erase the volume header (you can’t modify the volume header easily when you booted from the TrueCrypt system disk; using a live CD like UBCD4WIN is one possible workaround).

Take a look at the CHS (Cylinders Heads Sectors) value: S = 63 confirms that a track is 63 sectors long.

Then I open the system drive with Tiny Hexer (notice that the sector size is 512 bytes or 0x200 bytes):

I go to sector 62, the last sector of the first track:

It contains the volume header (an encrypted volume header has no recognizable patterns, it looks like random bytes):

Then I erase the volume header by filling the sector with zeroes and writing it back to disk:

And if you absolutely want to prevent recovery of this erased sector, write several times to it with random data.

Booting is no longer possible, even with the correct password. The TrueCrypt bootloader will tell you the password is incorrect:

One can say that I’ve created a TrueCrypt disk that requires 2-factor authentication. To decrypt this disk, you need 2 factors: the password and the corresponding TrueCrypt Rescue Disk.

First you need to boot from the TrueCrypt Rescue Disk, and select Repair Options (F8):

And then you write the volume header back to the system disk. Remark that the TrueCrypt Rescue Disk requires you to enter the password before it writes the volume header to the disk:

And now you can boot from the system disk with your password.

Use this method if you need to travel with or mail an encrypted system disk and want to be 100% sure there is no way to decrypt the drive while in transit. But don’t travel with the 2 factors on you, send the TrueCrypt Rescue Disk via another channel.

It would be very nice to have true two factor authentication for truecrypt in fulldisk mode. I think this is one of the few things missing on this otherwise great software. It would put it on par with other paid solutions, like for example Safeboot or Bitlocker (not sure if bitlocker supports two factor with an external key on pendrive).

One idea would be perhaps to change the password for the encrypted volume after you created the rescue disk. If you change it to something incredibly long and random (which not even you would know), it would be, for most effects, as good as not having it at all. You could for example type randomly on the keyboard or generate a large random string to use as the password. One scenario where I think this would not suffice would be if you’re in a position such as being compelled to give the password for the encrypted volume. A forensic analysis on the harddrive would show that the header is still there, so you “should” have the password. But if the header is not there to start off, I can see a more plausible reasoning in claiming that it’s impossible to decrypt.

@R Actually, a forensic analysis can’t show that the header is there if there is no password to decrypt the header. The encrypted header has no structure, it looks like random bytes. What a forensic analysis can show is the absence of a header. For example all bytes are null.

@Jelbo I believe what you want to say is that recovering data from a overwritten drive is an urban legend.

I agree, but there are a couple of differences here. I don’t know if these differences are significant, as I’ve not researched this (this is a QuickPost).

The differences are:
1) we are not talking about recovering a complete disk, but at most 256 bytes
2) even recovering parts of the encrypted key could reduce the key space to search
3) the key is written in sector 62, which is not normally written to. On unencrypted disks, this sector remains pristine. And on TrueCrypt system disks, this sector is only written to once at disk encryption time as long as you don’t change the password

Again, I’ve not researched if this actually makes a difference. But I’m being cautious.

Very useful article; and perhaps a useful feature for Truecrypt to include in a future update!

The issues with deleting data are well known and I will not belabour them here. However a single overwrite with 0’s or 1’s would be good enough, Writing a 1 and then a 0 to each bit would probably be overkill but not time-consuming an would ensure that each bit has been set and reset once.

Overwriting with a known pattern would be better so you would be able to identify the reason for the data being erased. e.g overwrite the data with repeats of 0xDEADBEEF would reveal the reason why the data was overwritten. Random data or misleading data might be better though. Writing back a standard volume header might be better.

There are urban legends about recovering overwritten data but they are seemingly just that. No one claims to be able to do this in the visible world and the shadow world would find it a very difficult task. When it has been attempted it seems to give worse results that randomly guessing if a bit was 1 or 0.

A more plausible issue would be either overwriting the wrong sector by accident (or even worse perhaps) by design. Malware which tampers with the overwriting process would lead to a situation where you thought you had deleted the data but hadn’t.

You might then send the encrypted volume off to a third party (and the recovery disk via another route) only to find the data had been decrypted enroute (unknown to you).