Slashdot Mirror
Encrypted Images Vulnerable To New Attack
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."
naivjdae4ovhnrBuAbrf!AbjLbhPnaFrrZlPbzzrag!;wfqudnwrenfyihltred
Is it just me or does anyone else get the feeling that the original story confuses two completely different concepts (digital photos and drive images)?
How is this different from the well-known watermarking attack? Doesn't the fact that most encryption systems now use the block number as a salt render this attack useless?
Does this also count for compressed images like PNG and JPG? After all those aren't bitmaps anymore - and removing redundancy by compression is always a good idea for encrypting afaik.
The article points out that this attack only works with uncompressed bitmaps with extremely low entropy. This is hardly a cause for alarm.
It was always risky to have two versions of a block-structured file encrypted with the same key. You can see the changes. That may tell an attacker things about the encrypted data (filesystem, size of files, etc.) If you backup encrypted volumes, either put them in another container or decrypt the files and store them in another container with a different key. Never keep different volumes with the same key. The attack is of significance for law enforcement, which may be able to enter the premises of a suspect and get copies of an encrypted volume at two different points in time. (A hint for Truecrypt users: Changing the passphrase does not change the key.)
I just scanned these articles, but just from the fact I don't see a single occasion to talk about crypto modes, such as ECB,CBC,OFB,CFB,CTR etc., I'm unhappy.
20+ years old knowledge, probably badly designed software, some special attack against very bad design, and then a panic-like hype against encryption.
So please, tell the newspaper writers to learn somewhat about security and only after that start to write hype-like articles..
Sad.
So, if you have two similar blocks encrypted with the same key, that also contains bitmaps, an investigator may be able to see the image and or detect the presence of a hidden volume?
Am I getting it right?
Yes, I didn't get this as well. I'm by no meant an encryption pro, but I've at least implemented CBC and CFB modes, and I don't quite see how they could find outlines in a CFB encrypted image (for example!). I mean come on, the wikipedia article has for a long time had an ECB (the "worst" mode) encrypted image in the article about block cipher modes: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29
The summary title and summary write up are a little ambiguous.
That which does not kill me only postpones the inevitable.
The problem is most likely that they use ECB-mode and no IV. Using a different mode, like CBC might solve the problem. The problems with ECB are well known, even wikipedia has an entry about this problem http://en.wikipedia.org/wiki/Cipher_mode
It's not new, it's old stuff.
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.
If I am reading this correctly, they are describing a well known problem with plenty of well known solutions. One such is XTS, which is what TrueCrypt uses.
Not only is the sensationalist article/summary only pertinent to uncompressed bitmaps, TrueCrypt has warned their users about backing up hidden volumes for a long time (source). In fact, it's the first precaution in how to keep your hidden volume secure.
So people worrying about steganography on TrueCrypt volumes shouldn't, they've been telling you how to keep these volumes secure already.
You don't use any of those modes on disk images, because you need fast random access.
http://en.wikipedia.org/wiki/Disk_encryption_theory
The article is full of errors and so it is hard to judge from this as the sole information source. Anyway, from what the article says it sounds very much like a vendor of snake oil encryption trying to boost his sales. For example, as opposed to what the article seems to suggest in a reasonable implementation of a symmetric crypto algorithm it is usually avoided to use the same key twice (and in some modes like CTR you have to ensure this).
the attack's assumptions are too idealized. but even so, loop-aes, who needs 64 keys for encryption plus one iv given by the user, may be immune to this attack. it uses cbc mode in 512-byte chains. so for aes-256, for an image to be vulnerable, it has to contain identical blocks and be bigger than 256*64*512= 8*(2**20) bytes (8mb). not counting the additional randomess caused by the supplied iv.
btw, gentoo has excellent support for loop-aes :)
As this requires at least 2 images with the same key, encrypted 'working' hard drives are not vulnerable unless you make sector level backups. I would imagine that anyone who has illegal images (such as child porn) on their encrypted hard disk would not make backups of such images.
This is far from a new revelation, they used AES in ECB mode to encrypt the uncompressed bitmap.
As you can see on the wikipedia page for ECB this attack has been known for a while.
Completely agree, I thought the same although I have seen ECB used a lot simply out of ignorance and/or laziness. Something like counter ( CTR ) mode is very very very easy to implement and increases the security immeasurably. Like in most crypto solutions, there is no point having a strong cipher like AES when the protocol you use it within is a pile of plops, such as here.
It doesn't? What about the part in TFA that reads:
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
Maybe, but surely you could implement a sort of low resolution cipher chaining so that you used the chaining on only a small number of blocks. Enough to cover up any entropy analysis of what you were encrypting. Doing this on a small number of blocks would reduce the computation an add to security... I think* * This isn't my area any more, I've been out of the electronic crypto game for several years.
Ok, so they are able to extract some information from a ciphertext that was created from a low entropy plaintext. It is quite obvious that redundancy in data creates vulnerabilities. This is exactly the reason why any serious encryption software applied data compression (entropy coder) before encrypting.
Actually simply storing images in any format with data compression would completely invalidate this method. (eg. JPG, TIFF, PNG, GIF)
I linked the article that explains what to actually do, you know.
Ken Starling!
Previously: "Linux... Toward the Sunrise..." Now: "Linux... Toward the-- No, now, part of Every Sunrise"
Ah ha, sorry, must learn to read!
Flash media.
Which at the same time makes flash media vulnerable. The wear leveling feature of flash media could cause an old verion of a block to stay on memorychip, making it vulnerable to exactlyy this kind of attacks.
In order to be able to use this attack, the image needs to be completely uncompressed, you need to be using a dumb encryption system, and you need to know where the bits making up the image are stored. In practice, none of those are going to be true.
Seriously? Can an attack on cryptography, and it's possible counter-defensives be patented? Just how much could you screw up the US financial systems, if you came up with an attack on encrypted trafficing (like the stuff banks and stock markets use), came up with the "only" defense against it, and then patented both?
Of course you'd never license the attack to anyone, but since it's patented, it's well described in public. ... 1% of the value of all transactions protected.
And you'd want to get paid quite well to license the defense against this attack, wouldn't you? Say
shitty encryption?
seriously
In other words, their technique only reveals enormous, low colour-depth, uncompressed images. Do such images actually exist in real life?
Since native windows desktop backgrounds are BMP format images and often mostly one color except for an image on the side or bottom. they would be perfect targets.
I don't know if any of the backdrops in the standard Windows install qualify, but I suspect not.
I guess the mods don't have a sense of humor today.... that was hilarious :)
This is not a problem with block encryption modes at all. Disk encryption software can't rewrite the whole disk every time a block changes. That is a fundamental problem. If a block changes and you have an image before and after, then you can tell which block changed. It's worse if the key and IV stay the same for that block, but often the information which blocks changed between two images is all you need, for example to spot the location of filesystems and consequently to tell if there is a hidden volume.
A choice of modes is often available for IV generation. Loop-AES, dm-crypt, and TrueCrypt all support a choice for IV generation, and since this is usually well-advertised feature in such packages, the GP was likely talking about a choice of mode for IV generation.
The problem is most likely that they use ECB-mode and no IV. Using a different mode, like CBC might solve the problem.
"This attack requires NO knowledge of the key used for encryption and it applies to ECB Mode (Electronic Codebook), Counter Mode (CM), Galois/Counter Mode (GCM), LRW, XEX, XTS, as well as CBC-based modes of disk encryption applications (OTFE)."
Just looking at ECB ciphertext reveals patterns in the plaintext. This attack requires plaintext with known properties to be encrypted with the same key and IV as the text of interest, and it affects many other modes.
The problem is the IV for CBC never changes for a given sector - mainly because there is no provision to atomically write both a 512 byte sector and its 48+ bit IV. I *have* read about a disk designed for full disk encryption which provides 520 byte sectors instead of 512 byte sectors. That completely solves the problem.
Some disk encryption uses non-atomic sector writes (store IVs in a separate physical sector). This risks data loss should one get updated but not the other.
I will note that the problem is more easily completely solved for flash media - where it is easier to (atomically) tag sectors with additional data.
Erm why do you need fast random access to backups? The weakness is only if there are to images(disk images) containing the same image(bitmap).
IranAir Flight 655 never forget!
in fairness i stoped reading after i saw
PMC Ciphers demonstrated TurboCrypt's defence against another great weakness of encryption software, Trojan keyloggers
oh right that was the end, but seriously WTF that doesn't make any sense, hardware keyloggers? rootkits?
IranAir Flight 655 never forget!
These aren't backups.
Plain JPEG uses runlength and huffman encoding on the quantized matrix obtained after DCT.
This is relatively efficient because there are a lot of long string of repeats in the matrix (see Wikipedia article).
(This is where some applications such as Stuffit have been able to non-destructively increase the compression of JPEGs and gain a couple of 1% by using better algorithms to store the quantized results)
In lossless mode, JPEG uses instead Arithmetic coding on the raw non-quantized results of DCT.
PNG uses LZ77 (either on the raw pixels or on a delta) wich is an entirely different beast. As pointed out by other /.ers it's a *dictionary* compression which replace repeat parts with pointer to where to they where repeated first :
"ABACDABA" becomes "ABACD{go back 5 letters and copy 3 letters}"
It doesn't need a separate RLE mode, because the dictionary can be abused as follow :
"ACCCCCC" in RLE is "A{repeat 6xC}" and in LZ77 is "AC{go back 1 and copy 5 letter}"
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It sounds like if the image is included in the encrypted message and you have a copy of the unencrypted image, it may be possible to break the entire message. That is what is known as a "known plaintext attack." It isn't exactly a new idea, although its application to files/messages with embedded images might be.
"This attack requires NO knowledge of the key used for encryption and it applies to ECB Mode (Electronic Codebook), Counter Mode (CM), Galois/Counter Mode (GCM), LRW, XEX, XTS, as well as CBC-based modes of disk encryption applications (OTFE)."
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
what, are you daft? Counter mode is every bit as suitable for random access as ECB. If you knee-jerk when you here mode in this context you only expose your own ignorance.
Why would you need to encrypt your porn... unless....
Dude! Won't anybody stop you thinking about the children?
Privacy mode FTW!
But speaking seriously, securing your privacy is something you should ALWAYS do if you have a family - especially if you watch porn. Moral issues aside, depending on where you live, if your little brother (and/or his friends) finds your collection, you could get in serious trouble.
It happened in the city where I live. A teacher was fired because his son (who attends the same school) invited some of his friends to play on the computer. Unfortunately, the browser history wasn't cleared and guess what page appeared when they opened up Internet Explorer... obviously, the kids didn't keep their mouths shut.
Erm why do you need fast random access to backups? The weakness is only if there are two images(disk images) containing the same image(bitmap).
OOPS
as you cant compare a single image of a disk, and why would you have 2 images of a disk around for anything other than backups?
*if your running raid-1 with 2 disks youd have to identical images making the attack useless
IranAir Flight 655 never forget!
Oh, so terribly sorry, let me just change that to "none of those except one".
Maybe this amateur cryptographer should read a few more cryptography books (or even Wikipedia) before claiming something new.
No sig today...
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:
The society for a thought-free internet welcomes you.
Quote: "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 now be revealed."
Excuse me, but wasn't this mentioned right here some months ago? And turned out to be a special case?
Not to mention the poor grammar. "whose existence", indeed.
you mean third surely.
Lots of people here are talking about users backing up their own data, but what about a border agent backing up your data? There's some real danger. Let's say you regularly pass through an international border where the country has a policy of making back ups of your laptop drives. Many corporate travelers are in this situation. The border agent takes a quick snapshot of your drive on Monday morning. You leave the country on Friday, but return the following Monday. When you return next Monday, they take another snapshot. Bingo. If any of your files have changed but the drive key is the same, they've got the backup they need to prove you have a hidden drive and even find the vulnerable images.
The company that I work for did a weak job but I have found the weakness and they have fixed it what a great company please everybody buy their product!
from TFA : "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"
-- OMG !eleventy-one - if you encrypt 2 slightly different things with the same key you can almost recover the pattern of differences between them. The example on the 'site only works because they take a blank image then compare it to a real one, of the same size encrypted with teh same key. The only way this attack would work in real life is if they had the key (unless people have a large habit of saving, and then backing up, large blank images before storing a picture (which has a large blank background) at the same location.
to avoid : a) initialize the "blank" space in any ecrypted volume to random numbers. b) don't store 2 hours worth if pure black video uncompressed at the same location as any data which has large blocks of ones or zeros.
In other words, if you use a block encryption scheme, then change the data in 1 of the blocks, the encryption only changes in that 1 block, and so you can recover the pattern of differences.
This attack will only effect uncompressed images, because compression increases the entropy so that pixel information will be entirely different as the colors change.
Finding a pair of encrypted twin images like this is nearly impossible. How can they even tell where an image starts on disk when the filesystem itself is encrypted? Not to mention the very strict (and unlikely) requirements on the images themselves. The odds of actually being able to exploit this on a live system are very low IMHO.
Every child knows, that only full-bit-encryption, invented by the Kryptochef himself, protects your data reliably:
http://kryptochef.net/index2e.htm
I can use this to collect the bounty on the Gpcode virus?
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
*realizes all the images on AnonIB used to save as bitmaps because of a bug on the server*
*shits himself*
No one modded you up, but kudos anyway. That sounds like a workable scheme - but it still costs twice as much disk io. There is probably a way to optimize that as well. I wonder also if having two IVs on disk is a security weakness?
So, this means ant in an encrypted volume, where the directory and node structure are not visible, you need to 1) identify where an encrypted image is, and apply this comparison algorithm to the EXACT same unencrypted image, to see if it's there.
In other words, the best that this can really do is prove is an image is is in the encrypted volume, by applying the comparison algorithm every 512/4096 bytes along the volume's byte array.
Good for providing a law enforcement case, not much for detecting evidence of a crime - unless you are stupid enough to leave the images around as unencrypted versions as as well as encrypted.
lyalc
False. I use XTS. If you use well-written software (dm-crypt + luks) you barely take a speed hit. I'm on serpent-xts-essiv:sha256 with a 256 bit key and I lose 20% disk access speed or so. Not even noticable unless I'm copying large chunks of data.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
...and possibly "bullshit" or "FUD" while you're at it.
Their claim that this is a "ciphertext-only attack" is a lie. It's not an exaggeration or an inaccuracy, it's an outright, blatant lie.
What these people have done is taken a known plaintext attack, emphasized the fact that the desired plaintext and key isn't known (forgetting for a moment that this attack would be pretty pointless if it was), and hoped that because it requires two volumes people wouldn't realize it's a known plaintext attack.
This is beyond ridiculous:
So, the attack is valid, but only under the condition that the blocks containing the data in one volume are all zeroes in the other, AND this fact being known to the attacker?
There are only two cases where I can concievably imagine that a situation like this arising, and that's when the cyphertext of the volume is zeroed after formatting (no software I know of does this), or the image is deleted by an overwriting tool that zeroes it out (there is no reason to overwrite deleted data in a cryptographic volume, and all overwirting tools I know of recommend pseudorandom passes, not zeroes). Neither of these cases are likely; it's far more likely that a careless user will have simply written down their passphrase and stored it somewhere. In effect, this "problem" is imaginary.
They've effectively created a problem that doesn't exist and solved it in the same paper, in a pathetic attempt to promote their own software.
The point about discovering freespace-hosted volumes has absolutely nothing to do with this, and has been discussed deveral times in the past. It is also not a vulnerability in software, it is human error, or more precisely, not taking the time to RTFM. The standard procedure for backing up encrypted data is always to encrypt using a different key, because reusing the same key open the door to known plaintext and activity-mapping attacks like the ones described here. No self-respecting cryptographer (nor anyone else with genuine security concerns) backs up their data by copying their container file or cloning their partition.
Even the style of the paper reeks of marketing influence:
(note the poor grammar and use of three exclamation points for excessive emphasis)
Wonderful use of unsubstantiated claims and spurious statistics, not to mention trying to discredit the competition. And let us of course not forget the absurdity of applying statistics about pieces of software to a problem which is entirely user error.
This "white paper" is a scam, nothing but shameless self-promotion and a disgrace to the field.