CRYPTO-GRAM, May 15, 2003

                  CRYPTO-GRAM

                  May 15, 2003

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            [email protected]
          <http://www.counterpane.com>


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

Back issues are available at=20
<http://www.counterpane.com/crypto-gram.html>.  To subscribe, visit=20
<http://www.counterpane.com/crypto-gram.html> or send a blank message=20
to [email protected].

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


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

In this issue:
      Encryption and Wiretapping
      Crypto-Gram Reprints
      News
      Counterpane News
      Security Notes from All Over: Receipts
      Unique E-mail Addresses and Spam
      Comments from Readers


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

           Encryption and Wiretapping



In the long-titled "Report of the Director of the Administrative Office=20
of the United States Courts on Applications for Orders Authorizing or=20
Approving the Interception of Wire, Oral, or Electronic=20
Communications," we find the following interesting quote:

"Public Law 106-197 amended 18 U.S.C. 2519(2)(b) in 2001 to require=20
that reporting should reflect the number of wiretap applications=20
granted in which encryption was encountered and whether such encryption=20
prevented law enforcement officials from obtaining the plain text of=20
communications intercepted pursuant to the court orders.  In 2002, no=20
federal wiretap reports indicated that encryption was=20
encountered.  State and local jurisdictions reported that encryption=20
was encountered in 16 wiretaps terminated in 2002; however, in none of=20
these cases was encryption reported to have prevented law enforcement=20
officials from obtaining the plain text of communications=20
intercepted.  In addition, state and local jurisdictions reported that=20
encryption was encountered in 18 wiretaps that were terminated in=20
calendar year 2001 or earlier, but were reported for the first time in=20
2002; in none of these cases did encryption prevent access to the plain=20
text of communications intercepted."  (Pages 10-11.)

Two points immediately spring forward:

1) Encryption of phone communications is very uncommon.  Sixteen cases=20
of encryption out of 1,358 wiretaps is a little more than one=20
percent.  Almost no suspected criminals use voice encryption.

2) Encryption of phone conversations isn't very effective.  Every time=20
law enforcement encountered encryption, they were able to bypass it.  I=20
assume that local law enforcement agencies don't have the means to=20
brute-force DES keys (for example).  My guess is that the voice=20
encryption was relatively easy to bypass.

These two points can be easily explained by the fact that telephones=20
are closed devices.  Users can't download software onto them like they=20
can on computers.  No one can write a free encryption program for=20
phones.  Even software manufacturers will find it more expensive to=20
sell an added feature for a phone system than for a computer system.

This means that telephone security is a narrow field.  Encrypted phones=20
are expensive.  Encrypted phones are designed and manufactured by=20
companies who believe in secrecy.  Telephone encryption is closed from=20
scrutiny; the software is not subject to peer review.  It should come=20
as no surprise that the result is a poor selection of expensive lousy=20
telephone security products.

For decades, the debate about whether openness helps or hurts security=20
has continued.  It's obvious to us security people that secrecy hurts=20
security, but it's so counterintuitive to the general population that=20
we continually have to defend our position.  This wiretapping report=20
provides hard evidence that a closed security design methodology -- the=20
"trust us because we know these things" way of building security=20
products -- doesn't work.  The U.S. government hasn't encountered a=20
telephone encryption product that they couldn't easily break.

The report:
<http://www.uscourts.gov/wiretap02/2002wttxt.pdf>

My essay on secrecy and security:
<http://www.counterpane.com./crypto-gram-0205.html#1>


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

             Crypto-Gram Reprints



Crypto-Gram is currently in its sixth year of publication.  Back issues=20
cover a variety of security-related topics, and can all be found on=20
<http://www.counterpane.com/crypto-gram.html>.  These are a selection=20
of articles that appeared in this calendar month in other years.

Secrecy, Security, and Obscurity
<http://www.counterpane.com./crypto-gram-0205.html#1>

Fun with Fingerprint Readers
<http://www.counterpane.com./crypto-gram-0205.html#5>

What Military History Can Teach Computer Security, Part 2
<http://www.counterpane.com/crypto-gram-0105.html#1>

The Futility of Digital Copy Protection
<http://www.counterpane.com/crypto-gram-0105.html#3>

Security Standards
<http://www.counterpane.com/crypto-gram-0105.html#7>

Safe Personal Computing
<http://www.counterpane.com/crypto-gram-0105.html#8>

Computer Security: Will we Ever Learn?
<http://www.counterpane.com/crypto-gram-0005.html#ComputerSecurityWillWe=20
EverLearn> or <http://tinyurl.com/bo6m>

Trusted Client Software
<http://www.counterpane.com/crypto-gram-0005.html#TrustedClientSoftware>=20
  or <http://tinyurl.com/bo6p>

The IL*VEYOU Virus (Title bowdlerized to foil automatic e-mail filters.)
<http://www.counterpane.com/crypto-gram-0005.html#ilyvirus>

The Internationalization of Cryptography
<http://www.counterpane.com/crypto-gram-9905.html#international>

The British discovery of public-key cryptography
<http://www.counterpane.com/crypto-gram-9805.html#nonsecret>


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

                      News



The UK is considering e-voting:
<http://politics.guardian.co.uk/egovernment/comment/0,12767,939004,00.ht=20
ml> or <http://tinyurl.com/bo6t>

Funny password story.  And people wonder why security is so hard....
<http://www.computerworld.com/departments/opinions/sharktank/0%2c4885%2c=20
80191%2c00.html> or <http://tinyurl.com/bo6x>

Three interesting essays by Andrew Odlyzko.
"Economics, Psychology, and Sociology of Security":
<http://www.dtc.umn.edu/~odlyzko/doc/econ.psych.security.pdf>
"The Case Against Micropayments":
<http://www.dtc.umn.edu/~odlyzko/doc/case.against.micropayments.pdf>
"The Unsolvable Privacy Problem and its Implications for Security=20
Technologies"
<http://www.dtc.umn.edu/~odlyzko/doc/privacy.unsolvable.pdf>

Cyberterrorism, reality and hype:
<http://www.guardian.co.uk/online/story/0,3605,941970,00.html>

Another article about people mistakenly on the terrorist "watch=20
list."  The problem is what I wrote about last month: there is an=20
incentive for law enforcement to put people on this list, but no=20
incentive for them to take people off.  So the harrassment continues.
<http://www.oregonlive.com/news/oregonian/margie_boule/index.ssf?/base/l=20
iving/1051877124142830.xml> or <http://tinyurl.com/bo6z>

New Web site/blog/whatever.  Fun reading.
<http://stupidsecurity.com/>

Howard Schmidt resigns as the White House Cybersecurity Advisor, and=20
joins eBay as the VP of Security.  I'm not sure what this means for=20
government computer security, but my guess is that it's not good.
<http://www.computerworld.com/securitytopics/security/story/0,10801,8054=20
9,00.html> or <http://tinyurl.com/bo73>
<http://www.gcn.com/vol1_no1/daily-updates/21815-1.html>

The April Fool's RFC from two years ago.  I don't think I ever linked=20
to it.  (It would be funnier if it weren't so true.)
<http://www.isi.edu/in-notes/rfc3093.txt>

Interview with Paul Kocher.  Good points about copy protection.
<http://www.eweek.com/article2/0,3959,1043003,00.asp>

Security problem at Apple.com.  These kinds of problems are pretty=20
common, and are generally the result of programmers taking clever=20
shortcuts when designing Web forms and other interactive=20
features.  It's just easy to store data in the URL, and who thinks=20
about security?
<http://www.wired.com/news/privacy/0,1848,58718,00.html>

A Korean group is suing Microsoft for damages caused by the SQL Slammer=20
worm.  This will be an interesting case to follow, and probably a=20
harbinger of things to come.
<http://www.eweek.com/article2/0,3959,1054790,00.asp>
<http://english.chosun.com/w21data/html/news/200304/200304300025.html>

A majority of cybercrime losses are due to data theft.  I've been=20
saying this for a while, now.
<http://www.vnunet.com/News/1140571>


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

                Counterpane News



Counterpane is exhibiting/participating in several ISCA events: the=20
North America CACS event in Houston (May 18-20), Cyber Security 2003 in=20
Sacramento (May 20).
<http://www.isaca.org/nacacs2003b.htm>
<http://www.CyberSecurity2003.com>

Bruce Schneier recently received a Lifetime Achievement Award from SC=20
Magazine.
<http://www.westcoast.com/events/awards/>


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

     Security Notes from All Over: Receipts



Store owners want their salespeople to ring up a sale and provide a=20
receipt, because that practice also generates an internal register=20
receipt and makes it harder for salespeople to steal from the register:=20
It produces an accurate audit trail.  Honest salespeople don't care one=20
way or another, and in stores where returns are not common -- such as=20
fast-food restaurants or convenience stores -- neither do the=20
customers.   A common security practice is to put a sign on the=20
register that says: "Your purchase free if I fail to give a=20
receipt."  What that sign does is give the customer an interest in=20
paying attention to whether or not she gets a receipt and immediately=20
reporting an employee who doesn't give her one (by demanding her=20
purchase free).  It enlists her as a security agent to defend against=20
employee theft.  The customer has the capability to perform this=20
security function, and the sign gives her the incentive.


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

        Unique E-mail Addresses and Spam



A common security countermeasure against spam is to use unique e-mail=20
addresses when signing up for things.  If someone uses a different=20
e-mail address every time he gets an Amazon account, signs up for a=20
mailing list, or sends off for information, he gets two security=20
benefits.  One, he can track who sells his e-mail address to whom.  And=20
two, he can turn e-mail addresses off when they get too well=20
known.  For someone who has a large number of e-mail addresses=20
available and can point them all to a single e-mail address, it's a=20
quick and easy security countermeasure.  I've done it myself.

Recently a Crypto-Gram subscriber contacted us to complain about=20
his  e-mail address being used.  He subscribed using a unique e-mail=20
address, which was suddenly being spammed.  He was understandably=20
upset;  Counterpane's privacy policy explicitly states that we won't=20
use the Crypto-Gram mailing list for anything other than Crypto-Gram,=20
even Counterpane-related e-mail.

That's our policy, and I know we stick to it.  But if that's true, how=20
did his unique e-mail address get onto spam lists?  We Googled for the=20
unique e-mail address he'd used, and found that he'd posted a message=20
to a mailing list in which he accidentally used it.  Some spam=20
harvester must have recently found that.  He'd even recognized his=20
mistake at the time -- only because someone asked if the string=20
"counterpane" in his address had anything to do with me -- but of=20
course four years later it's hard to remember.

Mystery solved, but there is a larger problem here.  If the slip up=20
hadn't been Googlable, what could I or Counterpane say to prove our=20
innocence?  Using unique e-mail addresses is a good way to figure out=20
who's violating their privacy policy only if you're 100% reliable about=20
using them -- but everyone makes mistakes.  I can easily imagine myself=20
accidentally using a unique alias for the wrong thing and not even=20
noticing.  And the company involved could only defend itself by proving=20
a negative, which is impossible.

The address involved was of the format [email protected],=20
which provides a fairly obvious potential for framing.  There are 63=20
addresses of the form "counterpane@foo" in my subscription logs.  I'll=20
bet at least some of those people have a corresponding "amazon@foo" for=20
their Amazon accounts.  Good thing I don't want to make Amazon look bad....


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

               Comments from Readers



From: "Ian C. Blenke" <[email protected]>
Subject: Physical Denial of Service Attacks

While the "slashdot spam" scenario for postal abuse has become feasible=20
recently, abusing phone service victims with automated fax systems has=20
been possible for quite some time.  Try googling for "request catalog=20
fax" or "request whitepaper fax".



From: "St=E9phane Doyon" <[email protected]>
Subject: Liveness Tests as a Security Countermeasure

 > Individual catalog companies can protect themselves by
 > adding a human test to their sign-up form.   The idea
 > is to add a step that a person can easily do, but a
 > machine can't.  The most common technique is to produce
 > a text image that OCR technology can't understand but
 > the human eye can, and to require that the text be
 > typed into the form.  These have been popping up on
 > Web sites to prevent automatic registration; I've seen
 > them on Yahoo and PayPal, for example.

I would like to point out however that this technique is very=20
frustrating for blind people like me.  Yet another barrier to Web=20
accessibility.  (I don't order paper catalogs much of course, but I was=20
blocked by this technique once or twice for other transactions...)



From: "Steven M. Bellovin" <[email protected]>
Subject:  Security at Ballparks

 >A couple of weeks ago I was listening to a baseball game on the
 >radio.  The announcer was talking about the new antiterrorism security
 >countermeasures at the ballpark.  One of them, he said, was that people
 >are not allowed to bring bottles and cans into the park with them.

I suspect that that is a valid security measure, albeit not because of=20
terrorism.  They're trying to deny people small, heavy objects that=20
they can throw easily -- a problem that has happened.  (A few years=20
ago, when John Rocker was persona non grata among New York Mets fans,=20
batteries were the weapon of choice.)

Not understanding the threat model can make lots of security risks seem=20
absurd.  Imagine what someone who had never heard of timing attacks=20
would think of the RSA blinding step.



From: Erwann Abalea <[email protected]>
Subject:  Security at Ballparks

This kind of security measure has already been applied in France, and=20
maybe in England, for soccer competitions.  The problem is really about=20
security and not about the control of a market, since drinks are not=20
sold in those stadiums.  The fact is that some "hooligans" use bottles,=20
cans, or anything solid to hit other people, or throw these objects on=20
the playfield to hurt the players or the referees.



From: Jon Woodcock <[email protected]>
Subject: Non-Security Agendas

Your baseball piece brought to mind another abuse of the terrorism=20
argument to justify actions motivated by a personal agenda.  The Mayor=20
of Chicago recently arranged for the runway of a local airfield he=20
doesn't like to be dug up in the middle of the night -- his=20
justification, "Homeland Security."  See the saga unfold at=20
<http://www.aopa.org/whatsnew/newsitems/2003/030403meigs.html>.



From: "Vladimir G. Ivanovic" <[email protected]>
Subject: Airport Security

<http://www.parl.gc.ca/37/2/parlbus/commbus/senate/com-e/defe-e/rep-e/re=20
p05jan03-e.pdf> or <http://tinyurl.com/9c46>

After reading the first 60 or so pages of the report, it strikes me=20
that the Committee's recommendations might be effective against=20
yesterday's security threats (airplanes-as-missiles).  Yesterday's=20
threats succeeded because the security procedures in place at the time=20
were designed to be effective against an even older threat=20
(hijackings).  Something is wrong here...

If I were a terrorist, I would not use box cutters.  I'd try something=20
different.  In fact, why target airplanes at all?  A cruise liner, a=20
stadium, a bridge during rush-hour traffic, a nice chemical plant, all=20
would make spectacular headlines.



From: Nathan Rosenblum <[email protected]>
Subject: Mr. al-Hussayen

 >Saudi terrorist sympathizers learn computer security at
 >American universities.  "After studying in Texas and
 >Indiana, al-Hussayen began the University of Idaho's
 >doctoral program in computer science in 1999, with a
 >specialty in computer security and intrusion techniques,
 >according to the indictment."
 ><http://www.washingtonpost.com/wp-dyn/articles/A12758-2003Mar11.html>

Characterizing Mr. al-Hussayen as a "terrorist sympathizer" is=20
inaccurate.  At most, Sami is suspected of being involved with=20
organizations that contribute to terrorism.  It should be noted that=20
the actual charges against him relate to visa violations stemming from=20
the fact that he allegedly did not report membership in an organization=20
while applying for a visa.  Additionally, he is accused of working for=20
the IANA while studying at the University of Idaho (persons holding=20
student visas are not permitted to engage in activity unrelated to=20
their academic pursuits).

While I have difficulty believing that my former colleague knowingly=20
aided a terror-supporting organization through the alleged financial=20
transfers or through Web site development, it certainly is not=20
impossible.  Still, I feel that it would be more responsible to prepend=20
"suspected" to "terrorist sympathizer."  Indeed, even if Sami=20
al-Hussayen is convicted of the charges against him and is forced to=20
leave with his family for Saudi Arabia, it will still not be possible=20
to characterize him as a "terrorist sympathizer" on that basis; Sami=20
will not be tried on terror-related charges.


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


CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,=20
insights, and commentaries on computer security and cryptography.  Back=20
issues are available on <http://www.counterpane.com/crypto-gram.html>.

To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or=20
send a blank message to [email protected].  To=20
unsubscribe, visit <http://www.counterpane.com/unsubform.html>.

Please feel free to forward CRYPTO-GRAM to colleagues and friends who=20
will find it valuable.  Permission is granted to reprint CRYPTO-GRAM,=20
as long as it is reprinted in its entirety.

CRYPTO-GRAM is written by Bruce Schneier.  Schneier is founder and CTO=20
of Counterpane Internet Security Inc., the author of "Secrets and Lies"=20
and "Applied Cryptography," and an inventor of the Blowfish, Twofish,=20
and Yarrow algorithms.  He is a member of the Advisory Board of the=20
Electronic Privacy Information Center (EPIC).  He is a frequent writer=20
and lecturer on computer security and cryptography.

Counterpane Internet Security, Inc. is the world leader in Managed=20
Security Monitoring.  Counterpane's expert security analysts protect=20
networks for Fortune 1000 companies world-wide.

<http://www.counterpane.com/>

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