LEAP: The LEAP Encryption Access Project
Property
P2P
Silo
Federated
Availability
Low
High
High
Usability
Low
High
Low
Control
High
Low
High
Authenticity
High
Low
High
Anonymity
Low
Low
Low
Unmappability
Low
Low
Low
In contrast to a silo such as Facebook that runs continuously with high availability, in peer-to-peer systems an available low latency path to another peer can not be guaranteed. This also holds for federated systems, although less so as the number of servers is relatively low so path latency tends to be higher. Furthermore, peer-to-peer systems tend to fail to be usable, requiring special software be installed, as do many federated systems. User control tends to be low in silos, as users usually cannot retrieve their data and can by definition only communicate to other users of the silo, unlike peer-to-peer and federated systems. Authenticity tends to be high in peer-to-peer systems as peers can authenticate to peers, but can remain anonymous insofar as they do not have to authenticate to any master server unlike in silos and federated systems. In practice, the authenticity of peer-to-peer systems is often low, since many users do not properly use shared secrets or check key fingerprints. However, all systems fail to be unmappable. Silos by nature maintain all personal data in a centralized form accessible to system administrators, while federated systems fragment this between multiple servers. Even federated and peer-to-peer systems that allow anonymous usage reveal the social graph of their users to outside adversaries rather easily via traffic analysis, which is perhaps the one saving virtue of silos: At least with a silo, an outside adversary can’t determine your friends. The information gained by mapping a social graph of any given user can usually reveal their identity even if a system allows users to join a communication channel without revealing their anonymity.15
Unfortunately, these problems with the properties above appear to be unsolved regardless of which architectural approach a user takes (centralized authority, distributed peer-to-peer, or federated servers). Indeed, in this regard the federated approach does not actually solve all the problems of secure communication perfectly, but rather is a deployment strategy with certain security properties that allow it to fight the disadvantages of the peer-to-peer approach (sybil attacks and latency) and the centralized silo approach (single point of failure). If a centralized system only has to communicate with itself, it can solve the hard problems by trusting itself completely and thus only communicating within its trust boundary. However, this is unrealistic for many cases such as chat or email, and still contains the fatal flaw of a single point of failure. It is possible to safely ignore many of these problems if a system also ignores usability or matching the features that users have grown accustomed to with contemporary methods of online communication. Yet if a new system does care about usability and features, then it will demonstrate value across all these properties and so tackle any contingent problems in implementation.
15.3 Threat Model and Design
We consider the primary goal of stopping pervasive surveillance making it technically as difficult as possible for the contents of a message to be read by any party other than the intended recipient while preserving as much as possible the privacy of both sender and recipient. What is a necessary first step is end-to-end encryption applied to the actual content of messages from client to client. For our threat model, we are considering two distinct types of attack, an active server attacker that focuses decrypting messages on the server and a global passive adversary that simply copies all messages (encrypted or not). For attackers, the goal is to gain access to the content of the encrypted messages and to determine the social graph of who is communicating to whom. For decrypting messages, attacking a single server with many clients makes more sense than attacking many clients for most attackers. For this section, we will consider only the first attacker, as the second is more difficult to solve and an area for future research (see section “Future Research and Conclusion”).
The active server attacker uses either technical attacks or legal means to force a server to hand over the private keys of its users so the attacker can decrypt the encrypted messages. To prevent this, the private key material must not remain on any server, so that an attacker cannot decrypt the encrypted message by compromising the server or placing the server under compulsion. A case in point would be Lavabit, which had a single point of failure by virtue of being a company incorporated in the United States, so legal compulsion forced its shutdown.
How can we keep a federated model while the keeping the keys on the client? The problem can be broken down into a number of distinct components: server-side infrastructure, usable client software, and the fundamental protocol itself. Current OpenPGP-compliant or other content encryption protocols are difficult to set-up for many end-users and server administrators. As a result only a few large servers such as Google or activist e-mail servers under considerable threat (such as riseup.net) implement the server-side infrastructure for the protocols such as proper use of DKIM,16 and while standards like S/MIME17 are more widely supported, they are ignored by webmail clients and even many non-Web clients. LEAP facilitates such infrastructure deployment by creating “puppet” (automation) scripts for many of the harder tasks involved in setting-up a privacy-enhanced and secure email provider.18 Yet setting up certificate pinning19 and other best practices for email service providers is not enough. What is necessary is to have the client and server actively work together in order to encrypt the message, so to prevent the situation where private key materials are stored only on the server and defended only by weak defenses such as passwords.
Simply storing the private key on a single device of the user, as done by most encrypted mail programs, is not enough as users now want to read their e-mail through multiple devices. The main problem facing such a system is safely getting the correct keys onto users devices. LEAP accomplishes this through a multi-purpose client that appears to the user simply as an OpenVPN20 client, which is more accurately called the “Encrypted Internet Proxy” (EIP) client in LEAP (as different transport protocols could be used, such as Tor, rather than OpenVPN). However, there is more than meets the eye to the EIP functionality in the LEAP client: The LEAP client is bundled with the routines for generating, validating, and discovering keys as well as synchronizing keys and related material (such as the status of messages being “read” across multiple devices). This is the heart of the LEAP system.
Key storage and operations in the LEAP client piggyback on an OpenVPN EIP client since many users who would not install a native email reader application such as Thunderbird due to their preference for Web-based mail, but users likely would install a VPN on their system to enable activities such as file-downloading or watching streaming videos, but would not install an obtuse program just to aid key management. The LEAP client can then also generate keys, and with the help of the server can even manage the keys by using server-enabled discovery and trusted validation of public keys for the recipient of an email. Lastly, while some email clients such as Mailpile may natively supports encryption, LEAP allows users to continue using their existing non-Web e-mail client by providing a local SMTP proxy that captures unencrypted email, encrypts it, and then sent it out using the LEAP protocols.
15.4 State of LEAP Client-Server Architecture
The LEAP architecture consists of two main components, the LEAP Platform and the LEAP Client. Illustrated in Fig. 15.1, we show how a single server (S 1) runs the LEAP Platform that is accessed by a user (U 1) with a LEAP client installed on their machine, so that LEAP-enabled server can then encrypt messages to another server (S 2) so they may reach another user (U 2). Note that the user U 2 may be connected to another LEAP-enabled server or may simply be using public key encryption technologies of their choice, such as Thunderbird or Outlook.
Fig. 15.1
Components of LEAP email architecture
The LEAP platform offers a set of automation tools to allow an organization to deploy and manage a complete infrastructure for providing user communication services. The LEAP client is an application that runs on the user’s local device and is tightly bound to the server components of the LEAP Platform. The client is auto-updating (via Tor’s Thandy21), auto-configuring, and cross platform. Although message security rests entirely on a foundation of authenticity, since without proper validation of encryption keys a user cannot be assured of confidentiality or integrity, current systems of establishing message authenticity are so difficult to use that many users simply ignore this step (Gaw et al. 2006). LEAP will address authenticity by not only having opportunistic encryption but also strong and automatic identity validation. Lastly, recent advances in social network analysis have made unmappability an urgent requirement for any architecture that seeks to address the surveillance situation, which LEAP plans to address with graph resistant routing. Improvement in these areas will come at a price: Although LEAP communication tools will be backward compatible with existing federated standards such as SMTP, a user of the LEAP system will not have the same degree of choice in client software and providers as does a user of a traditional federated system.
15.4.1 LEAP Platform
The LEAP Platform consists of a command line tool and a set of complementary puppet modules. The recipes allow an organization to operate one or more clusters of servers to provision LEAP-enabled services. With the LEAP command line tool, a system administrator can rapidly deploy a large number of servers, each automatically configured with the proper daemons, firewall, encrypted tunnels, and certificates.
The LEAP Platform recipes define an abstract service provider, with recipes for complementary services that are closely integrated together. To create an actual infrastructure, a system administrator creates a “provider instance” by creating simple configuration files in a filesystem directory, one for each server. Typically, a system administrator will not need to modify the LEAP Platform recipes, although they are free to fork and merge as desired. The “provider instance” directory tree should be tracked using source control and is a self-contained encapsulation of everything about an organization’s server infrastructure (except for actual user data).
15.4.2 LEAP Data Storage
One design goal of the LEAP platform is for a service provider to act as a “untrusted cloud” where data are encrypted by the client before being sent to the server and we push as much of the communication logic to the client as possible. There are a few cases where the server must have knowledge about a user’s information, such as when resolving email aliases or when processing support requests. In the current implementation, data storage is handled by BigCouch, a distributed document-centric database server.22 Every user has a personal database for storing client encrypted documents, like email and chat messages. Additionally, there are several non-encrypted databases containing the minimal information needed to connect user accounts to optional support tickets and even billing details. The LEAP Platform includes a web application for user and administrator access to these non-encrypted databases, although future research will hopefully be able to minimize if not eliminate this information.
15.4.3 Soledad
Soledad (“Synchronization Of Locally Encrypted Data Among Devices”) is responsible for client-encrypting user data, keeping it in sync with the copy on the server and a user’s other devices, and for providing local applications with a simple API for document storage, indexing, and search. Soledad is implemented on the LEAP client to store email messages, the user’s public and private OpenPGP keys, and a contact database of validated public keys.
Soledad is based on U1DB, but modified to support encryption of both the local database replica and every document before it is synchronized with the server.23 Local database encryption is provided by a block-encrypted SQLite database24 via SQLCipher.25 Documents synchronized with the server are individually block encrypted using a key derived produced via an HMAC of the unique document id and a long storage secret. In order to prevent the server from sending forged or old documents, each document record stored on the server includes an additional client-computed MAC derived from the document id, the document revision number, and the encrypted content. The server time-stamps each update of the database, so that Soledad’s MAC and HMAC key used to encrypt the client database can only send the server new databases. The key for every device is attached to LEAP client.