Network Defense
by Rik Farrow

Public Key Infrastructure done right

There is a lot of buzz today surrounding PKI (public Key Infrastructure).
Like other areas, there is also a lot of fear, uncertainty, and
doubt.  As far as PKI goes, a bit of loathing might also be in order
as well.

A PKI supports the issuance, delivery, management, and revocation of
public keys.  And public keys are the basis for electronic commerce,
future authentication systems, secure email, and IP encryption.  So,
PKI sounds like a must-have technology.  But the reality is that we
are not quite ready yet, as the technology, or perhaps rather the
standards and implementaitons, still have a distance to cover before
they are ready for prime time.

Not that there aren't PKI's available today.  You can buy an PKI
system from Entrust or VeriSign today.  Just be ready to face a
recurring cost of over $100 per user per year for the privilege
(and that is at the 5,000 user 'discount' level).  Your return on
investment might be a long time coming.

So why you should be interested in PKI?  Let's take a look at what
the technology has to offer, as well as a few of the pitfalls 
waiting for early implementers, as well as poorly architected
designs.

The Key

The wonders of cryptography rest upon algorithms, and the ability to
securely exchange session keys.  In symmetric cryptography, each
pair of people who wish to communicate must securely exchange a
secret key.  The key cannot be sent across a network, but must be
communicated some other way--Federal Express, certified mail, or
courier.  While this sounds somewhat onerous, it is nothing compared
to the number of keys that must be exchanged.

For six people to communicate privately, fifteen keys need to be
securely exchanged.  If one thousand need to communicate privately,
the total balloons to 500,000 keys.  You can determine the number
of keys required with a simple formula: n*(n-1)/2, where n is the
number of participants.

Obviously, key distribution becomes a big problem in symmetric
key cryptography.  Plus, you don't get to use the network for
the key distribution--you must use some other mechanism.

This is where PKI steps in.  In assymmetric cryptography, a key
pair is used, and one of the key pair may be safely published
(see Figure 1).  One key is used to encrypt and the other to decrypt.
It doesn't matter which key in the pair is used to encrypt; the
other key must be used to decrypt the communication.  It also turns
out that assymmetric cryptography is painfully slow, one thousand
times slower than symmetric cryptography, so practical applications
of cryptography typically involve hybrids of both types.  Symmetric
cryptography is used to encrypt data, and assymmetric cryptography is 
used for exchanging session keys, as well as other purposes.

The best known application that uses public keys is SSL, the 
Secure Sockets Layer introduced by Netscape, used in Internet
Explorer, and by many Web servers for securing communications.
Here is how it works.  When the user of a Web browser selects
a URL that begins with _https_, instead of connecting to the
server at the typical Web port, 80, the browser connects to
port 443 instead.  The browser requests the server's certificate,
which contains the server's public key.  After the browser 
receives the server's certificate, it verifies the authenticity
of the certificate.

The browser then generates a pseudo-random number to use as
a symmetric key for encrypting the data to be transferred.  This
session key is then encrypted using the public key extracted from
the server's certificate, and sent to the server, along with the
encrypted data.  The server decrypts the encrypted session key,
then decrypts the data (Figure 2).  The server will use the same
session key to encrypt any data sent back to the browser.

Signed, sealed, and delivered

Your browser likely came with many pre-installed certificates (my
version of Netscape, running under BSDi UNIX, comes with over forty).
You can view the certificates that are included with your browser
by looking under the Security menubar option, Signers.  The certificates
for signers are used to vouch for other certificates that the browser
receives, for example, as part of an SSL transaction.  The browser
verifies a server's certificate by calculating a digital signature
for the certificate, extracting the signature of one of the signing
certificates that came with server's certificate, and decrypting the
extracted signature using the signing certificate's public key.  If
the decrypted  signature matches the just-calculated signature, the
server's certificate is considered verified (Figure 3).

Each of the forty or so signing certificates come from root Certificate
Authorities, organizations that vouch for the authenticity of other
certiciate authorities (CAs).  As long as you trust the root CAs, you,
or your software, can accept certificates from organizations you have
never communicated with before.  The root CA has authenticated their
certificates, presumably after verifying the identity of the agency.

Think of a root CA as a state's Motor Vehicle Division that issues
driver licenses, a form of a certificate.  You must appear in person,
and present ID, in order to apply for a driver's license.  Once you
have received your drivers license, you may use it as a means of
identifying yourself to others.  As long as people trust the state,
(and that the drivers license is not forged), your drivers license
works to identify you to others.  For example, a store clerk may
ask to see your drivers license when you pay with a check.  The 
drivers license works as an authenticating agent when you present
your check.

Now, imagine that someone has stolen your wallet, which contains
your drivers license and a blank check.  The thief can (perhaps)
forge your signature, then use the stolen drivers license as
proof of identity when presenting the check.  Fortunately, most
drivers licenses include a self-authenticating feature--your
photograph.  If the sales clerk or bank teller is alert, they
will notice that the picture does not match the person holding the
license, and refuse to honor the check (and perhaps call the 
police).

Notice that your Web browser is not so lucky.  Currently, Web
browsers do not employ a mechanism for checking for revoked
certificates.  A Web server's certificate is considered valid
until the expiration date included in the certificate has been
reached.  Thus, if an e-commerce site has their certificate 
revoked, your Web browser has no way of knowing.  It will
continue to trust revoked certificates.

Why would a certificate be revoked?  What a certificate does is
convey ownership of a key pair.  If the private key has been 
revealed or lost, the public key of the pair must also be invalidated
by revoking the certificate.  In the case of a lost server key,
the Web server could send out a new certificate, replacing any cached
certificate.  In the case of a root CA, any certificates signed
by the root CA would now also be invalid.  The root CA, whose business
is signing certificates, would be in big trouble.  Root CAs 
business model is based upon trust, and that would be gone 
after losing the private key used to sign certificates.

To avoid this possibility, most root CAs set up elaborate security
to protect their private keys.  The system containing the private
key is kept physically secure, in a vault.  The vault itself is
screened to eliminate electro-magnetic emanations (forget about
any network connection).  Persons entering the vault must be
authenticated using more than one strong method of identification,
for example, a picture ID badge presented to a guard, as well
as a retinal scan.  The vault has three doors in series which
are never opened at once, and do not present a straight path to
the interior of the vault.  And none of this is unreasonable.
Sooner or later, a root CA will be compromised, much to their dismay.

Local Authority

E-commerce servers can present certificates that bind their identity
to a key pair to support encrypted communications.  There are many
companies vying to become THE root CA--but there currently is no
single, worldwide CA.  Is this bad?

Not really.  The model currently in use relies on local authorities.
Cross certifications permit one CA to vouch for another's
authenticity.  And this model can and will work locally, in your
organizaiton, as well.

Several companies, including Entrust and VeriSign, now sell PKI
products, and Microsoft will be including one with Windows 2000
servers (once known as NT 5).  A study, commissioned by
Entrust, showed that the five year cost for installing a vendor's
product to support 5,000 users, including support and certificate
life cycle management, would be $2.8 million for Entrust's product
and $3.8 million for VeriSign's.  You would be correct to wonder
about the accuracy of information from a vendor sponsered study,
but one things is amply clear.  Running your own PKI will not be cheap.

A public utility company, which will go unnamed, investigated providing
a public key certificate to each of their customers, permitting them to 
pay on-line, check their accounts, and current usage compared to 
past usage, etc.  They first talked to to the established PKI companies,
and shocked at the result, tried a small pilot to calculate how
much it would cost to support their own PKI.  The number they came
up with was $10/year/customer.  With 4 million customers, this did
not seem to be a viable option, and the project was abandoned.

If your organization had their own PKI, they could use cerrificates
for IPSec.  IPSec is part of IP Version 6, has been ported to
some IPv4 stacks and is supported by most VPN products at some
level.  IPSec provides for authentication of IP headers with
digital signatures (no spoofed source addresses), and encryption
at layer three.  Layer three encryption means that any application
that uses the network will use encryption with participating systems
transparently--no modifications necessary.  Current IPSec products
require manual key exchange/configuration, but having a functional
PKI solves this problem.

While the CA manages keys, a directory service provides keys on
demand.  LDAP (Lightweight Directory Access Protocol) appears to
be the chosen method for distributing keys.  Keep in mind that the
server storing the certificates, and the delivery of the 
certificates containing
the keys, does not have to be secure.  The signature from the CA
with the certificate is what vouches for the authenticity of the
key pair/user binding.

Totally Secure

Which brings us to the vault that will contain your private key.
For most organizations outside of root CAs, a vault with triple
doors and electrical shielding will be overkill.  But you still
must do your utmost to protect your private key for your CA.  If
it is lost, it means re-issuing all certificates, and probably
arranging for cross certification again as well.

What I recommend is to put private keys and the signing software
on a notebook computer.  The notebook computer is kept in a
safe when not in use, and only a limited number of people can
actually open the safe.  A safe that requires two people to
open it (two keys, like safety deposit boxes, or two combinations)
is even better, as it provides for dual custody.

The notebook is _never_ connected to any network.  While you are
signing certificates, you keep the door locked, and have a witness
watching.  You can store certificates to be signed on floppy disks,
or a larger capacity external driver (like a Zip) if there are
large numbers of certificates to process.  When the procedure has
been completed, the notebook gets locked away again.  Then the floppy
or other media can be mounted on the directory server.

Users will also have their own private keys, and these will reside
on desktops connected to networks and even on roving notebooks.  The
security of users' private keys depends upon the keys being stored
encrypted using a passphrase.  Passphrases are like passwords, but
should be much longer.  If the passphrase that protects a user's
private key is weak (as most passwords in use are), then an
attacker could 'brute force' the passphrase using techniques
similar to password crackers like crack and l0phtcrack.

A better technique, and one we will be seeing soon, would be to 
store the private key on a smartcard.  Smartcards include both 
RAM (storage) and a CPU (for processing), and rely on an external
reader for power.  The user inserts the smartcard in the reader,
and enters a PIN number to unlock the card.  Then software that
needs to use the private key uses routines stored and executed
on the smartcard.  For example, to sign an e-mail, the MD5 or SHA
checksum (such as the ones used by PGP) is sent to the smartcard,
encrypted using the private key, and the result returned to the user's
computer.  

So far, adoption of smartcards has been slow for two reasons.  First,
that the cards themselves have been based on proprietary CPUs and
used obscure programming languages.  Today, Java-based cards are
available.  And second, that the card readers were expensive.  Card
readers are now available for under $100, as well as card readers
that can fit into a floppy disk drive (great for notebooks), or
are part of keyboards.  One vendor, ActivCard, has announced a 
card reader included in a mouse.  By attaching the mouse, even
mobile users can take advantage of smartcards on most computers.

The Frontier

PKI is a great concept, and it would be wonderful to have overlapping
CAs available today.  The reality is that this is still almost
rocket science-- well understood technology but difficult to
implement securely and correctly.  And costly as well.

As time passes, the implementations will become easier to use, 
and cheaper as well.  You don't need a crystal ball to predict
that.  Also, with the entry of mass market vendors such as
Microsoft, there will be even greater pressure on reducing
cost and complexity of CA and PKI products.

And hopefully, within the next several years, PKI will become
ubiquitous, and truly useful

As time passes, the implementations will become easier to use, 
and cheaper as well.  You don't need a crystal ball to predict
that.  Also, with the entry of mass market vendors such as
Microsoft, there will be even greater pressure on reducing
cost and complexity of CA and PKI products.

And hopefully, within the next several years, PKI will become
ubiquitous, and truly useful.

[end]
VeriSign www.verisign.com Mountain View, CA
Entrust www.entrust.com Richardson, TX
BSDi, www.bsdi.com, Colorado Springs, CO
PGP Inc. San Jose, CA (now owned by Network Associates)
Microsoft, www.microsoft.com Redmond, WA