19 July 1999

                 CRYPTO-GRAM

                July 15, 1999

              by Bruce Schneier
                  President
             Counterpane Systems
           schneier@counterpane.com
          http://www.counterpane.com


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

Back issues are available at http://www.counterpane.com.  To subscribe or
unsubscribe, see below.


Copyright (c) 1999 by Bruce Schneier


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

In this issue:
     The Future of Crypto-Hacking
     News
     Counterpane Systems News
     The Doghouse:  Bungled SSL
     Comments from Readers


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

         The Future of Crypto-Hacking



What is "crypto-hacking"?  As the first person to use the term, I get to
define it.  Crypto-hacking is hacking the mathematics of cryptography; it's
forcing cryptography to do something new, something different, something
unexpected.  It's pushing the boundaries of cryptography.  And it's been
happening regularly over the past several years:

Using information about timing, power consumption, and radiation of a
device when it executes a cryptographic algorithm, crypto-hackers have been
able to break smart cards and other "secure" tokens.  These are called
"side-channel attacks."

By forcing faults during operation, crypto-hackers have been able to break
even more smart cards.  This is called "failure analysis."

In a beautiful display of crypto-hacking, one researcher was able to break
RSA when used in the PKCS format.  The break didn't break RSA, but the way
it was used.  Just think of the beauty: we don't know how to factor numbers
and we don't know how to break RSA.  But if you use RSA in a certain way,
which happens to be a pretty common way, than it is possible in some
systems to break the security of RSA...without breaking RSA.

Crypto-hackers have analyzed many systems by breaking the random number
generators used to supply cryptographic keys.  The cryptographic algorithms
might be secure, but the key-generation procedures were not.  Again, think
of the beauty: the algorithm is secure, but the method to produce keys for
the algorithm has a weakness, which means that there aren't as many
possible keys as there should be.

Researchers have broken cryptographic systems by looking at the way
different keys are related to each other.  Each key might be secure, but
the combination of several related keys can be enough to cryptanalyze the
system.

The common thread through all of these exploits is that they've all pushed
the envelope of what constitutes cryptanalysis.  Before side-channel
attacks, cryptographers never thought about using information other than
the plaintext and the ciphertext to attack algorithms.  After the first
paper, researchers began to look at different side channels, invasive side
channels, attacks based on introducing transient and permanent faults, etc.
Suddenly there was a whole new way to do cryptanalysis. 

Crypto-hacking = cheating.

Several years ago I was talking with an NSA employee about a particular
exploit.  He told the story about how a system was broken; it was a sneaky
attack, one that I didn't think should even count.  "That's cheating," I
said.  He looked at me as if I'd just arrived from Neptune.

Cheating is one of the basic tenets of security engineering.  Conventional
engineering is about making things work.  It's the genesis of the term
"hack," as in "he worked all night and hacked the code together."  The code
works; it doesn't matter what it looks like.  Security is different; it's
about making sure things don't NOT work.  It's making sure security isn't
broken, even in the presence of a malicious adversary who does everything
in his power to make sure that things don't work in the worst possible way
at the worst possible times.  A good attack is one that the engineers never
even thought about.  Good attackers cheat.

And the future of crypto-hacking is the future of cheating.  Clever people
will continue to invent new ways to attack the mathematics of cryptography.

Like any kind of hacking, hacking cryptography requires a specific set of
skills.  The most important cryptographic skill is advanced mathematics;
you can't analyze cryptographic systems without it.  You can't cheat
without it.  You can break systems that use cryptography by going around
the cryptography, but that's not crypto-hacking.  Crypto-hacking means
hacking the cryptography, which means advanced mathematics.  And this
explains why you don't see many crypto-hackers wandering around: the
mathematics is hard.

Most of the crypto-hacking we've seen comes not from disenfranchised
outsiders, but from fringe insiders: graduate students, and some academic
and corporate researchers.  I can't think of one crypto-hacking exploit by
someone with a "handle."  In fact, most of the crypto-hackers get an
amazing amount of positive publicity from their exploits: newspaper
articles, academic papers, accolades.  There isn't much underground
crypto-hacking going on.

There are some crypto-hacking tools, but not many.  There are programs that
take advantage of poor passwords in UNIX and NT, or poor passphrases in
PGP, to break the encryption.  There's a program that tries to break PKZip
encryption, again based on poor password choice.  But there aren't any real
tools that allow for serious crypto-hacking, simply because too much
mathematical expertise would be required to use them.

I don't see this changing in the future.  Cryptography will continue to be
a science of mathematics, and crypto-hacking will necessarily be exactly
the same.  There will be all sorts of cool crypto-hacking exploits, but
it's not going to become a mass-market avocation.


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

                    News

The encrypted message on the CIA's sculpture at Langley:
http://www.abcnews.go.com/onair/WorldNewsTonight/wnt9990615_ciacode.html

Here's a free Java implementation of TLS (the successor to SSL):
http://www.rtfm.com/puretls/

Read the U.S. government position on cryptography in "Encryption: Impact on
Law Enforcement."  The 17-page paper discusses the uses and benefits of
encryption, the downside for law enforcement, the concept of recoverable
encryption (GAK), the Clinton administration's position on encryption, and
current encryption legislation.  Nothing new.
http://sion.quickie.net/en60399.pdf

Someone from the UK wrote a paper, "Possible NSA Decryption Capabilities,"
which outlines a cracking machine NSA might construct.
http://jya.com/nsa-study.htm

Major cluelessness alert.  There are people in the Pentagon ready to give
up on computer security and disconnect from the Internet.
http://sun.soci.niu.edu/~crypt/other/jdripper.htm
For a good analysis of this idiotic idea, read:
http://kumite.com/myths/opinion/discnect.htm

According to federal officials, federal Web sites and computer systems are
particularly vulnerable to outside attacks because they lack two important
elements: adherence to security plans and qualified personnel to maintain
security measures.
http://www.newspage.com/cgi-bin/NA.GetStory?story=h0624132.500date=19990625
&level1=46510&level2=46515&level3=821
http://www.mercurycenter.com/svtech/news/breaking/merc/docs/001859.htm

A bill giving digital signatures legal status passed the Senate Commerce
Committee.
http://www.news.com/News/Item/0,4,38262,00.html

This is an excellent survey paper on discrete logs.  "Discrete logarithms:
The past and the future":
http://www.research.att.com/~amo/doc/crypto.html

China Sees National Security Threat in P3.  Too funny for words:
http://jya.com/cn-p3-peril.htm

The British government plans to give its police and intelligence agencies
new powers to force disclosure of encrypted material used in electronic
commerce:
http://www.techserver.com/noframes/story/0,2294,66202-104800-744684-0,00.html

CERT paper on firewall security issues and best practices.
http://www.cert.org/security-improvement/modules/m08.html

Everyone pile on Microsoft!
http://www.zdnet.com/zdnn/stories/news/0,4586,2290399,00.html

A good example of the kind of fraud you can perpetrate when you can steal
pennies (well, $19.95) from lots of people:
http://www.sciam.com/1999/0899issue/0899cyber.html

There are many definitions of fairness in protocols.  Here's an article on
envy-free protocols:
http://www.newscientist.com/ns/19990717/newsstory9.html

The DefCon Web site was hacked by a group of German hackers who couldn't
afford the air fare to travel to DefCon.
http://www.news.com/News/Item/0,4,38970,00.html

Computers with high-speed modems (cable or DSL) and static IP addresses are
vulnerable to probing attacks from hackers.  (This might be a potential new
market for firewall vendors.)
http://www.nytimes.com/library/tech/99/07/circuits/articles/08hack.html

In last month's News section, I promised to write more about web-based
encrypted e-mail.  That article will be delayed until next month, as I am
still collecting information.



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

         Counterpane Systems News



Bruce Schneier will be giving a one-day cryptography course at two SANS
conferences.  See http://www.sans.org/newlook/home.htm for conference details:

SANS Network Security '99
October 5, 1999, New Orleans, LA

SANS Security San Francisco '99
December 12, 1999, San Francisco, CA

John Kelsey will be speaking at the Sixth Annual Workshop on Selected Areas
in Cryptography (SAC), August 8-10 in Ontario.  Details are at
http://www.engr.mun.ca/~sac99/.

Key-Schedule Cryptanalysis of DEAL

Yarrow-160: Notes on the Design and Analysis of the
      Yarrow Cryptographic Pseudorandom Number Generator

An article on Bruce Schneier's talk at BlackHat in Las Vegas:
http://www.computerworld.com/home/news.nsf/all/9907095crypto


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

         The Doghouse:  Bungled SSL



For most people, SSL is magic security dust that automatically makes your
Web surfing secure.  But it's not that easy.

At onsale.com, you need to register before you can buy things.  The form is
at https://www.onsale.com/atcost/custserv/atregister.htm.  Okay, they're
using IIS, but at least they've got SSL turned on.  You give them your
vitals and credit card info and then send it in.  But if you view the HTML
source, you see:  FORM METHOD="POST" ACTION="http://pecos.onsale.com/..."
They use SSL to deliver the form, but drop back to plaintext to receive the
data.

Verisign uses SSL, but they forgot to secure at least one part of their Web
site: http://www.verisign.com/developers/index.html.  You can click on
several options, and those for obtaining an Authenticode or Object Signing
ID are secure.  But click on the links for the "Free Guide" to Authenticode
or Object Signing, and you'll be entering -- and sending -- your personal
information in the clear, including the required telephone number.

Spree.com, which recently partnered with Barnes and Noble for their online
book sales, uses only 40-bit SSL.  Also, because of the way the frames are
used on their Web page, there is no lock icon on the screen to tell you if
you are using any crypto at all.

BizTravel (http://www.biztravel.com) is the worst offender.  All logons
with ID and password are unencrypted.  Anyone who intercepts that logon can
purchase travel tickets in user's name with the credit card info on file at
BizTravel.  Many such tickets are electronic, so delivery of paper
documents to an address of record isn't an issue.  A query to BizTravel
support elicited this response:  "Your password is encrypted.  In fact, we
at member services, cannot access your password either.  If you lose your
password, we have to assign a temporary password.  We have the option to
use the site under the 'secure server' off of the main menu.  I hope this
eases your concerns regarding using biztravel.com."  I couldn't find the
secure server link at all.


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

          Comments from Readers



From: John Kelsey <kelsey@counterpane.com>
Subject: Internet Malware

The speed of propagation is one threat.  The other is that these macro
viruses can be far more complex than their executable cousins, because if
they only infect large documents, the change in size won't be noticeable.
Why not include a pretty substantial mutation engine within the document,
encrypted and stored to look like valid data?  Or a program to test for
various known security flaws on the internal network, and exploit those it
finds to spread itself?  If your virus can get away with being 500 KB, a
lot of nasty things become possible.  If you're forced to spread on 1.44 MB
floppies, this just isn't acceptable.

One interesting thing about these viruses is that the viruses in question
generally don't need the power to do anything obviously nasty to the system
they're on.  They just have to be able to make use of the e-mail system.
So a lot of standard file-permission type schemes won't do much good, here.
The user who's reading e-mail is almost always authorized to send it out,
as well.  Even on systems like Unix and Win NT with real security built in,
the viruses should spread just fine.

I think the fundamental problem is that people use attachments in e-mail to
exchange data for programs that don't have any security analysis done to
them.  Why should someone designing a freeware PostScript viewer, LaTeX
compiler, JPEG viewer, file decompressor, etc., have spent a lot of time
worrying about security holes?  But an attacker can reasonably look at
those programs for security holes.

There is a whole class of network attacks that are basically attempts to
use network services, provided to the outside world, to compromise the
machines providing those services.  I think of these e-mail attachment
attacks as very closely related to those attacks.  The problem is that by
allowing e-mail attached Excel spreadsheets, we're more-or-less making
Excel a network service, like NFS or FTP.

You can send data into it from off the targeted machine.  It will act on
the data and can even send you something back.  It doesn't matter whether
the data you send and receive is sent one packet at a time or one e-mail
message at a time.

Of course, this is disastrous for security, because Excel and Word and a
zillion other single-user programs are simply not designed to be secure
when fed data from a malicious source.  The macro virii aren't all that
hard to resist -- simply making all programs require a user-prompt before
executing macros will go a long way in that direction.  A much scarier
thing is there are almost certainly subtle bugs in Word or Excel that
involve formatting the file oddly, so as to cause a buffer overflow, or to
cause some other odd behavior.

For operating systems with some kind of security built in (e.g., not
Windows 95 or 98), it would be ideal to be able to open attachments, by
default, in a kind of chroot-like environment.  This would not only
restrict changes to a specific subdirectory, but would also refuse to allow
any communications with the outside world.  Probably, this wouldn't be hard
to set up in an operating system with user permissions and such.

Attachments in e-mail essentially create a whole new set of Internet
services, running on the user's machines.  The attachment in the e-mail is
a message to some program that nobody thinks of as a network service --
like Excel, Word, or the DOS/Windows command line.  Nobody *thinks* of it
as a network service, but if it accepts data from untrusted sources on the
net, acts on it, and maybe even responds to it, then it *is* a network
service, at least in the security sense -- attackers ought to be looking at
it as a reasonable point of attack, looking for buffer overflows and such.
The fact that a human user has to intervene to open attachments is helpful,
but they can obviously be fooled.

Every application you run on your machine that can be executed by opening
an attachment is now a kind-of network service.

One defense is to is to limit the kinds of attachments that can be sent
through the firewall, or that can be opened by the e-mail program.  If only
applications without macro abilities may be used to open attachments, this
can provide some protection.  (There could eventually be command-line
options for things like Word and Excel turning off macro execution
entirely; those options would be included in the mail system's call to
those programs.  Other "network services" would be turned off entirely.)


From: Peter Low <peterlow@fletcherspaght.com>
Subject: Microsoft and security

I attended a Microsoft smoke and mirrors show in Boston (promoting their
DNS "concept") shortly after Melissa had made the rounds.  At the end of
the show, Bill Gates fielded questions from the audience.  When it was my
turn, I pointed out that Microsoft has simplified computing to the point
where it can be pushed to the masses, but, at the same time, Microsoft has
put a burden on the masses to protect themselves from malware.  The users
who don't know much about how computers work are being asked to decide
whether or not to allow files with scripts to be run when they open them.
I asked Mr. Gates what commitment Microsoft was going to make to improving
security for users of Microsoft products. 
His answer was less than satisfying.  He stated that the option of asking
users whether or not to enable macros when they open a file is a good first
line of defense because they can decide whether they trust the person who
gave them the file.  (Gee, I've never received an infected file from
someone I trust.  Also, you can turn the option off.  Also, a lot of novice
users will enable macros because they don't understand the danger.)  He
then talked about the potential for automating the procedure through the
use of digital signatures.  (Gee, I bet that will be much more
effective...)  I was left with the impression that things will get a lot
worse before they start to get better.

Maybe Microsoft could include fields in their database of user information
(tied to your Ethernet address) showing whether or not you are infected
with various strains of virii or other malware, then allow users to check
the database before accepting files from other users -- I bet they could
make a lot of money from that service.

I work for a consulting firm, and, unfortunately, I need to use Office so
that I can share files, often containing macros, with clients.  I have no
way of knowing what precautions my clients take with regard to malware, and
feel I am put at risk due to poor software design from Microsoft.  Bummer.
At least I don't have to use Outlook.


From: Bruce McNair <bmcnair@research.att.com>
Subject: Various

Regarding data-borne diseases:  Actually, as much as I'd like to bash
Microsoft, they weren't the first.  When Bob Morris' Internet Worm was
making the rounds about 10 years ago and when the missing semicolon brought
down Signalling System 7, we were hypothesizing about the possibility of
data-borne viruses.  I found a neat feature of troff that allows you to
make a call to a UNIX shell, which would make a virus or worm much easier
to create.  I don't know how long before we saw it that this nice feature
was there, but I can imagine that it's been a while.

Regarding automata modelling natural immune systems:  I wouldn't bank on
this one.  The natural immune system is effective in the long term because
it protects the group at the possible expense of the individual.  Sure,
it's unfortunate if you happen to die of pneumonia, but if you happen to
live, you and your descendents may have a better long term chance.  It's a
little hard to imagine using a secure cooperative distributed computing
system that allows individual systems (i.e., users' terminals) to be
compromised without really bothering the user whose system is down.
Besides, the patient stealthy viruses are able to do a number on the
distributed immune system, even after millions of years of development.  In
the long run, I'll bet on the virus. :-)

Regarding Mr. Hewlett's comments about consumer credit card liability:
Credit card laws in the USA are greatly in favor of the consumer, but there
are limitations.  (E.g., these regulations do not apply to "virtual checks"
or debit card transactions.)  In general, retailers bear the major burden
of credit card fraud.

Consumers are generally liable for the first $50 of fraud, but card issuers
handle this differently.  Since Novus (DiscoverCard) and American Express
directly control both the merchant and cardmember relationships, they are
more likely to pursue matters to resolution.  American Express has
consistently resolved every dispute I've raised without the $50 liability.

Card associations like Visa and MasterCard are more loosely coupled, with
different companies "owning" the cardmembers, merchants, and card
processing functions.  More effort is required on their part to resolve
disputes and in my experience they are more likely to enforce the $50
liability.  Interestingly, this can amount to inaction in the event of
sporadic fraud.  Someone I know was stuck with the task of independently
contacting the merchant and disputing a fraudulent $49.95 recurring charge
(just under the $50 cutoff).

On the merchant front, the risk is _huge_ for accepting a fraudulent card.
In addition to losing the product to thieves, the transaction is reversed
(minus the transaction fees paid to the bank), and the merchant is hit with
a "chargeback" fee of $20 or more.  Normally the merchant has two weeks to
respond to a dispute; if their dispute ratio is high enough, the merchant
automatically waives their right to challenge disputes -- the merchant is
presumed wrong until evidence to the contrary is presented (i.e., funds are
immediately deducted from their account).

Merchants do have some defenses, but they aren't great.  They must get a
credit card authorization code and perform a (crude) address verification.
Ideally, the shipment should require a signature for release, providing the
necessary documentation for the transaction -- even this may not be
adequate to support a merchant's case (since anyone can sign for the
shipment).  Ultimately, Internet retailers are left on their own to add
other tools to detect abnormal and fraudulent behavior.

Of course, these facts overlook what the "general public" is concerned
with: encrypting the data between client and server.  Curiously, this is
probably the least likely place for a theft.  (A more valuable function of
SSL is actually the identification aspect -- it ensures that a site has
some degree of legitimacy and that the URL hasn't been hijacked.

IMO, encrypting the data transfer between client and server is probably the
least of security concerns, due to the access and technology required to
steal data.  The larger risk is how the merchant secures data once it's
stored on the destination host.  Crackers have stolen 10,000's of credit
card numbers in well-publicized cases by breaking into Internet servers;
it's far easier, considering the number of servers and OS security holes.

In summary, consumers are legally protected -- more than most think.
Retailers are at a much higher risk than many realize.  SSL is very
valuable, but not for the reasons people generally think.  And the general
public's not paying any attention to the real threat -- how merchants
secure their data files.


From: Paul Holman <pablos@fortnocs.com>
Subject: Who's at risk?

While technically what you say is accurate, you must have never experienced
credit card fraud first hand.  For most people the inconvenience caused by
this is worth weighing.  You have to notify your card issuer, provide
documentation, destroy your card, and wait for a new one.  Yeah you're only
liable for a maximum of $50, but it could cost you hundreds in time.

Credit card fraud worldwide is estimated at US$10B annually.  Banks don't
brag about this, they try to keep it under wraps so you feel like it isn't
risky to use your credit card.  That money has to come from somewhere.
Directly or indirectly, the savings is being passed on to you.

Sadly, to implement secure protocols requires the cooperation of everyone
involved.  This means both the merchant and the consumer.  Our job in the
security industry is to try to make communication as secure as possible,
and part of doing that is to make it convenient to use.


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

CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on cryptography and computer security.

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 president of
Counterpane Systems, 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 cryptography.

Counterpane Systems is a six-person consulting firm specializing in
cryptography and computer security.  Counterpane provides expert consulting
in: design and analysis, implementation and testing, threat modeling,
product research and forecasting, classes and training, intellectual
property, and export consulting.  Contracts range from short-term design
evaluations and expert opinions to multi-year development efforts.
http://www.counterpane.com/

Copyright (c) 1999 by Bruce Schneier