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 :
- your motherboard must have a TPM chip, which is used for the encryption, as a unique source to derivate the encryption keys.
- 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 :
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 ?
Related posts:
Comments 2
In order to be able to successfully steal you password you computer has to be powered on (the key must be held in memory), someone has to take away your (still running) computer and within seconds must cool your (warm!) RAM chips down to below zero degrees celcius.
At a temperature of about -50°C the key could(!) still be available after several minutes. With liquid nitrogen cooling the key may be available for about an hour.
In other words: It requires a lot of effort on the side of the “hacker”. Unless the information you have is very valuable indeed I can’t imagine anyone going to these sort of pains.
As for increased security: You could try to randomly distribute parts of the key across memory. This would increase the chance that some parts of the key are already lost when recovery is attempted. And it would give the attacker less bits to work with in order to positively identify a possible part of the key. You could also add some random key-like sequences to memory. On the other hand: A “distributed” key needs some kind of mapping which tells where the different parts are located and in what order… the mapping might be even easier to find, thus simplifying the process of locating the key parts.
Another note: Your TPM chip also needs to store the key somewhere. Instead of cooling the memory chips the attacker simply has to freeze your TPM chip. Different location, same game. If the key is actually stored in the chip (hardware) it even less secure since it’s not volatile.
Posted 19 Mar 2008 at 7:22 pm ¶Both suspend-to-disk and suspend-to-ram is vulnerable, so the “powered on” requirement is misleading. In order for this to be not effective, the laptop must be turned off completely.
Personally, I think this is mostly important when keeping other people’s data. Currently, using suspend or hibernate, you cannot tell a client that the data is safe on your laptop because of hard disk encryption. You would have to tell him that there is a small chance that the data is stolen through a known vulnerability.
As for the obvious fixes, these would be different from hibernate and suspend. For hibernate, the image should simply be encrypted, and the OS should then prompt for a key when booting. For suspend, the keys should be removed from RAM and reread from disk, again prompting a password. The latter is not so easy to implement, I think, while it would not surprise me if hibernate already supports this.
Please note that while encryption fascinates me, I am not an offcial expert in the area, just a mathematician.
Posted 20 Sep 2008 at 10:00 am ¶Post a Comment