CRYPTO-GRAM

               February 15, 2001

               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/crypto-gram.html>.  To subscribe or 
unsubscribe, see below.


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


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

In this issue:
      Hard-Drive-Embedded Copy Protection
      Crypto-Gram Reprints
      News
      Counterpane Internet Security News
      An Intentional Backdoor
      The Doghouse: NASA and eTrue
      A Semantic Attack on URLs
      E-mail Filter Idiocy
      Air Gaps
      Internet Voting vs. Large-Value e-Commerce
      Comments from Readers


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

     Hard-Drive-Embedded Copy Protection



CPRM (Content Protection for Recordable Media) is a system for enforcing 
copy protection on personal computers.  The basic idea is to enforce 
digital rights management -- copy-prevention, limited use, whatever -- in 
electronic media.

In more detail, the scheme requires specially designed copying 
software.  This software communicates directly to the disk drive, bypassing 
the operating system.  To write a document, first the drive and the 
software authenticate to each other.  Then the drive sends the software 
keying material that is stored in a nonstandard place on the drive that's 
unique to the medium, and also reads back an increment-only counter in the 
medium.  The user-level application -- or, more likely, a server somewhere 
on the Web -- encrypts the file using that keying material.  The encrypted 
object is written as an ordinary file on the medium.  An intermediate key 
file is written as a second ordinary file.

The "player" for these encrypted objects will pull an increment-only 
counter out of the drive, use it and the keying material to decrypt the 
intermediate key-file, and then extract the document key from that 
file.  It will then play the document.

To move (as opposed to copy) the document to another disk, the software 
will check to determine if this is permissible.  (Perhaps the permissions 
will be embedded in the file; perhaps the software will query another 
computer over the Internet.)  If the move is allowed, the software will 
re-encrypt the document for the new medium (only allowing it to be stored 
in a copy-protected medium), increment the increment-only counter in the 
old medium, generate a new key-file key with the new counter value, and 
rewrite the old key-file, deleting the key that would allow the old copy to 
be played.  After moving the document, even if the user keeps a copy of the 
encrypted bits, it won't play on the original medium because its key won't 
be in the key-file on that medium.

If a user copies the encrypted object to another medium without going 
through the approved procedure, its key won't be in the key-file on the new 
medium, so the reader can't play it.  If the user copies both of them to 
another medium, the key-file won't be decryptable since its key depends on 
the medium-specific keying info.  If the user makes a backup copy of his 
entire disk, "moves" the encrypted song onto another medium, then scrubs 
and restores the entire original disk, the restored key-file won't be 
decryptable, since the increment-only counter (that is hashed with the 
medium-specific keys to produce the key-file key) will have changed.

There are other tricks built into the system.  There's no single global 
secret to steal, and there's a mechanism to recover security if some of the 
many global secrets get out.  The system is based on something called 
"broadcast encryption," developed by Amos Fiat and Moni Naar in 1993.

The technology will be ineffective, but that may not matter.

Broadly speaking, there are three classes of people who copy 
documents.  There are average users, who just want a second copy for 
whatever reason but won't use hacker tools.  There are  more savvy users, 
who are willing to download programs that break copy-protection 
schemes.  And there are professionals, who are prepared to spend serious 
money to break copy-protection schemes.

Against the first group, any security measure works.  This hardware scheme 
is overkill.  Against the second group, any scheme that involves software 
fails.  I've written about this extensively both in _Secrets and Lies_ (see 
pp. 250-253) and in a previous issue of Crypto-Gram.  Basically, the scheme 
described above has a key stored in hardware and a software decryptor.  To 
break the scheme, you don't need to extract the hardware key.  You can let 
the decryption software do it normally, and then grab the document after 
decryption and before play.  Someone will write software do to this, just 
as someone has written software to get around every other similar 
scheme.  The hardware component doesn't matter.

Where it will make a difference is in devices that don't expose the 
decrypted document.  The reason the computer embodiment fails is because 
the document exists unencrypted in the computer, and a hacker can write a 
program to take advantage of that.  If this copy protection is brought 
forward to the video monitor, or the speakers, then the document never 
exists in the computer in unencrypted form.  If the scheme only runs on DVD 
players or MP3 devices or anything else where you can't run custom 
software, this is much more effective.

But it still doesn't work against the third class of attackers: the 
professionals.  These are people willing to invest in custom 
hardware.  They will always be able to break these schemes and extract the 
documents.  And they will always be able to produce and sell bootlegs, at 
least to the limits of law enforcement in whatever country they're in.

There is another angle here, making this even more complicated.  Content 
providers are no longer relying on technology to enforce copy protection, 
they're relying on laws.  The algorithms used in this scheme will be 
patented, so anyone who writes a hacked decoder will be infringing on the 
patent.  And any software designed to circumvent this mechanism will be 
illegal under the Digital Millennium Copyright Act.  Not only can the 
authors of this software be prosecuted, but so can people who "traffic" in 
this software: e.g., post or link to it on their Web site.

This will not make it any harder to find such circumvention software -- 
notice how easy it is to find DeCSS today with your search engine -- but it 
will have a chilling effect on the whole idea.  2600 Magazine was 
successfully prosecuted for linking to DeCSS; similar pressure will be 
brought to bear against anyone who publicizes any DeCPRM software.

So, what do we have here?  We have a serious threat to civil liberties: 
large entertainment companies are allying themselves with the computer 
industry to dictate what can and can't happen on your hard drive.  (CPRM is 
only supposed to be for flash memory.  This is a lie, of course.  Already 
it is planned for IBM's tiny hard drive, and larger drives aren't far 
behind.)  We have a technology that will, in some circumstances, make 
backups impossible.  Compatibility problems between disk drives that have 
CPRM and those that don't will force networks to completely upgrade their 
mass storage.  We have a technology that forces users to buy proprietary 
decoding software forever.  We have a technology that won't really work 
unless it extends to computer output devices; you may find yourself forced 
to upgrade your monitor as well to watch movies on your computer.  And we 
have an increased reliance on legal harassment by media companies.  It's 
that last bit that scares me the most.

The proposal:
<http://www.theregister.co.uk/content/2/15620.html>
<http://www.lmicp.com/4centity/data/tech/cpsa/cpsa081.pdf>
<http://www.lmicp.com/4centity/data/tech/4cspec.pdf>
<http://www.theregister.co.uk/content/2/15718.html>
<http://www.theregister.co.uk/content/2/15797.html>

What's Wrong with Copy Protection, by John Gilmore:
<http://www.toad.com/gnu/whatswrong.html>

Copy protection and why it doesn't work:
<http://www.counterpane.com/crypto-gram-9811.html#copy>

EFF's archives on the topic:
<http://www.eff.org/IP/>

The 4C Entity (IBM, Intel, Toshiba and Matsushita), which owns and 
advocates CPRM:
<http://www.dvdcca.org/4centity/>


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

             Crypto-Gram Reprints



Distributed denial-of-service attacks:
<http://www.counterpane.com/crypto-gram-0002.html#DistributedDenial-of-Servi 
ceAttacks>

Publicizing vulnerabilities:
<http://www.counterpane.com/crypto-gram-0002.html#PublicizingVulnerabilities>

Recognizing crypto snake-oil:
<http://www.counterpane.com/crypto-gram-9902.html#snakeoil>


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

                      News



Nineteen technology companies have joined forces to share data on system 
vulnerabilities and Internet threats.  Called the Information Technology 
Information Sharing and Analysis Center (IT-ISAC), the group is supposed 
work with the government to head off future cyberattacks on the group's 
members.  I have very mixed feelings about this.  On the one hand, sharing 
information is a good idea, and we need more of this.  On the other hand, 
the problem with sharing information among group members is that it remains 
a secret from the rest of the world.  The last thing we want is a divide of 
haves and have-nots, with only those in special clubs being secure.
<http://www.msnbc.com/local/rtar/m8943.asp>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2674800,00.html>
<http://www.wired.com/news/politics/0,1283,41212,00.html>

Princeton University's Ed Felten is not going to publish details about how 
he broke the Secure Digital Music Initiative (SDMI) watermark challenge, 
because of the prosecution provisions of 1998 Digital Millennium Copyright 
Act (DMCA).
<http://www.theregister.co.uk/content/6/16107.html>
<http://www8.nytimes.com/2001/01/15/technology/15TUNE.html>

A rebuttal to my essay last month about certifying security products:
<http://www.avolio.com/columns/ProdCert.html>

The future of operating system security:
<http://securityportal.com/cover/coverstory20010115.html>

Latest news on U.S. crypto export controls:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2673461,00.html>

Testimony on evaluating voting machines.  He makes the point that voting 
machines should never have secret or proprietary parts.  A bit long, but 
worth reading.
<http://www.cs.uiowa.edu/~jones/voting/uscrc.html>
And a U.S. government report on the problems of computerized voting from 
1988.  Lots of lessons that should be learned.
<http://www.nist.gov/itl/lab/specpubs/500-158.htm>

A Linux worm -- called Ramen -- is working its way through the 
Internet.  Some consider this retribution for the smugness of Linux users 
about the security of their operating system versus Windows.  That misses 
the point; of course all operating systems will have vulnerabilities.  The 
two interesting points are: 1) default installations of Red Hat Linux are 
insecure, just like default installations of Windows, and 2) just because 
patches exist for a vulnerability doesn't mean we're safe.
<http://news.cnet.com/news/0-1003-200-4508359.html>

Why the government needs to protect individual privacy on the Internet, 
while staying away from regulating content, information, and ideas.
<http://www.oecdobserver.org/news/fullstory.php/aid/409>

A year after the highly publicized distributed denial-of-service attacks, 
the Internet is still vulnerable:
<http://cgi.zdnet.com/slink?76741:8469234>

The EFF has petitioned a federal appeals court to overturn a lower court's 
interpretation of the DMCA to mean that the 2600 Web site must remove links 
to DeCSS.
<http://news.excite.com/news/zd/010119/17/eff-on-decss>
<http://www.computeruser.com/news/01/01/22/news14.html>
<http://news.cnet.com/news/0-1005-201-4537831-0.html>
<http://www.geek.com/news/geeknews/2001jan/gee20010122003915.htm>

Leo Marks, WW II cryptographer and author of _Between Silk and Cyanide_ died:
<http://www.theregister.co.uk/content/4/16308.html>

Often, security vulnerabilities are never patched:
<http://news.cnet.com/news/0-1007-201-4578373-0.html?tag=btmprm>

The 3G cell phone encryption algorithms are public.  This is a welcome 
change from the industry's usual practice of secret cryptography.  Bravo.
<http://www.research.att.com/~janos/3gpp.html>

After all these years, the Net still isn't a safe place (no surprise):
<http://computerworld.com/cwi/story/0,1199,NAV65-663_STO56690_NLTs,00.html>

All vulnerability scanners miss things, but the open source (and free) 
Nessus was judged to be the best:
<http://www.networkcomputing.com/1201/1201f1b1.html>

Children are a significant personal privacy risk:
<http://www.ecommercetimes.com/perl/story/6942.html>

Master's thesis:  Cryptographic Software Export Controls in the EU.
<http://ethesis.helsinki.fi/julkaisut/oik/julki/pg/parviainen/>

DirecTV scored a direct hit against pirates.  Over the course of a few 
months it surreptitiously broadcast, byte by byte, a program that allowed 
it to permanently disable pirate DirecTV access cards.  On January 21st, 
they triggered the program.  Supposedly this knocked out 98% of cracked 
cards.  My favorite tidbit is that they wrote "GAME OVER" into an affected 
area of memory.  The pirate community is already working on hardware 
workarounds and, supposedly, the cracked cards that use emulation are easy 
to fix.  So while DirecTV won this battle, the war goes on.
<http://www.securityfocus.com/news/143>
<http://news.bbc.co.uk/hi/english/sci/tech/newsid_1138000/1138550.stm>
<http://slashdot.org/articles/01/01/25/1343218.shtml>
<http://www.hackhu.com/>

Basic cryptanalysis of RSA's formerly proprietary SecurID hash function.
<http://www.atstake.com/research/reports/initial_securid_analysis.pdf>

The NSA is trying to design a hack-proof computer.  I don't know, but this 
seems like a poorly thought out idea.
<http://www.zdnet.co.uk/news/2001/4/ns-20672.html>

Classic snake oil:
<http://www.securesystems.com.au/>
It's secret, and they even have a contest.

More snake oil: cryptanalysis of "Encrypted Magic Folders":
<http://www.accessdata.com/emf_cryptanalysis.html>

It seems that private keys are exposed in the Java security database.  This 
explanation is worth reading.
<http://www.amug.org/~glguerin/security/jdk-1.1/exposure.html>

A bunch of cryptographers, myself included, wrote an amicus brief for the 
DeCSS case that EFF is supporting:
<http://eon.law.harvard.edu/openlaw/DVD/NY/appeal/000126-cryptographers-amic 
us.html>

Optical vote readers can be worse than punch cards, according to a 28 Jan 
01 LA Times article.  Some systems reject ballots because the voter marked 
the oval for a candidate and then also wrote the same candidate's name in 
the write-in space.  Personally, I don't see how that can be interpreted as 
anything but "the clear intent of the voter."  My favorite blunder has to 
be the counting machines that rejected mail-in absentee ballots because 
they detected the fold in the paper (unavoidable in order to actually mail 
the ballot in the legal envelope) as a second vote.  (If you want to read 
the article online, you have to pay for it at www.latimes.com.  The idiots 
only keep their links free for a few weeks.)

Excellent article on why micropayments don't make business sense.
<http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.html>

Fascinating thought piece on the future of "digital rights management":
<http://www.discover.com/feb_01/gthere.html?article=featnapster.html>

There have been reports that RSA has been cracked by a Filipino "math 
enthusiast."  Actually, the cracking algorithm is slower than factoring.
<http://www.zdnetasia.com/news/dailynews/story/0,2000010021,20178050-1,00.htm>
An e-mail conversation with Ron Rivest about the algorithm:
<http://www.seedmuse.com/rsa_edit.htm>

Crypto break of the 802.11 wireless LAN encryption protocol (Apple's 
AirPort, for example).  Real-time decryption of traffic is possible.  Nice 
work.
<http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2681947,00.html>
<http://www.wired.com/news/technology/0,1282,41612,00.html>


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

       Counterpane Internet Security News


Schneier's "Why Cryptography is Harder than it Looks" has been published on 
a German Web site:
<http://legamedia.de/nl/nl.php3?nl=a6577c331eb4a55ac8e738e74ff06f86>


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

             An Intentional Back Door



It's one thing have an attacker add a back door to your system for later 
unauthorized access.  It's quite another to deliberately do it to yourself.

It seems that Borland did this very thing with its Interbase database.  All 
versions released for the past seven years (versions 4.x through 6.01) have 
this back door.  How it came about and how it was discovered is instructive.

Versions of Interbase before 1994 didn't have any access-control 
mechanisms.  This was fixed in version 4.0 using a peculiar system.  Since 
they had a database, the engineers created a special database within 
Interbase for account names and encrypted passwords.  This solution had a 
problem: in order to authenticate a user, the program had to access the 
database, but before the program could access the database, it had to 
authenticate a user.

Now there are many ways to solve this problem, but hard coding the username 
"politically" and the password "correct" is not the one I would have 
chosen.  But it is the one Borland did.  This is the backdoor; anyone using 
that username and password can access any Interbase database.

Lesson one:  Deliberately adding back doors creates a security problem 
whose magnitude is unknown and changes over time.  I call this the "window 
of exposure."  The moment this product was shipped, the vulnerability 
existed.  But as long as no one knew about it, it wasn't a problem.  At 
this point we have no idea if anyone in the hacking underground knew about 
the vulnerability, or if any criminals took advantage of it.  Certainly the 
programmers who coded the "feature" knew about it.  They could have told 
others.  Word could have gotten around.

Now the vulnerability is public; everyone knows about.  Within days of 
announcement, there were reports of scans looking for the 
vulnerability.  Borland issued a patch, but who knows what percentage of 
users will patch their systems.  The vulnerability will remain in many 
systems for years.

Lesson two: Open source helps security, sometimes.  Interbase was made open 
source in July 2000.  This vulnerability was discovered six months later by 
a German software developer.  If he hadn't discovered it, maybe we would 
still not know about it.  If someone had looked at the code sooner, maybe 
we would have known sooner.  Open source means that more people examine the 
source code, but it is no guarantee that vulnerabilities will be found or 
-- even if found -- fixed properly.  If the person who discovered the 
vulnerability was intent on breaking into systems, this would have played 
out much differently.

Lesson three:  In a world with no liabilities, trust is transitive whether 
you like it or not.  Company X's customers trust Company X.  If Company X 
was using Interbase, those customers were also trusting Borland...only they 
didn't know it.  Those customers are also trusting Company X's hardware and 
software suppliers, ISP, etc., etc., etc.  If the Company X had some sort 
of legal liability towards its customers, then this transitive relationship 
would not exist.  But because the customers have no recourse if Company X 
screws up, it does.

Back doors have the unfortunate property of being all or nothing.  It's 
like leaving your house key under the mat.  If no one knows about it, it's 
pretty safe.  If everyone knows about it, it makes your door lock 
useless.  Borland certainly belongs in the doghouse for this one.

<http://www.securityfocus.com/news/136>
<http://www.windowsitsecurity.com/articles/index.cfm?articleID=16566>
<http://www.cert.org/advisories/CA-2001-01.html>


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

         The Doghouse: NASA and eTrue



NASA is testing a biometric authentication system that works over the 
Internet.  I've repeatedly written, both in these pages and in _Secrets and 
Lies_, about the dangers and insecurities of remote biometric 
authentication.  But if that weren't enough, the CEO of the biometric 
company eTrue was reported to have said: "And anyone attempting to hack 
into a NASA system will have his or her own biometric characteristics 
logged and recorded."  Why would anyone attempting to break into a network 
send his *own* fingerprint to be authenticated?  (Note that it is not a 
direct quote in the article, which may mean that the reporter is to blame 
for this.)

<http://www.fcw.com/fcw/articles/2001/0101/web-nasa-01-04-01.asp>

My essay on biometrics:
<http://www.counterpane.com/crypto-gram-9808.html#biometrics>


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

           A Semantic Attack on URLs



This is clever.  Last month I received an e-mail that said:

Check out breaking news at CNN:
<http://www.cnn.com&story=breaking_news@18.69.0.44/evarady/www/top_story.htm>

(Unfortunately, the URL no longer works.  But stick with me.)  At first 
glance, this looks like a CNN URL.  But the URL does not lead to, or does 
not redirect from, cnn.com.  The page is not CNN's.  The URL is a clever 
hack that plays with people's assumptions about what a URL is supposed to 
look like.

Here's how it works.  An MIT student created a fake Web page and put it up 
on his Web site at:

<http://salticus-peckhamae.mit.edu/evarady/www/top_story.htm>

He then sent out the first URL above.  If you examine that URL carefully, 
you can see that the host name is not "www.cnn.com" but "18.69.0.44," which 
is the same as salticus-peckhamae.mit.edu.  (For extra obfuscation, he 
could have converted that host name to decimal.)  That entire bit before 
the @-sign -- "www.cnn.com&story=breaking_news" -- is a "username," 
something allowed by the HTTP specification but rarely used in actual URLs.

This is a really clever example of a semantic attack: one that targets 
people and meaning rather than computer syntax.  The attacks are obvious: 
someone could send a fake e-mail from www.whatever.com, telling them to 
click on this URL for a free gift.  The URL would look like it came from 
the Whatever company, but would instead go to a look-alike site that 
harvests the usernames and passwords.

Most Internet users have no idea what a URL is supposed to look like, let 
alone how to parse one.  In a world where there is no real way to validate 
anything, the URL has become the means that people use to determine the 
source of a Web page.  (Does anyone EVER examine a public-key 
certificate?)  But if URLs can play with our expectations of what they 
should look like, what can we do?

Semantic Attacks:
<http://www.counterpane.com/crypto-gram-0010.html#1>


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

             E-Mail Filter Idiocy



As long as we're mentioning semantic attacks, let's talk about semantic 
defenses.  Many companies filter incoming e-mail for viruses, Trojans, 
spam, etc.  Some of these filters blocked the January Crypto-Gram.

Ten copies were blocked because they contained the character string 
"ILOVEYOU" -- even though they were plain text with no attachments.  This 
makes no sense to me:  it's laughably easy to change ILOVEYOU to use some 
other subject line, but good luck getting it to spread through plain text 
e-mail.  (I suppose you could put the source code in the message and just 
hope the recipient would compile it.)  So what the filter really does is 
block e-mail containing information about the Trojan, not to mention this 
issue of Crypto-Gram.

But that bit of overreaction pales in comparison to this bounce message I 
received:  "MailMarshal (an automated content monitoring gateway) has 
stopped the following e-mail for the following reason:  It believes it may 
contain unacceptable language terms, or inappropriate material....

"MailMarshal Rule: Inbound Messages: Block Unacceptable Language, Script 
Profanity Porn and Racism Triggered, Expression: blow AND job Triggered 1 
times weighting 5.  For more information on e-mail virus scanning, security 
and content management, visit http://www.crypsys.nl"

That's right, MailMarshal blocked Crypto-Gram because in one place I used 
the word "blow" and then a couple of thousand words later I used the word 
"job."  And the sad thing is that the very same e-mail filter will block 
this issue of Crypto-Gram for the very same reason, and the recipient will 
never know.


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

                     Air Gaps



Whale Communications has been marketing something called e-Gap, which they 
claim is an "air gap" between two networks.  Basically, the system consists 
of two servers.  One is connected to the Internet and the other to the 
internal network.  The two servers only connect through the e-Gap system, a 
SCSI-based memory device that gets toggled between them.  The two servers 
are never directly connected.

This is an interesting idea, but it's not an air gap.

What E-Gap really does is create a proxy connection between two 
computers.  It's a slow connection.  It's a very limited connection; the 
system strips down any network layers under the session layer.  What that 
means is that if you set up a system using E-Gap and an intruder were to 
break into the Internet server, he could not obtain TCP/IP connectivity to 
the internal server.  This certainly increases the security of the back-end 
server.

Nonetheless, the intruder can still access the back-end server as a regular 
client.  The intruder can still break into the internal system by 
exploiting any vulnerabilities above the transport layer.

The whole point of an air gap is that there is no automated connection 
between the two devices.  It's not simply that there is no physical 
connection between the devices most of the time, but that any logical 
connection between the two devices is not automated.  If the Internet 
server and the back-end server were on opposite sides of a room, there 
would be an air gap between them.  To connect the two computers, a user has 
to walk a floppy disk across the room.  For an attacker to attack one 
computer from the other, he needs to be physically present.  Even if an 
attacker gains access to the Internet server remotely, he cannot bridge the 
air gap to the back-end server.

While E-Gap can claim that with their device systems are "completely 
disconnected at all times," the truth is that their switch operates 
automatically at all times.  There is always a logical connection between 
the systems connected by their device.  And that connection is subject to 
remote attack, and possible compromise.

I'm not saying that this is a bad product -- it sounds like a good product 
-- but it is not an air gap.  Calling it one is deceptive marketing.  Kind 
of like calling a stream cipher a one-time pad.


Whale's page describing their technology:
<http://www.whale-com.com/fr_0300.htm>
They call it "impenetrable."  Also note that on their home page they don't 
just call it an air gap but a *physical* air gap, just in case someone 
might have wanted to give them the benefit of the doubt.

A response to critics by someone with Whale:
<http://lists.gnac.net/firewalls/mhonarc/firewalls.199911/msg00269.html>

Hall of shame puff piece:
<http://www2.cio.com/archive/050100_development_content.html>

Whale isn't the only one.  Here's a review of six "air gap" products:
<http://www.infosecuritymag.com/articles/july00/cover.shtml>

Airgap Networks, which has few details on their product, is notable for 
actually defining "air gap" (albeit in an Orwellian manner).
<http://www.airgap.net/what.html>


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

   Internet Voting vs. Large-Value e-Commerce



One of the odder comments I've heard in the debate on Internet voting is 
the following: "If we can protect multi-billion-dollar e-commerce 
transactions on the Internet, certainly we can protect elections" (or words 
to that effect).  I've heard it so often that I feel the need to explain 
why it isn't true.

There are two important differences between large financial transactions 
and voting that make the former much more suitable for networked 
implementation: anonymity and recovery.

In _Secrets and Lies_, I made the point that electronic financial systems 
based on identity (electronic credit cards, electronic checks, PayPal, 
etc.) are much more likely to be implemented than electronic cash because 
the former is much easier to secure.  Large financial transactions all have 
names attached: who gets the money, who loses the money.  Votes only have 
the names of the recipients attached; the whole point of a secret ballot is 
to remove the name of the voter.  This makes is much harder to protect the 
system from fraud, much harder to detect fraud if it happens, and much 
harder to identify the perpetrator and arrest him.

Another difference between large financial transactions and voting is that 
you can unwind a financial transaction.  This is important.  If someone 
manages to steal a billion dollars from a financial system, you can freeze 
the transaction, try to figure out what happened, and hopefully return the 
money.  If someone manages to hack the vote, there's nothing you can 
do.  This is the lesson from Florida: even in the face of a confusing 
ballot, manipulation of absentee ballot applications, widespread voter 
irregularities, and voting technology that disproportionally 
disenfranchised minorities, there was nothing that could be done.  The vote 
was taken on Election Day, and that's that.  Revoting would have been even 
more unfair, because it is impossible to recreate the conditions at the 
time of the original vote.  Our voting system doesn't allow for the same 
ability to redo transactions that our financial systems do.

There's another, less important, difference between large financial 
transactions and voting: in the latter, appearances matter.  If someone 
claims to have stolen a billion dollars and no one seems to have lost it, 
you can safely ignore his boast.  On the other hand, if some political 
group claims, on election night, to have hacked the vote...what do you 
do?  You can't disprove the claim.  You can't redo the vote to make sure it 
is accurate.

Building a secure Internet-based voting system is a very hard problem, 
harder than all the other computer security problems we've attempted and 
failed at.  I believe that the risks to democracy are too great to attempt it.

Quotes:

Phil Noble, director of politicsonline.com, said "...if the largest banks 
in the world transfer billions of dollars every day electronically we can 
use the same technology to ensure secure voting."
<http://www.politicsonline.com/pol2000/electorales_launch/semana-959/>

 From "Analysis of Internet Voting Protocols," by Andre M. Chernay: 
"Currently existing software is adequate to protect the integrity of the 
ballot once the ballot gets into the Internet pipeline.  Transactions 
currently performed over the Internet include e-commerce, the transferring 
of funds around the world, and the purchasing and selling of stocks.  For 
example, 100 million Americans will go online this year and spend almost 
$12 billion in online purchases."
<http://www.mcgeorge.edu/cir/analysis_internet_voting.htm>

This same argument was made on an All Things Considered radio segment 
"Allow People to Register to Vote Online" on 10 Aug 1999.
<http://search.npr.org/cf/cmn/cmnps05fm.cfm?SegID=55141>

"'Vote Integrity on the Internet Is No Different From Billion Dollar 
Transactions,' Says Chris Kenber, President and CEO of Hifn."
<http://biz.yahoo.com/prnews/001207/ca_hifn_vo.html>

 From an article called "About (tele)democracy":  "First, we experience 
voter fraud now and always have lived with it.  Today claims about voting 
irregularities are heard at nearly every election.  Second, if there is an 
incentive to commit electronic fraud, surely money is the prime 
motivation.  Yet, every day, hundreds of billions of dollars move through 
the banking system with good security.  Fraud exists, but it has been 
policed and prosecuted."
<http://www.pels.net/artikel/004.htm>


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

             Comments from Readers



From: Richard <richard@away32.com>
Subject: Underwriters Laboratories

I used to work for a company that manufactured electric hospital beds, and 
was the liaison to UL, and I became very familiar with their modus operandi 
and know how the public can continue to be hoodwinked.

First, they take no legal responsibility for a product (if it should fail), 
by saying that the product is "Listed" not "Approved".  Listing simply 
means that the product met some minimal standards that were in effect at 
the time the product was made.  For encryption software, cracking simply 
means that that version met the old standard, and the software company 
needs to submit a new version to meet the new standard.

Next, they require the manufacturer to pay an annual fee to keep up the 
listing, along with allowing a UL inspector to visit the premises and check 
various samples periodically.  The manufacturer naturally paid extra for 
this.  If the manufacturer wanted to make changes to a product in a listed 
area, they had to submit the change beforehand and when UL accepts it 
(charging extra, of course), then the manufacturer could put it into 
production.  If the inspector found an unauthorized change in the product, 
he could tell the manufacturer they could not ship any more product with 
the UL label on it.  Since the UL logo is usually part of the regularly 
applied product packaging, he was, in effect, halting production.  This 
means that if a software company wanted to improve or fix a bug in their 
product, they couldn't sell it until UL was satisfied.

Finally, every electrically savvy buyer of electrical products can look at 
the guts of a product and pretty well tell if it is reasonably "safe".  The 
consumer, on the other hand, is made to believe that the product is totally 
safe.  The truth is, is that UL goes through an evolution rating a product 
and making changes, just like any manufacturer, and makes mistakes and 
fixes to their standards.  So any defect in any given UL Listed Encryption 
software would simply mean revisions to their standards.

All of this means money for UL, with no responsibility for any damage done.

Your last paragraph on "Ethical Extortionist" hits the nail exactly on the 
head.  It plays right into the current public thinking that we need some 
"authority" to validate every facet of our lives.  Authority is one of the 
six principles of influence as explained by Dr Robert Cialdini's 
http://www.influenceatwork.com/6principles.html article on influence.

I guess what I am trying to point out is that while you and I know that UL 
is a farce, they will probably be involved and come out smelling like a 
rose.  The only way for them not to be involved is if all the encryption 
companies band together and ignore them.  But that "authority" stamp of 
approval, excuse me, listing is too much of a selling point to be ignored.


From: Nick Rozanski <nick@rozanski.com>
Subject: The "Insurance" Model of Security

When most of us think about security, we view it as a binary quality of a 
system -- so we ask questions like "Is this system secure?"  The correct 
answer to this question is always "no" --­ *any* security architecture can 
be broken if there is someone willing to invest the effort, time, and/or 
money to break it.

However this approach is flawed.  A much better way is to recognise that it 
is impossible to implement totally foolproof security -- the best we can do 
is to decide how *resistant to attack* our security architecture needs to 
be, which we can do this by answering two questions.  Firstly, "what is the 
cost to me if my security architecture is compromised?" And secondly (not 
always the same thing) "what is the benefit to someone else of compromising 
my security?"

It is important to understand that the answers to these questions come from 
the business, not from technologists.  (All we have to do is to design and 
build it!) Furthermore, in an ideal world it should be possible to 
objectively *demonstrate* that the system provides the required level of 
security -- in the same way that we are expected to demonstrate conformance 
to other classes of requirement (functional, performance, etc.) as part of 
acceptance.

Where we are today, this is very hard, not least because of the difficulty 
in quantifying, or better still eliminating, the human factors which so 
often seem to be involved in security breaches.  In practice, demonstration 
of conformance to security requirements (or otherwise!) usually takes place 
after systems go live.

The final question to ask is "how will I respond if (when) my security 
architecture is eventually breached?"  This is a problem which needs to be 
addressed by both sides -- technology to "tighten up" the security holes 
which have been exposed, and business to deal with the commercial fall-out 
and make the needed organisational changes.  The answers to these questions 
should form part of any security model as much as the technology components do.


From: Greg Guerin <glguerin@amug.org>
Subject: On "Code Signing in Microsoft Windows"

Here's a relatively simple attack on the code-signing in Whistler, 
regardless of who controls it or what it turns out to be.

1) Create an individual Web-based e-mail account on Hotmail, representing 
yourself as a sole proprietorship software developer.  For the truly 
criminal, falsify all the information.

2) Register as a developer with Microsoft, providing the Hotmail e-mail 
address.  The basic Microsoft registration is probably free.

3) Buy a genuine Authenticode code-signing key.  This may be a non-trivial 
expense though probably not more than a few hundred bucks.  For the truly 
criminal, pay for it with a stolen credit-card number.

4) Once you have the code-signing certificate, sign your malware with it, 
then distribute in the usual way.  If your malware subtly sabotages the 
code-signing system itself, say by subverting the root key, so much the better.

5) Make the private key widely public by posting the private key and the 
code-signing certificate on a H4KOR 51TE, or by other means.  One truly 
wicked possibility is to incorporate the private key and the cert itself as 
part of the malware, creating a self-signing worm.

6) Don't tell Microsoft, or the certificate provider, or anyone else that 
your private key has been "compromised."  For the truly criminal, delete or 
abandon the falsified identity.

Eventually your code-signing certificate will be revoked (we hope).  Until 
that happens and the Certificate Revocation List eventually gets around, 
your malware can go anywhere and do anything.  It is, after all, completely 
authentic and trusted as far as the code-signing process is concerned.  And 
if there's no CRL at all, then your malware can survive until its 
certificate expires or an antidote is released.

There is some monetary cost involved in this attack, but if a group of even 
petty criminals pools their cash, it's basically pocket-change.  And if 
they profit from the attacks in some way, then they can create identities 
and buy keys on the fly, staying ahead of the CRL effectively forever.

This attack shows what happens when one of the main premises inherent in 
the crypto-system is flagrantly violated.  In this case, the intentional 
widespread dissemination of the private key makes everything else in the 
system, including accountability, moot.


From: Phil Pennock <Phil.Pennock@globnix.org>
Subject: On "Code Signing in Microsoft Windows"

There's another way to defeat this.  If a program is signed and running, 
then it's henceforth trusted.  If there's a buffer overrun allowing someone 
to smash the stack, then their code is presumably trusted  --  how would 
Microsoft prevent it?  Stackguard-like technologies go some way towards 
preventing the more trivial attacks, but that's it.

So you have a buffer overrun in, say, an e-mail client.  Given Microsoft's 
history, it isn't far-fetched to suppose that it's the default client which 
Microsoft ships (but then, the same can be said for c-client).  The lack of 
adequate bounds-checking is discovered, someone writes a worm which goes 
around, lugging extra code as needed (e.g., along the lines of Samhain) and 
they disable the checking on the system.  Hey presto ...


From: Leonardo Humberto Liporati <liporati@almg.gov.br>
Subject: Brazilian Voting Machine

The description of the modified PC used in the Brazilian elections has an 
error.  The machine doesn't have a small ballot box attached to it.  So the 
machine doesn't print and slip every vote into the ballot box.  At the end 
of voting the machine only prints some copies of a final report with totals 
by candidate.  This is most criticized "weakness" of the machine; there is 
no way to recount the votes because there are no physical proof of the 
vote, just a digital record on a floppy and in an internal flash memory 
card.  This way the machine fails to achieve the AUDIT attribute, enforced 
by the fact that the modified PC runs a proprietary operating 
system/software whose source code is a commercial secret and can't be 
reviewed.  Also the machine is said to use classified encryption 
software/algorithm developed by ABIN (the Brazilian secret service) that 
isn't available to public review.  This way, when the machine print the 
initial "zero votes" report, no one can be sure that it represents the 
"initial state," just that the software inside it knows how to print such 
report.  There is no way to check/ensure whether the final report (or the 
floppy contents) are the real results or pre-programmed values set by the 
own government.

The machine also fails to achieve the ANONYMITY attribute.  The machine 
holds the name and ID number of each voter of that electoral zone.  Before 
every vote, using the remote control, the operator types the ID number of 
the voter to release the keypad.  As the software is secret, we can't be 
sure that it doesn't record the vote along with the ID of the 
voter.  Another problem is that the machine sounds a beep for every key 
pressed.  Usually a vote is made by typing the candidate's number (2 to 5 
digits) and pressing the "confirm" key, but there is one key for "blank 
vote."  So counting the number of beeps we can easy identify blank votes.

The Brazilian electronic system is far from perfect and receives many 
criticisms by specialists.  The Web site <http://www.votoseguro.org> holds 
a discussion group about it, but it is in Portuguese.


From: Celso Brites <brites@correionet.com.br>
Subject: Brazilian Voting System

In your Cryptogram December 15 proposal for an automated voting system you 
say: "The voter checks the paper ballot for accuracy, and then drops it 
into a sealed ballot box.  The paper ballots are the 'official' votes and 
can be used for recounts, and the computer provides a quick initial tally."

The paper ballot you propose was used in the first Brazilian electronic 
election.  However, it has been abandoned on the elections that followed, 
in order to avoid an old type of electoral fraud, known in Brazil as "Voto 
de Cabresto" (literally translated, "halter vote").  In this fraud, a 
politician (typically a small-town, large property owner) "buys" votes from 
his (usually desperately poor) electorate with promises of small benefits, 
goods, or even cash.  To assure that they will vote as promised, the 
politician uses the following trick: someone in his payroll gets to be the 
first one to vote, but it drops any piece of paper instead of his ballot in 
the box.  He takes the ballot with him and marks it with a small 
handwritten sign.  He then hands it to the first of the politician 
"clients", which is instructed to put the signed ballot in the box and 
bring his own ballot back, thus proving he voted for the "right" 
candidate.  The whole process is then repeated: the new ballot is signed 
and handed to the next "client".

This process could be avoided by using a sealed transparent conduit between 
the machine and the box, so that the voter would not touch the ballot, but 
could check if it was properly printed. For some reason it was not adopted.


From: Todd Hooper <Todd.Hooper@watchguard.com>
Subject: Publishing Security Advisories

I think the spat between Microsoft and Bugtraq is less about the rights of 
the security community, and more about Bugtraq (aka SecurityFocus) 
protecting their income stream from advertising on their portal.  If 
Microsoft don't let them distribute the material, the value of Bugtraq (and 
SecurityFocus) is reduced in some fashion.


From: Jonah Duckles <jduckles@purdue.edu>
Subject: Gianus in the Doghouse

I found your "Doghouse" entry for <http://www.gianus.com> intriguing.  I 
visited their site and found that they were claiming they had full 
technical reports detailing how none of the independent testing agencies 
they had submitted their product to were able to access protected 
information.  The two "technical" reports that I received had descriptions 
that basically were accounts of how good the product seemed to be.  There 
was no technical probing of what kinds of things the product was actually 
doing to "hide" the data.

I contacted the person who had sent me these technical reports again to say 
that I felt the product simply obfuscates the data and does not actually 
provide any security and I received the following e-mail:

      From: "GIANUS TECHNOLOGIES" <gianus@gianus.com>
      To: "Jonah Duckles" <jduckles@purdue.edu>
      Subject: RE: Technical Reviews
      Date: Wed, 24 Jan 2001 13:15:29 -0800

      So, Mr. Duckles, maybe you're the genius we were looking for!!!

      How can you express an opinion about something you have never even seen??

      You are more than welcome to try to retrieve any information we protect
      with the Phantom. ...But what do we get if you cannot???

      There probably is a reason why you are in the academic world, and not in
      the commercial (real) one.

      Best Regards.
      ____________________________________________
      GIANUS TECHNOLOGIES

I guess you have every reason to keep these guys out in the Doghouse, for 
bad security practice AND bad PR.


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

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 _Secrets and Lies_ and 
_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) 2001 by Counterpane Internet Security, Inc.