This document describes the formal procedures for generating, backing up, and activating Dyber PKI root and intermediate CA key pairs. All key ceremonies are witnessed, recorded, and auditable.
1. Overview
A key ceremony is a formal, witnessed process for generating cryptographic key material that will serve as a trust anchor. Dyber conducts key ceremonies for:
Root CA key generation. The Root CA is the ultimate trust anchor for all Dyber hardware device attestation. Its private key must be generated and stored with the highest level of security.
Intermediate CA key generation. The Intermediate CA signs device certificates. Its key must be generated securely and bound to the Root CA through a signed certificate.
Emergency re-key. If a CA key is compromised or suspected compromised, an emergency ceremony generates replacement keys.
All ceremonies follow the same core principles: air-gapped generation, multi-person control, independent witnessing, and complete audit trail.
2. Roles and Responsibilities
2.1 Ceremony Administrator
The Ceremony Administrator directs the ceremony, reads each step aloud, and ensures the procedure is followed exactly. The administrator does not handle key material or activation data.
2.2 Key Custodians
Key Custodians hold shares of the HSM activation credentials. A minimum of three custodians are appointed. Any two custodians can activate the HSM (2-of-3 quorum). Custodians are responsible for:
Safeguarding their activation share (PIN, token, or smart card)
Being physically present during ceremonies requiring HSM activation
Reporting any suspected compromise of their activation share immediately
2.3 Ceremony Witnesses
At least one independent witness must be present for every key ceremony. The witness:
Must not hold any other role in the ceremony
Observes every step and confirms each was performed correctly
Co-signs the ceremony log at the conclusion
May be an external auditor, legal counsel, or a Dyber employee who does not hold a trusted PKI role
2.4 Technical Operator
The Technical Operator executes commands on the ceremony workstation and HSM under the direction of the Ceremony Administrator. The operator has no access to activation credentials.
No person may hold more than one role in a single ceremony
Quorum
2-of-3 Key Custodians required for HSM activation
3. Prerequisites
3.1 Equipment
Air-gapped workstation. A dedicated laptop or workstation with no network interfaces enabled (WiFi disabled, Ethernet disconnected, Bluetooth off). Verified clean by the Technical Operator before the ceremony.
Hardware Security Module (HSM). FIPS 140-3 Level 3 validated. Connected to the air-gapped workstation via USB or direct serial interface. Pre-initialized with a blank partition.
Backup HSM. A second HSM of the same model for key backup, stored at a separate location.
Tamper-evident bags. For sealing HSMs and activation data after the ceremony.
USB drives (2x). New, sealed, for transferring the public certificate from the air-gapped workstation. Destroyed after transfer.
Printed procedure. A hard copy of this ceremony procedure for the administrator to read from.
Camera or video recording equipment. For recording the ceremony (optional but recommended).
Ceremony log forms. Pre-printed forms for recording each step, timestamps, and signatures.
3.2 Software
OpenSSL 3.5 or later with native ML-DSA-65 support
HSM vendor PKCS#11 library and management tools
SHA-256 fingerprint utility
3.3 Pre-Ceremony Checklist
Verify the identity of all participants (government-issued photo ID)
Confirm the air-gapped workstation has no network connectivity
Verify the HSM firmware version and tamper-evident seal
Confirm USB drives are factory sealed
Distribute printed ceremony procedure to the administrator
Begin the ceremony log with date, time, location, and participant names
4. Root CA Key Ceremony
The following procedure generates the Root CA key pair, creates the self-signed Root CA certificate, and secures the private key in the HSM.
The Root CA private key must never leave the HSM in plaintext. All key generation occurs inside the HSM's cryptographic boundary. The air-gapped workstation sends commands to the HSM but never holds the private key.
Initialize HSM Partition
The Technical Operator initializes a new partition on the HSM labeled DYBER-ROOT-CA. The Key Custodians each enter their activation share (PIN/token) to set the quorum policy to 2-of-3. The administrator confirms the partition is empty.
Generate ML-DSA-65 Key Pair
Two Key Custodians authenticate to the HSM. The Technical Operator executes the key generation command. The HSM generates an ML-DSA-65 key pair internally using its certified TRNG. The private key is stored in the HSM partition and never exported.
The Technical Operator generates the self-signed certificate using the HSM-resident key. The OpenSSL configuration specifies the subject DN, validity period (20 years), and extensions (basicConstraints: critical, CA:TRUE; keyUsage: critical, keyCertSign, cRLSign; subjectKeyIdentifier: hash).
The Technical Operator displays the certificate details. The administrator and witness verify: the subject DN is correct, the validity period is 20 years, the algorithm is ML-DSA-65, the extensions are correct, and the certificate is self-signed (issuer = subject).
openssl x509 -in root-ca.pem -text -noout
Compute and Record Fingerprint
The Technical Operator computes the SHA-256 fingerprint of the Root CA certificate. The fingerprint is read aloud, written on the ceremony log by the administrator, and independently verified by the witness.
The Root CA certificate (public data only) is copied to two USB drives in both PEM and DER format. One USB drive is for the publishing workstation; the second is a backup. No private key material touches the USB drives.
Deactivate and Seal HSM
The Key Custodians deactivate their sessions. The Technical Operator powers off the HSM. The HSM is placed in a tamper-evident bag, sealed, and the seal number is recorded in the ceremony log. The sealed HSM is stored in the designated secure location.
5. Intermediate CA Key Ceremony
The Intermediate CA ceremony generates a new key pair, creates a CSR, and has it signed by the Root CA. This ceremony requires the Root CA HSM to be temporarily brought online.
Verify Root CA HSM Seal
Before unsealing, the administrator and witness inspect the tamper-evident bag. The seal number is compared against the ceremony log. Any evidence of tampering halts the ceremony immediately.
Generate Intermediate CA Key Pair
On the Intermediate CA HSM (which will be connected to the signing service), the Technical Operator generates an ML-DSA-65 key pair. The private key is stored in the HSM partition DYBER-INTERMEDIATE-CA.
The Technical Operator generates a CSR for the Intermediate CA using the configuration that specifies: subject DN with OU=Device Attestation, and the requested extensions.
The Root CA HSM is unsealed and powered on. Two Key Custodians authenticate to the Root CA partition. The administrator confirms the Root CA certificate fingerprint matches the recorded value.
Sign Intermediate CA Certificate
The Technical Operator signs the CSR with the Root CA, producing the Intermediate CA certificate with a 10-year validity and extensions: basicConstraints (critical, CA:TRUE, pathlen:0), keyUsage (critical, keyCertSign, cRLSign), authorityKeyIdentifier, subjectKeyIdentifier, crlDistributionPoints, and authorityInfoAccess (OCSP).
The Technical Operator displays the certificate and verifies: issuer matches the Root CA subject, subject is correct, algorithm is ML-DSA-65, extensions are present and correct, and the chain validates.
Both the Root CA and Intermediate CA fingerprints are computed, read aloud, and recorded. The serial numbers of both certificates are recorded in the ceremony log.
Deactivate and Seal Root CA HSM
The Root CA HSM is deactivated, powered off, sealed in a new tamper-evident bag, and the new seal number is recorded. The Root CA HSM is returned to secure storage.
6. Key Backup Procedures
6.1 Root CA Key Backup
The Root CA private key is backed up to a secondary HSM using the HSM vendor's secure key cloning or wrapping protocol. The backup occurs during the initial key ceremony, before the primary HSM is sealed.
The backup HSM must be the same model and firmware version as the primary.
Key transfer uses the HSM's internal key wrapping mechanism. The private key never appears in plaintext outside an HSM.
The backup HSM is sealed in a tamper-evident bag and stored at a geographically separate location.
Access to the backup HSM requires the same 2-of-3 custodian quorum as the primary.
6.2 Intermediate CA Key Backup
The Intermediate CA key is backed up using the same procedure. The backup is tested by signing a test certificate and verifying it chains correctly before the backup HSM is sealed.
6.3 Activation Data Backup
Each Key Custodian's activation share is sealed in a tamper-evident envelope and stored in a safe deposit box or equivalent secured storage. The storage location is different from the HSM storage location. A record of which custodian holds which share and where it is stored is maintained by the Ceremony Administrator in a sealed envelope stored with the organization's legal records.
7. Post-Ceremony Verification
Before the ceremony is formally concluded, the following verifications must pass:
Chain validation. The Intermediate CA certificate validates against the Root CA certificate using openssl verify.
Fingerprint match. The SHA-256 fingerprints recorded in the ceremony log match the computed fingerprints of the certificates on the USB drives.
Extension check. All required X.509v3 extensions are present and have the correct values (verified visually from openssl x509 -text output).
Algorithm confirmation. Both certificates use ML-DSA-65 (OID 2.16.840.1.101.3.4.3.18).
Backup verification. A test signature using the backup HSM produces a valid signature verifiable against the certificate.
CRL generation test. An empty CRL is generated and signed by the Intermediate CA to verify signing capability.
8. Ceremony Material Destruction
After the ceremony is complete and all verifications pass:
The air-gapped workstation's storage is securely wiped (full disk overwrite). If an SSD, a secure erase command is issued.
USB drives used for certificate transfer are physically destroyed after the certificates are published.
Any scratch paper or printouts used during the ceremony (other than the official ceremony log) are shredded.
The ceremony log is signed by all participants and stored with the organization's legal records.
Never discard ceremony materials without destruction. Even public certificates on USB drives could be swapped by an attacker if the drives are recoverable. Physical destruction eliminates this vector.
9. Emergency Re-Key Procedure
If a CA key is compromised or suspected compromised:
Immediate notification. All Key Custodians and the Ceremony Administrator are notified. The compromised key is disabled if possible (HSM partition locked).
Incident assessment. Determine the scope: which key is compromised, which certificates are affected, and whether the compromise is confirmed or suspected.
Revocation. If the Intermediate CA key is compromised, publish an updated Root-level CRL revoking the Intermediate CA certificate. If the Root CA key is compromised, publish a notice to all known relying parties.
Emergency ceremony. Conduct a key ceremony following the standard procedure, with the additional requirement that the compromised HSM is forensically preserved (not wiped) for incident investigation.
Re-provisioning plan. Develop a plan for re-provisioning affected devices. Notify customers and provide a timeline.
Incident report. Publish an incident report on the Dyber news page within 72 hours of confirmed compromise.
10. Ceremony Log
The following is the template for the ceremony log. A completed copy is signed by all participants and archived with the organization's legal records.
DYBER PKI KEY CEREMONY LOG
===========================
Date: ____________________
Location: ____________________
Ceremony Type: [ ] Root CA Generation
[ ] Intermediate CA Generation
[ ] Emergency Re-Key
[ ] Key Backup/Recovery
PARTICIPANTS
------------
Ceremony Administrator: __________________ Signature: __________
Key Custodian 1: __________________ Signature: __________
Key Custodian 2: __________________ Signature: __________
Key Custodian 3: __________________ Signature: __________
Technical Operator: __________________ Signature: __________
Witness: __________________ Signature: __________
EQUIPMENT
---------
Primary HSM Model: ____________________
Primary HSM Serial: ____________________
Backup HSM Model: ____________________
Backup HSM Serial: ____________________
Workstation ID: ____________________
USB Drive 1 Serial: ____________________
USB Drive 2 Serial: ____________________
CEREMONY STEPS
--------------
Step Time Performed By Verified By Notes
---- -------- -------------- -------------- -----
1 ________ ______________ ______________ _____
2 ________ ______________ ______________ _____
3 ________ ______________ ______________ _____
...
RESULTS
-------
Certificate Subject: ____________________
Certificate Serial: ____________________
SHA-256 Fingerprint: ____________________
Algorithm: ML-DSA-65 (FIPS 204)
Validity Start: ____________________
Validity End: ____________________
SKI: ____________________
HSM Seal Numbers:
Primary HSM: ____________________
Backup HSM: ____________________
POST-CEREMONY VERIFICATION
--------------------------
[ ] Chain validation passed
[ ] Fingerprint matches recorded value
[ ] Extensions verified
[ ] Algorithm confirmed ML-DSA-65
[ ] Backup HSM test signature passed
[ ] CRL generation test passed
MATERIAL DESTRUCTION
--------------------
[ ] Workstation storage wiped
[ ] USB drives physically destroyed
[ ] Scratch materials shredded
All participants confirm this log is a true and accurate
record of the ceremony as performed.
Administrator Signature: ____________________ Date: ________
Witness Signature: ____________________ Date: ________
Historical Ceremony Records
Ceremony #1: Initial Root CA and Intermediate CA Generation