Slashdot Mirror
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?"
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.
FP?
I think the problem is people approach to the security.
They think you can just take AES and HMAC and glue them together in any way
and arrive at security. I mean both are secure right? The result should be secure?
Wrong! Schneier names one of the chapters in one ofhis book: "Cryptography is hard but that's just the easy part!"
It really is very hard to secure information. It's almost intractable.. We've seen a few articles here in the last week about interesting side-channel attacks. Breaking RSA keys by listening and an earlier one which broke into computers by heating them up.
Cryptography is littered with broken designs fielded designs like WEP and let's not mention software security..
It's going to be twenty years before we have "trustworth computing". It would help if we could modularize cryptography like we can computer programs...
Simon.
Wait for a cryptographer to analyze the product, then read about it on /.
About the last thing that comes to mind is "WinZip". Surely anyone in the least bit serious about security would look into something more mature (the implementation not the algorithm).
Kremlin Encrypt/Decrypt comes to mind as software that I've had good experience with.
We need 2048-bit buzzwords.
Open source is critically important with crypto, IMHO. Crypto seems to me to be something that a malicious entity would be more likely to put a backdoor into, instead of, say, an image editing program. Open source, as we all know, means that the code can be audited and compiled by a trusted party (myself), thus guaranteeing the legitimacy of the program. Perhaps more importantly, open source means the software is subject to peer review.
I took a class in cryptography last semester. The professor offered the best words of advice I ever heard in the subject: "Don't try to create new algorithms. We know how to do that already. What we have is secure. What you need to work on is the implementation. Just because something uses encryption, it is by no means secure."
He then proceeded to explain how easily NTLM can be defeated in a brute force attack.
...is really the lowest common denominator of zip programs. It is what Joe and Jane Sixpack of Bunghole, Indiana use to exchange photos with their son Jake in college in Goatse, Minnesota.
It is to archiving programs what AOL is to ISPs.
Given that, do you really trust anything it does to be secure in any meaningful way?
It's like if AOL announced that all AOL connections were protected using "state-of-the-art technology based on OpenSSL". Would you really trust an AOL connection to be as secure as, say, an OpenSSH connection from an OpenBSD box to another OpenBSD box?
Just because it's buzzword-compliant doesn't mean it's actually as secure as that buzzword would imply in more geekish circles...
Honey, I shrunk the Cygwin
Given that the WinZip people were undoubtedly trying to add "real" security without changing the way their users have become accustomed to working with the product, it seems to me like they did a pretty good job.
The solutions to the points raised in the article as far as I can tell pretty much boil down to:
1) Be aware that metadata of the encrypted files is not secure. (The only WinZip-specific flaw, and certainly possible to work around)
2) Be careful how you communicate regarding the transmission of encrypted files.
3) Be careful with your password.
4) Check your PC every time you return to your office to make sure nobody has placed a keylogger between it and your keyboard.
Certainly slashdot users can do that!
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.
PJRC: Electronic Projects, 8051 Microcontroller Tools
I didn't read the whole paper but the first attack was dealing with the meta-data.
What I can't believe is that they would still leave so much stuff unencrypted. A very poor design decision.
I mean, how freaking hard is it to put a flag at the start of the archive saying it is encrypted and then just raw encrypt the rest of the data. That design seems obvious and would be as secure as AES can be (eg. just create a normal zip, encrypt it, add flag/tag at start).
The ratio of people to cake is too big
While most of the points raised in the paper seem valid, some done make sense. Case in point: "someone may use a keystroke logger to find out what your passphrase is". How the fuck is this a Winzip vulnerability?
Complexity is often your enemy when designing secure systems. It might be tempting to implement lots of features and bells and whistles and cherries on top, but if you're serious about security you'll want to keep it as simple as possible.
Of course since when is anyone who's serious about protecting their data is going to use winzip? One tool for each job please, this is for compressing and archiving data, not to protect it. Anything else they try to build on top of it is only giving a false sense of security to people.
I can see how "AES Encryption" must have had the marketing guys wetting their pants though.
Stick with what you're good at.
Might I note that this is the same Yoshi Kohno who broke the Diebold voting system and SSH.
Doesn't this violate the DMCA or something? I don't want to get this guy in trouble, I'm just trying to figure out if this is the kind of research I'm allowed to pursue in an american university.
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.
There are validation programs in which third party laboratories test and inspect systems related to computer security. Probably the most well known of these is the FIPS 140 program, run by NIST and recognized by the US and Canada. A friendlier description is in this FAQ.
Another international validation program is the Common Criteria program. This provides an internationally accepted set of IT security requirements, policies, and procedures for testing.
Use validated software. Buy validated software. Looking at software that isn't validated? Encourage them to look into the validation process. The US government can no longer purchase cryptographic modules that are not FIPS 140 validated. Put similar rules in place at your organization.
Check out our infosecurity industry blog: http://securitymusings.com/
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.
7-zip also uses AES with a 256 bit cipher key for it's password protected file option. I store my personal backups in the 7z format, as I've always had a bad feeling about WinZip's zip cipher scheme, so I wonder what issues the 7z's encryption implementation might have.
The ZIP archive compression standard came out probably about 15 years ago (Phil Katz was a programming god despite serious personal problems), and even then it was obvious that the metadata wasn't encrypted, even with the simpler initial encryption algorithm.
Everybody knows that if you want a secure, encrypted ZIP file, you compress the files first (with or without encryption) into a zip file called "data.zip". _Then_ you zip that file into a second, meta, zip file with encryption.
The article points out that metadata isn't encrypted. I mean, this has been obvious for 15 years, right?
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.
.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 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
* 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.)
Caveat Emptor is not a business model.
"Don't try to create new algorithms. We know how to do that already. What we have is secure. What you need to work on is the implementation. Just because something uses encryption, it is by no means secure."
I hope you've misquoted him.
Personally, I know of no provably secure means of encryption and decryption [de-encryption]. I know that it is widely believed [although I don't know whether an infrastructure is in place within which it could be proved] that one time pads are secure, but I don't know of anyone who's proposed a way secure means for the distribution of one-time pads, and, for that matter, there's a rather old and rather contentious controversy as to whether one-time pads can even exist in the first place [Google on God does not play dice with the universe].
As for the standard encryption and authentication techniques, to the best of my knowledge, it is still an open question as to whether there are holes in Rivest-Shamir-Adleman; specifically, to the best of my knowledge, it is an open question as to whether third-party decryption of Rivest-Shamir-Adleman is as hard as the factorization problem itself.
And even if you assume that third-party decryption of Rivest-Shamir-Adleman is as hard as factorization, it is still, to the best of my knowledge, an open question as to whether factorization is a hard problem, at least on classical Tukey/von Neumann machines. [It is known that factorization is not necessarily a hard problem on a class of theoretical machines which do not yet exist in practice.]
So anyone who says "What we have is secure" is either incompetent to practice in the field [which, I suppose, does not necessarily determine the competency to teach about the field] or has been misquoted.
To the contrary, anyone who is honest about the state of affairs within the community of encryption artists will tell you, "We have a collection of algorithms that are widely believed to be secure, but I can no more prove to you that they are secure than I can, for instance, offer you a proof of The Existence*."
[*FYI: It is a little-known fact that Kurt Gödel believed he was in the possession of a proof of The Existence towards the end of his career...]
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.