Cryptographic Integrity

Architectural deep-dive on the multi-anchor + multi-witness substrate that powers Adjudon's audit trail. Complementary to Audit Log & Security (entry-level overview) and Witness Ecosystem (CT-analogy explainer).

Live status (2026-05-11)

Live today: SHA-256 hash chain, RFC 8785 JCS canonicalisation, content-hash content addressing, chain heartbeat verification scheduler, GET /api/audit/verify endpoint, open-source verifier scaffold.

Anchors in mock mode (architecture wired, live activation gated on founder action):

Layer 1 (eIDAS RFC 3161 qualified timestamp via D-Trust GmbH) — services/eidasTimestampService.js:69 returns mock when EIDAS_TSA_PROD env-var unset (commercial contract pending).
Layer 2 (OpenTimestamps Bitcoin) — services/otsAnchorService.js.isLiveMode() returns false when OTS_CALENDAR_PRIMARY unset (env-config gate).
Layer 3 (Trillian Tessera Signed Tree Heads) — Fly.io deployment pending per FOUNDER_ACTION_CHECKLIST gate 7.
Layer 4 (Per-tier qSeal, Enterprise+) — qsealSigner env-gated, requires D-Trust contract.

Until each gate fires, the corresponding layer produces deterministic-mock proofs that preserve chain integrity but do not unlock their respective statutory presumptions. Mocks are clearly marked in the dashboard + verifier output (isMock: true). We document this honestly so procurement does not arrive expecting a live witness layer that does not exist yet.

The cryptographic vs operational gap

Adjudon's audit chain has been operationally append-only since v1 (Cardinal Rule #5: no updateOne, no deleteOne, no chainHash overwrite — enforced by application logic and code review). But operational append-only isn't enough.

A motivated insider with direct MongoDB write access bypasses every Cardinal-Rule-#5 application-level guard, rewrites payload + recomputes chainHash forward to head, and the chain still verifies. The only externally observable trace is mismatch against any party who has previously recorded a head hash — by definition not Adjudon itself.

Without independent witnesses, the chain is not append-only against the chain operator. This is precisely the gap Certificate Transparency closed for HTTPS in 2013 (RFC 6962). The Phase 1 Audit Trail rebuild closes the equivalent gap for AI decision audit trails.

The four-layer architecture

Layer	What it proves	Defends against	EU residency
eIDAS RFC 3161 qualified timestamp (D-Trust GmbH primary, GlobalSign nv-sa fallback)	Document existed at time T; integrity preserved; eIDAS Art. 41(2) statutory presumption	Single-document forgery, backdating	EU-native; Bundesnetzagentur supervised
OpenTimestamps Bitcoin anchor	Merkle root over many leaves existed at block height B	Operator collusion, cross-jurisdictional irreversibility	EDPB Guidelines 02/2025 endorse on-chain hash + off-chain payload
Trillian Tessera CT-style witness (self-hosted Frankfurt + 2+ external EU monitors Phase 2)	Chain consistent across time, no split-view, entries publicly observable	Compromised operator + private collusion with single witness	Self-hostable Frankfurt; external witnesses EU-only
Per-tier qSeal at Enterprise tier (eIDAS Art. 35–40; Phase 3 deliverable)	Anchor itself is a sealed electronic document	Repudiation by Adjudon-as-writer	EU QTSP

The four layers do not substitute for one another. Each closes a distinct attack surface. Verification under EU AI Act Art. 12 / Art. 13 obligations and German civil-procedure §286 ZPO + §371a Abs. 3 ZPO requires only the layers Adjudon publishes plus one independent witness.

The threat model (A1–A6)

The substrate is designed against six adversary scenarios documented in the Methodology v1.0 white paper:

A1 — Insider with direct database write access (closed by OTS Bitcoin + Tessera consortium)
A2 — Compromised single witness operator (closed by M-of-N witness consortium + OTS independence)
A3 — Backdating/forward-dating (closed by eIDAS Art. 41(2) statutory presumption)
A4 — eIDAS TSP failure or coercion (closed by dual-QTSP failover + OTS independence)
A5 — Bitcoin reorg / double-spend (closed by re-submission + QTSP independence)
A6 — Cryptographic primitive failure (closed by ADR-AT-01 schema-version + algoSuite tagging)

Implementation status

Service	Status
Daily Merkle anchor	Existing (Sprint E.c hardened)
eIDAS RFC 3161 client	Existing (mock fallback)
OpenTimestamps Bitcoin anchor	Phase 1 NEW (`otsAnchorService` + `otsScheduler`)
Trillian Tessera witness	Live in production (since 2026-05-11). Adjudon-built Tessera personality service running at `https://tessera.adjudon.com`. Two append-only Merkle logs (one per chain namespace) with Ed25519-signed c2sp.org/tlog-checkpoint format. Public verifier key: `tessera.adjudon.com+f64bee39+AdkG8EGhORx/pELSyAqHH1MN2jJfMlaSdUTsZK6pLYn1` (also at adjudon.com/keys/tessera-public.txt).
Continuous heartbeat verifier	Phase 1 NEW (`chainHeartbeat` + `heartbeatScheduler`)
Per-tier qSeal	Phase 3 NEW (`qsealSigner` + `qsealAnchorHook`, env-gated `AUDIT_TRAIL_QSEAL_ENABLED`; live mode requires D-Trust commercial contract). When the live D-Trust API is unreachable, the scheduler logs the failure and skips that day's seal — it does not fall back to a mock seal in live mode, because a mock placeholder that looks real on the dashboard but offers zero §371a Abs. 3 effect would silently downgrade compliance posture. The chain remains intact via layers 1-3.
External witness consortium	Phase 2 deliverable (LD-4)

Verification (for third-party auditors)

A third-party auditor verifying an Adjudon-produced chain claim follows the procedure documented in AUDIT_TRAIL_METHODOLOGY_V1.md §10:

Per-event verification (chainHash + payloadDigest recomputation)
Daily anchor verification (RFC 6962 Merkle root recomputation)
RFC 3161 qualified timestamp verification (TSA cert against EU LOTL)
OpenTimestamps Bitcoin verification (SPV proof against canonical chain)
Tessera witness verification (STH signature + inclusion proof)

The Phase 3 open-source adjudon-verify CLI executes all five steps in sequence for the requested chain range.

The cryptographic vs operational gap​

The four-layer architecture​

The threat model (A1–A6)​

Implementation status​

Verification (for third-party auditors)​

Further reading​

The cryptographic vs operational gap

The four-layer architecture

The threat model (A1–A6)

Implementation status

Verification (for third-party auditors)

Further reading