Attacking WinZip AES Encryption

bden writes "As another tidbit from Bruce Schneier's Crypto-Gram, remember back in January when WinZip was Slashdotted for moving forward with its new AES-based encryption technology? Everything sounded good since we all knew that AES is secure, right? Well, a cryptographer took a look at how WinZip uses AES and found lots of problems. Regardless of how many people actually plan to use WinZip encryption, the lesson, according to Schneier, is that "cryptography is hard, and simply using AES in a product does not magically make it secure." So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?"

Comments

Quick summary

[pjrc]

Here's the security problems, quickly summarized (and oversimplified). These are in the same order as the paper. The paper is lengthy and not an easy read... if you can't be bothered to RTFA, maybe this will help.

1. Filenames, file sizes, time/date stamps are plaintext. Only the file contents are encrypted. Filenames, dates may be sensitive data (example giving, pinkslips.zip contains file pinkslip-bob.doc).
2. Both compressed and uncompressed sizes are stored without encryption, so an attacker can know the compression ratio and perhaps infer what type of data it is based upon its compressability.
3. File lengths are not authenticated. A man-in-the-middle attack could modify the file sizes recorded inside the zip archive so decrypting produces "garbage" output files (without warning that the zip archive was tampered). The man in the middle intercepts the communication about the problem and impersonates a request from the sender to see the "garbage". The garbage is after decryption, so if the receipient sends it in the clear, the man in the middle can easily turn it into the original plaintext.
4. File names are not authenticated, so an attacker could tamper with the file names and change their extensions. On windows and other systems, the file name extension determines which software will be used to view the file.
5. The CRC is stored without encryption. If an attacker suspects he knows what the message is, he can replace the ciphertext with his guess, and watch if the receipient complains about a CRC error.
6. Zip archives can contain some encrypted files, others plaintext. They worry that a receipient may believe all or most files were protected, when only a few or one was.
7. Key generation isn't random enough, so keys may be reused. I don't fully understand this one... maybe someone who does will reply and explain it??
8. Attacker can create a "self-extracting" archive that mimics the GUI of Winzips, but is actually a trojan horse. They admit this isn't really winzip's problem.

Similar to IANAL, I'm not a crypto expert. I probably botched some of these a bit, especially the key collisions one. If I've misunderstood any of these, please reply.

Re:Simple

[wfberg]

So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?"

By only using peer reviewed open source software for starters.

Also note how the "UNIX" tradition of chaining smaller, single-purpose applications together would have also prevented the problems described in this paper.
If you first create an archive (tar.bz or even ZIP), and then run it through gpg, the metadata is encrypted by default, and these problems would not have arisen.
Furthermore, there's no need to check every archiver under the sun for subtle encryption snafus, since the encryption is done by a specialized application. Wheter you GPG a .rar or a .zip, you only need to look at GPG to find bugs. And if and when you do, fix GPG, or use something else.

I wonder why people use a .ZIP plugin in outlook to encrypt mail, even though outlook has encryption (though admittedly, using cumbersomely acquired SSL certificates) built right in..

Also note that in the EU (now 25 countries!) public key cryptography such as GPG and SSL is all but mandated for electronic signatures that will stand up in court; better to use public key crypto than to rely on a shared key if you need to rely on file's or email's authenticity/non-repudiation.

Yoshi's broken other things too....

[meese]

Might I note that this is the same Yoshi Kohno who broke the Diebold voting system and SSH.

aespipe

[EventHorizon]

aespipe is a fast lightweight UNIX solution that is simpler than GPG:

http://loop-aes.sourceforge.net/aespipe/

Would be interesting to analyze it for potential problems; the included bz2aespipe script, at the very least, specifies the hashing and crypto algos in plaintext.

The difference

[StarBar]

between a secure program and a less secure program has nothing todo with AES. It is all about the keys. Whenever you are using symetric encryption, like AES, you need to store the key somewhere accessible both when encrypting aswell as decrypting. A human brain for instance. However at 128 bit encryption it starts to be hard to remember binary keys, even for smart folks. Then you need a secure way to store the key in, like a smartcard or an USB dongle or fetching it using PKI from a central storage using asymetric encryption like RSA. The weak point will still be the key storage and transportation, not the AES part.

However using weaker crypto algorithms like DES will invalidate any secure keystorage simply becuase it would be much more vulnerable to brute force attacks. Using AES simply moves the weak point to another link in the chain of security for WinZIP.

A curiousity for an example is the book "Neuromancer" by William Gibson where the AI had to trick a human beeing to unlock the last link to its pal AI because it could not be cracked by computers. A 100% computer secured old fashioned iron key! :-) I just love that chapter.

Much ado over nothing?

[BillX]

This may be non-news to those who read the paper, but it seems like the "vulnerabilities" here are overstated. Plenty of "rah, rah, should've used open-source, all your data are belong..." comments, but successful use of any of the exploits in the paper seems highly unlikely at best.

The vulnerabilities listed basically boil down to:

* Filenames and sizes aren't encrypted. If you store sensitive data in the filename, it can be read. (The paper uses the example of Bob intercepting a zip file containing a file named PinkSlipForBob.doc)

* The type of encryption method used is not authenticated. If a malicious user is able to perform a man-in-the-middle attack and edit the file so that it specifies a different (incorrect) encryption method, the final recipient will decrypt it and get a file of nothing but garbage. Now, if the attacker can also social-engineer the victim to send him that garbage file, the original file can be reconstructed.

* File names stored in the .zip are not authenticated. Like above, if the attacker can change the file extension, (s)he can cause the file to open in the wrong application when the victim unzips that file. This will likely be a nuisance at best; while the paper states that this method could be used to mount an attack similar to the above (getting garbage decrypted by a different method), it's unclear how this would actually work (since the file decrypted successfully, and there isn't any garbage). The attacker would have to coerce the user to send the unencrypted file itself.

* The next attack involves the attacker actually knowing the entire contents of the file (s)he wants to intercept, which to me at least, seems to defeat the purpose of intercepting it. Actually, that's a slight oversimplification: for this attack, the attacker needs to know 1 of n possibilities of what the exact file contents could be, and with this information, has a 1 in n chance of finding out if (s)he was right, by replacing the file in the archive with the "guess" (again, requiring the ability to modify the file in transit), and use the fact of whether (s)he intercepts a "Hey Bob, that zip file you sent was corrupted" message to find out whether the guess was right. (If it was a 1-byte file named "yesorno.txt", and the attacker wanted to know whether it contained "Y" or "N", this could be a useful attack. For less trivial files, however, this doesn't seem very feasible.)

* WinZip allows both encrypted and un-encrypted files in the same archive, so the end-user doesn't know if any given file was encrypted or not. An attacker can (man-in-middle, yadayada) add files to the archive before it reaches its recipient, and the recipient won't know they're not part of the original archive. A definite flaw, however, not directly a data leak of any kind. (Although, if one of the 'unofficial files' is a keylogger, and you can get the luser to run it....)

* A weakness in key randomization will cause a repeat key to be generated once every 2^32 files rather than the theoretical maximum of 2^64 files. So, "all" the attacker needs to do is find a victim who will use WinZip to encrypt, oh, 4.2 billion files or so, and they will have a good chance that one of the encryption keys is a repeat. Supposing there was a repeat, now they just have to know the entire contents of the larger of the two files, and they can determine the contents of the smaller one.

The paper also briefly mentions attacks like "plant a keylogger" or "replace Winzip with a program that looks like Winzip", but I wouldn't exactly call these flaws in the AES implementation. (The paper also comes to pretty much this conclusion, and so doesn't dwell on these possibilities.)

misdirected criticism

[hak1du]

From a quick glance through the paper, it doesn't sound like he found any smoking guns. The attacks he thinks of are pretty unlikely, and he did not find anything that makes the method intrinsically insecure.

WinZip seems to do what it claims it does: encrypt file contents with AES, no more and no less. Yes, it leaves the "metadata" unencrypted, such as it is, but so what? You get the same kind of behavior when you use the AES command line utility on UNIX. Nobody ever said that it would protect metadata, and it should be pretty clear to users that it doesn't as soon as they open the WinZip archive and see the file names. Furthermore, protecting the metadata through encryption would decrease usability significantly.

We also know that shredders don't offer perfect security, but they are sure a lot better than just throwing out documents on the curb. Well, it's the same with cryptography. The sooner people like Schneier realize that and stop scaring people away from cryptography by making obscure points, the better off we all are.