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)
ICANN will hold its next public meeting in Copenhagen on 11-16 March 2017. More information here.
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, ICANNcould 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.
Picture credit: TiBine
With the rollover of the Root Zone Key Signing Key (KSK) ICANN is marking another important step to improve the security of the Domain Name System, i.e. Internet’s address book. Here’s the details.
ICANN today posted plans to update or “roll” the Root Zone Key Signing Key (KSK), marking another significant step in our ongoing efforts aimed at improving the security of the Domain Name System (DNS).
The KSK rollover plans were developed by the Root Zone Management Partners: ICANN in its role as the IANA Functions Operator, Verisign acting as the Root Zone Maintainer, and the U.S. Department of Commerce’s National Telecommunications and Information Administration (NTIA) as the Root Zone Administrator. The plans incorporate the March 2016 recommendations of the Root Zone KSK Rollover Design Team, after it sought and considered public comment on a proposed rollover process.
What is the KSK?
The KSK is a cryptographic public-private key pair that plays an important role in the Domain Name System Security Extensions (DNSSEC) protocol.
The public portion of the key pair serves as the trusted starting point for DNSSEC validation, similar to how the root zone serves as the starting point for DNS resolution.
The private portion of the KSK is used during the Root KSK Ceremonies to sign the Zone Signing Keys used by Verisign to DNSSEC-sign the root zone.
Why Roll the KSK?
Good security hygiene recommends passwords be changed periodically to reduce the risk that those passwords can be compromised via brute force attacks.
As with passwords, the community has informed us that the cryptographic keys used to sign the root zone should be periodically changed to help maintain the integrity of the infrastructure that depends on those keys and ensure that security best practices are followed.
The KSK Rollover Process
Rolling the KSK involves creating a new cryptographic key pair that will be used in the DNSSEC validation process to verify that responses to queries for names in the root zone (typically TLDs) have not been altered in transit.
Transitioning to that new key pair and retiring the current key pair is also part of the rollover process. Internet service providers, enterprise network operators, and others who have enabled DNSSEC validation must update their systems with the new public part of the KSK, known as the root’s “trust anchor.”
Failure to do so will mean DNSSEC-enabled validators won’t be able to verify that DNS responses have not been tampered with, meaning those DNSSEC-validating resolvers will return an error response to all queries.
Because this is the first time the root’s KSK key pair will be changed since it was generated in 2010, a coordinated effort is required across many in the Internet community to successfully ensure all relevant parties have the new public portion of the KSK and are aware of the key roll event.
ICANN will be discussing the KSK rollover at various technical fora and using the hashtag #KeyRoll to aggregate content, provide updates, and address inquiries on social media. We have also created a special online resource page to keep people up to date with key roll activities.
If the KSK rollover is smoothly completed, there will be no visible change for the end user. But as with pretty much any change on the Internet, there is a small chance that some software or systems will not be able to gracefully handle the changes.
If complications become widespread, the Root Zone Management Partners may decide that the key roll needs to be reversed so the system can be brought back to a stable state. We have developed detailed plans that will enable us to back out of the key roll in such a circumstance.
The KSK rollover will take place in eight phases, which are expected to take about two years. The first phase is scheduled to begin in Q4 of 2016.
Developers of software supporting DNSSEC validation should ensure their product supports RFC 5011. If their products do, then the KSK will be updated automatically at the appropriate time.
For software that does not conform to RFC 5011, or for software which is not configured to use it, the new trust anchor file can be manually updated.
This file will be available here and should be retrieved before the resolver starts up and after the KSK is changed in the DNSKEY Resource Record Set (RRset) of the DNS root zone.
ICANN has developed operational tests that software developers and operators of validating resolvers can access to evaluate whether their systems are prepared for the KSK rollover. You can learn more about these tests here.
As the KSK rollover draws nearer, all interested parties can learn more and get updates at https://www.icann.org/kskroll. Please share this resource with others and encourage them to learn about these upcoming changes to the DNS.
This post was originally published on ICANN website