Verifying HSM Authenticity or Key Attestation

Hardware Security Modules have traditionally been deployed in the corporate data center’s most secure zone. Establishing trust with the HSM is, in part, achieved by physical access control. In cases of remote client usage (such as cloud cryptography), the client needs a way to verify the authenticity of the device protecting their most valued cryptographic keys.

Thales also provides a tool for validating the attestation of keys created by the HSM, to verify that they were created by a Luna HSM.

>Public Key Confirmations

>Verifying the HSM's Authenticity

>Verifying Key Attestation

Public Key Confirmations

Thales's Luna HSMs include factory-issued device identities certified by a Thales authority. The root of this authority is maintained by Thales in HSMs locked in a vault with layered physical and logical access controls. These certificates are used as the root of trust for the issuance of “public key confirmations” (PKCs), certificates issued by the HSM attesting to the life cycle of a specific private key. A Luna HSM will issue confirmations only for private keys that were created by a Luna cryptographic module and that can never exist outside the security perimeter of a Luna HSM. A valid confirmation is cryptographic proof that a specific key is inside the identified HSM. The confirmation is also proof that the identified HSM is real.

The key pair within the HSM that signs the confirmation is called a Hardware Origin Key (HOK). It is protected inside the cryptographic module’s FIPS 140-2 Level 3 security boundary. Each HOK is unique and there is no way to extract or replace it. The HOK is created in the HSM at the time of manufacture and certified by Thales’s secure manufacturing authority, which is certified by Thales’s root authority.

Public key confirmations are automatically generated for RSA key pairs in the HSM. A user can get a confirmation through the PKCS #11 API or the Luna cmu utility, and use it to verify that any RSA key is protected and has always been protected by a Luna HSM. A PKC bundle contains the following certificates:

>MIC: Manufacturing Integrity Certificate; corresponds to the Manufacturing Integrity Private Key (MIK), signed by the Thales root.

>HOC: Hardware Origin Certificate; corresponds to the Hardware Origin Private Key (HOK). Unique to each HSM. Signed by MIK.

>DAC: Device Authentication Certificate; corresponds to the Device Authentication Private Key (DAK). Unique to each HSM. Signed by HOK.

>PKC: Public Key Confirmation Certificate; certificate for a private key on the HSM. Signed by DAK.

Public key confirmations are delivered as PKCS #7 files containing a certificate chain. The PKCS #7 files can be viewed using tools like OpenSSL and Microsoft’s Certificates snap-in for MMC.

NOTE   While third-party tools are capable of cryptographically validating the certificate signature chain, they may display some certificate errors, since they do not recognize some Thales-specific key usage attributes included in the certificates.

Chains of Trust

The chain of trust available via the cmu utility included with the Luna HSM Client, Chrysalis-ITS, is built in by default, and originates from Thales's SafeNet root certificate authority. It uses the MIC, HOC, DAC, and the PKC.

NOTE   Since the introduction of Functionality Modules, HSMs are shipped from the factory with FM-ready hardware. This means that they contain, and use, the HOK and the HOC, but they also have the FM-HOK and FM-HOC on standby. If FMs are enabled on the HSM, the original HOK and HOC are deleted, and the chain-of-trust, thereafter, proceeds through the FM-HOC.

Verifying the HSM's Authenticity

The cmu utility also includes a command, cmu verifyhsm, that tests an HSM’s authenticity by creating and verifying a confirmation on a temporary key created in the HSM. The test includes a proof of possession that asks the HSM to sign a user-entered string as proof the associated private key is present within the target HSM.

NOTE   This confirmation procedure is currently not supported on FM-enabled HSMs. Refer to FM Deployment Constraints for details.

The test requires the SafeNet root certificate, provided below:

NOTE   The current certificate is valid until 2031-12-31, but it might change before this date at Thales's discretion. Ensure that you have the most recent version of this documentation.

To verify the HSM's authenticity

1.Right-click the link above and save the root certificate to the Luna HSM Client directory.

2.Open a command line and navigate to the Luna HSM Client directory.

3.Use the cmu utility to authenticate the HSM. You must specify a challenge string for the HSM to sign, and the root certificate file:

# cmu verifyhsm -challenge <string> -rootcert safenet-root.pem

When prompted, specify the partition you wish to use and the Crypto Officer credential for that partition.

>cmu verifyhsm -challenge "1234567890" -rootcert safenet-root.pem
Select token
 [0] Token Label: mypartition-1
 [1] Token Label: mypartition-2
 Enter choice: 0
Please enter password for token in slot 0 : ********
Reading rootcert from file "safenet-root.pem"... ok.
Generating temporary RSA keypair in HSM... ok.
Extracting PKC bundle from HSM... ok.
Verifying PKC certificate... ok.
Verifying DAC certificate... ok.
Verifying HOC certificate... ok.
Verifying MIC certificate... ok.
Verifying MIC against rootcert... ok.
Signing and verifying challenge... ok.
Verifying HSM serial number... ok.
Overall status: Success.

If this test fails, contact the HSM SO.

Verifying Key Attestation

Thales provides a Java utility, Luna PKC Validator, that allows you to verify that a key was created by a Luna HSM. This tool can be compiled from the repository below:

https://github.com/ThalesGroup/luna-pkc-validator

The utility requires one of the following root certificates for validation.

>To check the attestation of RSA keys, use the SafeNet root certificate, provided above.

>To check the attestation of ECC keys, use the Thales ECC Manufacturing Integrity Certificate: