Child pages
  • HSM Buyers' Guide

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

The purpose of this document is to provide a set of guidelines for purchasing a Hardware Security Module (HSM) for use with OpenDNSSEC.

Types of HSMs

Hardware Security Modules come in a variety of shapes, forms and sizes:

...

For the purpose of this document, HSMs are divided into four categories:

1. Software tokens

Characteristics of this category are:

...

SoftHSM is an example of a software token. It is provided by OpenDNSSEC.

2. Low-cost small form-factor (smart cards and USB tokens)

Characteristics of this category are:

  • Low price (sub €100/unit)
  • Portable
  • Limited storage capability for key material (less than 20 RSA key-pairs)
  • Limited or no support for symmetric cryptographic algorithms
  • Limited speed for cryptographic operations

3. Medium- to high-cost cryptographic accelerators (PCI cards/separate units)

Characteristics of this category are:

  • Medium to high price (€2500 – €30000 per unit)
  • Fixed location
  • Emphasis is on acceleration of cryptographic operations not on key storage (typical product names: "SSL accelerator" or "Crypto accelerator", etc.)
  • High speed cryptographic operations both symmetric as well as asymmetric

4. Medium- to high-cost traditional hardware security modules (PCI cards/separate units)

Characteristics of this category are:

...

Of these four types of HSMs, three types are suitable for use with OpenDNSSEC (types 1, 2, and 4). Type 3 HSMs (cryptographic accelerators) are less suited for use with OpenDNSSEC because they do not always provide the means to securely and efficiently store cryptographic key material.

Supported algorithms and key sizes

Most HSMs support both RSA as well as DSA key generation and signing. RSA is recommended for use with OpenDNSSEC. The RSA support should at least comply with the following guidelines:

...

  • The maximum key size is limited to 1024 bits
  • Validation of DSA signatures requires significantly more processing than validation of RSA signatures, thus imposing additional load on validating resolvers.

APIs for access

Most HSMs will support one or more of the following APIs for access to their cryptographic functionality:

...

To be interoperable with OpenDNSSEC a HSM must support the PKCS #11 API. The minimum supported version of the PKCS #11 API is version 2.11. A compliancy tool will be made available that tests whether the PKCS #11 module supplied with a HSM is compatible with OpenDNSSEC.

Speed of cryptographic operations

When comparing HSMs in order to decide which one to purchase it is useful to compare the speed of cryptographic operations. There are two important benchmarks to look for:

...

In general, separate unit HSMs and PCI cards will outperform smart cards and USB tokens by a large factor.

Security certifications

It is common for HSM manufacturers to have the security of their devices evaluated by a third party auditor. These audits are usually performed against internationally recognised standards for security evaluation. The two most important standards are:

Federal Information Processing Standard (FIPS) 140-2

This standard is maintained by the National Institute of Standards and Technology (NIST) which is a United States governmental body. The FIPS 140-2 standard recognises four levels to which a module can be evaluated (for a more detailed description see FIPS 140-2):

...

For use with OpenDNSSEC, a HSM that has at least a FIPS 140-2 level 2 certification is recommended. Note that operating a HSM in FIPS 140-2 level 3 or higher mode may impose restrictions on on-board key generation through the PKCS #11 API that may be incompatible with OpenDNSSEC.

Common Criteria Evaluation Assurance Levels (CC-EAL)

The Common Criteria are an internationally recognised set of standards for evaluating security hardware and software. It is a highly regulated process with the following characteristics:

...

Please note: a Common Criteria certification only has value if the Protection Profile is strict enough. Therefore, a Common Criteria certification can only really be trusted if the Protection Profile that was used for the evaluation is checked (this is very difficult for outsiders). Within the EU, the Protection Profile for Secure Signatured Creation Devices (SSCD) (European standard CWA 14169) is a valuable profile for evaluation.

Backup and synchronisation

The key material used by OpenDNSSEC and stored in a HSM is extremely valuable as it guarantees the continued signed presence of a domain in the Domain Name System. It is therefore important to check the backup mechanisms supported by your HSMs.

...

Wiki Markup
A good example of a backup strategy is a HSM which maintains a key database (on disk) that is secured using (a) \[set of\] master key(s). These can be stored on smart cards that can be distributed among multiple security officers. An N out of M model can then be used to restore the master key(s) in a new HSM if a backup needs to be restored where at least N out of M security officers need to present their card to restore the master key(s). The new HSM can then access the key database stored on disk which could have been backed up using readily available backup tools.

Matching HSM types to typical usage scenarios

This section provides guidelines for the features to look for in an HSM given a specific usage scenario in combination with OpenDNSSEC

Scenario 1: organisation with a few small to medium size static zones

For this scenario a USB token or smart card should suffice to store the Key Signing Keys; Zone Signing Keys could be stored in a soft token that is protected using a key on the USB token or smart card.

Scenario 2: organisation with one or a few large static zones

For this scenario a USB token or smart card should suffice to store the Key Signing Keys; Zone Signing Keys could be stored in a soft token that is protected using a key on the USB token or smart card.

Scenario 3: organisation with many small to medium size static zones

For this scenario a simple HSM should suffice. Both Key Signing Keys as well as Zone Signing Keys could be stored in the HSM. It is important to pay attention to the number of keys the HSM can store. This should be a large multiple of the number of zones.

Scenario 4: organisation with many large static zones

It is recommended to use a HSM in this scenario. Both Key Signing Keys as well as Zone Signing Keys could be stored in the HSM. It is important to pay attention to the number of keys the HSM can store. This should be a large multiple of the number of zones. In addition to this, key generation speed and signing speed are important parameters.

Scenario 5: organisation with (many) dynamic zones

It is recommended to use a HSM in this scenario. Both Key Signing Keys as well as Zone Signing Keys could be stored in the HSM. It is important to pay attention to the number of keys the HSM can store. This should be a large multiple of the number of zones. In addition to this, key generation speed and signing speed should both be very high.

Checklist

The checklist below can help determine whether or not a HSM is suitable for use with OpenDNSSEC:

...