From: Bruce Schneier [mailto:[log in to unmask]]
Sent: Wednesday, November 15, 2000 11:59 PM
To: [log in to unmask]
Subject: CRYPTO-GRAM, November 15, 2000
CRYPTO-GRAM
November 15, 2000
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
[log in to unmask]
<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
Crypto-Gram Reprints
News
Counterpane Internet Security News
_Secrets and Lies_ News
SDMI Hacking Challenge
Microsoft Hack (the Company, not a Product)
Comments from Readers
** *** ***** ******* *********** *************
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/0,4164,2635346,00.html>
(multipage, don't miss the others)
<http://www4.zdnet.com:80/intweek/stories/news/0,4164,2634368,00.html>
<http://www.infoworld.com:80/articles/hn/xml/00/10/02/001002hnesign.xml>
<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.counterpane.com/crypto-gram-9911.html#WhyComputersareInsecure>
Elliptic-Curve Public-Key Cryptography
<http://www.counterpane.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCry
ptography>
The Future of Fraud: Three reasons why electronic commerce is different
<http://www.counterpane.com/crypto-gram-9811.html#commerce>
Why copy protection does not work:
<http://www.counterpane.com/crypto-gram-9811.html#copy>
** *** ***** ******* *********** *************
News
A cyber Underwriters Laboratory? Don't hold your breath.
<http://www.zdnet.com/enterprise/stories/main/0,10228,2640597,00.html>
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/A62985-2000Oct20.html>
The stolen Enigma machine has been returned:
<http://news.bbc.co.uk/hi/english/uk/newsid_977000/977127.stm>
People are worried about security in cyberspace:
<http://dailynews.yahoo.com/h/nm/20001016/ts/tech_security_dc_1.html>
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.counterpane.com/pki-risks.html>
Here is a rebuttal:
<http://members.nbci.com/aram_perez/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/nsa_external_team_report.pdf>
<http://www.nsa.gov/releases/nsa_new_enterprise_team_recommendations.pdf>
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/0,4712,2642537,00.html>
Interesting article on the threats to business information:
<http://www.cnn.com/2000/TECH/computing/10/18/business.spy.threat.idg/index.
html>
The European Cybercrime Treaty threatens human rights.
<http://www.zdnet.co.uk/news/2000/41/ns-18546.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/jw-1027-aes.html>
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/feature_fingerprints.html>
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/pritchard_pfv.htm>
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/tracking001021.html>
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/EncryptionRuleOct2K.pdf>
News reports:
<http://www.cnn.com/2000/TECH/computing/10/19/encryption.exports.ap/>
<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/0,4586,2647934,00.html>
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/0,3604,381054,00.html>
Another commentary on semantic attacks:
<http://www.securityfocus.com/commentary/104>
Incident-response database:
<https://cassandra.cerias.purdue.edu/main/index.html>
** *** ***** ******* *********** *************
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?ArticleID=21187>
<http://www.crn.com/Components/Search/Article.asp?ArticleID=21207>
Managed Security Monitoring:
<http://www.techrepublic.com/article.jhtml?id=r00620001011cav01.htm&page=1>
Decent article on Schneier's BlackHat talk:
<http://www.techtv.com/cybercrime/hackingandsecurity/story/0,9955,2058,00.ht
ml>
** *** ***** ******* *********** *************
_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.counterpane.com/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/20001030/t000103702.html
>
<http://www.byte.com/column/BYT20001018S0001>
<http://www.matrix.net/publications/mn/mn1010_secrets_and_lies.html>
All reviews:
<http://www.counterpane.com/sandlrev.html>
Buy the book here:
<http://www.amazon.com/exec/obidos/ASIN/0471253111/counterpane/>
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/index.html>
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>
<http://www.wired.com/news/technology/0,1282,40054,00.html>
<http://www.salon.com/tech/log/2000/11/08/sdmi_tests/index.html>
<http://www.washingtonpost.com/wp-dyn/articles/A49514-2000Nov8.html>
SDMI's denial:
<http://www.theregister.co.uk/content/1/14608.html>
<http://www.salon.com/tech/log/2000/11/08/sdmi_tests/index.html>
A nice analysis:
<http://www.eet.com/story/OEG20001031S0037>
Article about DMCA provisions becoming active:
<http://www.securityfocus.com/templates/article.html?id=107>
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.counterpane.com/crypto-gram-9812.html#contests>
I also wrote about the futility of digital content protection:
<http://www.counterpane.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/27+micro102700_latestne
ws.html+20001027>
Microsoft changes its story:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2646430,00.html>
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2646049,00.html>
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/0,5859,2646523,00.html>
Commentary on the attackers' motivations:
<http://www.securityfocus.com/commentary/112>
Legal ramifications of seeing the stolen source code:
<http://www2.linuxjournal.com/cgi-bin/frames.pl/articles/currents/0024.html>
Lessons of the attack:
<http://www.zdnet.com/eweek/stories/general/0,11011,2646167,00.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2646315,00.html>
<http://securityportal.com/articles/mshacked20001029.html>
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2646203,00.html>
<http://dailynews.yahoo.com/h/nm/20001029/tc/microsoft_hackers_dc_12.html>
Other attacks against Microsoft:
<http://www.infoworld.com/articles/hn/xml/00/11/03/001103hnhacker.xml>
<http://thestandard.com/article/display/0,1151,20065,00.html>
** *** ***** ******* *********** *************
Comments from Readers
From: [log in to unmask]
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" <[log in to unmask]>
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 <[log in to unmask]>
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/29/www.ocregister.com/com
munity/crimecourts/hack00922cci.html>
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 <[log in to unmask]>
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 <[log in to unmask]>
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/newsid_971000/971231.stm>
From: "Ethan Samuel Simon" <[log in to unmask]>
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 <[log in to unmask]>
Subject: Assurance
Bruce Schneier <[log in to unmask]> 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 <[log in to unmask]>
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/aesq&a.htm>
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 <[log in to unmask]>
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.counterpane.com/crypto-gram.html> or send a
blank message to [log in to unmask] To unsubscribe,
visit <http://www.counterpane.com/unsubform.html>. Back issues are
available on <http://www.counterpane.com>.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will
find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as
it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of
Counterpane Internet Security Inc., the author of "Applied Cryptography,"
and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served
on the board of the International Association for Cryptologic Research,
EPIC, and VTW. He is a frequent writer and lecturer on computer security
and cryptography.
Counterpane Internet Security, Inc. is a venture-funded company bringing
innovative managed security solutions to the enterprise.
<http://www.counterpane.com/>
Copyright (c) 2000 by Counterpane Internet Security, Inc.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
