Security

STEED: End-to-end email encryption

Is end-to-end email encryption a lost cause, or do the existing protocols simply fail to meet the ease-of-use requirements needed for widespread adoption? That is a question the security community has debated for years without arriving at a consensus. Two key developers from the GnuPG project have outlined a new approach to email encryption that they call STEED, for "Secure Transmission of Encrypted Electronic Data." It is backwards compatible with existing OpenPGP and S/MIME standards, but seeks to smooth out the stumbling blocks that "casual" and non-technical users typically find onerous.

STEED is outlined in an October 17 white paper [PDF] co-authored by Werner Koch, co-founder of FSF Europe and lead developer of GNU Privacy Guard (GnuPG aka GPG), and Marcus Brinkmann, longtime Debian and GNU/Hurd developer and Koch's partner at security consulting firm g10code. The paper outlines the overall security approach taken by OpenPGP and S/MIME — including the setup, configuration, and maintenance tasks expected of the user, as well as the trust model that each scheme employs. S/MIME's trust model is called PKIX, for "public-key infrastructure for X.509," and encompasses the existence and operation of trusted certificate authorities (CAs). In contrast, OpenPGP's trust model is the web-of-trust (WoT), which depends on a global, decentralized reputation system.

Koch and Brinkmann argue that email encryption has failed to take off both because of "usability pitfalls" in OpenPGP and S/MIME approaches, and because the PKIX and WoT trust models fail to match up with user expectations and the "mental model" users associate with email. Ultimately, STEED is a set of practices that, if implemented in mail user agents (MUAs), mail servers, and encryption utilities, would put secure-by-default choices into play with a minimum of user involvement. The resulting system amounts to a different trust model, which the authors feel would seem saner to end users. The paper merely outlines the pieces that make up STEED; the authors are seeking feedback and input, but plan to push the work forward with actual specifications in the future, and code targeting Thunderbird, Outlook, Kmail, and a webmail client.

Components

STEED is comprised of three functional techniques: automatic key generation, automatic key distribution via DNS, and opportunistic encryption.

With automatic key generation, the MUA would automatically create an OpenPGP key-pair or a self-signed S/MIME certificate whenever creating a new mail account. The name and email address associated with the key or certificate are taken directly from the account set-up data, and cryptographic parameters are pre-configured in the MUA using sane defaults. S/MIME, like TLS, is intended to work with CA-signed certificates, but self-signed certificates are cryptographically equivalent — the difference is that self-signed certificates do not follow the PKIX trust model, which STEED is intending to supplant anyway.

If there is anything more confusing to new users than public-private key-pairs, the authors suggest, then it is the "unpractical" methods used to store, distribute, and retrieve keys. Their solution is to replace dedicated keyservers with a DNS-based distribution method. DNS is decentralized, widely available, and the fact that email addresses include a domain name makes it fit naturally into the structures of existing DNS records. Obtaining an encryption key would be matter of querying the DNS server at the relevant person's email domain and asking for the record associated with that person's user name. An added bonus is that piggybacking on DNS automatically benefits from other security advances like DNSSEC. The white paper does not recommend a specific DNS resource record type, but does suggest that the DNS records store a key or certificate fingerprint and an associated URL linking to the full key.

Opportunistic encryption is, quite simply, encrypting messages by default. Encryption is intended to happen in the MUA, which will be left to implement its own policies regarding message headers, options presented to the user, and when to fall back to sending a message in the clear.

Trust

If everyone has a key, and other users' keys are easily retrievable via a DNS query performed transparently by the MUA, then email encryption and digital signatures would work smoothly. The remaining problem in the scheme is how to authenticate the key or email address of a remote person — particularly one that has not made contact in the past. After all, an attacker could intercept DNS queries and spoof an identity or perform a man-in-the-middle attack against a legitimate-looking contact.

The existing email encryption schemes tackle this problem with PKIX and WoT. But the authors cite a PGP usability study that indicates that these trust models are confusing to users:

Furthermore, they add, neither trust model matches up with users' natural expectations when using email, because both defer trust decisions to someone else. PKIX defers all trust judgments to an external authority, while WoT defers it to peer recommendations. In both cases, a binary trust determination is made before the communication is even read: "Neither system utilizes the users own experience with the peer in the context of the communication happening over time."

STEED's trust model is "trust upon first contact" (TUFC), which accepts the certificate or key of the remote party upon first contact, but persists and tracks it for the user. This is the trust model used by SSH, the authors note, and is what "virtually all users do anyway, when faced with the task to make a trust decision that interrupts their line of work." In other words, TUFC exists outside of an external "trust infrastructure," and leaves it up to the user to verify suspicious first contacts through other means (in person, phone calls, etc.). After the first contact, the system helps the user by flagging changed or revoked keys.

Challenges

Implementing STEED would require changes to the popular MUAs and encryption frameworks (including GnuPG), which the authors discuss, but there are also other challenges that cannot be solved by hard work alone. For example, automatic key generation is fine, except that users will either be interrupted to create (and then memorize) a passphrase, or else the passphrase must be stored somewhere. The paper suggests relegating passphrase storage to a "PIM service" — although the authors do not go into any significant detail. They appear to expect such a service to be network-accessible, and acknowledge that it must be able to communicate with MUAs (and other applications) from more than one platform. At one point, they refer to the service having a "passphrase vault," which implies encryption. Perhaps such a service is to protected by a user's existing account credentials, or else it would be imposing yet-another-password-to-remember, when one of STEED's goals is to spare users from choosing and remembering an encryption passphrase.

Since many email users today are content to store even sensitive correspondence with commercial SaaS companies, there might not be an elevated privacy concern with tossing a passphrase into the mix, but it is also just one more piece of information that could be stolen. On the other hand, STEED makes room for savvy users to create their own keys or use existing keys and security devices, so perhaps the extra-cautious could take that route. STEED's goal is to lower the bar for participation in secure email — at some point surely the benefits of preventing eavesdropping outweigh the risk of losing a passphrase.

A bigger issue is that STEED would require email providers to implement a key system in their DNS infrastructure, and a way for users to store and update their keys. That may not present them with a technical challenge, but convincing providers to change their policies and DNS infrastructure would be a huge undertaking. In addition to that, so many users today use webmail services like GMail that are available over SSL/TLS, which makes implementing a "new" security system an even harder sell.

There is also the issue of how to properly handle user mobility, particularly when users wish to access the same mail account from multiple devices. The authors do not offer easy solutions to any of these questions in the paper, but there is a sizable STEED discussion thread running on the GnuPG mailing list.

Jerome Baum suggested bypassing email providers' DNS and including a URL (privately-hosted or on a keyserver) for the sender's encryption key as a mail header instead. That idea has the benefit of being "in-band" and not requiring email provider support, though it still requires changes to the MUA. Peter Lebbing suggested using Bittorrent or another peer-to-peer system for hosting and retrieving keys.

Mark H. Wood said that attempting to bypass the passphrase-management problem is asking for trouble. "To be secure without being involved in the process is an unreasonable expectation which can never be met." Better, he said, to focus on generating passphrases that can be easily memorized, than to suggest storing them off-site.

Perhaps the thorniest problem was raised by Tom Ritter, who observed that supporting multiple devices also means supporting temporary usage of any random computer. "There's the very practical problem of _sometimes_ I do need to read my mail from a machine that is not my own. As a security person I almost never do it. But 'the young crowd' do it all the time. You have to satisfy that requirement also." Of course, most temporary email access of this type is done through a web mail interface, which has its own share of problems: either implementing the cryptographic functions in JavaScript or another client-side technology, or decrypting messages on the remote server. Either option carries risks. In addition, doing the encryption/decryption on the server breaks the "end-to-end encryption" principle.

Koch is scheduled to speak about STEED in November at the 2011 Free Society Conference and Nordic Summit (FSCONS); there may be changes to the proposal or further details on the protocols at that time. Until then, despite all of the debate, the consensus view on the GnuPG list is that STEED is at least taking on a very important problem: most people do not use email encryption because it is too difficult to configure and manage. Taking most of the decisions out of the user's hands and settling them in the MUA may not be perfect, but it would make for a vast improvement.

Even that, however, would not tackle the biggest obstacle to email encryption of all — the naive assumption by many users that their email is already secure because the lock icon is visible in the browser's location bar. At its heart, STEED is an attempt to make MUAs "do the right thing" more and rely less on the user, because the technical underpinnings of end-to-end encryption are already well-understood by the developer community. STEED is completely compatible with user-driven OpenPGP and S/MIME. But whether or not it could push the apathetic masses into end-to-end encryption remains to be seen. Perhaps nothing can, but making it simpler is certainly better than nothing.

Comments (15 posted)

Brief items

Security quotes of the week

Comments (4 posted)

New vulnerabilities

asterisk: multiple vulnerabilities

Comments (none posted)

clamav: recursion level crash

Comments (none posted)

cyrus-imapd: denial of service

Comments (none posted)

dbus: symlink attack

Comments (none posted)

etherape: denial of service

Comments (none posted)

fail2ban: insecure temp files

Comments (none posted)

freetype2: code execution

Comments (none posted)

java-1.6.0-sun: multiple unspecified vulnerabilities

Comments (none posted)

kernel: denial of service

Comments (none posted)

kernel: multiple vulnerabilities

Comments (none posted)

kfreebsd-8: code execution

Comments (none posted)

nova: information leak

Comments (none posted)

open-iscsi: code execution

Comments (none posted)

opera: code injection

Comments (none posted)

pam: arbitrary code execution

Comments (none posted)

phpMyAdmin: multiple vulnerabilities

Comments (none posted)

puppet: man-in-the-middle attack

Comments (none posted)

xen: denial of service

Comments (none posted)

XTier: code execution

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>