IP: Crypto-Gram -- Why Digital Signatures Are Not Signatures

[Dave Farber <farber@cis.upenn.edu>]

>Date: Sun, 10 Dec 2000 11:16:45 -0500
>From: "L. Leon Campbell" <campbell@UDel.Edu>
>
>Dave:
>
>You may have already seen this since it almost a month old but I found
>it most interesting.
>
>Leon.
>____________________________________________________
>Why Digital Signatures Are Not Signatures
>http://www.counterpane.com/crypto-gram-0011.html#1
>--
>_____________________________________________________________________
>L. Leon Campbell
>AAUP Contract Maintenance Officer
>The Hugh M. Morris Research Professor of Molecular Biosciences
>University of Delaware
>400 Morris Library
>Newark,  DE 19717-5267
>Voice: (302) 831-6767         EMail Internet: campbell@udel.edu
>
>"Information Without Access Is Not Information"
>_____________________________________________________________________
>
>
>
>Crypto-Gram
>
>
>
>November 15, 2000
>
>by Bruce Schneier
>Founder and CTO
>Counterpane Internet Security, Inc.
>schneier@counterpane.com
><http://www.counterpane.com>
>
>A free monthly newsletter providing summaries, analyses, insights, and 
>commentaries on computer security and cryptography.
>
>Back issues are available at 
><http://www.counterpane.com>. 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-KeyCryptography> 
>
>
>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.htmls> 
>
>
>----------
>
>
>
>Counterpane Internet Security News
>
>
>
>The Smithsonian is sponsoring a lecture and book signing at the 
>International Monetary Fund Center:
>720 19th Street, N.W., Washington, DC, on 29 November at 6:30 - 8:00 p.m. 
>Everyone is invited.
>
>Bruce Schneier is chosen as one of the 20 executives to watch by CRN 
>magazine:
><http://www.crn.com/Components/Search/Article.asp?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.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:
><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_latestnews.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: Ben_Tilly@trepp.com
>Subject: Semantic Attacks
>
>In your article on semantic attacks you mention rewriting history. I have 
>seen it in action.
>
>In January of 1999 reports appeared that Windows NT had failed FIPS 140-1 
>and this was a black eye since it meant that the US government was not 
>supposed to use it. A few months later, without fanfare, most of those 
>reports had disappeared.
>
>Now there is reason to believe that the initial reports were mistaken, but 
>the fact that they were simply deleted bothers me quite a bit.
>
>Particularly since Microsoft has apparently brought pressure to bear to 
>keep people from reporting over the last few years how Microsoft marketed 
>NT 3.51 and then NT 4.0 as having a C2 level of security when it had no 
>such certification. Indeed the team that managed to certify NT 3.5 with 
>service pack 3 flat out told Microsoft that they would not meet the 
>standard with 4.0. (They thought that NT 3.51 would pass, but contrary to 
>popular belief it was never tested.) And indeed after several years and 6 
>service packs, the closest that Microsoft came was a UK rating which they 
>claim is equivalent to the US C2 Orange Book.
>
>Change that from a bit. It *really* bothers me that Microsoft could manage 
>to keep one story from being widely reported, and get another (albeit 
>incorrect) one deleted.
>
>From: "Carl Ellison" <cme@acm.org>
>Subject: Semantic Attacks
>
>The semantic attacks you cite sound like they have a huge amount in common 
>with identity theft -- and stem from the same cause -- people interpreting 
>what they see based on invalid assumptions, or more accurately, 
>assumptions that once upon a time were always valid and even now are 
>usually valid.
>
>From: Fred Mobach <fred@mobach.nl>
>Subject: Semantic attacks
>
>Bruce Schneier wrote:
>
> > It's not only posting false information; changing old
> > information can also have serious consequences. I don't > know of any 
> instance of someone breaking into a newspaper's
> > article database and rewriting history, but I don't know of > any 
> newspaper that checks, either.
>You might take a look at:
><http://www.attrition.org/mirror/attrition/2000/09/29/www.ocregister.com/community/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.
>
><http://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.
><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 <mis@seiden.com>
>Subject: In Defense of HSBC
>
>I agree with your conclusion, but don't agree that the wording of the HSBC 
>agreement leads to it.
>
>It seems to me there are several issues here.
>
>First, HSBC is trying to prevent banking customers from doing something 
>risky or dumb, but they get to take the loss. HSBC are saying explicitly 
>that doing your banking in a cybercafe or on a public access machine at a 
>computer security conference (i.e. on an untrustworthy platform) is so 
>risky that it's your risk when you do such a thing. (I'd be too paranoid 
>to do this sort of thing in any case. Based on knowledge and belief, I 
>wouldn't do debit card transactions using the ATM networks in some countries!)
>
>Second, without supplying trusted hardware for authentication, HSBC has to 
>hope that the platform will not being tampered with, either physically or 
>logically.
>
>Of course, we can fairly criticize HSBC if they are doing something dumb 
>themselves, such as storing authentication information in the clear on a 
>client, or leaking client authentication information in their 
>implementation (say in weakly protected cookies). We can also criticize 
>HSBC for trying to place the need to establish assurance against "copying 
>of access" on their banking customer, who is unequipped to gain such 
>assurance except in superficial ways.
>
>Whether HSBC are using "industry common practices" (typically low cost 
>solutions) or "industry best practices" (more expensive, low usability, 
>rocket science), they are trying to put the liability for client-end 
>security on the place that is most able to control it, and that seems 
>correct to me.
>
>The presence of third parties, such as intermediaries, bill payment 
>aggregators, sites that cache your credentials "for your convenience", as 
>well as third-party provided client software (such as wallets and 
>Microsoft Passport) complicate the picture considerably. I'm not sure how 
>to completely answer the question "To what extent is the control in the 
>hands of the banking customer, and to what extent is it in the hands of 
>Microsoft or other third parties?"
>
>Of course we can argue about whether a particular technology is adequate 
>protection for some specific assets in a transaction, and who should 
>assume the risk in specific cases, so let's get specific:
>
>In the usual case of industry "common practices", suppose they use basic 
>authentication (passwords) over SSL, as many financial sites do. Here are 
>some attacks that come to mind.
>
>High tech attacks:
>
>- If a bad guy somehow wrote a fraudulent cert in the root CA file of the 
>browser, client trust could be placed in the bad guy's phony version of 
>the HSBC banking web site, if the client could be directed there. An 
>administrator with control over a local forwarding DNS and administrative 
>rights over the client workstation in question could do both of those, and 
>harvest HSBC application logins and passwords.
>- Cookie replay attacks using unexpired cookies issued by HSBC to a client 
>as session credentials. (There have been several methods for getting 
>cookies, including bugs in browsers.)
>
>Lower tech attack:
>
>- Recently discovered client browsers bugs/misfeatures have allowed 
>discovery of cookies (arbitrary client side files and program execution, 
>for that matter). Convincing browsers that remember logins and passwords
>to disclose them is another possibility.
>
>- A bad guy could install a keystroke monitor (hardware or software) on 
>the client platform to capture logins and passwords, and report them to a 
>remote site.
>
>Even lower tech attack:
>
>- video recording or shoulder surfing of logins and passwords.
>
>Often a banking user has no practical alternative other than to do 
>occasional banking transactions from their place of business, and to trust 
>the administrators and the physical security where they work. Why should 
>any of these attacks be the bank's liability problem?
>
>One argument I could make is that "passwords are obsolete" and HSBC should 
>be supplying a hardware token for authentication, but they would still 
>likely be using the token only for *initial* authentication, and issuing a 
>credential stored in a client-side cookie.
>
>Given an untrustworthy platform, they are essentially forced to disclaim 
>client-side liability.
>
>Here's a rare case of "best practices":
>
>Suppose a bank goes whole hog, and supplies a crypto smartcard and reader 
>to each user, and a signed java applet which requests the password (to 
>unlock the card) and sends banking transactions to the smartcard for 
>cryptographic signing, la de doo da.
>
>They still have several client-side exposures (some of which are 
>admittedly pretty high-tech):
>
>- a bad guy can install client-side software which watches for the 
>password entry event and piggybacks fraudulent requests around the same 
>time as authentic ones
>
>- a bad guy can install client-side software that alters the requests so 
>what is actually signed is not what the user enters, sees, and believes is 
>what they signed.
>
>- the smartcard drivers can be altered to log or cache passwords for later 
>use. (Some smartcard drivers even have this as a "debugging feature".)
>
>(It's true that all of these attacks require the presence of the smartcard 
>to abuse its ability to sign a fraudulent transaction.)
>
>So maybe the bank really needs to raise the bar even further, to use a 
>smartcard reader with a remote pin pad, that can eject the card (perhaps 
>even after a single signing operation), and to have the user reinsert the 
>card and reenter the pin for each signing operation (there goes user 
>friendliness), and to try to detect tampering with any piece of software 
>they depend on. And they need to provide a display directly on the reader 
>so the user can see what is being signed, preferably in terms the user 
>actually understands (not XML)! (Possibly they need to provide genetic 
>manipulation for the users, to make them smarter?)
>
>Or perhaps they need to supply something like a java card with enough of 
>an environment needed to establish trustworthy communication with a 
>trusted server over an entirely untrusted channel.
>That bar is getting so high that they may not be able to economically jump 
>over it, for consumer banking.
>
>To summarize my opinions:
>
>In general, it seems fair to me for HSBC to disclaim liability for 
>client-side or third party problems which aren't under their control, but 
>their customer is typically even less equipped to deal with those problems.
>
>Given their dependence on a fundamentally untrustworthy platform, it would 
>be better if they supplied their customers with client-side technologies 
>adequate for safe banking transactions (at least at home and in the 
>workplace), and HSBC assumed the risk for transactions made using those 
>technologies.
>
>There should be recourse for financial losses resulting from exploitation 
>of bugs or design defects in software, particularly if such software is 
>unavoidably bundled with an operating system.
>
>
>----------
>CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, 
>insights, and commentaries on computer security and cryptography.
>
>To subscribe, visit 
><http://www.counterpane.com/crypto-gram.html> 
>or send a blank message to >or send a blank message to crypto-gram-subscribe@chaparraltree.com. 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/>
>
>
><crypto-gram-0010.htm>previous issue
><crypto-gram.htm>back to Crypto-Gram index
>
>----------
>Copyright Counterpane Internet Security, Inc., 2000
>
><.htm>Home page - <oursol.htm>Monitoring Services - 
><literature.htm>Literature - <jobs.htm>Jobs - <about.htm>About Us - 
><team.htm>Our Team - <partners.htm>Partners - <customers.htm>Customers - 
><investors.htm>Investors - <jobs.htm>Jobs - <ourname.htm>Our Name - 
><contact.htm>Contact Info - <cisnews.htm>News - <pressrel.htm>Press 
>Releases - <conf.htm>Conferences - <incidents.htm>Security Incidents - 
><labs.htm>Counterpane Labs - <crypto-gram.htm>Crypto-Gram Newsletter - 
><twofish.htm>Twofish - <orderac2.htm>Order Books
>
>
>
>



For archives see: http://www.interesting-people.org/