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?"
Like the subject says, could carelessness in encryption have been a non factor even a couple years ago? Does the raw processing power on the average desktop make it that much easier to exploit a mistake or break weak encryption? In any case, I hope Winzip realizes "security" and "encryption" are more than just buzzwords.
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.
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
Having access to the source code is a good start, so the community can examine the methods used. It's not like WinZip has my business to lose if I could compile the source myself.
The only surefire protection against Microsoft infections is abstinence. - The Onion
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.
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.
...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
Repeat after me:
:)
"Open source software is good, Closed Source is bad!"
I feel like sometimes these stories are intended to invoke that type of response, whether warranted or not.
A company did a bad job programming here -- no need to indite all Proprietary software on Winzip's account.
-Jason/a.
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!
Security is a system problem, and requires you to look beyond the boundaries of software.
Breaking security requires to find a side-channel, where secure information leaks through. Just when you thought you found the perfect software solution, there's some chap that starts probing your address bus or checking the power consumption profile of your processor. Darn!
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?
It got proper AES implementation. And unrar sources are open, so you can check how it's done. Packs much better than WinZip too.
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.
While those are some interesting problems, I have to admit, they're really minor. Most of these are more social engineering attacks than technology attacks in the first place(i.e. man in the middle), and only 1, key generation, is a true technological threat to the encryption. As far as I'm concerned, even with their "flawed" implementation, this is strong enough for my needs. Anything past this calls for PGP in the first place.
Security has been and always will be an educational problem. Open Source makes the problem more transparent, but it's still pretty naive to think that someone is going to do a security audit of every line of code in a given product. Ex: Linux proved this with it's kernel hacks. Regardless of the severity of the problem, they were in plain site for anyone to analyze and correct for years. More than likely someone found the holes and was free to exploit them for years until a white hat hacker made the issue public. This was just one example and equally applies to any software. The first line of defense in securing code is developer education for proper implementation of security using well known good practices. The greatest weakness that we as development professionals is that there are not enough resources available to teach these best practices, but they're coming slowly based on customer demand. I think that we all have to remember that security issues have only recently become a mainstream computing problem and coincided directly with the increase in broadband Internet connections. I.e. The last 8 years or so. So, what secure coding resources do developers have available to them today?
"So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?"
Do some research and ignore buzzwords.
I have no signature
This statement about winzip is quite misleading. Either the author didn't bother to read the paper or has an emotional bias against non-free software.
The encryption method in WinZip is actually fairly secure, the attack mentioned in the article consists of tricking someone into sending back the decrypted output. While design improvements could be made to make this less likely this hardly qualifies as 'simply use(ing) the right busswords'. So long as you aren't an idiot and send data so confidentional you might reasonably be the victim of a complicated man in the middle attack this product will work fine for your security needs. In fact as they mention in the article PGP suffered from a similar problem.
In fact, aside from the documented fact that the file names and lengths are in plaintext, this tool provides all the security an individual user is ever really going to need. Even large corporations are unlikely to be the victims of sucesfull man in the middle attacks and certainly anyone using WinZip for their security needs doesn't really need to worry. This is certainly enough to stop your family friends and law enforcement from reading your shit.
I know I'm going to get jumped on by some crypto people and to be fair it *is* good we find issues like this report them and either document or fix them. However, if we are going to consider social factors (such as tricking someone into sending back 'garbage') it is only fair we credit social factors toward the credit of such a program. So we should consider the social factor that WinZip is hardly used by the government or milatary when asking if it is a reasonable security product.
If you liked this thought maybe you would find my blog nice too:
I disagree that the filename should be authenticated, changing the filename should be allowed since different systems allows different characters. If I had an encrypted zipfile that I had trouble sending because the filename was too long or had spaces or something in it, I should be able to simply rename it and send it without having to decrypt and encrypt it all over again.
The social engineering is a bit of a stretch, if someone is dumb enough to send back error files, then it would be simpler to send them a corrupt file then later ask them what password they had typed in.
A lot of these problems could be worked around by first putting your files into a zipfile and using Winzip to encrypt that file.
...and the reason that the general public is such a long way off is because it's not built into widely-used e-mail MUAs as a natural function. While there are certainly things to be said (though not all of those things are good) for simplicity and modularity with regard to security, until Outlook starts shipping with a standard "Encrypt this e-mail" checkbox, the general public isn't going to be using encrypted mails.
Regarding not all of the things being good - you can't encapsulate security. That's exactly the problem in this case - they've taken a provably secure method of using an assumed-secure algorithm and applied it in a (mildly) inappropriate way, with the effect that the result is no longer as secure as one might assume. They could have taken GPG and done exactly the same thing...
PenguiNet: the (shareware) Windows SSH client
The other flaws are differences between what is actually done and what a user is likely to expect to be done. In a social engineering attack, the attacker confuses the victem in some way; in this case, the victem is confused in advance by the software, and does something inappropriate because of that.
The mechanism fails to provide several expected properties: that all of the information in the file is hidden and that a file which decrypts without error with a given key was created by someone with the key (and does not have modified filenames or masked data).
The key generation attack only works against someone who generates 4 billion zip files with the same password; while a cryptographer might expect 16e18 zip files to be required, I doubt anyone is likely to actually create enough files to permit the attack. (If you create a zip file every second, you should change your password some time in the next 126 years, just to be sure).
As it is, WinZip needs two warnings: filenames and sizes are not encrypted; and, if you get something broken out of WinZip, it might still be sensitive. The latter turned out to be a flaw in PGP as well, and it was considered sufficiently important to fix.
So how can we distinguish between an application that simply uses the right buzzwords, like AES, from an application that is actually secure?
We can't. I think it's more of a question of "Is it secure enough?" The WinZip encryption may be weak, but unless you're zipping up government secrets it's probably OK.
Almost all encryption schemes can be broken, either through brute force or social engineering, it's just the way it is.
Peer review certainly helps, but doesn't ensure that the product is secure. It may you tell which products are not secure, but then the above paragraph shows that.
Welcome to security. The technology side to security is easier then the human side.
Not all of those are social engineering attacks though. Modifying the header to prevent the data from being properly decrypted is a technical attacking. Data security is protecting your data from a 3rd party while ensureing that the recipient can read the data.
Cryptographers hate poorly implemented security, especially when properly implemented security is possible. That is why this is news: People need to know that WinZip is not secure despite the "AES" feature. We the tech savvy have to let the unwashed masses know that WinZip isn't secure.
Many software houses cannot get the security right for their products. There must be some unique problem upon this.
First, it is the testing problem. For most features, e.g. number of request handled by a database, compression ratio of a video encoding software, the correctness of an accounting package, the test is easier to construct than the software itself. For security related enhancement, the difficulty is about the same (similar applies to stability).
Second, it is the actual developing problem. For most small/medium size software house (except the security related ones), I doubt if they have specialist who knows security/ encryption of that kind of stuff. One day, when the PHB wants some more security feature in the product, he would most likely deploying some programmers skilled in other areas to work on this. Obvious, it won't work that well....