On Jan 15, 2011, at 5:53 AM, Marsh Ray wrote: > 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"?
Yes, that's the strict definition. At its strictest, it's impossible. What you really mean when you say that is that the probability the attacker can modify the data is less than 2^keysize. If you're willing to loosen the definition, you can do more. When I first saw the wide-block stuff described as "Poor Man's Authentication" I got a wry smile on my face. It's bending the definition of authentication, but bending it in a way that I think is a good thing -- as long as we don't go too far. > >> 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? Nope. There just isn't one, at least in some information-theoretic sense. There are some modes like GCM and CWC that give integrity and encryption and are constant-space, but they're streaming modes and not suitable for storage. I don't know of a reason why it's impossible, it's just that if you look at the tool set and the requirements set, they don't overlap in a desirable way. > >> 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. See? Operational issues. Right now, we're at a cusp point for operational issues. Crypto is fast enough that for most cases, you tell people not to worry about it. But in some areas like storage, the I/O speeds are increasing fast. If you look at SSDs, for example, they're fast and getting faster, and outstripping the ability of the CPU to encrypt at full I/O speed. The AES-NI instruction set tips the balance back to the crypto, but they're still so finely balanced that speed and performance are real issues. Read-ahead caching, for example, is of an optimizer than you think when the disk is faster than the CPU. Moreover, disk systems are hard to write and when you have a nasty bug, you lose people's data. People don't like having their data lost. Simplicity is a virtue in all security systems, as well as in others. > >> 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. You don't. You get a mass of garbage and the odds are it's going to crap out on you. > >> 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. Pay close attention to the subtle differences between comms traffic and storage. In comsec, the attacker has free range to modify traffic, force retransmits, and so on, because the underlying system is built with the assumption that errors are common. Storage systems are built so that they assume that things work right. An error is not only uncommon, but serious. Already the attacker has little latitude, because errors passed up to the application layer are presumed to be a media error or worse. The ability to fuzz a storage system is typically limited. Many attacks on file systems are equivalent to attacks that say, "Assume the attacker has root...." Any time you're assuming the attacker has root, you're screwed. Other attacks presume that the authorized user of the system is part of the threat model. I just don't find these interesting. It is, of course, easy to create a storage system that ends up having a comm system under it, but the correct way to handle many technical problems like that is layering. Put your file system on top of a comm system that does integrity. > > 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 :-) No, Certicom had nothing to do with it, as I understand it. The issue is in DSA of all sorts. If you aren't careful with your random numbers, you give away the key. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
