We have looked at e-mail encryption on both Thunderbird and G-Mail, and that is good, but in 2014 a lot of people use mobile phones and tablets for their e-mail. So it makes sense to look at how we can do this. The solution I am going explore here involves two components, the K-9 Android mail client, and APG, the Android Privacy Guard. I am going to stick to what I know, so if you are looking for help with iPhone or iPad, the best I can do is suggest that you try a Google search. On Android, while many people use Gmail, K-9 is a very popular client for people looking for a more traditional POP3 or IMAP client to handle their e-mail needs. So this should be a good solution for many people. As regards APG, I am not aware that anyone has done an audit of this program. It seems to be the most widely recommended, and is probably OK, but I am making no larger claims for it.
Installing APG and K-9 is just the usual process of going to the Google Play Store and clicking the Install button. When both programs have been installed, you need to configure them. Start by doing the usual configuration of your e-mail account in K-9. I will assume you don’t need any particular help on that, it is the usual configuration for account type, login name, password, SMTP server for sending out mail, and IMAP or POP3 server for incoming. Make sure this is correct by connecting to your mail server, sending a test e-mail, etc. When that is done, verify that you have a public and private key available. In our Gmail tutorial we looked at how to export those keys from your desktop computer. Review that information if necessary. You will need to have both of these keys in ASCII form before you can make this work. You need to copy these keys from your computer to your phone. There are different ways to do this, but I am going to do it using a program called AirDroid (also available in the Play Store) that lets you connect via WiFi. In brief, AirDroid creates a Web server on the phone, and you connect via your browser.
Install AirDroid as usual from the Play Store. On some newer Android phones an icon will automatically be placed on your screen, but if not, go to your Apps Drawer and open it. It will give you an address it picks up from your WiFi router. Usually your WiFi router will assign addresses from a non-routable range of IPv4 addresses, such as the 192.168.xxx.xxx range, and AirDroid will pick one of those, and tell you to open it in your browser. It will also specify port 8888, entered after the address and separated by a colon. So the address to put in your browser will be something like 192.168.1.18:8888. This will be sent to your phone, and then you will be asked to approve the connection by pressing a button on your phone. Use the Upload function on the right of the browser page to upload your keys. If you exported both the public and private key as one operation, it will be a single file. This will go to the AirDroid Uploads directory.
Next, you may need to use a File Management tool. In my experimenting I found that APG did not see the AirDroid Uploads directory, but when I installed ASTRO File Manager it integrated with APG and let me see the file. In APG I then clicked the Import button, and my keys were imported. You need to do it one at a time (once for Public, once for Private), but once you have imported them you should be able to send and receive encrypted e-mails.
Note! Important! Danger, Will Robinson! : You just added your private key as an easily readable ASCII file to your phone. Anyone who can get your phone can get your key. I would delete this file as soon as you have things working. Depending on your jurisdiction and its laws you may not have any right to privacy in the contents of your phone, and the authorities will probably be overjoyed to get this kind of information. You have been warned!
With your keys in APG, you should find that K-9 has added a few things. Open the Compose window and you will now see two check boxes right under the To: field, and above the Subject field: One for Sign, and another for Encrypt. You can sign your e-mails right away. Just put in a check mark, compose your e-mail as usual, and when you click Send you will be asked for your passphrase. Enter your passphrase, and your digitally signed e-mail is on its way.
Sending encrypted e-mail requires a little more. Recall that you need to know the public key of the recipient of the e-mail if you want to send encrypted e-mail. You can search for keys to import from the public keyservers within APG. Click the hamburger icon in APG in the upper left, next to the key icon, and in the menu that appears you will see Import Keys. This will bring up a search window where you can search for keys. The default search server is pools.sks-keyservers.net, but clicking the drop-down will let you choose sobkeys.pgp.net, or pgp.mit.edu as alternative servers to search. Given that all of these servers sync with each other I don’t see any great reason to prefer one to the other, but perhaps the key you want was just uploaded to the MIT keyserver two minutes ago and has not yet propagated to all of the other keyservers yet. In any case, you can type in a name in the search box and click the button. When you get a result you like, you can import her public key into your key ring and start sending encrypted e-mail to her. One thing you need to keep in mind is that each device has its own key ring, so if you commonly correspond with people from your laptop, desktop, and smart phone, you need to import each key three times.
On any device, whether a phone, laptop, tablet, or desktop, you should have something called a key ring which is simply a database of the keys you know about. In Linux this is usually provided by the operating system as a standard service, and in Windows it is more often provided by the PGP software. Your own key pair will be stored there as well as the public keys of all of your correspondents. Generally, a key is given a short 8-character identifier. For example, if I go to http://pgp.mit.edu, I can type in my own name (Kevin O’Brien), and get back a list of results. At the top of the list is this entry:
pub 2048R/E50BB64E 2013-11-02 Kevin O'Brien (Encryption is great!)
This tells me that I can download the public key, that it is a 2048-bit key, and has the identifier E50BB64E. It was created on November 2, 2013, belongs to Kevin O’Brien, has the Comment “Encryption is great!”, and the e-mail address firstname.lastname@example.org. If I click on my name, I get a little more information. such as that this key was signed by my friend Tony Bemus. Going back to the search results screen, if I click on the 8-character Key ID, I get the actual public key, which is also on the About page of this web site. It looks like this:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: SKS 1.1.4
Comment: Hostname: pgp.mit.edu
—–END PGP PUBLIC KEY BLOCK—–
The pretty much universal way to import keys is to copy all of this text, including the BEGIN PGP PUBLIC KEY BLOCK and the END PGP PUBLIC KEY BLOCK, and paste it into a window in your software. Sometimes you can import using just the 8-character ID, but not all software handles this. Remember that the Public key is intended to be completely public, and can only be used to encrypt a message being sent to you. Many people do what I have done in putting their Public key on their web site. For example, Bruce Schneier has his on the Contact page of his web site. So there is nothing wrong with doing this, it just makes it easier for people to send you e-mail. As an example of use, if I open Mailvelope, and go the the Import page (Options, Import Keys), there is a text box where I can just paste in the text of the key, and I am ready to send encrypted e-mail.
Of course, as you might imagine people who use encryption tend to be very careful about using these keys, for the most part. A big issue is how much to trust the keys. I would not trust any key I got from searching on a public key server without some added corroboration. Because it is simple for me to create a key, claim that my name is Bruce Schneier, and attempt to divert his correspondence to me. Since I created the key, I could decrypt any messages encrypted with it. This is called the trust issue, and the answer is the Web of Trust. This is not 100% foolproof, but is reasonably secure if you take care. For instance, one of my correspondents is Tony Bemus. How do I know that the key I am using for him is really his key? Well, I know Tony personally, I have been in the same room with him, I know his voice, etc. so I can pick up the phone, call him, and ask if DB471CEE is really his key. This is also important in case of a name collision. I know there a lot of people out there named Kevin O’Brien, and some of them also have keys.
The next layer in this model is key signing. I mentioned that my key was signed by Tony. If his partner on the Sunday Morning Linux Review podcast Mary Tomich was looking for my key, she might see that Tony signed it, and give it a higher level of trust if she already trusts Tony. And if you looked a key that claimed to be Bruce Schneier and saw that no one had ever signed it, you would be suspicious since Bruce is very well known in the Security space. But note that qualification. If someone is known to sign anything without checking, it would be prudent to discount that trust on anything they have signed. One way keys get signed is at Key Signing Parties which often take place as part of techie conventions and such. The way these generally work is that you come with your 8-character ID, and some good identification (passport, driver’s license, etc.) and other people there look at your identification, and if they decide they like the look of it, they can take your 8-character key and sign it. It is a good idea to have this on slips of paper you can give out, because often people do not sign right there, but take it home to sign in the next few days. The more signatures you get, and the more trustworthy the signers are, the more your key would be trusted.
There are different levels of trust, and when someone signs your key they indicate just how much trust they are putting into it. The Gnu Privacy Handbook lays this out as
Nothing is known about the owner’s judgement in key signing. Keys on your public keyring that you do not own initially have this trust level.
The owner is known to improperly sign other keys.
The owner understands the implications of key signing and properly validates keys before signing them.
The owner has an excellent understanding of key signing, and his signature on a key would be as good as your own.
I have seen it slightly different, but this is the general case. Personally, I would never trust anyone’s key as much as I do my own. If I were signing a key at a key signing event and it is for someone I don’t personally know, I would probably choose “unknown”.
This will probably wrap up the discussion of encryption and e-mail for the time being. Next we will move on to a general model for understanding security, courtesy of Bruce Schneier.
Listen to the audio version of this post on Hacker Public Radio!