Author: C. B. Roellgen
In early October 2008 we've published a new attack that affects a large number of disk encryption softwares that were currently available on the market. In our paper "Visualisation of potential weakness of existing cipher engine implementations in commercial on-the-fly disk encryption software”, we were able to show that disk-based encryption schemes can in part be circumvented to reveal protected data. The attack was named “Backup Attack” by me.
In order to mount the attack successfully, an encrypted volume image file is duplicated and both files are subsequently used independently to store information. Subtracting data bits with identical bit positions in the two files from each other yields zero for blocks or sectors that contain identical bit patterns in both files. This proves undeniably use of encrypted image files, how much data is stored in the encrypted image file and plaintext can even be revealed under certain circumstances without any knowledge of the key. The new attack 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.
A blogger has found the following words for the new attack on October 09, 2008:
"In a blatant attempt to get some PR:
... Turns out that if you use a block cipher in Electronic Codebook Mode, identical plaintexts encrypt to identical ciphertexts.
Yeah, we already knew that.
And -- ahem -- what is it with that photograph in the paper? Couldn't the researchers have found something a little less adolescent?
For the record, I doghoused PMC Ciphers back in 2003:
PMC Ciphers. The theory description is so filled with pseudo-cryptography that it's funny to read. Hypotheses are presented as conclusions. Current research is misstated or ignored. The first link is a technical paper with four references, three of them written before 1975. Who needs thirty years of cryptographic research when you have polymorphic cipher theory?
EDITED TO ADD (10/9): I didn't realize it, but last year PMC Ciphers responded to my doghousing them. Funny stuff.
Probably has the blogger not fully read the paper. This almost becomes clear in a comment to the blog entry:
The authors of the paper explain an attack on exactly those enhanced cipher modes you talk about.
I'm starting to wonder if people actually read the paper, or just drew a conclusion after hearing 'attack on ECB'.
Then again, maybe I misunderstood the paper altogether.
Either way I'm still not convinced this is a very practical attack, though.
Posted by: Rr at October 9, 2008 11:08 AM"
Another commentator finally realizes what the new attack is all about and he even adds valuable information:
"@ mrb, Sparky,
mrb :- "...any cypher will be vulnerable to the multiple-snapshot attack to determine which parts have changed, unless the whole file or volume is re-encrypted whenever something has changed."
Which is correct only if by "file" you are refering to the whole backup not individual user files and importantly a different key is used each time.
However you go on to say,
mrb :- "Of course, that attacker wouldn't know what the changed part contains or contained in the past."
You are making a very dangerous assumption there which is that the change has no context to other events.
First off how about the fact that a very large number of organisations use a "third party" offsite storage facility for their backup tapes...
The tape "owner" assumption is that as the backup is encrypted then it does not matter what the "third party" does with the tape provided it's available if and when required by the owner organisation.
They do not think, as a lot of backup encryption system designers also appear not to, about either "attacks in depth" or about how "Traffic analysis" methods might be applied to the "deltas" of the backups when mapped onto a time line of known events about the target "owner".
Secondly think about SAN and NAS systems with their "snap-shot" modes. They provide a very fine grained set of deltas so even if the volume is encrypted you will be able to roll backwards and forwards easily almost on a file by file basis. And due to efficiency only the key used for the individual file blocks can be changed.
A lot of "full" backup tapes start with almost "time invariant" system files (which are likley to be known quiet accuratly to an attacker) so a simple examination would reveal if the same encryption key had been used from one backup to another (very bad but happens).
The backups then tend to follow exactly the same file system walk each time (so the same files tend to be in the same place each time).
Worse the information about which individual backup tape file and what it relates too, is often recorded in plaintext as part of the tape header etc to aid use in recovery...
Even not having usefull plaintext knowing such things as when the company starts it's financial year end might easily reveal which part of the tape(s) covers the finance dept server etc etc.
A sudden change in the areas known to be used by marketing would be an early indicator of a new campaign and possibly product. Finding this area would be a simple case of rolling back wards from a previous campaign.
With each delta more and more information about what is where on the backups etc will leak from simple "traffic analysis".
Once the various sections are mapped out just monitoring the size of changes is going to provide usefull intel.
So much so that it might reduce the information required for a direct attack to knowing not much more than the text of a letter, and which person typed it up and having a delta or snapshot from the night before and the night after might be all you need to start a known plaintext attack (often possible as due to speed the encryption actually used is effectivly a stream system in older solutions).
I could go on but the simple fact is that a lot of the systems I have looked at are vulnerable in one way or another to "traffic analysis" on their backups and most definatly on SAN/NAS snapshots.
Security of information on storage systems is a very very hard problem when you start looking at it from a slightly higher level than just a one off image of data.
Things like metadata and invariant scripts aide the attacker, and applying traffic analysis methods elicits quite a lot of information.
Doing daft things like using the same key to back up internal only servers with others that have public data storage (mail servers etc) aid attackers by enabaling chosen plaintext attacks.
Oh and if you examin your backup tapes and discover that an attack in depth is possible due to key reuse or it effectivly uses stream encryption then go and find another solution pronto...
Posted by: Clive Robinson at October 11, 2008 1:04 AM"
We are of course open for a discussion. Probably it's a good idea to open a blog for this subject. Readers are invited to send me your thoughts by e-mail.