Sovereign key ceremony

A key ceremony is the controlled event that creates or changes the private key used to sign your product licences. Its purpose is to make key custody demonstrable, not ceremonial for its own sake.

For DYCRYPT Sovereign, generate the private key inside your HSM or PKCS#11 token and keep it non-exportable. DYCRYPT receives access to request signatures through the configured hardware boundary. Your application receives only the public key or certificate.

Assign the roles first

Role	Responsibility
Key custodian	Controls the HSM partition, token, backup policy, and recovery material.
DYCRYPT operator	Configures the product and connects it to the approved PKCS#11 signing object.
Application owner	Embeds the public key and confirms the application rejects signatures from any other key.
Independent observer	Records who attended, which procedure was followed, and which evidence was retained.

Keep these roles separate where your policy requires dual control. DYCRYPT does not decide your segregation-of-duties policy.

Before the ceremony

Record:

• the product and environment the key will sign for;
• the approved algorithm and key size;
• HSM vendor, model, firmware, partition, and object-label convention;
• whether the signing object must be non-exportable;
• who may administer the HSM and who may issue licences;
• backup, recovery, and destruction requirements;
• the application release that will receive the public key.

Confirm the selected algorithm is supported by both DYCRYPT and the application SDK before generating anything.

Generate and register the key

1. Authenticate the required custodians under your HSM procedure.
2. Generate the signing key inside the approved HSM partition or PKCS#11 token.
3. Mark the private object non-exportable when the hardware supports that policy.
4. Export only the public key or a certificate containing it.
5. Record the public-key fingerprint independently.
6. Configure DYCRYPT to address the signing object through PKCS#11.
7. Issue a test licence and verify it from a clean application build.
8. Change one signed field and confirm verification fails.
9. Retain the ceremony record under your evidence policy.

The exact screens, commands, and evidence formats depend on the HSM and the scoped Sovereign deployment. Capture them in the deployment runbook rather than assuming one vendor’s procedure applies to another.

Evidence to retain

• approved ceremony plan and attendance record;
• HSM key-generation or audit output;
• public-key fingerprint and certificate, if used;
• DYCRYPT product identifier and signing configuration;
• test-licence identifier and verification result;
• application artifact hash containing the public key;
• exceptions, failed steps, and their disposition.

DYCRYPT does not currently claim a separately specified tamper-evident audit log. If your control requires append-only evidence, retain the ceremony record in your existing governed evidence system.

Rotation and recovery

Do not discover the rotation path during an incident. Before production, test how you will:

• introduce a new public key to the application;
• keep already-issued licences verifiable for their required lifetime;
• stop new signatures with the old key;
• recover the HSM partition without exporting the key in plaintext;
• revoke access for a departing custodian;
• document destruction when the retention period ends.

Treat algorithm migration as an application-release problem as well as a key-management problem. A field binary can verify only the algorithms and public keys it already knows how to accept.