Summary of the vulnerabilities of the actually available implementations of encrypted filesystems on Linux.
All the source information is listed on LinuxCryptoFSBrainStroming.
This table lists the correspondancy between the AES implementations available on a GNU/Linux system and the vulnerabilities.
In this table, by "access to the hard-disk", we mean physical access to the piece of hardware; to say it more precisely, this means that the attacker is able to remove the hard-disk and replace it without the drive's owner realizing it. So, this doesn't include situations where the attacker has only one time access to the machine (for example in the case of seizing).
| implementations | attacker has access to the hard-disk | attacker has no access to the hard disk |
|---|---|---|
| CBC/IV-plain (dm-crypt in upstream 2.6.9) | watermarking, malleability, moveability, repeatability | watermarking |
| CBC/ESSIV (loop-aes 3.0) | malleability, moveability, repeatability | none of these |
| LRW (recent patch for dm-crypt) | none of these | none of these |
The definition of vulnerabilities is as followed:
- watermarking: the attacker can detect the presence of some specially-crafted file(s).
- malleability: some information leakage and modifications are possible (ie. some bits inside of a sector).
- moveability: arbitrary sectors of the disk can be moved in a way that this modification can't be detected.
- repeatability: it's possible to revert the state of a disk sector to an old state in a way this modification can't be detected.
Watermarking allows an attacker to prove the presence or absence of a file previsously prepared by him/her and put in the filesystem in plaintext (so this require an active action of an user of the attacked system). %BR% Malleability allows the attacker to modify small amounts of data present in the disk. %BR% Moveability permit modifications of portions of data, and leakage of significant amounts of data. Using this property, an attacker might replace a password by a known one without being detected. %BR% Repeatability make reverting the disk to a previous state possible, so that any modifications that has occured since is undone. %BR%
In any case, none of these vulnerabilities permit an attacker to get the key or the passphrase used to encrypt the hard-disk, and none of these vulnerabilities allow an attacker to decrypt the complete hard-disk without knowing the key or the passphrase. The dangerousity lies in the combination or them, combination that makes leaking and alteration of data possible. That's where the access to the hard-disk is important for the attacker: in order to exploit and combine these attacks, one's need repeated access to the data.
Globally, if you combine all these little attacks, you get the risk of getting the data accessed by an attacker despite of the encryption. Moreover, all these attacks arise from the fact that the encryption mode used by dm-crypt and loop-aes actually isn't suitable for encrypting a great quantity of static information, especially when the data can be accessed and modified in the encrypted form.
To summarize, both dm-crypt and loop-aes suffer from concrete security holes in a setup where an attacker can have repeated access to the hard-drive. On the other side, both are relatively secure in a server-like situation, where you can assume an attacker has not physical access to the machine.
To put it even shorter, it can be considered safe to actually use dm-crypt or loop-aes on a server, but it can be far more dangerous in other situations.
We haven't included other considerations than security, since the three setups are otherwise equivalent in terms of speed and maintenance.
More detailled technical informations about all that can be found there: http://clemens.endorphin.org/LinuxHDEncSettings .
Some performance benchmarks are available on http://deb.riseup.net/storage/benchmarks/encryption/.