Email encryption

Last updated

Email encryption is encryption of email messages to protect the content from being read by entities other than the intended recipients. Email encryption may also include authentication.

Contents

Email is prone to the disclosure of information. Most emails are encrypted during transmission, but they are stored in clear text, making them readable by third parties such as email providers. [1] By default, popular email services such as Gmail and Outlook do not enable end-to-end encryption. [2] By means of some available tools, persons other than the designated recipients can read the email contents. [3]

Email encryption can rely on public-key cryptography, in which users can each publish a public key that others can use to encrypt messages to them, while keeping secret a private key they can use to decrypt such messages or to digitally encrypt and sign messages they send.

Encryption protocols

With the original design of email protocol, the communication between email servers was in plain text, which posed a huge security risk. Over the years, various mechanisms have been proposed to encrypt the communication between email servers. Encryption may occur at the transport level (aka "hop by hop") or end-to-end. Transport layer encryption is often easier to set up and use; end-to-end encryption provides stronger defenses, but can be more difficult to set up and use.

Transport-level encryption

One of the most commonly used email encryption extensions is STARTTLS. It is a TLS (SSL) layer over the plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. Assuming that the email servers on both the sender and the recipient side support encrypted communication, an eavesdropper snooping on the communication between the mail servers cannot use a sniffer to see the email contents. Similar STARTTLS extensions exist for the communication between an email client and the email server (see IMAP4 and POP3, as stated by RFC 2595). STARTTLS may be used regardless of whether the email's contents are encrypted using another protocol.

The encrypted message is revealed, and can be altered by, intermediate email relays. In other words, the encryption takes place between individual SMTP relays, not between the sender and the recipient. This has both good and bad consequences. A key positive trait of transport layer encryption is that users do not need to do or change anything; the encryption automatically occurs when they send email. In addition, since receiving organizations can decrypt the email without cooperation of the end user, receiving organizations can run virus scanners and spam filters before delivering the email to the recipient. However, it also means that the receiving organization and anyone who breaks into that organization's email system (unless further steps are taken) can easily read or modify the email. If the receiving organization is considered a threat, then end-to-end encryption is necessary.

The Electronic Frontier Foundation encourages the use of STARTTLS, and has launched the 'STARTTLS Everywhere' initiative to "make it simple and easy for everyone to help ensure their communications (over email) aren’t vulnerable to mass surveillance." [4] Support for STARTTLS has become quite common; Google reports that on Gmail, 90% of incoming email and 90% of outgoing email was encrypted using STARTTLS by July 24, 2018. [5]

Mandatory certificate verification is historically not viable for Internet mail delivery without additional information, because many certificates are not verifiable and few want email delivery to fail in that case. [6] As a result, most email that is delivered over TLS uses only opportunistic encryption. DANE is a proposed standard that makes an incremental transition to verified encryption for Internet mail delivery possible. [7] The STARTTLS Everywhere project uses an alternative approach: they support a “preload list” of email servers that have promised to support STARTTLS, which can help detect and prevent downgrade attacks.

End-to-end encryption

In end-to-end encryption, the data is encrypted and decrypted only at the end points. In other words, an email sent with end-to-end encryption would be encrypted at the source, unreadable to service providers like Gmail in transit, and then decrypted at its endpoint. Crucially, the email would only be decrypted for the end user on their computer and would remain in encrypted, unreadable form to an email service like Gmail, which wouldn't have the keys available to decrypt it. [8] Some email services integrate end-to-end encryption automatically.

Notable protocols for end-to-end email encryption include:

OpenPGP is a data encryption standard that allows end-users to encrypt the email contents. There are various software and email-client plugins that allow users to encrypt the message using the recipient's public key before sending it. At its core, OpenPGP uses a Public Key Cryptography scheme where each email address is associated with a public/private key pair.

OpenPGP provides a way for the end users to encrypt the email without any support from the server and be sure that only the intended recipient can read it. However, there are usability issues with OpenPGP — it requires users to set up public/private key pairs and make the public keys available widely. Also, it protects only the content of the email, and not metadata — an untrusted party can still observe who sent an email to whom. A general downside of end to end encryption schemes—where the server does not have decryption keys—is that it makes server side search almost impossible, thus impacting usability.

The content of an email can also be end-to-end encrypted by putting it in an encrypted file (using any kind of file encryption tool [9] ) and sending that encrypted file as an email attachment. [10]

Demonstrations

The Signed and Encrypted Email Over The Internet demonstration has shown that organizations can collaborate effectively using secure email. Previous barriers to adoption were overcome, including the use of a PKI bridge to provide a scalable public key infrastructure (PKI) and the use of network security guards checking encrypted content passing in and out of corporate network boundaries to avoid encryption being used to hide malware introduction and information leakage.

Setting up and using email encryption

Transport layer encryption using STARTTLS must be set up by the receiving organization. This is typically straightforward; a valid certificate must be obtained and STARTTLS must be enabled on the receiving organization's email server. To prevent downgrade attacks organizations can send their domain to the 'STARTTLS Policy List' [11]

Most full-featured email clients provide native support for S/MIME secure email (digital signing and message encryption using certificates). Other encryption options include PGP and GNU Privacy Guard (GnuPG). Free and commercial software (desktop application, webmail and add-ons) are available as well. [12]

While PGP can protect messages, it can also be hard to use in the correct way. Researchers at Carnegie Mellon University published a paper in 1999 showing that most people couldn't figure out how to sign and encrypt messages using the current version of PGP. [13] Eight years later, another group of Carnegie Mellon researchers published a follow-up paper saying that, although a newer version of PGP made it easy to decrypt messages, most people still struggled with encrypting and signing messages, finding and verifying other people's public encryption keys, and sharing their own keys. [14]

Because encryption can be difficult for users, security and compliance managers at companies and government agencies automate the process for employees and executives by using encryption appliances and services that automate encryption. Instead of relying on voluntary co-operation, automated encryption, based on defined policies, takes the decision and the process out of the users' hands. Emails are routed through a gateway appliance that has been configured to ensure compliance with regulatory and security policies. Emails that require it are automatically encrypted and sent. [15]

If the recipient works at an organization that uses the same encryption gateway appliance, emails are automatically decrypted, making the process transparent to the user. Recipients who are not behind an encryption gateway then need to take an extra step, either procuring the public key, or logging into an online portal to retrieve the message. [15] [16]

Encrypted email providers

Since 2000, the number of available encrypted email providers has increased significantly. [17]

See also

Related Research Articles

<span class="mw-page-title-main">Encryption</span> Process of converting plaintext to ciphertext

In cryptography, encryption is the process of encoding information. This process converts the original representation of the information, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information. Encryption does not itself prevent interference but denies the intelligible content to a would-be interceptor.

<span class="mw-page-title-main">HTTPS</span> Extension of the HTTP communications protocol to support TLS encryption

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It uses encryption for secure communication over a computer network, and is widely used on the Internet. In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS, or HTTP over SSL.

Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications. Phil Zimmermann developed PGP in 1991.

<span class="mw-page-title-main">Public-key cryptography</span> Cryptographic system with public and private keys

Public-key cryptography, or asymmetric cryptography, is the field of cryptographic systems that use pairs of related keys. Each key pair consists of a public key and a corresponding private key. Key pairs are generated with cryptographic algorithms based on mathematical problems termed one-way functions. Security of public-key cryptography depends on keeping the private key secret; the public key can be openly distributed without compromising security.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

In cryptography and computer security, a man-in-the-middle (MITM) attack is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, as the attacker has inserted themselves between the two parties. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within the reception range of an unencrypted Wi-Fi access point could insert themselves as a man-in-the-middle. As it aims to circumvent mutual authentication, a MITM attack can succeed only when the attacker impersonates each endpoint sufficiently well to satisfy their expectations. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, TLS can authenticate one or both parties using a mutually trusted certificate authority.

Hushmail is an encrypted proprietary web-based email service offering PGP-encrypted e-mail and vanity domain service. Hushmail uses OpenPGP standards. If public encryption keys are available to both recipient and sender, Hushmail can convey authenticated, encrypted messages in both directions. For recipients for whom no public key is available, Hushmail will allow a message to be encrypted by a password and stored for pickup by the recipient, or the message can be sent in cleartext. In July, 2016, the company launched an iOS app that offers end-to-end encryption and full integration with the webmail settings. The company is located in Vancouver, British Columbia, Canada.

<span class="mw-page-title-main">Onion routing</span> Technique for anonymous communication over a computer network

Onion routing is a technique for anonymous communication over a computer network. In an onion network, messages are encapsulated in layers of encryption, analogous to the layers of an onion. The encrypted data is transmitted through a series of network nodes called "onion routers," each of which "peels" away a single layer, revealing the data's next destination. When the final layer is decrypted, the message arrives at its destination. The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes. While onion routing provides a high level of security and anonymity, there are methods to break the anonymity of this technique, such as timing analysis.

<span class="mw-page-title-main">Key exchange</span> Cryptographic protocol enabling the sharing of a secret key over an insecure channel

Key exchange is a method in cryptography by which cryptographic keys are exchanged between two parties, allowing use of a cryptographic algorithm.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

End-to-end encryption (E2EE) is a private communication system in which only communicating users can participate. As such, no one, including the communication system provider, telecom providers, Internet providers or malicious actors, can access the cryptographic keys needed to converse.

In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key-agreement protocols that gives assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. For HTTPS, the long-term secret is typically the private key of the server. Forward secrecy protects past sessions against future compromises of keys or passwords. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key. This by itself is not sufficient for forward secrecy which additionally requires that a long-term secret compromise does not affect the security of past session keys.

Email privacy is a broad topic dealing with issues of unauthorized access to, and inspection of, electronic mail, or unauthorized tracking when a user reads an email. This unauthorized access can happen while an email is in transit, as well as when it is stored on email servers or on a user's computer, or when the user reads the message. In countries with a constitutional guarantee of the secrecy of correspondence, whether email can be equated with letters—therefore having legal protection from all forms of eavesdropping—is disputed because of the very nature of email.Morrison, Steven R. "What the Cops Can't Do, Internet Service Providers Can: Preserving Privacy in Email Contents". Va. JL & Tech.</ref>

In cryptography, a hybrid cryptosystem is one which combines the convenience of a public-key cryptosystem with the efficiency of a symmetric-key cryptosystem. Public-key cryptosystems are convenient in that they do not require the sender and receiver to share a common secret in order to communicate securely. However, they often rely on complicated mathematical computations and are thus generally much more inefficient than comparable symmetric-key cryptosystems. In many applications, the high cost of encrypting long messages in a public-key cryptosystem can be prohibitive. This is addressed by hybrid systems by using a combination of both.

Secure messaging is a server-based approach to protect sensitive data when sent beyond the corporate borders, and it provides compliance with industry regulations such as HIPAA, GLBA and SOX. Advantages over classical secure e-mail are that confidential and authenticated exchanges can be started immediately by any internet user worldwide since there is no requirement to install any software nor to obtain or to distribute cryptographic keys beforehand. Secure messages provide non-repudiation as the recipients are personally identified and transactions are logged by the secure email platform.

<span class="mw-page-title-main">Proton Mail</span> End-to-end encrypted email service

Proton Mail is a Swiss end-to-end encrypted email service founded in 2013 headquartered in Plan-les-Ouates, Switzerland. It uses client-side encryption to protect email content and user data before they are sent to Proton Mail servers, unlike other common email providers such as Gmail and Outlook.com. The service can be accessed through a webmail client, the Tor network, or dedicated iOS and Android apps.

Peerio was a cross-platform end-to-end encrypted application that provided secure messaging, file sharing, and cloud file storage. Peerio was available as an application for iOS, Android, macOS, Windows, and Linux. Peerio (Legacy) was originally released on 14 January 2015, and was replaced by Peerio 2 on 15 June 2017. The app is discontinued.

<span class="mw-page-title-main">Tutanota</span> Free and open-source end-to-end encrypted email software and host

Tutanota is an end-to-end encrypted email app and a freemium secure email service. The service is advertisement-free; it relies on donations and premium subscriptions. As of March 2017, Tutanota's owners claimed to have over 2 million users of the product.

<span class="mw-page-title-main">Mailfence</span> Encrypted email service

Mailfence is a secure and encrypted email service that offers OpenPGP based end-to-end encryption and digital signatures. It was launched in November 2013 by ContactOffice Group, which has been operating an online collaboration suite for universities and other organizations since 1999.

<span class="mw-page-title-main">EFAIL</span> Email security vulnerability

Efail, also written EFAIL, is a security hole in email systems with which content can be transmitted in encrypted form. This gap allows attackers to access the decrypted content of an email if it contains active content like HTML or JavaScript, or if loading of external content has been enabled in the client. Affected email clients include Gmail, Apple Mail, and Microsoft Outlook.

References

  1. "Email encryption in transit". Gmail Help. Google Inc. Retrieved 2020-06-15.
  2. "Enable hosted S/MIME for enhanced message security". GSuite Admin Help. Google Inc. Retrieved 2020-06-15.
  3. SMEmail – A New Protocol for the Secure E-mail in Mobile Environments, Proceedings of the Australian Telecommunications Networks and Applications Conference (ATNAC'08), pp. 39–44, Adelaide, Australia, Dec. 2008.
  4. "Announcing STARTTLS Everywhere: Securing Hop-to-Hop Email Delivery". EFF. 2018-06-25. Retrieved 2018-07-14.
  5. "Email encryption in transit".
  6. "Postfix TLS Support". Postfix.org. Retrieved 2014-04-16.
  7. Dukhovni; Hardaker (2015-10-14). SMTP Security via Opportunistic DANE TLS. IETF. doi: 10.17487/RFC7672 . RFC 7672.
  8. "End-to-end encryption". How To Geek. Retrieved 9 April 2015.
  9. Mitchell, Paul (January 16, 2022). "Sending encrypted e-mails with PGP". Privacy Dedicated Library.
  10. "Secure email attachments with 7-Zip". Columbia College Information Technology, Columbia University. Retrieved 16 July 2018.
  11. STARTTLS FAQ Retrieved 2018-07-24.
  12. Eric Geier, PCWorld. "How to Encrypt Your Email." April 25, 2012. Retrieved May 28, 2014.
  13. Klint Finley, WIRED. "Google's Revamped Gmail Could Take Encryption Mainstream." Apr 23, 2014. Retrieved June 04, 2014.
  14. In Security and Usability: Designing Secure Systems that People Can Use, eds. L. Cranor and G. Simson. O'Reilly, 2005, pp. 679-702. "Why Johnny Can’t Encrypt."
  15. 1 2 By Luis Rivera, SC Magazine. "Protecting customer privacy through email encryption." March 11, 2014. July 18, 2014.
  16. Gibson, Stan (July 22, 2014). "Health care data security now defined by encryption thin clients". SearchHealthIT.
  17. Sparrow, Elijah; Halpin, Harry; Kaneko, Kali; Pollan, Ruben (2016). Foresti, Sara; Persiano, Giuseppe (eds.). "LEAP: A Next-Generation Client VPN and Encrypted Email Provider". Cryptology and Network Security. Lecture Notes in Computer Science. Cham: Springer International Publishing. 10052: 176–191. doi:10.1007/978-3-319-48965-0_11. ISBN   978-3-319-48965-0.