[Cryptech Tech] Fwd: [Dnssec-deployment] Fwd: Replacement of Root KSK Hardware Security Modules

[Warren Kumari]

Badderies......

W

---------- Forwarded message ----------
From: *Kim Davies* <kim.davies at icann.org>
Date: Monday, March 23, 2015
Subject: [Dnssec-deployment] Fwd: Replacement of Root KSK Hardware Security
Modules
To: "<dnssec-deployment at dnssec-deployment.org>" <
dnssec-deployment at dnssec-deployment.org>, "dns-operations at dns-oarc.net" <
dns-operations at dns-oarc.net>, "ksk-rollover at icann.org" <
ksk-rollover at icann.org>


 Apologies for duplicates. I am forwarding on this announcement we posted
to our Root DNSSEC announcement list.

 kim

 *Subject: **Replacement of Root KSK Hardware Security Modules*

  ICANN today posted a summary of its planned HSM Replacement Project for
the Root KSK online at
https://www.icann.org/news/announcement-3-2015-03-23-en

 Here is the text:

 *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.

 With kindest regards,

  Kim Davies
Director, Technical Services
ICANN





-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cryptech.is/archives/tech/attachments/20150323/66f2e26d/attachment.html>