Scot McPhee on 23 Oct 2000 15:49:04 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

<nettime> Semantic Attacks: The Third Wave of Network Attacks, from CRYPTO-GRAM, October 15, 2000


This issue of cryptogram covers 'Semantic Attacks', i.e. "attacks that target 
the way we, as humans, assign meaning to content", and also of interest to
nettime readers, 'Council of Europe Cybercrime Treaty' amongst the usual
braod range of topics concerning computer security. --SM.


-----Original Message-----
From: Bruce Schneier [mailto:schneier@counterpane.com]
Sent: Monday, October 16, 2000 3:21 PM
To: crypto-gram@chaparraltree.com
Subject: CRYPTO-GRAM, October 15, 2000


                  CRYPTO-GRAM

                October 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:
      Semantic Attacks: The Third Wave of Network Attacks
      Crypto-Gram Reprints
      News
      Counterpane Internet Security News
      Council of Europe Cybercrime Treaty -- Draft
      The Doghouse: HSBC
      NSA on Security
      AES Announced
      NSA on AES
      Privacy Tools Handbook
      Comments from Readers


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

   Semantic Attacks: The Third Wave of Network Attacks



On 25 August 2000, the press release distribution service Internet Wire 
received a forged e-mail that appeared to come from Emulex Corp. and said 
that the CEO had resigned and the company's earnings would be 
restated.  Internet Wire posted the press release, not bothering to verify 
either its origin or contents.  Several financial news services and Web 
sites further distributed the false information, and the stock dropped 61% 
(from $113 to $43) before the hoax was exposed.

This is a devastating network attack.  Despite its amateurish execution 
(the perpetrator, trying to make money on the stock movements, was caught 
in less than 24 hours), $2.54 billion in market capitalization disappeared, 
only to reappear hours later.  With better planning, a similar attack could 
do more damage and be more difficult to detect.  It's an illustration of 
what I see as the third wave of network attacks -- which will be much more 
serious and harder to defend against than the first two waves.

The first wave of attacks was physical: attacks against the computers, 
wires, and electronics.  These were the first kinds of attacks the Internet 
defended itself against.  Distributed protocols reduce the dependency on 
any one computer.  Redundancy removes single points of failure.  We've seen 
many cases where physical outages -- power, data, or otherwise -- have 
caused problems, but largely these are problems we know how to solve.

Over the past several decades, computer security has focused around 
syntactic attacks: attacks against the operating logic of computers and 
networks.  This second wave of attacks targets vulnerabilities in software 
products, problems with cryptographic algorithms and protocols, and 
denial-of-service vulnerabilities -- pretty much every security alert from 
the past decade.

It would be a lie to say that we know how to protect ourselves against 
these kinds of attacks, but I hope that detection and response processes 
will give us some measure of security in the coming years.  At least we 
know what the problem is.

The third wave of network attacks is semantic attacks: attacks that target 
the way we, as humans, assign meaning to content.  In our society, people 
tend to believe what they read.  How often have you needed the answer to a 
question and searched for it on the Web?  How often have you taken the time 
to corroborate the veracity of that information, by examining the 
credentials of the site, finding alternate opinions, and so on?  Even if 
you did, how often do you think writers make things up, blindly accept 
"facts" from other writers, or make mistakes in translation?  On the 
political scene we've seen many examples of false information being 
reported, getting amplified by other reporters, and eventually being 
believed as true.  Someone with malicious intent can do the same thing.

In the book _How to Play With Your Food_, Penn and Teller included a fake 
recipe for "Swedish Lemon Angels," with ingredients such as five teaspoons 
of baking soda and a cup of fresh lemon juice, designed to erupt all over 
the kitchen.  They spent considerable time explaining how you should leave 
their book open to the one fake page, or photocopy it and sneak it into 
friends' kitchens.  It's much easier to put it up on www.cookinclub.com and 
wait for search engines to index it.

People are already taking advantage of others' naivete.  Many old scams 
have been adapted to e-mail and the Web.  Unscrupulous stockbrokers use the 
Internet to fuel their "pump and dump" strategies.  On 6 September, the 
Securities and Exchange Commission charged 33 companies and individuals 
with Internet semantic attacks (they called it fraud) such as posting false 
information on message boards.

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.

Against computers, semantic attacks become even more serious.  Computer 
processes are much more rigid in the type of input they accept; generally 
this input is much less than a human making the same decision would 
get.  Falsifying input into a computer process can be much more 
devastating, simply because the computer cannot demand all the 
corroborating input that people have instinctively come to rely 
on.  Indeed, computers are often incapable of deciding what the 
"corroborating input" would be, or how to go about using it in any 
meaningful way.  Despite what you see in movies, real-world software is 
incredibly primitive when it comes to what we call "simple common 
sense."  For example, consider how incredibly stupid most Web filtering 
software is at deriving meaning from human-targeted content.

Can airplanes be delayed, or rerouted, by feeding bad information into the 
air traffic control system?  Can process control computers be fooled by 
falsifying inputs?  What happens when smart cars steer themselves on smart 
highways?  It used to be that you had to actually buy piles of books to 
fake your way onto the New York Times best-seller list; it's a lot easier 
to just change a few numbers in booksellers' databases.  What about a 
successful semantic attack against the NASDAQ or Dow Jones databases?  The 
people who lost the most in the Emulex hoax were the ones with 
preprogrammed sell orders.

None of these attacks is new; people have long been the victims of bad 
statistics, urban legends, and hoaxes.  Any communications medium can be 
used to exploit credulity and stupidity, and people have been doing that 
for eons.  Computer networks make it easier to start attacks and speed 
their dissemination, or for one anonymous individual to reach vast numbers 
of people at virtually no cost.

In the near future, I predict that semantic attacks will be more serious 
than physical or even syntactic attacks.  It's not enough to dismiss them 
with the cryptographic magic wands of "digital signatures," 
"authentication," or "integrity."  Semantic attacks directly target the 
human/computer interface, the most insecure interface on the 
Internet.  Only amateurs attack machines; professionals target people.  And 
any solutions will have to target the people problem, not the math problem.


The conceptualization of physical, syntactic, and semantic attacks is from 
an essay by Martin Libicki on the future of warfare.
<http://www.ndu.edu/ndu/inss/macnair/mcnair28/m028cont.html>

PFIR Statement on Internet hoaxes:
<http://www.pfir.org/statements/hoaxes>

Swedish Lemon Angels recipe:
<http://www.rkey.demon.co.uk/Lemon_Angels.htm>
A version of it hidden among normal recipes (I didn't do it, honest):
<http://www.cookinclub.com/cookbook/desserts/zestlem.html>
Mediocre photos of people making them (note the gunk all over the counter 
by the end):
<http://students.washington.edu/aferrel/pnt/lemangl.html>

SatireWire:  How to Spot a Fake Press Release
<http://www.satirewire.com/features/fake_press_release.shtml>

Taking over the air-traffic-control radio:
<http://abcnews.go.com/sections/us/DailyNews/FakeAirTraffic000829.html>

A version of this essay appeared on ZDnet:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2635895,00.html>
SlashDot commentary on it:
<http://slashdot.org/articles/00/10/06/055232.shtml>


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

             Crypto-Gram Reprints



Steganography: Truths and Fictions:
<http://www.counterpane.com/crypto-gram-9810.html#steganography>

Memo to the Amateur Cipher Designer:
<http://www.counterpane.com/crypto-gram-9810.html#cipherdesign>

So, You Want to be a Cryptographer:
<http://www.counterpane.com/crypto-gram-9910.html#SoYouWanttobeaCryptographe
r>

Key Length and Security:
<http://www.counterpane.com/crypto-gram-9910.html#KeyLengthandSecurity>


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

                     News



Three phases of computer security.  Very interesting essay by Marcus Ranum:
<http://pubweb.nfr.net/~mjr/usenix/ranum_4.pdf>

Mudge and the other side of the story:
<http://www.zdnet.com/intweek/stories/columns/0,4164,2634819,00.html>

How one anti-virus company trades on fear, uncertainty, and doubt:
<http://www.zdnet.com/enterprise/stories/main/0,10228,2626255,00.html>

Soon hackers will be able to cause highway pileups in California:
<http://www.halt2000.com/legislate.html>

Will we ever learn?  Someone hacked 168 Web sites, using the exact same 
vulnerability that others have used to hack high-profile Web sites weeks 
and months earlier.
<http://www.vnunet.com/News/1110938>

The threat of espionage over networks is real.  Or, at least, someone 
thinks so.
<http://www.zdnet.com/zdnn/stories/news/0,4586,2626931,00.html?chkpt=zdhpnew

s01>

Hacking the CueCat barcode scanner.  This looks like a trend: company does 
a really bad job at security, and then attempts to use lawyers to "solve" 
their problem.
<http://www.securityfocus.com/news/89>
And there's a security advisor on how the CueCat is tracking users:
<http://www.privacyfoundation.org/advisories/advCueCat.html>
Hacking the CueCat (this URL is often busy...keep trying):
<http://www.flyingbuttmonkeys.com/useofthingsyouownisnowillegal/>
Disabling the serial-number on the unit:
<http://4.19.114.140/~cuecat/>
A list of freely available alternative drivers:
<http://blort.org/cuecat/>
How to disable the weak cryptography used by the unit:
<http://www.flyingbuttmonkeys.com/useofthingsyouownisnowillegal/cue-decrypt/
>

Why reverse-engineering is good for society:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2636304,00.html>

Article on the futility of protecting digital content:
<http://www.msnbc.com/news/462894.asp?cp1=1>

The downside of Linux's popularity: now the operating system is more likely 
to be insecure by default.
<http://www.osopinion.net/Opinions/JoeriSebrechts/JoeriSebrechts5.html>

This article estimates the cost of lost passwords to businesses: $850K a 
year for a business with 2500 computers.
<http://www.nytimes.com/library/tech/99/08/circuits/articles/05pass.html>

Short-term browser surveillance: tracking users with HTTP cache headers.
<http://www.linuxcare.com.au/mbp/meantime/>

An e-mail worm spies on home banking data (in German).
<http://www.heise.de/newsticker/data/pab-15.09.00-000/>

Amazingly stupid results from Web content filtering software:
<http://dfn.org/Alerts/contest.htm>

A portal for spies (in Russian):
<www.agentura.ru>
News article on the topic:
<http://www.themoscowtimes.com/stories/2000/09/14/010.html>

A virus for the Palm Pilot:
<http://vil.nai.com/villib/dispvirus.asp?virus_k=98836>
<http://www.zdnet.co.uk/news/2000/37/ns-18042.html>

Digital signatures could lead to tracing of online activity and identity
theft.
<http://www.zdnet.com/zdnn/stories/news/0,4586,2633544,00.html>

Will people ever learn that redacting PDF files doesn't work the same way 
as redacting paper?
<http://www.wired.com/news/politics/0,1283,39102,00.html>

Jon Carroll on social engineering:
<http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2000/09/2

8/DD56668.DTL>

Kevin Mitnick sez: security means educating everybody.
<http://cgi.zdnet.com/slink?56512:8469234>

California gets a new computer crime law:
<http://news.cnet.com/news/0-1005-200-2883141.html>

Embarrassing Palm Pilot cryptography:
<http://www.securiteam.com/securitynews/PalmOS_Password_Retrieval_and_Decodi

ng.html>

Heavily redacted Carnivore documentation online:
<http://www.epic.org/privacy/carnivore/foia_documents.html>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO51829,00.html>
Carnivore does more than the FBI admitted:
<http://www.theregister.co.uk/content/1/13767.html>
<http://www.securityfocus.com/news/97>
And the review group doesn't seem very impartial:
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO51991,00.html>
Open-source Carnivore clone released.
<http://www.networkice.com/altivore/>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2630674,00.html>
<http://www.cnn.com/2000/TECH/computing/09/19/email.surveillance.ap/index.ht
ml>

Good article of how government officials at all levels routinely and 
knowingly commit security violations with laptops and sensitive data.  Most 
troubling quote:  "Even when officials are cited for security infractions, 
they rarely are subjected to punishment. Infractions do go in personnel 
records. But, unless there is a clear pattern of repeated violations, they 
generally are ignored, security officials said."
<http://www.latimes.com/business/cutting/20001003/t000093746.html>

News on the stolen Enigma machine.  The story keeps getting weirder.
<http://news.bbc.co.uk/hi/english/uk/newsid_958000/958062.stm>

The war on teen hackers:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2637321,00.html>

CERT has finally endorsed the policy of full-disclosure of security 
flaws.  They will disclose flaws after 45 days.
<http://www.zdnet.com/zdnn/stories/news/0,4586,2637904,00.html>
CERT's new policy:
<http://www.cert.org/faq/vuldisclosurepolicy.html>

NIST has defined SHA (Secure Hash Algorithm) for longer bit lengths: 
SHA-256, SHA-384, and SHA-512.
<http://csrc.nist.gov/cryptval/shs.html>

SDMI hacked?
<http://salon.com/tech/log/2000/10/12/sdmi_hacked/index.html>


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

       Counterpane Internet Security News



A reporter spent 24 hours in one of Counterpane's Secure Operations Centers 
(SOCs), and wrote this article:
<http://www.thestandard.com/article/display/0,1151,19119,00.html>

Counterpane's announces its Technical Advisory Board (TAB):
<http://www.counterpane.com/pr-adv.html>

Bruce Schneier is speaking and signing copies of Secrets and Lies at 
bookstores in Seattle, Portland, New York, Boston, and Washington DC in 
October.
<http://www.counterpane.com/sandltour.html>

Bruce Schneier is speaking at the Compsec conference in London (1-3 
November), and the CSI conference in Chicago (13-15 November).
<http://www.elsevier.nl/homepage/sag/compsec99/2000.htm>
<http://www.gocsi.com/#Annual>


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

  Council of Europe Cybercrime Treaty -- Draft

The Council of Europe has released a new draft of their cybercrime treaty. 
Some highlights:

Two new sections on interception of communications have been included.  All 
service providers must either technically conduct surveillance on demand, 
or technically assist law enforcement (i.e. Carnivore).

The section outlawing security tools remains unchanged, except for a 
footnote that says that an explanatory report will take care of the problem 
of legitimate users.

The section that seems to require releasing crypto keys remains 
unchanged.  A new section proposes that people be forced to process the 
information for the police, and an amusing footnote describes how this will 
be better for privacy.

The intellectual property section has been slightly modified, but appears 
to still be so broad that it will require criminal penalties for putting 
anything on the net that would violate copyrights.

An analysis of the treaty:
<http://www.securityfocus.com/commentary/98>

The treaty:
<http://conventions.coe.int/treaty/EN/projets/projets.htm>

My comments on the previous draft:
<http://www.counterpane.com/crypto-gram-0008.html#6>


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

              The Doghouse: HSBC



How to blame the victim:

According to HSBC's terms and conditions for its banking service:  "You 
must not access the Internet Banking Service from any computer connected to 
a local area network (LAN) or any public internet access device or access 
point without first making sure that no-one else will be able to observe or 
copy your access or get access to the Internet Banking Service pretending 
to be you."

Even worse, the same document states that the customer will be liable for 
any losses that are the result of gross negligence.  And gross negligence 
is defined as non-compliance with the terms and conditions.  So HSBC is now 
free to penalize the customer if they screw up security.

For a while I've made the case that the person who should be concerned 
about computer and network security is the person who holds the liability 
for problems.  Credit cards are a good example; the limits on customer 
liability put the onus on the banks and credit card companies to clean up 
security.  Here we see a bank deliberately trying to pass the liability off 
for its own security lapses onto its customers.

Pretty sneaky.

Based on this negative publicity, HSBC will "review the wording of its 
terms and conditions."  It's a first step.

<http://www.theregister.co.uk/content/archive/12741.html>


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

                 NSA on Security



"A lot of you are making security products that are an attractive 
nuisance....  Shame on you.  [...]  I want you to grow up.  I want 
functions and assurances in security devices.  We do not beta test on 
customers.  If my product fails, someone might die."  --Brian Snow, INFOSEC 
Technical Director at the National Security Agency, speaking to commercial 
security product vendors and users at the Black Hat Briefings security 
conference.

I find this quote (and Snow's entire talk) fascinating, because it speaks 
directly to the different worlds inside and outside the NSA.  Snow is 
campaigning for increased assurance in software products: assurance that 
the products work as advertised, and assurance that they don't do anything 
that is not advertised.  Inside the NSA, assurance is everything.  As Snow 
says, people die if security fails.  Millions of dollars can be spent on 
assurance, because it's that serious.

Outside the NSA, assurance is worth very little.  The market rewards better 
capabilities, new features, and faster performance.  The market does not 
reward reliability, bug fixes, or regression testing.  The market has its 
attention firmly fixed on the next big idea, not on making the last big 
idea more reliable.

Certainly, assurance is important to security.  I argued as much in 
_Secrets and Lies_.  I also argued that assurance is not something we're 
likely to see anytime soon, and that the smart thing to do is to recognize 
that fact and move on.

In the real world, there's little assurance.  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.  When a city builds a prison, 
there are no assurances that it will reduce crime.  Safety is easier than 
security -- there is some assurance that buildings won't collapse, fire 
doors will work, and restaurant food will be disease-free -- but it's 
nowhere near perfect.

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.  Retailers know that there are no assurances 
against shoplifting, and set their prices to account for 
"shrinkage."  Computer and network security is no different:  Implement 
preventive countermeasures to make attacks harder, implement detection and 
response countermeasures to reduce risk, and buy enough business insurance 
to make the rest of the problem go away.  And build your business model 
accordingly.

Those are tools that the military cannot take advantage of.  The military 
can't buy insurance to protect itself if security fails.  The military 
can't revise its "business model"; it's not a business.  If military 
security doesn't work, secrets might be exposed, foreign policy might fail, 
and people might die.

Assurance is a great idea, and I'm sure the military needs more of it.  But 
they are as likely to get it out of the commercial sector as they are 
likely to find EMP-hardened, TEMPEST-shielded, and MIL-SPEC electronics 
down at the local Radio Shack.


Snow's quote appeared in:
<http://www.infoworld.com/articles/hn/xml/00/07/28/000728hnnsa.xml?0802wepm>


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

                  AES Announced



Rijndael has been selected as AES.  Well, NIST has proposed Rijndael for 
AES.  There is a three-month public review, and then the Secretary of 
Commerce will sign a Federal Information Processing Standard (FIPS) 
formalizing the Advanced Encryption Standard.  But the choice of algorithms 
has been narrowed to one: Rijndael.

Of course I am disappointed that Twofish didn't win.  But I have nothing 
but good things to say about NIST and the AES process.  Participating in 
AES is about the most fun a block-cipher cryptographer could possibly have, 
and the Twofish team certainly did have a lot of fun.  We would do it all 
over again, given half the chance.

And given their resources, I think NIST did an outstanding job 
refereeing.  They were honest, open, and fair.  They had the very difficult 
job of balancing the pros and cons of the ciphers, and taking into account 
all the comments they received.  They completed this job in an open way, 
and they stuck to the schedule they outlined back in 1996.

While some people may take issue with the decision NIST made -- the 
relative importance NIST gave to any particular criterion -- I don't think 
anyone can fault the process or the result.  There was no one clear AES 
winner of the five semi-finalists; NIST took an impossible job and 
completed it fairly.

Rijndael was not my first choice, but it was one of the three algorithms I 
thought suitable for the standard.  The Twofish team performed extensive 
cryptanalysis of Rijndael, and will continue to do so.  While it was not 
the most secure choice (NIST said as much in their report), I do not 
believe there is any risk in using Rijndael to encrypt data.

There is a significant difference between an academic break of a cipher and 
a break that will allow someone to read encrypted traffic.  (Imagine an 
attack against Rijndael that requires 2^100 steps.  That is an academic 
break of the cipher, even though it is a completely useless result to 
anyone trying to read encrypted traffic.)  I believe that within the next 
five years someone will discover an academic attack against Rijndael.  I do 
not believe that anyone will ever discover an attack that will allow 
someone to read Rijndael traffic.  So while I have serious academic 
reservations about Rijndael, I do not have any engineering reservations 
about Rijndael.

Nor do I have any reservations about NIST and their decision process.  It 
was a pleasure working with them, and the entire Twofish team is pleases to 
have been part of the AES process.  Congratulations Rijndael, 
congratulations NIST, and congratulations to us all.

News stories:
<http://www.wired.com/news/politics/0,1283,39194,00.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2635864,00.html>

NIST AES Web site:
<http://csrc.nist.gov/encryption/aes/>

NIST coverage:
<http://www.nist.gov/public_affairs/releases/g00-176.htm>

NIST's final AES report:
<http://csrc.nist.gov/encryption/aes/round2/r2report.pdf>

The Twofish team's final AES comments:
<http://www.counterpane.com/twofish-final.html>

The Twofish team's Rijndael cryptanalysis:
<http://www.counterpane.com/rijndael.html>

This AES hardware survey was completed too late to be on the NIST site:
<http://ece.gmu.edu/crypto/AES_survey.pdf>


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

                 NSA on AES



The NSA's non-endorsement of AES was very carefully worded:  "The National 
Security Agency (NSA) wishes to congratulate the National Institute of 
Standards and Technology on the successful selection of an Advanced 
Encryption Standard (AES).  It should serve the nation well.  In 
particular, NSA intends to use the AES where appropriate in meeting the 
national security information protection needs of the United States 
government."

The quote is attributed to Michael J. Jacobs, Deputy Director for 
Information Systems Security at the National Security Agency.

Note the last sentence.  The NSA has not stated that it will use AES to 
protect classified information.  The NSA has not stated that it will use 
AES widely.  It has simply stated that, "where appropriate," it will use 
AES to meet its "national security information protection needs."

In the past, the NSA has, on occasion, used DES to protect what was known 
as "sensitive but unclassified" information -- personnel records, 
unclassified messages, etc. -- and we all know how secure DES is.  My guess 
is that they will use AES to protect a similar level of information, in 
instances where buying commercial products that implement AES is a cheaper 
alternative to whatever custom alternatives there are.

It is possible that they will eventually use AES for classified 
information.  This would be a good thing.  But my guess is that many more 
years of internal cryptanalysis are required first.

You can read the quote here:
<http://www.nist.gov/public_affairs/releases/aescomments.htm>


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

             Privacy Tools Handbook



Senate Judiciary Committee Chairman Orrin Hatch has released a consumer 
guide to online privacy tools.  His stated hope is that consumers will 
demand adequate privacy from e-retailers and avoid legislated privacy 
regulation.  Really, it's a piece of propaganda against government 
regulation of privacy, though nicely buzzword compliant with "anonymizers" 
and "infomediaries" among the technological superheros who can save the day.

Some observations:

         a) Companies who post privacy policies online are not legally 
obligated to follow those policies, nor are they prohibited from changing 
them arbitrarily.  That is, there are essentially no legal consequences for 
cheating (breaking the policy), probably not even "false advertising" 
claims.  And that completely ignores companies who don't even post their 
policies.

         b) Consumers cannot even begin to make "informed decisions" about 
sharing their personal data if they are unaware of all the ways that data 
can be aggregated, cross-correlated, and otherwise manipulated.  The whole 
point of regulation is to protect customers from corporate manipulation.

         c) The whole debate is built on the tacit premise that you don't 
own information about yourself, regardless of how that information was 
collected (including being collected under false pretenses).  Contrast that 
to EU personal-data laws, which are based on a very different premise.

         d) As long as there is a profit to be made, and no consequences 
for cheaters, industry self-regulation is a paper tiger.  The "bad actors" 
will simply stay one jump ahead of the law and legal jurisdiction, and 
there are precious few federal laws that can be applied effectively, anyway.

         e) In the document, government regulation is always characterized 
as either "ill-advised," "burdensome," "excessive," or 
"heavy-handed."  Industry self-regulation is always characterized as 
"meaningful," "commend[able]," or "effective."  Whatever happened to simple 
effective federal legislation?  And while the current federal fair-trade 
and food-purity laws are far from simple, is anyone seriously advocating 
that they be totally rescinded?  Reformed, yes, but not demolished.

By the way, as long as we're on the subject of unintentional privacy 
leaks...  Examining the PDF file, we can learn:

         1) The document's author is listed as "AlR" (lower-case L in the 
middle).
         2) It was created with PageMaker 6.5.
         3) The PDF file was made by PDFWriter 3.0.1 for Power Macintosh.

It probably wouldn't be all that hard to find out exactly who "AlR" is; how 
rare are phone directories for the Judiciary Committee and Orrin Hatch's
staff?

<http://www.zdnet.com/zdnn/stories/news/0,4586,2630778,00.html>
<http://www.mercurycenter.com/svtech/news/breaking/merc/docs/080131.htm>

Hatch's guide may be found at:
<http://judiciary.senate.gov/privacy.htm>

Official Senate Judiciary Committee PDF document:
<http://judiciary.senate.gov/privacy.pdf>


Thanks to Greg Guerin, who had more of a stomach to read through this 
document than I did.


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

             Comments from Readers



From:  Anonymous
Subj:  People Security

This is a true account of what happened to me a couple of weeks 
ago.  (Passwords have been changed and names have been deleted.)  I have an 
"Internet banking" arrangement with a local bank.  I recently wanted to add 
another account to their system, so I rang their help desk to do so, the 
conversation going along the following lines:

Me: "Hello.  I want to make some changes to my Internet banking account."
Operator: "Yes sir.  What is your account number?"

Me: "1234-5678"
Operator: "Ah yes, Mr. Anonymous.  Now, your account has some passwords on
it."

Me: <getting prepared to divulge them, but before I can speak> Operator: 
"There are three passwords, two are women's names, and one isn't.  The 
women's names start with 'D' and 'M'."

Me: <rather astonished at his 'help'> "Dorothy and Margaret."
Operator: "That's right."

Me: "and the third one is ..."
Operator: "Yes, I know.  It's 'swordfish'.  Now, what changes do you want 
to make to your account?"

When you look at this behavior, you can see that the bank can hire security 
experts, encrypt their data), and all this comes to naught if the operators 
divulge the passwords over the phone.  It makes you wonder how far I would 
have got if I had actually said "I can't remember the password -- can you 
give me a hint".

Clearly there are some design problems with their system, on top of the 
obvious training problems.  The operator *should not* be presented with the 
passwords on his screen, thus he cannot divulge them even if he wanted 
to.  Rather, he should have to type in the word(s) the customer supplies, 
with the computer merely saying "right" or "wrong" (and locking him out 
after 3 or so attempts).

The fact that he did so, so readily, suggests that every second customer 
has forgotten his password, and he was just trying to be helpful.  This 
being the case, it makes you wonder whether expecting customers to remember 
lots of passwords is really the solution to improved security.  The 
evidence suggest not.


From: "Gary Hinson" <Gary.Hinson@CCCL.net>
Subject: Non-disclosure as a marketing tool

See if this company announcement looks familiar:  "We acknowledge that 
product X has a serious security flaw (which, for security reasons, we 
cannot describe in too much detail), but don't worry -- we have fixed 
it.  Registered users click here to upgrade to the latest secure version..."

Call me a cynic, but this strikes me as a marvelous sales booster.  Users 
are told there is a known security problem in their software, but have 
insufficient information to conduct a realistic risk assessment, to 
determine whether they are really exposed.  Therefore they are compelled to 
upgrade or face unknown risks.  Meanwhile the newsletters and security 
sites discuss the gravity of the flaw and describe (often theoretical) 
exploits and eventually the mass media catch on.  At this point, we've 
reached the stage at which it no longer matters whether an individual 
user/system manager is actually at risk.  He's now facing serious pressure 
from peers and management to upgrade and can't argue strongly that there's 
no need.

Even if the product upgrade in question is offered as a "free patch," one 
often needs to upgrade associated programs at cost (especially if, say, the 
insecure product is an operating system).  There's no such thing as a free 
lunch!

Just one more cynical thought.  Suppose that the latest version has ANOTHER 
security flaw that is mysteriously revealed in, say, 6 months time, 
re-starting the upgrade cycle.  Now, without access to the original source 
and associated materials, who can say whether or not the flaw was 
intentionally inserted by the vendor?

You can see where I'm heading here.  Users' fears about security may be 
being used deliberately by the vendors to drive up product sales, when the 
traditional means (facelifts, releasing new product features etc.) are 
becoming less effective due to the software market maturing.


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

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 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/>

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

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net