Skip to main content

DNSSEC Root Key Operations and the Infineon Smartcard Bug

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.


Footnotes:

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.


-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAqAAgqVVmukLohruATNqE5H71bb167GEmFVUs7JBtIRbQ7yBwKMUV
VBRN/q/nx8uPAF3RgjQTOsBxCoEYLOH9FK0ig7yDQ1+d8vYxMlGTGhdt8NpR5U9C
5gSGDfs1lYAlD1WcxUPE/9Ucvj3oz9BnGSN/n8R+5ynaBoNfpFLoJemhjrwuy89W
NHRlLDPPVqkDO8312XMSF5fsgIkEG24DobctCnNbmE4DaHMJMyMk8nwtuoXp2xXo
OgFDOC6XSwYhwY5iXs7JB1d9nnut6VJBqB676KkB1NMnbkCxFMCi5vw40ZwuaqsC
ZEsoE/V1/CFgHg3uSc2e6WpDED5STWKHPQIDAQAB
-----END RSA PUBLIC KEY-----
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEArP+0CbzJOfgx96Hl7Ij3pZJV7FMEC+QyAnOQpM6JbW+QhvPF4Xf7
/hGBY6rsevFGLEeUWUTE4sAmvl6Yu83tJZeCcuHj4HnFCU1XPw6DyS8Csy01E7FV
C4JpKcgN0PksrJZtF3af1YZ7ZHw/OAKavcSBUuuPIHFZ7MXSMsfBU3x59LesKP8R
aC8haBv21qulVQMr9vnwNr6yqqWzd41u6/umv56hkb5KsMrqdZ4vdzofkCnHPsuN
VzW5Mh2whfG44tgDj+KUGZJUjO4NZ91FR+Ed1jr5yfwcVGb7aEzwCdcZfCz3nnkq
tQHmqKHKUZryy5tfY2fpTA1HUCRRNXvhtQIDAQAB
-----END RSA PUBLIC KEY-----

Comments

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