CRYPTO-GRAM, February 15, 2000

[mea culpa <jericho () DIMENSIONAL COM>]

From: Bruce Schneier <schneier () counterpane com>


                  CRYPTO-GRAM

               February 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier () counterpane com
           http://www.counterpane.com


A free monthly newsletter providing summaries, analyses, insights, and
commentaries on computer security and cryptography.

Back issues are available at http://www.counterpane.com.  To subscribe or
unsubscribe, see below.


Copyright (c) 2000 by Counterpane Internet Security, Inc.


** *** ***** ******* *********** *************

In this issue:
      Distributed Denial-of-Service Attacks
      New Chinese Cryptography Regulations
      Counterpane Internet Security News
      Publicizing Vulnerabilities
      Counterpane -- Featured Research
      News
      Mitnick Case Yields New Crypto Twist
      The Doghouse:  X.com
      Cookies
      Comments from Readers


** *** ***** ******* *********** *************

     Distributed Denial-of-Service Attacks



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>


** *** ***** ******* *********** *************

      New Chinese Cryptography Regulations



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>


** *** ***** ******* *********** *************

      Counterpane Internet Security News



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


** *** ***** ******* *********** *************

          Publicizing Vulnerabilities



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#KeyFindingAttacksandPublic
ityAttacks>

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.


** *** ***** ******* *********** *************

       Counterpane -- Featured Research



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


** *** ***** ******* *********** *************

                     News



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=zdhpnew
s01>

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>

** *** ***** ******* *********** *************

      Mitnick Case Yields New Crypto Twist



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>


** *** ***** ******* *********** *************

              The Doghouse:  X.com



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



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>


** *** ***** ******* *********** *************

               Comments from Readers



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:
- He broke a "fairly solid 96 digits code" [i.e. 320 bits] used by the
Groupement for the "CB" credit cards, with details consistent with an RSA
signature scheme with simple redundancy.
- He made a spectacular demonstration to experts, factoring some special
format 640-bit public modulus, guessing the factors had been chosen close
to the square root of the modulus and with some special properties.  He is
clear his method does not work in a general case.  He makes no explicit
claim 640-bit signatures are used in the counterfeit Smart Cards.  I failed
to find any independent confirmation of a 640-bit factorization by Humpich,
or even any other statement attributed to Humpich that he ever factored a
640-bit RSA key.

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:
- Factoring the systemwide public modulus of 321 bits, which corresponding
secret key is used at card issuance to produce a static 320-bit RSA
signature held in the card, certifying the 16 digits card number and expiry
date; this static signature being checked by POSTs as a simple off-line
validation of the card.
- Making working Smart Cards holding counterfeit card number, expiry date,
and signature thereof.

<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 computer security and cryptography.

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 founder and CTO of
Counterpane Internet Security Inc., 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 computer security
and cryptography.

Counterpane Internet Security, Inc. is a venture-funded company bringing
innovative managed security solutions to the enterprise.

http://www.counterpane.com/

Copyright (c) 2000 by Counterpane Internet Security, Inc.

ISN is sponsored by Security-Focus.COM