Lurking with PGP

Phil Zimmermann's PGP program was written primarily to allow people to be quite sure their private communications remain private. The messages are encrypted so that only the intended recipient is able to read them—as long as users have read the manual and paid heed to its security warnings. Pretty Good Privacy.
I'm Still Not Convinced

If the possibility of a forged posting on the comp.os.linux.announce newsgroup doesn't worry you enough to make you want to install PGP, consider another situation. Suppose you see a newsgroup posting or e-mail message that looks like it is from Ted Ts'o (one of the main Linux developers), and which claims that:

  • A security hole has been found in Linux,

  • It is being exploited by crackers who are destroying the systems they crack into,

  • An attached kernel patch will solve the problem, and

  • You should install the patch on your system(s) as soon as possible.

Further suppose that the patch is beyond your comprehension. Do you install the patch? Let's assume that Ted is trustworthy (a pretty good assumption). How do you know that it is really Ted who made the posting or sent the message? Perhaps the patch really creates a security hole through which a cracker could attack, and a cracker is forging the message and pretending to be Ted in order to convince you to apply the patch.

You can know because Ted PGP-signed his patch, and because you have a copy of his public key. No one could sign it correctly without a copy of his private key, and Ted is a security expert who keeps his private key very safe.

Getting Keys

In order to check a PGP-signed message, you need to have the public key. Where do you get the key? You want to get the real user's real key, not a fake one produced by a forger who is using the fake key to impersonate the sender.

Fundamentally, you need to get the key from a different source than the message. News and mail are notoriously insecure; anyone can fake an e-mail or news message, and anyone who wants to read this article to learn about PGP will probably not notice that the message is fake, and probably won't know how to tell the difference.

If someone is forging messages that are supposed to look like they come from someone else, and they are including PGP, they will also be attempting to propagate a fake key for the user as whom they are masquerading. This means that in an ideal world, you will collect public keys before you need to use them to verify a message. However, there's a good chance that you don't have the key yet when you want to read the message. Where do you look to find a key, and how do you know that it is correct?

Sometimes you can get a key from someone's home page on the Web. If you do that, you have to weigh the possibility that someone has broken security on that system and corrupted the key there. If you get the key well before you want to verify a suspicious message, chances are pretty good that the key you get will be good. The same goes for keys retrieved via finger. If you think you will ever want to verify a comp.os.linux.announce posting, get the key now. If you are paranoid, keep checking for the next few days to make sure there is no announcement that the key was forged or compromised.

One place to find lots of PGP keys is on BAL's PGP Public Key Server, at www-swiss.ai.mit.edu/~bal/pks-toplev.html. This web site has a large database of public keys, and the person you are looking for may have submitted the public key to the database. There's no security; anyone could post an update to anyone else's public key, even forgeries. You still have to verify the keys you get from BAL's server; it's only a convenient point of exchange.

None of these techniques ensure that the key you get is good. All security is a matter of degree, and this technique provides, for most purposes, a reasonable level of assurance that you have the right key. Don't bet the family fortune on it.

Essentially, PGP allows you to extend trust you already have. If you trust your brother to tell you the truth in person, and he has verified that your copy of his PGP public key is correct, then you can be rather sure that a message that is correctly signed with his private key really comes from him. You can be only as sure of that, however, as of his ability to keep his private key secret.

Signed Keys

If your brother is sure that his copy of Joe's public key is correct, and you trust your brother to give you a good copy of Joe's public key, then you can be fairly sure that a message that is signed with Joe's public key really comes from Joe. This is a very useful notion, and PGP supports it.

To verify that he is positive that Joe's public key really belongs to Joe, your brother can sign the key with his own private key. If you are certain that your copy of your brother's public key is correct, and your brother has signed Joe's public key, then if you trust your brother's judgement in verifying keys you can be mostly sure that your copy of Joe's public key is correct. Now that you know Joe's key, if you trust his judgement, you can be reasonably confident of the veracity of public keys which he has signed.

PGP users have organized PGP-key-signing gatherings (parties, BOF (Birds of a Feather) sessions at conferences, whatever) in order to meet face to face and sign each other's keys. As people go to different gatherings in different places, it becomes easier and easier to say, “I trust my brother, and my brother has signed Joe's key, and Joe has signed Jean's key, so I can be pretty sure that this message signed with Jean's key is really from Jean.” This concept has become known as the “web of trust”.

Don't go off the deep end when it comes to the web of trust. PGP doesn't make people trustworthy. As Zimmermann says in the PGP manual, “Trust is not necessarily transferable; I have a friend who I trust not to lie. He's a gullible person who trusts the President not to lie. That doesn't mean I trust the President not to lie. This is just common sense.” If you don't trust someone about other things, there's no reason to trust their signatures of other people's keys. They may be duped or careless or lying themselves.

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions