In an earlier article about email encryption I wondered why it wasn’t in more common use. One of the barriers to its adoption is the hassle in exchanging public keys.
[A brief primer: for me to send you an encrypted message I have to lock it up with a public key that you provide to everyone. The message can then only be unencrypted with a private key, which you keep to yourself. Before I send you something secret I must first obtain your public key, which can be a hassle. Today the typical way to get someone's certificate is for them to send you a signed email.]
Trading public keys for the first time
The basis of this approach is to have the email clients talk to each other about the public keys. Once that’s established then your secret message can be safely passed along.
Here is the outline of a typical interaction of sending an encrypted email to someone for the first time:
- User A tells his email client to send User B an encrypted email
- A’s email client sees that it doesn’t have B’s public encryption key, so it can’t yet send the message
- A’s email client keeps the email queued up and sends B’s client a request for her public key. This is just a regular email message in a format that will be automatically recognized by B’s client.
- B’s email client automatically responds to the request with B’s public key. The request for public key is human-readable. So if B’s email client does not know this protocol, user B sees something like this: "This message is a request from A a@a.com for your public key, in order to send you an encrypted message. Please reply to this message with yor public key. If you are not sure how, click here."
- User A’s email client receives B’s public key, and incorporates into B’s contact information silently.
- User A’s email client sees that it has messages awaiting B’s public key. It encrypts and sends the message.
The net result is that secure email can be traded as usual, with the details worked out by the clients. It cuts out middlemen "Certificate Authorities" who collect and distribute public keys. If someone needs to send something sensitive to someone who is not yet setup for encryption, it lays a clear path for that user, alleviating the burden on the sender to educate the recipient.
Bonus security: Making sure B is really B
Security freaks may be concerned that someone who is not B may intercept my request, impersonate person B, give a fake public key and get me to send the secret message to the bad guy. This concern seems most directly addressed with a dose of lithium.
Nevertheless, if it really becomes necessary to make sure that B is who B claims she is, here is a more natural way:
- At step 2 above, A is prompted for a question to ask B that is something that only B could answer: "To make sure this message is really going to John Smith, please enter a question that only this person will be able to answer (eg. your nickname or a piece of information you recently told B verbally)."
- Person B receives the request as an email message and replies with the answer to the question.
- Person A receives the response with B’s answer to the question. A’s email client asks the user to accept or reject the answer. When the response is accepted the accompanying public key is associated with B’s contact record.
Again, this is probably not necessary for 99.9% of cases and should be avoided, as it adds another geeky layer.
Forcing corporate and government employees to exchange encrypted email
What can executives appalled at the corporate secrets coming and going through the ether do? They could establish a corporate policy that blocks unencrypted emails from leaving the premises. This would quickly force insiders and outsiders to play by the rules: no unencrypted email exchange with the outside world. [Anyone know of corporations with such policies?]
What about partners sending things in? Even more heavy-handed policy would be to prohibit incoming email from being delivered without encryption. The gateway at the corporate boundary would automatically bounce-back a message, telling outsiders to resend the message with encryption, and link to clear step-by-step instructions for setting this uip.
A more humane variant would allow the first x (say 3) messages through without warning, to allow for sporadic inquiries. The next y (say 5) messages would also be allowed through as a grace period. The outsider would be forewarned that ongoing communication will require that future messages be encrypted, and provided instructions for setting it up and the public key of the recipient. Finally, subsequent messages would be rejected. The recipient inside would be notified that a message from that user was rejected.
These policies would get outside partners onboard with encryption very quickly, plugging the inadvertent exposure of sensitive information to the open Internet.
See also
Questions for Readers
- Has public key trading been solved in a better way yet?
Forcing employees to send and receive only encrypted mails would be troublesome.
The sales people would raise high holy hell if their customers and especially their prospects could not email them without encryption. Same thing for customer support people.
What about all the automated emails that get sent from various systems and servers being run internally? Many of these servers are software bought from a 3rd party and the company cannot easily modify them to send encrypted mails.
So while I agree that encrypted mails are a good idea for companies, it is not feasible to mandate encryption.
Also, another idea on the way public keys should be traded is a DNS-like lookup system for public keys. Once a certificate authority provides a public key to an email address, this key would be shared and forwarded amongst all the authorities in the same way that a domain name is shared and forwarded amongst DNS servers. To go along with this, a new type of key lookup server would be implemented. This server could be run by the certificate authorities, ISPs, or even particular techie people on their linux box at home. The final piece is that email client software should be able to look up any email address to on this server to see if there is a public key registered for it. If so, it can use it for encryption. The user should even be given the choice of whether to use this key automatically when sending emails in order to encrypt them whenever possible.
As more and more people sign up for encryption, this type of system will become more and more useful.
Someone please write a standard for this!