Attestation bundle format and construction
A key attestation bundle is a JSON object containing all the required data to verify that a key has been generated by an nShield HSM. It is the standard used by the Key Attestation Verifier and is encouraged for any other implementations for verifying nShield keys. All field names, data types and requirements are listed in the table below. For a worked example for retrieving the required fields using Python, nShield libraries and an HSM connection, see Bundle construction example.
All nShield data types (e.g. M_KeyData) are marshaled to byte strings. DDDS objects (e.g. warrants) are marshaled to byte strings. Byte strings are encoded with URL-safe base64 encoding, from RFC4648.
There are no ordering constraints on bundle representation.
Bundle fields
Field | Type | Encoding | Presence | Description |
---|---|---|---|---|
pubkeydata |
M_KeyData |
marshal+base64 |
Always |
Public key material in nCore format (including any domain parameters) |
kcmsg |
M_ModCertMsg |
marshal+base64 |
Always |
The key generation certificate body (i.e. ModCertType_KeyGen) |
kcsig |
M_CipherText |
marshal+base64 |
Always |
The signature on the key generation certificate under KML |
modstatemsg |
M_ModCertMsg |
marshal+base64 |
Always |
A module state certificate (i.e. ModCertType_StateCert). See below for further requirements. |
modstatesig |
M_CipherText |
marshal+base64 |
Always |
The signature on the module state certificate under KLF2. |
warrant |
DDDS list |
marshal+base64 |
Always |
The DDDS encoding of the generating HSM’s KLF2 warrant. |
root |
string |
none |
Always |
The name of the warranting root used in this certificate. This will always be KWARN-1 for nShield HSMs. |
knsopub |
M_KeyData |
marshal+base64 |
Persistent keys |
KNSO public key (needed to validate trump ops groups and actions) |
hkre |
M_KeyHashEx |
marshal+base64 |
Recoverable keys |
Hash of KRE (needed to validate recovery blobbing action) |
hkra |
M_KeyHashEx |
marshal+base64 |
Recoverable keys |
Hash of KRA (needed to reconstruct world binding certs) |
hkfips |
M_KeyHashEx |
marshal+base64 |
Persistent keys in FIPS worlds |
Hash of KFIPS (needed to reconstruct world binding certs) |
hkmc |
M_KeyHashEx |
marshal+base64 |
Persistent keys |
Hash of KMC (needed to reconstruct world binding certs) |
hkm |
M_KeyHashEx |
marshal+base64 |
Persistent keys |
Hash of KM (needed to validate module configuration) |
CertKMaKMCbKNSO |
M_CipherText |
marshal+base64 |
Persistent keys in non-FIPS worlds |
Signature on world binding cert |
CertKMaKMCaKFIPSbKNSO |
M_CipherText |
marshal+base64 |
Persistent keys in FIPS worlds |
Signature on world binding cert |
CertKREaKRAbKNSO |
M_CipherText |
marshal+base64 |
Recoverable keys |
Signature on world binding cert |
ciphersuite |
string |
none |
Persistent keys |
Ciphersuite name for security world from the NFKM_CipherSuite enumeration (e.g. DLf3072s256mAEScSP800131Ar1) |
Persistent and recoverable keys
'Recoverable' has its normal nShield meaning:
-
The key’s ACL has MakeArchiveBlob action permitting blobbing under KRE (recovery key).
-
The key’s ACL has a 'trump ops' permission group, requiring KNSO (security officer’s key) authorization and permitting any action (generally including ExpandACL and/or ExportAsPlain).
'Persistent' has a special meaning here, not connected to the idea of cardsets being persistent. A persistent key has at least one blobbing action in its ACL, meaning it can be saved to some kind of storage and used long after generation. A non-persistent key has no blobbing actions. Note that recoverable keys are always persistent.