[ISN] File and email encryption with GnuPG (PGP) part six

Wed Apr 28 05:44:33 EDT 2004

+------------------------------------------------------------------+
|  Linux Security: Tips, Tricks, and Hackery        27-April-2004  |
|  Published by Onsight, Inc.                             Edition  |
|                                                                  |
|  http://www.hackinglinuxexposed.com/articles/20040427.html       |
+------------------------------------------------------------------+

This issue sponsored by EFF: Defending Freedom in the Digital World

The Electronic Frontier Foundation (EFF) is a membeship organization
that needs your help. EFF works to protect civil liberties taht
relate to new technologies. Our lawyers engage in cases that champion
online freedoms, our site archive is a comprehensive digital rights
resource, and we've developed a powerful media presence.

Check out http://www.eff.org/ to learn more.

--------------------------------------------------------------------

File and email encryption with GnuPG (PGP) part six
By Brian Hatch

Summary: Signing public keys is your way of telling GnuPG and other
people that you've verified the owner of the key.
                               ------

Last time I showed you how to exchange and verify public PGP keys
with an individual. After you've verified a user's key (KeyID, bits,
type, fingerprint, and user's actual identity) you should sign their
key.

Signing a key tells the PGP software (GnuPG in most cases for us
Linux heads) that you've acknowledged the key is legitimate when
verifying the signature. Let's take a look at the different
verification possibilities.

Here's the mutt[1] header of a PGP signed email, where we've never
downloaded the key at all:

  gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
  gpg: Can't check signature: public key not found

Compare to the next one, where we do have a copy of their public key,
but have never signed the key:

  gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
  gpg: Good signature from "John Doe (My First PGP Key) <jdoe at example.com>"
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:          There is no indication that the signature belongs to the owner.
  Primary key fingerprint: B53F E57B D0C1 F689 FCE2  5623 5B9A A5F8 801E A932

Or this one, where the public key is on our keyring, and the key is
signed by us:

  gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
  gpg: Good signature from "John Doe (My First PGP Key) <jdoe at example.com>"

And, to round things out, one where the key is on our keyring, signed
and all, but the signature is invalid (the message was corrupted in
transit, most likely)

  gpg: Signature made Wed Apr 14 18:59:36 2004 PDT using DSA key ID D5D3BDA6
  gpg: BAD signature from "Jon Doe (My First PGP Key) <jdoe at example.com>"

The third example above is what we'd like to see - messages signed by
other parties whom we've verified, received with a valid signature,
assuring us that the message came unaltered from the owner of the PGP
key. When you see this success, either the individual sent it and all
is well, or their key has been compromised, no other possibilities
exist. Naturally, we're hoping they haven't been compromised...

Before we sign the key, let's check out the existing signatures on
this key on our keyring:

  # Show the key, and all the signatures too
  $ gpg -kvv D5D3BDA6
  pub  1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>
  sig 3       D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>
  sub  1024g/26F8D783 2003-12-14
  sig         D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>

Yup, the key is just signed by John himself, no one else yet. Now
it's time for us to sign his key, so GnuPG will stop telling us that
it's untrusted, and so we can introduce John to other people:

  $ gpg --sign-key jdoe at example.com

  pub  1024D/D5D3BDA6  created: 2003-12-14 expires: never      trust: -/f
  (1). John Doe (My First PGP Key) <jdoe at example.com>

  pub  1024D/D5D3BDA6  created: 2003-12-14 expires: never      trust: -/f
   Primary key fingerprint: 0E43 DC31 C484 431C 5B07  3875 7B2D D3D8 D5D3 BDA6

       John Doe <jdoe at example.com>

  How carefully have you verified the key you are about to sign actually belongs
  to the person named above?  If you don't know what to answer, enter "0".

     (0) I will not answer. (default)
     (1) I have not checked at all.
     (2) I have done casual checking.
     (3) I have done very careful checking.

  Your selection?

At this point you get to tell GPG how thorough you were in verifying
the key owner's identity. If you followed the procedures in the
previous article, you probably verified their identity by looking at
their driver's license, passport, doing a fingerprint scan and DNA
test, etc. In my opinion, if you can't honestly say #3 above, then
you shouldn't be signing the key at all.[2]

Ok, so, let's get this finished up:

  Are you really sure that you want to sign this key
  with your key: "Jane Doe (Home Key) <janedoe at example.net>>"

  I have checked this key very carefully.

  Really sign? yes

  You need a passphrase to unlock the secret key for
  user: "Jane Doe (Home Key) <janedoe at example.net>"
  1024-bit DSA key, ID 42851101, created 2004-01-01

  Passphrase: (type passphrase)

Note the utter lack of output in the event that you've typed the
passphrase correctly - good old Unix tradition at work. So, let's
check out the key now and see our new signature on it.

  # Show the key, and all the signatures too
  $ gpg -kvv D5D3BDA6
  pub  1024D/D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>
  sig 3       D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>
  sig 3       42851101 2004-04-19 Jane Doe (Home Key) <janedoe at example.net>
  sub  1024g/26F8D783 2003-12-14
  sig         D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe at example.com>

So you can now see that Jane has signed John's key on 19-Apr-2004
with her key, 0x42851101. At this point it's a good idea to send the
newly signed key back to John, and if he has no objections upload it
to the keyservers as well so everyone can benefit from her signature.
We covered this previously, but here's a reminder:

  # Send all keys to keyservers
  $ gpg --send-keys

  # Or just the one key
  $ gpg --send-key "john doe" 

  # Extract and email him his signed key
  $ gpg --export -a 'john doe'  > john_keys.asc
  $ mutt -a john_keys.asc jdoe at example.com 

There are, of course, other ways you can get the keys to owner if you
want. For example rather than attaching the key manually as I have
above with mutt[3] you could attach the key using esc k from the
message creation screen. Incidentally, if someone sends you keys in
email, you can import them using ctrl-k in mutt.

So, by this point we have all the important parts of PGP/GPG/GnuPG in
our hands. You can create your keys, verify and sign the keys of
others, verify and/or encrypt data. Many tools have built in PGP
support to save you from working on the command line, which will make
work with PGP as seamless as working with your editor.[4]

NOTES:

[1] Greatest email program in the world

[2] There is a second kind of signature, called a local signature.
This type of signature won't be exported to any keyservers, so no one
would know you signed their key. This is useful if you want to stop
getting "untrusted signature" warnings on keys that you're fairly
sure are legit, but don't want to have others believe you have
actually verified. The PGP key that comes with your Linux
distribution would be a good candidate for local signing. To sign
locally, you'd use gpg --edit-key and then lsign, but I won't cover
that further.

[3] I simply cannot plug this email client enough...

[4] And, naturally, that editor should be vim. ;-)

                            -------------
Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
Linux Exposed and Building Linux VPNs. He's currently debugging a
problem in a monitoring product that thinks it's in standby mode when
it should be active. Luckily, it's buggy, and as such will always
send notifications even in standby mode, when it shouldn't. So it's
broken because it's in standby mode by mistake, but it's working
because it's buggy and notifies of problems anyway. Look - two wrongs
do make a right! I'm going to go get some tea and pretend this never
happened... Brian can be reached at brian at hackinglinuxexposed.com.

--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.

The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request at lists.onsight.com.

Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/

--------------------------------------------------------------------