Crypto-Gram Newsletter

November 15, 2000

by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
schneier@schneier.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:


Why Digital Signatures Are Not Signatures

When first invented in the 1970s, digital signatures made an amazing promise: better than a handwritten signature -- unforgeable and uncopyable -- on a document. Today, they are a fundamental component of business in cyberspace. And numerous laws, state and now federal, have codified digital signatures into law.

These laws are a mistake. Digital signatures are not signatures, and they can't fulfill their promise. Understanding why requires understanding how they work.

The math is complex, but the mechanics are simple. Alice knows a secret, called a private key. When she wants to "sign" a document (or a message, or any bucket of bits), she performs a mathematical calculation using the document and her private key; then she appends the results of that calculation -- called the "signature" -- to the document. Anyone can "verify" the signature by performing a different calculation with the message and Alice's public key, which is publicly available. If the verification calculation checks out then Alice must have signed the document, because only she knows her own private key.

Mathematically, it works beautifully. Semantically, it fails miserably. There's nothing in the description above that constitutes signing. In fact, calling whatever Alice creates a "digital signature" was probably the most unfortunate nomenclature mistake in the history of cryptography.

In law, a signature serves to indicate agreement to, or at least acknowledgment of, the document signed. When a judge sees a paper document signed by Alice, he knows that Alice held the document in her hands, and has reason to believe that Alice read and agreed to the words on the document. The signature provides evidence of Alice's intentions. (This is a simplification. With a few exceptions, you can't take a signed document into court and argue that Alice signed it. You have to get Alice to testify that she signed it, or bring handwriting experts in and then it's your word against hers. That's why notarized signatures are used in many circumstances.)

When the same judge sees a digital signature, he doesn't know anything about Alice's intentions. He doesn't know if Alice agreed to the document, or even if she ever saw it.

The problem is that while a digital signature authenticates the document up to the point of the signing computer, it doesn't authenticate the link between that computer and Alice. This is a subtle point. For years, I would explain the mathematics of digital signatures with sentences like: "The signer computes a digital signature of message m by computing m^e mod n." This is complete nonsense. I have digitally signed thousands of electronic documents, and I have never computed m^e mod n in my entire life. My computer makes that calculation. I am not signing anything; my computer is.

PGP is a good example. This e-mail security program lets me digitally sign my messages. The user interface is simple: when I want to sign a message I select the appropriate menu item, enter my passphrase into a dialog box, and click "OK." The program decrypts the private key with the passphrase, and then calculates the digital signature and appends it to my e-mail. Whether I like it or not, it is a complete article of faith on my part that PGP calculates a valid digital signature. It is an article of faith that PGP signs the message I intend it to. It is an article of faith that PGP doesn't ship a copy of my private key to someone else, who can then sign whatever he wants in my name.

I don't mean to malign PGP. It's a good program, and if it is working properly it will indeed sign what I intended to sign. But someone could easily write a rogue version of the program that displays one message on the screen and signs another. Someone could write a Back Orifice plug-in that captures my private key and signs documents without my consent or knowledge. We've already seen one computer virus that attempts to steal PGP private keys; nastier variants are certainly possible.

The mathematics of cryptography, no matter how strong, cannot bridge the gap between me and my computer. Because the computer is not trusted, I cannot rely on it to show me what it is doing or do what I tell it to. Checking the calculation afterwards doesn't help; the untrusted computer can't be relied upon to check the calculations properly. It wouldn't help to verify the code, because the untrusted computer is running the code (and probably doing the verification). It wouldn't even help to store the digital signature key in a secure module: the module still has to rely on the untrusted computer for input and output.

None of this bodes well for digital signatures. Imagine Alice in court, answering questions about a document she signed. "I never saw it," she says. "Yes, the mathematics does prove that my private key signed the document, but I never saw it." And then an expert witness like myself is called to the stand, who explains to the judge that it is possible that Alice never saw the document, that programs can be written to sign documents without Alice's knowledge, and that Alice's digital signature doesn't really mean anything about Alice's intentions.

Solving this problem requires a trusted signing computer. If Alice had a small hand-held computer, with its own screen and keyboard, she could view documents on that screen and sign them with that keyboard. As long as the signing computer is trusted, her signatures are trusted. (But problems remain. Viewing a Microsoft Word document, for example, generally involves the very software most responsible for welcoming a virus into the computer.) In this case we're no longer relying on the mathematics for security, but instead the hardware and software security of that trusted computer.

This is not to say that digital signatures are useless. There are many instances where the insecurities discussed here are not relevant, or where the dollar value of the signatures is small enough not to warrant worrying about them. There are also instances where authenticating to the signing computer is good enough, and where no further authentication is required. And there are instances where real-world relationships can obviate the legal requirements that digital signatures have been asked to satisfy.

Digital signatures prove, mathematically, that a secret value known as the private key was present in a computer at the time Alice's signature was calculated. It is a small step from that to assume that Alice entered that key into the computer at the time of signing. But it is a much larger step to assume that Alice intended a particular document to be signed. And without a tamperproof computer trusted by Alice, you can expect "digital signature experts" to show up in court contesting a lot of digital signatures.

Comments on the new federal digital signature law:
<http://www4.zdnet.com:80/intweek/stories/news/...> (multipage, don't miss the others) <http://www4.zdnet.com:80/intweek/stories/news/...>
<http://www.infoworld.com:80/articles/hn/xml/00/10/...> <http://www.pioneerplanet.com/tech/tcv_docs/028992.htm>

A survey of laws in various states and countries:
<http://rechten.kub.nl/simone/DS-LAWSU.HTM>


Crypto-Gram Reprints

Programming Satan's Computer: Why Computers are Insecure
<http://www.schneier.com/...>

Elliptic-Curve Public-Key Cryptography
<http://www.schneier.com/...>

The Future of Fraud: Three reasons why electronic commerce is different
<http://www.schneier.com/...>

Why copy protection does not work:
<http://www.schneier.com/crypto-gram-9811.html#copy>


News

A cyber Underwriters Laboratory? Don't hold your breath.
<http://www.zdnet.com/enterprise/stories/main/...>

The government of France concludes that Echelon is a threat to privacy. (Their report identifies two Echelon sites in Australia.)
<http://cgi.zdnet.com/slink?59369:8469234> <http://www.it.fairfax.com.au/breaking/20001020/...>

The stolen Enigma machine has been returned:
<http://news.bbc.co.uk/hi/english/uk/newsid_977000/...>

People are worried about security in cyberspace:
<http://dailynews.yahoo.com/h/nm/20001016/ts/...> And yet again, industry analysts predict security problems.
<http://www.nwfusion.com/news/2000/1011attack50.html>

Good essay on hackers and the hacker ethic:
<http://www.feedmag.com/essay/es405_master.html>

About a year ago Carl Ellison and I wrote "10 Risks of PKI":
<http://www.schneier.com/paper-pki.html> Here is a rebuttal:
<http://members.nbci.com/aram_perez/...> [link moved to http://home.pacbell.net/aram/responsetenrisks.html]

Remote-controlled robot spy:
<http://www.newscientist.com/nlf/1021/follow.html> Military version of the same idea:
<http://www.newscientist.com/news/news.jsp?id=ns226113>

Two NSA documents about their own culture and disorganization:
<http://www.nsa.gov/releases/...> <http://www.nsa.gov/releases/...>
Both reports are available as HTML: <http://cryptome.org/nsa-reorg-et.htm>
<http://cryptome.org/nsa-reorg-net.htm>
And an article on the reports:
<http://www.theregister.co.uk/content/1/14170.html>

Putting tracking chips in people:
<http://www.digitalangel.net/>

Two useful publications from the Electronic Privacy Information Center.
The 2000 Privacy Law Sourcebook:
<http://www.epic.org/pls>
The 2000 edition of the Privacy and Human Rights survey: <http://www.epic.org/bookstore/phr/>
Both are worth buying, and EPIC is worth supporting.

Software and hardware vendors treat security problems as public-relations problems. No surprise; I've been saying this for years.
<http://www.zdnet.com/sp/stories/column/...>

Interesting article on the threats to business information:
<http://www.cnn.com/2000/TECH/computing/10/18/...>

The European Cybercrime Treaty threatens human rights.
<http://www.zdnet.co.uk/news/2000/41/ns-18546.html> [link moved to http://news.zdnet.co.uk/story/0,,s2082055,00.html

The AES algorithm as been chosen, but it's still a long and complicated road towards standardization.
<http://www.nwfusion.com/news/2000/1016apps.html>
A good summary article on the AES process:
<http://www.javaworld.com/javaworld/jw-10-2000/...>
An article on a talk I gave on AES:
<http://www.theregister.co.uk/content/1/14435.html>

An article that challenges the assumption that no two fingerprints are exactly alike. This kind of thing has interesting implications for biometrics:
<http://www.linguafranca.com/print/0011/...>

Cheating is rampant on multi-player computer games. This excellent summary article discusses the general classes of cheats, and tries to offer some ways to mitigate the problem. The lessons apply equally well to other Internet based systems: commerce, community, etc. Well worth reading.
<http://www.gamasutra.com/features/20000724/...>

Despite a White House prohibition, 13 U.S. government agencies are secretly using technology that tracks the Internet habits of people visiting their Web sites, and in at least one case provides the information to a private company.
<http://abcnews.go.com/sections/tech/DailyNews/...>

FBI agent Marcus C. Thomas (who is mentioned in the EPIC FOIA documents) discussed Carnivore at a presentation at NANOG 20.
<http://cryptome.org/carnivore-demo.htm>

Publius: anonymous posting of files on the Internet. How it works:
<http://www.sciam.com/2000/1000issue/1000techbus2.html>

The U.S. has implemented new, and more lenient, encryption export regulations. On October 19, the U.S. Department of Commerce's Bureau of Export Administration (BXA) published an amendment to its export regulations on encryption products. The new rule amends the Export Administration Requirements (EAR) and liberalizes exports and re-exports of encryption products to the fifteen European Union member states plus Australia, the Czech Republic, Hungary, Japan, New Zealand, Norway, Poland and Switzerland. The text of the revised rules are available at:
<http://www.bxa.doc.gov/Encryption/pdfs/...>
News reports:
<http://www.cnn.com/2000/TECH/computing/10/19/...> <http://www.usatoday.com/life/cyber/tech/cti691.htm>

SANS Security Alert, including security predictions for 2001 (mine are in there, too):
<http://www.sans.org/SANSSecAlert2_102000.pdf>

Mideast cyberwar: Israeli and Palestinian hackers are attacking each other's networks:
<http://www.zdnet.com/zdnn/stories/news/...>
And this cyberwar is spreading to the U.S.
<http://www.wired.com/news/business/0,1367,39913,00.html>

Ross Anderson reports an example of a semantic attack, this one a glitch: "British newspapers today reported that a baby was born at Eastbourne General Hospital by Caesarian section, the operation being performed under torchlight following a power cut caused by a storm. On one account, the standby generators couldn't be started as the computer that controlled them believed they were already on; and when power was restored after twenty minutes it could not be switched through to the operating theatre as the computer believed that the generators were still running. On another account, the computer refused to believe that the power had gone off in the first place." Attacks of this type will similarly target the inability of computers to collect corroborating information before making decisions.
<http://www.guardian.co.uk/uk_news/story/...>

Another commentary on semantic attacks:
<http://www.securityfocus.com/commentary/104>

Incident-response database:
<https://cassandra.cerias.purdue.edu/main/index.htmls>


Counterpane Internet Security News

The Smithsonian is sponsoring a lecture and book signing at the International Monetary Fund Center:
720 19th Street, N.W., Washington, DC, on 29 November at 6:30 - 8:00 p.m. Everyone is invited.

Bruce Schneier is chosen as one of the 20 executives to watch by CRN magazine:
<http://www.crn.com/Components/Search/Article.asp?...> <http://www.crn.com/Components/Search/Article.asp?...>

Managed Security Monitoring:
<http://www.techrepublic.com/article.jhtml?...>

Decent article on Schneier's BlackHat talk:
<http://www.techtv.com/news/hackingandsecurity/story/...> [link dead as of 2001-05-01; try http://www.techtv.com/news/hackingandsecurity/story/...]


Secrets and Lies News

Worldwide sales stand at 45,000; the book is in its fourth printing. (About two dozen typos are corrected in this latest printing, none serious.) The book tour has been a success; thanks to all who attended one of the events.

Book Web site:
<http://www.schneier.com/book-sandl.html>

Upside magazine has excerpted Chapter 2:
<http://www.upside.com/Ebiz/39ac19eb0.html>

More book reviews:
<http://www.latimes.com/business/columns/innovation/...> <http://www.byte.com/column/BYT20001018S0001>
<http://www.matrix.net/publications/mn/...>
All reviews:
<http://www.schneier.com/book-sandl-rev.html>

Buy the book here:
<http://www.amazon.com/exec/obidos/ASIN/0471253111/...>
Through Amazon's affiliates program, sales of this book have raised over $6000 for the Electronic Privacy Information Center.


SDMI Hacking Challenge

The Secure Digital Music Initiative issued a hacking challenge in an attempt to prove its content-protection system safe. Despite a widespread boycott of the challenge, a team of researchers claims to have broken all the SDMI security technologies.

These are all points I've discussed before, but let's review.

1. Hacking contests are meaningless; they do not show security. Just because a technology survives a contest does not mean that it is secure. (Remember, hackers don't play fair.) Near as I can tell, the SDMI break does not conform to the challenge rules, and the music industry might claim that the SDMI schemes survived the technology.

2. Even if the contest was meaningful and the technology survived it, watermarking does not work. It is impossible to design a music watermarking technology that cannot be removed. Here's a brute-force attack: play the music and re-record it. Do it multiple times and use DSP technology to combine the recordings and eliminate noise. Almost always there is a shortcut technique to neutralize the watermark, but the brute-force attack always works.

3. Even if watermarking works, it does not solve the content-protection problem. If a media player only plays watermarked files, then copies of a file will play. If a media player refuses to play watermarked files, then analog-to-digital copies will still work. If a watermark is designed to identify the legitimate owner of the file, it still doesn't prove who copied the file or provide the copyright owner with a party worth suing.

Digital files intrinsically undermine the scarcity model of business: replicate many copies and sell each one. Companies that find alternate ways to do business, whether they be advertising funded, or patronage funded, or membership funded, or whatever, are likely to survive the digital economy. The media companies figured this out quickly when radio was invented -- and then television -- so why are they so slow to realize it this time around?

The challenge:
<http://www.hacksdmi.org/> <http://www.salon.com/tech/log/2000/09/14/hack_sdmi/...>

The boycott:
<http://slashdot.org/articles/00/09/15/1244236.shtml> <http://www2.linuxjournal.com/articles/misc/0022.html>

The break:
<http://biz.yahoo.com/prnews/001108/dc_sdmi_ex.html> <http://www.zdnet.co.uk/news/2000/44/ns-18963.html> [link moved to http://news.zdnet.co.uk/story/0,,s2082462,00.html]
<http://www.wired.com/news/technology/...> <http://www.salon.com/tech/log/2000/11/08/sdmi_tests/...>
<http://www.washingtonpost.com/wp-dyn/articles/...>

SDMI's denial:
<http://www.theregister.co.uk/content/1/14608.html> <http://www.salon.com/tech/log/2000/11/08/sdmi_tests/...>

A nice analysis:
<http://www.eet.com/story/OEG20001031S0037>

Article about DMCA provisions becoming active:
<http://www.securityfocus.com/templates/article.html?...>

URL of an interesting (for its reasoning and justification) but lengthy "rule-making process" under DMCA, which came into effect on 28 Oct 2000:
<http://cryptome.org/dmca102700.txt>

I wrote about the futility of hacking contests in Crypto-Gram two years ago, and in Secrets and Lies.
<http://www.schneier.com/...>

I also wrote about the futility of digital content protection:
<http://www.schneier.com/crypto-gram-9811.html#copy>

The most ironic part of this story: this kind of testing is not legal under the Digital Millennium Copyright Act, unless SDMI specifically agrees to it.


Microsoft Hack (the Company, not a Product)

First the attack lasted three months. Then it was six weeks and the attackers had access to major source code. Then, it was only five or six days. Now it's 12 days but they didn't see anything interesting. Soon, the whole thing will have been a penetration test by a Microsoft tiger team. And when Bill Gates finally takes over the world, he'll have Winston Smith consign all copies of the story to a memory hole, since it will never have happened.

I don't buy Microsoft's rewriting of history. If the attacker didn't get anything interesting, why was the FBI called in? The FBI has better things to do than trace every two-bit cracker that knocks on Microsoft's door. If the Trojan only got onto a home computer of a Microsoft employee or contractor, why did Microsoft block access to its corporate network for all of its employees, globally, over the weekend? Why did they make everyone change their passwords afterward?

Near as I can tell, this is how Microsoft was hacked:

1) An unknown employee received an e-mail carrying the QAZ Trojan, and inadvertently installed it, possibly on a machine at home he used to connect to the Microsoft network. (QAZ first appeared in China around July.) This virus-like software disguises itself as Notepad, a Windows program used for reading text messages.

2) QAZ then sent a remote signal to a computer in Asia with the location on the Internet of the newly infected computer. QAZ also may have automatically downloaded and installed hacker tools from a Web site in the South Pacific, but I don't know that for sure. There may be other malicious code involved, but I am not sure about that either. QAZ then gave the intruder some control over the victim's computer, and it automatically tried to spread to any computers it found in that section of Microsoft's network.

3) The hackers used another program to collect employee passwords, which were automatically sent to a Russian e-mail address.

4) Posing as Microsoft employees working off-campus, the hackers used the pilfered passwords to enter sensitive areas of the network and downloaded files.

Others have done an admirable job reporting on the events, but some points still need to be made:

1) This isn't a professional job; it's an opportunistic one. The attacker got in via a Trojan, stole some passwords, wandered around the network for a while, and was eventually tossed out. A professional would have gotten in, gotten the goods, and left. Microsoft would never have known anyone was there.

2) I doubt the attacker modified any source code. Modifying source code in ways that don't break it is hard, even for the authors. And Microsoft probably has good version control on its code; changes would get noticed.

3) Some reports have wondered why so many Microsoft employees have access to the source code. It's because Microsoft is a software company, and giving employees access to the software is a good thing. Sure, Microsoft could limit access to only the people who obviously need access, but that would encourage myopia, reduce collaboration, and limit synergy. The U.S. military works this way: people need a security clearance to view information of a certain classification, and also need to demonstrate "need to know" for any given piece of information. In doing this, the military deliberately chooses security over effectiveness. Microsoft is not the military; in choosing to share information they made the smarter choice.

4) Some reports have claimed "poetic justice": Microsoft hacked by flaws in its own products. While technically true, this is unfair. Any network of this size and complexity will have dozens, if not hundreds, of security vulnerabilities. The attackers got in through a vulnerability in a Microsoft product, but they could have just as easily chosen another route. If the network were entirely SunOS or Linux or whatever, there would be different vulnerabilities. The moral is not that Microsoft products are insecure, it's that complex systems are insecure.

5) The only way to defend against this sort of thing is real-time network monitoring. Given that vulnerabilities exist, and always will, detection and response are the only countermeasures that work. I know this sounds self-serving, but in all honesty this is exactly the kind of attack I built Counterpane Internet Security to defend against. If we were watching Microsoft, we would have seen this immediately.

6) This kind of thing happens all the time, to everyone. Microsoft may be this month's poster child for bad security, but don't think they're unique. The amazing thing isn't that Microsoft noticed after three months (or six weeks), it's that they noticed at all.

7) Networks that are "political" are more vulnerable: Microsoft, cigarette companies, drug companies, governments, political parties. These networks are more likely to be targeted than random corporate networks.

8) The most damage was to Microsoft's image. This is what they spent the most effort repairing: spinning the story, limiting the press damage, and so forth. These secondary risks -- bad publicity, loss of good name, potential shareholder liability -- are often far more dangerous than direct losses.

9) Microsoft's spin-control hurt. Many were not fooled. Lots of hackers became incensed at Microsoft's boasting. There has already been two additional public -- and successful -- attacks against Microsoft in the days following this story. I believe that the attacker wanted to prove Microsoft wrong. And I believe there will be others.

Morals: Always keep your antivirus software up to date, monitor your network in real time, and don't believe that you are invulnerable. Static passwords are not sufficient to protect your major corporate assets. And please don't rewrite history; others can't learn from your mistakes that way, and I'm sure the FBI will lose patience with you pretty quickly.

The Associated Press coverage:
<http://www.courierpress.com/cgi-bin/view.cgi?200010/...>

Microsoft changes its story:
<http://www.zdnet.com/zdnn/stories/news/...> <http://www.zdnet.com/zdnn/stories/comment/...>

Skepticism about the new story:
<http://www.theregister.co.uk/content/1/14306.html> <http://www.theregister.co.uk/content/1/14327.html>

Top 10 Things Bill Gates said when he heard Microsoft was hacked:
<http://www.zdnet.com/zdnn/stories/comment/...>

Commentary on the attackers' motivations:
<http://www.securityfocus.com/commentary/112>

Legal ramifications of seeing the stolen source code:
<http://www.linuxjournal.com/articles/currents/0024.html>

Lessons of the attack:
<http://www.zdnet.com/eweek/stories/general/...> <http://www.zdnet.com/zdnn/stories/news/...>
<http://securityportal.com/articles/...> <http://www.zdnet.com/zdnn/stories/comment/...>
<http://dailynews.yahoo.com/h/nm/20001029/tc/...>

Other attacks against Microsoft:
<http://www.infoworld.com/articles/hn/xml/00/11/03/...> <http://thestandard.com/article/display/...>


Comments from Readers

From: Ben_Tilly trepp.com
Subject: Semantic Attacks
In your article on semantic attacks you mention rewriting history. I have seen it in action.
In January of 1999 reports appeared that Windows NT had failed FIPS 140-1 and this was a black eye since it meant that the US government was not supposed to use it. A few months later, without fanfare, most of those reports had disappeared.
Now there is reason to believe that the initial reports were mistaken, but the fact that they were simply deleted bothers me quite a bit.
Particularly since Microsoft has apparently brought pressure to bear to keep people from reporting over the last few years how Microsoft marketed NT 3.51 and then NT 4.0 as having a C2 level of security when it had no such certification. Indeed the team that managed to certify NT 3.5 with service pack 3 flat out told Microsoft that they would not meet the standard with 4.0. (They thought that NT 3.51 would pass, but contrary to popular belief it was never tested.) And indeed after several years and 6 service packs, the closest that Microsoft came was a UK rating which they claim is equivalent to the US C2 Orange Book.
Change that from a bit. It *really* bothers me that Microsoft could manage to keep one story from being widely reported, and get another (albeit incorrect) one deleted.

From: "Carl Ellison" <cme acm.org>
Subject: Semantic Attacks
The semantic attacks you cite sound like they have a huge amount in common with identity theft -- and stem from the same cause -- people interpreting what they see based on invalid assumptions, or more accurately, assumptions that once upon a time were always valid and even now are usually valid.

From: Fred Mobach <fred mobach.nl>
Subject: Semantic attacks
Bruce Schneier wrote:
> It's not only posting false information; changing old
> information can also have serious consequences. I don't > know of any instance of someone breaking into a newspaper's
> article database and rewriting history, but I don't know of > any newspaper that checks, either.
You might take a look at:
<http://www.attrition.org/mirror/attrition/2000/09/...>
There is the mirrored page of the Orange County Register which has been cracked. The joke was :
"William Gates, 20, known online as Shadow Knight and Dark Lord, and known offline as the president of Microsoft breached security systems protecting NASA computers at the Jet Propulsion Lab in Pasadena and Stanford University in Palo Alto, according to court documents."

From: Bruce McNair <bmcnair research.att.com>
Subject: Semantic Attacks
Your comments on Semantic Attacks were particularly interesting and reminded me of an event that occurred in Bell Labs about 10 years ago.
In Bell Labs in the late '80s and early '90's, we had cross organizational committees on all kinds of things. I happened to be a member of the Committee on Computer Security (CCS). Fred Grampp was the representative from Research and always had an interesting way of looking at and demonstrating a point. Fred also apparently was involved in an ongoing series of practical jokes with Russ Archer, who was head of the Murray Hill computer center.
One day, as we later recognized, all the members of the CCS individually got email that appeared to have been sent from the email account of this fellow, Russ Archer.
What was interesting was that the content of the email was totally bizarre; sentences were coherent, paragraphs sounded like they were somehow consistent, but the thread of the email sounded liked the ramblings of a deranged lunatic. (It turned out to be a message composed of all the sentences from the AP Newswire that had the word sensitive or sensitivity in them. Each separate story started a new paragraph.)
As a group of people who had a more than passing involvement in security, one would expect that, given the bizarre email from an individual we had no reason to get email from we would ask "Who has forged Russ Archer's email address?" Instead, every individual first asked "Who is this guy Russ Archer and what is wrong with him?"
Obviously when people started calling Russ and asking him why he had sent the email, it didn't take long for him to figure out that this was Fred's retaliation for some previous thing Russ had done, perhaps filling Fred's office with packing peanuts, applying a stolen Denver boot to Fred's car in the parking lot, or some similar thing.
The fact in this case that EVERY relatively computer security savvy person FIRST assumed the email signature was valid, even when confronted with nonsensical content from a stranger says a lot about the feasibility of any semantic attack, when the content is plausible and the targets are not sophisticated enough to realize how easy the attack is.

From: Jim Reid <jim rfc1035.com>
Subject: Semantic attacks
An example of this came before the English courts last week. A disgruntled (ex?) employee of an English newspaper tried to sabotage production. He asked a rival paper for GBP600,000 to change the paper's content and foul up production by crashing servers and network links to printing plants just before print deadlines. He proved himself to the other newspaper by changing the date on one page from October to Octobre. At this point the rival paper brought in the police and the would-be extortionist was arrested.
Actually, attacking the news archives on Web sites like the BBC's could be a big problem. Given the security of most Web sites, this is worrying. An on-line copy of an old article could be rewritten and, if done carefully, would be very hard to detect.
<http://news6.thdo.bbc.co.uk/hi/english/uk/...>

From: "Ethan Samuel Simon" <ethan danneskjold.com>
Subject: Semantic attacks
I worked for a hotel company as an inbound telephone representative. Some bonus compensation and performance evaluation was based upon a fraction which had as its numerator the number of reservations a representative made and as its denominator the number of inbound telephone calls the representative received. Usually a number which translated to 1/3 was considered acceptable, a number in excess of 1/3 was considered good. Of course, if a representative was to make more than one reservation per telephone call received, that would count in the numerator, theoretically making a number greater than 1 possible. The other bit of information relevant to the story is that during the first two weeks of work, representatives were trained in a classroom environment, specifically on how to enter information into the reservation computers, and how to handle telephone calls. Mock telephone calls and mock reservations were made possible via role playing and a code for a test hotel, respect
ively. Reservations could be made in one of three test hotels, each with varying amenities and conditions which would more easily simulate the "real world" environment. Those reservations were actually processed as reservations in dummy files on dummy computers.
Thus, one who understood the way that the "fraction" worked and the way that the number of reservations was counted, could deduce that by simply making random reservations for fictional people on the test computers would increase one's fraction, and thus one's bonus compensation and performance evaluation.
The same type of attacks were possible in my eighth grade typing class on an Apple IIe which counted the number of lines you had typed. If you just hit enter a bunch of times, it would advance a blank line and the number of lines you had typed. If you were able to quickly type and fill up the remainder of the screen with the lines you were supposed to type, it looked like you typed many, many more lines than you had.

From: An Anonymous Federal Director of a Major Network Security Manufacturer
Subject: NSA and Assurance
My blood boiled when I heard Mr. Snow speak at Black Hat; I couldn't even stay in the room. My comments:
1. NSA, like most of the federal government, goes with the lowest bidder when they acquire products. They buy cheap network security products and then have the gall to rail at the manufacturers for shoddy products. You get what you pay for and quality is not cheap.
2. As a manufacturer of quality network security products, my experience has been that it is not typically the product's fault when network security is breached. Poorly configured products, lack of training, lack of awareness, personnel shortages, and lack of management attention are almost always the culprits. Tank manufacturers warranty their tanks against manufacturer-induced mechanical failure but they do not provide any warranty if a tank crew silhouette themselves on top of a ridgeline and are destroyed by an enemy tank.
3. Why would a manufacturer provide assurances in this kind of an environment? What possible value would they be? Who will pay for them? (The NSA?) The manufacturer's lawyers would write these assurances so that only an identifiable product failure would be covered by the liability clause -- statistically improbable, but regardless each incident would require an army of lawyers and tremendous technical resources to resolve. Who would police the assurance clauses? For example, if a server OS is found to have an exploit and a patch exists to solve it but is not applied by the systems administrator, is it a manufacturing flaw? Actually, the courts would police these issues and who knows how they would rule? Mr. Snow's ideas would simply enrich lawyers and raise the cost of network security products. Wouldn't those wasted resources be better applied toward affordable quality network security (product, personnel, training, services, etc...) in the first place? Keep in mind that the federal agencies have permanent lawyers on their staffs -- reducing litigation does not save them any funding. On the contrary, federal lawyers often need to find some way to justify their existence.
4. Your comment about the lack of TEMPEST and EMP protected products at Radio Shack is very perceptive. NSA (like the rest of the government) ostensibly want to purchase COTS [Commercial Off-the-Shelf] products but they still want government specification. Clearly the federal government wants COTS pricing for government specification products.
5. The federal government needs to stop buying products and start buying solutions. Products are an integral part of those solutions but products are not silver bullets.
6. The marketplace has spoken. For example, Microsoft has won the OS battle, Cisco and Checkpoint are winning the firewall battle. Clearly the marketplace is not rewarding products for their security content. It is rewarding ease of installation/management, marketshare, and marketing/sales campaigns. The formula for success is: 1) building a product quickly so that marketshare can be grabbed first (quality control becomes an obstacle in this case), 2) building a product that is easy to install/manage but security is an after-thought at best, and 3) investing in a large sales/marketing force (often at the expense of development and engineering). If this is what Mr. Snow was trying to say, I agree with him. However he is a willing and integral part of the marketplace rewarding the manufacturers following the formula for success above. What has Mr. Snow done other than provide pious announcements at BlackHat? He provided no examples of where NSA has accomplished anything to
correct the perceived imbalance in the marketplace. Mr. Snow's words would be more meaningful if NSA showed the courage to demonstrate the action it is asking the marketplace to undertake.
7. In the '70's and '80's, the federal government dominated the high-technology industry (for example, DARPANET became the international standard for data communications). But the federal government is now in the position of being a small, niche market for the high-technology industry (FORTEZZA and Defense Messaging System are excellent examples of the federal government setting a standard and the world ignoring them). Look at the stock prices for Lockheed Martin, Raytheon and Northrop Grumman. Wall Street regularly beats up on government contractors -- "every dollar spent chasing a government customer is one not spent on the really important marketspace like e-commerce and B2B intranets" (Wall Street analyst). Mr. Snow needs to learn to live with the world as it is, not how he wants it to be.
Bottom line: If Mr. Snow wants quality COTS products, he needs to pay for them. If he wants assurance, he needs to pay for it. It appears that his call for quality and assurance is no more than flailing about trying to find a scapegoat for the military's lack of network security (Rep. Horn's report card on the federal government is instructive in this regard). Mr. Snow's actions speak far louder than his words.

From: Joe Marshall <jrm content-integrity.com>
Subject: Assurance
Bruce Schneier <schneier@counterpane.com> writes:
> In the real world, there's little assurance.
True, but there is 'blame' and 'CYA' which figures very strongly in this situation.
> When you buy a lock for your front door, you're not
> given any assurances about how well it functions or > how secure your house will be as a result.
Exactly. In fact, should your lock perform 'too well', you could be in violation of the law: it is illegal to create a location that is resistant to police entry. No doubt fire codes play a role as well.
The 'assurance' you get is that if a burglar *does* break into your home, and it can be shown that the lock was either defective, or the lock manufacturer was negligent, that you can perhaps recover an award from the lock manufacturer. (I put the word 'assurance' in quotes because in the real world, it would be unlikely that you would actually *receive* any such award, even if it were awarded.)
Additionally, your home owners insurance may 'require' you to buy a lock (note they do not specify how resistant that lock must be, nor do they verify that you use it correctly, only that you purchase and install one). If you fail to do so, you will not get a settlement should your home be burglarized.
A perfectly rational act in this scenario is to purchase the least expensive, commonly used lock. In buying the lock, you have bought 'someone to blame' should your house be broken into because of a failure of that lock, and you have fulfilled your obligations under your insurance.
Note that actual security plays no part in this decision.
> Business security is all about risk management. Visa
> knows that there is no assurance against credit card > fraud, and designs their fee structures so that the
> risks are manageable.
But what is the biggest risk? The occasional credit card fraud, or the class action lawsuit? The latter can bankrupt a company, the former is simply a cost that can be passed on to the customer. Visa is only motivated to provide 'adequate' or `reasonable' assurances against fraud (and only to those that vociferously complain about it!), not 'protection' against it.
I think that as long as this attitude of displacing the blame and CYA persists, there is little motivation to find any actual 'solution' to the risks that 'false security' creates.

From: Bill Napier <billnapier yahoo.com>
Subject: Re: NSA on AES
To quote your article:
>The NSA has not stated that it will use AES to
>protect classified information.
To quote the NIST faq of AES: "The Advanced Encryption Standard (AES) will be a new Federal Information Processing Standard (FIPS) Publication that will specify a cryptographic algorithm for use by U.S. Government organizations to protect sensitive (unclassified) information.
<http://www.nist.gov/public_affairs/releases/...>
In other words, the AES standard (once approved) is approved for use to protect SENSITIVE, UNCLASSIFIED information. So it's not just the NSA that won't be using it to protect classified information, it should be all of the government (we can only assume that the NSA has its own Encryptions Standard to use with Classified information).

From: Mark Seiden <mis seiden.com>
Subject: In Defense of HSBC
I agree with your conclusion, but don't agree that the wording of the HSBC agreement leads to it.
It seems to me there are several issues here.
First, HSBC is trying to prevent banking customers from doing something risky or dumb, but they get to take the loss. HSBC are saying explicitly that doing your banking in a cybercafe or on a public access machine at a computer security conference (i.e. on an untrustworthy platform) is so risky that it's your risk when you do such a thing. (I'd be too paranoid to do this sort of thing in any case. Based on knowledge and belief, I wouldn't do debit card transactions using the ATM networks in some countries!)
Second, without supplying trusted hardware for authentication, HSBC has to hope that the platform will not being tampered with, either physically or logically.
Of course, we can fairly criticize HSBC if they are doing something dumb themselves, such as storing authentication information in the clear on a client, or leaking client authentication information in their implementation (say in weakly protected cookies). We can also criticize HSBC for trying to place the need to establish assurance against "copying of access" on their banking customer, who is unequipped to gain such assurance except in superficial ways.
Whether HSBC are using "industry common practices" (typically low cost solutions) or "industry best practices" (more expensive, low usability, rocket science), they are trying to put the liability for client-end security on the place that is most able to control it, and that seems correct to me.
The presence of third parties, such as intermediaries, bill payment aggregators, sites that cache your credentials "for your convenience", as well as third-party provided client software (such as wallets and Microsoft Passport) complicate the picture considerably. I'm not sure how to completely answer the question "To what extent is the control in the hands of the banking customer, and to what extent is it in the hands of Microsoft or other third parties?"
Of course we can argue about whether a particular technology is adequate protection for some specific assets in a transaction, and who should assume the risk in specific cases, so let's get specific:
In the usual case of industry "common practices", suppose they use basic authentication (passwords) over SSL, as many financial sites do. Here are some attacks that come to mind.
High tech attacks:
- If a bad guy somehow wrote a fraudulent cert in the root CA file of the browser, client trust could be placed in the bad guy's phony version of the HSBC banking web site, if the client could be directed there. An administrator with control over a local forwarding DNS and administrative rights over the client workstation in question could do both of those, and harvest HSBC application logins and passwords.
- Cookie replay attacks using unexpired cookies issued by HSBC to a client as session credentials. (There have been several methods for getting cookies, including bugs in browsers.)
Lower tech attack:
- Recently discovered client browsers bugs/misfeatures have allowed discovery of cookies (arbitrary client side files and program execution, for that matter). Convincing browsers that remember logins and passwords
to disclose them is another possibility.
- A bad guy could install a keystroke monitor (hardware or software) on the client platform to capture logins and passwords, and report them to a remote site.
Even lower tech attack:
- video recording or shoulder surfing of logins and passwords.
Often a banking user has no practical alternative other than to do occasional banking transactions from their place of business, and to trust the administrators and the physical security where they work. Why should any of these attacks be the bank's liability problem?
One argument I could make is that "passwords are obsolete" and HSBC should be supplying a hardware token for authentication, but they would still likely be using the token only for *initial* authentication, and issuing a credential stored in a client-side cookie.
Given an untrustworthy platform, they are essentially forced to disclaim client-side liability.
Here's a rare case of "best practices":
Suppose a bank goes whole hog, and supplies a crypto smartcard and reader to each user, and a signed java applet which requests the password (to unlock the card) and sends banking transactions to the smartcard for cryptographic signing, la de doo da.
They still have several client-side exposures (some of which are admittedly pretty high-tech):
- a bad guy can install client-side software which watches for the password entry event and piggybacks fraudulent requests around the same time as authentic ones
- a bad guy can install client-side software that alters the requests so what is actually signed is not what the user enters, sees, and believes is what they signed.
- the smartcard drivers can be altered to log or cache passwords for later use. (Some smartcard drivers even have this as a "debugging feature".)
(It's true that all of these attacks require the presence of the smartcard to abuse its ability to sign a fraudulent transaction.)
So maybe the bank really needs to raise the bar even further, to use a smartcard reader with a remote pin pad, that can eject the card (perhaps even after a single signing operation), and to have the user reinsert the card and reenter the pin for each signing operation (there goes user friendliness), and to try to detect tampering with any piece of software they depend on. And they need to provide a display directly on the reader so the user can see what is being signed, preferably in terms the user actually understands (not XML)! (Possibly they need to provide genetic manipulation for the users, to make them smarter?)
Or perhaps they need to supply something like a java card with enough of an environment needed to establish trustworthy communication with a trusted server over an entirely untrusted channel.
That bar is getting so high that they may not be able to economically jump over it, for consumer banking.
To summarize my opinions:
In general, it seems fair to me for HSBC to disclaim liability for client-side or third party problems which aren't under their control, but their customer is typically even less equipped to deal with those problems.
Given their dependence on a fundamentally untrustworthy platform, it would be better if they supplied their customers with client-side technologies adequate for safe banking transactions (at least at home and in the workplace), and HSBC assumed the risk for transactions made using those technologies.
There should be recourse for financial losses resulting from exploitation of bugs or design defects in software, particularly if such software is unavoidably bundled with an operating system.

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on computer security and cryptography.

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

later issue
earlier issue
back to Crypto-Gram index

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..