Auditable entropy chain
Where every random byte in QNSP comes from.
This page documents the end-to-end source of randomness for every cryptographic operation in QNSP — 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 QNSP backend service. Implementation: openssl/openssl drbg.c. |
| 4. Application-level consumption | Node.js crypto.randomBytes() / crypto.getRandomValues() in 16 backend services + the @noble/post-quantum browser SDK + @cuilabs/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-managed FIPS 140-3 Level 3 HSM DRBG.
On Maximum, Government, and Specialized policy tiers, root key generation is routed through the customer's HSM. QNSP never sees raw entropy bytes; the customer retains key-custody and independent FIPS validation.
| Stage | Source | Standard / spec | How to verify |
|---|---|---|---|
| Hardware DRBG (BYOH tiers — Maximum / Government / Specialized) | Customer-managed HSM DRBG. Eight supported vendors via PKCS#11: AWS CloudHSM (Cavium HSM), Azure Managed HSM (Marvell LiquidSecurity), Thales Luna 7, Entrust nShield Solo XC / Connect XC, Utimaco CryptoServer Se-Series Gen2, Marvell LiquidHSM, Fortanix DSM, HashiCorp Vault HSM. | Each vendor independently FIPS 140-3 Level 3 validated. CMVP-certified DRBG (SP 800-90A) inside the tamper-responsive boundary. Customer retains key-custody; QNSP never sees raw entropy bytes. | PKCS#11 channel established at tenant onboarding; key generation routed through HSM-side OPS_GenerateKeyPair on Maximum + Government + Specialized policy tiers per packages/security/src/crypto-policy.ts (STRICT/MAXIMUM/GOVERNMENT_CRYPTO_POLICY requireHsmForRootKeys: true). |
Supported HSM vendors (current): AWS CloudHSM, Azure Managed HSM, Thales Luna 7, Entrust nShield Solo XC / Connect XC, Utimaco CryptoServer Se-Series Gen2, Marvell LiquidHSM, Fortanix DSM, HashiCorp Vault HSM. Each vendor independently FIPS 140-3 Level 3 validated by an NVLAP-accredited CSTL.
Chain C · QRNG mix-in (optional, sales-assisted)
Quantum-entropy seeded into HSM DRBG for tenants who require it.
QNSP 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. QNSP 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. QNSP 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. QNSP 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. QNSP 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 QNSP 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). QNSP 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 QNSP 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; QNSP will tighten its RBG-construction language once 800-90C is finalized.
- This page documents algorithm-level / construction-level entropy provenance. It is NOT a module-level FIPS 140-3 / CMVP attestation of the QNSP service plane. CMVP validation via an NVLAP-accredited CSTL is on the roadmap; current entropy assurance flows from the OS + OpenSSL + HSM-vendor validation records cited above.
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)