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 verify that its key generation meets NIST SP 800-90A requirements. 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 raw seed is used to derive the AES-CTR-DRBG key and is then discarded from memory.

1. The hash, provider identity, seed size, 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.

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"

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 frequently reseeding happens (every 60 seconds or every 1,000 DRBG requests, whichever comes first)
• Whether the system has ever operated in degraded mode (consecutive 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 SHA-256 hashes (phone hashes, fingerprint hashes, 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. It enforces a strict re-seeding discipline:

• Time-based: Re-seed every 60 seconds, regardless of request volume
• Count-based: Re-seed after every 1,000 DRBG output requests, regardless of elapsed time
• Whichever threshold is reached first triggers the reseed

Each reseed event generates a new audit record. This means the shield_entropy_pool table contains a continuous, timestamped chain of entropy provenance events that documents the system's cryptographic hygiene over its entire operational lifetime.

For SOC 2 Type II auditors, the entropy pool is a complete, unbroken chain of evidence with no sampling, showing that the system's randomness sources operated within specification for every minute of the audit period.

The re-seeding discipline also serves a cryptographic purpose beyond auditability. NIST SP 800-90A requires that DRBGs be reseeded before their output reaches a threshold where statistical bias could accumulate. The 1,000-request limit is well below the theoretical output limit of AES-CTR-DRBG, providing a conservative margin that satisfies even the most stringent interpretations of the standard.

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 and reason. No user identifiers, no session IDs, no IP addresses.
• tenant_id: The organizational tenant. Not a user identifier.
• expires_at: Retention expiry for automatic cleanup.

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 percentage of entropy events sourced from each tier. A healthy system shows >99% quantum-sourced (Tier 1 or Tier 2) with rare or zero classical fallback events.

2. Reseed continuity timeline

A chronological view of reseed events demonstrating that the DRBG was never operated beyond its reseeding limits. Any gap longer than 60 seconds between reseed events would indicate a potential compliance exception, though the system's architecture prevents this by design.

3. Entropy quality attestation

The entropy_bits_per_byte field, when populated by providers that report quality metrics, gives auditors a quantitative measure of the randomness quality. True quantum sources consistently produce values near the theoretical maximum of 8.0 bits per byte. Degraded or classical sources produce lower values.

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 demonstrates that keys are derived from verified entropy sources.
• ISO 27001 Annex A.10: Cryptographic controls. The provenance chain proves that the organization's cryptographic implementation uses entropy of known quality and origin.
• NIST SP 800-90A: Recommendations for random number generation. The reseed discipline, XOR mixing, and AES-CTR-DRBG implementation follow the specification, and the audit pool provides the evidence.
• FIPS 140-3: Cryptographic module validation. While PasskeyBridge does not claim FIPS 140-3 certification for its edge-function runtime, the entropy management practices align with the standard's requirements for entropy sources and DRBG operation.
• SEC Reg S-ID / MiFID II: Identity verification requirements that depend on the integrity of the underlying cryptographic stack. The audit pool provides downstream evidence that the identity verification pipeline is built on sound cryptographic foundations.

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, returning predictable or attacker-controlled values, the XOR mixing with independent local CSPRNG entropy ensures the resulting seed retains at least the entropy of the local source. 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.

PasskeyBridge treats compliance as an engineering discipline. The NF-07 Entropy Audit Pool is an integral component of the QRNG-DRBG rather than a log bolted onto the side of the system, and it generates audit artifacts as a natural byproduct of correct operation.

The pool exists because the regulators of tomorrow will ask questions that the regulators of today have not yet formulated. When a FIPS 140-3 assessor asks for entropy provenance, when a quantum computing advisory board asks for evidence of quantum readiness, when a post-quantum migration audit requires proof that classical and quantum entropy sources were managed correctly during the transition, the answers will already be in the audit pool. Timestamped. Hashed. Verifiable. And containing exactly zero pieces of personally identifiable information.

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

Start free · Test the API