Trust anchor for Dyber hardware device attestation. All Dyber devices ship with an Endorsement Key (EK) certificate signed by the Dyber Device Intermediate CA. This page publishes the root and intermediate CA certificates, the current CRL, and the certificate policy.
Dyber firmware binaries, SDK releases, and driver packages are signed with an Extended Validation (EV) code signing certificate issued by SSL.com. This is a separate trust chain from the device attestation PKI above. Code signing provides end-user assurance that downloaded software is authentic and unmodified.
Verification. All Dyber SDK and firmware releases published on GitHub (github.com/dyber-pqc) carry an Authenticode signature from this certificate. On Windows, right-click any signed binary, select Properties, then Digital Signatures to verify. On Linux, use osslsigncode verify or check the accompanying .sig file with GPG.
Why classical RSA? No certificate authority currently issues PQC code signing certificates at the EV assurance level required by operating system trust stores (Windows SmartScreen, macOS Gatekeeper). The SSL.com EV certificate uses RSA because that is what the ecosystem accepts today. All Dyber releases also carry an ML-DSA-65 cosignature from the Dyber Device Intermediate CA, verifiable with the trust chain published on this page. When PQC EV code signing becomes commercially available, Dyber will transition to a PQC-native certificate.
Every Dyber hardware device (QUAC-100, QuantaSE, QuantaTPM, QuantaM2, QuantaHSM, QuantaRNG) is provisioned with a unique Endorsement Key (EK) certificate at manufacturing time. This certificate is signed by the Dyber Device Intermediate CA, which is itself signed by the Dyber Root CA. The certificates published on this page form the trust anchor for that chain.
A valid, unrevoked device EK certificate attests to three things: (1) the device is genuine Dyber hardware produced in an authorized manufacturing facility, (2) the firmware loaded on the device at provisioning time was authentic and unmodified, and (3) the device had not been tampered with at the time of provisioning. The certificate does not attest to the current firmware state or physical integrity after shipment. For runtime firmware attestation, use the device's secure boot log and remote attestation protocol documented in the QuantaCore SDK.
The CRL is updated every 7 days. Revocation may occur if a device is reported compromised, if a manufacturing defect affects a batch, or if a firmware vulnerability requires key rotation. For revocation requests, contact legal@dyber.org. The full certificate policy is available at /pki/policy/.
For environments without network access to dyber.org or ocsp.dyber.org, EK certificates are also stored on-device and exportable via the management interface. Use the QuantaCore SDK or the device CLI to extract the full certificate chain:
# Export device EK certificate chain dyber-cli device cert export --format pem --output device-chain.pem # Verify the chain offline against the bundle dyber-cli cert verify --ca-bundle /path/to/bundle.pem --cert device-chain.pem # Or with oqs-provider + OpenSSL openssl verify -CAfile bundle.pem -untrusted intermediate-ca.pem device-ek.pem
The bundle.zip download includes a README with step-by-step import instructions for airgapped environments, including trust store configuration for common operating systems and HSM platforms.
For automated trust chain import, certificate monitoring, and compliance tooling, the PKI metadata is available as structured JSON.
curl -s https://dyber.org/pki/metadata.json | python3 -m json.tool