Weryfikowalny czas i integralność w systemie, który nie widzi treści
Compliance na samych szyfrogramach i skrótach: wieloźródłowe dowody czasu, łańcuch audytu odporny na manipulację i zastępcze skanowanie przy szyfrowaniu E2E — z opublikowanym wynikiem negatywnym o antywirusie serwerowym.
Koch Laboratory — weryfikowalny czas i integralność w systemie, który nie widzi treści
Ten kierunek bierze na warsztat sprzeczność wpisaną w każdy „bezpieczny” system zarządzania dokumentami: wymogi zgodności (znakowanie czasem, dziennik audytu, zastępcze skanowanie, retencja) zakładają, że system coś wie o dokumentach — a szyfrowanie po stronie klienta zakłada, że serwer nie wie nic. Program badawczy pyta, ile z obowiązków compliance da się zrealizować na samych szyfrogramach i skrótach, gdzie przebiega twarda granica tej redukcji i co ta granica wymusza w architekturze. Część wyników jest negatywna — i te publikujemy w pierwszej kolejności.
Metodyka. Jak w reszcie laboratorium: problem → hipoteza → falsyfikowalne kryterium → metoda → wynik z warunkami brzegowymi. Weryfikowalność rozumiana jest dosłownie: dowody mają być sprawdzalne narzędziami trzecimi, nie deklaracją systemu.
1. Wiarygodny czas bez zaufania do własnego zegara
Pytanie badawcze. Jak wystawić dowód istnienia dokumentu w czasie, któremu można wierzyć, mimo że zegar własnego serwera jest z definicji niewiarygodny (awaria, dryf, manipulacja) — i tak, by dowód dało się zweryfikować offline, bez udziału systemu, który go wystawił? Dlaczego to trudne. Pojedyncze źródło czasu to pojedynczy punkt zaufania; wiele źródeł to problem konsensusu (rozjazdy, niedostępność, źródła podpisane kryptograficznie vs niepodpisane). Do tego wymóg prywatności: dowód nie może ujawniać treści dokumentu — wolno mu widzieć wyłącznie skróty. Stan techniki (publikowany). RFC 3161 (TSA) z zewnętrznymi urzędami znakowania; protokół Roughtime; weryfikacja odpowiedzi standardowym OpenSSL. Żądania znacznika budowane są na minimalnym, własnoręcznie kontrolowanym kodowaniu DER — struktura żądania jest standardem, nie wynalazkiem; wynalazku nie ma i nie jest deklarowany. Kryterium sukcesu (testowane). Dowód zawiera artefakty weryfikowalne narzędziami trzecimi; skrót dokumentu jest kryptograficznie związany z odpowiedzią urzędu; degradacja źródeł jest jawna — dowód deklaruje, czy oparto go o źródła podpisane, czy o słabszy fallback. Konstrukcja (reguła konsensusu wielu źródeł, zakresy wiązania skrótów, drabina degradacji): wstrzymana (otwarta opcja patentowa). Wynik negatywny (publikowany). Pierwsza architektura oparta o Roughtime jako źródło podstawowe okazała się operacyjnie niestabilna (dostępność i utrzymanie klienta) i została wycofana w całości na rzecz TSA jako źródła podstawowego z Roughtime w roli wzmocnienia. Udokumentowane przeprojektowanie, nie „feature”. Status: zaimplementowane + testy.
2. Dziennik audytu odporny na manipulację — per najemca, pod współbieżnością
Pytanie badawcze. Jak zbudować dziennik zdarzeń, którego nie da się po fakcie ani przepisać, ani przerzedzić — w systemie wielonajemczym, gdzie zapisy tego samego łańcucha powstają współbieżnie, a dane przechodzą migracje? Dlaczego to trudne. Wiązanie skrótami (hash-chain) jest proste na papierze; trudne są warunki brzegowe: deterministyczna kanonizacja wpisu (ta sama treść musi dawać ten sam skrót po latach i po migracji), porządek wpisów przy równoczesnych zapisach, separacja łańcuchów najemców oraz to, by weryfikacja była operacją rutynową (cykliczną), a nie śledztwem. Stan techniki (publikowany). Łańcuchy skrótów i dzienniki tylko-do-dopisywania; wymagania GoBD / IDW PS 880 dla niezmienności zapisów księgowych; magazyn WORM (Object Lock) jako warstwa retencji. Kryterium sukcesu (testowane). Każda modyfikacja lub usunięcie wpisu jest wykrywalne przy najbliższej weryfikacji łańcucha; wpisy są niemodyfikowalne na poziomie aplikacji; weryfikacja przebiega automatycznie w stałym rytmie i rozdziela najemców. Status: zaimplementowane + testy; twardość porządku wpisów przy skrajnej współbieżności — w walidacji (otwarta niepewność techniczna programu, nie deklarowana jako domknięta).
3. Zastępcze skanowanie (BSI TR-03138) w systemie, który nie widzi skanu
Pytanie badawcze. Czy prawnie istotny proces zastępczego skanowania — z kontrolą jakości, zasadą czworga oczu, protokołem i dopiero potem zniszczeniem oryginału papierowego — da się przeprowadzić tak, by serwer nigdy nie widział treści zeskanowanego dokumentu? Dlaczego to trudne. TR-03138 zakłada audytowalny proces wokół treści (jakość skanu, kompletność), a architektura zero-knowledge odbiera serwerowi dostęp do tej treści. Trzeba rozstrzygnąć, które ogniwa procesu wolno przenieść na stronę klienta, a co serwer może poświadczać wyłącznie na poziomie metadanych i skrótów — nie tracąc wartości dowodowej protokołu. Stan techniki (publikowany). BSI TR-03138 (RESISCAN) i dokumentacja proceduralna GoBD (Verfahrensdokumentation); nieodwołalna retencja WORM po zatwierdzeniu. Kryterium sukcesu. Protokół skanowania jest kompletny i niezmienny po zatwierdzeniu; migawka metadanych jest związana skrótem; zatwierdzenie pociąga za sobą automatyczną blokadę retencyjną; żaden krok nie wymaga ujawnienia treści serwerowi. Konstrukcja (maszyna stanów zatwierdzeń, reguły ról i wyjątków, sprzężenie protokołu z blokadą WORM): wstrzymana. Status: zaimplementowane / w walidacji.
4. Wynik negatywny (publikowany): antywirus serwerowy w architekturze zero-knowledge
Teza. Skanowanie antywirusowe po stronie serwera jest w tej architekturze bezcelowe i szkodliwe: serwer przechowuje wyłącznie szyfrogramy, więc skaner nie ma czego analizować, a fałszywy alarm (kwarantanna/usunięcie) niszczyłby jedyną kopię szyfrogramu — czyli sam stawałby się wektorem utraty danych. Magazyn dokumentów został świadomie wyłączony spod AV; skanowanie ma sens dopiero na jawnie plaintextowych ścieżkach wejścia, jeśli takie powstaną. Szerszy wniosek graniczny. Ten sam konflikt wraca wszędzie, gdzie regulacja wymaga od systemu widzenia treści (np. integracje fakturowe wymagające plaintextu po stronie serwera): czysty model zero-knowledge nie domyka się wtedy bez wydzielonego, jawnie oznaczonego toru o innym modelu zaufania. To rozgraniczenie — gdzie zero-knowledge kończy się z przyczyn prawnych, nie technicznych — jest wynikiem programu. Status: zamknięte (wynik negatywny, publikowany); decyzja architektoniczna udokumentowana.