These days with larger and larger drive capacities, erasing stored data takes longer and longer. Another problem is also the inability to do so when the time comes, due to bad sectors or hardware failures. Just because the data is not accessible by you does not mean that it is also inaccessible to someone else with the know-how.

Cryptographic erasure to the rescue!

Crypto erase simply erases the encryption key that is used to encrypt the data on your drive. This is the primary reason why I encrypt my drives.

Oddly, I have not found anyone talking about BitLocker crypto erasure or doing it. The closest I have seen is manage-bde -forcerecovery, which removes all TPM-related key protectors. This is briefly described in a TechNet article titled BitLocker™ Drive Encryption and Disk Sanitation.

But what if we are not running Windows? What if the disk is not a Windows boot drive that is protected by a TPM key protector?

In order to erase the (key) data, we first need to know how the data is stored on disk. For open-source FDE implementations, this is easy because the disk format is well-documented, but BitLocker is not exactly open.

BitLocker Disk Format

BitLocker was first introduced in Windows Vista and has gone through changes since then. Some changes were made to the format in Windows 7, but has largely remained unchanged through Windows 8 till 10.

For LUKS, it is simple – there is a LUKS header at the start of the disk, followed by the encrypted volume data. For BitLocker, it is slightly more involved, probably due to backward-compatible design considerations.

The header at the start of the partition is a valid boot sector (or boot block), so not all BitLocker information can be stored within. Instead, this volume header points to the FVE metadata block where most of the data is kept. In fact, there are 3 of these for redundancy. This metadata block is what holds all the key material.

The metadata blocks are spaced (almost) evenly apart, located near the start of the volume.

# blwipe -offset 0x2010000 bitlocker-2gb.vhd
metadata offset 0: 0x02100000
metadata offset 1: 0x100c8000
metadata offset 2: 0x1e08f000
metadata block 0 (size 65536): parsed OK
metadata block 1 (size 65536): parsed OK
metadata block 2 (size 65536): parsed OK

The first metadata block usually begins at 0x02100000. This illustration depicts the locations for a 2 GB volume:

If there are 3 of these blocks, how do we know know which ones contain valid data?

Continue reading →