On 01/14/2011 06:13 PM, Jon Callas wrote:
This depends on what you mean by data integrity.
How about "an attacker with write access to the disk is unable to modify the protected data without detection"?
In a strict, formal way, where you'd want to have encryption and a MAC, the answer is no. I don't know of one that does, but if there *is* one that does, it's likely got other issues.
How come? Is there some principle of conservation of awesomeness at work or something?
Disks, for example, pretty much assume that a sector is 512 bytes (or whatever). There's no slop in there. It wouldn't surprise me if someone were doing one, but it adds a host of other operational issues.
If the crypto driver is functioning as a "shim" layer on top of a block device it seems reasonable that it could reduce the overall size seen by upper layers and remap the actual storage a little bit.
A 256-bit hash takes 32 bytes, 1/16th of the 512 byte sector size. So a encrypting driver could simply map 15 blocks onto 16 hardware disk blocks. This might impose very little overhead since the minimum number of blocks in the smallest IO operation goes from one to two, but this may not be noticeable. My understanding is that the 512-byte block size is mainly used by the disk bus protocols and the lower- and higher-layers (e.g. RAID, filesystems, virtual memory) will operate on 4-8K blocks and not hit that minimum anyway. The disk itself can be expected to do a fair amount read-ahead caching too.
However -- a number of storage things (including TrueCrypt) are using modes like XTS-AES. These modes are sometimes called "PMA" modes for "Poor Man's Authentication." XTS in particular is a wide-block mode that takes a per-block tweak. This means that if you are using an XTS block of 512 bytes, then a single-bit change to the ciphertext causes the whole block to decrypt incorrectly.
But how does anyone know that it decrypted incorrectly without some integrity checking? It seems like any integrity scheme will have upper bounds on its security related to the number of bits dedicated to that purpose.
If you're using a 4K data block, even better, as the single bit error propagates to the whole 4K.
That doesn't sound too bad to me. Any drive of mine having hard read errors is salvaged for refrigerator magnets. I don't recall ever having a data loss event of under 4K anyway.
The virtual memory page size of x86 is 4K (and 8K for x64) I believe MS Windows structures file accesses based on (at least) the VM granularity as well.
On top of that, there's the use of the tweak parameter; in disk storage, it's typically a function of the LBA of the data. Together, this severely limits what an attacker can do to a storage system. Single bit changes make a whole sector go bad, and you can't shuffle sectors. While that isn't authentication in a formal sense, operationally the constraints it puts on the attacker make it look a lot like authentication.
Sometimes the ability to glitch a system with random garbage at the right time is all the attacker needs.
For example, the attacker intercepts an HTTP request from your browser and returns a web page which uses Javascript to fill as much memory as possible with the address of a system function (On small systems, this could easily be the majority of all address space.) This can result in stacks and executable sections of various other system processes being paged out to disk.
The web page then asks for a resource which requires reading a part of the disk which was corrupted ahead of time by the attacker. The attacker may or may not have the ability to place the glitch in a specific file. Perhaps the web page loads an unusual image format which requires loading a dynamic library to display. Perhaps the attacker was able to introduce corruption in the swap or hibernation file.
In any case, there's a very good chance that any random garbage code will read a pointer from a random memory address and jump to it. (E.g., on x86 there are several one- and two-byte instruction prefixes which will do that, so the real chance is probably > 1%). Now he has code execution.
In other cases, glitching the 'end' marker of a file, or the file length in a filesystem structure could result in accessing a huge amount of data past the actual end of the file, possibly bypassing filesystem permissions checking in the process.
At best, the attacker now has the ability to fuzz your applications' file format parsing code. Ask Adobe and Microsoft just how effective that can be.
XTS has the additional advantage that it's a small overhead on top of AES. So while it's not actual data integrity, once you start lowering your requirements by saying, "in any way, shape or form," anyone who is using XTS, EME, or other wide-block, tweakable modes, they're getting close to what you're asking for.
As I understand it, the Playstation 3 filesystem crypto was defeated by simply deleting the encrypted files, filling up the disk with movies and then placing the cyphertext in the movie data stream (they may have had to ensure it went back into the right sector). Playing back the movies prompted the hardware to happily decrypt the data and output the plaintext of the files.
(I guess Certicom got the last laugh on Sony after all :-) - Marsh _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
