One Key to Rule Them All: Threats Against Service Provider Private Encryption Keys

EFF has worked hard to convince organizations like Facebook and Wikimedia to join the ranks of many other large and small websites including Twitter, Gmail, and EFF in supporting HTTPS by default, and we're happy to see steady progress from major service providers on this front.

While increased deployment of HTTPS is a huge step forward in securing the web and protecting user communications, it is not a silver bullet. There are many types of attacks on HTTPS that we need to be vigilant about, but here we want to focus on one in particular -- how safe are the private encryption keys of service providers?

In order to understand why this question is so important, it is worth taking stock of a remarkable and scary fact about how HTTPS works: for any given website, the same key is used to protect all user communications on that website.

It is important to take a moment to fully absorb this, so let's walk through the example of Facebook. Every single one of the billions of transactions that occur on the social network every day are encrypted based on information derived from the same private key held by Facebook. This means that knowledge of the mere 2048 bits of data that comprise this key1 – small enough to be scribbled on a single piece of paper and mistaken for a 2nd grader's math homework – is all that stands between a powerful attacker and full, unfettered access to the plaintext communications of over a billion users of the popular social network: every private message, every chat, everything.

This situation is not unique to Facebook but also applies across the board to most other service providers who use encryption, like Google, Twitter, and Wikimedia.2 Given the almost unimaginable importance of these keys, they are an incredibly attractive target for criminals as well as for law enforcement and intelligence agencies. And the risks of failing to safeguard the keys are tremendous. Let's walk through them.

Law Enforcement and Intelligence Agency Access

Law enforcement or intelligence agency attempts to seek private SSL keys from providers should be considered not based on the nature of the keys themselves, but on what information the keys allow access to. This means that the law is different depending on, for instance, whether the information sought is content or noncontent or is sought via FISA, ECPA, the Wiretap Act, via a National Security letter or otherwise. We will do a subsequent post to discuss this in detail, but one point is worth noting here: for email providers, chat services, video conferencing and others transmitting the content of communications, a single private SSL key allows access to a huge amount of customer content. The vast array of communications protected by a single SSL key is even more exaggerated in the case of content delivery networks (CDNs) and hosting providers who often use a single SSL key for many different customers.

As such, any demand by the government to have access to such a key is more like an unconstitutional general warrant, and should run afoul of the particularity requirement of the Fourth Amendment. Similar limitations, usually based on relevance, exist even in statutes that allow for collection of noncontent. Given that access to a service provider’s SSL key will always give government access to a tremendous amount of information by or about innocent bystanders, it is hard to imagine a situation in which an order for such a key would NOT be overbroad.

Theft

Service providers like Google and Facebook run front-end web servers that handle the HTTPS handshake whenever you connect to the website. These web servers must have access to the relevant private key in order to work.3 On most servers, the key is simply represented as a short text file on the hard drive. If just one server is compromised, it could mean a compromised key, and if the attack is clandestine, the theft might go unnoticed.

In addition to remote compromise through hacking, a physical attack on data centers that house these front-end servers by could result in a stolen key.

Both of these dangers exist not only for service providers who run their own servers, but also for CDNs and hosting providers that hold keys on behalf of their customers.

Weak keys, and breakthroughs in cryptanalysis

Another possibility is that the service provider in question is using a key that is in some sense “weak”: perhaps it is insecurely generated and thus factorable, or perhaps the key is not long enough, to list a couple of examples. This would mean that the key could be potentially recovered with some sort of cryptographic attack.

And even if the service provider is doing everything right, there are few guarantees when it comes to real-world cryptosystems – it's possible that at some point in the future a researcher could expose a devastating flaw that would allow a particular type of key to be recovered with ease.

What can be done to protect private keys?

With respect to technical protections, we think that companies should use the highest level of security to protect these keys. Theft should be regularly monitored for, and keys should be promptly changed if any evidence of theft is discovered, or if advances in cryptography make use of a certain key inadvisable.

We also strongly recommend the use of Perfect Forward Secrecy (PFS). Sites that already use HTTPS can choose to enable PFS to better protect their users, and the advantages of PFS are detailed here. Some service providers, such as Google, already do this, and we hope that more join them.

Conclusion

The private SSL keys underlying HTTPS connections can unlock a huge amount of information. As we fight to increase HTTPS adoption and to improve the security of HTTPS, we must also ensure that private keys remain out of the hands of eager governments and criminals.