July 15, 1999
by Bruce Schneier
A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.
Copyright (c) 1999 by Bruce Schneier
In this issue:
What is "crypto-hacking"? As the first person to use the term, I get to define it. Crypto-hacking is hacking the mathematics of cryptography; it's forcing cryptography to do something new, something different, something unexpected. It's pushing the boundaries of cryptography. And it's been happening regularly over the past several years:
Using information about timing, power consumption, and radiation of a device when it executes a cryptographic algorithm, crypto-hackers have been able to break smart cards and other "secure" tokens. These are called "side-channel attacks."
By forcing faults during operation, crypto-hackers have been able to break even more smart cards. This is called "failure analysis."
In a beautiful display of crypto-hacking, one researcher was able to break RSA when used in the PKCS format. The break didn't break RSA, but the way it was used. Just think of the beauty: we don't know how to factor numbers and we don't know how to break RSA. But if you use RSA in a certain way, which happens to be a pretty common way, than it is possible in some systems to break the security of RSA...without breaking RSA.
Crypto-hackers have analyzed many systems by breaking the random number generators used to supply cryptographic keys. The cryptographic algorithms might be secure, but the key-generation procedures were not. Again, think of the beauty: the algorithm is secure, but the method to produce keys for the algorithm has a weakness, which means that there aren't as many possible keys as there should be.
Researchers have broken cryptographic systems by looking at the way different keys are related to each other. Each key might be secure, but the combination of several related keys can be enough to cryptanalyze the system.
The common thread through all of these exploits is that they've all pushed the envelope of what constitutes cryptanalysis. Before side-channel attacks, cryptographers never thought about using information other than the plaintext and the ciphertext to attack algorithms. After the first paper, researchers began to look at different side channels, invasive side channels, attacks based on introducing transient and permanent faults, etc. Suddenly there was a whole new way to do cryptanalysis.
Crypto-hacking = cheating.
Several years ago I was talking with an NSA employee about a particular exploit. He told the story about how a system was broken; it was a sneaky attack, one that I didn't think should even count. "That's cheating," I said. He looked at me as if I'd just arrived from Neptune.
Cheating is one of the basic tenets of security engineering. Conventional engineering is about making things work. It's the genesis of the term "hack," as in "he worked all night and hacked the code together." The code works; it doesn't matter what it looks like. Security is different; it's about making sure things don't NOT work. It's making sure security isn't broken, even in the presence of a malicious adversary who does everything in his power to make sure that things don't work in the worst possible way at the worst possible times. A good attack is one that the engineers never even thought about. Good attackers cheat.
And the future of crypto-hacking is the future of cheating. Clever people will continue to invent new ways to attack the mathematics of cryptography.
Like any kind of hacking, hacking cryptography requires a specific set of skills. The most important cryptographic skill is advanced mathematics; you can't analyze cryptographic systems without it. You can't cheat without it. You can break systems that use cryptography by going around the cryptography, but that's not crypto-hacking. Crypto-hacking means hacking the cryptography, which means advanced mathematics. And this explains why you don't see many crypto-hackers wandering around: the mathematics is hard.
Most of the crypto-hacking we've seen comes not from disenfranchised outsiders, but from fringe insiders: graduate students, and some academic and corporate researchers. I can't think of one crypto-hacking exploit by someone with a "handle." In fact, most of the crypto-hackers get an amazing amount of positive publicity from their exploits: newspaper articles, academic papers, accolades. There isn't much underground crypto-hacking going on.
There are some crypto-hacking tools, but not many. There are programs that take advantage of poor passwords in UNIX and NT, or poor passphrases in PGP, to break the encryption. There's a program that tries to break PKZip encryption, again based on poor password choice. But there aren't any real tools that allow for serious crypto-hacking, simply because too much mathematical expertise would be required to use them.
I don't see this changing in the future. Cryptography will continue to be a science of mathematics, and crypto-hacking will necessarily be exactly the same. There will be all sorts of cool crypto-hacking exploits, but it's not going to become a mass-market avocation.
The encrypted message on the CIA's sculpture at Langley:
Here's a free Java implementation of TLS (the successor to SSL):
Read the U.S. government position on cryptography in "Encryption: Impact on Law Enforcement." The 17-page paper discusses the uses and benefits of encryption, the downside for law enforcement, the concept of recoverable encryption (GAK), the Clinton administration's position on encryption, and current encryption legislation. Nothing new.
Someone from the UK wrote a paper, "Possible NSA Decryption Capabilities," which outlines a cracking machine NSA might construct.
Major cluelessness alert. There are people in the Pentagon ready to give up on computer security and disconnect from the Internet.
According to federal officials, federal Web sites and computer systems are particularly vulnerable to outside attacks because they lack two important elements: adherence to security plans and qualified personnel to maintain security measures.
A bill giving digital signatures legal status passed the Senate Commerce Committee.
This is an excellent survey paper on discrete logs. "Discrete logarithms: The past and the future": http://www.research.att.com/~amo/doc/crypto.html
China Sees National Security Threat in P3. Too funny for words: http://jya.com/cn-p3-peril.htm
The British government plans to give its police and intelligence agencies new powers to force disclosure of encrypted material used in electronic commerce:
CERT paper on firewall security issues and best practices.
Everyone pile on Microsoft!
A good example of the kind of fraud you can perpetrate when you can steal pennies (well, $19.95) from lots of people:
There are many definitions of fairness in protocols. Here's an article on envy-free protocols: http://www.newscientist.com/ns/19990717/newsstory9.html
The DefCon Web site was hacked by a group of German hackers who couldn't afford the air fare to travel to DefCon. http://www.news.com/News/Item/0,4,38970,00.html
Computers with high-speed modems (cable or DSL) and static IP addresses are vulnerable to probing attacks from hackers. (This might be a potential new market for firewall vendors.) http://www.nytimes.com/library/tech/99/07/circuits/...
In last month's News section, I promised to write more about web-based encrypted e-mail. That article will be delayed until next month, as I am still collecting information.
Bruce Schneier will be giving a one-day cryptography course at two SANS conferences. See http://www.sans.org/newlook/home.htm for conference details:
SANS Network Security '99
SANS Security San Francisco '99
John Kelsey will be speaking at the Sixth Annual Workshop on Selected Areas in Cryptography (SAC), August 8-10 in Ontario. Details are at http://www.engr.mun.ca/~sac99/.
Key-Schedule Cryptanalysis of DEAL
Yarrow-160: Notes on the Design and Analysis of the Yarrow Cryptographic Pseudorandom Number Generator
An article on Bruce Schneier's talk at BlackHat in Las Vegas:
For most people, SSL is magic security dust that automatically makes your Web surfing secure. But it's not that easy.
At onsale.com, you need to register before you can buy things. The form is at https://www.onsale.com/atcost/custserv/atregister.htm. Okay, they're using IIS, but at least they've got SSL turned on. You give them your vitals and credit card info and then send it in. But if you view the HTML source, you see: FORM METHOD="POST" ACTION="http://pecos.onsale.com/..." They use SSL to deliver the form, but drop back to plaintext to receive the data.
Verisign uses SSL, but they forgot to secure at least one part of their Web site: http://www.verisign.com/developers/index.html. [link moved to http://www.verisign.com/products/signing/index.html] You can click on several options, and those for obtaining an Authenticode or Object Signing ID are secure. But click on the links for the "Free Guide" to Authenticode or Object Signing, and you'll be entering -- and sending -- your personal information in the clear, including the required telephone number.
Spree.com, which recently partnered with Barnes and Noble for their online book sales, uses only 40-bit SSL. Also, because of the way the frames are used on their Web page, there is no lock icon on the screen to tell you if you are using any crypto at all.
BizTravel (http://www.biztravel.com) is the worst offender. All logons with ID and password are unencrypted. Anyone who intercepts that logon can purchase travel tickets in user's name with the credit card info on file at BizTravel. Many such tickets are electronic, so delivery of paper documents to an address of record isn't an issue. A query to BizTravel support elicited this response: "Your password is encrypted. In fact, we at member services, cannot access your password either. If you lose your password, we have to assign a temporary password. We have the option to use the site under the 'secure server' off of the main menu. I hope this eases your concerns regarding using biztravel.com." I couldn't find the secure server link at all.
From: John Kelsey <kelseycounterpane.com>
The speed of propagation is one threat. The other is that these macro viruses can be far more complex than their executable cousins, because if they only infect large documents, the change in size won't be noticeable. Why not include a pretty substantial mutation engine within the document, encrypted and stored to look like valid data? Or a program to test for various known security flaws on the internal network, and exploit those it finds to spread itself? If your virus can get away with being 500 KB, a lot of nasty things become possible. If you're forced to spread on 1.44 MB floppies, this just isn't acceptable.
One interesting thing about these viruses is that the viruses in question generally don't need the power to do anything obviously nasty to the system they're on. They just have to be able to make use of the e-mail system. So a lot of standard file-permission type schemes won't do much good, here. The user who's reading e-mail is almost always authorized to send it out, as well. Even on systems like Unix and Win NT with real security built in, the viruses should spread just fine.
I think the fundamental problem is that people use attachments in e-mail to exchange data for programs that don't have any security analysis done to them. Why should someone designing a freeware PostScript viewer, LaTeX compiler, JPEG viewer, file decompressor, etc., have spent a lot of time worrying about security holes? But an attacker can reasonably look at those programs for security holes.
There is a whole class of network attacks that are basically attempts to use network services, provided to the outside world, to compromise the machines providing those services. I think of these e-mail attachment attacks as very closely related to those attacks. The problem is that by allowing e-mail attached Excel spreadsheets, we're more-or-less making Excel a network service, like NFS or FTP.
You can send data into it from off the targeted machine. It will act on the data and can even send you something back. It doesn't matter whether the data you send and receive is sent one packet at a time or one e-mail message at a time.
Of course, this is disastrous for security, because Excel and Word and a zillion other single-user programs are simply not designed to be secure when fed data from a malicious source. The macro virii aren't all that hard to resist -- simply making all programs require a user-prompt before executing macros will go a long way in that direction. A much scarier thing is there are almost certainly subtle bugs in Word or Excel that involve formatting the file oddly, so as to cause a buffer overflow, or to cause some other odd behavior.
For operating systems with some kind of security built in (e.g., not Windows 95 or 98), it would be ideal to be able to open attachments, by default, in a kind of chroot-like environment. This would not only restrict changes to a specific subdirectory, but would also refuse to allow any communications with the outside world. Probably, this wouldn't be hard to set up in an operating system with user permissions and such.
Attachments in e-mail essentially create a whole new set of Internet services, running on the user's machines. The attachment in the e-mail is a message to some program that nobody thinks of as a network service -- like Excel, Word, or the DOS/Windows command line. Nobody *thinks* of it as a network service, but if it accepts data from untrusted sources on the net, acts on it, and maybe even responds to it, then it *is* a network service, at least in the security sense -- attackers ought to be looking at it as a reasonable point of attack, looking for buffer overflows and such. The fact that a human user has to intervene to open attachments is helpful, but they can obviously be fooled.
Every application you run on your machine that can be executed by opening an attachment is now a kind-of network service.
One defense is to is to limit the kinds of attachments that can be sent through the firewall, or that can be opened by the e-mail program. If only applications without macro abilities may be used to open attachments, this can provide some protection. (There could eventually be command-line options for things like Word and Excel turning off macro execution entirely; those options would be included in the mail system's call to those programs. Other "network services" would be turned off entirely.)
From: Peter Low <peterlowfletcherspaght.com>
I attended a Microsoft smoke and mirrors show in Boston (promoting their DNS "concept") shortly after Melissa had made the rounds. At the end of the show, Bill Gates fielded questions from the audience. When it was my turn, I pointed out that Microsoft has simplified computing to the point where it can be pushed to the masses, but, at the same time, Microsoft has put a burden on the masses to protect themselves from malware. The users who don't know much about how computers work are being asked to decide whether or not to allow files with scripts to be run when they open them. I asked Mr. Gates what commitment Microsoft was going to make to improving security for users of Microsoft products.
His answer was less than satisfying. He stated that the option of asking users whether or not to enable macros when they open a file is a good first line of defense because they can decide whether they trust the person who gave them the file. (Gee, I've never received an infected file from someone I trust. Also, you can turn the option off. Also, a lot of novice users will enable macros because they don't understand the danger.) He then talked about the potential for automating the procedure through the use of digital signatures. (Gee, I bet that will be much more effective...) I was left with the impression that things will get a lot worse before they start to get better.
Maybe Microsoft could include fields in their database of user information (tied to your Ethernet address) showing whether or not you are infected with various strains of virii or other malware, then allow users to check the database before accepting files from other users -- I bet they could make a lot of money from that service.
I work for a consulting firm, and, unfortunately, I need to use Office so that I can share files, often containing macros, with clients. I have no way of knowing what precautions my clients take with regard to malware, and feel I am put at risk due to poor software design from Microsoft. Bummer. At least I don't have to use Outlook.
From: Bruce McNair <bmcnairresearch.att.com>
Regarding data-borne diseases: Actually, as much as I'd like to bash Microsoft, they weren't the first. When Bob Morris' Internet Worm was making the rounds about 10 years ago and when the missing semicolon brought down Signalling System 7, we were hypothesizing about the possibility of data-borne viruses. I found a neat feature of troff that allows you to make a call to a UNIX shell, which would make a virus or worm much easier to create. I don't know how long before we saw it that this nice feature was there, but I can imagine that it's been a while.
Regarding automata modelling natural immune systems: I wouldn't bank on this one. The natural immune system is effective in the long term because it protects the group at the possible expense of the individual. Sure, it's unfortunate if you happen to die of pneumonia, but if you happen to live, you and your descendents may have a better long term chance. It's a little hard to imagine using a secure cooperative distributed computing system that allows individual systems (i.e., users' terminals) to be compromised without really bothering the user whose system is down. Besides, the patient stealthy viruses are able to do a number on the distributed immune system, even after millions of years of development. In the long run, I'll bet on the virus. :-)
Regarding Mr. Hewlett's comments about consumer credit card liability: Credit card laws in the USA are greatly in favor of the consumer, but there are limitations. (E.g., these regulations do not apply to "virtual checks" or debit card transactions.) In general, retailers bear the major burden of credit card fraud.
Consumers are generally liable for the first $50 of fraud, but card issuers handle this differently. Since Novus (DiscoverCard) and American Express directly control both the merchant and cardmember relationships, they are more likely to pursue matters to resolution. American Express has consistently resolved every dispute I've raised without the $50 liability.
Card associations like Visa and MasterCard are more loosely coupled, with different companies "owning" the cardmembers, merchants, and card processing functions. More effort is required on their part to resolve disputes and in my experience they are more likely to enforce the $50 liability. Interestingly, this can amount to inaction in the event of sporadic fraud. Someone I know was stuck with the task of independently contacting the merchant and disputing a fraudulent $49.95 recurring charge (just under the $50 cutoff).
On the merchant front, the risk is _huge_ for accepting a fraudulent card. In addition to losing the product to thieves, the transaction is reversed (minus the transaction fees paid to the bank), and the merchant is hit with a "chargeback" fee of $20 or more. Normally the merchant has two weeks to respond to a dispute; if their dispute ratio is high enough, the merchant automatically waives their right to challenge disputes -- the merchant is presumed wrong until evidence to the contrary is presented (i.e., funds are immediately deducted from their account).
Merchants do have some defenses, but they aren't great. They must get a credit card authorization code and perform a (crude) address verification. Ideally, the shipment should require a signature for release, providing the necessary documentation for the transaction -- even this may not be adequate to support a merchant's case (since anyone can sign for the shipment). Ultimately, Internet retailers are left on their own to add other tools to detect abnormal and fraudulent behavior.
Of course, these facts overlook what the "general public" is concerned with: encrypting the data between client and server. Curiously, this is probably the least likely place for a theft. (A more valuable function of SSL is actually the identification aspect -- it ensures that a site has some degree of legitimacy and that the URL hasn't been hijacked.
IMO, encrypting the data transfer between client and server is probably the least of security concerns, due to the access and technology required to steal data. The larger risk is how the merchant secures data once it's stored on the destination host. Crackers have stolen 10,000's of credit card numbers in well-publicized cases by breaking into Internet servers; it's far easier, considering the number of servers and OS security holes.
In summary, consumers are legally protected -- more than most think. Retailers are at a much higher risk than many realize. SSL is very valuable, but not for the reasons people generally think. And the general public's not paying any attention to the real threat -- how merchants secure their data files.
From: Paul Holman <pablosfortnocs.com>
While technically what you say is accurate, you must have never experienced credit card fraud first hand. For most people the inconvenience caused by this is worth weighing. You have to notify your card issuer, provide documentation, destroy your card, and wait for a new one. Yeah you're only liable for a maximum of $50, but it could cost you hundreds in time.
Credit card fraud worldwide is estimated at US$10B annually. Banks don't brag about this, they try to keep it under wraps so you feel like it isn't risky to use your credit card. That money has to come from somewhere. Directly or indirectly, the savings is being passed on to you.
Sadly, to implement secure protocols requires the cooperation of everyone involved. This means both the merchant and the consumer. Our job in the security industry is to try to make communication as secure as possible, and part of doing that is to make it convenient to use.
To subscribe, visit http://www.schneier.com/crypto-gram.html or send a blank message to firstname.lastname@example.org. Back issues are available at http://www.schneier.com. To unsubscribe, visit http://www.schneier.com/crypto-gram-faq.html.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is president of Counterpane Systems, the author of Applied Cryptography, and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served on the board of the International Association for Cryptologic Research, EPIC, and VTW. He is a frequent writer and lecturer on cryptography.
Counterpane Systems is a six-person consulting firm specializing in cryptography and computer security. Counterpane provides expert consulting in: design and analysis, implementation and testing, threat modeling, product research and forecasting, classes and training, intellectual property, and export consulting. Contracts range from short-term design evaluations and expert opinions to multi-year development efforts.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..