PNCE: Signed/Encrypted Email
PNCE: Signed/Encrypted Email
Email is one of oldest internet applications, but unfortunately it was designed in an atmosphere of trust. One aspect of this is that anyone can send you email claiming to be from anyone else; the identification of the sender done by your email client is really only about as secure as using the return address on a piece of mail carried by the Postal System to identify the sender.
Unfortunately, a lot of people have started to take advantage of this lack of authentication, and the fact that most people are generally trusting and assume email comes from the person listed. This malfeasance results in many forged emails being sent, trying to trick unsuspecting users into opening virus or other malware infested attachments or to send sensitive information back to the hacker.
The best way to deal with this is by adding digital signatures and/or encrypting email, and this is most easily done through public key encryption algorithms. This has been standardized for interoperability by IETF based on Phil Zimmermann's em_it(Pretty Good Privacy) or PGP program, which has been kept alive in the OpenPGP and GNU PrivacyGuard software. Basically, to sign a message, the software generates a special checksum or hash from the message, and encrypts that hash with your private key. This encrypted hash is then sent along with the message. The recipient then decrypts the hash with your public key, and makes sure the message still generates the same hash. The hash algorithm is selected so that it is considered impossible given a message to generate another message with the same hash value. Thus the recipient knows that the message was generated by someone knowing your private key, and presumably you are the only such person.
Encryption generally has you encrypting the message with your private key, and then encrypting again with the recipient's public key. This doubly encrypted message is then sent to the recipient. The recipient decrypts once with his private key and once with your public key and reads the message. Because of the encryption with the recipient's private key, only the recipient can read the message. Because of the encryption with your private key, the recipient also knows the message came from you. Note also that because of the encryption with the recipient's private key, there can only be a single recipient (in practice, the software can deal with multiple recipients by generating multiple doubly encrypted messages, one for each recipient, and sending the appropriate version to each recipient).
The above scenarios all assume that private keys are secure and known only to their owners, and that everyone's public key is widely and reliably known. Without the above assumptions, no additional security is gained, because the above protocols basically just ensure that, e.g., this message was sent by someone knowing the private key corresponding to this public key. (There is also the assumption that no one can obtain a private key given a public key in any reasonable amount of time; thus far this assumption appears to be quite reliable, and so key management is actually the weakest link.)
To help protect the first assumption (that private keys are known only to their owners), private keys should be placed in a secure location on your computer. Unfortunately, this is not really enough, as you need the private key on a computer you receive/send email on, which therefore must be on the network, and therefore may be vulnerable to hackers. It is usually advised to additionally encrypt your private key with a passphrase. This will make it significantly harder for a hacker to steal your key.
The process of obtaining public keys is discussed in detail in a later section.
As discussed earlier, a digitally signed message consists of two parts, the original message, and an encrypted digest hash of the message. Basically, other than for a few additional lines demarking where the message that was hashed begins and ends and an additional section for the hash, the original message will still be there in a readable form. So even if you do not have any PGP aware software installed, you will still be able to read the message. For example, in a non-PGP aware browser, a message might look like:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This is an example of what a digitally signed message would look like in a mail client that did not know about digital signatures. Sincerely, Me -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFDDjaFZBVs0/CzZpoRAlx1AJwLUvfRaDclBg7MpVcaB5+Aa8uz+wCeIZei xfWSxcTEahIUAoKtwoztxO8= =n+iu -----END PGP SIGNATURE-----
Note that the message is still quite readable, you just have to ignore the BEGIN PGP SIGNED MESSAGE line and everything between the BEGIN PGP SIGNATURE and END PGP SIGNATURE lines, inclusive. Of course, in that case, you have NOT ascertained whether or not the message is really from the stated sender. But that is the same situation you would be in if the message was not signed. (Indeed, the above message is NOT validly signed, as the text message was changed after the signature generated.)
But the point is, if you do not care about verifying whether your email is from whom it claims to be from, you can just ignore some lines and everything is as before.
If an appropriate plugin is installed and configure in your email client, however, it should automatically detect that the message is signed and attempt to verify the signature. At this point, several things can happen:
The good part is that once you have the appropiate software installed and configured, and you have the public keys for the people who correspond with you (or at least those corresponding with digitally signed email), everything is pretty much automatic. You only need to check whether the software reported an error validating the signature (and that only if you are concerned about such).
If someone sends you PGP encrypted email, you need the PGP software to read it. Unlike signed email, there is no work around without the software (if there were, it would defeat the purpose of encryption).
Technically, to send you encrypted email, you need to have your public PGP key advertised (or at least known to the sender), which means that you have a PGP key and so you should have the proper software to read the email.
If you do not use PGP and you get encrypted email, it is probably bogus or misdirected, and you can probably ignore it. The only potentially dangerous scenario is if someone made and advertised a PGP key in your name, i.e. they are trying to impersonate you. If you suspect that, contact the sender of the email and PCS with your suspicions and we will try to assist you.
If you have the software installed, it should recognize that the message is encrypted and decrypt it automatically. It will need your private key, which should be passphrase protected, and so will ask you for your passphrase. Depending on how the software is configured, it may ask everytime you view the message (meaning that the message is stored on disk encrypted); some software may allow you to store the decrypted message on disk; this is more convenient but less secure. The choice depends on what the information is and why it was being encrypted.
Freeware versions of PGP software is available for most if not all platforms. This section is still under construction, but tries to present some options available. PCS is looking into installing PGP software on all systems we maintain, but this is a low priority task and so will be done as staff work on machines for other issues.
The PGP software and installation/configuration instructions vary by platform, and indeed because for best results it must integrate with the email client, it varies by email client as well.
Note: The email client specific instruction pages are not complete, and some (all?) of the links below may be missing. PCS will try to add to these as time allows. If you need assistance with using digital signature/encryption packages with your email client, please contact PCS.
So you got your PHP software installed and configured and integrated with your email client. But before it can be useful, you need to inform the software about the public keys of those you correspond with, or in PGP terminology, you need to add public keys for these people to your keyring.
The documents linked to in the section above discuss the mechanics of establishing your own private/public key pair, and of adding and signing other peoples public keys to your keyring. This section discusses how to get the public keys.
There are several ways to obtain public keys for people. Ideally, OIT would maintain a system, probably through LDAP, where you could get public keys for people on campus. However, that is not available at this time. Often people place their public keys on their personal web sites. The public keys for PCS staff is available here. run public PGP key repositories where people can place their public keys so others can access them. A couple of such repositories are:
The keys for PCS staff are also available at the above sites.Once you have obtained a public key, you may wish to sign it to indicate your trust in the key. Please remember that you should only sign keys that you know belong to the person it is supposed to be for, and that you should not trust keys you just download from websites. Ideally, you should have personal contact for keys that you sign. PGP does support a concept of a web of trust, wherein you can trust keys for someone you do not know personally but for whom someone you do trust has signed. This gets beyond the level of this document, for more information see the GNU Privacy Handbook
