+------------------------------------------------------------------+ | 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@private>" 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@private>" 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@private>" 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@private> sig 3 D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@private> sub 1024g/26F8D783 2003-12-14 sig D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@private> 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@private pub 1024D/D5D3BDA6 created: 2003-12-14 expires: never trust: -/f (1). John Doe (My First PGP Key) <jdoe@private> 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@private> 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@private>>" 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@private>" 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@private> sig 3 D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@private> sig 3 42851101 2004-04-19 Jane Doe (Home Key) <janedoe@private> sub 1024g/26F8D783 2003-12-14 sig D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@private> 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@private 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@private -------------------------------------------------------------------- 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@private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2004, Brian Hatch. _________________________________________ ISN mailing list Sponsored by: OSVDB.org
This archive was generated by hypermail 2b30 : Wed Apr 28 2004 - 06:06:28 PDT