February 15, 2000
by Bruce Schneier
President
Counterpane Systems
schneier@counterpane.com
http://www.counterpane.com
A free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.
Copyright (c) 1998 by Bruce Schneier
In this issue:
Suddenly, distributed denial-of-service (DDS) attacks are big news. The first automatic tools for these attacks were released last year, and CERT sent out an advisory in November. But the spate of high-profile attacks in mid-February has put them on the front pages of newspapers everywhere.
Not much is new. Denial-of-service attacks have been going on for years. The recent attacks are the same, only this time there is no single source of the attack. We've seen these for years, too. The attacker first breaks into hundreds or thousands of random insecure computers (called "zombies") on the Internet and installs an attack program. Then he coordinates them all to attack the target at the same time. The target is attacked from many places at once; his traditional defenses just don't work, and he falls over dead.
It's very much like the pizza delivery attack: Alice doesn't like Bob, so she calls a hundred pizza delivery parlors and, from each one, has a pizza delivered to Bob's house at 11:00 PM. At 11, Bob's front porch is filled with 100 pizza deliverers, all demanding their money. It looks to Bob like the pizza Mafia is out to get him, but the pizza parlors are victims too. The real attacker is nowhere to be seen.
This sounds like a complicated attack on the Internet, and it is. But unfortunately, it only takes one talented programmer with a poor sense of ethics to automate and distribute the attacks. Once a DDS tool is publicly available, an attacker doesn't need skill; he can use a simple point-and-click interface to infect the intermediate sites, as well as to coordinate and launch the attack. This is what's new: easy-to-use DDS tools like Trin00 and Tribal Flood Network.
These attacks are incredibly difficult, if not impossible, to defend against. In a traditional denial-of-service attack, the victim computer might be able to figure out where the attack is coming from and shut down those connections. But in a distributed attack, there is no single source. The computer should shut down all connections except for the ones it knows to be trusted, but that doesn't work for a public Internet site.
Other defenses also have problems. I've seen proposals that force the client to perform an expensive calculation to make a connection. (RSA pre-announced such a "solution.") This works against standard denial-of-service attacks, but not against a distributed one. Large-scale filtering at the ISPs can help, but that requires a lot of effort and will reduce network bandwidth noticeably.
At least one report has suggested that a lack of authentication on the Internet is to blame. This makes no sense. The packets did harm just by the attempt to deliver them; whether or not they were authenticatable is completely irrelevant. Mandatory authentication would do nothing to prevent these attacks, or to track down the attackers.
There have been two academic conferences on DDS attacks in recent weeks, and the general consensus is that there is no way to defend against these attacks. Sometimes the particular bugs exploited in the DDS attacks can be patched, but there are many that cannot. The Internet was not designed to withstand DDS attacks.
Tracing the attacker is also incredibly difficult. Going back to the pizza delivery example, the only thing the victim could do is to ask the pizza parlors to help him catch the attacker. If all the parlors coordinated their phone logs, maybe they could figure out who ordered all the pizzas in the first place. Something similar is possible on the Internet, but it is unlikely that the intermediate sites kept good logs. Additionally, it is easy to disguise your location on the Internet. And if the attacker is in some Eastern European country with minimal computer crime laws, a bribable police, and no extradition treaties, there's nothing you can do anyway.
So far, these attacks are strictly denial-of-service. They do not affect the data on the Web sites. These attacks cannot steal credit card numbers or proprietary information. They cannot transfer money out of your bank account to trade stocks in your name. Attackers cannot gain financially from these attacks. Still, they are very serious. And it is certainly possible that an attacker can use denial of service as a tool for a more complicated attack that IS designed to steal something.
This is not to say that denial-of-service attacks are not real, or not important. For most big corporations, the biggest risk of a security breach is loss of income or loss of reputation, either of which is achieved by a conspicuous denial-of-service attack. And for companies with more mission- or life-critical data online, a DOS attack can literally put a person's life at risk.
The real problem is that there are hundreds of thousands, possibly millions, of innocent naive computer users who are vulnerable to attack. They're using DSL or cable modems, they're always on the Internet with static IP addresses, and they can be taken over and used as launching pads for these (and other) attacks. The media is focusing on the mega e-corporations that are under attack, but the real story is the individual systems.
Similarly, the real solutions are of the "civic hygiene" variety. Just as malaria was defeated in Washington, DC, by draining all the swamps, the only real way to prevent these attacks is to protect those millions of individual computers on the Internet. Unfortunately, we are building swampland at an incredible rate, and securing everything is impracticable. Even if personal firewalls had a 95% market penetration, and even if they were all installed and operated perfectly, there would still be enough insecure computers on the Internet to use for these attacks.
I believe that any long-term solution will involve redesigning the entire Internet. Back in the 1960s, some people figured out that you could whistle, click, belch, or whatever into a telephone and make the system do things. This was the era of phone phreaking: black boxes, blue boxes, Captain Crunch whistles. The phone company did their best to defend against these attacks, but the basic problem was that the phone system was built with "in-band signaling": the control signal and the data signal traveled along the same wires. In the 1980s, the phone company completely redesigned the phone system. For example SS7, or Signaling System 7, was out-of-band. The voice path and data path were separated. Now it doesn't matter how hard you whistle into the phone system: the switch isn't listening. The attacks simply don't work. (Red boxes still work, against payphones, by mimicking the in-band tones that count the coins deposited in the phones.)
In the long term, out-of-band signaling is the only way to deal with many of the vulnerabilities of the Internet, DDS attacks among them. Unfortunately, there are no plans to redesign the Internet in this way, and any such undertaking might be just too complicated to even consider.
Discussion of DDS attacks:
<http://staff.washington.edu/dittrich/talks/cert/>
CERT Advisory:
<http://www.cert.org/incident_notes/IN-99-07.html>
Tool to check if Tribal Flood Network or Trin00 is installed on your computer:
<http://www.nfr.net/updates/>
Tutorial on DOS attacks: <http://www.hackernews.com/bufferoverflow/00/dosattack/dosattack.html>
Trin00 Analysis: <http://staff.washington.edu/dittrich/misc/trinoo.analysis>
Tribal Flood Network Analysis: <http://staff.washington.edu/dittrich/misc/tfn.analysis>
Stacheldraht Analysis: <http://staff.washington.edu/dittrich/misc/stacheldraht.analysis>
Declan McCullagh's essay on the topic: <http://www.wired.com/news/politics/0,1283,34294,00.html>
Claiming that they are trying to prevent state secrets from being stolen, China has issued some strict Internet cryptography controls. First, everyone who uses encryption has to register with the government and give the details of what software they are using and the algorithm, users' names, e-mail addresses, as well as the location of their computers. Second, Chinese companies are prohibited from buying products containing encryption software that was designed overseas. (So if a U.S. software company wants to sell encryption in its product, it needs to rip out whatever it has now and install something Chinese-made.)
This is a weird one, and I have a few observations. One, China is probably afraid that foreign security products have back doors. This is possible, and something that the U.S. has done before. But I don't see how enforcing requirements on crypto algorithms help here. Back doors are usually much more subtle than a broken crypto algorithm,
Two, this could easily be a prelude to key escrow. Certainly the first step toward requiring people to give a copy of their encryption keys to the government is to find out who is using encryption, and what kind.
Three, even by itself this information is useful for Chinese espionage. Traffic analysis is a very difficult problem, and knowing who is using encryption software (and where they are physically located) makes it a lot easier to know who to target.
People with a lot more political expertise than I have said that this is really nothing. China demanded that all fax machines be registered a decade ago, and many didn't bother to comply.
<http://www.wired.com/news/print/0,1294,33910,00.html>
<http://www.usatoday.com/life/cyber/tech/cth217.htm>
<http://www.currents.net/newstoday/00/01/27/news6.html>
Lots of excitement; still lots of secrecy. We're up to 45 employees and still growing. If anyone knows of a good VP of Marketing who likes commuting to San Jose, send him my way.
The Counterpane Web site has a new look. Visit it:
<http://www.counterpane.com>
Bruce Schneier is speaking at PC Forum, on March 15th
:
<http://www.edventure.com/PC2000/>
Last month I discussed publicity attacks, and the tendency of vendors to hype security vulnerabilities as publicity for their products and services. My essay generated a lot of commentary (see the end of the article for some URLs). This is a complicated issue, with gray areas, slippery slopes, and a lot of room for debate. My position has changed over time. I'd like to revisit it.
There are really two issues here, intertwined. If someone discovers a vulnerability in a product, should he quietly alert the vendor or should he make it public? And when is a vulnerability important and when is it trivial?
The first issue involves some history.
In 1988, the Morris Worm illustrated how susceptible the Internet is to attack. The Defense Advanced Research Projects Agency (DARPA) funded a group to coordinate responses to these kinds of attacks, increase security awareness, and generally do good things for Internet security. The group is known as CERT -- more formally, the Computer Emergency Response Team -- and its response center is at Carnegie Mellon University in Pittsburgh.
Over the years CERT has acted as kind of a clearinghouse for security vulnerabilities. People are supposed to send vulnerabilities they discover to CERT. CERT then verifies that the vulnerability is real, quietly alerts the vendor, and publishes the details (and the fix) once the vendor has fixed the vulnerability.
This sounds good in theory, but worked less well in practice. There were three main complaints. First, CERT got a lot of vulnerabilities reported to it, and there were complaints about CERT being slow in verifying them. Second, the vendors were slow about fixing the vulnerabilities once CERT told them. Since CERT wouldn't publish until there was a fix, so there was no real urgency to fix anything. And third, CERT was slow about publishing reports even after the fixes were implemented.
The "full disclosure" movement was born out of frustration with this process. Internet mailing lists like Bugtraq (begun in 1993) and NT Bugtraq (begun in 1997) became forums for people who believe that the only way to improve security is to understand and publicize the problems. This was a backlash against the ivory tower attitude of CERT. As one hacker wrote: "No more would the details of security problems be limited to closed mailing lists of so-called security experts or detailed in long, overwrought papers from academia. Instead, the information would be made available to the masses to do with as they saw fit."
Today, many researchers publish vulnerabilities they discover on these mailing lists, sometimes accompanied by press releases and the usual flurry of factoids. The press trolls these mailing lists, and writes about the vulnerabilities in the computer magazines: both paper-based and online. (This is why there have been so many more press stories about computer vulnerabilities over the past few years.) The vendors scramble to patch these vulnerabilities as soon as they are publicized, so they can write their own press releases about how quickly and thoroughly they fixed things. The full disclosure movement is improving Internet security.
At the same time, hackers use these mailing lists to learn about vulnerabilities and write attack programs (called "exploits"). Sometimes the researchers themselves write demonstration exploits. Sometimes others do. Some of these attacks are complicated; but as soon as someone writes a point-and-click exploit, anyone can exploit the vulnerability.
Those against the full-disclosure movement argue that publishing vulnerability details does more harm than good by arming the criminal hackers with tools they can use to break into systems. Security is much better served, they counter, by not publishing vulnerabilities in all their gory details.
Full-disclosure proponents counter that this assumes that the researcher who publicizes the vulnerability is always the first one to discover it, which simply isn't true. Sometimes, vulnerabilities have been known by attackers (sometimes passed about quietly in the hacker underground) for months or years before the vendor ever found out. The sooner a vulnerability is publicized and fixed, the better it is for everyone.
That's the debate in a nutshell: Is the benefit of publicizing an attack worth the increased threat of the enemy learning about it? (In the language of the intelligence community, this is known as the "equities issue.") If vulnerabilities are not published, then the vendors are slow (or don't bother) to fix them. But if the vulnerabilities are published, then hackers write exploits to take advantage of them.
In general, I am in favor of the full-disclosure movement, and think it has done a lot more to increase security than it has to decrease it. Publicizing a vulnerability doesn't cause it to come into existence; it existed even before it was publicized. Given that most vendors don't bother fixing vulnerabilities that are not published, publicizing is the first step towards closing that vulnerability. Punishing the publicizer feels a lot like shooting the messenger; the real blame belongs to the vendor that released software with the vulnerability in the first place.
The second issue -- the one that generated most of the discussion last month -- involves the agenda of the researcher. Publishing a security vulnerability is a play for publicity; the researcher is looking to get his own name in the newspaper by successfully bagging his prey. The publicizer often has his own agenda: he's a security consultant, or an employee of a company that offers security products or services. This is especially true if the vulnerability is publicized in a press release. Services like PR Newswire and Business Wire are expensive, and no one would do it unless they thought they were getting something in return.
All researchers are guilty of courting publicity. I am guilty of this. It was fun when my Microsoft PPTP break hit the press. Calling the protocol "kindergarten cryptography" was a hoot. On the other hand, I objected to nCipher's publication of their key finding attack last month. The differences are subtle and there's a lot of gray area, but here are my rules.
First, I am opposed to attacks that primarily sow fear. Publishing vulnerabilities that there's no real evidence for is bad. Publishing vulnerabilities that are more smoke than fire is bad. Publishing vulnerabilities in critical systems that cannot be easily fixed and whose exploitation will cause serious harm (e.g., the air traffic control system) is bad.
Second, I believe in giving the vendor advance notice. CERT took this to an extreme, sometimes giving the vendor years to fix the problem. I'd like to see the researcher tell the vendor that he will publish the vulnerability in a month, or three weeks (no fair giving the vendor just seven days to fix the problem). Hopefully the vulnerability announcement can occur at the same time as the patch announcement. This benefits everybody. (Admittedly, I did not do this with Microsoft PPTP.)
Third, I believe that it is irresponsible, and possibly criminal, to distribute exploits. Reverse-engineering security systems, discovering vulnerabilities, and writing research papers about them benefits research; it makes us smarter at designing secure systems. Distributing exploits just make us more vulnerable. For example, Mixter is a German hacker who wrote the Tribal Flood Network tool used in some of the distributed denial-of-service attacks. I believe he has a lot to answer for. His attack tool served no good. It enabled criminals and cost a lot of companies a lot of money. Its existence makes networks less secure.
This is not clear-cut: there are tools that do both good and bad. Vulnerability assessment tools can be used both to increase security, and to break into systems. Remote administration tools look a lot like Back Orifice. Publishing tools can also help; Microsoft has lied to the press and denied that a published vulnerability is real, until an actual exploit appeared.
I like Marcus Ranum's "be part of the solution, not part of the problem" metric. Full disclosure is part of the solution. Convincing vendors to fix problems is part of the solution. Sowing fear is part of the problem. Handing computer weaponry to clueless teenagers is part of the problem.
These are my opinions; they have changed over time, and are probably still changing. I came to this field via cryptography. Cryptography is by nature adversarial, even in the ivory towers of academia. Someone proposes a new scheme: an algorithm, a protocol, a technique. Someone else breaks it. A third person repairs it. And so on. It's all part of the fun, and this is how I learned. I first came to network security with this philosophy. But when it comes to fielded systems, things can get a lot trickier. Publishing vulnerabilities can cause significant damage to networks, and considerable pain and suffering for network administrators. If an announcement, product, or exploit makes things worse, it's bad. If it makes things better, it's good.
My original essay:
<
http://www.counterpane.com/crypto-gram-0001.html#KeyFindingAttacksandPublicityAttacks>
One response:
<
http://www.securityfocus.com/templates/forum_message.html?forum=2&head=754%20&id=754>
A response to that response:
<
http://www.securityfocus.com/templates/forum_message.html?forum=2&head=754%20&id=789>
The discussion on SlashDot:
<
http://slashdot.org/articles/00/01/17/0839211.shtml>
Marcus Ranum's essay on the topic:
<http://www.clark.net/pub/mjr/pubs/dark/>
See also the reader comments at the end of this issue.
"A Twofish Retreat: Related-Key Attacks Against Reduced-Round Twofish"
Niels Ferguson, John Kelsey, Bruce Schneier, Doug Whiting
The Twofish AES submission document contains a partial chosen-key and a related-key attack against ten rounds of Twofish without whitening, using 256-bit keys. This attack does not work; it makes use of a postulated class of weak key pairs which has the S-box keys and eight successive round keys equal, but no such pairs exist. In this report we analyze the occurrence of this kind of weak key pair and describe how such pairs may be used both to mount attacks on reduced-round Twofish and to find properties of reduced-round Twofish that are not present in an ideal cipher. We find that related-key and chosen-key attacks are considerably less powerful against Twofish than was previously believed.
< http://www.counterpane.com/twofish-related.html>
One of the nicer things about living in Minneapolis:
<
http://www.ag.state.mn.us/home/files/news/pr_conspriv_011300.html>
GCHQ (the British NSA equivalent) is looking for recruits. Take the test
on their Web site.
<http://www.gchq.gov.uk/>
Various pundits have said that the government is still winning the crypto
battle as long as Windows is shipping without strong crypto. Guess what?
Microsoft has said that it would release Windows 2000 worldwide with strong
cryptography.
<
http://www.wired.com/news/technology/0,1282,33745,00.html>
A brute-force machine for a combination lock:
<
http://vv.carleton.ca/~neil/robotics/locraker.html>
Would you hire hackers? Some backlash to the @stake announcement:
<
http://www.zdnet.com/enterprise/stories/security/news/0,7922,2420340,00.html>
Why security policies fail:
<
http://www.cdc.com/solutions/whitepapers/Why_Security_Policies_Fail.pdf>
Another distributed attack against a 56-bit cipher, one called the
CS-Cipher. This one took 62 days on about 38,000 machines, and happened to
require searching 98% of the keyspace.
<
http://www.wired.com/news/print/0,1294,33695,00.html>
Nice article on how easy it is to hack into Web sites:
<
http://www.pcworld.com/current_issue/article/0,1212,14415,00.html>
The NSA has contracted with Secure Computing Corp. for a secure version of
Linux. Personally, I don't know if the Linux license allows the NSA to
make a secure version of the operating system if they are not going to
freely distribute the results.
<
http://www.fcw.com/fcw/articles/web-nsalinux-01-17-00.asp>
The U.S. government and cyber crime:
<
http://www.currents.net/newstoday/00/01/17/news4.html>
<
http://www.fcw.com/fcw/articles/web-fbi-01-14-00.asp>
<
http://www.computerworld.com/home/print.nsf/all/000111DBFE>
<
http://washingtonpost.com/wp-srv/business/feed/a39572-2000jan13.htm>
The new export rules and the Bernstein case:
<
http://www.wired.com/news/print/0,1294,33651,00.html>
In a nice piece of irony, the new U.S. crypto regulations will benefit
federal agencies:
<
http://www.fcw.com/fcw/articles/web-export-01-14-00.asp>
Other commentary on the new encryption regulations:
<
http://www.computerworld.com/home/print.nsf/all/000113DD42>
<
http://www.usatoday.com/life/cyber/tech/cth136.htm>
New service monitors what radio station you're listening to:
<
http://www.wired.com/news/technology/0,1282,33799,00.html?tw=wn20000125>
Windows 2000 has its first virus:
<
http://www.computerworld.com/home/print.nsf/all/000113DD52>
and its first security holes:
<
http://dailynews.yahoo.com/h/zd/20000130/tc/20000130748.html>
Remember, it hasn't even been released yet.
I'm not the only one who thinks Internet voting is a dumb idea. The
"California Internet Voting Task Force" agrees.
<
http://www.ss.ca.gov/executive/ivote>
This is the most clever piece of credit-card fraud I've seen in a long time:
<
http://www.zdnet.com/zdnn/stories/news/0,4586,2427490,00.html?chkpt=zdhpnews01>
More information on the French smart card hack:
<
http://www.msnbc.com/news/361936.asp>
<
http://www.theregister.co.uk/000123-000005.html>
<
http://www.parodie.com/english/smartcard.htm>
Someone is suing Yahoo for violating Texas's anti-stalking law by using
cookies to track computer users' every move without their consent:
<
http://news.cnet.com/category/0-1005-200-1533164.html>
Twofish on the AS/400:
<
http://www.news400.com/features/newmf/Article.cfm?ArticleID=13333>
Snake-oil alert. Remember, it is possible -- although unlikely -- that
this is as good as NEC's PR department makes it sound. But it will take
years to know.
<
http://www.theregister.co.uk/000127-000025.html>
<
http://www.cnn.com/2000/TECH/computing/01/24/nec.strong.encrypt/index.html>
Good summaries of the DVD break and deCSS. An important point is that DVDs
can be copied and pirated without using deCSS or any other decryption,
which certainly makes the original claim of "prevents piracy" look either
astoundingly ignorant or brazenly deceptive.
<
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000127.htm>
<
http://www.latimes.com/news/comment/20000207/t000012301.html>
<
http://linuxtoday.com/stories/16556.html>
Recently declassified NSA documents. 9 and 12 mention ECHELON:
<
http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index2.html>
General information:
<
http://www.gwu.edu/~nsarchiv/NSAEBB/NSAEBB23/index.html>
Worth reading. EPIC's testimony on digital infrastructure protection.
<
http://www.epic.org/security/EPIC_testimony_0200.pdf>
House passes digital signature legislation:
<
http://www.cnn.com/2000/TECH/computing/01/31/esignatures/>
France sues the U.S. and U.K. over ECHELON:
<
http://www.the-times.co.uk/news/pages/tim/2000/02/10/timfgneur01007.html?999>
Former CIA director John Deutch brought classified information home on his
unsecured laptop.
<
http://www.fcw.com/fcw/articles/2000/0131/web-security-02-04-00.asp>
<
http://www.wired.com/news/print/0,1294,34105,00.html>
New vulnerabilities in e-commerce. Some shopping carts allow shoppers to
alter fields in HTML forms and URLs to alter prices of items they are buying.
<
http://www.computerworld.com/home/print.nsf/all/000202E636>
<
http://www.usatoday.com/life/cyber/nb/nb2.htm>
<
http://www.theregister.co.uk/000203-000006.html>
When Kevin Mitnick was captured, federal agents seized two of his laptop computers. Several files on those computers were encrypted. During pre-trial discovery, the prosecution refused to give copies of the encrypted files to the defense unless Mitnick gave them the key. The defense argued that the Constitution required the government to turn over any documents that might help Mitnick defend himself. The prosecution argued that since they had no idea what was in the files, they could be potentially dangerous. Unfortunately, the judge agreed with the prosecution.
< http://www.nytimes.com/library/tech/00/01/cyber/cyberlaw/28law.html>
A bank where you can withdraw money not just from your account, but from anyone's account. My favorite quote from X.com's CEO: "I don't think a mistake was made." Sadly, I believe him.
<
http://www.zdnet.com/zdnn/stories/news/0,4586,2429999,00.html>
<
http://www.currents.net/newstoday/00/01/31/news4.html>
<
http://www.nytimes.com/library/tech/00/01/biztech/articles/28secure.html>
Cookies are a clever programming trick built into WWW browsers. Basically, a cookie is a little bit of data that a Web server gives to a browser. The browser stores the data on the user's computer, and returns it to the server whenever the browser returns to the server. Cookies can do all sorts of useful and good things. Unfortunately, they can also do all sorts of useful bad things. First I'll explain how they work; then I'll talk about the problems.
The WWW is basically a stateless protocol. This means that the server doesn't know who you are from one click to the next. All the server does is serve up Web pages. A browser asks for a Web page; the server gives it to it. The server has no idea if this is the same browser as before or a different browser, nor does it care. This works great for simple, static, Web sites that just contain informational pages.
More complex Web sites are dynamic. Retail Web sites often have shopping carts, which travel with you as you browse the site. Paid access informational sites have usernames and passwords, which travel with you as you go from page to page. (I would find it annoying to have to type my username and password in every time I wanted to see another New York Times article.) Cookies are a way to handle this.
Remember that the WWW protocols are stateless; there is no way for the server to remember who you are from one mouse click to the next. By giving the browser a cookie and then asking for it back, the server can remember who you are. "Oh yes, you're user 12345657; this is your shopping cart." Cookies allow the browser to add state to the WWW protocols. You can think of them as a large distributed database, with pieces stored on millions of browsers throughout user-land.
So far, so good. And mostly, cookies are good, if the server placing the cookie plays by the rules. The server can set how long the cookie lasts before it expires: a few days seems like a good number. A server can set restrictions on who can access the cookie. They usually limit access to servers in the same domain; this means that if your cookie comes from random-merchant.com, than only random-merchant.com can access the cookie.
The problems come when they are abused. Some servers use cookies to track users from site to site, and some use them to uncover the identity of the user. Here's an easy example: there are companies that resell advertising space on popular sites. DoubleClick is a company that does that; often the ads you see are placed there by DoubleClick in arrangement with the site. If you're browsing on sex-site.com, you're going to see a portion of that window that comes from DoubleClick.com. DoubleClick.com gives you a cookie. Later (that day, or maybe another day), when you're browsing on CDNow.com, there might be another DoubleClick-placed ad. DoubleClick can request the cookie from your browser and, because the cookie says that it was created while you were visiting a sex site, send you targeted ads while you're browsing CDNow. Because DoubleClick is on a bunch of commerce sites, its cookies can be used to track you across all of those sites.
Even worse, if you type your e-mail address in at any of those sites and DoubleClick gets it, DoubleClick can now attach an e-mail address to your browsing habits. All it needs is for you to type that address in once -- that's ordering only one thing -- and it has it forever. (Or, for as long as that cookie has not expired, which can be years.)
DoubleClick freely admits they collect data and use that data to target ads to users, but until recently they denied building an identity database. Two weeks ago, USA Today exposed their duplicity. They have since admitted that they try to collect names and attach cookies to off-line identities. The implications for private Web browsing are profound.
There's more. Sites can send you a cookie in e-mail that it can use to identify you if you later visit that site with your browser. Here's how it works: the site sends you a piece of HTML e-mail. (This implies you're using an e-mail program that supports HTML messages, such as Microsoft's Outlook and Outlook Express, Netscape Messenger, or Eudora.) The message contains a URL to a graphic, which the site can use to send you a cookie. Now, when you browse the site at some later date, the site can use the cookie to link the browsing with the e-mail, and hence the e-mail address. Supposedly this has been used by some sites to track Web surfers.
Some things cookies cannot do: Cookies cannot steal information from your computer. A cookie is simply some data that the server gives the browser, and the browser later returns. A cookie cannot grab your passwords or files. (ActiveX, Java, and JavaScript are much more dangerous in this regard.) Cookies cannot steal your credit card numbers.
The lesson here is that cookies are not bad, but there are some very malevolent uses of them. There are ways in most browsers to turn cookies off completely, and third-party programs that help you manage them better. Managing is a better solution, since some Web sites refuse entry to people who don't accept cookies.
"Opt out" of DoubleClick. They can't keep your personal information if you
tell them not to. DO THIS NOW.
<
http://www.cdt.org/action/doubleclick.shtml>
Cookie blocking software:
<
http://www.junkbusters.com/ht/en/cookies.html>
<
http://www.ecst.csuchico.edu/~atman/spam/adblock.shtml>
Anonymous Web browsing:
<
http://www.zeroknowledge.com>
Stories on DoubleClick's duplicity:
<
http://www.usatoday.com/life/cyber/tech/cth211.htm>
<
http://www.hackernews.com/arch.html?012600#1>
<
http://news.cnet.com/news/0-1005-200-1531929.html?dtn.head>
Lawsuit against DoubleClick:
<
http://www.wired.com/news/print/0,1294,33964,00.html>
CDT's testimony on online profiling:
<
http://www.cdt.org/testimony/ftc/mulliganFTC.11.30.99.shtml>
From: Andrew D. Fernandes <andrew@cryptonym.com>
Subject:
Publicity Attacks
I have a couple of comments regarding your "Publicity Attack" article in the January Crypto-Gram.
First, you insinuated that my company, Cryptonym, being a PKI vendor, had somehow profited by publicizing the Microsoft/NSA issue. In fact, we didn't make a penny off of the information. Heck, I couldn't sell you anything even if I wanted to. We are at least a year from releasing any products whatsoever -- products that will be fully open source -- and we only take on a very limited amount of consulting.
We thought that we were doing the "Right Thing" by publicizing the fact that all US companies wanting to export crypto software had to involve themselves somehow with the NSA. It was never our intention to make money off of our finding, and so far, we haven't.
Second, you discuss publicity attacks. Apparently, we cannot trust nCipher or eEye to discuss security because they sell security products and consulting. In fact, at the end of the Crypto-Gram is a note indicating that we should be wary of claims about elliptic curves made by Alfred Menezes because he has financial interest in Certicom. I think that this is going too far.
Yes, perhaps nCipher and eEye (and maybe even Cryptonym) did a bad job publicizing security holes. Maybe Alfred wants to fool everybody about the security of elliptic curves for his own nefarious gain. But get real!
Everybody in this field -- including you and Counterpane -- has strong monetary ties to the industry, therefore everything everybody says has to be taken in context. These financial ties do not mean that a company's advice or press releases cannot be trusted. Taking advice about cryptography is no different than taking advice from your lawyer. You have to know how your lawyer will benefit from you taking their advice.
But I think it's presumptuous to imply that we lack professional integrity if you disagree with us. For instance, why are you advising people to use RSA over ECC? Why not ElGamal or Authenticated Diffie-Hellman? After all, RSA is patented, while ElGamal and ADH are not... Wait! Does Counterpane hold any shares of RSA?! Could Counterpane be making money by advising people that ECC isn't as good as RSA?
I certainly hope not. I don't agree with your ECC vs. RSA advice (and neither does Alfred Menezes). However, I do believe in you and your company's professional integrity.
From: Geoff Thorpe <geoff@eu.c2.net
Subject: nCipher's
Key-Finding Attack
I was interested to read your thoughts on the nCipher-announced key-scanning attacks. As someone who works for a company that produces an open-source based secure web-server I would have as much temptation as anyone to play down the importance of such attacks -- especially as the desired inference seems to be that the web-server can't be secure unless one shells out on hardware crypto too! However, I feel it's dangerous to disregard what the underlying work may have to tell us about our security and configurations, regardless of whether or not that involves taking it to the extent that press release may like us to (which is to conclude hardware crypto is the solution to the problem).
I do generally agree with the sentiment that these key-scanning attacks aren't nearly as sensational as the press might like (or be led) to believe -- key scanning is nothing new and this work has simply sped it up quite a bit, and there are only very specialized kinds of web-server usage where these attacks can be mounted against a server that has been set up competently. However it is incompetently set up web-servers that are mostly likely to be discussed to illustrate and justify attacks so we're best to look under the hood to see what we can take and what we can discard from all this.
IMHO, the research behind the announcement is legitimate and worthy of a look -- if for no other reason, to get a more healthy respect for key-protection. In particular, the research uses some interesting ideas on scanning large blocks of data for areas of high-entropy before using more refined search techniques to track down actual keys in the "haystack". It rather effectively illustrates why one must have a keen eye for scenarios where unencrypted private keys lie in any media subject to brute-force scanning, no matter how impossibly resource intensive the scanning attacks may at first appear. The research in question illustrates how a large hard-disk could be scanned quite quickly to search out a private key that may lie in it (e.g., a swap partition, a core dump, etc.). Everyone knows an unencrypted private key is always a target -- but the research gives some considerable warning to those who might have previously thought 1 private key in 2 Gb of data was too difficult a thing to find.
Also, the attack has at least led us to consider situations where this kind of attack is or is not an issue rather than allowing hackers to do it for us. The truth is that this family of attacks, at least in the case of web-servers, is only a serious threat for multi-hosting servers that run multiple virtual hosts in the same web-server application that is running a secure virtual host (and does not use any setuid on the web-server child processes). In that scenario, an administrator who can upload and activate native (e.g., CGI) programs in their virtual host can not only scan for and find their own private key (if they have one), but also the private keys of any other loaded virtual hosts running in the same processes (or as the same user). By attaching to a running process (as debuggers do) or using some "/proc"-style mechanism to get direct access to a process's virtual memory, you can begin your scanning as you would on a regular file. There are not many servers running in scenarios like this (where an "administrator" can compromise anyone except him/her-self), but the research has at least allowed to us to consider exactly who is and isn't vulnerable (helping the former, and providing some peace-of-mind to the latter) before the lessons are learnt the hard way.
From: Nicko van Someren <nicko@ncipher.com
Subject: Re: Key
Finding
First, I would like to point out a significant inaccuracy in your report. You state in the penultimate paragraph that "[the] nCipher release included a hacker tool". This is incorrect. We have built a tool that efficiently finds SSL server keys and we have shown it to a limited number of web server vendors, but we have NEVER released the code; nor do we have any intention of doing so.
On the broader issue of what you call "publicity attacks," I feel I must defend nCipher's issuance of a press release on this topic. An essential aspect of developing security solutions is finding the weaknesses in existing systems, and when those weaknesses are found it is reasonable to let those who will be affected know. After making the theoretical attacks known in February 1999, we found that many web server vendors felt that the attacks were impractical and ignored the issue. Thus we went on to prove the practicality of these attacks and let the server vendors have the details of our new results. We then went on to let the rest of the world know.
While you are right to say that nCipher has some interest in the results of this research, it is rare for any company to carry out research without having some interest in the results.
We stand by our stance that publication of potential modes of attack is preferable to obscuring them and allowing them to be employed on an unsuspecting world.
From: ruth@innocent.com
Subject: Radio Pirates
The "Radio pirates" story originated in New Scientist, where for all I know it was told in a more balanced way, and probably had a side panel explaining RDS technology and the reason for this vulnerability.
RDS (Radio Data System) lets consumer radios decode a low bit rate digital signal from compatible FM broadcasts. This signal can include a station ID (such as "BBC R4" or "KISS FM", and various other info, but there is also an additional feature which drivers can switch on at their option called TP (Traffic Programme) which switches to local stations when they are broadcasting a travel update.
Just why is this a "Good illustration of the hidden vulnerabilities in digital systems"? Even if you believed the misleading articles from the BBC which says that "radio stays tuned in until ... the driver switches off the RDS feature," you'd still realise that this system degrades nicely to ordinary FM radio service at the push of a button. Actually those reports are an exaggeration, all the RDS car radios I've ever seen had a button labelled "TP", which when pressed enables or disables just the traffic programme service. This leaves all the other benefits of RDS intact.
I cannot think of a mechanism that would permit radios to identify and ignore pirate TP signals, without going to fully fledged DAB (as the UK inevitably will in the next decade anyway)? Offering an optional additional service which is subject to a potential DOS doesn't seem like such a vulnerability to me.
From: anonymous
Subject: French Smart Card Break
in the December 15, 1999 issue of Crypto-Gram, you wrote:
> A French engineer succeeded in factoring the 640-bit
> RSA key stored in the chip on the card (all French
> "CB" credit cards have had a chip since 1990).
What is clearly established [agreed by Serge Humpich and the Groupement des Cartes Bancaires in court] is that Humpich made some counterfeit Smart Cards, with incremental account numbers, and used them to buy metro tickets in an automatic machine, as a demonstration to the Groupement. This is basically what he is charged for. The judge is expected to release a verdict on February 25, 2000. A summary (in French) of the audience is at < http://www.legalis.net/legalnet/actualite/affairehumpish/pagehumpish.htm>
> From several sources, including Humpich himself on a TV show and this audience report, he was trying to sell his expertise to the Groupement, through a lawyer in an attempt to remain anonymous.
The 640-bit claim originated in the "Pirate Mag" magazine (also known for promoting the idea that PGP has a backdoor). They have an interview < http://www.acbm.com/pirates/num_05/interview.html> of Serge Humpich where he claims:Based on undeniable evidence that the Groupement des Cartes Bancaires originally used a systemwide 321 bits public key, and the lack of evidence of wider keys in general use as of early 1999, many believe that the card fraud Humpich demonstrated is a combination of:
<http://humpich.com/>, a recent Web site on the case with sources apparently close to Serge Humpich, describes how he factored a 321-bit key in 1997, citing the classical MPQS factoring algorithm, modest computing resources, and a Japanese program. They present 640-bit keys as a reasonable choice the Groupement des Cartes Bancaires could have made, but did not.
The same Web site contains on-line scans of publications where French
expert Louis C. Guillou, known to be involved in the design of the Smart
Card system used by the Groupement des Cartes Bancaires, warns as early as
1988 [in French] then again in 1990 [in English] that the 320 bit key then
in still-experimental use by CB is obsolete.
<
http://humpich.com/LCguillou_AnnTelecom_No43_1988.jpg>
<
http://humpich.com/SmartCard19900810-2.jpg>
It could be that Humpich demonstrated he can break an obsolete system, tried to make money out of it, and as a retaliation is being sued using whatever legal means available.
Make your own opinion.
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security.
To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe, visit http://www.counterpane.com/unsubform.html. Back issues are available on http://www.counterpane.com.
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.
Copyright (©) 2000 by Counterpane Internet Security, Inc.
