Basic Email Encryption and Authentication for Lawyers
Some compare email to sending a post card via postal mail. As an open format, standard email is potentially readable by any intervening person. Encrypting email provides some privacy and confidentiality protection by obscuring the text of the email. Encryption uses a computer algorithm to transform the plain text email into an encrypted email. Perhaps surprisingly, many email clients (MS Outlook, Thunderbird, etc.) include at least one form of built-in email encryption. Furthermore, email encryption tools can also serve as an “authenticating signature” and confirms the message’s origin—this email came from A.
Two common forms of email encryption are 1) S/MIME and 2) OpenPGP (derived from PGP and including open source implementations such as GNUPGP). [FN1] Both S/MIME and OpenPGP use public-key encryption (PKI) models. Put simply, PKI uses a easily distributed public key to encrypt a message and then a private key (NEVER shared) to de-crypt the message. Think of this as the public key acting a padlock and the private key as a key to the padlock. You distribute (opened) padlocks to all persons with whom you want to send encrypted email. The person sending you the email “locks” the padlock before sending. When you receive the email, your private key opens the padlock. [FN2]
While S/MIME and OpenPGP provide encryption and authentication, the models differ primarily on how the key itself is authenticated. S/MIME uses hierarchical trust authorities (companies) who “sign” the key, issue a certificate to the key holder, and stand behind the signature. In other words, the trust authority says: yes, this key belongs to X because we confirm so, and this certificate says so. Usually, the trust authority charges a fee for this service—typically, about $20.00 per year per certificate. OpenPGP (and variants) use a different model. OpenPGP uses a non-centralized “web of trust” where peers authenticate keys. In this model, trust arises from the person signing the key—in other words, do you trust the person who signed this key? OpenPGP is free.
Which is better? That really is not the proper question. Each model has risks and benefits. Both provide legitimate encryption and authentication functions. For example, S/MIME carries annual fees and is tied to a specific email address. OpenPGP is slightly more difficult to install and relies on peer-authentication (requiring more diligence).
Installation and Use of Encryption
OpenPGP requires the installation of a basic package of encryption features in your email client (MS Outlook, Thunderbird, etc.). These packages are freely available (e.g., start at GNUPGP). The basic steps are:
- download the tools,
- install OpenPGP,
- install the email client plug-in,
- generate public and private keys,
- distribute the PUBLIC key, and
- backup the public and private keys.
Once installed, when creating an email, you simply obtain the public key of the person to whom you are sending an email to and then encrypt the email using his or her public key. (The email client automates much of this process.) [FN2]
Most email clients include the S/MIME tools. Thus, the “installation” centers on obtaining the S/MIME Certificate from a certificate authority.
- obtain S/MIME certificate from a trust authority,
- install certificate in email client, and
- backup the certificate.
Trust authorities operate on two models. Some provide a publicly accessible access to S/MIME certificates issues by the authority. Others rely on the certificate/key holder to manually distribute his or her key to others (or use a company-wide certificate server). Once installed, the process parallels OpenPGP: obtain the public key of the person to whom you wish to send encrypted email and use his or her public key to encrypt the email.[FN4]
S/MIME and OpenPGP also provide an optional authentication function. This gets confusing (see my prior footnotes before proceeding). The encryption process uses the PUBLIC key of the person to whom you are sending the message to encrypt the email using the recipient’s public key. However, you can also sign the email using your own PRIVATE key allowing the recipient to use your public key to authenticate that the email indeed came from you (after all, you alone have the private key). In other words, while both acts use the SAME system, you essentially double-processing the email. One process encrypts the email using the RECIPIENT’S public key. That email is then additionally “signed” using your private key—an envelope within an envelope metaphor. So, when you send an email, you can “sign” the email using YOUR private key to authenticate to the recipient that the email originated using your key (they use your public key to authenticate the signature). The recipient uses his private key to de-crypt the message.
Confused? Think two envelopes: 1) internal envelope secured by encryption using the public key of the intended recipient and only able to be opened by the recipient and 2) an optional outer envelope signed using your private key saying “this is from me” and the recipient uses your public key to authenticate the signature.
Authentication can be used alone (one can simply sign emails to verify origination) or combined with encryption (saying: this email came from me according to my key and is only “openable” by you according to your key). Furthermore, some email clients allow automatic “signing” of all outgoing messages—a convenient way to distribute your PUBLIC key.
OpenPGP and S/MIME provide encryption and authentication functions. Both require some additional, but not onerous, steps to use on a daily basis. The installation looks formidable but is fairly straight-forward. The biggest stumbling-block is probably understanding how PKI works. For lawyers, both options provide a easy means to encrypt and authenticate email. [FN5]
Thank you to Nick Barrett for pointing out an error in the original article.
FN1—PGP has a long, convoluted history, but the trademark, PGP, is now owned by Symantec. OpenPGP is the freely available version. See http://www.openpgp.org/.
FN2—See Public-key cryptography.
FN3—Important concept: You encrypt an email using the public key of the person TO WHOM you are sending the email. Example: A wants to send an encrypted email to B. A obtains B’s public key. A encrypts the email with B’s public key. When B receives the encrypted email, B’s email client decrypts using B’s private key. See Public-key cryptography.
FN5—Authenticate here is used in an encryption sense, not a legal sense. The authentication merely shows the email originated from a specific key not that the key owner physically sent the email. Example: C sits at A’s computer while A is logged in and at lunch. C uses A’s private key to send a “signed” email to B. B gets the email. The email is authenticated to A using A’s public key but that does not mean A, herself, sent the email—the nefarious C sent the email. Lesson: always log off when you computer is not in use.
Original Post Date: March 11, 2011
Updated: 06 July 2011
Updated: 14 June 2017