LWN.net Logo

May CRYPTO-GRAM newsletter

From:  Bruce Schneier <schneier@counterpane.com>
To:  crypto-gram@chaparraltree.com
Subject:  CRYPTO-GRAM, May 15, 2003
Date:  Wed, 14 May 2003 23:57:49 -0500

                  CRYPTO-GRAM

                  May 15, 2003

               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/crypto-gram.html>.  To subscribe, visit 
<http://www.counterpane.com/crypto-gram.html> or send a blank message 
to crypto-gram-subscribe@chaparraltree.com.

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 
of the United States Courts on Applications for Orders Authorizing or 
Approving the Interception of Wire, Oral, or Electronic 
Communications," we find the following interesting quote:

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

Two points immediately spring forward:

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

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

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

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

For decades, the debate about whether openness helps or hurts security 
has continued.  It's obvious to us security people that secrecy hurts 
security, but it's so counterintuitive to the general population that 
we continually have to defend our position.  This wiretapping report 
provides hard evidence that a closed security design methodology -- the 
"trust us because we know these things" way of building security 
products -- doesn't work.  The U.S. government hasn't encountered a 
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 
cover a variety of security-related topics, and can all be found on 
<http://www.counterpane.com/crypto-gram.html>.  These are a selection 
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 
EverLearn> or <http://tinyurl.com/bo6m>

Trusted Client Software
<http://www.counterpane.com/crypto-gram-0005.html#TrustedClientSoftware> 
  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 
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 
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 
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 
list."  The problem is what I wrote about last month: there is an 
incentive for law enforcement to put people on this list, but no 
incentive for them to take people off.  So the harrassment continues.
<http://www.oregonlive.com/news/oregonian/margie_boule/index.ssf?/base/l 
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 
joins eBay as the VP of Security.  I'm not sure what this means for 
government computer security, but my guess is that it's not good.
<http://www.computerworld.com/securitytopics/security/story/0,10801,8054 
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 
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 
common, and are generally the result of programmers taking clever 
shortcuts when designing Web forms and other interactive 
features.  It's just easy to store data in the URL, and who thinks 
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 
worm.  This will be an interesting case to follow, and probably a 
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 
saying this for a while, now.
<http://www.vnunet.com/News/1140571>


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

                Counterpane News



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

Bruce Schneier recently received a Lifetime Achievement Award from SC 
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 
receipt, because that practice also generates an internal register 
receipt and makes it harder for salespeople to steal from the register: 
It produces an accurate audit trail.  Honest salespeople don't care one 
way or another, and in stores where returns are not common -- such as 
fast-food restaurants or convenience stores -- neither do the 
customers.   A common security practice is to put a sign on the 
register that says: "Your purchase free if I fail to give a 
receipt."  What that sign does is give the customer an interest in 
paying attention to whether or not she gets a receipt and immediately 
reporting an employee who doesn't give her one (by demanding her 
purchase free).  It enlists her as a security agent to defend against 
employee theft.  The customer has the capability to perform this 
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 
addresses when signing up for things.  If someone uses a different 
e-mail address every time he gets an Amazon account, signs up for a 
mailing list, or sends off for information, he gets two security 
benefits.  One, he can track who sells his e-mail address to whom.  And 
two, he can turn e-mail addresses off when they get too well 
known.  For someone who has a large number of e-mail addresses 
available and can point them all to a single e-mail address, it's a 
quick and easy security countermeasure.  I've done it myself.

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

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

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

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


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

               Comments from Readers



From: "Ian C. Blenke" <ian@blenke.com>
Subject: Physical Denial of Service Attacks

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



From: "Stéphane Doyon" <s.doyon@videotron.ca>
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 
frustrating for blind people like me.  Yet another barrier to Web 
accessibility.  (I don't order paper catalogs much of course, but I was 
blocked by this technique once or twice for other transactions...)



From: "Steven M. Bellovin" <smb@research.att.com>
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 
terrorism.  They're trying to deny people small, heavy objects that 
they can throw easily -- a problem that has happened.  (A few years 
ago, when John Rocker was persona non grata among New York Mets fans, 
batteries were the weapon of choice.)

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



From: Erwann Abalea <erwann.abalea@certplus.com>
Subject:  Security at Ballparks

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



From: Jon Woodcock <jpwoodcock@yahoo.co.uk>
Subject: Non-Security Agendas

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



From: "Vladimir G. Ivanovic" <vladimir@acm.org>
Subject: Airport Security

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

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

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



From: Nathan Rosenblum <flander@smurf.to>
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 
inaccurate.  At most, Sami is suspected of being involved with 
organizations that contribute to terrorism.  It should be noted that 
the actual charges against him relate to visa violations stemming from 
the fact that he allegedly did not report membership in an organization 
while applying for a visa.  Additionally, he is accused of working for 
the IANA while studying at the University of Idaho (persons holding 
student visas are not permitted to engage in activity unrelated to 
their academic pursuits).

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


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


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

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

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 "Secrets and Lies" 
and "Applied Cryptography," and an inventor of the Blowfish, Twofish, 
and Yarrow algorithms.  He is a member of the Advisory Board of the 
Electronic Privacy Information Center (EPIC).  He is a frequent writer 
and lecturer on computer security and cryptography.

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

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

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



(Log in to post comments)

Telephone encryption and closed algorithm security

Posted May 15, 2003 19:45 UTC (Thu) by MortFurd (guest, #9389) [Link]

QUOTE:
Two points immediately spring forward:

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

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

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

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

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

END QUOTE

I think there are other possibilites that should be considered. There is voice encryption (encrypted digital transmission of voice) and voice scrambling on the market today. True encryption devices can't be bought by just any Tom, Dick, or Harry. Try sometime and you'll see. Voice scrambling, on the other hand, is much easier to come by - and at lower security levels quite trivial to crack since it is purely analog.
Voice scrambling is nothing more than frequency inversion. More secure systems change inversion frequencies more rapidly and use more elaborate schemes for staying synchronized.

The lowest level systems use a single fixed inversion frequency which can easily be "cracked." Slightly more secure systems change inversion frequencies up to a few times per second.

A mid-level system changes inversion frequencies up to a few hundred times a second. High level systems change frequencies up a thousand times per second. Anything above the lowest level uses a pseudo random number generator to select the next frequency at each change.

For the lower levels, no improvement in the random number generation is going to help. The inversion is to easy to get around. At the very low levels, a human being can change his decoder frequencies manually fast enough to decode everything - and if he has a recording then there's really nothing to it.

The higher levels are impossible to decode by hand - they aren't commonly available, though.

The decoder need not match the encoder perfectly, either. A match to within about 200Hz is good enough for intelligibilty.

Due to the bandwidth limitations of the analog telephone network, and echoes and other problems, a telephone scrambling unit actually has a very limited range of inversion frequencies it can use. It is also limited in the rate at which it can change frequencies. Because of these limitations, and because plus or minus 200Hz is a good enough match, it is usually sufficient to set a simple inverter to somewhere near the middle of the scrambling units inversion frequency range. The audio will be distorted to some extent, but intelligible enough for a trained ear to understand perfectly well. Some people with enough experience can "decode" the lower level systems with nothing but their ears.

Manufacturers routinely market analog scrambling equipment as "voice encryption equipment." That is not strictly true, but it is close enough for marketing types and for the people who purchase it.

I've read the referenced report, and nowhere does it mention the type of encryption used. Since the average person on the street doesn't differentiate between encyrption and scrambling, I would venture to say that in most (if not all) cases analog scrambling was used.

Since the referenced cases were probably not using digital encryption, picking on the algorithm is rather like blaming a break in on the padlock on the front door, when in reality the thief simply walked around back and kicked in a window.

Given the different types of equipment available, and the lack of details in the study, it would seem that the study has no great relevance to the discussion of open versus closed algorithm security.

Copyright © 2003, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds