Misunderstood: WikiLeaks, The CIA, And Encryption

Much of the excitement surrounding the WikiLeaks “Vault 7” release of purported CIA documents concludes that the CIA has broken encryption.  We didn’t reach the same conclusion.  We explore potential vulnerabilities in encryption apps and conclude that end-to-end encryption, coupled with strong protection at the device level remains the best way to secure everyday communication.

Headlines

WikiLeaks’ recent release of documents purportedly from the CIA, called “Vault 7,” has created quite a media storm.  Allegedly, the CIA has been able to bypass encrypted messaging apps on Android phones.  Many commentators conclude that the CIA has been able to “break” encryption, enabling it to decrypt all kinds of secure information.  If anyone, including the CIA, could break state-of-the-art encryption algorithms, the result would be catastrophic.  Encryption is used to safeguard a lot of information, and if one entity could break it, we are all very vulnerable.

We have seen no reported evidence, however, that the leaked documents contain proof that encryption has been broken.  Rather, the news implies that the CIA could be using vulnerabilities in phone and computer software to gain access to information before it’s encrypted.

Potential Vulnerabilities of Apps using Encryption

Let’s consider some ways apps using encryption could be vulnerable.  A typical messaging app works like this:

Potential

A message (e.g. email or chat) is created using an app on a phone or computer.  It’s then encrypted by the app and then sent over the Internet to a server, which stores this message along with others.  It is then decrypted at some point and delivered to the recipient’s device.  There are several ways an attacker can compromise this system.

Decrypting at the Server

Most Internet applications use encryption to secure communications between a user’s device and the server.  These applications generally use SSL (secure sockets layer) or TLS (transport layer security), standards that encrypt traffic between client devices (phones and computers) and servers.

Decrypting

As can be seen in the diagram above, the message originally encrypted by an app in a phone is decrypted at the server, so the server can process it.  The encrypted message is shown in green and the decrypted message is orange.  While the encryption prevents an attacker from seeing the message en route to the server, once the message is decrypted on the server, an attacker can access it.  Unfortunately, many popular email programs, including Gmail and Microsoft Outlook 365, work this way.  Most of the email processing occurs on the server, so the server has to operate on decrypted messages.

The result is a significant vulnerability at the server.  This is a big problem because, from an attacker’s perspective, the server is the richest target.  If the attacker compromises the server, it could see all the messages from all users of the system, potentially leaking a lot of information. Because the most damaging attacks occur at the server, the technology industry has historically paid a lot of attention to protecting it, in essence building “taller walls” around data centers.  Inevitably, however, servers are compromised.  Notable examples include the email attacks on servers at the Democratic National Committee, the attack on Sony’s email servers, and Yahoo’s admission that up to a billion user accounts may have been compromised over the past few years.  All of these were attacks that resulted in information compromised from servers.

End-to-end Encryption

Properly designed end-to-end encryption can address this server vulnerability problem.  End-to-end encryption means that a message encrypted in the app of one user’s device is never decrypted until it reaches its destination in the app of another user’s device.  The message is shown in green throughout the communication, indicating that encryption is occurring end-to-end.

End

With end-to-end encryption, the server stores only encrypted data; server attackers see only gibberish.  This significantly reduces the likelihood of large scale breaches.

The Keys to Encryption

Any time encryption is used, it relies on keys (which are essentially numbers with lots of digits) that lock or unlock the data.  These keys must be safeguarded.  Even if data is encrypted end-to-end, if an attacker were to obtain the decryption key then users’ data would be unprotected.  Similarly, if an attacker were to trick a user into using the wrong encryption key, the user’s information would also be compromised.

keys

Managing these keys can become complicated.  Some systems require the user (or IT administrators) to create, install and maintain the keys.  Others try to make things easier by managing the keys automatically for the user, often by storing the keys on the server.  But storing the keys on the server can make them vulnerable to a server attack.  Other systems encrypt the keys on the server, using a user password, to minimize the likelihood of a successful server attack.  Yet even this scheme has vulnerabilities as there are well understood methods for guessing a high percentage of user passwords.  Storing decryption keys on a server amounts to giving the server the ability to decrypt users’ data.

Attacks Prior to Encryption

Even when well-crafted end-to-end encryption is used, information has to be decrypted somewhere, and it’s usually in an app running on the user’s computer or mobile device.  Vulnerabilities are discovered in phone and computer operating systems on a regular basis.  Some software developers and phone manufacturers are pretty good at fixing these security holes, hence, it is important to apply security patches in a timely manner.

Attacks

Summary

The WikiLeaks documents suggest that the CIA is using a variety of techniques that can exploit vulnerabilities in computer and phone software.  We have not seen evidence that the encryption algorithms themselves have been broken.  Rather, the articles we’ve seen imply that the CIA could be exploiting device vulnerabilities to gain access to information before it’s encrypted.

In the end, to achieve a strong level of security for the entire user-to-user path, one needs a combination of a well-designed end-to-end encryption protocol with strong protection within users’ devices.

About Raluca Ada Popa
Raluca Ada PopaRaluca Ada Popa is Founder and Chief Technology Officer at PreVeil, a Boston cybersecurity company that provides end-to-end encrypted email and file sharing. Her research is in security and applied cryptography. Raluca has developed practical systems that protect data confidentiality by computing over encrypted data as well as designed novel encryption schemes. Raluca received her PhD in computer security as well as two BS degrees, in computer science and in mathematics, from MIT. She is the recipient of an Intel Early Career Faculty Honor award, George M. Sprowls Award for best MIT CS doctoral thesis, a Google PhD Fellowship, a Johnson award for best CS Masters of Engineering thesis from MIT, and a CRA Outstanding undergraduate award from the ACM.
About Nickolai Zeldovich
Nickolai ZeldovichNickolai Zeldovich is Chief System Architect at PreVeil, a Boston cybersecurity company that provides end-to-end encrypted email and file sharing. He is also an Associate Professor at MIT's department of Electrical Engineering and Computer Science, and a member of the Computer Science and Artificial Intelligence Laboratory. His research interests are in building practical secure systems, from operating systems and hardware to programming languages and security analysis tools. He received his PhD from Stanford University in 2008, where he developed HiStar, an operating system designed to minimize the amount of trusted code by controlling information flow. In 2005, he co-founded MokaFive, a company focused on improving desktop management and mobility using x86 virtualization. Prof. Zeldovich received a Sloan fellowship (2010), an NSF CAREER award (2011), the MIT EECS Spira teaching award (2013), and the MIT Edgerton faculty achievement award (2014).
In this article