CRYPTO-GRAM

               November 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.com
          <https://www.counterpane.com>


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

Back issues are available at <https://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:
<https://www4.zdnet.com:80/intweek/stories/news/0,4164,2635346,00.html> 
(multipage, don't miss the others)
<https://www4.zdnet.com:80/intweek/stories/news/0,4164,2634368,00.html>
<https://www.infoworld.com:80/articles/hn/xml/00/10/02/001002hnesign.xml>
<https://www.pioneerplanet.com/tech/tcv_docs/028992.htm>

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


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

              Crypto-Gram Reprints



Programming Satan's Computer:  Why Computers are Insecure
<https://www.counterpane.com/crypto-gram-9911.html#WhyComputersareInsecure>

Elliptic-Curve Public-Key Cryptography
<https://www.counterpane.com/crypto-gram-9911.html#EllipticCurvePublic-KeyCry 
ptography>

The Future of Fraud:  Three reasons why electronic commerce is different
<https://www.counterpane.com/crypto-gram-9811.html#commerce>

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


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

                      News



A cyber Underwriters Laboratory?  Don't hold your breath.
<https://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.)
<https://cgi.zdnet.com/slink?59369:8469234>
<https://www.it.fairfax.com.au/breaking/20001020/A62985-2000Oct20.html>

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

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

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

About a year ago Carl Ellison and I wrote "10 Risks of PKI":
<https://www.counterpane.com/pki-risks.html>
Here is a rebuttal:
<https://members.nbci.com/aram_perez/ResponseTenRisks.html>

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

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

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

Two useful publications from the Electronic Privacy Information Center.
The 2000 Privacy Law Sourcebook:
<https://www.epic.org/pls>
The 2000 edition of the Privacy and Human Rights survey:
<https://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.
<https://www.zdnet.com/sp/stories/column/0,4712,2642537,00.html>

Interesting article on the threats to business information:
<https://www.cnn.com/2000/TECH/computing/10/18/business.spy.threat.idg/index. 
html>

The European Cybercrime Treaty threatens human rights.
<https://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.
<https://www.nwfusion.com/news/2000/1016apps.html>
A good summary article on the AES process:
<https://www.javaworld.com/javaworld/jw-10-2000/jw-1027-aes.html>
An article on a talk I gave on AES:
<https://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:
<https://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.
<https://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.
<https://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.
<https://cryptome.org/carnivore-demo.htm>

Publius: anonymous posting of files on the Internet.  How it works:
<https://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:
<https://www.bxa.doc.gov/Encryption/pdfs/EncryptionRuleOct2K.pdf>
News reports:
<https://www.cnn.com/2000/TECH/computing/10/19/encryption.exports.ap/>
<https://www.usatoday.com/life/cyber/tech/cti691.htm>

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

Mideast cyberwar: Israeli and Palestinian hackers are attacking each 
other's networks:
<https://www.zdnet.com/zdnn/stories/news/0,4586,2647934,00.html>
And this cyberwar is spreading to the U.S.
<https://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.
<https://www.guardian.co.uk/uk_news/story/0,3604,381054,00.html>

Another commentary on semantic attacks:
<https://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:
<https://www.crn.com/Components/Search/Article.asp?ArticleID=21187>
<https://www.crn.com/Components/Search/Article.asp?ArticleID=21207>

Managed Security Monitoring:
<https://www.techrepublic.com/article.jhtml?id=r00620001011cav01.htm&page=1>

Decent article on Schneier's BlackHat talk:
<https://www.techtv.com/cybercrime/hackingandsecurity/story/0,9955,2058,00.html>


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

           _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:
<https://www.counterpane.com/sandl.html>

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

More book reviews:
<https://www.latimes.com/business/columns/innovation/20001030/t000103702.html>
<https://www.byte.com/column/BYT20001018S0001>
<https://www.matrix.net/publications/mn/mn1010_secrets_and_lies.html>
All reviews:
<https://www.counterpane.com/sandlrev.html>

Buy the book here:
<https://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:
<https://www.hacksdmi.org/>
<https://www.salon.com/tech/log/2000/09/14/hack_sdmi/index.html>

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

The break:
<https://biz.yahoo.com/prnews/001108/dc_sdmi_ex.html>
<https://www.zdnet.co.uk/news/2000/44/ns-18963.html>
<https://www.wired.com/news/technology/0,1282,40054,00.html>
<https://www.salon.com/tech/log/2000/11/08/sdmi_tests/index.html>
<https://www.washingtonpost.com/wp-dyn/articles/A49514-2000Nov8.html>

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

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

Article about DMCA provisions becoming active:
<https://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:
<https://cryptome.org/dmca102700.txt>

I wrote about the futility of hacking contests in Crypto-Gram two years 
ago, and in Secrets and Lies.
<https://www.counterpane.com/crypto-gram-9812.html#contests>

I also wrote about the futility of digital content protection:
<https://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:
<https://www.courierpress.com/cgi-bin/view.cgi?200010/27+micro102700_latestne 
ws.html+20001027>

Microsoft changes its story:
<https://www.zdnet.com/zdnn/stories/news/0,4586,2646430,00.html>
<https://www.zdnet.com/zdnn/stories/comment/0,5859,2646049,00.html>

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

Top 10 Things Bill Gates said when he heard Microsoft was hacked:
<https://www.zdnet.com/zdnn/stories/comment/0,5859,2646523,00.html>

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

Legal ramifications of seeing the stolen source code:
<https://www2.linuxjournal.com/cgi-bin/frames.pl/articles/currents/0024.html>

Lessons of the attack:
<https://www.zdnet.com/eweek/stories/general/0,11011,2646167,00.html>
<https://www.zdnet.com/zdnn/stories/news/0,4586,2646315,00.html>
<https://securityportal.com/articles/mshacked20001029.html>
<https://www.zdnet.com/zdnn/stories/comment/0,5859,2646203,00.html>
<https://dailynews.yahoo.com/h/nm/20001029/tc/microsoft_hackers_dc_12.html>

Other attacks against Microsoft:
<https://www.infoworld.com/articles/hn/xml/00/11/03/001103hnhacker.xml>
<https://thestandard.com/article/display/0,1151,20065,00.html>


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

              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:
<https://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 <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.

<https://news6.thdo.bbc.co.uk/hi/english/uk/newsid_971000/971231.stm>


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.
<https://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 <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 <https://www.counterpane.com/crypto-gram.html> or send a 
blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, 
visit <https://www.counterpane.com/unsubform.html>.  Back issues are 
available on <https://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.

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

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