Verifizierbare Zeit und Integrität in einem System, das die Inhalte nicht sieht
Compliance allein auf Chiffraten und Hashes: Mehrquellen-Zeitnachweise, eine manipulationsevidente Audit-Kette und ersetzendes Scannen unter Ende-zu-Ende-Verschlüsselung — samt eines veröffentlichten negativen Ergebnisses zum serverseitigen Virenschutz.
Koch Laboratory — verifizierbare Zeit und Integrität in einem System, das die Inhalte nicht sieht
Diese Richtung nimmt sich den Widerspruch vor, der in jedem „sicheren” Dokumentenmanagement steckt: Compliance-Pflichten (Zeitstempelung, Audit-Protokoll, ersetzendes Scannen, Aufbewahrung) setzen voraus, dass das System über die Dokumente etwas weiß — clientseitige Verschlüsselung setzt voraus, dass der Server nichts weiß. Das Forschungsprogramm fragt, wie viel der Compliance-Pflichten sich allein auf Chiffraten und Hashes erfüllen lässt, wo die harte Grenze dieser Reduktion verläuft und was diese Grenze der Architektur aufzwingt. Ein Teil der Ergebnisse ist negativ — und diese veröffentlichen wir zuerst.
Methodik. Wie im übrigen Labor: Problem → Hypothese → falsifizierbares Kriterium → Methode → Ergebnis mit Randbedingungen. Verifizierbarkeit ist wörtlich gemeint: Nachweise müssen mit Drittwerkzeugen prüfbar sein, nicht per Erklärung des Systems.
Publikationshinweis (IP). Für patentfähige Richtungen veröffentlichen wir Problem, Stand der Technik und Erfolgskriterium — nicht die Lösungskonstruktion. Wo „Konstruktion: zurückgehalten” steht, wird das technische Detail als Anmeldematerial vorgehalten.
1. Glaubwürdige Zeit ohne Vertrauen in die eigene Uhr
Forschungsfrage. Wie stellt man einen glaubwürdigen Existenznachweis eines Dokuments in der Zeit aus, obwohl die Uhr des eigenen Servers per Definition unglaubwürdig ist (Ausfall, Drift, Manipulation) — und zwar so, dass der Nachweis offline prüfbar ist, ohne Mitwirkung des Systems, das ihn ausgestellt hat? Warum schwierig. Eine einzelne Zeitquelle ist ein einzelner Vertrauenspunkt; mehrere Quellen sind ein Konsensproblem (Abweichungen, Nichtverfügbarkeit, kryptographisch signierte vs. unsignierte Quellen). Hinzu kommt die Privatsphäre-Anforderung: Der Nachweis darf den Dokumentinhalt nicht offenlegen — er darf ausschließlich Hashes sehen. Stand der Technik (veröffentlicht). RFC 3161 (TSA) mit externen Zeitstempelstellen; das Roughtime-Protokoll; Prüfung der Antworten mit Standard-OpenSSL. Die Stempel-Anfragen werden auf einer minimalen, selbst kontrollierten DER-Kodierung aufgebaut — die Struktur der Anfrage ist Standard, keine Erfindung; eine solche wird auch nicht beansprucht. Erfolgskriterium (getestet). Der Nachweis enthält mit Drittwerkzeugen prüfbare Artefakte; der Dokument-Hash ist kryptographisch an die Antwort der Stelle gebunden; die Degradation der Quellen ist offengelegt — der Nachweis deklariert, ob er auf signierten Quellen oder einem schwächeren Fallback beruht. Konstruktion (Konsensregel mehrerer Quellen, Hash-Bindungsbereiche, Degradationsleiter): zurückgehalten (offene Patentoption). Negatives Ergebnis (veröffentlicht). Die erste Architektur mit Roughtime als Primärquelle erwies sich als operativ instabil (Verfügbarkeit, Client-Wartung) und wurde vollständig zurückgebaut — zugunsten von TSA als Primärquelle mit Roughtime als Verstärkung. Ein dokumentiertes Redesign, kein „Feature”. Status: implementiert + Tests.
2. Manipulationsevidentes Audit-Protokoll — pro Mandant, unter Nebenläufigkeit
Forschungsfrage. Wie baut man ein Ereignisprotokoll, das sich nachträglich weder umschreiben noch ausdünnen lässt — in einem mandantenfähigen System, in dem Einträge derselben Kette nebenläufig entstehen und Daten Migrationen durchlaufen? Warum schwierig. Hash-Verkettung ist auf dem Papier einfach; schwierig sind die Randbedingungen: deterministische Kanonisierung des Eintrags (derselbe Inhalt muss nach Jahren und nach Migrationen denselben Hash ergeben), die Ordnung der Einträge bei gleichzeitigen Schreibvorgängen, die Trennung der Mandantenketten — und dass die Prüfung eine Routineoperation (zyklisch) ist, keine Ermittlung. Stand der Technik (veröffentlicht). Hash-Ketten und Append-only-Protokolle; GoBD- / IDW-PS-880-Anforderungen an die Unveränderbarkeit; WORM-Speicher (Object Lock) als Aufbewahrungsschicht. Erfolgskriterium (getestet). Jede Änderung oder Löschung eines Eintrags ist bei der nächsten Kettenprüfung erkennbar; Einträge sind auf Anwendungsebene unveränderlich; die Prüfung läuft automatisch in festem Rhythmus und trennt die Mandanten. Status: implementiert + Tests; die Härte der Eintragsordnung unter extremer Nebenläufigkeit — in Validierung (offene technische Unsicherheit des Programms, nicht als abgeschlossen deklariert).
3. Ersetzendes Scannen (BSI TR-03138) in einem System, das den Scan nicht sieht
Forschungsfrage. Lässt sich ein rechtlich relevanter Prozess des ersetzenden Scannens — mit Qualitätskontrolle, Vier-Augen-Prinzip, Protokoll und erst danach Vernichtung des Papieroriginals — so führen, dass der Server den Inhalt des gescannten Dokuments nie sieht? Warum schwierig. TR-03138 setzt einen auditierbaren Prozess um den Inhalt voraus (Scanqualität, Vollständigkeit), die Zero-Knowledge-Architektur entzieht dem Server genau diesen Inhalt. Zu entscheiden ist, welche Prozessglieder auf die Clientseite verlagert werden dürfen und was der Server ausschließlich auf Ebene von Metadaten und Hashes bezeugen kann — ohne den Beweiswert des Protokolls zu verlieren. Stand der Technik (veröffentlicht). BSI TR-03138 (RESISCAN) und die GoBD-Verfahrensdokumentation; unwiderrufliche WORM-Aufbewahrung nach der Bestätigung. Erfolgskriterium. Das Scanprotokoll ist nach der Bestätigung vollständig und unveränderlich; der Metadaten-Snapshot ist per Hash gebunden; die Bestätigung zieht automatisch die Aufbewahrungssperre nach sich; kein Schritt erfordert die Offenlegung des Inhalts gegenüber dem Server. Konstruktion (Bestätigungs-Zustandsmaschine, Rollen- und Ausnahmeregeln, Kopplung Protokoll↔WORM-Sperre): zurückgehalten. Status: implementiert / in Validierung.
4. Negatives Ergebnis (veröffentlicht): serverseitiger Virenschutz in einer Zero-Knowledge-Architektur
These. Serverseitiges Virenscannen ist in dieser Architektur zwecklos und schädlich: Der Server speichert ausschließlich Chiffrate, der Scanner hat also nichts zu analysieren — und ein Fehlalarm (Quarantäne/Löschung) würde die einzige Kopie des Chiffrats vernichten, der Schutzmechanismus würde selbst zum Datenverlust-Vektor. Der Dokumentenspeicher wurde bewusst vom Virenschutz ausgenommen; Scannen ergibt erst auf explizit plaintextigen Eingangspfaden Sinn, falls solche entstehen. Breiteres Grenzergebnis. Derselbe Konflikt kehrt überall wieder, wo Regulierung vom System das Sehen des Inhalts verlangt (z. B. Rechnungsintegrationen, die serverseitigen Plaintext erfordern): Das reine Zero-Knowledge-Modell schließt sich dann aus rechtlichen, nicht technischen Gründen nicht — ohne eine abgetrennte, offen gekennzeichnete Spur mit anderem Vertrauensmodell. Diese Abgrenzung ist ein Ergebnis des Programms. Status: abgeschlossen (negatives Ergebnis, veröffentlicht); Architekturentscheidung dokumentiert.