July 2010 Archives

Stomp Rocket

23359.jpg

23355.jpg

23362_600.jpg

Visit to Toledo

Highlights of our trip to trip to Toledo:

  • Shopping at The Anderson's (where daddy bought a melon-baller)
  • Pool party at TK's awesome house!
  • Meeting the "Original Stewie"
  • Skipping rocks at side-cut park
  • Seeing the building where Grandpa Dan worked
  • Playing the squeaky mouse with shy Lily
  • 3-D sidewalk chalk -- NCIS style!
  • Washing Grandma's 2nd story windows, yikes
  • A slow Italian dinner with everyone
  • Ice cream every night
  • Silly bands!
  • Lounging in the red carpet club
23028_600.jpg23072_900x600.jpg 23059_450x675.jpg23163_450x675.jpg 23100_600.jpg23121_900x600.jpg 23143_600.jpg23156_600.jpg 23148_900x600.jpg23158_600.jpg 23233_600.jpg23243_600.jpg 23255_600.jpg23283_600.jpg 23171_600.jpg

Signing the DNS Root

I've never been very good at explaining my job to family and friends. I'm going to try to make up for that a little by talking about some things I've been involved in at work that I find particular exciting.

In less than two days the root zone of the Internet's Domain Name System (DNS) will be officially signed, for the first time. Signing the zone means adding an extra layer of security, so that we can be sure received DNS messages are authentic.

DNS is an Internet protocol that, among other things, is used to map domain names to IP addresses. It was invented 27 years ago without any real security features. Some 10 years ago, people began work to develop security extensions to the protocol, which we call DNSSEC.

The DNS is a hierarchical system, which is to say, tree-like. We usually visualize it as an inverted tree, with the "root" of the tree at the top. The root of the DNS is important because it is the starting point for any lookup. In DNSSEC the root is especially important because it is the starting point for validation. Think of the root zone as the only point that everyone automatically trusts.

My employer, VeriSign, plays two important roles with the DNS root zone. First, VeriSign operates two of the 13 root servers (named by the letters A and J). Second, VeriSign is the Root Zone Maintainer. In the context of DNSSEC, this means that its our job to actually sign and publish the zone.

In DNSSEC, signing is accomplished using keys. These keys have two parts: a public part and a private part. A signature is created using the private (secret) part and can be later verified using the public part.

There are two types of keys: KSKs and ZSKs. Both are needed to sign a zone and normally a single organization would be responsible for both. However, the root zone's importance necessitates a separation-of-powers. VeriSign is responsible for only the ZSKs while the Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for the KSKs.

The public part of the KSK from ICANN forms what we call the Trust Anchor for the DNS. It is the root of the security hierarchy. If you have the trust anchor (the public part) you can validate or verify any signature in the DNS hierarchy.

As you may imagine, the keys to the root zone are Serious Business. Keys equate to trust. If an attacker of some kind manages to get a copy of a private key, the attacker immediately becomes trusted. In other words, the attacker can create new signatures that everyone will automatically trust. Therefore, keys are stored in fancy (and expensive) devices designed to protect them called a Hardware Security Module (HSM). If the device thinks it is being attacked, it erases the keys inside.

ksk0002.jpg

On Monday I was privileged enough to participate in a key signing ceremony for the root zone. ICANN has built a pair of ceremony rooms -- one on each coast -- where private keys are stored and where signatures are generated. Specifically, the purpose of the ceremony and these rooms is to generate signatures of VeriSign's ZSKs using ICANN's KSK. In other words, VeriSign's keys are signed using ICANN's key. Approximately every three months a number of ICANN staff and Trusted Community Representatives will meet in one of the rooms and hold a key signing ceremony.

Trusted community representatives are people from around the world involved in the DNS. ICANN has designed a system whereby some number of representatives must be present in the room in order to read the keys from the security devices and generate the signatures.

The ceremony I witnessed on Monday was the second such ceremony to take place. At the first ceremony they initialized the devices in the east coast room, generated the first KSK, and signed the first set of ZSKs. At the second ceremony they initialized the west coast room and signed the second set of ZSKs. I found the whole thing really fascinating.

The ceremony took 6+ hours with a short break about halfway through. About 20 people in all were involved. There is a ceremony script with approximately two hundred distinct steps. And the entire thing was recorded on video. The reason for the elaborate ceremony is to demonstrate that keys and signatures are generated in complete transparency. There is extensive logging, auditing, witnessing, and recording of the entire thing. The level of attention to detail and paranoia is quite amazing.

Seven of the trusted community representatives are designated as Crypto Officers. They are assigned "smartcards" that are used to operate the HSM. Some number of crypto officers (three I think) must insert their cards in order to activate the HSM for signing. The crypto officers are not allowed to take their smartcards home with them, however. Instead, they leave the cards in a locked safe, which has bank-style safe deposit boxes inside. They take the deposit box key (an actual, physical key!) home with them.

ksk0003.jpg

Everything that goes into a safe is placed inside a plastic tamper-evident bag. The bags have serial numbers on them. Throughout the ceremony everyone was writing down the bag serial numbers on their copy of the script. At the next ceremony, these bags are removed, checked for evidence of tampering and matching serial numbers.

Signing of keys is done on a laptop running Linux. The laptop has no hard drive. Instead it boots from a read-only CDROM which contains all the necessary programs. As further evidence of the level of paranoia, a SHA256 hash of the CDROM was taken during the ceremony. This hash is a string of 64 hexadecimal characters (which we all wrote down) that represents a fingerprint of the contents of the CDROM. It will be verified in future ceremonies to prove that ICANN hasn't done something sneaky, like replace it with a different CDROM.

4791651390_44e37b350e.jpg

My role at this ceremony was to authenticate the ZSKs right before they were signed by ICANN. The ZSKs, generated at VeriSign, are sent to ICANN days before the ceremony. They put the ZSKs onto a flash memory disk, which gets inserted into the laptop. I brought with me a sheet of paper that has a hash (fingerprint) of the ZSK data.  Just before signing they asked me to turn my back to the screen and read (from my sheet) the sequence of words that represents the hash value.  Since my spoken words match the words on the screen, it is proof that the ZSKs are authentic and came from VeriSign. Then the keys are signed!

Here's Mehmet, the ceremony administrator, handing me a copy of the signed keys:

DW-gets-SKR.png

This was about halfway through the ceremony (step 108 of 199). The remainder was mostly putting things into bags, writing down their numbers, and locking them in the safes.

The real excitement happens on Thursday when we "unblind" the keys in the root zone and allow the actual KSK to be published so that DNSSEC validation can finally take place!

Family Kopczynski

KOP_0543.jpg

About this Archive

This page is an archive of entries from July 2010 listed from newest to oldest.

June 2010 is the previous archive.

August 2010 is the next archive.

Find recent content on the main index or look in the archives to find all content.

Categories

Pages

  • 2009-photos
  • 2010-photos
Powered by Movable Type 4.32-en