Skip to main content

The Problem with "The Seven Keys"

From time to time, articles are published about "the seven people who control the keys to the Internet.” These articles, while probably well-intentioned, are completely incorrect. Let’s be absolutely clear: there are no keys that cause the Internet to function (or not to function).

The so-called "keys to the Internet” only relate to one function, and even then, they can only be used in extremely narrow circumstances. It is important to understand what these keys do, to see why they do not control the Internet.

First and foremost, the keys being talked about belong to just one single part of the Internet – the mechanism for authenticating the data in the domain name system (DNS), called DNSSEC. It is based on a hierarchy of cryptographic keys starting at the root of the DNS. The cryptographic keys for the root of the DNS are managed by ICANN.

These cryptographic keys are kept in two secure facilities over 4,000 kilometers apart, and are protected with multiple layers of physical security such as building guards, cameras, monitored cages and safes. The innermost layer of physical security is a specialized device called a hardware security module (HSM), which stores the actual cryptographic keys. An HSM resists physical tampering, for example, if someone attempts to open the device or even drops it, the HSM erases all the keys it stores to prevent compromise. ICANN keeps two HSMs at each facility.

The root zone cryptographic key cannot be used outside an HSM. The system that has been designed to operate an HSM requires many people to be present. Some of these people are technical community members from around the world, known as Trusted Community Representatives, and others are ICANN staff. Each person has a specific role in activating the HSM, which happens in a regular event we call a “key ceremony.”

But what if some event rendered the HSMs inoperable (e.g., a catastrophic bug in the firmware)? Even this extremely unlikely scenario needs a recovery plan, so ICANN keeps a backup for each root key, in a highly encrypted form, in a safe at each secure facility. If something happened to all four HSMs, ICANN could buy a new HSM from the same manufacturer and restore the root keys using the backup. In this scenario, our security policy requires additional Trusted Community Representatives be present to restore the backups that ICANN holds.

This is where many of the articles talking about "the keys to the Internet" get the story wrong. The Trusted Community Representatives are each given a physical key (some are metallic, others are smart cards) that is used during a key ceremony. The type of physical key depends on their specific role. Some Trusted Community Representatives are selected as “Cryptographic Officers” that activate HSMs during routine ceremonies. Others are selected as “Recovery Key Share Holders” that activate the backup in the disaster recovery scenario. In both instances, the physical key these representatives hold is only used to activate materials that are stored within the secure facility, and do not contain the root zone’s cryptographic keys. By themselves, and without having access to ICANN’s secure facilities, the keys cannot be used to access the protected root key. For that to happen, the representatives would all have to be inside the secure facility and the safe holding the backup smart cards would have to be open. Unless all the multiple layers of physical security fail, that scenario can only happen during a planned key ceremony.

The other problem with the story about the keys is that the Internet is much more than DNSSEC. The Internet consists of many different systems, and the DNS is just one of them. Controlling one aspect of the Internet, such as DNSSEC, does not lead to full control of other aspects.

So, the next time you read about “seven people who control the keys to the Internet," you’ll know that the Trusted Community Representatives perform a valuable service, but for a very limited operation.

Comments

    Ravi Kumar  21:26 UTC on 22 February 2017

    sdasd

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."