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

Re:Predictable..

[Ckwop]

They missed the header data.. It's attacks based on the fact the header data isn't authenticated.

Simon.

winzip is reasonably secure

[js3]

most of the flaws mentioned in the article will require the attacker to go to great lengths to break the encyption. Others include the often quoted but rarely practical middle man attacks. In otherwords it is not flawed to the point where your teenage kid can hack your zip files, but the NSA could do crack it if they really wanted to

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:Quick summary

[AaronMB]

> 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??

Note: i am not a crypto expert

I've been reading up on PRNGs recently so I'll take a shot at it. The encryption method used is AES in what's known as Counter mode. The way that works is like so:

F(X) = AES(X, SALT)

So to get the next one in the list, all you have to do is calculate AES(X + 1, SALT). Since F(X+1) does not depend on F(X) at all, they can be done in parallel. To get the cipher text, simply XOR the plaintext with the stream.

So X needs to start somewhere. In the WinZip specification, it starts at 0 and keeps incrementing. Thus, if you reuse a password, it'll give you the exact same sequence.

The issue here is that they only use a 64-bit salt. Thus, you would expect that after 2^32 salts have been gone through, you'll have repeated 1. Since you've repeated one, you'll have generated the exact same sequence twice, and due to the nature of XOR, you can use that to help decrypt the 2 zip files.

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.

Re:I hear a familiar mantra coming on...

[Anonymous Coward]

"A company did a bad job programming here -- no need to indite all Proprietary software on Winzip's account. :)"

We don't have enough professors to audit all the closed software. If it *was* open source to begin with, I am sure that this problem would have been more likely to be found without professors help.

I trust no 3rd party applications that implemenet encryption, security, or anonymous type applications honestly and competently. Always try to a F/OSS alternative.

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.

Re:Simple

[Krunch]

GPG (and PGP) already compress the encrypted data. It seems PGP only use the .zip format but GPG also support bzip2 and gzip. Look at the -z and --compress-algo options of GPG.

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.

Re:Simple

[wfberg]

GPG (and PGP) already compress the encrypted data. It seems PGP only use the .zip format but GPG also support bzip2 and gzip. Look at the -z and --compress-algo options of GPG.

PGP/GPG uses compression for security purposes (remove as much entropy as possible) but IIRC it doesn't archive; i.e. include multiple files (and a directory structure) in one file.

This capability is precisely what bit WinZip in the ass (WinZip lives for archiving) because they left the meta-data that lists filenames etc. unencrypted.

Archiving multiple files before encrypting them is also a good idea, since you'd be sending out as much as possible in one go - if you encrypt each file separately you're again leaving meta-data around the place (if only the fact that you sent n emails, 1 of size 10K, the other.. etc.).

Encrypted military communications lines are said to be transmitting constantly, even when not being used to send messages (sending garbage in stead) to prevent any eaves dropper from detecting sudden spikes in communications. Kind of like installing one of those suspensions that rocks your car about to prevent people from guessing when the van's a-rockin', don't come a knockin'..

Note that WinZip could just as well use/invoke GPG "under the hood" without users even knowing about it.

Key collisions, an explanation

[Gregoyle]

I'm not a crypto expert either, but I've got a decent grasp on the subject.

After reading the paper, what they're talking about with key collisions is a fairly common problem with beginning cryptosystems.

When designing a cryptosystem, you try to get the same "bit level" of security throughout the system. The reason for this is that in most cases any system is only as strong as its weakest component (I know, duh, right). In a system using a 128 bit symmetrical block cypher (in this case AES) you are usually going for ~64 bits of "security". This basically means you can expect any successful attack to take 2^64 operations. The reason you don't get 128 bits is because of the "birthday attack"[a].

So generally if you're using AES 128 you are going for 64 bits of security. The problem with AE-2 (the system used in WinZip), at least according to the author, is that the key generation algorithm only gets ~32 bits of security. The article just says "the key derivation process is randomized"; it does not say what algorithm is used. My guess is that they used a 64 bit algorithm to randomize they keys generated from the password.

Since the CTR mode counter is always initially zero in this system, that means that there is no additional randomness added to the keystream (you get all your randomness from the password).

So that part is basically saying that the system is at most half as secure as one would expect for a (well designed) system using AES 128.

[a] The "birthday attack" is named after the "birthday paradox", which is the idea that if you have 23 people in the same room there is a greater than 50% chance that two of them have the same birthday. Where N is the number of possible choices, sqrt(N) is approximately the number of random choices made before there is a %50 chance that two of them coincide. Since in encryption you are usually using values of 2^n, this means that the "birthday bound" is 2^(n/2), e.g. if you are using encryption which normally would take 2^128 steps to find a collision, the probability of a collision is greater than %50 if you take only 2^64 steps.

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.)

Re:Use validated software!

[Antibozo]

These "validations" aren't really worth much. I personally have evaluated a product that had passed Common Criteria, and I found numerous critical vulnerabilities, including flaws in basic SSL implementation, an obvious buffer overflow, the ability to access the entire supposedly protected database without authentication, etc. This was a closed-source product, so I'm sure there was a lot more that I missed, since all I did was test it for a couple of days.

It's much better to go with open source so at least you can audit the code yourself. Saves a lot of time.

Funny: another product I audited advertised its use of AES. As someone else pointed out, key exchange is often the problem. In this case, the key exchange mechanism used was to publish the key in plaintext after reordering the bytes, on a web page with no authentication required.

Do not trust vendors when they tell you how secure their product is, or bandy about terms like "AES" and "Common Criteria". Most closed source products are crap -- I'm speaking from experience here -- and the vendors who know that they're selling crap just lie. If you can't get the vendor to open the source to you, you're probably better off going with someone else. If there's no other option, test the hell out of it.

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.

Secure enough for most.

[dtfinch]

An attacker won't be able to extract the contents from your zip files without your assistance.

To summarize their main concerns:
* The file listing is not encrypted, allowing attacker to see file names, sizes, compression ratios, and dates.
* The files are encrypted using an AES based stream cipher, whereby if the attacker replaces the encrypted contents, gets you to decrypt them, and gets a hold of the decrypted garbage that resulted, they can use the "garbage" to decrypt the original.
* An attacker can rename files in the zip.

The only one that reveals the contents of your data requires a bit of social engineering to get you to decrypt a chosen ciphertext and send them the result. Without tricking you into helping them, all an attacker can do is get a file listing, which may not be useful if they already knew what they were after.

Re:Predictable..

[fwarren]

Arugments about convenience are not bogus;

True, but let's look at the quote:

Fast, Inexepensive, Easy to Understand. Pick any two

There are always tradeoffs. The trick is to know which tradeoffs work the best for you. One set of trade offs work best for a company competing for business (or at least the company will bet on one set of trade offs paying off), while a different set of trade offs work best for a particular individual.

When I was 12, I used a simple substituion cypher. With the following cavets:

1. What I was encoding was probably a note to my best friend with a message like "Hey, lets talk to our moms about me spending Friday night at your house. This is great that my sister can't read this note if she finds it."
2. I knew that any 10 year old who had 2 paragraphs of encoded text and a library book could break the code. I knew an adult who knew what he was doing could probably break it with only a sentance or two.
3. I knew I was going to encode the note, hand it to my friend later in the day, and he would go straight home to decode it, there was not much chance of it being intercepted.

For what I was doing, it was the best method available to me. Wrapping notes around rods, or making invisible ink, were more trouble than they were worth. We did not have 2 rods of the same size, and my expermients with invisble ink were never really satisfactory.

Still, I have nothing really worth hiding. However, if I want to. I have the following requirements.

1. Do the encryption on the computer, to eliminate redunancy and incrase the speed and accuracy of encryption/decryption.
2. Use an encryption method that is currently considered secure by cryptoanlysis.
3. Use a public/private key encryption method to simplify the process of protecting my private key and making it easy to get/distribute public keys.
4. Use an implementation that does not swap data out to the hard drive, leave remenants of unencrypted files, etc. Things that would make the implementation insecure and easy to hack.
5. Understand that if someone physically comes gets my computer with my passphrase on it, and I pick a weak passphrase, my infomation will no longer be private.
6. Understand that if someone can obtain physical access to my computer and install keyloging hardware, or has the equipment to listen to frequencies from my keyboard or monitor, my information still is not secure.

Within those parameters, I do not know of a better product than pgp/gpg encryption. Does it take work to learn. Yes, yes it does. If I want to exchange encryped information, will I probably have to teach the other person how to use it? Yes, yes I will.

As far as even savy system administrators not using pgp. I will trust the data of 100 individuals with a secure passphrase of not getting hacked is far more likely than the possibility of those 100 administrators who do not use pgp.

Why? For all the reasons I mentioned above. They probably feel very secure, but in reality have a weak encryption setup. It won't come back to haunt most of them, but nonetheless, it is still weak.

People that want and really need security, will take whatever steps necessary to get it. They will live with the hassle to get that security and will be secure because of it.

Relying on the OS to provide it makes it only as safe as the weakest link, and we have seen how many weak links there are in the OS chain. Not to mention trusting that the OS does not have any backdoors.

Always a tradoff. So for, I have not seen a better set of trade offs for exchaning encrypted information between users than pgp. But I am open to consider better implementaions of encryption software when they become available.