Encrypted Images Vulnerable To New Attack 155
rifles only writes "A German techie has found a remarkably simple way to discern some of the content of encrypted volumes containing images. The encrypted images don't reveal themselves totally, but in many cases do let an attacker see the outline of a high-contrast image. The attack works regardless of the encryption algorithm used (the widely-used AES for instance), and affects all utilities that use single symmetric keys. More significant to police around the world struggling with criminal and terrorist use of encryption, the attack also breaks the ability of users to 'hide' separate encrypted volumes inside already encrypted volumes, whose existence can now for the first time be revealed." The discoverer of this attack works for a company making full-disk encryption software; their product, TurboCrypt, has already been enhanced to defeat the attack. Other on-the-fly encryption products will probably be similarly enhanced, as the discoverer asserts: "To our knowledge is the described method free of patents and the author can confirm that he hasn't applied for protection."
Re:Watermark? (Score:5, Interesting)
Or CBC mode? Or any of a dozen other ways to prevent this well-known attack on ECB mode encryption? http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation [wikipedia.org]
Yes. And apparently TurboCrypt now supports such things too, hence the press release.
Not new (Score:5, Interesting)
As long as you backup the entire drive image - they will know that you made changes. Salt does not render this attack useless.
This is why you do not backup images of encrypted drives (or reencrypt changed documents with the same key - this is normally not a problem for decent file crypto).
If you are going to backup data that's on an encrypted drive, you copy the files and reencrypt them to your backup media.
Re:Watermark? (Score:4, Interesting)
How would you use CBC on a disk image that requires fast random access?
Here's what you should have been reading on Wikipedia: http://en.wikipedia.org/wiki/Disk_encryption_theory [wikipedia.org]
Re:Only works on uncompressed bitmaps (Score:3, Interesting)
The attack shown works on an image with a bit depth of 2. Camera RAW files have much higher bit depth, and unless you're saturating the whole sensor, I would imagine the image does not contain significantly large values of the same exact pixel value.
Re:Only works on uncompressed bitmaps (Score:3, Interesting)
To expand on your point:
What they are doing (although they don't put it like this) is searching for blocks in the compressed data whose pre-image is all zeroes (i.e. a large patch of white in the original image). For this to produce anything useful the image must be huge (so that a single scanline spans several blocks) and must contain large of areas of pure white.
In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?
Re:Watermark? (Score:3, Interesting)
Exactly. Use of ECB mode is pointless. All ECB mode does is change one block value to another since they are encrypted the exact same way. Thus, two similar blocks will have exactly the same output.
If you're using AES and you supposedly know what you're doing, you use CBC or CFC or another chaining mode. These feed the results of the previous encryption operation rendering the type of attack discussed in the article moot.
I can't believe they gave them any press time on this. Argh!
Two issues... (Score:3, Interesting)
But it is believed to effect almost any encryption program currently on sale as long as the two volumes being compared use the same encryption key whilst being slightly different from one another.
There are two issues that immediately come to mind:
Re:Watermark? (Score:4, Interesting)
Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.
LRW should fall to the bitmap attack presented in the article, so long as the bitmap is overwritten in place between ciphertexts. Any other weakness in LRW using the same key is minimized unless you are filling your disk with 127th degree polynomials in GF(2) represented as 128-bit vectors, that happen to differ from each other by n*k in GF(2) where n is the sector number they're stored in and k is the LRW tweak key. Most people don't do that. The probability of doing so with normal use is roughly the probability of accidentally guessing the tweak key.
The only real solution for the bitmap problem is modification of the file system to contain secure IVs for each block on the disk. Reusing IVs has *always* been shown to be a bad idea. It's broken more thought-to-be-secure schemes than I can count.
As an aside, once I actually found two files from a Slackware distribution that were detectable inside a truecrypt volume. One problem truecrypt had back then was that they were using 512 byte CBC blocks, while most file systems used larger blocks, so it was trivial to insert a file that would guarantee that the resulting ciphertext would be vulnerable to detection by starting at an even sector boundary and having just simple bit differences. I am guessing that in both cases the files being detected were executables with a large dynamic link section, since that would contain a whole lot of simple offsets that could match up with the sector IV vulnerability.
Re:Watermark? (Score:4, Interesting)
Since the encryption is done at the block device layer, it shouldn't be part of the file system but rather a part of the encryption layer. Except from that detail, I agree with you. However doing it is tricky. When you take a logical sector with 512 bytes of data and put it together with a small IV, it no longer fits in a 512 bytes sector. So you have to come up with a layout on disk that is efficient. And then you have the problem of updating it. Because you cannot write two sectors to disk atomically (with some disks you can't even write one). So you end up having the potential of data loss if an update does not complete because of a power failure. And the data loss is not guaranteed to affect only the logical sector you were writing at the time. I am still thinking about the problem. A raid layer have some similar problems, and I have been considering whether merging those two layers would help solving this problem. A can see a few other advantages you could get from merging a raid layer with an encryption layer.
Indeed. And the damage depends on the kind of encryption used. CBC is actually dealing pretty well with reused IVs compared to other encryptions. RC4 and counter mode are two examples where reusing IVs is so bad that you might as well not be encrypting at all.
Interesting. Though the patterns are simple, I wouldn't have thought they would show up unless they were carefully constructed.
That's the vulnerability I was referring to. And this is what is demonstrated by the file I linked to. It requires just one or two bits of difference between neighbor sectors depending on which parameters you used to set up the volume. My file contains just a lot of variants of that to cover different byte orderings so as to demonstrate the weakness not just in truecrypt, but also in some early Linux loopback encryptions.
The fact that a file system block consists of multiple disk sectors just makes the exploit slightly more reliable. Even if the sizes were the same, the file system would still try to put consecutive blocks from your file right next to each other on disk. (If it didn't do that, performance would go down by orders of magnitude).