Email encryption is used to send sensitive information by email from sender to recipient. Encryption between the end devices of sender and recipient is possible as end-to-end encryption. Email encryption often goes hand in hand with the digital signature and is actually combined with it in many standards such as X.509 or PGP. The goal of a digitally signed e-mail is to send information from the sender to the recipient in such a way that the sender is identifiable and no one can manipulate the e-mail unnoticed on the way from the sender to the recipient. The email signature thus satisfies the need for authenticity and integrity, but does not ensure confidentiality; this requires encryption.
Regardless of end-to-end encryption, the transmission between e-mail servers and end devices (clients) is also encrypted by default. Due to the protocol stack used, TLS or STARTTLS are used. The integrity and confidentiality of the e-mail can also be ensured by signing the e-mail or encrypting it end-to-end. There are various forms of application for email encryption and email signature.
Client-based email encryption and signature
The classic e-mail encryption and signature takes place from client to client (end-to-end encryption). Example: Alice sends an encrypted and signed message to Bob via email.
---
The encryption and signature of the message are handled by Alice’s e-mail client. Bob’s public key is used for encryption. The signature is done with Alice’s private key. The decryption and signature verification of the message is handled by Bob’s e-mail client. Decryption is done with Bob’s private key. The signature is checked with Alice’s public key. Client-based solutions have the disadvantage that they are too complex for many organizations (companies, associations). Because appropriate IT infrastructures are not available, the temptation is great to completely dispense with e-mail encryption and signature in the organization.
Server-based email encryption and signature
To avoid the disadvantages of client-based encryption, server-based solutions are the tool of choice. The work of encryption and signature is not done by clients, but by servers.
Example 1: Alice works in company A and sends an encrypted and signed message to Bob via email. The encryption and signature of Alice’s message are handled by an email server (a so-called encryption gateway), which is located in company A. The decryption and signature verification of the message is handled by Bob’s e-mail client.
Example 2: Alice works in company A and sends an encrypted and signed message to Bob via email. Bob works in company B. Alice’s message is encrypted and signed by an email server located in Company A. The decryption and signature verification of the message at Bob is done by an e-mail server located in company B.
So the advantages of a server-based solution are the following:
- The members of the organization (e.g. the employees in the company) do not have to deal with the topic of encryption and signature.
- The work is done by the administrator, who maintains the centrally located server.
- Nevertheless, all e-mail traffic can be encrypted and signed, provided that the internal users want it and the external communication partners participate.
The disadvantage of this solution is that the administrator or third parties can listen to the path between the sending e-mail client and the internal mail server (encryption gateway) and thus read and change e-mails.
Server-based solutions can offer the administrator the following services:
- Automatically generate, manage and publish secret and public keys of internal users (e.B. for public LDAP directories)
- Automatically query, validate and possibly save the certificates of external communication partners for later use
- Issue certificates fully automatically
PKI-based email encryption and signature
The common method of achieving confidentiality and authenticity in email is PKI-based email encryption and signature. PKI stands for public key infrastructure. PKI-based email encryption and signature almost always uses one of the following two standards:
- S/MIME: Secure / Multipurpose Internet Mail Extensions
- OpenPGP: Open Pretty Good Privacy
PKI-based email encryption and signature is used in both client-based and server-based solutions.
Password-based email encryption
Password-based email encryption is an option that can be offered by server-based solutions. It solves the following problem:
- If server-based solutions are PKI-based, they can relieve the internal communication partners of the operating organization of complicated PKI, but not the external communication partners. The external communication partners must either operate a server-based solution in their organization themselves or, if this is not possible, operate their PKI client-based. If they can’t do both, then email encryption is not possible, at least PKI-based.
- To avoid not encrypting at all, server-based solutions can offer password-based email encryption in addition to PKI-based email encryption. For external communication partners who have a PKI, PKI-based encryption is then carried out. For communication partners who do not have a PKI, password-based encryption can be used.
There are several ways to implement password-based email encryption. Example of one of many possibilities:
- Alice works in a company with a server-based solution. Bob has no PKI at all.
- Alice sends a message to Bob via email.
- The server-based solution does not find any certificates for Bob and automatically opts for password-based delivery of the message to Bob.
- The message from Alice is on hold.
- Bob receives an email notification that a message is waiting for him.
- Bob sets up an account on a web server and assigns a password for himself.
- The message on hold is then automatically converted into a PDF file, the contents of the PDF file are encrypted with the password provided by Bob, and the protected PDF is delivered to Bob by e-mail (as an attachment).
- Bob opens the PDF, enters his password into the PDF reader and can read Alice’s message.
- Every additional message from the company where Alice works is now automatically sent to Bob as a PASSWORD-encrypted PDF.
Benefits for external communication partners
- No certificates are required on the recipient side.
- Automated password management replaces the complex certificate issuance process at trust centers for the external communication partner. The only requirement is that he has standard software (e.g. web browser or PDF reader).
S/MIME-based email encryption and signature in detail
As with pure hybrid encryption, each communication partner must generate a key pair before they can sign emails or receive encrypted emails. Without a separate key pair, it is only possible to verify foreign signatures and encrypt messages.
In the S/MIMEworld, it is common for new communication partners to have their public key signed by a certificate authority. To do this, the public key is sent to the certification authority. Depending on the security class, the CA checks more or less strictly whether the public key belongs to the person claiming it. After passing the check, the CA creates a certificate of the key by signing it with its secret signing key. The certificate consists of the public key itself, the signature and administrative data. In addition to the signing key used for signing, there is a public verification key that can be used to verify the signature. For this CA verification key, there is also a certificate, the CA certificate, which in turn has been signed by a certification authority. In this way, a chain of CA certificates is created. The last link in such a chain is called a root CA certificate. The root CA certificate has been self-signed, so in practice, further paths are taken to ensure that the root CA certificate is genuine.
Messages can be both signed and encrypted. A signature ensures that a message has not been altered and provides information about the identity of the author. Encryption guarantees the confidentiality of the message, usually ensuring that the sender and all recipients of a message can decrypt it.
