Public Key Authentication

Why should (or shouldn't) I certify a key?

Signing another person's key is your binding signature (binding in the sense that the rest of the PGP community depends to some degree on your being honest) that the key belongs to the person it claims to belong to. Many people have different identities on one key ... mine, for instance has several that list out like this:

pub 1280 0xFA4C5DB1 1996-06-13 ---------- RSA Sign & Encrypt uid Michael T. Babcock <[email protected]> uid Mike Babcock uid Michael T. Babcock <[email protected]> uid Michael T. Babcock <[email protected]> uid Michael T. Babcock <[email protected]> uid Thawte Freemail Member <[email protected]>

Each of the uid lines is one way to identify me or get a hold of me. You'll notice that I have a line for each of my E-mail addresses. If, for instance, you knew (for certain!) that this was my key and that I was the recipient of E-mail at [email protected], then you would sign that user-ID. The whole key isn't signed, just the IDs that you are certain of. This is asked by PGP -- don't sign the ones you aren't sure of.

The purpose of using PGP for encryption is to ensure that only the intended recipient can decrypt whatever you are sending them. In the case of PGP signatures, you want to make sure that no one tampered with the message before it was received. Of course, there is no point in getting someone's signature on a message if you can't prove that it's their signature.

For PGP to be a secure method of encryption and validation, it is imperative that you understand why you should or should not trust a key on your keyring. Some messages and the like may not be important enough to be sure of the receiver. This means you may not check the signature on every signed message you receive. If a security note comes to you by E-mail claiming to be from some large company and it's PGP signed, you'll probably try to check that, though. However, when you encrypt a message, it will only be readable by the person to whom you encrypted it, so be sure you're using an authentic key.

Paranoia

Part of the problem is that many people don't understand the paranoia (as they see it). There is a high ability of low skilled hackers to read your E-mail on a regular basis or even replace incoming E-mails with messages from themselves (that look authentic). It's just as easy for this malicious person to generate a PGP key with one of your associates' E-mail address on it (PGP can't and doesn't check if it's real). They could then sign messages to you and encourage you to encrypt messages to them (which might, in turn, be encrypted to the real PGP key and sent off to the right person, without them knowing). This could even be done by a business collegue or your snooping boss. This is where key signing (authentication) comes into play.

For the secure sending of information using PGP, how can you be sure that the public keys you intend to use belong to who you think they belong to? There are many ways to check a PGP key, and for starters, you should always try to get a copy directly from the person, whether on paper (as a printed copy of the text version of the key -- to verify against the one they may have sent by E-mail), or on diskette. A fax from them (faxes are not secure either), or a verification of their key's fingerprint over the phone is also a good idea. If these aren't possible, then get a copy of their key by every method possible; by E-mail from them, by fingering them for it, from their WWW site, from a BBS that they call, from the keyservers, and any messages they have put it in. If you get the same key from each place, and this is good enough for you, then make sure some messages that this person sends (newsgroups, etc) that are signed with that key verify.

Key signing ...

Don't forget about key-signing though. When you sign someone's key, you let everyone know that you know that identity to belong to the person it claims to belong to. This helps build what's known as the web of trust. The web of trust is the term that Phil Zimmermann uses to describe PGP's key authentication techniques. Instead of using a centrally administered database of keys and who they belong to, PGP allows anyone to generate any number of keys. These keys you then give to all your PGP using associates and friends. You encourage them to sign them when they are certain they are from you. Now people who you can't get in personal contact with can trust your key because it's signed by someone who trusts your key.

How do I know?

In the old days when PGP was text-based (and still is on most Unix systems), these concepts were a little easier to follow because you had to do them yourself. Now, because of nice graphical interfaces, some of this is hidden from you. You may (in Windows), have to right-click on a key and look at its properties to see if it's signed by anyone, and in that case, by whom. In my case, I type in PGP -KC tyenet and it checks all the keys with tyenet in them somewhere (everyone at my ISP). This gives me a nice output like:


Type Bits KeyID      Created    Expires    Algorithm       Use
pub  1024 0x4B875F7F 1998-04-09 ---------- DSS             Sign & Encrypt 
sub  2048 0xADAA2DC2 1998-04-09 ---------- Diffie-Hellman                 
uid  Allen Crutchfield <[email protected]>
sig!      0x4B875F7F 1998-04-09 Allen Crutchfield <[email protected]>
sig!      0x89641F17 1998-04-10 Michael T. Babcock <[email protected]>

pub  1024 0x536FFA63 1998-10-02 *REVOKED*  DSS             Sign & Encrypt 
sub  4096 0xA977DBD3 1998-10-02            Diffie-Hellman                 
uid  David F. Longe <[email protected]>
sig!      0x536FFA63 1998-10-02 David F. Longe <[email protected]>

pub  1024 0x8C86809A 1998-10-06 ---------- DSS             Sign & Encrypt 
sub  4096 0x3C3C6FF3 1998-10-06 ---------- Diffie-Hellman                 
uid  David Longe <[email protected]>
sig!      0x8C86809A 1998-10-06 David Longe <[email protected]>

sec+ 1024 0x750C259F 1998-11-03 2000-11-02 DSS             Sign & Encrypt 
sub  2468 0xB5F3894E 1998-11-04 2000-11-03 Diffie-Hellman                 
uid  Michael T. Babcock <[email protected]>
SIG!      0x750C259F 1998-11-03 Michael T. Babcock <[email protected]>
uid  Michael T. Babcock <[email protected]>
SIG!      0x750C259F 1998-11-17 Michael T. Babcock <[email protected]>

pub  1280 0xFF663131 1998-06-16 ---------- RSA             Sign & Encrypt 
uid  Stephen Tyers <[email protected]>
sig!      0xFF663131 1998-06-16 Stephen Tyers <[email protected]>

pub  1280 0x36517395 1996-08-21 ---------- RSA             Sign & Encrypt 
uid  Wayne Lambert <[email protected]>
sig!      0x36517395 1996-08-21 Wayne Lambert <[email protected]>
sig!      0xFA4C5DB1 1996-08-23 Michael T. Babcock <[email protected]>

It then breaks down the validity and trust-levels for each of those keys: (Validity is whether it's signed by myself or someone I trust or someone they trust -- up to 3 levels, Trust is whether I trust them or not for the sake of the previous calculation).


  KeyID      Trust     Validity  User ID
  0x4B875F7F marginal  complete  Allen Crutchfield <[email protected]>
                                 Allen Crutchfield <[email protected]>
             complete            Michael T. Babcock <[email protected]>
# 0x536FFA63 untrusted invalid   David F. Longe <[email protected]>
                                 David F. Longe <[email protected]>
  0x8C86809A untrusted invalid   David Longe <[email protected]>
                                 David Longe <[email protected]>
* 0x750C259F ultimate  complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
                       complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
  0x89641F17 complete  complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             complete            Michael T. Babcock <[email protected]>
             complete            Mike Babcock <[email protected]>
             marginal            Steve Coles <[email protected]>
             marginal            Allen Crutchfield <[email protected]>
                       complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             complete            Michael T. Babcock <[email protected]>
             complete            Mike Babcock <[email protected]>
             marginal            Steve Coles <[email protected]>
                       complete  CyTech Computers <[email protected]>
                                 Michael T. Babcock <[email protected]>
             complete            Michael T. Babcock <[email protected]>
             complete            Mike Babcock <[email protected]>
             marginal            Steve Coles <[email protected]>
  0xFA4C5DB1 complete  complete  Michael T. Babcock <[email protected]>
             marginal            Wayne Lambert <[email protected]>
             complete            Mike Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             marginal            J. Michael Lowe <[email protected]>
             marginal            Ronny L. Waldrip <[email protected]>
             ultimate            Michael T. Babcock <[email protected]>
                       complete  Mike Babcock
                                 Michael T. Babcock <[email protected]>
             marginal            J. Michael Lowe <[email protected]>
                       complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             marginal            J. Michael Lowe <[email protected]>
                       complete  Michael T. Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             marginal            J. Michael Lowe <[email protected]>
                       complete  Michael T. Babcock <[email protected]>
             complete            Mike Babcock <[email protected]>
                                 Michael T. Babcock <[email protected]>
             marginal            J. Michael Lowe <[email protected]>
                       complete  Thawte Freemail Member <[email protected]>
             complete            Thawte Personal Freemail Issuing Key 1997.06.24 08:27
             ultimate            Michael T. Babcock <[email protected]>
  0xFF663131 untrusted invalid   Stephen Tyers <[email protected]>
                                 Stephen Tyers <[email protected]>
  0x36517395 marginal  complete  Wayne Lambert <[email protected]>
                                 Wayne Lambert <[email protected]>
             complete            Michael T. Babcock <[email protected]>

How can I get my key signed?

If you make regular contact with someone in person as well as on-line, you should get them to sign your key, preferably exchanged on a diskette, so that anyone who trusts either of you can trust the other.

Some groups still hold key-signing 'parties' from time to time, often announced in alt.security.pgp. At these parties, everyone shows up with adequate personal ID to prove they are themselves and a copy of their PGP key fingerprint to give out to people. As people are assured that someone is really the person owning that fingerprint, they write the information down (key ID, fingerprint and name) and when they get home, sign the keys in question. Of course, everyone has to remember to send their signed versions of others' keys back to the keyservers and/or to the owners.

To get the E-mail address of your PGP key signed, you can go to Thawte. Thawte will ask you for several pieces of ID, including your SIN or other national identification number for identification purposes. You can decide whether you trust them with it; but it's free to get a low-end certification. Thawte also offers Netcape and IE PKS public keys. Read their on-line information to get a good grasp of everything they offer, and how it works.