As part of an ongoing series, we’re highlighting the benefits and advantages of various end-to-end encryption tools for messaging, file storage, and secret management.
Direct peer-to-peer communication is difficult to secure due to the multiple parties involved in routing messages. File storage is difficult to secure due to the long-lived nature of the sensitive data and the timespans between access. I have introduced you to solutions to help secure both of these scenarios.
At least one scenario makes security difficult due to a hybrid of these other two: email. With email, the communication is both peer-to-peer with multiple parties relaying messages and involves potentially long-lived data.
Secure Email
The premise of most secure email implementations is based on public key cryptography and a public key infrastructure (PKI). Key pairs present two pieces of cryptographic information – a public key used to encrypt data and a matching private key used to decrypt.
The PKI allows for the exchange and verification of public keys, either through direct cryptographic signatures or through a trusted third party certification. In any event, the structure of this system allows for one party to generate a message, encrypt it for the recipient’s eyes only, and trust that the data will be safe for a long period of time even if exposed to a potential attacker.
Let’s look at two options for secure email and a service provider that helps make secure messaging both possible and easy for end users.
Pretty Good Privacy (PGP)
PGP is both a standard and a program (from Symantec) for encrypting, decrypting, and cryptographically signing arbitrary data. It’s been around since 1991 and is widely supported on various platforms by multiple open source projects.
Email can be both signed and encrypted using PGP. End users will each have a pair of keys – one public which is shared publicly through directories like Keybase, and one private which is kept confidential. Message authors will encrypt a message using the recipient’s public key. The only way to decrypt the message is with the recipient’s secret private key.
PGP’s primary advantage is its open source availability. The open source GNU project has developed GNU Privacy Guard (GPG), an free replacement for Symantec’s implementation of PGP. Thanks to GPG, there are libraries and extensions for many popular languages and applications for everyone to use.
As part of our Encrypt Everything series, we walked through the steps required to create a PGP/GPG key pair and highlighted a handful of options available for email clients. If you want to use public/private keys for secure email, this is a great place to start.
S/MIME
While PGP relies on a public infrastructure for secure email (i.e. you must create and share a key, then have peers cross-sign your keys), S/MIME is an alternative protocol that centralizes trust with a certificate authority. S/MIME still uses public key encryption, but in this case also utilizes a signed certificate to verify authenticity of the keys.
Users create an S/MIME certificate request with an authority like Comodo. Comodo will create a private key directly in the web browser for the email address being verified. They will then email the certificate directly to the address. Users will then install the certificate on their machine alongside the private key and can now sign emails or decrypt secure messages sent by third parties.
Note: It is important to use the right browser on the right machine when generating the private key. Chrome and Safari work just fine on MacOS and place the private key in your keychain automatically. On Windows, you must use Internet Explorer or the private key won’t export properly.
S/MIME’s primary advantage is that it’s built in to just about every major email client available. Its drawbacks are two-fold:
- Though a centralized authority issues all certificates, there isn’t a public directory of keys. Instead, you must send a signed message to give someone your public key – without your key, no one can send you a secure email.
- S/MIME flips the trust model from that of PGP. Instead of relying on a web of trust to verify the identity of a sender or recipient – you trust someone else who has independently verified an identity and signed a key – you are trusting the certificate authority (Comodo) and the integrity of the email system used by the sender or recipient. Comodo doesn’t do any identity verification. Their certificate merely verifies that the sender/recipient had control of the email address.
ProtonMail
ProtonMail leverages PGP/GPG under the hood to power secure email as a service. Internally, ProtonMail encrypts all messages for your eyes only with a PGP public key generated when you open an account. ProtonMail’s server will also keep track of an encrypted copy of your private key. This key is encrypted with a password of your choice to which the server never has access.
When you log in to ProtonMail, your password is used in a secure remote password authentication scheme. ProtonMail never has access to your password. Once logged in, a script in the browser uses your password and a salt returned by the server to derive the PGP passphrase that, in turn, decrypts your PGP private key.
ProtonMail’s servers store all email encrypted at rest. It is decrypted by you on your machine after you’ve downloaded the messages and unlocked your PGP private key. This is true even for messages sent by third parties in plain text; ProtonMail’s servers immediately encrypt messages using your public key upon receipt. Senders can even encrypt messages using your public key before sending and you’ll decrypt the message locally all the same.
Further, ProtonMail has exposed a hidden onion site allowing you to use their service anonymously over the Tor network.
Is it enough?
End-to-end encryption is all about protecting data from one end of a “channel” to another. In some cases, this channel is a real-time communication pipeline. In others it’s a span of time across which an individual accesses the same data securely. With secure email it’s both a communication pipeline and a span of time. However, all three of these scenarios deal with somewhat large pieces of data.
Come back next week for a look at ways to protect smaller pieces of data, namely secrets and passwords.