Compliance & Privacy · 2026-03-13

The Zero-Knowledge Audit Trail: Proving Provenance Without PII

By J. W. Bouckaert

The compliance paradox

Every regulated industry faces the same contradiction. Auditors require evidence. Privacy law prohibits retention.

A financial institution must demonstrate that its authentication system uses cryptographically sound randomness. A healthcare provider must prove that session tokens are not predictable. A defense contractor must show how its key generation draws randomness. In each case, the auditor's question is the same: "Show me where your entropy came from."

The naive answer is to log the raw entropy. Store the seed bytes. Keep a record of every quantum random number that entered the system. The auditor can inspect it, verify it, and sign off.

The problem is that raw entropy, once stored, becomes a liability. If an attacker obtains the entropy that seeded a cryptographic key, the key is compromised. If the entropy that generated a nonce is recoverable, the nonce is replayable. Storing the very data that proves security destroys it.

The act of proving cryptographic integrity must not compromise the cryptographic material it seeks to validate. This is the foundational constraint of zero-knowledge audit design.

This is the compliance paradox. Prove the provenance without exposing the material. PasskeyBridge's NF-07 Entropy Audit Pool resolves it.

NF-07

The Entropy Audit Pool is a subsystem within PasskeyBridge's QRNG-DRBG architecture that logs every entropy seeding event in a way that is verifiable by auditors but useless to attackers.

The mechanism is straightforward:

1. Quantum entropy is fetched from the four-tier provider hierarchy: Outshift (Cisco quantum hardware), QCi uQRNG (photonic quantum hardware), ANU QRNG (prototyping fallback), or local CSPRNG (emergency fallback).

1. Local CSPRNG entropy is XOR-mixed into the quantum seed. This guarantees uniqueness even if the upstream QRNG provider returns stale or cached values. The mixed seed is the actual cryptographic material used downstream.

1. The mixed seed is hashed with SHA-384. The hash is the only artifact that persists. The mixed seed itself becomes the AES-256 key for the counter-mode generator and is never written anywhere.

1. The hash, provider, seed size, health-test results and timestamp are written to the shield_entropy_pool table. No raw entropy is stored. No user identifier is attached. No session context is recorded.

A database trigger links each new row into PasskeyBridge's hash chain, so a row that is altered or removed later breaks the chain. The result is an append-only ledger of entropy provenance events that answers "where did the entropy come from?" and "when?" without answering "what was the entropy?"

Entropy Audit Record:
  raw_entropy_hash:  "a7c3f8...d91e"  (SHA-384 of mixed seed)
  source_provider:   "outshift_qrng"
  seed_size_bits:    256
  metadata:
    reseeded_at:     "2026-03-13T14:22:07.341Z"
    reseed_reason:   "interval_or_count"
    health_tests:    { SP 800-90B repetition count and adaptive proportion results }

An auditor can verify that quantum-sourced entropy was used at a specific time. An attacker who obtains this record learns nothing about the actual key material.

The four-tier verification chain

The audit trail does not simply log that "entropy was used." It records which tier of the quantum entropy hierarchy provided the seed, creating a verifiable provenance chain that maps directly to the platform's cryptographic assurance levels.

Each source_provider value in the audit record is a verifiable claim about the entropy's origin. An auditor reviewing the shield_entropy_pool table can immediately determine:

• What percentage of entropy events used quantum sources vs. classical fallback
• Whether failover events occurred (Tier 1 unavailable, fell to Tier 2)
• How often reseeding happens (a background refresh after 60 seconds or 1,000 requests, and a blocking reseed after 5 minutes or 5,000 requests, whichever comes first)
• Whether the system has ever operated in degraded mode (CSPRNG fallback entries)

This is the difference between claiming "we use quantum randomness" and proving it with an auditable record.

SHA-384 rather than SHA-256

The entropy hash uses SHA-384, departing from the SHA-256 used elsewhere in the platform. This is a deliberate design choice for two reasons:

1. Collision resistance margin: SHA-384 provides 192 bits of collision resistance vs. SHA-256's 128 bits. For an audit record that must remain valid across decades of regulatory retention requirements, the additional margin is warranted.

1. Distinct hash family: Using a different hash length from the operational 256-bit hashes (HMAC-SHA-256 phone and fingerprint hashes under a server-held pepper, SHA-256 nonce hashes) creates a clear separation between audit artifacts and operational artifacts. An auditor or forensic analyst can immediately distinguish an entropy provenance hash from a user-facing hash by its length alone. This is an ergonomic decision rather than a cryptographic one, but it reduces confusion in incident response.

The re-seeding discipline

The QRNG-DRBG does not seed once and run indefinitely. Each running instance of the generator reseeds on these rules:

• Time-based: once 60 seconds have passed since the last seed
• Count-based: once 1,000 output requests have been served since the last seed
• The reseed happens at the next draw after either threshold is reached, with the fresh seed fetched in the background

Each seed generates a new audit record. An instance that serves no requests does not reseed, and each edge-function instance keeps its own generator, so the table records the seeds that were actually used rather than one entry per minute.

The reseed limits borrow the idea of a reseed interval from NIST SP 800-90A. The generator is AES-256 in counter mode keyed directly with the mixed seed. It is not a validated SP 800-90A CTR_DRBG, and the 1,000-request limit is far below the limits that standard sets.

Zero-PII by construction

The Entropy Audit Pool stores no personally identifiable information by construction, not by policy. This distinction matters.

A system that stores PII and then applies access controls is "zero-PII by policy." The data exists; the controls prevent unauthorized access. If the controls fail, the data is exposed.

A system that never receives PII in the first place is "zero-PII by construction." There is no data to expose because no data was stored.

The shield_entropy_pool table contains:

• raw_entropy_hash: SHA-384 of mixed entropy. It cannot be reversed or linked to any user.
• source_provider: Which QRNG tier provided the seed. No user context.
• seed_size_bits: Always 256. A constant.
• metadata: Reseed timestamp, reason and health-test results. No user identifiers, no session IDs, no IP addresses.
• tenant_id: The organizational tenant. Not a user identifier.
• consumed, consumed_at and expires_at: Bookkeeping for the seed itself. expires_at defaults to one minute after the row is written and marks when the seed stops being usable; rows are not deleted when it passes.
• entropy_bits_per_byte: An optional quality figure from providers that report one.

There is no column in this table that can identify, directly or indirectly, any natural person. The record is about the system's behavior and never any user's. This is zero-PII architecture applied to infrastructure audit, not just application data.

Auditor artifacts

When a SOC 2 Type II auditor, an ISO 27001 assessor, or a regulatory examiner requests evidence of cryptographic controls, PasskeyBridge produces three artifacts from the Entropy Audit Pool:

1. Provider distribution report

A summary of source_provider values over the audit period, showing the share of entropy events from each tier and every fallback to the local CSPRNG.

2. Reseed timeline

A chronological view of seed events. Gaps longer than 60 seconds are expected when an instance is idle, because a reseed happens only at the next draw.

3. Health-test results

Each accepted seed carries the results of the SP 800-90B Repetition Count and Adaptive Proportion tests run on that draw, and draws that failed are rejected before use. The optional entropy_bits_per_byte field is filled only when a provider reports a quality figure, and no production record has one so far.

None of these artifacts contain raw entropy, user data, or any material that could be used to reconstruct cryptographic keys.

The regulatory alignment

The NF-07 Entropy Audit Pool maps directly to specific regulatory and compliance frameworks:

• SOC 2 Trust Service Criteria CC6.1: Logical access security controls, including cryptographic key management. The audit pool is evidence of where the randomness behind nonces came from. PasskeyBridge's SOC 2 work is readiness; no audit is scheduled.
• ISO/IEC 27001:2022 Annex A control 8.24 (Use of cryptography; Annex A.10 in the 2013 edition): the provenance records show the origin and health-test results of the entropy in use.
• NIST SP 800-90B: the Repetition Count and Adaptive Proportion health tests run on every draw. The generator itself borrows its reseed limits from SP 800-90A but is not a validated SP 800-90A DRBG.
• FIPS 140-3: PasskeyBridge does not claim FIPS 140-3 validation for its edge-function runtime or for this generator.

The XOR mixing guarantee

A subtle but critical detail: the QRNG-DRBG always XOR-mixes the quantum seed with locally generated CSPRNG entropy before use. This provides a defense-in-depth guarantee:

mixed_seed = quantum_seed XOR local_csprng_entropy

AES-CTR key = import(mixed_seed)

Even if a quantum entropy provider is compromised and returns predictable or attacker-controlled values, the XOR with independent local CSPRNG output keeps the mixed seed at least as unpredictable as the local CSPRNG. The audit record captures the hash of the mixed seed in place of the raw quantum bytes, so the provenance record reflects the actual cryptographic material in use.

This is why the audit classification distinguishes between quantum-sourced and classical fallback but does not claim that the system is "purely quantum." The system is quantum-enhanced and classically guaranteed. The audit trail reflects this reality honestly.

Building for future regulators

Most identity platforms treat compliance as a checkbox exercise. They generate logs, apply retention policies, and hope the auditor does not ask difficult questions about entropy sourcing.

In PasskeyBridge the NF-07 Entropy Audit Pool is written by the QRNG-DRBG itself each time it takes a seed, so the audit records come from normal operation rather than from a separate logging step.

When an assessor asks where the entropy behind a nonce came from, the answer is a row in the pool: a timestamp, a provider, a SHA-384 digest and the health-test results, with no personal data in it.

Explore the QRNG Architecture → | Read the PQC Deep Dive → | Start building →

Start free · Test the API