Update: Bruce Schneier
weighs in.
Original post:
Several readers (and a colleague) wrote to ask me about
this story (and the many others like it) that hit the web in the past few days. The stories don't have much detail beyond the fact that somehow seven people were chosen to hold the keys that it would take to “restart the Internet” in the event of a disaster. The more geekly folks out there know that the Internet is a highly distributed system with no central point of control, so the notion of restarting the Internet doesn't, on the face of it, make much sense. So what the hell is this story talking about?
Well, first of all, there's a bit of overdramatization in the story. Actually, a whole
lot of overdramatization. But there's also a grain of truth to it.
To understand what's going on here, you first need to understand a tiny bit about the
Domain Name System (DNS). Even though you may not realize it, you're probably using it every day. For example, if you typed “www.jamulblog.com” to read this blog, your web browser submits that name to DNS to look up the address (“74.125.47.121” in this case) of my blog's web server. Then your web browser contacts that web server to get the actual blog posts. So DNS is sort of like a phone book in which your web browser can look up names to find the address – which, like a phone number, it can use to contact a web server directly.
DNS has a trick that your phone book doesn't, however. If you ask for a name that your local DNS server (probably run by your Internet service provider) doesn't know, that DNS server will ask a “root server” for the address of the “authoritative” DNS server that
will know that name. For example, if you typed in my blog's address and your local DNS server had never heard of it before, your local DNS server would ask a root DNS server for the address of the authoritative DNS server for “jamulblog.com”. Then it would ask
that DNS server for the address of “www.jamulblog.com”. This is called a
recursive query. I've glossed over all sorts of details, but the basic idea of a recursive query is key to understanding this “restart the Internet” story. With me?
Recently (July 15th) the root DNS servers implemented
DNS Security Extensions (DNSSEC). These security extensions are a very complex, designed-by-gigantic-committee protocol designed to
allow DNS clients (such as your web browser) to verify that the DNS responses it receives (those addresses) are, in fact,
authorized (not forged) responses. Without these extensions, it's relatively easy for a program to forge DNS responses – so that you type in “www.bony.com” but instead of getting the Bank of New York, you get some site that
looks like the BONY site but is actually just trying to capture your password. Forging DNS responses is bad, and DNSSEC is designed to prevent it. But (and this is where the hype comes in) DNSSEC is
optional on the client (like your web browser). You can turn it off.
The way that DNS clients can verify that responses are authorized is to follow a
chain of authority all the way back to the root DNS server. Ignoring the details of how this works, it all depends on a Secret Master Key (SMK) that's held on the root DNS servers. This SMK is just a (very) big number, with something like 1000 digits in it. Without the SMK, the root servers could not generate verifiably authentic responses, and neither could any other DNS servers. That means that without the SMK, no DNS clients (even your web browser) that have implemented DNSSEC could verify the responses. You'd type in my blog address and you'd get an error message instead of my blog. The internet would be broken!
Well, not quite. It's simple enough to turn off the DNS security on DNS clients. It's a bit more work for intermediate DNS servers (like the one your Internet service provider runs), but not really very much more work. In addition, even if DNSSEC was completely broken, there are plenty of DNS servers that don't participate in DNSSEC at all (such as Google's DNS servers, for example), and these would keep right on working. Nevertheless, if the SMK were lost, the result would be (temporary) service interruption for millions of systems. Plus it would be a really big pain in the patoot.
How could the SMK be lost? There are lots of scenarios, all of them involving disasters that wiped out all of the root DNS servers at the same time. Pick your poison: earthquake, meteorite strike, giant tornadoes, terrorists, nuclear war, coordinated copper-eating ants. None of these are very likely to wipe all the root DNS servers out, but theoretically it
could happen.
So there's an SMK backup and a recovery procedure, part of the
overall DNSSEC security procedures. The security requirements make backup tricky. You don't want to have a complete copy of the SMK available to any one person, because that one person could then do something bad, like sell the SMK to al Qaeda or the Russian Mafia. The backup needs to be really secure. So the approach they took (see diagram at right, and
associated presentation for details) was to split up the SMK into 7 pieces, any 5 of which could be used to recreate the whole thing. These 7 pieces have been deposited into 7 safe deposit boxes. The 7 keys to the safe deposit boxes have been entrusted to 7 individual people (hopefully trustworthy folks!).
In the event of a successful coordinated copper-eating ant attack that wiped out all the root DNS servers, these seven people would be called. They'd first travel to their safe deposit box, use the key they've been entrusted with to open it, and grab their piece of the SMK. Then they'd travel to a secure location. When at least five of these folks had arrived at that secure location, technicians could piece together the SMK from the fragments each carried – and the root DNS servers would once again be able to authenticate their responses, your web browser would be happy, sunshine would break through the clouds, and there would be no more hunger. I made up the last bit...
Also this:
