Create Key Attestation
Primus HSM can create different attestations to prove the provenance of artifacts, including keys. Such key attestations allow external auditors to verify the attributes of a key and that it securely resides inside Primus HSM.
Prerequisites
Key attestation requires the Root Key Store to be set up.
General steps
Key attestations can be created using any of the supported APIs. The general steps are the following:
-
Generate an "attestation key pair" on the Partition.
- This is a normal asymmetric key with the
attestationattribute set. - Primus HSM will automatically issue a certificate for this key, signed by the device key.
To verify the key attestation, an auditor will need the
PrimusHSM_Attestation.crtfile, which contains the full certificate chain.
tip- This step is not required for the REST API, since the TSB automatically generates an attestation key.
- It is possible to generate multiple different attestation keys on a single Partition.
- This is a normal asymmetric key with the
-
Generate a key you want attested. For example, this can be a signing key.
-
Create the key attestation.
- This function takes as input the key to be attested and the attestation key to use.
- It returns the key attestation signature:
${LABEL}.sigand the key attestation content:${LABEL}.xml.
See the Verify Key Attestations tutorial to learn how to verify key attestations.
Code Samples
See the following tutorials for concrete examples how to create a key attestation:
Example Key Attestation
The sample below shows the XML part of a key attestation. Note that for simplicity, the accompanying signature and certificate chain are omitted here, but you should always verify them before you trust the XML.
How you interpret the metadata is up to your use case. Use an XML parser of your choice to process the attributes.
For example, you can verify that the key has attributes extractable=false and never_extractable=true.
This proves that the key was generated inside the HSM and could never be extracted from it.
Similarly, the <key_use_count> field shows how often the key was used,
and the <policy> block shows the key's SKA policy.
For details, please see the list of available key attributes.
<?xml version="1.0" encoding="UTF-8"?>
<private_key creation="generated">
<uuid>005259F9-ACACA30A-48203320-6B81A8E3</uuid>
<label format="UTF-8">my-ed25519-key</label>
<create_time>2026-10-20T09:27:59Z</create_time>
<attest_time>2026-10-20T09:27:59Z</attest_time>
<key_use_count>0</key_use_count>
<algorithm>ED</algorithm>
<algorithm_oid>1.3.101.112</algorithm_oid>
<public_key format="base64">MCowBQYDK2VwAyEATbCLaY4SKIzxHADIZb0atIX9CUwfDLgxPRdchHnUUJo=</public_key>
<attributes>
<decrypt>true</decrypt>
<sign>true</sign>
<unwrap>true</unwrap>
<decapsulate>false</decapsulate>
<derive>false</derive>
<sensitive>true</sensitive>
<always_sensitive>true</always_sensitive>
<extractable>false</extractable>
<never_extractable>true</never_extractable>
<modifiable>false</modifiable>
<copyable>false</copyable>
<destroyable>true</destroyable>
<unique>true</unique>
</attributes>
<policy>
<key_status>
<blocked>false</blocked>
<sam_approved>false</sam_approved>
</key_status>
<rule_use>
<token name="Token1">
<timelock>0</timelock>
<timeout>0</timeout>
</token>
</rule_use>
<rule_block>
<token name="Token1">
<timelock>0</timelock>
<timeout>0</timeout>
</token>
</rule_block>
<rule_unblock>
<token name="Token1">
<timelock>0</timelock>
<timeout>0</timeout>
</token>
</rule_unblock>
<rule_modify>
<token name="Token1">
<timelock>0</timelock>
<timeout>0</timeout>
</token>
</rule_modify>
</policy>
</private_key>