17 June 1999
CRYPTO-GRAM
June 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:
E-Mail Viruses, Worms, and Trojan Horses
Counterpane Systems -- Featured Research
News
Counterpane Systems News
The Doghouse: Shopping.com
The Other Doghouse: ChecksNet
Hacking Archives on the WWW
International Encryption Policy
International Encryption Products
Comments from Readers
** *** ***** ******* *********** *************
E-Mail Viruses, Worms, and Trojan Horses
Looking back from the future, 1999 will have been a pivotal year for
malicious software: viruses, worms, and Trojan horses (collectively known
as "malware"). It's not more malware; we've already seen thousands.
It's
not Internet malware; we've seen that before, too. But this is the
first
year we've seen malware that uses e-mail to propagate over the Internet and
tunnel through firewalls. And it's a really big deal.
Viruses and worms survive by reproducing on new computers. Before the
Internet, computers communicated mostly through floppy disks. Hence,
most
viruses propagated on floppy disks, and sometimes on computer bulletin
board systems (BBSs).
There are some obvious effects of floppies as a vector. First,
malware
propagates slowly. One computer shares a disk with another which shares
a
disk with five more, and over the course of weeks or months a virus turns
into an epidemic. Or maybe someone puts a virus-infected program on
a
bulletin board, and thousands get infected in a week or two.
Second, it's easy to block disk-borne malware. Most anti-virus
programs
can automatically scan all floppy disks. Malware is blocked at the
gate.
BBSs can still be a problem, but many computer users are trained never to
download software from a BBS. Even so, anti-virus software can
automatically scan new files for malware.
And third, anti-viral software can easily deal with the problem. It's
easy
to write software to block malware you know about. You simply have
the
anti-virus scanner search for bit strings that signify the virus (called
a
"signature") and then execute the automatic program to delete the virus and
restore normalcy. This deletion routine is unique per virus, but it
is not
hard to develop. Anti-viral software has tens of thousands of
signatures,
each tuned to a particular virus. Companies release them within a day
of
learning of a new virus. And as long as viruses propagate slowly, this
is
good enough. My software automatically updates itself once a month.
Until
1999, that was enough.
What's new in 1999 is e-mail propagation of malware. These programs
-- the
Melissa virus and its variants, the Worm.ExploreZip worm and its inevitable
variants, etc. -- arrive via e-mail and use e-mail features in modern
software to replicate themselves across the network. They mail
themselves
to people known to the infected host, enticing the recipients to open or
run them. They don't propagate over weeks and months; they propagate
in
seconds. Anti-viral software cannot possibly keep up.
And e-mail is everywhere. It runs over Internet connections that
block
everything else. It tunnels through all firewalls. Everyone uses
it.
It's easy to point fingers at Microsoft. Melissa uses features in
Microsoft Word (and variants use Excel) to automatically e-mail itself to
others, and Melissa and Worm.ExploreZip make use of the automatic mail
features of Microsoft Outlook. Microsoft is certainly to blame for
creating the powerful macro capabilities of Word and Excel, blurring the
distinction between executable files (which can be dangerous) and data
files (which, before now, were safe). They will be to blame when
Outlook
2000, which supports HTML, makes it possible for users to be attacked by
HTML-based malware simply by opening an e-mail. Microsoft set the
security
state-of-the-art back 25 years with DOS, and they have continued that
legacy to this day. They certainly have a lot to answer for, but the
meta-problem is more subtle.
One problem is the permissive nature of the Internet and the computers
attached to it. As long as a program has the ability to do anything
on the
computer it is running on, malware will be incredibly dangerous. Just
as
firewalls protect different computers on the same network, we're going to
need something similar to protect different processes running on the same
computer.
This cannot be stopped at the firewall. This type of malware tunnels
through a firewall using e-mail, and then pops up on the inside and does
damage. So far the examples have been mild, but they represent a proof
of
concept. And the effectiveness of firewalls will diminish as we open
up
more services (e-mail, Web, etc.), as we add increasingly complex
applications on the internal net, and as crackers catch on. This
"tunnel-inside-and-play" technique will only get worse.
And anti-virus software can't help much. If a virus can infect 1.2
million
computers (one estimate of Melissa infections) in the hours before a fix
is
released, that's a lot of damage. What if the code took pains to hide
itself, so that a virus won't be discovered for a couple of days? What
if
a worm just targeted an individual; it would delete itself off any computer
whose userID didn't match a certain reference? How long would it take
before that one is discovered? What if it e-mailed a copy of the
user's
login script (most contain passwords) to an anonymous e-mail box before
self-erasing? What if it automatically encrypted outgoing copies of
itself
with PGP or S/MIME? Or signed itself; signing keys are often left
lying
around the system. Even a few minutes of thinking about this yields
some
pretty scary possibilities.
It's impossible to push the problem off onto users with "do you trust this
message/macro/application" messages. Sure, it's unwise to run
executables
from strangers, but both Melissa and Worm.ExploreZip arrive pretending to
be friends and associates of the recipient. Worm.ExploreZip even
replied
to real subject lines. Users can't make good security decisions under
ideal conditions; they don't stand a chance against a virus capable of
social engineering.
What we're seeing here is the convergence of several problems: the
permissiveness of networks, interconnections between applications on modern
operating systems, e-mail as a vector to tunnel through network defenses
and as a means to spread extremely rapidly, and the traditional naivete of
users. Simple patches won't fix this. There are some
interesting
technologies on the horizon that try to mimic the body's own immune system
to automatically deal with unknown malware, but I am not very optimistic
about them. Sure they'll catch some things, but it will always be
possible
to design malware specifically to defeat the immune systems. A large
distributed system that communicates at the speed of light is going to have
to accept the reality of viral infections at the speed of light.
Unless
security is designed into the system from the bottom up, we're constantly
going to be fighting a holding action.
Melissa:
http://www.zdnet.com/zdnn/stories/news/0,4586,2233116,00.html
http://www.zdnet.com/zdnn/stories/news/0,4586,2234121,00.html
Worm.ExploreZip
http://www.zdnet.com/zdnn/stories/news/0,4586,2274306,00.html
http://www.wired.com/news/news/politics/story/20160.html
http://www.symantec.com/press/1999/n990614d.html
** *** ***** ******* *********** *************
Counterpane Systems -- Featured Research
"Protecting Secret Keys with Personal Entropy"
C. Ellison, C. Hall, R. Milbert, and B. Schneier, FUTURE GENERATION
COMPUTER SYSTEMS, to appear.
Conventional encryption technology often requires users to protect a secret
key by selecting a password or passphrase. While a good passphrase will
only be known to the user, it also has the flaw that it must be remembered
exactly in order to recover the secret key. As time passes, the ability
to
remember the passphrase fades and the user may eventually lose access to
the secret key. We propose a scheme whereby a user can protect a secret key
using the "personal entropy" in his own life, by encrypting the passphrase
using the answers to several personal questions. We designed the scheme
so
the user can forget answers to a subset of the questions and still recover
the secret key, while an attacker must learn the answer to a large subset
of the questions in order to recover the secret key.
http://www.counterpane.com/personal-entropy.html
** *** ***** ******* *********** *************
News
Hushmail is like Hotmail, but encrypted. They implement SSL from the
browser to the server, and Blowfish to encrypt messages. Free secure
e-mail for the masses. Their source code is available via free
download.
Furthermore, they developed their product off-shore, so they don't face any
export restrictions. I haven't seen any evaluations of the code, but
it's
certainly a good idea.
News story:
http://www.wired.com/news/news/email/explode-infobeat/technology/story/19804.html
Hushmail homepage:
http://www.hushmail.com
Technical summary:
https://www.hushmail.com/tech_description.htm
Source code:
http://www.cypherpunks.ai/~hush/hush-src.103.zip
And ZipLip is a competing secure web e-mail service:
http://www.techweb.com/wire/story/TWB19990526S0002
I'll write more about both of these products next month.
The French data agency CNIL is investigating Microsoft and Intel, to
determine if their anti-privacy antics violates any European data
protection laws.
http://www.europa.eu.int/comm/dg15/en/media/dataprot/wpdocs/wp16en.htm
http://www.europa.eu.int/comm/dg15/en/media/dataprot/wpdocs/wp17en.htm
A report on how 128-bit crypto was liberated in France.
http://jya.com/jospin-coup.htm
The United States has been accused using key-escrow to steal secrets.
http://www.techweb.com/wire/story/TWB19990518S0004
http://www.nytimes.com/techweb/TW_Report_U_S_Uses_Key_Escrow_To_Steal_Secrets.html
How to discuss Blowfish with your children.
http://www.hcs.harvard.edu/~demon/issues/apr_26_1999/blowfish/blowfish.html
There are rumors that the CIA is using computers to attack the foreign bank
accounts of Yugoslav leader Milosevic.
http://www.techweb.com/wire/story/reuters/REU19990524S0001
"We've lately had reason to wonder if our nation's cryptography policy is
being made by fools. It is a mixed blessing to learn that the people
in
charge are merely liars." A good editorial.
http://www.zdnet.com/pcweek/stories/columns/0,4351,403283,00.html
OpenSSL, an open-source toolkit for SSL and TLS, version 0.9.3 has been
released.
http://www.openssl.org/
Here's a site that provides random primitive and irreducible polynomials,
useful for stream-cipher construction.
http://www.dmi.ens.fr/~chabaud/Poly/polyform.html
U.S. banks are opening a lab to test computer security products.
http://www.news.com/News/Item/0,4,36923,00.html
The Electronic Telegraph has an interesting feature on the security of
safes: how they're made, how they can be attacked. I never realized
that
safes were rated according to how much insurance you can get on cash
contents.
http://www.telegraph.co.uk:80/et?ac=000647321007942rtmo=Q9QwSezR&atmo=99999999&pg=/et/99/5/13/ecfsafe13.html
Good news department: The U.K. has reversed its position on key
escrow.
Blair's government has dropped a proposal that would have required it.
http://www.infoworld.com/cgi-bin/displayStory.pl?990527.icblair.htm
Someone wrote an Enigma-machine simulator that runs on an iButton.
So you
can have an Enigma-machine secret decoder ring.
http://www.javaworld.com/jw-08-1998/jw-08-indepth.html
The National Security Study Group (some government agency or another)
launched a web site
(http://www.nssg.gov)
to encourage and gather public
comment on national security in the 21st century. Be nice and don't
hack
them for a week or so.
http://www.fcw.com/pubs/fcw/1999/0531/fcw-agsitesurv-05-31-99.html
Send secret messages in DNA.
http://news.bbc.co.uk/hi/english/sci/tech/newsid_365000/365183.stm
http://news.excite.com/news/r/990610/02/science-dna-microdot
http://www.cnn.com/NATURE/9906/10/top.secret.dna.ap/
CGHQ, the British NSA-equivalent, is moving. Their new site will
house
4500 people, and should be completed by 2002.
http://www.guardianunlimited.co.uk/Archive/Article/0,4273,3862710,00.html
Germany goes on record as being in favor of strong cryptography. It
seems
they don't trust the U.S. not to spy on them.
http://www.wired.com/news/news/politics/story/20023.html
** *** ***** ******* *********** *************
Counterpane Systems News
The Black Hat Briefings '99 is a Computer Security Conference scheduled for
July 7 and 8 in Las Vegas, Nevada. DefCon is a hackers convention held
the
weekend after. Bruce Schneier will be speaking at both.
http://www.blackhat.com/
http://www.defcon.org/
** *** ***** ******* *********** *************
The Doghouse: Shopping.com
For security-clueless shopping, you can't beat this one:
"Shopping.com
uses RSA Laboratories commercial encryption suited for U.S. export
(RC4-Export, 128 bit with 40 secret). What does that mean to you?
RSA
protects your sensitive communications over the Internet (such as a credit
card number) by transforming the data into an unreadable format.
Furthermore, Shopping.com ensures the privacy of the information not only
online, but through our back-end systems." Wow. I am in awe.
http://www.shopping.com/store/INFO/INFO_SECURE.ASP?nav=|-1|-1|-1|-1|-1x=cgi-bin
** *** ***** ******* *********** *************
The Other Doghouse: ChecksNet
You too can send your bank account name and routing information in the
clear over the net. Order your checks from these people. Their
Web page
clearly states: "ChecksNet protects your personal and bank account
information from theft or misuse by encoding and scrambling the data as it
is transmitted from this website to us." However, the order form is
sent
in the clear; they don't use SSL.
http://www.checksnet.com/order.htm
** *** ***** ******* *********** *************
Hacking Archives on the WWW
There's a lot of hacking information on the WWW, but you have to take the
time to look for it. Typing "hacker archive" into AltaVista results
in
over three million hits. Yahoo's information is much better organized,
but
there's still a lot of pages to wade through.
A great starting site is
http://www.infoworld.com/cgi-bin/displayNew.pl?/security/links/security_corner.htm.
These guys write a weekly security column for InfoWorld, and their
site is a wealth of useful security links. When I'm looking for something,
I usually go there first.
The content site I spent the most time at was
http://www.genocide2600.com/~tattooman/main.shtml,
because it seemed
well-organized. Nevertheless, it was clear that this is an archive,
not a
directory. If you're trying to find a particular hack for a
particular
piece of software on a particular operating system, expect to spend some
time searching. The material is sorted by general category, but the
descriptions are limited. On the other hand, if you're looking for
write-ups of the latest security holes and exploits, it's neatly sorted by
date.
For a non-hacker like me, most of this material is way beyond my level of
expertise. Still, there's also a fair amount of scary and useful
stuff.
Just reading through the archive descriptions is enough to make anyone lose
faith in any kind of network security. In addition to the
vulnerabilities
and exploits, there are Windows, Novell, and Unix security tools; password
crackers; miscellaneous hacking tools; general utilities; and -- just in
case you'd forgotten that hacking was a subculture -- humor archives.
There are also links to archives of hacker discussion lists.
Other archives include:
The Electronic Frontier Foundation "hacker" archive.
http://www.eff.org/pub/Net_culture/Hackers/
The archives for 2600 Magazine and for Phrack Magazine.
http://www.2600.com
http://www.phrack.com
And Netscape's hacker page, with links to major hacker sites on the Web.
http://excite.netscape.com/computing_and_internet/programming/hacking
This last one is the Web page I found most interesting, in the abstract.
Hacking has come of age, if Netscape lists the links openly, instead of
trying to pretend they don't exist. In general, hackers (at least in
their
public face) are more interested in penetrating systems and exposing
vulnerabilities than in causing damage or stealing money. But most
sites
are still have legal disclaimers about how the information is only for
educational purposes and is not intended to be used to commit the crimes
that could be attributed to the information provided. First amendment
or
not, much of this is a gray area.
** *** ***** ******* *********** *************
International Encryption Policy
EPIC has released its "Cryptography & Liberty 1999: An International
Survey
of Encryption Policy." This is an excellent survey on international
encryption policy (it runs about 130 pages), produced by the Electronic
Privacy Information Center (EPIC).
Here's the executive summary:
"Most countries in the world today have no controls on the use of
cryptography. In the vast majority of countries, cryptography may be
freely used, manufactured, and sold without restriction. This is true
for
both leading industrial countries and for developing countries. There
is a
movement towards international relaxation of regulations relating to
encryption products, coupled with a rejection of key escrow and recovery
policies. Many countries have recently adopted policies expressly
rejecting requirements for key escrow systems and a few countries, most
notably France, have dropped their escrow systems. There are a small
number of countries where strong domestic controls on the use of
cryptography exist. These are mostly countries where human rights
command
little respect.
"Recent trends in international law and policy point toward continued
relaxation of controls on cryptography. The Organization for Economic
Cooperation and Development's Cryptography Policy Guidelines and the
Ministerial Declaration of the European Union, both released in 1997, argue
for the liberalization of controls on cryptography and the development of
market-based, user driven cryptography products and services. There
is a
growing awareness worldwide of encryption and an increasing number of
countries have developed policies, driven by the OECD guidelines.
"Export controls remain the most powerful obstacle to the development and
free flow of encryption. The revised December 1998 Wassenaar
Arrangement
may roll back some of the liberalization sought by the OECD, particularly
by restricting the key lengths of encryption products that can be exported
without approval licenses. However, several major countries have
already
indicated that they do not plan to adopt new restrictions.
"The United States government continues to lead efforts for encryption
controls around the world. The U.S. government has exerted economic
and
diplomatic pressure on other countries in an attempt to force them into
adopting restrictive policies. The U.S. position may be explained,
in
part, by the dominant role that national intelligence and federal law
enforcement agencies hold in the development of encryption policy."
http://www2.epic.org/reports/crypto1999.html
** *** ***** ******* *********** *************
International Encryption Products
The ACP has commissioned a study on the availability of international
encryption products. It's called "Growing Development of Foreign
Encryption Products in the Face of U.S. Export Regulations."
Here are excerpts from the executive summary:
"Development of cryptographic products outside the United States is not
only continuing but is expanding to additional countries; with rapid growth
of the Internet, communications-related cryptography especially is
experiencing high growth, especially in electronic mail, virtual private
network, and IPsec products. This report surveys encryption products
developed outside the United States and provides some information on the
effect of the United States export control regime on American and foreign
manufacturers.
"We have identified 805 hardware and/or software products incorporating
cryptography manufactured in 35 countries outside the United States.
The
most foreign cryptographic products are manufactured in the United Kingdom,
followed by Germany, Canada, Australia, Switzerland, Sweden, the
Netherlands, and Israel in that order. Other countries accounted for
slightly more than a quarter of the world's total of encryption products.
"The 805 foreign cryptographic products represent a 149-product increase
(22%) over the most recent previous survey in December 1997. A majority
of
the new foreign cryptographic products are software rather than hardware.
Also, a majority of these new products are communications-oriented rather
than data storage oriented; they heavily tend towards secure electronic
mail, IP security (IPsec), and Virtual Private Network applications.
"We identified at least 167 foreign cryptographic products that use strong
encryption in the form of these algorithms: Triple DES, IDEA, Blowfish,
RC5, or CAST-128. Despite the increasing use of these stronger
alternatives to DES, there also continues to be a large number of foreign
products offering the use of DES, though we expect to see a decrease in
coming years.
"On average, the quality of foreign and U. S. products is comparable. There
are a number of very good foreign encryption products that are quite
competitive in strength, standards compliance, and functionality."
http://www.seas.gwu.edu/seas/institutes/cpi/library/docs/cpi-1999-02.pdf
** *** ***** ******* *********** *************
Comments from
Readers
From: "John C. Kennedy" <transmog@worldnet.att.net>
Subject: Novell
Having worked with Novell's security group closely for the last three and
a
half years on cryptographic and network security issues, I want to point
out a couple of things that aren't quite apparent about the remote console
password encryption hack that you report on in your latest newsletter.
(Disclaimer: This is in no way an official response from Novell, merely a
constructive comment by an informed party.)
The use of the remote console feature for managing NetWare servers is
something that Novell has advised against for quite some time to begin
with. Server console access is something that Novell strongly
recommends
be protected by physical access restrictions:
http://developer.novell.com/research/appnotes/1997/november/06/04.htm
Novell's security experts have *always* considered the use of remote
console capabilities to be a fundamentally risky proposition to begin with.
Console access allows direct access to the NetWare trusted computing base.
However, when customers demand such a feature and are willing to take the
risk it is difficult for any company to say no.
If one assesses network security from a "weakest link in the chain"
perspective, it is the fact that access to console services is available
remotely *at all* that is probably a bigger risk than the weak password
encryption technique employed. Console access is not something that
should
be granted based simply on single factor authentication, but in many "low
threat" environments this is an acceptable risk/convenience trade-off to
make.
The password obfuscation technique may seem amateurish at first glance, but
it most likely has more to do with some exportability issue than lack of
expertise or knowledge within Novell's security group. The design
pre-dates my association with Novell by a couple of years, but I am
confident that it was not due to ignorance within the security staff.
Obfuscation techniques are not something anyone likes to bet the farm on,
and Novell's strong caveats about the use of rconsole reflects this.
Novell has been working for the last couple of years on an architecture to
permit strong encryption for authentication purposes without allowing that
same capability to be exploited as an uncontrolled method for
confidentiality. This is not an easy problem to tackle, but Novell's
new
international cryptographic services architecture in fact solves this
"crypto with a hole" problem for both Novell and its customers.
(http://www.novell.com/corp/security/)
Regardless of one's position on the crypto export issue, we all know that
this has been a real problem for software and hardware vendors for quite
some time. It is especially difficult to solve for companies that ship
to
so many different import/export jurisdictions. U.S. export laws are
matched by equally restrictive import laws in many countries. The
ability
to field policy-controlled crypto will allow Novell to bring new network
security mechanisms to the global market based on cryptography that is
"strong" by anyone's measure.
I think your chastising of Novell is well-intentioned, but fails to
acknowledge that, (1) weak cryptography *is not* always the weakest link
in
the security chain and (2), that import/export laws have had predictable
and, to date, largely unavoidable results in software designs destined for
global markets. So-called "strong cryptography" can lend a false sense
of
security or be otherwise counterproductive when viewed in the larger
context that many vendors have to address. A context that, in fact,
most
casual observers have neither the patience or necessary intimate knowledge
to address.
From: "Robert A. Lerche" <ral@msbit.com>
Subject: Microsoft's Internet Explorer
MS IE does not provide a means for encrypting downloaded personal
certificates. Netscape prompts for a password and encrypts local
storage
(although I think you're allowed to specify a blank password), but MS IE
doesn't.
From: "Jack Hewlett" <jackhewlett@hotmail.com>
Subject: Who's at risk?
You continually publish articles saying how bad various security software
products are. So the obvious question is, "Who's at risk here, the
Retailer or the Consumer?" I've never understood the need to be
secretive
about my Credit Card Numbers. It seems to me, I could publish my
Credit
Card number in the newspaper, and "I" would not be at any risk!
If a charge appears on my monthly statement and I can show the following:
1. The merchandise was NOT shipped to my address.
2. The Retailer does NOT have a piece of paper containing my signature.
3. The Retailer does NOT have a recording containing my voice.
then surely I'm under no legal obligation to pay that portion of the bill.
This is a very important topic for the individual. If all the risk
associated with weak security software falls on the Retailer, then I don't
have to care about this topic.
If my suppositions are incorrect, then how do I protect myself against all
the clerks who see my Credit Card Number when I use it in a retail
establishment? I understand that I have legal obligations to report
a card
stolen when I no longer have physical possession of it. But, since
it is
impossible for me to control knowledge of the Number (and Expiration Date),
can the "fine print" of the Credit Acceptance I signed hold me fiscally
responsible for something I can't control? Even if I did sign such
terms,
would they hold up in court, when I argue that I did nothing wrong and
acted in a prudent manner?
From: Geoff Thorpe <geoff@raas.co.nz>
Subject: Hacking root CAs in Internet Explorer
I note my mate Peter Gutmann's email about substituting root CAs into IE's
"certificate store". I think I actually alerted him to this, and the
problem remains in more recent versions. IE Version 4 also registers
the
".der" file extension so that an ASN encoded self-signed X509 CA
certificate saved as cert.der and double-clicked will automatically launch
the "Accept new CA cert?" dialog of IE. By default, all the options
are
enabled (ticked), including authenticating client and server certs (https),
authenticating email certs (S/MIME), and software signing (Authenticode).
Even the default button is "OK," so hitting enter is enough. They
have,
however, added a new dialog box, so that selecting OK gives a quick "Are
you sure" type warning, displays all the information about the cert
(distinguished name components, expiry dates, etc.) and the default button
in this case is "No" (you have to click Yes to accept it). This still
does
not address the fact that most users will not really grasp the gaping
security hole this creates for them -- though at least Netscape
Communicator goes some way towards letting them know you REALLY should
check up on the cert's authenticity before giving it too much trust -- and
they have a neat option to always provide warnings when using certs signed
by the new CA cert in question.
There's a very dangerous attack permitted by this lax attitude towards
accepting CA certs. If you can get anyone with an Authenticode signing
key
(perhaps a developer has a signed cert from Verisign or whoever) to accept
a phony CA cert, then all hell can break loose. You can then get
native
code in a signed .cab file (signed with a cert that is signed from the
phony CA) onto the developer's machine (it's now trusted, so they will not
be given warnings -- and depending on their settings, they may not even be
*told anything*). That native code can use MS's CryptoAPI to retrieve
the
developer's Authenticode private key (in typical fashion, the API does not
require a password to retrieve the key) and mail it out to the hacker.
That hacker then has someone else's code-signing cert and key. Using
it,
they can put signed viruses around, and provide signed hacked versions of
software (perhaps providing a "mirror" of popular software all of which is
really just dressed-up and highly creative "fdisk" variations) -- and if
law enforcement ever get involved, their only lead will be the unfortunate
developer's Authenticode cert. Of course, if the hacker can plant phony
CA
certs around everywhere, he/she can always just create their own phony
CA-signed Authenticode certs (perhaps named "Microsoft Corp.") and use
those. But the point being illustrated here is that the hacker only
needs
to get the phony CA into *one* developer's machine (not everybody they want
to hack); after that, he/she has someone else's digital identity with which
to wreak havoc.
But this brings me around to an issue I had been wanting to mention, and
relates to a background project of mine. Microsoft has its own
cert-trust
settings, store, and API (if any at all); so does Netscape, so does any
S/MIME-enabled mailer, so does any secure tunneling utility, etc. etc.
Not
only has this led to a complete decentralisation (it's pretty much
"per-application") on a user's system as to his/her "trust" settings, it
has also led to the inevitable incompatibilities of standards -- just ask
anyone working for a CA about processing cert-requests for IE (and each
version thereof), Navigator, and the popular web-servers. They're all
various mutations and modifications of ASN, X509, PEM, and MIME that give
massive headaches for anyone who wants to dream of cross-compatibility (as
of now, I don't know anyone who has managed to make a single user-cert
(with private key) work on Communicator and IE simultaneously).
My idea had been loosely termed the "PKI kernel" -- a core library and
interface that is presumed present and callable on all systems being
compiled and deployed. Unlike the proliferation of various PKI toolkits
using various standards (PKIX, etc.) and proprietary interfaces, I wanted
to just put the minimum necessary core in to allow some centralisation --
and to ensure it was thin enough that it did not impose functional
restrictions on applications using it. E.g., I was thinking that this
should not be a "provider plug-in" architecture, as its very benefit would
come from it being singular and ubiquitous on a system. It would not
provide any cryptographic tools (ciphers, PKC encryption, etc.), and it
would not provide any services (SSL tunneling, SSH, etc.) -- it would
simply be a way to centralise root certs, user certs, pending
cert-requests, and private keys, and maintain policies as to their use.
At
its most rudimentary, it could just be a free-for-all cert repository.
At
its more refined, it could be a strict framework where a root-user has
stipulated that policies are inherited from another system and that only
certain certs can be used for certain things. E.g., an app can ask
the
core for a list of "user certs" for use with "https" or check if a
particular CA cert is trusted for a certain task, the policy could
stipulate that any signed (user) certs imported into the core for use with
S/MIME must be at least 1024 bits and signed by the "X" CA, etc.
It just seems that each operating system has one concept of "print
management", or "the TCP/IP stack", etc., and yet every single
crypto-enabled program seems to have its own concept of trusted root certs,
cert-policies, key-usages, and all the incompatibilities that come with
them. They all use the same "protocols" (SSL/TLS, S/MIME, etc.), and
they
all use the same "algorithms" (RC4, RSA, etc.), because everyone sensibly
agrees that it's best to just get one standard right than many different
standards simultaneously, yet it's often overlooked that authenticity and
identification depend very much on the careful and coordinated handling of
certification, which every application seems to want to have its own
individual poke at.
** *** ***** ******* *********** *************
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