Key Management

Refer to the Security Worlds chapter in the User Guide for a description of the Security World infrastructure available for managing the secure life-cycle of cryptographic keys. See Security World Access Control Architecture for a description of the different keys available to protect application keys.

Security strength is represented by a number associated with the amount of work (that is, the number of guesses/operations) that is required to break a cryptographic algorithm or system. The security strength is specified in bits and is a specific value from the set {80, 96, 112, 128, 192, 256} e.g. a security strength of 112 bits would require on average 2^(112-1) operations to brute force the algorithm or system.

Security World modes are selected when creating a Security World. The available modes, associated cipher suites, automatic FIPS mechanism compliance and security strengths are:

Security Worlds created with a pre v12.50 release can be loaded. The cipher suites, automatic FIPS mechanism compliance and security strengths for these Worlds are:

Pre v12.50 Security Worlds ciphersuites, FIPS mechanism conformance and security strengths:

The tables above identify the ciphersuites, automatic compliance with NIST SP800-131A Revision 1 and security strength. The National Institute for Standards and Technology (NIST) have published, over the years, good key management guidance. NIST SP800-131A Revision 1 – Transitioning the Use of Cryptographic Algorithms and Key Lengths is referenced in the table as it provides guidance on suitable cryptographic algorithms and key sizes for protecting sensitive data today. This document, published in November 2015, advises that the minimum security strength for algorithms or keys is now 112 bits. Whilst the immediate audience is U.S. government agencies, NIST standards provide a global benchmark in security standards which many global product vendors adhere to, in order to provide their customers with appropriate levels of security assurance. Therefore, the industry standard minimum security strength is considered to be 112 bits today.

Depending on the application library used, a range of cryptographic algorithms are available for selection. The algorithm used and key size selected (if applicable) should be sufficient to protect customer data from threats identified in the deployed environment for their data. In line with standard security best practice, the security strength, as described in Security World security strengths, of the Security World ciphersuite will effectively limit the security strength that can be claimed for any key or algorithm used by the HSM. As advised in Security World security strengths a minimum security strength of 112 bits is considered the industry standard.

The Cryptographic Algorithms appendix in the User Guide for your HSM identifies all algorithms and key sizes available (both NIST approved and non approved). NIST SP 800-57 Part 1 Revision 4 has a section on Comparable Algorithm Strengths which provides guidance on identifying the security strength of different NIST approved algorithms and key sizes. BlueKrypt Cryptographic Key Length Recommendation could be a useful reference for determining required key sizes for common cryptographic functions:

The General Key Management Guidance section of NIST SP 800-57 Part 1 Revision 4 provides guidance on the risk factors that should be considered when assessing cryptoperiods and the selection of algorithms and keysize.

The nfkmverify command-line utility can be used to identify algorithms and key sizes (in bits). See the Cryptographic Algorithms appendix in the User Guide for your HSM for more information.

A cryptoperiod is the time span during which a specific cryptographic key is authorized for use.

NIST SP 800-57 Part 1 Revision 4 has sections describing the rationale for cryptoperiods and the risk factors that should be considered when determining cryptoperiods. Setting a cryptoperiod limits, amongst other things, the amount of data exposure if a key is compromised. You are advised to perform a threat analysis, considering the sensitivity of your data and what controls you have in place to mitigate compromise, to determine appropriate cryptoperiods for keys protecting that data.

In terms of the key management schema the following cryptoperiod rules must be applied:

The nShield HSM includes a certified random number generator that uses a hardware based source of entropy. This provides greater security than a random number generator that uses a non-hardware based source of entropy that is typically provided by general purpose computers. Therefore, always use the nShield HSM to generate random numbers and keys.

The sensitive Security World data e.g. application key blobs, stored on the host or RFS is encrypted using the Security World key. You must regularly back up all the data stored in the Key Management Data directory with your normal backup procedures. It would not matter if an attacker obtained this data because all sensitive data is protected by the Security World key, stored in your HSM, and the Administrator cards for that Security World.

In terms of cryptoperiods (see above) keys that have reached the end of the cryptoperiod and therefore no longer exist on the nShield HSM may still exist on backups. If feasible then the backup data should also be deleted. However, if the backups have to be maintained for operational, resilience, or audit reasons, then ensure that the relevant procedural controls are implemented to mitigate attacks on retired keys.

We recommend generating a new key instead of importing an existing key whenever possible. The import operation does not delete any copies of the imported key material from the host, and as traces of this key material may still exist on disks or in backups, there is a risk that the key material may become compromised after it has been imported. It is your responsibility to ensure any unprotected key material is deleted. If a key was compromised before importation, then importing it does not make it secure again.

Key separation (i.e. each key only has a single purpose) is an important security principle which is re-enforced in nShield by having different key types for different purposes (e.g. ECDHPrivate/ECDHPublic for Elliptic Curve (EC) Key-Establishment keys and ECDSAPrivate/ECDSAPublic for EC signing/verification keys).

There is a use case where a static EC private Key-Establishment key will also be used to sign a CSR to request an (initial) certificate for the associated static EC public Key-Establishment key. For this particular use case, the keyType ECPrivate/ECPublic should be used for the EC Key-Establishment key, with a specialized ACL allowing the ECPrivate key to be used for a single signing (OpPermissions:Sign), and then key-establishment (OpPermissions:Decrypt).