Verifiable time and integrity in a system that cannot see the content
Compliance on ciphertexts and hashes alone: multi-source time proofs, a tamper-evident audit chain and replacement scanning under end-to-end encryption — including a published negative result on server-side antivirus.
Koch Laboratory — verifiable time and integrity in a system that cannot see the content
This direction tackles the contradiction built into every “secure” document management system: compliance duties (timestamping, audit trail, replacement scanning, retention) assume the system knows something about the documents — client-side encryption assumes the server knows nothing. The research program asks how much of the compliance burden can be discharged on ciphertexts and hashes alone, where the hard limit of that reduction lies, and what that limit forces on the architecture. Some of the results are negative — and those we publish first.
Method. As in the rest of the lab: problem → hypothesis → falsifiable criterion → method → result with boundary conditions. Verifiability is meant literally: proofs must be checkable with third-party tools, not by the system’s own declaration.
Publication note (IP). For patentable directions we publish the problem, the state of the art and the success criterion — not the solution’s construction. Where “Construction: withheld” appears, the technical detail is retained as filing material.
1. Credible time without trusting one’s own clock
Research question. How do you issue a credible proof that a document existed at a point in time, given that your own server’s clock is untrustworthy by definition (failure, drift, manipulation) — and do it so the proof verifies offline, without the issuing system’s participation? Why it is hard. A single time source is a single point of trust; multiple sources are a consensus problem (divergence, unavailability, cryptographically signed vs unsigned sources). Add the privacy requirement: the proof must not disclose document content — it may only ever see hashes. State of the art (published). RFC 3161 (TSA) with external timestamping authorities; the Roughtime protocol; verification of responses with standard OpenSSL. Timestamp requests are built on a minimal, self-controlled DER encoding — the request structure is a standard, not an invention, and none is claimed. Success criterion (tested). The proof carries artifacts verifiable with third-party tools; the document hash is cryptographically bound to the authority’s response; source degradation is explicit — the proof declares whether it rests on signed sources or on a weaker fallback. Construction (multi-source consensus rule, hash-binding scopes, degradation ladder): withheld (patent option kept open). Negative result (published). The first architecture, with Roughtime as the primary source, proved operationally unstable (availability, client maintenance) and was removed entirely in favour of TSA as primary with Roughtime as reinforcement. A documented redesign, not a “feature”. Status: implemented + tests.
2. Tamper-evident audit trail — per tenant, under concurrency
Research question. How do you build an event log that can be neither rewritten nor thinned out after the fact — in a multi-tenant system where entries of the same chain are written concurrently and the data undergoes migrations? Why it is hard. Hash chaining is simple on paper; the boundary conditions are not: deterministic canonicalization of an entry (the same content must hash identically years later and across migrations), entry ordering under concurrent writes, separation of tenants’ chains, and making verification a routine (periodic) operation rather than an investigation. State of the art (published). Hash chains and append-only logs; GoBD / IDW PS 880 requirements for record immutability; WORM storage (Object Lock) as the retention layer. Success criterion (tested). Any modification or deletion of an entry is detectable at the next chain verification; entries are immutable at the application level; verification runs automatically on a fixed cadence and separates tenants. Status: implemented + tests; hardness of entry ordering under extreme concurrency — in validation (an open technical uncertainty of the program, not declared closed).
3. Replacement scanning (BSI TR-03138) in a system that cannot see the scan
Research question. Can a legally significant replacement-scanning process — quality control, four-eyes principle, a protocol, and only then destruction of the paper original — be run so that the server never sees the content of the scanned document? Why it is hard. TR-03138 assumes an auditable process around the content (scan quality, completeness), while a zero-knowledge architecture removes exactly that content from the server. One must decide which links of the process may move to the client side and what the server can attest purely at the level of metadata and hashes — without losing the protocol’s evidentiary value. State of the art (published). BSI TR-03138 (RESISCAN) and GoBD procedural documentation (Verfahrensdokumentation); irrevocable WORM retention after confirmation. Success criterion. The scanning protocol is complete and immutable once confirmed; the metadata snapshot is hash-bound; confirmation automatically triggers the retention lock; no step requires disclosing content to the server. Construction (confirmation state machine, role and exception rules, protocol↔WORM-lock coupling): withheld. Status: implemented / in validation.
4. Negative result (published): server-side antivirus in a zero-knowledge architecture
Thesis. Server-side antivirus scanning is pointless and harmful in this architecture: the server stores only ciphertexts, so the scanner has nothing to analyse — and a false positive (quarantine/deletion) would destroy the only copy of the ciphertext, turning the protection mechanism itself into a data-loss vector. The document store was deliberately excluded from AV; scanning only makes sense on explicitly plaintext ingestion paths, should they ever exist. Wider boundary conclusion. The same conflict returns wherever regulation requires the system to see content (e.g. invoicing integrations that require server-side plaintext): the pure zero-knowledge model then fails to close for legal, not technical, reasons — unless a separate, openly labelled lane with a different trust model is added. Locating that boundary — where zero-knowledge ends for legal rather than technical reasons — is a result of the program. Status: closed (negative result, published); architectural decision documented.