Auditable entropy chain
Where every random byte in QNSI comes from.
This page documents the end-to-end source of randomness for every cryptographic operation in QNSI — key generation, encapsulation, signing, nonces, IVs, tokens. The chain is structured around NIST SP 800-90A Rev. 1 (DRBG constructions), SP 800-90B (entropy sources), and the draft SP 800-90C (3rd public draft, July 2025) for RBG-construction guidance.
Three chains coexist: a CSPRNG chain that backs default and strict tier tenants, an HSM-DRBG chain for Maximum, Government, and Specialized tier tenants using BYOH, and an optional QRNG mix-in chain available as a sales-assisted add-on for tenants who require quantum-entropy mixing under their own infrastructure.
Chain A · CSPRNG (default + strict tiers)
OpenSSL DRBG seeded from Linux + CPU hardware entropy.
Four-stage chain: CPU TRNG → Linux kernel CRNG → OpenSSL DRBG → application randomBytes(). Every byte is traceable to a NIST-validated construction or a documented OS / library implementation.
| Stage | Source | Standard / spec | How to verify |
|---|---|---|---|
| 1. CPU hardware entropy | Intel RDRAND / RDSEED (x86_64 Fargate hosts on m6i / m7i / c6i / c7i), ARM TRNG (Graviton hosts), AWS Nitro Security Chip TRNG (per-instance, isolated from host) | Intel DRNG implements NIST SP 800-90B-compliant entropy source + SP 800-90A DRBG. AWS Nitro TRNG runs per-instance and is part of the Nitro System whitepaper. | Verified at runtime via /proc/cpuinfo for rdrand/rdseed flags and /sys/devices/system/cpu/* topology. CPU instruction directly feeds the Linux kernel entropy pool through arch_get_random_*() callbacks. |
| 2. Linux kernel entropy pool | Linux kernel CRNG — mixes (a) CPU TRNG via arch_get_random_*(), (b) interrupt timing jitter, (c) device timing, (d) early-boot stored entropy. Output via getrandom(2) syscall, /dev/urandom, /dev/random. | Linux kernel ≥ 5.18 uses BLAKE2s for pool mixing and ChaCha20 for output; SP 800-90B-style entropy estimation. getrandom() blocks until the pool is seeded then never blocks again on reseed. | Container image: node:24-alpine pinned in every backend Dockerfile. getrandom(2) is the syscall Node.js crypto uses internally; verified via strace. |
| 3. OpenSSL DRBG | OpenSSL CSPRNG — NIST SP 800-90A AES-256-CTR-DRBG by default. Reseeded from getrandom() at process start and every 2^48 bits of output or 2^16 generate calls (whichever first). | NIST SP 800-90A Rev. 1 — AES-CTR-DRBG (validated construction). OpenSSL implementation backs the FIPS 140-3 OpenSSL provider used in FIPS-validated paths. | Node.js crypto.randomBytes() → OpenSSL RAND_bytes() → SP 800-90A DRBG. Same code path used by every QNSI backend service. Implementation: openssl/openssl drbg.c. |
| 4. Application-level consumption | Node.js crypto.randomBytes() / crypto.getRandomValues() in 18 backend services + @noble/post-quantum in browser and edge runtimes + @heossihq/liboqs-native (when liboqs is configured to use OpenSSL as RNG, which is our build flag). | Inherits SP 800-90A DRBG output. liboqs is built with OQS_USE_OPENSSL=ON, which routes its randombytes() calls through OpenSSL's DRBG rather than its built-in System RAND. | tooling/docker/liboqs-builder-base.Dockerfile line 22: cmake -GNinja -DOQS_USE_OPENSSL=ON -DOQS_BUILD_SHARED_LIBS=OFF. Verified in apps/kms-service, apps/vault-service, apps/auth-service randomBytes() call sites. |
Chain B · HSM DRBG (BYOH on higher tiers)
Customer-qualified HSM DRBG.
Where a customer HSM has passed qualification and is configured for the deployment, root-key generation can execute within that device. The resulting claim is limited to the observed path and the selected device's certificate scope.
| Stage | Source | Standard / spec | How to verify |
|---|---|---|---|
| Customer-qualified hardware DRBG (conditional deployment path) | A customer-managed HSM DRBG is used only after the exact device and QNSI connector pass live qualification. QNSI has six PKCS#11 connector implementations; the two REST custody backends are not PKCS#11 entropy sources. | Any CMVP or DRBG claim is taken from the selected device's certificate and is limited to its listed model, firmware, operating mode, algorithm scope, and deployment configuration. | Qualification must capture the live token identity, mechanism inventory, key-operation results, correlation IDs, and vendor-certificate mapping. A policy requiring HSM custody does not itself prove that routing occurred. |
QNSI publishes connector implementations separately from qualification status: six use PKCS#11 and two use REST. A vendor name never establishes device compatibility, entropy provenance, or FIPS scope without live qualification evidence.
Chain C · QRNG mix-in (optional, sales-assisted)
Quantum-entropy seeded into HSM DRBG for tenants who require it.
QNSI does not ship QRNG hardware as a platform-wide dependency. Tenants who contractually require quantum entropy bring their own QRNG (Qrypt, Quantum Dice, ID Quantique Quantis, Quantum-Origin) and integrate it into their HSM via PKCS#11. QNSI mixes the customer QRNG into the HSM DRBG seed as an RBG3 prediction-resistance reseed per NIST SP 800-90C — never as the sole source.
| Stage | Source | Standard / spec | How to verify |
|---|---|---|---|
| QRNG mix-in (sales-assisted add-on) | Customer-supplied Quantum Random Number Generator: ID Quantique Quantis devices (PCIe / USB), Qrypt cloud entropy service, Quantum Dice device, Quantum-Origin from Quantinuum, or any QRNG that exposes a NIST SP 800-90C-compliant Get_entropy_input interface through a PKCS#11-equipped HSM. | NIST SP 800-90C (draft, July 2025 third public draft) defines RBG2/RBG3 constructions for combining a quantum entropy source with a DRBG. QNSI mixes QRNG bytes into the HSM DRBG seed material as RBG3 prediction-resistance reseed, never as the sole source. | Available as a sales-assisted add-on (`byoh-qrng-mixin` in apps/billing-service pricing config). Activation requires a signed BYOH agreement and customer-provided device certificates. QNSI never operates customer QRNG infrastructure. |
Policy-tier entropy mapping
Defaults and enforcement by crypto policy tier.
The cryptoEntropySource field on a tenant's crypto policy declares which chain is authoritative for that tenant. Defaults map cleanly from the four crypto policy tiers; tenants on Maximum or Government can additionally enable the QRNG mix-in add-on.
| Policy tier | cryptoEntropySource | Enforcement |
|---|---|---|
default | csprng | OpenSSL SP 800-90A AES-CTR-DRBG (seeded from Linux getrandom + CPU TRNG). Same path as Node.js stdlib crypto.randomBytes(). |
strict | csprng | Same DRBG as default. Adds policy-level requirement that all KEM/sig operations use NIST-finalized algorithms (FIPS 203/204/205). |
maximum | hsm-byo | Root key generation routed through customer-managed HSM DRBG via PKCS#11. QNSI fail-closes if HSM is unreachable for root-key operations. |
government | hsm-byo | Same as maximum, plus algorithm restriction to FIPS-finalized only (no draft standards). QRNG mix-in available as additional add-on for tenants that contractually require quantum entropy. |
Known limitations · honesty section
What this page does and does not claim.
- The cryptoEntropySource field on a tenant's crypto policy is currently a declarative contract recorded in the audit trail and the billing layer. It is enforced at the policy-decision layer (PDP rejects operations that violate the contract) but production code does not yet route per-tenant randomness through different physical sources — every randomBytes() call in QNSI backend services resolves to the same OpenSSL DRBG. Per-tenant entropy-source routing is on the platform roadmap and tracked separately from this page.
- QRNG mix-in is delivered via the customer's HSM (the HSM performs the RBG3 reseed). QNSI does not host QRNG devices and never sees raw entropy bytes from the customer's QRNG. This is the architecturally correct position: it keeps trust boundaries clean and lets the customer own quantum-physics attestation independently from the QNSI control plane.
- NIST SP 800-90C is still a draft as of this publication date. The third public draft (July 2025) is the latest revision; QNSI will tighten its RBG-construction language once 800-90C is finalized.
- This page documents algorithm-level and construction-level entropy provenance. It is not a module-level FIPS 140-3 / CMVP attestation of the QNSI service plane. Customer-HSM assurance exists only for a deployment with approved live-device qualification evidence.
Related evidence + standards
Where to verify each claim independently.
- NIST SP 800-90A Rev. 1 — DRBG constructions (AES-CTR-DRBG, HMAC-DRBG, Hash-DRBG)
- NIST SP 800-90B — entropy source requirements
- NIST SP 800-90C (3rd public draft, July 2025) — RBG2 / RBG3 constructions
- OpenSSL RAND_bytes(3) — the actual DRBG implementation Node and liboqs route through
- Linux getrandom(2) — the kernel syscall that seeds OpenSSL
- AWS Nitro System security whitepaper — Nitro Security Chip TRNG
- NIST CMVP — per-vendor HSM FIPS 140-3 validation records (look up each HSM model on the Active Validation List)
- /verify/conformance — complementary page covering NIST ACVP test-vector conformance for our PQC implementations (the algorithm side of the picture; this page covers the entropy side)