Skip to main content

ICANN Announces 2015 Hardware Security Module Replacement Project for the Root Key Signing Key

The Internet Corporation for Assigned Names and Numbers (ICANN) today announced the 2015 Hardware Security Module Replacement Project for the Root Key Signing Key.  An overview of the project and related information is below.

Overview

As part of securely maintaining the Root Zone Key Signing Key (KSK), ICANN utilizes specialized devices known as Hardware Security Modules (HSMs). These HSMs store the private key material for the Root Zone KSK, and are powered by batteries that have a limited lifespan. While the batteries are currently in good condition and have an expected shelf life of 10 years, the manufacturer warrants the first five years of operation.  Out of an abundance of caution, ICANN is planning to replace the existing units during 2015 after five years of service.

Background

The Domain Name System Security Extensions (DNSSEC) provides a way for software to validate that Domain Name System (DNS) data has not been modified during Internet transit. This is done by incorporating public key cryptography into the DNS hierarchy to form a chain of trust originating at the root zone.

In accordance with its role as IANA Functions Operator, ICANN is the Root Zone Key Signing Key Operator performing the function of securely generating and storing the Root Zone KSK. ICANN uses HSMs to store the KSK. HSMs are secure crypto-processors that manage cryptographic keys and perform cryptographic operations while providing physical protection of the private keying material through tamper evident mechanisms. ICANN has two duplicate HSMs for each secure ICANN Key Management Facility (KMF) — one facility on the U.S. East Coast and another facility on the U.S. West Coast. In the event that one HSM or KMF should fail, the other redundant devices and locations would be available for use. Beyond these options there are further recovery procedure details that are documented in the KSK Disaster Recovery and Business Continuity Plan.

Unlike many other electronic devices, the battery for an HSM is typically built into the unit and cannot be replaced individually. The batteries in these HSMs have a life expectancy of 10 years from the manufacture date, with the manufacturer warranty covering five years of support from the date of first use.

Replacement Process

The HSMs currently in production were first used in 2010. With the warranty period ending, and as a conservative approach to the battery’s expected lifetime, ICANN intends to bring into service new HSMs during calendar year 2015. The contents of the existing HSMs will be imported into the new HSMs, which can perform the same functions as the existing set. This process will be performed during quarterly events at the KMFs known as key signing ceremonies. Scripts will be written to include the commissioning of new HSMs during regularly scheduled key signing ceremonies in 2015.

ICANN plans to augment the existing four HSMs with an additional four HSMs such that the new HSMs are placed into parallel production with the 2010 HSMs for a transitional period to guarantee the security and availability of KSK operations.

Once the relevant parties are confident that the new HSMs are functioning correctly and the continuity of KSK operations will not be compromised, a secure method of decommissioning and destroying the existing modules will be designed to adhere to the most current industry specifications.

Key Risks

The following list represents the key identified risks and their mitigations:

Risk: All four production HSMs fail to perform cryptographic operations due to a battery failure thus impacting the continuity of operations.

Mitigation: There are currently four duplicate HSMs, plus additional backups that can be activated by the disaster recovery process. The failure rate of a battery in a single HSM is easily mitigated by the redundancy resulting from the three other HSMs. The expected shelf life of the battery is around 10 years, and each unit reported their battery condition as good. That said given the similar production dates, it is possible that the batteries in all HSMs could fail around the same time. To maintain the continuity of operation and mitigate the risk of all HSMs ceasing to function, we consider it prudent to perform the HSM replacement in 2015 and use HSMs with differing battery lot and production dates.

Risk: The new production HSMs do not function correctly when powered up for the first time.

Mitigation: As part of installing the new HSMs, acceptance testing will be performed to verify the function of the units prior to the ceremonies in which they are put into production. For a period after the new HSMs are placed into service, the existing HSMs will continue to be stored in the secure facilities allowing for more options for remediation in the case of new HSM failure.

Risk: All new production HSMs share a common defect.

Mitigation: It is possible that if all four HSMs are from the same production batch, they may have common flaws (such as bad battery composition) that would compromise the redundancy in place. To mitigate this risk, ICANN worked with the vendor to ensure the HSM units are comprised of models with different manufacture dates and contain batteries that were built in different production runs.

Questions and Answers

Q1: Why do the HSMs need to be replaced, and not just the batteries?

A1: While the HSMs can be reconditioned with new batteries, they must be returned to the vendor to perform that procedure. ICANN will replace the HSMs, rather than recondition the units, to ensure the cryptographic key material does not leave the secure Key Management Facilities.

Q2: How does this project involve a future rollover of the Root KSK?

A2: This project is distinct from the project to replace the existing Root KSK with a new Root KSK (known as a “rollover”). HSM issues relating to the rollover will be considered by the Root KSK Rollover Design Team.

Separation of the HSM replacement project from a Root KSK rollover is considered beneficial to allow time for the Rollover Design Team to fully develop their approach without being influenced by operational pressures relating to HSM replacement.

Q3: What consideration was made in selecting the replacement HSMs?

A3: ICANN procured the most recent HSM model, the AEP Keyper Plus, from the vendor used to provide the HSMs that are currently in production. This model meets FIPS 140-2 Level 4 security certification, which is a requirement for the Root KSK in the IANA Functions contract. This model also allows for the importing of the Root KSK from the older models without needing to regenerate the Root KSK. The newer HSM model was selected rather than the current HSM model in ICANN’s production model as the expected lifetime of support from the vendor is greater.

Q4: How many trusted community representatives are needed to replace the HSMs?

Q4: ICANN has determined that three trusted community representatives is the minimum number needed to export the root KSK from the existing production devices, and import them into the new devices. This process does not require generation of a new set of “SO” and “OP” cards, and therefore does not require the entire set of Cryptographic Officers to be present. The existing Recovery Key Share Holders’ credentials will continue to work with the new HSMs.

About ICANN

ICANN's mission is to ensure a stable, secure and unified global Internet. To reach another person on the Internet you have to type an address into your computer — a name or a number. That address has to be unique so computers know where to find each other. ICANN coordinates these unique identifiers across the world. Without that coordination we wouldn't have one global Internet. ICANN was formed in 1998. It is a not-for-profit public-benefit corporation with participants from all over the world dedicated to keeping the Internet secure, stable and interoperable. It promotes competition and develops policy on the Internet's unique identifiers. ICANN doesn't control content on the Internet. It cannot stop spam and it doesn't deal with access to the Internet. But through its coordination role of the Internet's naming system, it does have an important impact on the expansion and evolution of the Internet. For more information please visit: www.icann.org.


More Announcements
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."