Additional Considerations When Selecting an HSM and Designing a Secure Environment

What design objectives are met by a Hardware Security Module?

The selection decision for an HSM is about more than specifications and security issues – it’s about operation efficiency, scalability, performance, economics, business relations ships and support; the right HSM reduces lifecycle costs and security risks to increase customer value.

The overall functional security objectives (FSO) for a FIPS 140-1 Validation comprise the following:

Protect a cryptographic module from unauthorized operation or use.
Prevent the unauthorized disclosure of the non-public contents of the cryptographic module, including plain text cryptographic keys and other critical security parameters.
Prevent the unauthorized and undetected modification of the cryptographic module, including the unauthorized modification, substitution, insertion, and deletion of cryptographic keys and other critical security parameters.
Employ FIPS approved security methods for the protection of unclassified information.
Provide indications of the operational state of the cryptographic module.
Ensure the proper operation of the cryptographic module.
Detect errors in the operation of the cryptographic module and to prevent the compromise of sensitive data and critical security parameters as a result of those errors (this is referred to as “fail-safe”. That is, if the device fails, it will fail in such a way as not to compromise its secrets).

The factors to consider when developing best practices for use with hardware-based key management devices are the following:

Key Generation: are all private signing keys generated on a key management device?
Key Storage: are all private signing keys stored on a key management device 100% of the time?
Key Backup: are all private signing keys backed up from a FIPS 140-1 level 3 key management device to another identical device?
Certificate Signing: are all certificates signed on the key management device 100% of the time?
Trusted Path: are all critical security parameters managed through a separate path and never through a host?
FIPS 140-1 Validation: Is the key management device officially validated to a minimum of FIPS 140-1 level 3?
Does the device provide high availability?

OR

The root key should be generated in a FIPS 140-1 Level 3 or higher security module;
The root key should never exist in plain text outside the cryptographic boundary of a FIPS 140-1 Level 3 or higher module;
Movement or backup of the CA root key should not expose the root key;
Access to the root key security module should require strong authentication and m/n access control splits where m>2, n>4 (e.g. 3/5)
Physical attack to the security module should disable the cryptographic functions and destroy the keying data.
Providing the above functionality at the required level of security for CA operations requires that these functions all be performed in hardware meeting FIPS stringent requirements.

If the hardware security product chosen does not meet these criteria, then the encryption keys are still vulnerable to internal and external attacks, system crashes, and viruses. Moreover, by using hardware key protection from the beginning of deployment, an organization can achieve the highest security at the outset.

Such protection can be provided by placing all cryptographic key management and encryption/decryption functions into a hardware device rather than residing in software on a host computer. By using a trusted hardware cryptographic module in conjunction with tamper-proof tokens, the sensitive cryptographic processing, key generation, verification, storage, and deletion functions can be offloaded from the CA server. This offloading not only protects the critical keying data, it also provides the benefit of backing up the keying material for disaster recovery.