Even though we have modern messaging technologies like Apple’s Messages that default to encrypted communications, we still primarily use e-mail, even for sensitive business transactions. If you have several partners that you would like to communicate privately with, then while you can resort to an encrypted collaboration platform, you can also do so via classic e-mail, with only a few steps taken for each person.

There are many tools that you can install on your Mac to provide a layer of encryption for e-mail, but an easy one that is built in is S/MIME encryption, where you use certificates to verify identity and use public and private keys to encrypt messages. If this sounds daunting, it can be done without you needing to understand any details of the encryption process (though I will outline it below).

The basics of what you have to do are the following (this will have to be done separately by both people who are trying to encrypt messages to each other using specific e-mail accounts):

1. Obtain a certificate for your e-mail account

There are several places you can get a certificate, but a common one that’s free is Comodo’s SSL Certificates for e-mail, a UK-based certificate authority:

1. Go to this Web site at Comodo.
2. Click the “Free Email Certificate” button.
3. Supply your name and e-mail (and an optional certificate revocation password)
4. Wait for the e-mail confirmations, which will contain a link to download your certificate.

2. Install the certificate in your keychain

The file downloaded will likely be named “CollectCCC.p7s,” which is a certificate file that contains your private key. This is important to keep in a secure location, so save it somewhere on your computer. You then need to ensure it is installed in your Mac’s keychain:

1. Open Keychain Access (in Macintosh HD > Applications > Utilities).
2. Drag the .p7s file to your Login keychain, confirming any messages that show up.
3. Click the My Certificates category, and note the certificate (it should be named after your e-mail address).
4. Expand the certificate and double-click the key listed under it.
5. Click the Access Control tab.
6. Choose “Confirm before allowing access” and click the plus button to add the Mail application to the list.
7. Save the changes and quit Keychain Access.

3. Compose new messages to distribute your public key

Now you can create a new message in Mail, and the program will automatically make use of the digital certificate for signing and encrypting messages. Upon composing a message, you will see two new buttons in the message window: one that looks like a lock for encrypting the message, and another that looks like a starburst for signing the message. Both of these are necessary for proving your identity and subsequently encrypting messages, though only the starburst one will be usable initially.

Note that at this point, I am assuming both you and the person you are trying to send encrypted messages to have performed the above steps and have separate personalized SSL certificates installed. You two are now primed for encrypting your messages, but will first need to use your certificates to “prove” to each other that you are who you say you are:

1. Enter your recipient’s e-mail address in the To field.
2. Ensure you are sending your message from the e-mail account for which you created the certificate.
3. Click the starburst button to sign the message.
4. Send the message to your recipient.

4. Receive a reply to get your recipient’s public key

Your recipient should be able to read your e-mail and see that it is digitally signed. The signature can be verified by clicking on it, but now the recipient will have a public key for your certificate, that is stored in the recipient’s keychain. If the recipient has similarly installed a certificate for his or her e-mail account, then he or she can send you an encrypted e-mail reply (or compose a new e-mail to encrypt):

1. The recipient replies to your e-mail.
2. The recipient ensures a certificate-associated e-mail address is used to send the message.
3. The encryption button will now be active.
4. The recipient clicks both this and the starburst button to sign the message before sending it.

The message will arrive to you in encrypted form as an “smime” attachment that can only be read if you have the private key for decrypting the message (which you should have if the message was encrypted using your public key). Since the recipient signed the message, you will also get his or her public key certificate automatically installed in your keychain. Note that you may see a warning that asks you to confirm access to your keychain’s certificate for the decryption process.

Troubleshooting

If the decryption cannot occur, then you will see a blank message with an attachment called “smime” in it. If this occurs, then you need to ensure you have the recipient’s certificate in your keychain. Sometimes you may also have problems with your keychain that can affect the certificates stored in it. To address this, select your login keychain in Keychain Access and choose Keychain First Aid from the Keychain Access menu. Choose “Repair” and click the “Start” button. Finally, sometimes Apple’s security frameworks may not properly handle the changes to the keychain, which often will be accompanied by odd requests to authenticate for accessing various online services. If this occurs, you can log out and log back into your account (or restart your Mac) to refresh these and hopefully have the certificates and your keychain be accessible again.

Removing encryption options

Signing and encrypting e-maill messages is optional, even if you have certificates installed; however, if you wish to revert your system then you can go to Keychain Access, locate the Comodo certificate you installed for your email account (searching for your account will help locate it), and then remove it. Now quit and re-launch Mail, and your account should no longer have options for signing and encrypting messages.

How encryption and certificates work

Encryption requires a key (ie, a password) that is used in a cipher algorithm for scrambling data, such that only that key can be used to unscramble the data. One way of doing this is to encrypt data with a single key and then share that key with others so they can decrypt the data. This approach has an obvious vulnerability in that the key is generic (ie, can be used anywhere) so it can be stolen to then access your secured data.

A second and more secure approach is to have one key for encrypting data, and another associated key for decrypting data. The key for decrypting is kept private by you, and the one for encrypting can be used by anyone to encrypt data sent only to you, but cannot be used to decrypt the data. Now the data can be encrypted by them and sent to you, and you can use your private key to unlock and read the data. In essence, you create a setup that tells people you can unlock the data they send to you, provided they encrypt it with the public keys that you give them. This is a basic look at the pairwise approach for encryption that SSL uses.

For the e-mail encryption we set up above, these keys are issued as part of the certificate you got from Comodo. When you installed this in your keychain, both the private key and its associated public key were installed in your keychain. When you sign your e-mails, you are giving this public key to your e-mail recipient, telling them to use this when they wish to encrypt messages they send back to you. You can do the same for them, provided they have a similar certificate setup.

You don’t technically have to use certificates for distributing these encryption keys; however, the use of them folds in another layer of security by way of a trust network, or specifically the use of an uninterested third party who can vouch that you are who you say you are. This is the job of a Certificate Authority like Comodo, where through your verification email you proved to them that you have command of the current e-mail address. They trust you on this, and then issued you the certificate in their name that you can use to help prove to someone’s computer that you underwent Comodo’s verification process. (Your computer uses a Comodo-issued root certificate, installed by Apple, to compare with the certificate in your email and confirm it is from Comodo).

If the associated private key has been compromised (ie, someone has stolen it), then you can have Comodo revoke this certificate so it will not check out when being sent to someone as a signed e-mail. This will warn them that the certificate cannot be verified, and they should not use its included public key for encrypting data.

Granted Comodo’s basic verification isn’t the most robust, and there are other certificates authorities (Verisign, Geotrust, Thawte, etc.) that require far more scrutiny (perhaps even an in-person interview), but these will likely cost you a lot of money to purchase. However, in all cases, the use of the private and public keys for SSL encryption is the same. The certificate’s value is basically where it came from, just like a robust PhD diploma certificate from a university that proves you underwent the classes and education necessary for the degree. You pay a lot for this certificate in terms of money and time, whereas a cheap one you get from an unaccredited institution will not hold as much weight for proving your education.

Overall, who you choose to verify and certify your identity will be important for proving this identity to other systems, and while not needed for encrypting data, is a component that ensures everyone involved with the encryption can trust each other. In this sense, if you have a reputable individual vouching for you, then you can likely get further than if you have an unknown person vouching for you (or nobody at all).