CRYPTO-GRAM May 15, 2003 by Bruce Schneier Founder and CTO Counterpane Internet Security, Inc. schneier@counterpane.com A free monthly newsletter providing summaries, analyses, insights, and=20 commentaries on computer security and cryptography. Back issues are available at=20 . To subscribe, visit=20 or send a blank message=20 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=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: My essay on secrecy and security: ** *** ***** ******* *********** ************* 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 . These are a selection=20 of articles that appeared in this calendar month in other years. Secrecy, Security, and Obscurity Fun with Fingerprint Readers What Military History Can Teach Computer Security, Part 2 The Futility of Digital Copy Protection Security Standards Safe Personal Computing Computer Security: Will we Ever Learn? or Trusted Client Software =20 or The IL*VEYOU Virus (Title bowdlerized to foil automatic e-mail filters.) The Internationalization of Cryptography The British discovery of public-key cryptography ** *** ***** ******* *********** ************* News The UK is considering e-voting: or Funny password story. And people wonder why security is so hard.... or Three interesting essays by Andrew Odlyzko. "Economics, Psychology, and Sociology of Security": "The Case Against Micropayments": "The Unsolvable Privacy Problem and its Implications for Security=20 Technologies" Cyberterrorism, reality and hype: 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. or New Web site/blog/whatever. Fun reading. 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. or 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.) Interview with Paul Kocher. Good points about copy protection. 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? 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. A majority of cybercrime losses are due to data theft. I've been=20 saying this for a while, now. ** *** ***** ******* *********** ************* 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). Bruce Schneier recently received a Lifetime Achievement Award from SC=20 Magazine. ** *** ***** ******* *********** ************* 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 name+counterpane@machine.domain,=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" 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" 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" 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 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 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 . From: "Vladimir G. Ivanovic" Subject: Airport Security or 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 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." > 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 . To subscribe, visit or=20 send a blank message to crypto-gram-subscribe@chaparraltree.com. To=20 unsubscribe, visit . 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. Copyright (c) 2003 by Counterpane Internet Security, Inc.