This document describes how Dyber, Inc. operates its private PKI for hardware device attestation. It follows the RFC 3647 framework and covers identification, authentication, certificate lifecycle, security controls, and audit procedures.
Dyber, Inc. ("Dyber") operates a private Public Key Infrastructure for the purpose of hardware device attestation. Every Dyber cryptographic accelerator, secure element, TPM, and RNG module ships with an Endorsement Key (EK) certificate signed by the Dyber Device Intermediate CA. This CPS describes the practices and procedures governing the issuance, management, and revocation of certificates within the Dyber PKI.
This PKI is a private trust model. The Dyber Root CA is not included in any public browser or operating system trust store. Relying parties explicitly import the Dyber Root CA certificate into their trust configuration as part of integrating Dyber hardware.
The Registration Authority function is performed by the Dyber manufacturing provisioning system. There is no external RA. Device identity is established through the manufacturing process, not through applicant interaction.
Subscribers are Dyber hardware devices. A device does not "apply" for a certificate. The certificate is provisioned automatically during manufacturing after the device generates its key pair and exports its public key.
Relying parties are customers, integrators, and systems that verify Dyber device certificates. They include enterprise IT departments deploying Dyber accelerators, cloud providers integrating Dyber HSMs, and IoT platforms verifying Dyber secure elements.
Dyber publishes the following PKI artifacts at https://dyber.org/pki/:
CA certificates and CRLs are published immediately upon generation. The PKI metadata endpoint at /pki/metadata.json is updated simultaneously and includes serial numbers, fingerprints, validity periods, and download URLs for programmatic consumption.
https://ocsp.dyber.org provides current revocation status.All published PKI artifacts are publicly readable without authentication. Write access is restricted to authorized Dyber PKI administrators via Cloudflare Workers deployment credentials with multi-factor authentication.
Device EK certificates use X.500 Distinguished Names with the following structure:
The Subject Alternative Name (SAN) extension may include a firmware version hash URI.
Each device serial number is unique within the Dyber manufacturing system. The CN field (serial number) combined with the OU field (model) guarantees globally unique subject names. The manufacturing database enforces uniqueness and rejects duplicate serial numbers.
Device identity is validated through the manufacturing process itself. A certificate is issued only when:
There is no human applicant. The entire process is automated within the manufacturing facility.
Device certificates are not re-keyed. If a device key is compromised, the certificate is revoked and the device is decommissioned. A replacement device receives a new certificate through the standard manufacturing provisioning process.
Revocation requests are accepted from:
There is no application process. Certificates are issued automatically during device manufacturing. The provisioning system acts as both the applicant and the registration authority.
The provisioning station performs the following before submitting a signing request to the Intermediate CA:
The Intermediate CA signing service validates the CSR format and extensions, signs the certificate, and returns it to the provisioning station. The signed certificate is then:
A certificate is considered accepted when the post-provisioning verification (challenge-response against the full chain) succeeds. If verification fails, the certificate is immediately revoked and the device is flagged for investigation.
Device EK private keys are generated on-device and never exported. The device uses the EK for:
Device certificates are not renewed. Devices are provisioned once. If a certificate approaches expiry (10-year validity), the device owner contacts Dyber for a replacement device or re-provisioning service.
Not supported. See Section 3.3.
Not supported. A new certificate requires a new key pair and a new provisioning event.
Submit a revocation request to legal@dyber.org with the device serial number, certificate serial number (if known), and reason for revocation. Emergency revocations are processed within 24 hours. Routine revocations are processed within 7 days and reflected in the next CRL.
None. Revocation requests are acted upon as soon as they are validated.
Certificate suspension is not supported. Certificates are either valid or revoked.
Every 7 days under normal operations. Within 24 hours for emergency revocations.
Relying parties should check the CRL or query the OCSP responder before accepting a device certificate. The CRL distribution point and OCSP responder URL are embedded in every device certificate via the Authority Information Access and CRL Distribution Points extensions.
The OCSP responder at https://ocsp.dyber.org provides real-time certificate status per RFC 6960. It supports both HTTP GET and POST methods. Responses are signed by the Intermediate CA using ML-DSA-65.
A device's subscription ends when its certificate is revoked or expires. No additional action is required from the device owner.
Device EK private keys are never escrowed. They are generated on-device and cannot be exported. There is no key recovery mechanism. If a device key is lost, the device must be replaced.
The Root CA HSM is stored in a physically secured, access-controlled location operated by Dyber. The location has environmental controls (temperature, humidity, fire suppression) and is protected by multi-layer physical access controls.
Access to the Root CA HSM requires the physical presence of a quorum of key custodians (minimum 2 of 3). Access events are logged with timestamps and participant identity. The HSM is stored in a tamper-evident container when not in use.
The Root CA HSM storage location has uninterruptible power supply (UPS) protection. The Intermediate CA signing service runs on Cloudflare's infrastructure with redundant power and cooling.
All personnel in trusted roles undergo background checks and sign confidentiality agreements. Training on PKI operations, key management, and incident response is required before assuming any trusted role. Annual refresher training is mandatory.
Audit logs are reviewed weekly by a PKI administrator who was not the subject of the logged events. Anomalies are escalated immediately.
Audit logs are retained for a minimum of 7 years after the expiration of the last certificate issued under the logged CA key.
All CA records, including issuance logs, revocation records, key ceremony documentation, and audit logs, are archived in encrypted storage with geographic redundancy. Archives are retained for the lifetime of the Root CA plus 7 years.
If the Root CA key approaches end of life, a new Root CA is generated in a formal key ceremony (see Key Ceremony Documentation). The old Root CA continues to validate existing certificates until all devices provisioned under it are decommissioned or re-provisioned. Both Root CAs are published simultaneously during the transition period.
Root CA key material is backed up in encrypted, geographically separated HSMs. Recovery requires a quorum of key custodians and follows the same security procedures as a key ceremony.
Not applicable. Device private keys are generated on-device and never leave the device.
The device exports its public key to the provisioning station over a physically secured interface (USB, JTAG, or SPI, depending on the device model). The public key is transmitted in ML-DSA raw format and wrapped in a PKCS#10 CSR by the provisioning station.
The Root CA private key requires a quorum of 2-of-3 key custodians to activate. No single person can access the Root CA private key.
The Root CA private key is backed up to a secondary HSM stored at a geographically separate location, accessible only with the same quorum requirements. Device private keys are never escrowed.
Root CA: encrypted backup in secondary HSM. Intermediate CA: encrypted backup in secondary HSM. Device keys: no backup (generated and retained on-device only).
Private keys are not archived after destruction. When a CA key reaches end of life, it is securely destroyed per Section 6.2.9.
CA private keys are generated within the HSM and never exported in plaintext. Key transfer between HSMs (for backup) uses the HSM vendor's secure key wrapping protocol.
All CA private keys are stored within FIPS 140-3 Level 3 HSMs. Keys are protected by the HSM's internal access control mechanisms and are never stored in software or on disk.
Root CA: quorum authentication (2-of-3 custodian tokens/PINs). Intermediate CA: automated activation via HSM partition credentials, with MFA for administrative access. Device keys: activated by the device's firmware after secure boot.
Root CA: HSM powered off and returned to tamper-evident storage after each use. Intermediate CA: HSM session closed when signing service is stopped. Keys are zeroized on the HSM if the key is being decommissioned.
CA public keys are archived indefinitely as part of the published certificates. Device public keys are recorded in the CA database.
HSM activation data (PINs, tokens) are distributed to key custodians in sealed, tamper-evident envelopes. Custodians store their activation data separately from the HSM. Activation data is changed after each key ceremony or if a custodian's role changes.
The Intermediate CA signing service runs on Cloudflare Workers with the following controls:
Software updates to the CA signing service and OCSP responder are deployed via Cloudflare's CI/CD pipeline. All changes are version-controlled, code-reviewed, and deployed with zero-downtime rollout. Rollback is available within seconds.
The Root CA is air-gapped. It has no network connectivity. The Intermediate CA signing service communicates with the provisioning station over mutually authenticated TLS. The OCSP responder is served via Cloudflare's edge network with DDoS protection and TLS termination.
Certificate issuance and revocation events are timestamped using the signing system's clock, synchronized via NTP. OCSP responses include thisUpdate and nextUpdate fields with UTC timestamps.
Internal compliance audits are conducted annually. The audit covers all aspects of this CPS, including key management, certificate lifecycle, physical controls, and personnel procedures. External audits are conducted as required by customer contracts or regulatory obligations.
Internal audits are performed by Dyber personnel who do not hold trusted roles in the PKI (separation of duties). External audits are performed by qualified auditors with experience in PKI operations and FIPS 140 validation.
Audit findings are classified by severity. Critical findings (those affecting key security or certificate integrity) require immediate remediation. All findings are tracked to resolution and verified in the subsequent audit.
Internal audit results are reported to Dyber executive management. External audit reports are made available to relying parties and customers upon request under NDA where appropriate.
There are no fees for accessing CA certificates, CRLs, OCSP responses, or this CPS. Device EK certificates are included with Dyber hardware products at no additional cost.
Dyber maintains appropriate insurance for its business operations. Specific financial responsibility related to PKI operations is governed by individual customer agreements.
The following information is confidential:
The following information is public:
The Dyber PKI does not process personal information. Certificates are issued to hardware devices, not individuals. Audit logs may contain employee names in trusted roles; these are handled per the Dyber Privacy Policy.
Dyber retains all intellectual property rights in the PKI infrastructure, software, and documentation. Relying parties are granted a non-exclusive, royalty-free license to use the published CA certificates and CRLs for the purpose of verifying Dyber device certificates.
Dyber warrants that:
Relying parties must:
Except as expressly stated in this CPS and applicable customer agreements, Dyber provides the PKI on an "as is" basis. Dyber does not warrant uninterrupted availability of the CRL or OCSP services, though it makes commercially reasonable efforts to maintain high availability.
Dyber's liability related to the PKI is limited to the terms of the applicable customer agreement. In no event shall Dyber be liable for indirect, incidental, or consequential damages arising from reliance on certificates issued under this CPS.
This CPS is governed by the laws of the State of Maryland, United States, without regard to conflict of law principles.
Disputes related to this CPS or the PKI are resolved per the dispute resolution provisions of the applicable customer agreement. In the absence of such provisions, disputes are submitted to binding arbitration in Annapolis, Maryland.
Version 1.0. Effective date: 2026-06-11. Dyber, Inc., Annapolis, Maryland.