ProtonMail Security Features and Infrastructure

Proton Technologies A.G.

8 July 2016

Contents

Introduction 3

Authentication 4Issues with Traditional Password Authentication . . . . . . . . . . . . 4The Secure Remote Password Protocol (Version 6a) . . . . . . . . . . 4

Choosing a Modulus . . . . . . . . . . . . . . . . . . . . . . . . . 6Improvements over RFC 5054 . . . . . . . . . . . . . . . . . . . . 7

Two Factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8

Email Encryption 8PGP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Implementation of the OpenPGP Standard . . . . . . . . . . . . . . . 11

Key Distribution and Management . . . . . . . . . . . . . . . . . 11Sending Encrypted and Signed Messages and Attachments . . . . 11Decryption and Signature Verification . . . . . . . . . . . . . . . 12

Password-Protected Messages . . . . . . . . . . . . . . . . . . . . . . . 13

Administration 13The Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Domains and Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 14User and Key Management . . . . . . . . . . . . . . . . . . . . . . . . 14Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Data Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Email Client Compatibility 15

Infrastructure 16Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Database Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Network and Facilities 18

1

Denial of Service Resistance 18

Conclusion 19

2

Introduction

ProtonMail is a secure email system servicing over 1 million customers aroundthe world, ranging from private individuals to large enterprises. It aims toprovide a much higher level of security than traditional email services withoutadversely impacting usability.

To achieve such security, ProtonMail conservatively assumes that all mailservers may eventually be compromised. Thus, ProtonMail uses end-to-endencryption to ensure that plaintext email data is never sent to the server. Ifa server only contains encrypted messages, then the risks of a central serverbreach are mitigated.

ProtonMail’s security extends beyond just strong encryption. We have seentime and time again that the human factor is the weak link in enterprise security.End user passwords can frequently be compromised by insecure connections,phishing, or malware. ProtonMail takes several additional steps to guard againstthis. First, ProtonMail uses strong authentication which makes most bruteforce or dictionary attacks impossible – even if an attacker has compromisedthe connection between client and server. Second, ProtonMail’s encryptionprotocols ensure that a single compromised account does not endanger otheraccounts.

We firmly believe that the most secure system is one that users will actuallyuse. Thus, ProtonMail was designed from the ground up with a strong emphasison usability. To accomplish this, we built the first encrypted email system wherethe encryption is entirely automatic and invisible to the end user. For usabil-ity reasons, we retain compatibility with legacy email protocols such as IMAPand SMTP so ProtonMail accounts can be accessed from existing email clientsand can seamlessly communicate with non-ProtonMail email accounts. How-ever, because of the inherent insecurity of IMAP and SMTP, ProtonMail usesa bridge service to maintain encryption and authentication without sacrificingIMAP/SMTP support.

While ProtonMail can be deployed either in the cloud or on an organiza-tion’s premises, we are firm believers in the cloud as the future of all enterprisesoftware. ProtonMail’s cloud offerings provide the best of both worlds. Orga-nizations can benefit from the security and reliability advantages of the cloud,while retaining data control and data privacy due to the end-to-end encryp-tion. Further, the economies of scale of the cloud imply a much lower cost ofownership for email infrastructure. For these reasons, ProtonMail is primarilydeployed in the cloud.

The goal of this document is to provide a more detailed look at the tech-nology behind ProtonMail. The first sections cover the technical details forProtonMail’s authentication and encryption technology. The next sections dis-cuss the ProtonMail’s extensive administrative tools and how key managementis handled within an organization, followed by details of how ProtonMail se-curely supports legacy email clients. Lastly, an overview of ProtonMail’s securecloud infrastructure is provided, with a discussion of the technologies we utilizeto ensure maximum data uptime and availability.

3

Authentication

ProtonMail users enter a user-chosen password on each login, but while Pro-tonMail’s backend is responsible for validating and resetting the password, thepassword cannot be derived by either ProtonMail or an attacker with accessto the network. This is achieved with the Secure Remote Password protocol,which as detailed below, conveys a zero-knowledge password proof from theuser to the server. The security granted by this protocol extends to the user’sprivate keys, which are encrypted with a salted hash of their password beforebeing sent to the server. For additional security, users also have the option ofenabling two-factor authentication.

Issues with Traditional Password Authentication

Most online services send the cleartext password or password equivalent to theserver on every login. If the server is compromised, whether from maliciouscode injected onto the server or due to a memory exposure such as in the recentHeartbleed vulnerability, user passwords or password-equivalents can be leakedno matter how they were salted and hashed.

Moreover, if the encrypted TLS layer of the connection to the server is bro-ken, passwords can simply be read from network traffic by any intermediarysystem between the client and server. This possibility is not as unreasonable orunlikely as it may seem. There have numerous incidents of certificate authoritiesissuing fraudulent certificates or computers being changed to trust insecure au-thorities. In 2001, VeriSign issued false Microsoft certificates; in 2011, Comodoand DigiNotar issued false certificates to several websites, including Google andMozilla; in 2012 it came to light that Trustwave had created a subordinate rootcertificate capable of attacking a connection to any website; in 2015 it was re-vealed that Lenovo laptops were shipped with Superfish, software that, amongother things, caused the system to trust a root certificate with a publicly knownprivate key. This problem is exacerbated by the certainty that a state actorcould force a certificate authority to issue fraudulent certificates.

In contrast, the Secure Remote Password protocol [11] promises theoreticallyoptimal security. When using SRP, even an attacker who can arbitrarily read,modify, delay, destroy, repeat, or fabricate messages between ProtonMail and alegitimate user in an undetectable fashion is limited to checking only a singlepassword guess per login attempt, a task which could be done just by trying tolog in directly. Even if a server is compromised and acts maliciously, password-equivalent information is never revealed. This is all done without permanentprivate keys: all secret information is derived from the user’s password.

The Secure Remote Password Protocol (Version 6a)

The Secure Remote Password (SRP) protocol can be viewed as a variation ofthe more well-known and widely deployed Diffie-Hellman key exchange. As inDiffie-Hellman, SRP’s security in the face of eavesdroppers and other attackers

4

Client Server

Username

Generate random s

Salt, m, S = gs + kv mod m

Generate random c

C = gc mod m

Calculate u = Hash(C, S) Calculate u = Hash(C, S)

Calculate g(c+up)s = (gs)c+up Calculate g(c+up)s = (gcvu)s

Pc = Hash(C, S, g(c+up)s mod m)

Verify Pc

Ps = Hash(C,Pc, g(c+up)s mod m)

Verify Ps

Figure 1: The Secure Remote Password Protocol, as implemented in ProtonMail

relies on the difficulty of the discrete logarithm problem: given a fixed primenumber N and g, it is easy to compute gx mod N from x, but not the otherway around. Accordingly, for a password p (pre-hashed and salted, both tomake dictionary attacks slow and to ensure that there are no weaknesses dueto predictability), the server stores the verifier v ≡ gp mod N . This verifiercan be computed on the client side when setting a password, avoiding the needfor the server to see any password-equivalent data. For login, the SRP protocolproceeds in two phases. In the first stage, the client and server generate a sharedsecret, following the pattern of Diffie-Hellman. In Diffie-Hellman, both partiesgenerate random ephemeral public-private key pairs as a random secret a andga mod N . Then, they can each mix their private key with the other party’spublic key, producing a shared secret: (ga)b = gab = (gb)a mod N . SRP differsfrom this by mixing the verifier and the password into the key pairs, therebycausing a mismatch if the password and the verifier do not match.

On the server side, the generation of the ephemeral key pair proceeds nor-mally: the private key is a randomly chosen s, and the public key is gs mod N .However, when transmitting the public key to the client, the verifier is mixedin, and S ≡ kv + gs mod N is sent for a random constant k (generated as ahash of N and g). The client then calculates the actual server public key bycomputing S − kgp.

On the client side, the password is mixed into the private key. Although the

5

client generates a random c and sends across C ≡ gc mod N , the actual privateephemeral key is c+ up, where u is a mixing parameter derived as a hash of Cand S. The client can only calculate this private key by knowing the passwordp, while the server can calculate the public key from only the verifier as follows:

Cvu = gc(gp)u

= gcgup

= gc+up

Finally, the client and server generate a shared secret as in standard Diffie-Hellman, finding gs(c+up) = (gs)c+up = (gc+up)s.

The second phase of SRP is the actual authentication phase, in which theclient and server prove to each other that they hold the same secret. Thisonly happens when the password held by the client corresponds to the verifierheld by the server. Verification is a fairly simple process – the client sendsa hash of the shared secret, the server’s semi-public ephemeral key (gs modN), and some public data for randomization. In response, the server sends ofhash of the shared secret, the user’s knowledge proof, and some public data forrandomization.

In the first phase, the only sensitive value sent over the network is the verifiermixed into the server’s public ephemeral key. However, since s is uniformly ran-dom and g is chosen as a generator modN , gs mod N is uniformly distributed(except for 0), and therefore perfectly scrambles the verifier, rendering the mes-sage harmless.

In the second phase, assuming the hash function used is secure (in the ran-dom oracle model), an attacker cannot figure out anything about the hasheddata except via search over possible shared secrets. Since the shared secret islarge and randomly distributed, brute-force attacks are infeasible, and generat-ing the shared secret, even from a known password, is assumed to be difficultwithout knowledge of one of the private keys, which would take discrete loga-rithms to find. Therefore, an attacker cannot even mount a dictionary attackon a user’s password by observing an SRP connection.

Choosing a Modulus

SRP relies crucially upon working modulo an N that makes calculation of dis-crete logarithms difficult. In particular, when N−1 is made up of comparativelysmall factors, the Pohlig-Hellman algorithm makes it possible to break the prob-lem down into discrete logarithm problems of difficulty proportional only to thesize of those factors. Therefore, to minimize this risk, ProtonMail uses safeprimes of the form 2p+ 1, where p is another prime number.

However, choosing a single safe prime may be insufficient. With algorithmslike the number field sieve algorithm, it is possible to do a significant amountof precomputation on an arbitrary modulus to be able to calculate discretelogarithms efficiently in that modulus. While the amount of work necessary is

6

prohibitive for a one-off calculation, it seems within the reach of state actors todo such a computation on a 1024-bit modulus, and there is evidence that sucha computation has already occurred [1]. At ProtonMail, we take a conservativeapproach towards this threat. First, we use 2048-bit moduli, which ought to beout of reach for even state actors for quite some time. Second, we have optedto not use a single modulus for all users. This greatly reduces the impact of anattack on an SRP modulus, as such an attack would only affect a small fractionof users.

To defend against an MITM (man-in-the-middle) attacker feeding the clienta fraudulent, broken modulus, we have two layers of security. First, the mod-ulus is included in the password hash itself, meaning that in the worst case,the attacker would only be able to access information about a different hashof the password than the one used to actually log in. This reduces potentialcompromise to at worst a dictionary attack. Second, we send the client signedmoduli which can be verified to ensure that the modulus actually came fromProtonMail.

Improvements over RFC 5054

A version of the SRP-6a protocol has been standardized by the IETF in RFC5054 [9] for use in negotiating secure, authenticated TLS connections. Unfortu-nately, the RFC seems too outdated to be acceptable for use at ProtonMail.

First and foremost, we have deep security concerns around the use of SHA-1as a hashing algorithm. For password hashing in particular, SHA-1 is highlyproblematic: In the event of a database breach or the discovery of a weakness inthe SRP protocol, attackers would primarily execute dictionary attacks, and somodern password hashes are designed to be slow and memory hungry to impedehigh-speed, highly-parallel password cracking. SHA-1 is specifically designed tohave neither of these two crucial properties. Moreover, SHA-1 is not tunable– there is no clear way to scale up the password hashing cost as computingpower increases. In contrast, ProtonMail uses bcrypt, a time-tested, tunablyslow hashing algorithm designed for passwords.

Beyond its issues as a password hashing algorithm, SHA-1 is far too shortto be used safely in SRP. Many algorithms for computing discrete logarithms,prototypically Pollard’s kangaroo algorithm [8], have runtimes that only dependon the range of possible exponents, not the full size of the modulus. In the faceof those algorithms, SRP using SHA-1 has security roughly equivalent to usinga 180-bit modulus, which is well within the range of breakability.

Additionally, though the bulk of the attacks on SHA-1 are collision attacksthat have little bearing on the security of SRP, SHA-1 has recently been showingits age, and it is difficult to be confident that SHA-1 is or will be sufficientlysecure. As such, ProtonMail uses MGF-1-SHA-512 [5, B.2.1] both to expandthe bcrypt hash to a full 2048 bits and to generate the u and k scramblingparameters.

Second, RFC 5054 is meant as an implementation of authentication for theTLS protocol. While it has its flaws, the more traditional certificate-based TLS

7

authentication is extremely well tested, studied, supported, and updated. Bywrapping our implementation of SRP in a traditional TLS channel, we can lever-age the immense body of work that has gone into making existing TLS solutionssecure, improve privacy by encrypting usernames, and guard against novel at-tacks on the less well-tested SRP protocol by preventing even eavesdroppers inthe common case.

Two Factor Authentication

Two-factor authentication (2FA) can be optionally enabled for added security.2FA is a method of confirming identity that requires not only that the userknow information (e.g. their login password), but also that the user possess aparticular physical device (ex. a phone, computer, or hardware key) configuredwith their 2FA shared secret. ProtonMail implements the Time-based One-Time Password algorithm (TOTP) [7], which computes a single use passcodefrom a shared secret key and the current time measured in 30 second intervals.A TOTP passcode is only valid for a limited time, which prevents brute-forceand replay attacks.

When 2FA is first enabled for an account, the user is given a shared secretkey that they can enter into any TOTP-enabled application or device. Examplesinclude the Google Authenticator, Authy, and 1Password smartphone applica-tions, and Yubico Authenticator, which stores the shared secret on a hardwaredevice called a Yubikey. When a user wants to sign in to their account, the cho-sen application will use the TOTP algorithm to provide the correct passcodecorresponding to the user’s secret key. This passcode will need to be enteredalong with the correct login password in order to access the account. To pre-vent locking users out of their accounts if they lose their 2FA device, users arealso given 16 single use recovery codes when they enable 2FA. A valid recoverycode along with the correct login password will also allow users to enter theiraccount, where they can disable 2FA on the lost device and re-enable it on adifferent device.

Organization administrators are empowered to reset 2FA settings for non-private member users.

Email Encryption

PGP Overview

The PGP protocol utilizes a combination of public key and symmetric cryptog-raphy that offers two primary benefits for communications and email: confiden-tiality, whereby only designated parties can read a particular communication,and authenticity, whereby the recipient can verify the identity of the sender anddetect whether the communication has been tampered with in transit.

Public key cryptography utilizes a pair of keys for each party – a public keyused to encrypt messages sent to the party that can be widely disseminated, and

8

a private key used to decrypt messages sent to the party that is known only tothat party. Not only should an encrypted message not reveal any informationabout the message, but a public key should not reveal any information aboutits associated private key. Both of these properties are achieved by using math-ematical problems that are computationally infeasible to solve. For example,in RSA, the default public key cryptosystem provided by PGP, the private key(d) and the public key (exponent e and modulus n) are related such that forall messages m, (me)d ≡ m mod n. RSA’s security relies on two properties:that the message m cannot be derived from the encrypted message me mod n

even with knowledge of the public key, and that the private key d cannot bederived even with knowledge of e, n, and/or m. In order to derive either ofthese variables, an attacker would have to factor the public key modulus n,the product of two large unknown primes, a problem which is believed to beextremely computationally difficult for sufficient key length.

Unlike public key cryptography, symmetric key cryptography utilizes onlyone key, which is used for both encryption and decryption of a message. Sym-metric key algorithms tend to be much faster than public key algorithms, butrequire that both sides of the communication have access to the same key. Therequirement that this secret key be securely shared between the sending andreceiving parties is the main drawback of symmetric key cryptography.

Thus, in order to take advantage of the secure key distribution of public keycryptography and the speed of symmetric key cryptography, PGP combines apublic key algorithm with a much faster symmetric key algorithm. For example,ProtonMail’s implementation of PGP uses the public key algorithm RSA andthe symmetric key algorithm AES-256.

Message encryption with PGP goes as follows:

1. After the sender creates a message, a random 256-bit number is generatedthat will only be used during this transaction. This is called a “sessionkey”.

2. PGP symmetrically encrypts the message using this session key.

3. The session key is encrypted with the chosen public key algorithm foreach recipient using their public key. Because the session key is only256 bits long, the relative slowness of the public key algorithm does notsignificantly increase the overall computation time.

4. These encrypted session keys are prepended to the encrypted message andare sent together to all desired recipients.

To read a PGP-encrypted message, the recipient will:

1. Decrypt the encrypted session key meant for them, yielding the originalsession key

2. Use the session key to decrypt the encrypted message, yielding the originalmessage

9

Session Key

PK1

Session Key

PK2

Message Data Signature

SK

Figure 2: The makeup of a PGP message with two recipients with public keysPK1 and PK2. The session key SK is separately encrypted with the two publickeys, and the message data is symmetrically encrypted with the session key. Thesignature is optional.

Because no other party has the ability to decrypt any of the encryptedsession keys, and thus the ability to decrypt the message, the message will onlybe available to the sender and intended recipients.

In addition to encrypting the message, the sender can optionally choose toprovide a digital signature, which will allow the recipients to verify that themessage is indeed from the sender and has not been tampered with in transit.

To digitally sign a communication, the sender will:

1. Produce a hash of the message using a hash function that must be bothone-way (the hash value does not reveal any information about the mes-sage) and deterministic (the function always produces the same result onthe same input)

2. Use their private key to sign this hash value using a digital signaturealgorithm. This signed hash value is called the digital signature

3. Append the digital signature to the message before encryption and sending(which will proceed as detailed previously).

In order to verify the signature, the recipient will:

1. Decrypt the message as explained previously, yielding the digital signatureand the original message

2. Use a signature verification algorithm corresponding to the signing algo-rithm used by the sender, along with the sender’s public key, to producethe hash value from the digital signature

3. Calculate the hash value of the decrypted message using the same hashfunction as the sender.

4. Check whether the two hash values from steps 2 and 3 are equal. If theyare equal, the signature is verified.

If the signature is verified, then the recipient knows that the message wassigned with the sender’s private key and has not been changed since.

10

Implementation of the OpenPGP Standard

ProtonMail implements OpenPGP [2], the most widely-supported PGP stan-dard, using OpenPGP.js on the web client and a native code implementationon the mobile applications and IMAP/SMTP bridge. OpenPGP.js is an open-source Javascript library that is actively used and vetted by the security com-munity, including two independent security audits by the German cybersecurityfirm Cure53. The native implementation uses cryptographic primitives fromOpenSSL, one of the most ubiquitous and popular implementations of TLS/SSL.Both of these libraries provide key management functions as well as encryp-tion, decryption, signing, and signature verification of messages/attachments.ProtonMail’s interface to each of these functions is detailed in the followingsubsections.

Key Distribution and Management

Upon creating a ProtonMail account, every user generates a RSA public key/privatekey pair. These keys are generated client-side with a user ID (the user’s Pro-tonMail email address) and a passphrase (the user’s mailbox password, knownonly to the user) as inputs. The private key is symmetrically encrypted with themailbox password using AES-256. The public key and encrypted private keyare then stored on the ProtonMail server along with the user’s other accountinformation and retrieved whenever a user logs in successfully. The encryptedprivate key is decrypted on successful mailbox password entry on the user’s localdevice and can be used to read and sign messages during that session. Becausethe private key is stored encrypted by the mailbox password, and the mailboxpassword is known only to the user, ProtonMail cannot read the user’s messagesnor impersonate the user.

User accounts may have multiple email addresses associated with them, andeach address will have one or more sets of public/private keys. The primary setis used for encryption/signing, while the secondary (usually older) sets are usedfor decryption to ensure readability of older messages.

Sending Encrypted and Signed Messages and Attachments

Amessage and its attachments can be sent encrypted from a ProtonMail accountto any email address with an available corresponding PGP public key. If theemail address is associated within ProtonMail, the recipient’s public key will beautomatically retrieved. If the email address is not associated with a ProtonMailaccount, the corresponding public key must be imported by the user and savedin a contact. Message and attachment encryption in these two cases are handleddifferently, as detailed below.

Internal Emails (ProtonMail to ProtonMail) In this case, messages andattachments are encrypted and signed separately. Signing is optional for attach-ments because it requires re-downloading the encrypted attachments from the

11

server on message send, which can be slow, and signatures often go unchecked.Sending without signing only requires the encrypted session key packets to bedownloaded and re-encrypted with the recipients’ public keys. Messages arealways signed because there is no performance penalty. Keeping messages andattachments separate helps facilitate responsive webmail and IMAP interfaces,as large attachments do not need to be downloaded from the server in order toread the associated message. This also enables fast forwarding of messages, asattachments can be copied server-side.

External Emails (ProtonMail to another PGP email client) Thereare two PGP formats available for external PGP encryption – PGP/Inline andPGP/MIME. Sending an external PGP/Inline email works exactly the same wayas internal encryption – messages and attachments are separately encrypted andsigned as detailed above. The downside to Inline PGP from the user’s perspec-tive is that external clients often do not support HTML emails with PGP/Inline,but they are much more suited to webmail than PGP/MIME. PGP/MIME com-bines the message body and attachments in a multipart MIME form, and thenencrypts and signs them together. This method boasts full support for HTMLemails but can be slower if the message included large attachments, as the at-tachment must be downloaded and the large encrypted body re-uploaded tosend.

Decryption and Signature Verification

ProtonMail can decrypt and verify internal emails (from another ProtonMailaccount) as well as any other emails PGP-encrypted with the user’s public keyas long as the sender’s public key is in the user’s contacts.

Internal Emails If an email is sent from another ProtonMail account, thenthe message and attachments have been encrypted separately. In this case, themessage is decrypted and verified as it is read. The attachments are decryptedand verified only if downloaded.

External Emails If an encrypted email sent from outside ProtonMail is in thePGP/Inline format, then decryption and verification are the same as internalemails, with the exception that the sender’s public key may not be known tothe user. In this case, the message and attachments will be decrypted but thesignatures cannot be verified.

If the encrypted email is in the PGP/MIME format, then the messages andattachments have been combined and encrypted as a whole. In this case, thecombined form is decrypted and the signature optionally verified immediately.

The user will be alerted to any irregularities with the signature verification.

12

Password-Protected Messages

ProtonMail’s Encrypt-to-Outside feature (EO) allows a user to communicatewith someone without PGP keys outside of the ProtonMail platform in a fullyend-to-end encrypted manner. EO encryption takes place on the client deviceand is available in both web and native mobile application formats. Using EOencryption requires a shared secret (password) known to both parties commu-nicated to eachother via other means (e.g. phone). An optional password hintand/or expiration time for the message can also be set. By defult, all messagesexpire after 28 days if an earlier expiration date is not specified.

The encryption password is used to encrypt (with AES256) both the mes-sage itself as well as a randomly-generated token. The encrypted message, en-crypted token, and the plaintext token are then sent to the ProtonMail server.It’s important to note that the encryption password is never saved or sent toProtonMail at any time which maintains a zero-knowledge result.

The ProtonMail server then sends the designated recipient a generated emailnotifying them that they have a message waiting. This generated email con-tains a very long, unique link to access it. These links are very long and rate-limited to prevent brute-force guessing. The notification message can be white-labeled/customized.

Upon navigating to the unique link in a web browser the visitor is promptedto decrypt the random token with the password. If successful, the visitor canuse the token to authenticate to the server and retrieve the message, attach-ments, and associated metadata. Message decryption is then performed withthe password.

The authenticated visitor can also reply to the message. These replies areencrypted with the ProtonMail user’s public key and also end-to-end encrypted.

A maximum of 5 replies can be sent per EO message. This limit is to preventabuse by the recipient.

Moreover, sending and replying fully support end-to-end encrypted attach-ments.

Administration

ProtonMail for Enterprise combines maximum protection for corporate dataagainst unauthorized access with the tools necessary for successful organizationmanagement and regulatory compliance.

The Organization

Each ProtonMail for Enterprise client has an organization defined within theProtonMail Cloud. An organization is a collection of users with at least oneadministrator which share email domains, billing, and cloud resources. Organi-zation resources, such as storage space, can be provisioned to individual usersby organization administrators. Organizations also have an associated pub-lic/private key pair. This key pair is shared among the administrators and can

13

be used to access and read mail in non-private member accounts as well as signorganization data.

Roles

There are two possible user roles within an organization. The basic role is thatof the organization member, who can read and send email but cannot administerthe organization, assign or remove addresses, modify their storage space, etc.The other user role is that of administrator. Administrators can add and removeusers, domains, addresses, storage space, and modify the organization’s nameand other characteristics. They have access to and can modify organizationbilling and subscription information and they can also access non-private useraccounts and perform actions as the subordinate user. As administrators haveabsolute power within the organization, it is recommended that administratoraccounts not be used for regular mail purposes and instead only be used foradministration.

Domains and Addresses

Domains (i.e. mycorporation.com) are added and managed by organization ad-ministrations. Once the domain is correctly configured and verified, addressesassociated with the domain can be provisioned to members of the organiza-tion. Users can have multiple addresses, but mail is organized separately byaddress. All addresses in the ProtonMail system ignore case, hyphens, periods,and underscores when routing mail, which reduces misrouted mail. Addition-ally, ProtonMail-hosted addresses support ’+’-style subaddresses for routing(e.g. mail sent to test+abc@example.com is routed to test@example.com, as ismail sent to test+def@example.com).

User and Key Management

Administrators are empowered to create new organization members and assignthem addresses, a role, and a storage quota. Regardless of role, each user canbe either a private or non-private user. For compliance reasons, most if not allcorporate users are non-private. The difference between private and non-privateusers is who has ultimate control over the user’s encryption keys. For privateusers, this is the user herself. She generates her own keys, and no one but hercan read his correspondence. For non-private users, an administrator generatesthe encryption keys used for the account and saves a copy for administrativeuse. This allows the administrator both to read the user’s mail if necessary andalso restore account access in the event the user forgets her mailbox password.Administrators can also reset the login passwords and 2FA information of non-private users.

14

Client Side

Web Client

Android App

iOS App

IMAP Bridge

Thunderbird

Outlook

Evolution

Etc.

ProtonMail

Figure 3: The different ways to connect to ProtonMail

Import/Export

Data import is achieved via a downloadable, cross-platform tool which seam-lessly transfers data from the previous provider to ProtonMail. All mail isencrypted within the tool before sending the encrypted payload to ProtonMail.This ensures that the ProtonMail servers never see the unencrypted data. Ex-port is achieved via the same tool run in reverse.

Data Retention

Data retention periods for non-private users are enforced by disabling full mes-sage deletion for messages newer than a configured cutoff age, drafts excepted.

Email Client Compatibility

ProtonMail is compatible with existing email clients such as Thunderbird, Out-look, and others via a client-side IMAP/SMTP bridge that facilitates all encryp-tion and decryption operations and communicates with the ProtonMail API.

The IMAP and SMTP protocols [3][6] are the commonly implemented stan-dard for interaction between email clients and servers. Unfortunately, fewIMAP/SMTP client implementations provide end-to-end encryption. To re-tain compatibility with these clients while still offering end-to-end encryption,our bridge acts as a local intermediary that encrypts emails after they leave theclient but before they leave the user’s computer.

This bridge runs on Linux, OS X, and Windows and is downloadable fromthe ProtonMail website. Once installed, it acts as a proxy server for the Pro-tonMail API. All communications between the bridge and the cloud API areauthenticated using the SRP protocol and secured using TLS/SSL. Addition-ally, because the bridge is a static application installed locally, external mali-cious code changes are prevented. Moreover, by keeping the decryption softwareseparate from the actual email client, vulnerabilities in clients cannot allow anattacker to steal encryption keys. Using the bridge is simple and only requires

15

Client

Incoming Mail

HAProxy

HAProxy

Web Server

MySQL Backup DB

Web Server

MySQL Backup DB

Web Server

MySQL Backup DB

Redis

Redis

Mail Server

Mail Server

Mail Server

Figure 4: ProtonMail’s infrastructure

entering “localhost” and custom port numbers as the IMAP and SMTP serversin an existing email client.

Sending email through the IMAP/SMTP bridge is seamless from the user’sperspective. When email is sent, the bridge reads the recipients and determinesthe appropriate encryption to use (ProtonMail internal, EO/PGP if configuredin the ProtonMail contacts, or unencrypted for external recipients). If a recipi-ent is a ProtonMail user, the recipients’ public keys are fetched using the Pro-tonMail API and used to encrypt the message using standard PGP encryption.EO and PGP recipients are handled similarly except that the password/keysare retrieved and decrypted from the user’s encrypted contacts. The message isonly sent to the ProtonMail server post-encryption, which preserves end-to-endsecurity.

Incoming email is also handled through the bridge. When the bridge receivesa new message from the ProtonMail API, the user’s private key is used to decryptthe message on the fly. Because the decryption only happens locally the integrityof the end-to-end encrypted communication is maintained.

Other IMAP actions are translated to ProtonMail API commands as appro-priate. For example, copying a message to a user-defined folder is interpretedas labeling the message, and deleting a message from a user-defined folder isinterpreted as removing the corresponding label. Only deletions from the Trashfolder are interpreted as actual deletions.

Infrastructure

The ProtonMail server infrastructure is heavily distributed and redundant toensure high reliability and performance. The main parts of the system are shownin Figure 4.

16

Mail Servers

ProtonMail use MX DNS to load balance incoming SMTP traffic to multiplemail servers. This redundant setup ensures that if a mail server is taken offline,incoming mail will be automatically rerouted to the other servers. The MTAused for receiving and sending emails is Postfix, which is open source, secure,and widely used. In order to encrypt SMTP traffic, TLS 1.0 or higher and per-fect forward secrecy using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)key exchange are supported while vulnerable protocols such as SSL 3.0 and weakcipher suites are disallowed to prevent downgrade attacks. To filter mail, we de-ploy OpenDKIM (verifies and signs DKIM), OpenDMARC (verifies DMARC),ClamAV (rejects viruses), and SpamAssassin (assigns a score to incoming emailaccording to how spam-like the message is). These “milters” funnel clean emailsto the inbox and spoofed or spam emails to the spam folder. Postfix passes pro-cessed incoming mail to the application layer, which does further processing(including custom filtering) and encrypts the email with the user’s public key.The encrypted email is then stored and cannot be decrypted by anyone exceptthe recipient user.

Web Servers

ProtonMail’s web servers, powered by Apache, serve API requests originatingfrom the browser-based web application and the native iOS/Android mobileapps. HSTS ensures that all traffic uses HTTPS and HPKP to prevent man-in-the-mittle attacks. As with incoming mail, data in transit is encrypted using arecent version of TLS with strong cipher suites – as of July 2016, these measuresearn ProtonMail domains A+ ratings on Qualys SSL Labs’ test. Our serversrun hardened versions of CentOS and are load balanced by redundant HAProxyservers, which automatically reroute traffic if any web server goes offline. Withour own range of IPs, we ensure that all outgoing emails are sent from serverswith good IP reputation and won’t be summarily rejected by spam filters.

Database Servers

All of our critical user data resides on MySQL databases, which are widely usedand battle-tested by Internet giants like Facebook and Dropbox. While thereare newer and fancier database solutions available, none are mature or reliableenough to meet our standards, and none can match MySQL when it comes toexisting community and support.

To improve performance, data is horizontally sharded across multiple databaseservers. Each shard unit consists of a master that handles both reads and writesand replicates its data to two slaves. The primary slave is in the same datacen-ter as the master and is ready to take over if the master goes down, while thesecondary slave is in a separate datacenter in case of datacenter-wide failures.Backups are regularly made for disaster recovery, including to cold storage. Allshard units are maintained and operated with identical tools so that adding

17

more shards does not actually add more complexity. By knowing exactly whereeach piece of data is and having full control of the replication topology, weensure that we can scale up without sacrificing reliability.

To maximize performance, Redis servers act as a cache layer above MySQLfor frequent reads and transient data. The Redis servers are also deployed in afully redundant configuration to eliminate single points of failure.

Network and Facilities

ProtonMail’s cloud infrastructure runs on a dedicated network for both securityand reliability reasons. Our network spans three datacenters in Switzerland,two of which are ISO 27001 certified. Our datacenter providers include DeltalisSA and Equinix (NASDAQ: EQIX). Our data storage facilities are spread outacross both Western and Eastern Switzerland for geographic diversification anddirectly connected to major Internet Points of Presence (PoP) in both Zurichand Geneva.

We use an unique mix of facilities that have a special emphasis on securitydue to the special requirements of our customer base. Our primary datacenterin Attinghausen is located in the former Swiss air force command and controlbunker under 1000 meters of solid rock and linked to the outside world througha ultra reliable dark fiber link maintained by the Swiss Federal Railways forsignaling purposes along the Gothard tunnel. Being connected to critical Swissnational infrastructure helps to ensure the highest possible uptime on our up-links.

Proton Technologies AG is also a Local Internet Registry (LIR). Since 2014,we have been a member of RIPE NCC (Reseaux IP Europens Network Coor-dination Centre) with a dedicated allocation of IPv4 and IPv6 addresses. Thisallows us to control the IP reputation of our own subnet for optimal email deliv-erability and isolate our network infrastructure away from other entities whichmay be prone to failure. This also serves to protect our network from unautho-rized tapping or other network based attacks because we maintain full controlover our network up until the main Swiss Internet PoP in Zurich.

Denial of Service Resistance

Proton Technologies AG has in place sophisticated monitoring on all levels ofour network to detect intrusions and other malicious activity on our network.We have also partnered with Radware (NASDAQ: RDWR) to protect our net-work against external threats such as Distributed Denial of Service (DDoS)attacks, in which attackers flood a network with requests, attempting to makeit unavailable to its users. Such protection is increasingly necessary becauseDDoS attacks have now become the most common form of cyberattack, a trendwhich is expected to continue (see Figure 5).

18

0 20 40 60 80 100

DDoS

Phishing

Worm and Virus Damage

Unauthorized Access

Criminal SPAM

Fraud

Advanced Persistent Threat

Theft of Prop. Info/Intellectual Property

Corporate/Geo-political Sabotage

None of the above

51

50

47

34

29

25

23

15

7

9

Figure 5: Percentage of companies experiencing various cyberattacks [10]

Together with Radware and other network infrastructure partners, we oper-ate a 24/7 Network Operations Center with a 24/7 Emergency Response Teamto swiftly respond to any network based attacks and ensure maximum uptime.ProtonMail uses a DDoS protection system based off of Border Gateway Proto-col redirection. When an attack is detected, all network traffic is immediatelydiverted to dedicated scrubbing centers that remove attack traffic. During anattack, we usually divert traffic to DE-CIX in Frankfurt because ProtonMail haspreviously experienced attacks that would seriously stress the national networkcapacity of Switzerland.

After the removal of attack traffic, clean traffic is delivered to our networkedge via redundant GRE tunnels [4]. Thus, attack traffic is prevented fromhitting our border routers and overwhelming their capacity. The system that hasbeen implemented in partnership with Radware is capable of withstanding up to2 Tbps of attack traffic and has successfully defended against attacks reachingup to 120 Gbps (for comparison, the largest DDoS attack ever launched was500 Gbps). Due to the frequency with which our network sees attacks, DDoSprotection is usually maintained in an “active” state which allows our networkto automatically respond within 18 seconds of an attack with no impact tocustomers.

Conclusion

As a whole, ProtonMail’s cloud based encrypted email services provide a strongcombination of security, usability, and reliability that is essential for any en-terprise. Consistent with our company values of transparency and peer review,most of ProtonMail’s code is open source and available for review by the se-curity community. As part of that community, we are also actively engagedin both public and private efforts to improve the state-of-the-art in encryp-tion technology. Thus, specifications and implementation details discussed inthis whitepaper are always subject to change as improvements become avail-

19

DDoS

Mitigator

ProtonMail

Client

Attacker

Attacker

Client

Attacker

Figure 6: The network configuration when ProtonMail is under attack

able through continued research and development. For the most up to datewhitepaper, please contact your account manager.

20

References

[1] David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry,Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Em-manuel Thome, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, San-tiago Zanella-Beguelin, and Paul Zimmermann. Imperfect forward secrecy:How Diffie-Hellman fails in practice. In 22nd ACM Conference on Com-

puter and Communications Security, October 2015.

[2] J. Callas, L. Donnerhacke, H. Finney, D. Shaw, and R. Thayer.OpenPGP message format. RFC 4880, RFC Editor, November 2007.http://www.rfc-editor.org/rfc/rfc4880.txt.

[3] M. Crispin. Internet message access protocol - ver-sion 4rev1. RFC 3501, RFC Editor, March 2003.http://www.rfc-editor.org/rfc/rfc3501.txt.

[4] Dino Farinacci, Tony Li, Stan Hanks, David Meyer, and Paul Traina.Generic Routing Encapsulation (GRE). RFC 2784, RFC Editor, March2000. http://www.rfc-editor.org/rfc/rfc2784.txt.

[5] J. Jonsson and B. Kaliski. Public-Key Cryptography Standards (PKCS)#1: RSA cryptography specifications version 2.1. RFC 3447, RFC Editor,February 2003. http://www.rfc-editor.org/rfc/rfc3447.txt.

[6] J. Klensin. Simple Mail Transfer Protocol. RFC 5321, RFC Editor, October2008. http://www.rfc-editor.org/rfc/rfc5321.txt.

[7] D. M’Raihi, S. Machani, M. Pei, and J. Rydell. TOTP: Time-basedOne-Time Password algorithm. RFC 6238, RFC Editor, May 2011.http://www.rfc-editor.org/rfc/rfc6238.txt.

[8] John M. Pollard. Monte Carlo methods for index computation mod p.Mathematics of Computation, 32(143):918–924, July 1978.

[9] D. Taylor, T. Wu, N. Mavrogiannopoulos, and T. Perrin. Using the SecureRemote Password (SRP) protocol for TLS authentication. RFC 5054, RFCEditor, November 2007.

[10] Radware Emergency Response Team. Global application & network secu-rity report. Technical report, Radware, 2015-2016. Figure 4.

[11] Thomas Wu. SRP-6: Improvements and refinements to the Secure RemotePassword protocol. Submission to IEEE P1363.2 working group, October2002.

21