Cold boot attack, not a threat to Full disk encryption (FDE)

Since the new cold boot attack hack is on the news, touching most of the software encryption solutions, I have wondered if it had any chance to concern also hardware encryption.

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 ?