Docstoc

PKI In the Enterprise

Document Sample
PKI In the Enterprise Powered By Docstoc
					                   PKI In the Enterprise
                                        A White Paper




Written by:    Patrick Patterson
               Technical Specialist − PKI Project
               IP Value Added Services
               SITA/Equant

Date: February 25th, 2000
Table of Contents
Introduction...................................................................................................................................4
What is a PKI?..............................................................................................................................4
PKI as an enabler:........................................................................................................................5
Popular Misconceptions:...............................................................................................................5
    All PKIs (and certificates) are the same −................................................................................5
    PKI is a "silver bullet"...............................................................................................................5
    Certificate Enabled applications vs. PKI Enabled Applications.................................................6
Enabling your enterprise:..............................................................................................................6
Bibliography and further reading:..................................................................................................7
Introduction
Now that the Year 2000 buzz is largely over, many enterprises are turning towards electronic
commerce as the next big information technology challenge. More and more, companies are
asking themselves how they can handle transactions more efficiently, communications more
securely, and repetitive tasks in a more automated fashion. They look around, and hear the
words PKI brandished about as a solution to all of these problems. PKI − Public Key
Cryptography Infrastructure, has been promised for years as a technology would allow us have
private conversations over the Internet, sign for our business transactions, buy our children’s
Christmas presents, and enable single sign on across the enterprise. Sounds great. The problem
is that like any technology problem, the solution is easy, but the implementation is a great deal
harder than it appears on the surface. This paper will hopefully provide the reader with an
understanding of what a Public Key Infrastructure is about, what it can help you with, and what
challenges are ahead of you as you design, and roll out your solution. This paper assumes a
basic knowledge of cryptographic theory, and structures of a PKI. For background that covers this
subject in substantial depth, please refer to the bibliography found at the end of this document.

What is a PKI?
A Public Key Infrastructure is composed of two parts. The first is the Certification Authority. The
Certification authority is the part of the PKI that cryptographically signs user certificates. That’s it.
That’s all it really does. It says − I certify that I have seen this public key, and it has been
registered with this name from the Directory Service. Which brings us to the second part, the
Directory Service. The directory service acts as a repository for the certificates that the
Certification Authority has signed.

You are now saying to yourself − and THIS is what all the fuss is about.... well, almost, but not
quite. The value behind a PKI lies in the procedures that surround it. The procedures determine
the level of certainty that someone can have in the certificate that the Certification Authority has
signed. Now remember that when a Certification Authority signs a certificate, it says that it
guarantees that the Directory entry matches the public key on the certificate. Well... The policies
behind the PKI are what binds this validated certificate to an individual, corporation, or device (I’ll
call it an entity from here on in). Weak PKI procedures produce a weak binding between the
certificate, and the entity. Strong PKI procedures guarantee the binding of the certificate and the
entity in a manner that can be proven beyond a shadow of a doubt.

Once this binding has been established, it is now up to the entity that uses that certificate to
decide what is to be done with it. The most common use is currently for electronic mail, where, if
the user’s mail program is configured to look up certificates automatically, the use of certificates
to authenticate and encrypt messages happens automatically. If the user’s program doesn’t do
this, then it is up to the user to go and retrieve the certificates from the directory manually, and
load them into a local repository prior to use.
PKI as an enabler:
As demonstrated in the previous section, PKI by itself isn’t a solution, but rather is a tool to help
you get to the solution. The problem that it starts helping you to solve is assurance and privacy,
but it provides only parts of both. It provides part of the solution to the assurance problem in that
it provides a binding between an electronic certificate, and a real world entity. It provides part of
the solution to the privacy problem in that it allows a message to be encrypted in such a way that
only the entity that the binding says it belongs to can decrypt this message. However, it doesn’t
offer a method for actually cryptographically signing anything, nor does it provide any method for
encrypting or decrypting data. It relies on applications that have been "PKI enabled" to provide
that functionality. Before getting into how to tackle and solve real world problems with a PKI, I
should probably clear up a few....

Popular Misconceptions:
All PKIs (and certificates) are the same −
While some PKI vendors would like to have you believe that, it is very important to read the
documentation that comes from the PKI vendor to see just what a given certificate guarantees.
You’d be surprised to know that from most vendors, the basic level of certificate that they sell
guarantees virtually nothing. So you could receive a letter from Andrew Mountbatten−Windsor,
signed by one of these basic certificates, and although it looks like it comes from His Royal
Highness the Duke of York, in reality it could come from a 14 year old in Texas with a strange
sense of humor.
So, you have to ask yourself, after having read all of the policies of a given PKI (it is part of the
Certification Authority Standard that the Certification Practice Statement and the Certificate
Policies of a Certification Authority have to be available to the customers of that Certification
Authorityi), how comfortable are you in believing the binding between certificate and entity that a
given PKI guarantees, and how comfortable are you in using a particular certificate type for a
particular task. The answers to these questions should be answered by the specific uses for
which a given certificate type was intended, and the results of the last certification that your PKI
provider underwent.

(my favourite example is to compare a PKI to a bank − most people will trust a bank that has a
strong history, and a sense of security related to it, which is why most banks are housed in large
concrete or stone structures, with bars on the windows, and have large steel vaults with foot thick
walls .... contrast that to a bank that is set up by a guy in a gymnasium with a card table and a
pile of gold and dollar bills behind him − which are you going to trust more?)
*** THIS NEEDS TUNING****

PKI is a "silver bullet"
The second myth that a lot of people have, is that once an organization has implemented a PKI,
or has started to use a Third Party PKI, they become instantly secure. They say − well, all of my
communications are encrypted and signed, and all of my files are encrypted. Well... this is a start,
but if your users leave their pass phrases written on sticky notes attached to their monitors, and
their Private keys in a file that is left on an unsecured computer, then you really have no more
security than if you weren’t using a PKI at all.


Certificate Enabled applications vs. PKI Enabled Applications
The last myth that needs dispelling before we get on the problem of solving the problem is that all
applications that say they are PKI enabled aren’t, or are, but they only implement part of the
specification. A perfect case in point are America Online’s Netscape Communicator Product, and
    Microsoft’s Internet Explorer. Both of these products have the capability of using certificates for
    their operation, but neither one of them implements the standard to it’s fullest. For instance, in a
    classical PKI, an entity is supposed to have two different key pairs − one for signing/validation,
    and one for encrypting/decrypting. Both Navigator and Internet Explorer use a single key pair for
    both. The reason for the separation of the keys is that in the event of a key compromise, or the
    expiry of a given key, you can throw out the signing key, thus ensuring that the signing key never
    falls into the wrong hands, but you can retain the decryption key that gives you access to your
    data. If you only have one key, you can never do non−repudiation of an electronic signature.

    The other part of the standard where these products are not implemented to the fullest is in the
    area of Certificate lookup, and support for Certificate Revocation Lists. In short, neither product
    supports either of the above (Their Mail Clients do, but not the web browser) . What this means in
    practical terms, is that you have to load the certificates into the browser yourself, and, more
    importantly, the browser has no way of knowing when a given certificate becomes invalidated.

            Example:
            Let’s say that the entity that is bound to that certificate ceases to work for the same
            employer − as far as your browser (and you perhaps) would know, that person was still
            authorized to sign documents on behalf of that company... not a good situation to be in.

    These are just a few of the problems encountered when you hear that various software supports
    certificates − just remember that they may or may not always support operation inside of a PKI
    environment.

    Enabling your enterprise:
    Now that we have discovered what a PKI does, and what some of the pitfalls to avoid are, how
    can we put this technology to work so that your enterprise gets the most out of its decision.

    Three of the problems that need to be addressed are

    Determining what applications would benefit from public key
    cryptography?
    An application can benefit from being enabled with PKI capabilities when one of the following
    conditions is true:
 




       The Application requires two or more parties to communicate in a secure fashion
 




       The Application requires that the user identify themselves in order to gain access
 




       The Application requires that the origin of a transaction or document be verifiable
 




       The Application requires information be transmitted securely
 




       The Application requires that all of the above be auditable, provable, and verifiable

    While there are many solutions to the above problems, Public Key Cryptography, and PKIs by
    extension have been shown to offer a robust, scalable solution. The standards around them have
    specifically been design to allow transactions and communications between any number of
    related and unrelated parties to occur in a secure, and authenticated manner.

    How do we choose which Certification Authority to use?
    Once you have figured out which applications you can use Public Key Cryptography to solve
    confidentiality, authentication and non−repudiation problems for, the next task is to choose a
    Certificate Authority that fits your needs. A Certificate Authority should be chosen on the merits of
    whether or not their policies and practices provide a sufficient level of trust in the binding of an
    entity with their certificate to allow your application to function. This trust is demonstrated through
    the results of audits performed on a PKI, the strength of their procedures, and the reputation of
the issuer. As a CA user, you want to ensure that your chosen CA is audited regularly (at least
once a year by a reputable external auditor), that their procedures are well documented, that they
follow all of the standards for PKI Operation, and that the company behind the CA has a sterling
reputation.

As an example, if you were creating a validation application where you had to ensure that all
persons along the signing path were allowed to sign for their various tasks, and there was an
audit requirement that you would have to be able to prove that a given individual definitely signed
a given transaction, in an environment where the liability was in the millions of dollars, you would
want to only rely on certificates issued from an institution that could guarantee (in court if need
be) that their binding was 100% correct, and which could provide corroborative data that was able
to show that they can support this assertion.

If on the other hand you were simply doing communications of potentially sensitive but not
damaging information between two parties, then either a lower grade certificate, or a certificate
from a CA where there was a lower level of demonstrable trust would suffice.

Solutions for using cryptographic signatures with non PKI
Aware applications.
Let’s say that you want to verify that every document that you download from a web site has been
published by the organization that runs the web site, and that the documents have not been
tampered with in transit. Ideally, you should be able to click on the document, and as it is
downloading (or perhaps when it pops up in the viewer) you would get a screen that pops up and
tells you who created the document, when it was certified, who certified it, and a declaration that
this is a true copy. Alas, often, it is far from that easy to validate a signature on a document. Most
of the time, until software publishers create software that adhere’s to the PKI Standards, you will
be stuck with doing a procedure similar to the following. The following examples assume that you
have PKI aware software loaded on your computer, and that this software allows for online
certificate lookups. If you have software that requires you to manually obtain certificates, and
does not provide for a lookup of a certificate in a Certificate Revocation List, you will not be able
to guarantee the validity of a documents signature.

Example 1: You can download the signed document, and then save it to your computer. Once
this is done, most PKI software will let you select the file, and choose to validate the signature
and extract the document from the signature envelope. Once you have validated the file, you can
proceed to open it in the appropriate viewer.

Example 2: You can download the document, and, at the same time, download a separate
signature file for that document. This signature file can then be used to validate the integrity of the
document (the signature file contains a hash value, which can be verified against the value
generated by hashing the document on your machine), and then authenticate the signer.

As you can see, this can be a long, and somewhat technical process which could easily become
difficult to support, and even more difficult to enforce (how do you force your users to verify the
users of your documentation to validate the signature in Example 2?).

Consequently, in order for you to get the most out of your enrollment in a PKI, you should ensure
that your applications support the following:

Secure Certificate Management − via a smart card, or other hardware based device
Dual Key Support − to allow for true non−repudiation
Directory Lookup of Certificates − the standards specify communications via LDAPv3
Directory Lookup of CRL’s − to allow for certificate validity checking (alternatively OCSP can be
used)
Key Lifecycle Management − to allow your users to renew their certificates painlessly
PKIX−CMP Support − to allow easy communication between your application and the CA

If these guidelines are followed, and all of the standards listed in the Bibliography are followed by
both your application and the CA, you will be able to take advantage of your investment.

To sum up, PKI is not the magic bullet, but by building PKI Enabled applications, choosing a CA
with an appropriate trust level, and carefully rolling out solutions, your enterprise will be able to
take full advantage of Public Key Cryptographic Infrastructures, while avoiding the pitfalls.

Bibliography and further reading:
Working Groups:
http://www.ietf.org/html.charters/pkix−charter.html

IETF Requests for Comments:
RFC2459 − Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 2510 − Internet X.509 Public Key Infrastructure Certificate Management Protocols
RFC 2511 − Internet X.509 Certificate Request Message Format
RFC 2527 − Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices
Framework
RFC 2528 − Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm
(KEA) Keys in Internet X.509 Public Key Infrastructure Certificates
RFC 2559 − Internet X.509 Public Key Infrastructure Operational Protocols − LDAPv2
RFC 2585 − Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
RFC 2587 − Internet X.509 Public Key Infrastructure LDAPv2 Schema
RFC 2560 − X.509 Internet Public Key Infrastructure Online Certificate Status Protocol − OCSP

Public Key Cryptographic Standards:
For A full list of all of the PKCS standards please refer to:
http://www.rsa.com/rsalabs/pkcs/index.html

Additional White Papers:
A Kind and Gentle Introduction to Public Key Infrastructures − Andrew D. Fernandez − Web
Publication May 1999− http://www.cryptonym.com/research/intro2pki/intro2pki.html

Ten Risks of PKI: What You’re Not Being Told About Public Key Infrastructure −
C. Ellison and B. Schneier − Computer Security Journal, v 16, n 1, 2000, pp. 1−7. Available on
the web at: http://www.counterpane.com/pki−risks−ft.txt
i   RFC2527

				
DOCUMENT INFO