4 Ways Educational Institutions Can Encrypt Emails

Organisations and institutions have a very important role to play in the protection of sensitive data. Protecting data is cumbersome enough without diminishing budgets and a complex market of solutions. This guide aims to explain the four main encryption methods for email and explain the drawbacks and challenges with each approach so that you can make the decision that’s right for you.

Every organisation and institution is different and will have different IT infrastructures and resources to begin with. There is no right or wrong answer and often the solutions that you need will require using more than one encryption method.

It is helpful to think about your current infrastructure, the resources available in your IT department and the budget you have as key factors in making a decision. It is also helpful to think about what you want encryption to achieve.

Practically speaking, educational institutions (EIs) need to protect sensitive information about students in an ecosystem that involves parents, school staff and students emailing each other and third-parties outside of the EIs ecosystem. Encryption plays a vital role but only if the right information is being encrypted and only when the right people are able to decrypt that information. This ensures that the messages aren’t intercepted in transit, that they’re sent from a verified sender and that they arrive, unchanged, in the recipient inbox.

TLS Encryption for Email

Transport Layer Security or TLS encryption can be used to secure the connection between two mail servers. This means adding an additional layer to the existing Secure Mail Transfer Protocol (SMTP) used to send and receive emails.

To use TLS Encryption both servers need to have a digital certificate (usually purchased from a Certificate Authority). A certificate contains a public and a private key. A key is simply a long string of characters that serves as a “password” to decode encrypted data.

The public and private keys of a certificate are mathematically linked so that a public key can be used to encrypt a message and can only be decrypted by the corresponding private key.

For example, in a message between Alice and Bob, Alice encrypts the message with Bob’s public key. Bob can only decrypt this message with his private key.

The reliability of TLS encryption is based on the fact that a user keeps their private key private. If a hacker or third-party gets access to the private key, the system is no longer deemed to work.

Before a data transfer between servers, a digital handshake takes place where the servers:

1. Specify which version of TLS they will use.
2. Decide on which cipher suites they will use.
3. Authenticate the identity of the server via the public key and the certificate authorities’ signature on the TLS Certificate.
4. Generate a session key for continued encrypted communication.

Without the of TLS in the exchange of email between mail servers, the email message and contents would be readable in plaintext. This means anyone with access to the email server can read the entirety of the message contents.

But, one of the drawbacks of using TLS for email encryption is that TLS is intended to “fail open”, which means that in the event of a sending failure, the message still sends but unencrypted. This is the automatic response of the server.

For educational institutions reading this and wondering how TLS encryption translates to better security, there are some downsides. When an email is sent, it can bounce from server to server before it reaches its intended destination. TLS encryption tries to ensure that the message contents are hidden during this journey but if it can’t be, the message will still send unencrypted and be visible in plaintext.

A final point to make is that even if the message is encrypted, the meta-data is still public. The meta-data includes the recipient and sender identity (email address), the subject line, attachments and the date and time of sending. Many of these areas can contain sensitive and confidential information that hackers can still get access to.

S/MIME for Email Encryption

S/MIME Certificates are very similar to TLS Certificates in that they use public key cryptography and are issued by a Certificate Authority (CA). The important distinction between TLS and S/MIME email encryption is an important one to make. TLS Encryption used across the SMTP protocol is simply encrypting the connection, S/MIME is about encrypting the message itself. TLS Certificates are therefore issued to and installed on a server while S/MIME certificates are issued to email addresses and installed on a client or device like a mobile phone.

This is an important distinction since a connection can be hijacked and once an email is delivered, it is no longer protected under TLS Encryption. S/MIME encryption ensures the message itself is encrypted, protecting it in case the connection is hijacked and when the message is delivered. S/MIME encryption is used to offer full end-to-end encryption where recipients and senders can be reassured that S/MIME is protecting their messages from being read by a malicious third-party, or even by email providers.

There are some challenges that come with S/MIME encryption. One of the biggest being management of certificates. Organisations looking to secure internal emails often look at S/MIME as a solution but if certificate management is not done right, it doesn’t just reduce the likelihood of full end-to-end encryption, it can also create a vulnerability in your organisation for hackers to exploit.

Schools must ensure:

• each employee email address has an S/MIME certificate,
• these certificates are installed correctly,
• employees are trained on how to use them within the tools provided,
• certificates do not expire,
• certificates belonging to employees who leave the organisation are revoked as soon as they leave.

You can see how these tasks become a heavy burden for organisations who have hundreds, possibly even thousands of employees.

Another point to make is that S/MIME messages cannot be fully encrypted unless both the sender and receiver have a certificate and exchange public keys first. Then the message can only be read on a device where the S/MIME Certificate has been installed.

This is easy enough to manage on an internal network but the chain of encryption is broken when you email anyone outside of that network. Finance departments who are sending and receiving sensitive information from customers won’t be protected if customers don’t have an S/MIME Certificate and they may not want one based on the cost or time it takes to implement. You could also run into issue internally when a user opens an email on their mobile device, for example, if they haven’t installed the certificate there.

S/MIME is also tailored for end-to-end encryption which means that unless the email provider has the keys to decrypt your email (which in itself is a security issue), they cannot scan emails for spam or viruses. Some providers have got around this by providing the scanning service on the end user stations after the decryption has taken place but this also creates an issue for organisations as it may already be too late by that point, malware could be delivered. Another workaround is sending the message to a malware scanning server or gateway server where encryption keys are kept and messages can be decrypted and scanned before being re-encrypted and send to the email server. This of course means that the server must be highly protected as it will be a significant attack vector.

Finally, another challenge in S/MIME encryption is the support available in existing email applications. Support varies by provider and by device so it may not always be possible to provide full support for S/MIME with every email that you send. You cannot open an S/MIME encrypted email without an S/MIME certificate yourself as the contents cannot be decrypted and therefore, they cannot be read.

PGP For Email Encryption

PGP stands for “Pretty Good Privacy” and was originally created by Phil Zimmermann in 1991 but because of concerns that a growing number of developers had about wanting access to the code to implement PGP in their software; in 1997, Zimmerman decided to apply for an open standard of PGP to the IETF. IETF accepted the proposal and started the Open PGP working group.

In 2010, Symantec bought rights to PGP for $300 million but Open PGP remains freely available online alongside standards and guidance on how to use it. The Free Software Foundation developed its own OpenPGP compliant program called GNU Privacy Guard and OpenPGP.js has also been developed to allow web-based applications to use PGP in the browser.

PGP uses multiple encryption techniques including symmetric and asymmetric encryption with several supported algorithms. When talking about a server handshake above, I mentioned that the process involves checking the digital certificate authenticity by seeing that it is signed by a Certificate Authority. PGP doesn’t rely on this same hierarchy and it’s for this reason, that Open PGP is often referred to as “decentralised PKI” and because of this, it can provide end-to-end encryption AND server to server encryption.  

The message is first encrypted with a symmetric encryption key (that is 1 key to encrypt and the same key to decrypt rather than the public and private keypairs used in asymmetric encryption). The symmetric encryption key is generated by the sender and sent alongside the message to the recipient. To protect the message during transmission (because the decryption key is sent with the message) the entire message and key is encrypted using the recipient’s public key. Once received, only their private key can open the message and once opened, the session key can fully decrypt the contents of the message.

PGP also supports digital signatures, which are similar to S/MIME in that they electronically sign the message, so that when the recipient receives the message, they can detect if the message contents have been changed during transmission and that the message was really sent by the person who it claims to be sent by.

It is critical when sending and receiving emails that the identities behind sender and recipient are known and verified. Simply downloading a public key is not enough to confirm that fact. Certificate Authorities do this with a highly secure root server that stays “offline” or off any accessible networks to mitigate risk of an attack. The root server contains all the private keys of certificate’s issued and is therefore the keeper of the identities’ behind the certificates and the decryption keys belonging to those individuals.

The way PGP gets around the need for a centralized server is to let the user’s decide who they trust. They do this by allowing them to designate “trusted introducers”, where PGP will automatically validate those trusted introducers and in turn, validate the keys belonging to the users they identify as “trusted introducers” too. This creates what is known as the “Web of Trust”.

This process was first described by Phil Zimmermann in 1992, in the manual for PGP version 2.0:

“As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.”

When making the distinction between S/MIME and PGP it often helpful to think of another quote by Zimmerman:

“PGP is for people who prefer to pack their own parachutes”.

What he meant by this is simply that centralizing key management and issuance to a Certificate Authority is not always full-proof and relies on that CA to do their job right. But this also creates problem for user’s who are not 100% tech savvy as using PGP means they would have to check certificate validity manually.

PGP also becomes complicated to implement in an enterprise/institutional environment because it’s not especially easy to use or understand and the management and storage of the keys is particularly important in maintaining the trust. Wired even published an article called “We’re calling it, PGP is dead” in 2018 which mentioned the difficulty of usability and the lack of support in common devices such as Apple Mac, iOS and Android.

The trouble is, although it is difficult to implement, it is also notoriously difficult to crack and that’s why Facebook chose to use PGP to encrypt messages, Yahoo uses it as the default encryption technique, and why Google uses it for end-to-end encryption.

PDF Encryption

Where S/MIME and PGP fail is they’re not always supported by email clients and users are not always confident with using them to their fullest potential because it’s not always possible to get full end-to-end encryption when you have a virus scanning software sitting in the middle of the email’s journey. This leaves potential holes where messages and their attachments can be read, altered and even stored by a cyber-criminal.

PDF encryption gets around this as its very easy to use and every user has a PDF reader that they know how to use easily. PDF encryption works best if you have an email encryption gateway, which I discuss more at the end of this guide. It works because the email encryption gateway converts the email and attachments into a PDF and encrypts it with a password. There are various options involved in the way the password is generated and delivered:

1. The PDF can be encrypted using a pre-defined static password.
2. The PDF can be encrypted using randomly generated password. The password will be sent back by email to the sender of the message.
3. The PDF can be encrypted using randomly generated password. The password will be sent by SMS Text to the recipient.
4. The PDF can be encrypted using a One Time Password (OTP) algorithm

In any of the above scenarios, the recipient will receive a PDF attachment with an email that contains some plaintext informing the recipient that the message contents are encrypted and asking them to decrypt using the method chosen by the sender. To do so, the recipient will click a link and arrive on a portal where they must login.

The login credentials will apply to all future use of the portal by the recipient. In the case of decrypting the PDF, they will be able to do so using the password dialogue box in their PDF reader. They can also reply using the reply link in their PDF. This link takes them back to the portal where they can send an encrypted response.

PDF encryption is a great way to get around some of the limitations in the other forms of encryption I have mentioned in this guide. However; PDF encryption is not a catch all solution and in some cases, may not always be the best option. For example, where emails are internal, that is to say, between users on the same network, generating passwords to decrypt each time will become a resource heavy burden where automated S/MIME encryption would work better. Additionally, where the end recipient is not known, there might be suspicion raised from an email format the recipient is not familiar with.

Email Encryption Gateways

There is a way to get around the difficulty of managing full-scale email encryption on your own. Educational Institutions are already short for time and resource, so it stands to reason that IT admin’s time can be better spent on the overall school security rather than in becoming glorified email administrators.

This is where email encryption gateways can become a useful tool to bypass this additional spend and resource. An email encryption gateway can be installed into an internal network like that of an EI and configured to an EIs unique circumstances.

An email gateway is a server that sits between the sender and receiver where the email can be verified and checked based on the configuration settings of the owner of that server.

There are multiple features for protecting emails using a gateway solution.

• Multiple email encryption methods.
• Whitelists to say which domains are preferred.
• Blacklists to instantly filter bad domains.
• Checking headers of emails for certain keywords to automatically filter in SPAM, e.g. “make money”.
• User management.
• Email scanning and threat detection tools.
• Policy management where admin’s and user’s can decide how they would like to automate the encryption of their emails. For example, you can create a policy where all emails are encrypted by default or only if they contain sensitive data.
• Auditing and archiving features.

When managing risk in an EI, email encryption gateways can provide a solid and trusted solution to data loss prevention and mitigation of a data breach. Additionally, they can allow EIs to tailor the settings to suit their specific needs and use case.

While there is some work in implementing and installing a gateway, the long term benefits are hard to miss because the end-users notice very little but the overall email security capabilities are increased significantly. With so many options and tailoring involved, you can implement the encryption features that most suit your needs and ensure you’re EI is protected as much as possible.

If you want to find out more about our Email Gateway Solution, call or contact us today.