Why encryption would not have saved General Petraeus (part I)

The resignation of General Petraeus in the aftermath of details emerging of his correspondence with Paula Broadwell has reinvigorated the debate around privacy of data entrusted to cloud service providers. EFF provided a good summary of discrepancies in existing law, where there are seemingly haphazard exceptions carved for communications stored for more than 180 days or already-opened messages– exceptions that may have made it easier for FBI to obtain access to email exchanges between the general and Ms. Broadwell.

A knee-jerk reaction here is to argue they should have been using encryption all along. But this calls to mind a statement variously attributed to Peter Neumann or Roger Needham: “If you think cryptography is the solution to your problem, you either don’t understand cryptography or you don’t understand your problem.” There are three reasons why encryption is particularly fraught with problems for this use case.

1. Usability challenges. Web email providers for the most part have little or no integration with client-side encryption schemes, such as S/MIME or PGP. The average user of these services has no way to compose an email that is not going to be readable by both the sender and recipient services. This limitation is not to be confused with encryption of content to/from the user to the service. Protecting those links with SSL is standard practice today. (Although that in itself is a relatively new phenomenon– GMail lead the way among major providers by switching on SSL by default in 2010 in the aftermath of the China incident, although niche services such as Hushmail supported SSL going much earlier.)

Part of the fault lies with web browsers: they do not make it easy to exercise the cryptographic capabilities of the underlying OS in a platform-independent way. Speaking of Hushmail, that was an example of an attempt at overcoming the browser limitations using a custom Java-based solution itself authored by Hushmail and later implementing cryptographer server side. In the end it only proved the limitations of the model: because encryption code was provided by Hushmail itself (as opposed to being part of software locally installed on end user machine) at the behest of law enforcement it could be replaced by a Trojaned version that surrendered key material.

It is possible to indirectly use S/MIME or PGP by having a native client installed on the local machine. (Also called “rich client” in come circles, casting aspersions at the quality of web based user-interfaces) Examples of these are Outlook, Mozilla Thunderbird and Eudora. These applications either have built-in support or define an extension mechanism for third-parties to implement strong cryptography. They can also be configured to work with popular cloud providers such as Yahoo or GMail for sending/receiving email.

In this model, the email provider becomes glorified storage box for encrypted content. It has zero visibility into the content of messages exchanged, only seeing an opaque stream of unintelligible ciphertext. The privacy goal is achieved, but at what cost? Encrypted messages can only be sent from machines where email clients are setup and cryptographic keys available. The first limitation means that it is not possible to point any old web browser at mail.google.com to read email. Encrypted messages will appear with blank contents, with the actual ciphertext in an attachment that the service provider can not make sense of. Search over email contents will not work– since original message is not available, it can not be indexed. (Neither will ad targetting, but that is arguably a problem the user cares less about.)

There is also the problem of key management but in this regard General Petraeus and Ms. Broadwell were fortunate. As defense employees, they would be in possession of PIV cards, which are smart-cards that can store cryptographic keys for different purposes: authentication, digital signatures, encryption and even physical access with badge readers. Moreover the widespread use of PIV card for logical access has motivated different vendors to make sure their platform makes it easy to use the cards. Case in point: PIV support is built into Windows 7 with no additional middleware required. In the most likely scenario of two users running Outlook on a recent vintage Windows machine, signing or decrypting a message would be as easy as inserting the card into the reader and typing in the PIN. For two random users without the benefit of a government issued smartcard or an ecosystem shaped by market pressures to support that card, it would be a different magnitude of difficulty trying to decrypt messages on another machine.



Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s