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).
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:
- Go to this Web site at Comodo.
- Click the “Free Email Certificate” button.
- Supply your name and e-mail (and an optional certificate revocation password)
- 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:
- Open Keychain Access (in Macintosh HD > Applications > Utilities).
- Drag the .p7s file to your Login keychain, confirming any messages that show up.
- Click the My Certificates category, and note the certificate (it should be named after your e-mail address).
- Expand the certificate and double-click the key listed under it.
- Click the Access Control tab.
- Choose “Confirm before allowing access” and click the plus button to add the Mail application to the list.
- 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:
- Enter your recipient’s e-mail address in the To field.
- Ensure you are sending your message from the e-mail account for which you created the certificate.
- Click the starburst button to sign the message.
- 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):
- The recipient replies to your e-mail.
- The recipient ensures a certificate-associated e-mail address is used to send the message.
- The encryption button will now be active.
- 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.
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).
Excellent writeup, TK. Thank you.
I read that as long as “Use SSL” is enabled, sessions with iCloud are encrypted. What is the relationship between this and certifying encrypted email as described in the article? If the other sender or receiver is also an iCloud email address? If the other sender/receiver is a non-iCloud address?
The “Use SSL” option in the email account setup is for encrypted authentication and communication between your email client (ie, Mail) and the server, which prevents interception of your username and password when you log into the server.
This uses the SSL certificate issued by the server to similarly encrypt content, but only does so for the communication stream when you access and download messages. The content of the messages will still be stored in plain text, so technically a server admin can go into your e-mail account and look at your message content.
The use of S/MIME applies the same encryption, but does so for the message content between two email clients (yours and your recipient), as opposed to authentication and communication stream between your email client and the server. Ultimately its a similar routine for securing data, but does so on a different level.
Thanks! So does this mean that for iCloud emails, the content as well as ID/PW is encrypted between me and iCloud servers, even through routing in between (say, my ISP)? Then the content is stored in plain text only on iCloud server?
That’s correct. Only the ID and password, and the data stream that you send to the iCloud servers are encrypted (through your ISP and whatever route it takes to get to the servers). This is the connection and upload/download actions that your system has with iCloud, and it is secure. However, once transferred, the message itself is not encrypted.
There is the possibility that Apple has services that encrypt all iCloud data, just like having FileVault enabled on your Mac, where anything stored on the drive is encrypted. If this is the case, then data specifically stored on Apple’s servers is safer, but the nature of email is that the messages will be on your server as well as on the recipient’s server, so once off of iCloud’s servers it will be more vulnerable. Encrypting the email content itself will ensure that it can only be read by the person who has the private decryption keys in the SSL certificate (ie, the intended recipient).
A similar situation would be like copying a text file to a USB drive, where when connected to your system and in your possession the drive and its content are relatively safe. However, if you give the drive to a courier to deliver, then that courier could read its content. The S/MIME encryption is like you putting the text file in an encrypted disk image with a password that only the recipient knows, and then putting that image on the USB drive. In this scenario, the courier couldn’t read the content in any system, and you and the recipient know the content is safe, regardless of who handles it and where it resides.
Good! Thanks! So if I am exchanging email with another iCloud user, the only place the content would be vulnerable is on iCloud servers. And presumably, if the other party with a different server (say, Comcast) is also using SSL, the same would be true. So an interloper would need access to the mail server to read the content.
In other words, email using SSL is encrypted between user and server and cannot be simply intercepted from the data stream.
That’s correct. Using SSL in Mail will protect the data stream, and S/MIME will protect the content of your message.
I’m having trouble installing the certificate in my keychain. When I open the certificate and it loads into my keychain, it’s stored under Certificates and not My Certificates. So it does show up and everything. But there is no arrow to expand the certificate showing the key and allowing Mail to gain access to the certificate.
When I compose an email, no new buttons show up in regards to applying the key or signing the email.
Hello and thank you for this great article,
Well I have two devices, MacMini and MacBook Pro,
I successfully added this certificate for my MacMini but in my MacBook pro when I drag the *.p7s file into KeyChain Access there no expansion triangle located at the right side of my certificate.
Should I get a new certificate for my MacBook Pro ?
I would really appreciate if you help me regarding this issue.
P.S. : I am trying to install this certificate for the same email.
Thank you very much.