ProtonMailSecurityFeaturesandInfrastructure a bridge service to maintain encryption and...

Click here to load reader

  • date post

    20-Apr-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of ProtonMailSecurityFeaturesandInfrastructure a bridge service to maintain encryption and...

  • ProtonMail Security Features and Infrastructure

    Proton Technologies A.G.

    8 July 2016

    Contents

    Introduction 3

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

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

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

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

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

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

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

    Email Client Compatibility 15

    Infrastructure 16 Mail Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Database 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 around the world, ranging from private individuals to large enterprises. It aims to provide a much higher level of security than traditional email services without adversely impacting usability.

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

    ProtonMail’s security extends beyond just strong encryption. We have seen time 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 against this. First, ProtonMail uses strong authentication which makes most brute force or dictionary attacks impossible – even if an attacker has compromised the connection between client and server. Second, ProtonMail’s encryption protocols ensure that a single compromised account does not endanger other accounts.

    We firmly believe that the most secure system is one that users will actually use. Thus, ProtonMail was designed from the ground up with a strong emphasis on usability. To accomplish this, we built the first encrypted email system where the encryption is entirely automatic and invisible to the end user. For usabil- ity reasons, we retain compatibility with legacy email protocols such as IMAP and SMTP so ProtonMail accounts can be accessed from existing email clients and can seamlessly communicate with non-ProtonMail email accounts. How- ever, because of the inherent insecurity of IMAP and SMTP, ProtonMail uses a bridge service to maintain encryption and authentication without sacrificing IMAP/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 enterprise software. 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 of ownership for email infrastructure. For these reasons, ProtonMail is primarily deployed 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 for ProtonMail’s authentication and encryption technology. The next sections dis- cuss the ProtonMail’s extensive administrative tools and how key management is handled within an organization, followed by details of how ProtonMail se- curely supports legacy email clients. Lastly, an overview of ProtonMail’s secure cloud infrastructure is provided, with a discussion of the technologies we utilize to 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, the password cannot be derived by either ProtonMail or an attacker with access to the network. This is achieved with the Secure Remote Password protocol, which as detailed below, conveys a zero-knowledge password proof from the user to the server. The security granted by this protocol extends to the user’s private keys, which are encrypted with a salted hash of their password before being sent to the server. For additional security, users also have the option of enabling two-factor authentication.

    Issues with Traditional Password Authentication

    Most online services send the cleartext password or password equivalent to the server on every login. If the server is compromised, whether from malicious code injected onto the server or due to a memory exposure such as in the recent Heartbleed vulnerability, user passwords or password-equivalents can be leaked no 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 intermediary system between the client and server. This possibility is not as unreasonable or unlikely as it may seem. There have numerous incidents of certificate authorities issuing fraudulent certificates or computers being changed to trust insecure au- thorities. In 2001, VeriSign issued false Microsoft certificates; in 2011, Comodo and DigiNotar issued false certificates to several websites, including Google and Mozilla; in 2012 it came to light that Trustwave had created a subordinate root certificate capable of attacking a connection to any website; in 2015 it was re- vealed that Lenovo laptops were shipped with Superfish, software that, among other things, caused the system to trust a root certificate with a publicly known private key. This problem is exacerbated by the certainty that a state actor could force a certificate authority to issue fraudulent certificates.

    In contrast, the Secure Remote Password protocol [11] promises theoretically optimal security. When using SRP, even an attacker who can arbitrarily read, modify, delay, destroy, repeat, or fabricate messages between ProtonMail and a legitimate user in an undetectable fashion is limited to checking only a single password guess per login attempt, a task which could be done just by trying to log in directly. Even if a server is compromised and acts maliciously, password- equivalent information is never revealed. This is all done without permanent private 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 of the more well-known and widely deployed Diffie-Hellman key exchange. As in Diffie-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 prime number N and g, it is easy to compute gx mod N from x, but not the other way around. Accordingly, for a password p (pre-hashed and salted, both to make dictionary attacks slow and to ensure that there are no weaknesses due to predictability), the server stores the verifier v ≡ gp mod N . This verifier can be computed on the client side when setting a password, avoiding the need for the server to see any password-equivalent data. For login, the SRP protocol proceeds in two phases. In the first stage, the client and server generate a shared secret, following the pattern of Diffie-Hellman. In Diffie-Hellman, both parties generate random ephemeral public-private key pairs as a random secret a and ga mod N . Then, they can each mix their private key with the other party’s public key, producing a shared secret: (ga)b = gab = (gb)a mod N . SRP differs from this by mixing the verifier and the password into the key pairs, thereby causing 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