DNSSEC Root Key Operations and the Infineon Smartcard Bug

24 October 2017

Andres PavezAndres Pavez, Cryptographic Key ManagerRichard Lamb

Thanks to the ever-vigilant eyes of one of our Trusted Community Representatives (TCRs), Olaf Kolkman, the recently discovered Infineon smartcard vulnerability1 was brought to the attention of the root key-signing key (KSK) operations team at ICANN.

This bug, known as the "Return of Coppersmith Attack," or ROCA, has to do with a particular chip vendor's approach to generating keys. Fortunately, although smartcards are used in the management of the DNSEC root key,2 in ICANN's use, keys are not generated using the chips in any of these cards.3 Both the original 2010 root KSK and the new KSK that we are about to roll over to4 were generated inside the U.S. Federal Information Processing Standards (FIPS)-certified Hardware Security Module (HSM),5 with no components from this particular vendor (Infineon). We have contacted our HSM vendor (AEP) and this is the information that they provided to us:

Full details of the ROCA vulnerability will be announced in early November. Currently it is believed to affect ‎Infineon based products only. Ultra AEP's KeyperPlus does not contain any Infineon hardware including TPMs, nor does it use any Infineon software libraries.

The information released so far indicates the issue is within the "Fast Prime" method used by Infineon to generate RSA key pairs. The KeyperPlus does not use Fast Prime but instead generates RSA primes as specified in ANSI X9.31 from random data taken from the NIST SP800-90A SHA-512 HashDRBG seeded by a hardware entropy source.

We believe that we are not affected by the ROCA vulnerability but will, of course, review the situation once all the details are known.

Mr. Kolkman also pointed out a fine online tool developed by researchers at Masaryk University in Brno, Czech Republic, to test for the ROCA vulnerability.6 For further assurance, we ran both keys through this test and they came up safe.7

For these reasons, we believe that the DNSSEC KSKs are not subject to this vulnerability. However, no system is perfect, and this is an excellent example of the value and trust our open, direct community participatory management approach brings to our root KSK operations. Thanks go to Olaf Kolkman, the researchers at Masaryk University, and all the other community members who continue to help us build the trust in root KSK operations that few others can match.


1 https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/?comments=1&post=34183243

2 http://dc.org/files/DefCon25_pd.pdf

3 The various cards used in ICANN's management of the root zones DNSSEC-related keys are used for access control and backup. The private portion of the KSK is protected inside the HSM and is backed up onto cards encrypted with a key split amongst 7 other smartcards held by TCRs offsite for use in emergency recovery.

4 https://www.nanog.org/sites/default/files/2_Punky_Duero_Root_Zone_DNSSEC_KSK_Rollover.pdf

5 https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2793.pdf

6 https://keychest.net/roca

7 The ROCA test site above calls for a specific format ("PEM") of the DNSSEC public keys which is provided here for convenience for current and new root KSK.


Andres Pavez
Andres Pavez
Cryptographic Key Manager

Andres Pavez

Read biographyRead biography

Richard Lamb