Cryptographic sanity: How many keys?

Written by Rick van Rein in category: Crypto, Resilience, Security

WikiMedia Commons

In our architecture, we opt for Hardware Security Modules (or HSMs) as secure key stores. This helps us with high-availability of key material, and thus of our signed domains, but it also poses us with some limitations. An HSM generally has a limited number of keys that it can store. Had we opted for a smart card, then this would have been an even worse problem.

The number of keys supported in an HSM ranges from hundreds to thousands, depending on the license accompanying the device. While this may suffice for many small-scale needs, it is not automatically sufficient for a registrar like SURFnet. Smart cards, which only store a few keys up to ten or so are easily outgrown by anyone. It would be especially troublesome if the popularity of DNSSEC could outgrow the capacity of the secure key store chosen.

An extreme option could be to use a single key for all domains. A few generations are likely to co-exist during rollover procedures, but other than that all domains would gradually move from commonly shared key A to commonly shared key B, and then all would roll to the same key C, and so on. This requires so few keys that a smart card may have sufficient resources to work that way. But this approach may cause extra concerns if private keys have to be shared during zone transfers; also, it might simplify the possibility of one domain owner falsifying the contents of another party’s zones. As a general rule it is better to avoid any need to depend on proper behaviour among clients. Finally, separating clients may improve the possibilities for legal agreements about key ownership and responsibilities.

The other extreme would be to assign an individual key for each zone. This is the approach that can easily outgrow the potential of an HSM, let alone a smart card, because domains are cheap and popular.

The middle ground on which we settled is to represent all zones of one connected institution of SURFnet with a single key. So all domains of the same university are signed with the same key, but zones from different universities are signed with different keys.

Looking at our choice of OpenDNSSEC, this choice translates to a requirement of a so-called OpenDNSSEC signing policy per customer, and the setting to share keys within each such policy. Moreover, it is advisable to save space by not storing public keys in the HSM, which will be an option in OpenDNSSEC 1.2 and beyond. This is useful for a number of reasons:

  • The HSM limits the number of objects, not keys. Removing public keys doubles capacity.
  • Private key objects are usually embellished with public key data.
  • Public key data is public, and present in DNS, KASP database, and who knows where else.

If we were really tight in key storage space, we could consider not storing the short-lived ZSK in the HSM, but since at least the private part of the ZSK is still a true security object, we consider that too drastic to be an attractive option. Sharing keys and dropping public keys have no security implications, and are therefore much better suited optimisations of HSM storage.

1 Comment to “Cryptographic sanity: How many keys?”

  1. Ignorant says:

    I believe this article falls ever so close to a problem I am having. Information on the subject would be greatly appreciated.

Respond

*