Here is something I've been working on for a while, mostly to include in a
packet of information for our customers.  It's still a bit rambling, but you
may find it useful.  Most glaringly, it could use a few paragraphs on
encryption. Please send me any corrections or other feedback.




Public Keys and Certificates
Ken Hirsch
30 Jan 2002 (Draft)

There are two public-key encryption systems in widespread use on the
Internet: PGP and RSA.  PGP is used widely for file encryption and
somewhat widely for email.

RSA encryption is the basis for the "Public Key Infrastructure" (PKI),
which is used for secure HTTP (SSL), TLS, and S/MIME encryption for
email (built into Microsoft Outlook, Netscape Messenger, Novell
Groupwise and several other major email clients).  S/MIME can also be
used for file encryption.

[needs checking
[In principle, S/MIME encryption and the PKI are not necessarily tied
[to RSA encryption.  You could potentially use PGP to encrypt an
[S/MIME message and other public key encryption systems are possible
[but most software does not support that



With public key encryption, the usage of keys is as follows:
======================================================
Encryption              -- Recipient's public key
Decryption              -- Recipient's private key
Signature               -- Sender's private key
Verifying Signature     -- Sender's public key

Public key encryption systems protect against passive eavesdropping,
but for protection against active "man in the middle" attacks or
impostors, additional steps are needed. The Public Key
Infrastructure attempts to provide this additional protection as
well as convenient means for creating and exchanging keys.

[The PGP system does not work by certificates.  A correspondent just
provides his public key.  If you need to authenticate a key, it's
up to you to check on it.  If you know the person, you can call them up
and ask them to read you the key's "fingerprint", to make sure it is the
same.  Or you might get their key from their web site, assuming their
web site has not been hacked.  The company that markets PGP does have
a server for exchanging keys, but the authentication of the keys on
the server is ad hoc.]

With PKI,  public keys are contained in X.509 certificates, which
contain identifying information and are cryptographically "signed" by a
certificate authority (CA).  The certificate authority goes to some
effort to make sure that the identifying information goes with the
person requesting they certificate.

The extent to which the CA tries to verify the information depends on
the kind of certificate requested.  For just encrypting email, they just
make sure that the person requesting the certificate is at the email
address specified.  This is an automated process involving a trip to
their web site, receiving an email and then verifying the contents of
the email back at their web site.  A small payment may be required,
which not only provides revenue for the CA, but also provides a means of
tracking an impostor via their use of a credit card.

For other purposes, the verification process may involve phone calls,
signed forms via physical mail, credit checks, etc.  One sensitive use
of certificates is "code-signing".  When you visit some web sites, a
window will pop up, asking if you want to run a program created by, say,
Microsoft.  The code signature is supposed to verify that the program
was actually written by Microsoft and not by some hacker. Unfortunately,
the company that issues certificates for this purpose did issue some
code-signing certificates in Microsoft's name to some impostor.  This
was caught in an audit and Microsoft has issued patches to their web
browsers to look out for these bogus certificates.

In order to catch problems like this, the PKI includes the idea of
certificate revocation lists (CRLs), but unfortunately there is little
automated support for this in most products.  As an added safety
measure, and to supply continued revenue for certificate authorities,
certificates include an expiration date.  This creates a time limit on
the harm that a bogus certificate can do.

For some uses, the idea of a man-in-the-middle attack seems far-fetched
and it may be more economical to just create your own "self-signed"
certificates.  It is a policy issue of what certificates to accept for
what purposes, not a technical issue.  If a web browser or mail program
encounters a certificate that is signed by someone other than a
recognized certificate authority, it needs to ask the user whether this
certificate should be trusted.

For email, the easiest way to send someone your public key certificate
is to send them a signed email.  The signature will contain the
certificate.

How digital signatures work

In order to cryptographically sign a message, the signing program
first calculates a "hash" or "message digest" of the message.  A
bad example of a message digest function would be to add up the
numbers that are used to represent the characters in the message.
For example, md("STOP") = 84+69+83+84 = 320.  This would be a bad
message digest function because it is easy to alter the message
without changing the message digest, e.g. md("POTS") = 320, also.

The functions that are actually used, e.g. SHA1, MD2, or MD5, make it
almost impossible to alter a file in a way such that it is still
intelligible and yet keeps the same message digest number.  These
functions take files that are thousand or millions of bytes long and
output a message digest that is only 20 to 32 bytes long, yet highly
reliable.

The output of the message digest function is then encrypted using
the sender's public key.  The original file, the encrypted hash, and
the sender's certificate are all put together to be sent.  Or,
often, the output is then encrypted before being sent.

An example,

   Ken's private key = 97
   Ken's public key = 123
   Ken's certificate = {
       CN="Ken Hirsch",
       Email="[log in to unmask]",
       PublicKey=123,
       Issuer="Sloppy Certificate Authority",
       signature=203384384
   }

  My message = "STOP"

  Message digest = 320
  encrypt(320, 97) = 343443      where 97 is my private key.

  Signed message out =
     { "STOP", signaturealgorithm=simplesumwithbogusencryption,
               signature=343443,
               Ken's certificate = {
                       CN="Ken Hirsch",
                       Email="[log in to unmask]",
                       PublicKey=123,
                       Issuer="Sloppy Certificate Authority",
                       signature=203384384
                     }
     }


The recipient of the message calculates the message digest again,
then compares it with the decrypted signature.

  md("STOP") = 320
  decrypt(343443, 123) = 320       where 123 is my public key

They match, so the message is authenticated as untampered with and being
from me.  Only someone who knows my private key could have produced the
signature.

Well, you actually have to check that my certificate is valid, too.
Somebody could have sent a message with a fake certificate that looks
like it is from me.

How do you do verify my certificate?  It is signed by a certificate
authority (CA), and you check that signature the same way.  Of course,
you need to know the CA's public key to check it, so you need to get the
CA's certificate and check that it is valid, too.  This sounds like an
endless process, but eventually (usually in one or two steps) you should
get to a "self-signed certificate" of a trusted root CA.  These root
certificates are, for example, loaded when you install Internet
Explorer.  Your web browser does all this automatically when you click
on a link that starts with "https://" and your email program (if it
supports S/MIME) does this when you get a certificate from a new
correspondent.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *