Does the NSA Have a CA?

Since Edward Snowden started leaking secrets to the media, we’ve learned that our government has been up to all kinds of sneaky things — surveiling our allies, getting call records from big telecom providers, retrieving information from online services about our online activity, building massive databases, keeping data about Americans for years.

One of the reasons these revelations are upsetting is because the government security apparatus has had massive cooperation from the companies we trust with our data — Google, Verizon, Apple, AT&T, Yahoo, Facebook, and Microsoft. We know this much about some of the ways that Microsoft has been helpful:

Microsoft has collaborated closely with US intelligence services to allow users’ communications to be intercepted, including helping the National Security Agency to circumvent the company’s own encryption, according to top-secret documents obtained by the Guardian.

So far, we know that Microsoft has allowed the NSA to circumvent their user’s data security requirements on Skype, Outlook.com/Hotmail, and Skydrive. Microsoft claims to have had no other choice:

In a statement, Microsoft said: “When we upgrade or update products we aren’t absolved from the need to comply with existing or future lawful demands.” The company reiterated its argument that it provides customer data “only in response to government demands and we only ever comply with orders for requests about specific accounts or identifiers”.

The devil is in the details, of course. Given the scope of the Verizon data requests (i.e. everyone), for all we know, the NSA has issued legal demands for hundreds of millions of accounts.

That these tech companies are compelled to cooperate due to secret orders from a secret court is not comforting. I wonder what else the court has compelled them to reveal. It reminds me of one nightmare scenario that I used to worry about even before Snowden’s leaks: What levels of cooperation does the NSA get from root Certificate Authorities?

Unless you’re a computer geek, that probably doesn’t mean much to you. Let me explain…

When you go to secure site — one that begins in “https:” and makes the little lock symbol show up in your browser — that causes your browser to exchange encryption keys with the server to set up a secure encrypted connection. More than that, however, it guarantees that the browser is actually connected to the server you think it’s connected to, such as your bank’s online service page.

Without that second guarantee, a clever hacker or the NSA might be able to fake you out with something called a man-in-the-middle attack. That’s an attack where someone diverts your communications channel through a computer that can monitor it. It would work something like this:

• Your browser requests a secure connection to the bank’s server.
• Somewhere along the way, an NSA-controlled computer intercepts the connection request and pretends to be the bank’s server.
• At the same time, the NSA computer makes it’s own request to the bank’s server, pretending to be your browser.
• The bank’s server responds to the NSA request with an encrypted connection that you can use to talk to it securely.
• The NSA computer intercepts that response.
• The NSA computer responds to your browser’s request with its own encrypted connection, pretending to be the bank.
• Your browser receives the NSA computer’s response, and sets up the connection, thinking it’s talking to the bank, when it’s really talking to the NSA computer.

Now, whenever you send something to the bank (probably starting with your username and password) your browser will encrypt it for transmission to what it thinks is the bank’s server but is really the NSA computer in the middle. The NSA computer will decrypt it, read it, and then re-encrypt it for the real bank server and send it on its way. When the bank server sends it’s response back, it will think it’s talking to you (after all, you just sent the correct username and password) but it will actually be encrypting it for the NSA computer, which will intercept it, decrypt it, read it, and then re-encrypt it for you and send it back to you. As far as you’ll know, it came from the bank, and neither you nor the bank will know the NSA computer is sitting in the middle, reading everything you do.

In reality, it’s not quite that easy for the NSA (or anyone else) to insert themselves in the middle of a secure channel because the internet has a system in place for guaranteeing the identity of servers using public key signing. The operators of the server use a computer program to generate a random keypair — an algorithmically-related pair of digital strings, one public, the other secret, and each hundreds or thousands of bits long, that have a useful property: The secret key can be used to sign data, and the public key can be used to verify that signature.

This works by using the secret key as a parameter to a signing algorithm that, given a chunk of data, will generate a digital signature (another string hundreds or thousands of bits long) that is unique to that data and that secret key. Anyone who receives the data and the signature can check it by plugging the data and signature into a signature verification algorithm that is parameterized by the public key. In other words, only the owner of the secret key can sign the data, but the public key can be used by anyone in the world to verify that signature. So any data with a signature validated by the public key could only have come from someone who has the secret key.

So when your browser requests a secure connection to the bank, the bank sets it up by signing its response with its secret key. Your browser uses the bank’s public key to verify that the signature on the setup message could only have been created by someone with the bank’s secret key. Assuming the bank has been careful with its secret key, this means that the message could only have come from the bank. If the NSA tries to use a man-in the middle attack, it will fail when you ask for a secure connection to the bank. The NSA doesn’t have the bank’s secret key, so it can’t produce a signature that your browser will recognize as valid for the message it uses to setup the encrypted connection.

(In the case of your U.S. bank, this may not really be a problem for the NSA, since U.S. banking law pretty much means the government has access to everything the bank knows about you anyway, and the bank can just give them copies of everything you send. So feel free to imagine that this is your offshore bank in the Cayman islands. Or maybe you want to download movies from The Pirate Bay, or gamble in an online poker site run out of the Isle of Man. Or maybe you just want to send an email message to a friend without some friggin’ government agent looking over your shoulder. The signing system is intended to prevent anyone — including the NSA — from being able to insert itself into the middle of the encrypted communications.)

There’s one big problem: Key distribution. How do you get the bank’s public key? You could ask their server for it, of course, but that gets us right back to the man-in-the-middle attack — since you don’t already have the public key, there’s no way for you to verify that you actually received the key from the bank’s server. The NSA could sit in the middle and when the bank sends its public key, their computer could intercept it and send you a fake public key that the NSA created just to fool you. How could you know?

The answer is that the bank’s public key is transmitted in the form of a digital certificate. The certificate identifies itself as a server signing certificate, it identifies the domain name it represents, and it includes the public key. Most importantly, the certificate is itself signed by another corporation. For example, Cayman National Bank‘s certificate is signed by Verisign, Inc. using their Class 3 Extended Validation SSL certificate.

So how do you know that the Verisign signature is real? Well, when the server sends you its certificate, it also sends you a copy of Verisign’s server signing certificate, which includes a public key your browser uses to verify Verisign’s signature on the bank’s server certificate.

This takes you further down the rabbit hole, because now your browser has to verify the server signing certificate. It can do this because (as you might expect by now) Verisign’s server signing certificate is itself signed, this time by one of the root Certificate Authorities — commonly called CAs. As it happens, Verisign is its own root CA, so the Verisign server certificate is signed by the Verisign Class 3 Public Primary Certification Authority.

The reason it’s called a “root” Certificate Authority is because it’s different from the other certificates in that its authenticity is not guaranteed by another certificate. It’s not signed. Instead, it has a trusted origin. It came with your browser, or as part of your computer’s operating system. It’s essentially built-in.

This establishes a chain of trust: You trust your operating system and browser, the browser trusts the root signing certificate, the root certificate validates the server certificate, and the server certificate validates your bank’s server, allowing it to setup the secure connection. So when you connect to your bank and see the little lock symbol, you know you have a secure connection to the correct server for the domain name you requested. No room for the NSA in there.

Unless, of course, the NSA has compromised one of the root CAs. Does a FISA court have the power to order Verisign to disclose its root secret key? Or has the government pressured Verisign to sign false certificates, at least when one party to the communication is a foreigner? That way, if the NSA wanted to spy on your communications with an encrypted chat room in Antigua, all they’d have to do is get Verisign to sign a false certificate for that server and they could get in the middle and impersonate it. After all, your browser will believe anything Verisign says.

The thing is, it doesn’t even have to be Verisign. There are a scandalous number of root CAs. The list of certificates Microsoft will trust is here, Firefox’s list is here, and this might be Apple’s list. (Google’s Chrome uses the same certificates as the operating system it’s running on — Microsoft or Apple — or Firefox’s list when running on Linux.) Any authority can sign a server certificate for any domain, so if the NSA can get cooperation from any one of them, they can impersonate any server they want.

Seriously, take a look at one of those lists of CAs (the Firefox list is most readable) and ask yourself how much you trust those organizations — GoDaddy, America Online, Verizon, Equifax — not to mention all the ones you’ve never heard of (Turktrust? Camerfirma? Elektronik Bilgi Guvenligi A.S.?)

The NSA is not the only threat, either. Several CAs are operated by foreign governments, including Spain, Turkey, Japan, Hong Kong, Taiwan, and China. Also, both Comodo and DigiNotar have been compromised by hackers. Google’s description of the DigiNotar incident is especially disturbing:

These actions by Diginotar raised serious questions about 1) their competence to run a Certificate Authority (of any kind, much less a Root CA), and 2) their interest in protecting the Internet as a whole, over their own interests.

All the major vendors revoked their trust of DigiNotar’s certificates and the company went out of business.

Frankly, in the process of writing this, I think I’ve answered my own question. Given what Snowden has revealed about the NSA’s proclivities, and with over 150 root CAs all over the world, run by both governments and private entities, I’m willing to bet that the NSA has at least one CA willing to do its bidding.

Maybe someday Edward Snowden will tell us.