From SMTP to OpenPGP, S/MIME and Secure Message Escrow
Emails have been the epicenter of online communication for decades now. Unfortunately the underlying protocol called SMTP (Simple Mail Transfer Protocol), which was developed in 1982, was not designed with an emphasis on security and privacy. In this blogpost, we will briefly go through some of the most common End-to-End Encryption (E2EE) technologies such as OpenPGP, S/MIME, Secure Message Escrow that improve the security of email communication. We will also look into their respective pros and cons.
OpenPGP
This protocol was initially proposed by Philip Zimmermann in 1991 as Pretty good privacy (PGP). It then got standardized as OpenPGP in 2007. It uses Public key cryptography to sign, encrypt and decrypt emails. A sender signs an email with his private key and encrypts the email using the recipient’s public key. The recipient then decrypts the email using his private key, and verifies the signature using the sender’s public key.
OpenPGP defines its own encryption methods (AES, RSA, …) and encoding formats. In particular an encoding layer called ASCII Armor which allows binary data to travel unscathed in emails. OpenPGP can also be combined with MIME.
Pro’s
– Decentralization
To be able to trust the recipients are actually who they say they are, OpenPGP traditionally offers web of trust. Users can simply distribute their public keys as identity certificates. There is no official centralized authority that controls and manages the delegation of trust. Public keys must be vetted by other users who confirm the association between the key and an individual.
– Independency
Every user can generate a self-signed key-pair and can distribute the public key himself. Since there’s no centralized authority, a user can update key expiration date, and revoke the keypair, … at any time. No intervention of any third-party is needed.
– Full control
Since there’s no intermediary involved from generating a keypair, updating/managing it until it gets expired/revoked – the user holds full control of his keypair. Also, a user is free to upload his public key on public key repositories and/or share it directly with other users. The Mailfence keystore has also made this really easy.
– Other uses
OpenPGP can also be used for other non-email tasks. E.g., encrypting documents locally, or as a signature format for digitally signing emails and software packages. The validity of OpenPGP signatures can be validated with the signer’s public key.
Con’s
– Public key distribution
There is no fixed platform for distributing OpenPGP public keys. This sometimes makes it difficult to securely share them with other users. Anyone can upload a fake public key on a Public Key Server (PKS) or can steal someone’s revocation certificate and revoke the public key. Other privacy related concerns with PKS do exist as well. This often leave users with few choices.
– Web of Trust (WoT)
Web of Trust is a standardized way to assert and manage trust on other public keys. However, WoT is not well-adopted. Thus, most of the OpenPGP compliant solutions leave the burden of whether to trust recipient’s public keys on the users. This makes everyone responsible for the vetting of public keys.
– Usability
Lack of user-friendly solutions is one of the main reason behind OpenPGP’s lack of popularity. However, this is where Mailfence has taken the challenge and made OpenPGP easy-to-use.
Mailfence supports OpenPGP to offer encryption/decryption and signature generation/verification for emails.
S/MIME
S/MIME was initially developed by individual security vendors in 1995. A refined version was later standardized in 1998 and 1999. It uses Public key cryptography to digitally sign, encrypt or decrypt emails. The mechanism remains the same as in OpenPGP: sender signs an email with his private key and encrypts the email using the recipient’s public key. The recipient then decrypts the email using his private key, and verifies the signature using sender’s public key.
The building blocks include MIME (a standard way of putting data into emails with their types/encodings/…) and CMS (the binary format for encrypting and signing data).
Pro’s
– Trust delegation
The standard format of the public key certificate is based on X.509. The trust is anchored to the root Certification Authority (CA) which is a trusted authority that offers key management (revocation, expiration, …). This takes away the burden of verifying public keys from the users.
– Usability
Many local email clients come with built-in S/MIME support, which increases its ease-of-use. It has also been widely adopted in enterprise environments with in-house CA.
Cons
– Centralization
The X.509 model grants trust to a centralized root CA. There have been issues which have made users question the integrity of certain CA’s. Thus, some users don’t find it a reliable trust model.
– Dependency
The user is dependent on the CA for operations like renewing the public certificate (once it has been expired), or revoking a public certificate. This takes away the control from the user side into the hand of the CA.
Secure message escrow
Secure message escrow does not rely on Public key cryptography and is compatible with any system. After validating the sender, the system allows the sender to compose his/her message. He/she then chooses how the recipient(s) will verify his/her identity from a range of options (with a password/PIN code). The service then encrypts the message (with the chosen password/PIN code) before storing it. The recipient then receives an email, which contains a secure URL that links back to the sender service. The recipient uses the link, verifies his/her identity as per the sender specifications, enters the password/PIN code and decrypts the message to read it.
Pro’s
– Usability
It is relatively easy-to-use for both the sender and recipient, and can be delivered to anyone with an email address.
– Sender control
The messages are hosted securely, rather than being sent over the internet. They are stored encrypted and are kept until they are retrieved by the sender/recipient, deleted by the sender, or expire. Access to the message can also be logged. So it is also possible to see if and when it has been viewed.
– Recipient accessibility
After receiving the secure link, the recipient can access the message from any device (having an updated browser).
Con’s
– Platform specific
It requires the trust in a specific (sender) service. If a sender service is unreliable, there could be significant security issues.
– Dependence
The recipient cannot store the message. He can merely view it on sender’s portal. He can always copy it locally though, but that is not practical in various situations where recipients are required to systematically keep a record of all inbound messages.
> Mailfence supports secure message escrow for emails, check this blogpost for details.
SMTP TLS/STARTTLS (Note: this is not end-to-end encryption!)
SMTP is the protocol that sends emails from the origin to their destination. Transport Layer Security (TLS) is a cryptographic protocol that provides secure connections. SMTP and TLS together provide an encrypted tunnel for both inbound and outbound email traffic.
However, the encryption tunnel only works when both the sending and receiving servers support Opportunistic TLS (STARTTLS). Only then will you obtain a secure delivery from server to server.
There also exists SMTP STS (or MTA STS), which makes it mandatory for a service to support STARTTLS in order to receive a message. However STARTTLS should never be confused with end-to-end encryption where encryption/decryption is supposed to happen in end-user device.
Note: All of the above encryption methods (OpenPGP, S/MIME, Secure Message Escrow) do not protect the metadata or message headers. It is strongly recommended to always use TLS-based connections, more specifically on Tor (for higher level of privacy and security).
OpenPGP, S/MIME, Secure Message Escrow are secure email models that have their own advantages and disadvantages, but also different levels of security, ease of use and compatibility. While understanding these technologies plays a huge role in choosing the right model, it mostly is a question of individual requirements and preferences.
Also check:
- Secure email: Why end-to-end encryption is at the heart of it
- Mailfence end-to-end encryption and digital signatures
- OpenPGP encryption best practices
- OpenPGP digital signature best practices
- Symmetric vs Asymmetric encryption: What’s the difference
Follow us on twitter/reddit and keep yourself posted at all times.
