I met Matt Eshleman, Chief Technology Officer at Community IT, at NTC 2018 in New Orleans. After sitting through his session, I asked if he'd be willing to answer a few questions for our blog, and he graciously agreed. Thanks for taking the time to respond to our questions, Matt!
Q: Why would a nonprofit organization want to encrypt its email messages?
There are many reasons why an organization would want to encrypt email. They generally fall into the broad categories of compliance and risk management. Many organizations are subject to various types of compliance regulation, such as the Health Insurance Portability and Accountability Act (HIPAA), which require that Personally Identifiable Information (PII) be transmitted in an encrypted format. There are also scenarios in which certain information poses a serious risk to the organization, such as nonprofits working on sensitive human rights issues. It might be important to ensure that only the intended recipient is able to read the message.
Q: How exactly does email encryption work? 
Think of encryption as putting the information in a safe that has two keys. The person who puts the information in the safe has one key, and the person (or people) authorized to retrieve the information has the other.
Speaking more technically, there are three methods for encrypting email, each of which involves a different tradeoff between convenience and security.
Client-Side
This is the most difficult to manage, but also the most secure. This form of encryption is performed on the sender’s computer through Pretty Good Privacy (PGP), which uses a public/private key pair to encrypt the message. Wikipedia has a detailed, but accessible, explanation of how PGP works.
Basically, the sender encrypts (or locks) the contents of a message using the intended recipient’s public key and their own private key. This means that PGP email requires both the sender and receiver to have PGP configured. (You can see if someone has PGP configured by looking up their address in a public key server. One example is https://pgp.mit.edu/, where you can see that the PGP public key for meshleman@communityit.com has a key ID of 18ADAEAB.
Client-Side encryption is the most secure method, because the email remains obfuscated at rest. Even if an attacker hacks into your email account, they would see something like this:
----BEGIN PGP MESSAGE-----
hQIMA1FQcjrGWGOLAQ//ZUMnINLC0Td20dAIVVtdIrOFBqZDwAcJKJbVam8krNFE
VIX3nOqvjLCU0qwIHAj2Gnx5hr0IxPa+3Qpms/SaIAiFBCb1isqc+DebMQaS+9eZ
UIOJZStPglEkgWp471IX5pjBp4fkMFxj8gywJf1Fn2XB90Vyxpbif+LFw2Rl8VpN
E1bY/u6a+BwqyYFFrkwYxaTMqpJaQRmBpoJltH/zgNVe2/gD5BglvsV+Bo5rxWU5
Gr6hT13+nGbpARap08lVJbKlzNmkFgITKM7KiQSeTrOGwJ5d7rvBLRDFE4IOco65
ocy4Wo08OT0etm0nRWGd1WRV1dqdaEdpRVzk5b7YLoGRcpD41u697oEa21N7QHDM
Server –Side
This is the easiest type of encryption to implement. It is email encryption that is performed by the mail server. Office 365 E3 includes the ability to send an “encrypted” email. The sender encrypts the message using a pre-defined tag, most commonly in the subject line, and then sends the email. The Office 365 transport service identifies the tag and encrypts the message.
The recipient receives a notification that they’ve received an encrypted email that requires them to click on the link to a secure webpage where they can login with a “Microsoft Account” or request a OneTimePasscode to login and view the message. The message can be replied to, but if it is forwarded, the next recipient is unable to access the email because they were not the original recipient. The email message is in plain text on the sender’s computer, but the message does not reside in the recipient’s inbox.
This method is not quite as secure as Client-Side, because Microsoft owns both keys. In practice, Microsoft would only allow the intended recipient to use the key to unlock the message. However, if subpoenaed by a government, for example, they would be able to use the key to unlock the message.
Transport-Side
The third type of email encryption doesn’t rely on you, as the sender, to do anything. In that sense, it is entirely seamless. Most large email providers, including Gmail and Office 365, have implemented Transport Layer Security (TLS) encryption for messages in transit, which is a technical evolution of Secure Sockets Layer (SSL) encryption, and which can be thought of as “SSL for email.” (Wikipedia also provides a more detailed explanation of this method.) Enabling TLS or using a TLS-compliant email service ensures that no one can read your email as it is in transit between another TLS compliant provider.
In the example below, we can see that I have received a message that was protected by TLSv1.2
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) by mx1423.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 03 May 2018 13:20:40 +0000
Received: by mail-lf0-f48.google.com with SMTP id v85-v6so25907237lfa.13
for <MEshleman@communityit.com>; Thu, 03 May 2018 06:20:41 -0700 (PDT)
Q: What are some practical options, including some for organizations with a very small budget or low technical skill?
Increased security always requires a tradeoff with convenience, just as having to carry around and use house keys to unlock your house is less convenient than opening the doors or remembering the PIN code of your ATM card is less convenient than putting the card in the machine. First and foremost, organizations have to be willing to make that tradeoff.
The good news is that, in terms of financial investment, implementing email encryption is generally low-cost for either software or services. The more significant investment is in end-user training, and perhaps most importantly, creating a culture of accountability.
Because it will require buy-in and enforcement to be successful, a clear understanding of organizational requirements is the best place to start. Is your organization sending PII to another partner organization? If so, then implementing Server-Side encryption would be an easy place to start.
Or, perhaps your organization is a government watchdog or whistleblower organization. Client-Side encryption may be a better fit for you, as it allows you to send secure messages through untrusted channels. It also has the benefit of having the email messages encrypted at rest in case your device is lost or stolen.
Q: Are there any misconceptions about email encryption that you'd like to clear up right now?
Perhaps the biggest misconception is that email encryption is only needed for super-secret communication. In fact, with the addition of TLS for the big email providers, you are probably already using some form of encryption!
There are a number of use cases where email encryption is useful, and there are a number of great step-by-step resources out there for implementing a variety of email encryption tools. Here are a few to get started:
Matt Eshleman is Chief Technology Officer at Community IT. He is responsible for shaping Community IT’s strategy in assessing and recommending technology solutions to clients. With a deep background in network infrastructure technology he fundamentally understands how technology works and interoperates both in the office and in the cloud. Matt joined Community IT as an intern in the summer of 2000 and after finishing his dual degrees in Computer Science and Computer Information Systems at Eastern Mennonite University he rejoined Community IT as a network administrator in January of 2001. Matt has steadily progressed up at Community IT and while working full time received his MBA from the Carey School of Business at Johns Hopkins University.
