# Koch Laboratory - Wydruk sprawdzany wiersz po wierszu: pięć obalonych założeń i pierwsze pomiary · Forschungsportfolio / Portfolio badawcze / Research Portfolio > **Zasada publikacji.** Wyniki, kryteria i warunki pomiaru są jawne; sposób odczytu, budowa kodu i progi pozostają wstrzymane. > **Zasada uczciwości.** To pierwszy wpis tej linii badawczej; wyniki negatywne podajemy pierwsze i z liczbami. Gdzie wniosek pochodzi z analizy, a nie z pomiaru, mówimy to wprost. --- --- # 🇵🇱 WERSJA POLSKA ## Koch Laboratory - wydruk sprawdzany wiersz po wierszu: pięć obalonych założeń i pierwsze pomiary Dokument wydany jako PDF żyje dalej jako wydruk, skan albo zdjęcie telefonem. Czy kwota, data albo numer na takiej kopii to te same znaki, które dokument miał w chwili zapieczętowania, rozstrzyga dziś zwykle człowiek: aplikacja pokazuje dane z kodu na dokumencie, a on porównuje je z wydrukiem. Ta linia badawcza, prowadzona od 31 października 2026, mierzy, czy da się to sprawdzić automatycznie, wiersz po wierszu, ze zwykłego skanu i zdjęcia telefonem, i przy tym nigdy nie uznać uczciwego dokumentu za zmieniony. Wpis podaje wyniki z pierwszych dziesięciu dni listopada 2026: najpierw pięć założeń, które się nie utrzymały, potem wykrywanie zmiany jednego znaku, różnice między skanerem z podajnikiem a telefonem i model testowy z werdyktami ustalonymi przed próbą. **Co tu jest badaniem, a co nie.** Podpisane dane w widocznym kodzie 2D na papierze to dojrzały wzorzec (ICAO VDS, cyfrowa pieczęć BSI, francuski 2D-Doc). Automatyczne sprawdzanie wydruku ze wskazaniem zmienionego fragmentu opisano w latach 2006-2007 (Uniwersytet Genewski), a sprawdzanie wydruku telefonem - m.in. Fraunhofer SIT (2023) i SealClub (ETH Zurych). Treścią badawczą jest pomiar przy twardym kryterium: czy uczciwy znak nigdy nie wychodzi jako zmieniony, ile zmian jednego znaku wykrywa się wtedy na skanie i na zdjęciu, ilu uczciwych znaków obraz nie rozstrzyga i co zniekształca geometrię kartki - oraz założenia, które się przy tym nie utrzymały. Teza dowodowa: weryfikacja wykazuje, że sprawdzone wiersze wydruku są takie, jakie były w chwili pieczęci. Nie wykazuje, że ich treść jest prawdziwa, kto wystawił dokument ani że kartka nie jest kopią. **Metodyka.** Jak w reszcie laboratorium: problem → stan techniki → falsyfikowalne kryterium → metoda → wynik (potwierdzony, obalony albo częściowy, z warunkami brzegowymi) → następny krok. Wynik negatywny jest wynikiem. Fałszywy alarm to uczciwy znak albo wiersz uznany za zmieniony. „Nierozstrzygnięty” znaczy, że obraz nie przesądza: takiego znaku weryfikator nie uznaje ani za zgodny, ani za zmieniony, tylko pokazuje go człowiekowi jako wątpliwy. Liczby pochodzą z notatek pomiarowych i raportów prób z 5-10 listopada 2026. ### 1. Kierunek 1 - pięć założeń, które się nie utrzymały **Problem.** Pierwsze założenia linii - część z koncepcji z 31 października 2026, część z pierwszych dni pracy - nie były sprawdzone. Każde z nich, gdyby było fałszywe, dawałoby albo pozorną ochronę, albo fałszywe alarmy. **Stan techniki (publikowany).** Atak kopiujący: znak ukryty w dokumencie, który nie zależy od treści, można odczytać z chronionego dokumentu i tak samo nanieść na inny, bez znajomości klucza (Voloshynovskiy i in., SPIE 2006). Autokorekta OCR: w doświadczeniach Villána i in. (SPIE 2007) OCR odczytał podrobione słowo „aufhentication” jako „authentication” i fałszerstwo przeszło. BSI TR-03137 (cz. 1, wersja 3.0 z 2026 r., rozdz. 19) opisuje odtwarzanie danych OCR-em odpornym na błędy i zaleca pokazywanie człowiekowi każdego poprawionego znaku. **Kryterium (falsyfikowalne).** Założenie upada, gdy (1) istnieje atak, który je spełnia, a mimo to zmienia treść; (2) rachunek pokazuje efekt mniejszy niż rozdzielczość urządzenia; (3) pomiar w podanych warunkach daje odczyt nieczytelny albo wątpliwy tam, gdzie założenie obiecywało jednoznaczny. **Metoda.** Trzy założenia sprawdziliśmy analizą i rachunkiem: wiązanie treści przez geometrię strony, fizykę druku przy 10 pt i 600 dpi oraz rolę dolnej granicy czasu. Dwa pomiarem: OCR na 12 obrazach strony testowej (skany 150-600 dpi i zdjęcia telefonem, 6.11.2026) oraz trzy fonty o stałej szerokości znaków na renderach PDF tej samej strony przy 150 i 300 dpi (10.11.2026). Sposób odczytu i budowa kodu pozostają wstrzymane. **Wynik.** Żadne z pięciu założeń się nie utrzymało. - **(a) Drobne cechy składu strony, wyliczone z jawnych danych dokumentu, wiążą wydruk z treścią.** Nie wiążą. Kto zna te dane, liczy to samo ziarno, zmienia znak i składa go według niego; sprawdzenie geometrii uzna podróbkę za zgodną. W literaturze to atak kopiujący (Voloshynovskiy i in., 2006). Analiza. - **(b) Mikroprzesunięcia liter o ±0,5-1,5 % ich szerokości niosą bity, które przeżyją druk i skan.** Przy 10 pt to ok. 9-26 µm, a piksel drukarki 600 dpi ma ok. 42 µm. Pojedynczy bit zapisany tak drobnym przesunięciem jest bardzo zawodny. Sygnał statystyczny z wielu par może przetrwać, bo rasteryzacja działa jak dithering, ale tego nie mierzyliśmy. Rachunek, nie pomiar. - **(c) Ogólny OCR może dostarczyć tekst wiersza do sprawdzenia.** W literaturze OCR „poprawia” podróbki (przypadek „aufhentication”, 2007). U nas OCR wbudowany w Windows - na komputerze pomiarowym tylko z pakietem języka polskiego - czytał niemieckie znaki z błędami: „Hauptstrage” zamiast „Hauptstraße”, „Kliche” zamiast „Küche”, „Uber” zamiast „über”, „OO” zamiast „00”. Fałszywej niezgodności nie dał, ale wiersze z niemieckimi znakami często zostawały nieczytelne. Pomiar jednym OCR, bez pakietu niemieckiego. - **(d) W foncie DejaVu Sans Mono kropkowane zero odróżnia 0 od O.** Przy 10 pt kropka jest za mała. Ta sama strona w trzech fontach: DejaVu Sans Mono dał 14 wątpliwych znaków przy 150 dpi (6/G, 0/O, t/f, B/D) i 10 przy 300 dpi (wszystkie 0/O), JetBrains Mono i Cascadia Mono - po 0. Z jednym z tych dwóch fontów nowe dokumenty mają przy 300 dpi wszystkie wiersze zgodne, a przy 150 dpi jeden wątpliwy znak na dokument (S/5, g/q); wcześniej 4-7 wątpliwych wierszy. Pomiar na renderach PDF, nie na wydrukach. - **(e) Na wydruku wystarczy dolna granica czasu, czyli dowód, że pieczęć nie powstała wcześniej.** Nie wystarczy: kto ma to samo oprogramowanie, może przerobić treść i wydać nową pieczęć z tą samą dolną granicą. Przed tym chroni dopiero górna granica. Analiza; model testowy (kierunek 4) ma na ten przypadek osobną próbę. **Następny krok.** Brak - założenia zamknięte; (b) pozostaje rachunkiem. **Status:** pięć założeń zamkniętych: trzy analizą i rachunkiem, dwa pomiarem. ### 2. Kierunek 2 - zmiana jednego znaku na wydruku: zero fałszywych alarmów i cena w znakach nierozstrzygniętych **Problem.** Najmniejsza zmiana treści to jeden znak: cyfra kwoty albo daty, przecinek zamieniony na kropkę. Czytnik, który ma ją wykryć ze skanu albo zdjęcia, nie może przy tym uznawać uczciwych znaków za zmienione: jeden fałszywy alarm na prawdziwym dokumencie podważa całą weryfikację. Pytanie: ile zmian jednego znaku wykrywa się przy zerze fałszywych alarmów i ilu uczciwych znaków obraz wtedy nie rozstrzyga. **Stan techniki (publikowany).** Prace z Genewy (Voloshynovskiy i in., 2006; Villán i in., 2007) wskazują zmieniony blok tekstu - słowo, wiersz albo akapit - po wydruku, skanie, kserokopii i faksie; w doświadczeniach z 2007 r. wykryto dodanie, usunięcie i zamianę znaku, ale podróbkę „aufhentication” przepuścił OCR. Fraunhofer SIT (Bugert, Heeger, Berchtold, IS&T Electronic Imaging 2023) sprawdza telefonem podpisane bloki tekstu odczytane OCR-em; każdą niezgodność rozstrzyga użytkownik, a praca nie podaje wyników liczbowych. SealClub (Ochoa, Toro-Pozo, Basin, ETH Zurych; arXiv 2022) uwierzytelnia dokument papierowy z krótkiego nagrania telefonem i porównaniem obrazów zaznacza miejsca podejrzane o fałszerstwo. **Kryterium (falsyfikowalne).** Zero fałszywych alarmów: żaden uczciwy znak nie może zostać uznany za zmieniony. Znak, którego obraz nie rozstrzyga, dostaje status „nierozstrzygnięty” i liczy się osobno, jako koszt. Zmieniony znak nie może zostać uznany za zgodny. Kryterium obala jeden fałszywy alarm albo jedna zmiana uznana za zgodną. **Metoda.** Strona testowa na dwóch kartkach A4. Pierwsza to dokument uczciwy. Na drugiej, rachunku, cztery wiersze wydrukowano inaczej, niż je zapieczętowano, każdy z jedną zmianą: przecinek na kropkę, 5 na 8, 3 na 8, 2 na 7; do tego próbki pisma od 7 do 12 pt. Wydruk: drukarka laserowa Samsung Xpress C430W. Skany: HP ScanJet Pro 2000 s2 z podajnikiem; 150, 200, 300 i 600 dpi w kolorze, 300 dpi w JPEG, w czerni i bieli oraz z kartkami obróconymi o 180°. Zdjęcia: Motorola Razr 50 Ultra, cała strona z góry i pod kątem przy słabszym świetle. Pomiar z 5.11.2026: 22 obrazy (18 skanów i 4 zdjęcia). Powtórka z 6.11.2026: 40 obrazów - skany dwóch wydań strony testowej, cztery zdjęcia i rendery PDF przy 150-600 dpi. Werdykty wierszy: 9.11.2026, 60 obrazów z trzech wydań strony, które różnią się tylko kodem (skany, rendery PDF i zdjęcia). Sposób odczytu i budowa kodu pozostają wstrzymane. **Wynik.** Kryterium spełnione. Fałszywe alarmy: 0 na 12 474 sprawdzeniach uczciwych znaków (22 obrazy, 5.11) i 0 na 22 680 uczciwych znakach (40 obrazów, 6.11). Zmiany jednego znaku na skanach: 36 z 36 wykrytych jako zmienione, za każdym razem z poprawnym odczytem tego, co wydrukowano. Na zdjęciach: zmienione cyfry 6 z 6, a przecinek zamieniony na kropkę nierozstrzygnięty w 2 z 2 przypadków, bo na zdjęciu całej strony ogonka przecinka nie widać. Na 40 obrazach wykryto 78 z 80 zmian; dwie pozostałe to ten sam przecinek na zdjęciach, nierozstrzygnięty. Cena: uczciwe znaki nierozstrzygnięte - na skanach 0,5-4 %, prawie wyłącznie pary znaków podobnych w foncie proporcjonalnym (l/I, i/I, j/J, ł/l, kropka i dwukropek); na zdjęciach 2-10 % na pierwszej stronie i 20-29 % na drugiej, gdzie leżą rozmyte drobne próbki 7-9 pt. Werdykty wierszy (60 obrazów): żaden uczciwy wiersz nie wyszedł jako niezgodny ani nieczytelny; zmienione wiersze wyszły jako niezgodne: 4 z 4 na skanach i renderach (27 obrazów) i 3 z 4 na zdjęciach (3 obrazy), gdzie czwarty, z przecinkiem, został nierozstrzygnięty. Warunki brzegowe: (a) czytnik rozwijaliśmy na tych samych obrazach, na których podajemy wynik; jego wcześniejsza wersja dała na renderze 150 dpi jeden fałszywy alarm (kropka w próbce 7 pt), który zniknął po poprawce czytnika - niezależnym sprawdzianem są dopiero nowe dokumenty (kierunek 4) i nowe wydruki; (b) zdjęcie całej strony wystarcza do cyfr, nie do drobnej interpunkcji. **Następny krok.** Próby ręczne na nowym wydruku (kierunek 4). **Status:** kryterium spełnione na obrazach strony testowej, z warunkami (a)-(b); koszt w znakach nierozstrzygniętych zmierzony. ### 3. Kierunek 3 - skaner z podajnikiem a telefon: geometria kartki i czytelność kodów **Problem.** Weryfikacja ma działać ze skanu i ze zdjęcia telefonem. Oba urządzenia zniekształcają kartkę, a czytnik kodów w telefonie nie czyta każdego kodu. Zanim przyjmie się, że skan jest „lepszym zdjęciem”, trzeba zmierzyć, jak duże są te zniekształcenia i skąd pochodzą. **Stan techniki (publikowany).** ICAO Doc 9303, cz. 13 (wyd. 8, 2021) zakłada, że pieczęć sprawdzi nawet osoba bez przeszkolenia tanim sprzętem, np. aplikacją w smartfonie, i dla drukarek atramentowych zaleca moduł kodu co najmniej 0,3386 mm; BSI TR-03137 przyjmuje ten moduł jako wymóg. Fraunhofer SIT (2023) zastrzega, że odporność sprawdzania telefonem silnie zależy od jakości zdjęcia i wyprostowania dokumentu, nie podając liczb. **Kryterium (falsyfikowalne).** Intuicja „skan z podajnika odwzorowuje kartkę wierniej niż zdjęcie z ręki” upada, gdy odchyłka geometrii jest na skanach większa niż na zdjęciach. Odchyłkę przypisujemy podajnikowi, jeśli po obróceniu kartki o 180° zostaje w układzie skanera, a nie strony. Odczyt kodu oceniamy trójstopniowo: szybko, po długim celowaniu, wcale. **Metoda.** Punkty kontrolne rozmieszczone na kartce porównane z położeniem przewidzianym dla płaskiej kartki; odchyłka w milimetrach na papierze. Sprzęt jak w kierunku 2. Skaner: 18 obrazów z 5.11.2026 i dalsze przebiegi z 6.11.2026 na dwóch kolejnych wydrukach. Telefon: 4 zdjęcia całych stron z 5.11.2026 (JPEG 4096 × 3072). Kody 2D: dziewięć wariantów o module od 0,25 do 0,50 mm i różnych poziomach korekcji błędów; czytnik w aparacie telefonu, każdy kod osobno z bliska (5 i 6.11.2026), oraz narzędzie pomiarowe na całych obrazach skanów i zdjęć. Sposób odczytu i budowa kodu pozostają wstrzymane. **Wynik.** Intuicja upada. Skaner z podajnikiem: odchyłka średnio 0,12-0,24 mm na pierwszej kartce i 0,32-0,44 mm na drugiej, najwięcej 0,79 mm. Rośnie wzdłuż przesuwu papieru do ok. 0,7 mm i spada przy końcu kartki. Po obróceniu kartki o 180° zmienia kierunek w układzie strony, a w układzie skanera zostaje taka sama - pochodzi więc z podajnika, nie z drukarki. Między przebiegami zmienia się o ok. ±0,2 mm, a na dwóch kolejnych wydrukach średnie były podobne (0,14-0,21 mm i 0,31-0,37 mm). Telefon: średnio 0,16-0,20 mm, najwięcej 0,29-0,50 mm, przy rozdzielczości na kartce 271-339 dpi; zdjęcie nie ma zniekształcenia przesuwu papieru. Kody: ze skanów 150-600 dpi narzędzie pomiarowe odczytało z całego obrazu wszystkie kody poza najmniejszym przy 150 i 600 dpi; ze zdjęcia całej strony - tylko część, głównie większe. Czytnik w aparacie telefonu czytał szybko kody o mniejszej liczbie modułów, a gęstsze bardzo wolno albo wcale: 5.11 odczytał osiem z dziewięciu wariantów, w tym trzy dopiero po bardzo długim celowaniu; 6.11, gdy kody niosły więcej danych, trzech praktycznie nie odczytał (jeden raz, po bardzo długim celowaniu). Wyniki obu dni nie są w pełni spójne: kod o najniższym poziomie korekcji błędów 5.11 się nie odczytał, 6.11 tak. Kody leżące blisko siebie wymagały długiego celowania, bo czytnik bierze z kadru jeden kod. Wynik negatywny co do narzędzia: jedna z otwartych bibliotek do odczytu kodów czytała wszystkie kody z renderu PDF, a ze skanu 300 dpi tylko 4 z 9, i to dopiero z wyprostowanego wycinka; myliła się też przy ułamkowym rozmiarze modułu na ostrym obrazie. Do pomiaru czytelności jej nie używamy. **Następny krok.** Skany, zdjęcia i kserokopia nowego wydruku w próbach ręcznych (kierunek 4). **Status:** zmierzone 5-6.11.2026. ### 4. Kierunek 4 - model testowy z werdyktami ustalonymi przed próbą **Problem.** Pomiar na stronie testowej sprawdza odczyt, ale nie całą drogę dokumentu - wydanie, kod, czas, weryfikację - ani zachowanie weryfikatora wobec fałszerstw zaplanowanych z góry. Żeby wynik nie dopasował się do tego, co akurat wyszło, oczekiwany werdykt każdej próby trzeba zapisać przed przebiegiem. **Stan techniki (publikowany).** ICAO Doc 9303, cz. 13 określa werdykt pieczęci: ważna albo nieważna, z powodem (m.in. błąd odczytu, nieznany certyfikat, nieważny podpis). Prototyp Fraunhofer SIT (2023) nie podaje wyników liczbowych. Wdrożony format też bywa zawodny: France Titres-ANTS napisała 30 września 2025 r., że 2D-Doc na zawiadomieniach podatkowych z 2025 r. daje błędy przy odczycie, i zaleciła złożenie innego dokumentu. **Kryterium (falsyfikowalne).** Katalog prób z oczekiwanym werdyktem każdej próby i kryteria odbioru przyjęte 10.11.2026, przed przebiegiem: żaden zmieniony wiersz nie dostaje „zgodny” (wyjątek przewidziany z góry: fałszerz, który ma to samo oprogramowanie i wydaje własną pieczęć - wiersze zgadzają się wtedy z jego pieczęcią, a chronią przed nim granice czasu, kierunek 1 (e)); żaden uczciwy wiersz nie dostaje „niezgodny”, a na renderach także „nieczytelny”; każdy fałszywy dowód czasu jest niepotwierdzony, a prawdziwy potwierdzony; złośliwe dane wejściowe nie wywołują awarii ani odrzucenia bez komunikatu. Kryterium obala jedna weryfikacja niezgodna z oczekiwanym werdyktem. **Metoda.** Model w Dockerze z pełną drogą dokumentu: wystawca testowy, prawdziwa kryptografia, testowa usługa czasu zamiast produkcyjnej, weryfikacja tą samą drogą co w przeglądarce. Trzy wzory dokumentów (dwa rodzaje certyfikatów i rachunek), 75 dokumentów, 120 prób, 198 weryfikacji obrazów stron przy 150 i 300 dpi. Fałszerstwa powstają dwojako: jako PDF z innym tekstem niż zapieczętowany i jako zmiana obrazu po renderze (wklejenie, wymazanie, zamiana). Ten sam przebieg na dwóch rendererach PDF: w Windows (Windows.Data.Pdf) i w Dockerze pod Linuksem (poppler 22.12, czysta budowa z repozytorium, bez sieci). Do tego odporność: milion losowych i złośliwych tekstów kodu, 200 tys. złośliwych danych wejściowych weryfikacji, 22 obrazy skrajne (m.in. puste, sam szum, bardzo małe i bardzo duże, obrócone, lustrzane, w negatywie) i 21 przypadków granic formatu, część także w wersji weryfikatora przeznaczonej dla przeglądarki; oraz przegląd, w którym każdy bajt zawartości kodu przerobiono na kilka sposobów, a kod wygenerowano na nowo. Sposób odczytu i budowa kodu pozostają wstrzymane. **Wynik.** 198 z 198 weryfikacji zgodnych z oczekiwanym werdyktem, w obu środowiskach tak samo. Odporność: zero awarii i zero odrzuceń bez komunikatu. Żadna z 5232 przeróbek zawartości kodu nie dała pełnego potwierdzenia. Model znalazł sześć błędów czytnika, których pomiar na obrazach strony testowej nie mógł wykazać, bo tamte obrazy nie zawierały takich przypadków: - zaklejony albo niewydrukowany wiersz dostawał „zgodny z miejscami wątpliwymi”; - jedna cyfra dopisana tuż za wierszem przechodziła jako zgodna; - kod innego dokumentu doklejony obok kodu dokumentu był pomijany, zamiast wywołać odmowę; - obraz w lustrzanym odbiciu, np. z przedniej kamery telefonu, dawał uczciwemu wierszowi „niezgodny”, w przeglądarce po 50 s; - kwota przekreślona kreską 0,35 mm wychodziła przy 300 dpi zgodna; ten błąd znalazła symulacja prób ręcznych na obrazach (po poprawce 28 z 28 zgodnych z oczekiwanym werdyktem); - wiersz ze znakiem „@” wychodził nieczytelny. Wszystkie poprawiliśmy, każdy z testem; na 62 obrazach z wcześniejszych pomiarów (skany, rendery PDF, zdjęcia) statusy wierszy po poprawkach się nie zmieniły. Po pierwszym przebiegu poprawiliśmy też cztery oczekiwane werdykty (10.11.2026) - dwa dotyczyły przerobionego kodu i dopisków w wierszu, dwa sprawdzania czasu. To odstępstwo od reguły „werdykt przed próbą”, więc 198 z 198 to stan po tych poprawkach i po poprawkach czytnika. Znane niedoskonałości: przy 150 dpi wklejona cyfra 8 została odczytana jako „S” (werdykt „niezgodny” był poprawny), a nie każdy drobny dopisek przy znakach interpunkcyjnych jest przy 300 dpi wykrywany. Próby automatyczne to rendery PDF i zmiany obrazu, nie wydruki. Model nie dowodzi braku błędów; daje mierzalny wynik na katalogu prób ustalonym z góry. **Następny krok.** Próby ręczne według gotowej listy: 12 stron, każda jako osobny dokument z własną pieczęcią i oczekiwanym werdyktem - skany, zdjęcia, kserokopia, wydruk w skali, poprawki długopisem i taśmą, doklejone obce kody, na końcu kartka pognieciona. Potem ocena prezentacji werdyktu i niezależny przegląd kodu weryfikacji. **Status:** część automatyczna zakończona 10.11.2026. **Status kierunku.** Zamknięte: pięć założeń z kierunku 1. Zmierzone: wykrywanie zmiany jednego znaku przy zerze fałszywych alarmów, koszt w znakach nierozstrzygniętych, geometria skanera i telefonu oraz czytelność kodów. Model testowy przeszedł część automatyczną: 198 z 198. Ograniczenia pomiaru: jedna drukarka, jeden skaner, jeden telefon i łącznie 8 zdjęć; „podróbki” wydrukował autor. Najbliższe kroki: próby ręczne - poprawki długopisem, kserokopia, wydruk w skali - i niezależny przegląd kodu. --- --- # 🇩🇪 DEUTSCHE FASSUNG ## Koch Laboratory - ein Ausdruck, Zeile für Zeile geprüft: fünf widerlegte Annahmen und erste Messungen Ein als PDF ausgestelltes Dokument lebt als Ausdruck, Scan oder Handyfoto weiter. Ob ein Betrag, ein Datum oder eine Nummer auf einer solchen Kopie dieselben Zeichen sind, die das Dokument im Moment der Versiegelung hatte, entscheidet heute meist ein Mensch: Die App zeigt die Daten aus dem Code auf dem Dokument an, und er vergleicht sie mit dem Ausdruck. Diese Forschungslinie, geführt seit dem 31. Oktober 2026, misst, ob sich das automatisch, Zeile für Zeile, aus einem gewöhnlichen Scan und einem Handyfoto prüfen lässt und dabei ein ehrliches Dokument nie als verändert gilt. Der Eintrag nennt die Ergebnisse aus den ersten zehn Novembertagen 2026: zuerst fünf Annahmen, die sich nicht gehalten haben, dann die Erkennung der Änderung eines einzelnen Zeichens, die Unterschiede zwischen Scanner mit Einzug und Handy und ein Testmodell mit Urteilen, die vor dem Versuch festgelegt wurden. **Was hier Forschung ist und was nicht.** Signierte Daten in einem sichtbaren 2D-Code auf Papier sind ein ausgereiftes Muster (ICAO VDS, das digitale Siegel des BSI, das französische 2D-Doc). Die automatische Prüfung eines Ausdrucks mit Kennzeichnung des veränderten Abschnitts wurde in den Jahren 2006-2007 beschrieben (Universität Genf), die Prüfung eines Ausdrucks mit dem Handy u. a. von Fraunhofer SIT (2023) und SealClub (ETH Zürich). Forschungsgegenstand ist die Messung unter einem harten Kriterium: ob ein ehrliches Zeichen nie als verändert herauskommt, wie viele Änderungen eines einzelnen Zeichens sich dann auf dem Scan und auf dem Foto erkennen lassen, wie viele ehrliche Zeichen das Bild nicht entscheidet und was die Geometrie des Blatts verzerrt - sowie die Annahmen, die sich dabei nicht gehalten haben. Beweisaussage: Die Verifikation zeigt, dass die geprüften Zeilen des Ausdrucks so sind, wie sie im Moment des Siegels waren. Sie zeigt nicht, dass ihr Inhalt wahr ist, wer das Dokument ausgestellt hat oder dass das Blatt keine Kopie ist. **Methodik.** Wie im übrigen Labor: Problem → Stand der Technik → falsifizierbares Kriterium → Methode → Ergebnis (bestätigt, widerlegt oder teilweise, mit Randbedingungen) → nächster Schritt. Ein negatives Ergebnis ist ein Ergebnis. Ein Fehlalarm ist ein ehrliches Zeichen oder eine ehrliche Zeile, die als verändert gilt. „Unentschieden“ bedeutet, dass das Bild nicht entscheidet: Ein solches Zeichen erkennt der Verifizierer weder als übereinstimmend noch als verändert an, sondern zeigt es einem Menschen als zweifelhaft. Die Zahlen stammen aus Messnotizen und Versuchsberichten vom 5.-10. November 2026. ### 1. Richtung 1 - fünf Annahmen, die sich nicht gehalten haben **Problem.** Die ersten Annahmen der Linie - teils aus dem Konzept vom 31. Oktober 2026, teils aus den ersten Arbeitstagen - waren nicht geprüft. Jede von ihnen würde, wäre sie falsch, entweder einen Scheinschutz oder Fehlalarme liefern. **Stand der Technik (veröffentlicht).** Kopierangriff: Ein vom Inhalt unabhängiges, im Dokument verborgenes Zeichen lässt sich aus dem geschützten Dokument auslesen und genauso auf ein anderes übertragen, ohne den Schlüssel zu kennen (Voloshynovskiy et al., SPIE 2006). OCR-Autokorrektur: In den Experimenten von Villán et al. (SPIE 2007) las die OCR das gefälschte Wort „aufhentication“ als „authentication“, und die Fälschung ging durch. BSI TR-03137 (Teil 1, Version 3.0 von 2026, Kap. 19) beschreibt die Wiederherstellung von Daten mit fehlertoleranter OCR und empfiehlt, einem Menschen jedes korrigierte Zeichen zu zeigen. **Kriterium (falsifizierbar).** Die Annahme fällt, wenn (1) ein Angriff existiert, der sie erfüllt und dennoch den Inhalt verändert; (2) die Rechnung einen Effekt zeigt, der kleiner ist als die Auflösung des Geräts; (3) die Messung unter den genannten Bedingungen einen unleserlichen oder zweifelhaften Befund liefert, wo die Annahme einen eindeutigen versprach. **Methode.** Drei Annahmen haben wir durch Analyse und Rechnung geprüft: die Bindung des Inhalts über die Geometrie der Seite, die Physik des Drucks bei 10 pt und 600 dpi sowie die Rolle der unteren Zeitgrenze. Zwei durch Messung: OCR an 12 Bildern der Testseite (Scans mit 150-600 dpi und Handyfotos, 6.11.2026) und drei Schriften mit fester Zeichenbreite an PDF-Renderings derselben Seite bei 150 und 300 dpi (10.11.2026). Die Art des Auslesens und der Aufbau des Codes bleiben zurückgehalten. **Ergebnis.** Keine der fünf Annahmen hat sich gehalten. - **(a) Feine Merkmale des Seitensatzes, berechnet aus offenen Daten des Dokuments, binden den Ausdruck an den Inhalt.** Sie binden ihn nicht. Wer diese Daten kennt, berechnet denselben Startwert, ändert ein Zeichen und setzt es danach; die Prüfung der Geometrie hält die Fälschung für übereinstimmend. In der Literatur ist das der Kopierangriff (Voloshynovskiy et al., 2006). Analyse. - **(b) Mikroverschiebungen von Buchstaben um ±0,5-1,5 % ihrer Breite tragen Bits, die Druck und Scan überstehen.** Bei 10 pt sind das ca. 9-26 µm, und ein Druckerpixel bei 600 dpi misst ca. 42 µm. Ein einzelnes Bit, das mit einer so feinen Verschiebung geschrieben wird, ist sehr unzuverlässig. Ein statistisches Signal aus vielen Paaren kann überleben, weil die Rasterung wie Dithering wirkt, aber das haben wir nicht gemessen. Rechnung, keine Messung. - **(c) Eine allgemeine OCR kann den Text einer Zeile zur Prüfung liefern.** In der Literatur „verbessert“ OCR Fälschungen (der Fall „aufhentication“, 2007). Bei uns las die in Windows eingebaute OCR - auf dem Messrechner nur mit dem polnischen Sprachpaket - deutsche Zeichen fehlerhaft: „Hauptstrage“ statt „Hauptstraße“, „Kliche“ statt „Küche“, „Uber“ statt „über“, „OO“ statt „00“. Eine falsche Nichtübereinstimmung ergab sich nicht, aber Zeilen mit deutschen Zeichen blieben oft unleserlich. Messung mit einer einzigen OCR, ohne deutsches Sprachpaket. - **(d) In der Schrift DejaVu Sans Mono unterscheidet die gepunktete Null 0 von O.** Bei 10 pt ist der Punkt zu klein. Dieselbe Seite in drei Schriften: DejaVu Sans Mono ergab 14 zweifelhafte Zeichen bei 150 dpi (6/G, 0/O, t/f, B/D) und 10 bei 300 dpi (alle 0/O), JetBrains Mono und Cascadia Mono je 0. Mit einer dieser beiden Schriften haben neue Dokumente bei 300 dpi alle Zeilen übereinstimmend und bei 150 dpi ein zweifelhaftes Zeichen pro Dokument (S/5, g/q); zuvor 4-7 zweifelhafte Zeilen. Messung an PDF-Renderings, nicht an Ausdrucken. - **(e) Auf dem Ausdruck genügt die untere Zeitgrenze, also der Beweis, dass das Siegel nicht früher entstand.** Sie genügt nicht: Wer dieselbe Software hat, kann den Inhalt umarbeiten und ein neues Siegel mit derselben unteren Zeitgrenze ausstellen. Davor schützt erst die obere Grenze. Analyse; das Testmodell (Richtung 4) hat für diesen Fall einen eigenen Versuch. **Nächster Schritt.** Keiner - Annahmen abgeschlossen; (b) bleibt eine Rechnung. **Status:** fünf Annahmen abgeschlossen: drei durch Analyse und Rechnung, zwei durch Messung. ### 2. Richtung 2 - Änderung eines einzelnen Zeichens auf dem Ausdruck: null Fehlalarme und der Preis in unentschiedenen Zeichen **Problem.** Die kleinste Änderung des Inhalts ist ein Zeichen: eine Ziffer des Betrags oder des Datums, ein durch einen Punkt ersetztes Komma. Ein Leser, der sie aus einem Scan oder Foto erkennen soll, darf dabei ehrliche Zeichen nicht für verändert halten: Ein einziger Fehlalarm auf einem echten Dokument stellt die gesamte Verifikation infrage. Die Frage: Wie viele Änderungen eines einzelnen Zeichens werden bei null Fehlalarmen erkannt, und wie viele ehrliche Zeichen entscheidet das Bild dann nicht. **Stand der Technik (veröffentlicht).** Die Arbeiten aus Genf (Voloshynovskiy et al., 2006; Villán et al., 2007) zeigen einen veränderten Textblock - Wort, Zeile oder Absatz - nach Druck, Scan, Fotokopie und Fax an; in den Experimenten von 2007 wurden das Hinzufügen, das Entfernen und der Austausch eines Zeichens erkannt, die Fälschung „aufhentication“ ließ die OCR aber durch. Fraunhofer SIT (Bugert, Heeger, Berchtold, IS&T Electronic Imaging 2023) prüft mit dem Handy signierte, per OCR gelesene Textblöcke; jede Nichtübereinstimmung entscheidet der Nutzer, und die Arbeit nennt keine Zahlenergebnisse. SealClub (Ochoa, Toro-Pozo, Basin, ETH Zürich; arXiv 2022) authentifiziert ein Papierdokument aus einer kurzen Handyaufnahme und markiert durch Bildvergleich Stellen, die der Fälschung verdächtig sind. **Kriterium (falsifizierbar).** Null Fehlalarme: Kein ehrliches Zeichen darf als verändert gelten. Ein Zeichen, das das Bild nicht entscheidet, erhält den Status „unentschieden“ und wird gesondert als Kosten gezählt. Ein verändertes Zeichen darf nicht als übereinstimmend gelten. Das Kriterium wird durch einen Fehlalarm oder durch eine als übereinstimmend gewertete Änderung widerlegt. **Methode.** Testseite auf zwei A4-Blättern. Das erste ist ein ehrliches Dokument. Auf dem zweiten, einer Rechnung, wurden vier Zeilen anders gedruckt, als sie versiegelt wurden, jede mit einer Änderung: Komma zu Punkt, 5 zu 8, 3 zu 8, 2 zu 7; dazu Schriftproben von 7 bis 12 pt. Druck: Laserdrucker Samsung Xpress C430W. Scans: HP ScanJet Pro 2000 s2 mit Einzug; 150, 200, 300 und 600 dpi in Farbe, 300 dpi als JPEG, in Schwarzweiß und mit um 180° gedrehten Blättern. Fotos: Motorola Razr 50 Ultra, ganze Seite von oben und schräg bei schwächerem Licht. Messung vom 5.11.2026: 22 Bilder (18 Scans und 4 Fotos). Wiederholung vom 6.11.2026: 40 Bilder - Scans zweier Ausgaben der Testseite, vier Fotos und PDF-Renderings bei 150-600 dpi. Zeilenurteile: 9.11.2026, 60 Bilder von drei Ausgaben der Seite, die sich nur im Code unterscheiden (Scans, PDF-Renderings und Fotos). Die Art des Auslesens und der Aufbau des Codes bleiben zurückgehalten. **Ergebnis.** Kriterium erfüllt. Fehlalarme: 0 bei 12.474 Prüfungen ehrlicher Zeichen (22 Bilder, 5.11.) und 0 bei 22.680 ehrlichen Zeichen (40 Bilder, 6.11.). Änderungen eines einzelnen Zeichens auf Scans: 36 von 36 als verändert erkannt, jedes Mal mit korrektem Auslesen dessen, was gedruckt wurde. Auf Fotos: veränderte Ziffern 6 von 6, ein durch einen Punkt ersetztes Komma dagegen in 2 von 2 Fällen unentschieden, weil auf dem Foto der ganzen Seite der Schwanz des Kommas nicht zu sehen ist. Auf 40 Bildern wurden 78 von 80 Änderungen erkannt; die beiden übrigen sind dasselbe Komma auf Fotos, unentschieden. Preis: ehrliche Zeichen unentschieden - auf Scans 0,5-4 %, fast ausschließlich Paare ähnlicher Zeichen in einer Proportionalschrift (l/I, i/I, j/J, ł/l, Punkt und Doppelpunkt); auf Fotos 2-10 % auf der ersten Seite und 20-29 % auf der zweiten, wo unscharfe kleine Proben von 7-9 pt liegen. Zeilenurteile (60 Bilder): Keine ehrliche Zeile kam als nicht übereinstimmend oder unleserlich heraus; veränderte Zeilen kamen als nicht übereinstimmend heraus: 4 von 4 auf Scans und Renderings (27 Bilder) und 3 von 4 auf Fotos (3 Bilder), wo die vierte, mit dem Komma, unentschieden blieb. Randbedingungen: (a) den Leser haben wir an denselben Bildern entwickelt, an denen wir das Ergebnis angeben; seine frühere Fassung ergab am Rendering mit 150 dpi einen Fehlalarm (ein Punkt in der Probe mit 7 pt), der nach der Korrektur des Lesers verschwand - ein unabhängiger Test sind erst neue Dokumente (Richtung 4) und neue Ausdrucke; (b) ein Foto der ganzen Seite genügt für Ziffern, nicht für feine Interpunktion. **Nächster Schritt.** Manuelle Versuche an einem neuen Ausdruck (Richtung 4). **Status:** Kriterium erfüllt an Bildern der Testseite, mit den Bedingungen (a)-(b); Kosten in unentschiedenen Zeichen gemessen. ### 3. Richtung 3 - Scanner mit Einzug und Handy: Geometrie des Blatts und Lesbarkeit der Codes **Problem.** Die Verifikation soll aus einem Scan und aus einem Handyfoto funktionieren. Beide Geräte verzerren das Blatt, und der Codeleser im Handy liest nicht jeden Code. Bevor man annimmt, ein Scan sei ein „besseres Foto“, muss man messen, wie groß diese Verzerrungen sind und woher sie stammen. **Stand der Technik (veröffentlicht).** ICAO Doc 9303, Teil 13 (8. Ausg., 2021) geht davon aus, dass das Siegel auch eine Person ohne Schulung mit billigem Gerät prüfen kann, z. B. mit einer Smartphone-App, und empfiehlt für Tintenstrahldrucker ein Codemodul von mindestens 0,3386 mm; BSI TR-03137 übernimmt dieses Modul als Anforderung. Fraunhofer SIT (2023) weist darauf hin, dass die Robustheit der Prüfung mit dem Handy stark von der Qualität des Fotos und der Entzerrung des Dokuments abhängt, ohne Zahlen zu nennen. **Kriterium (falsifizierbar).** Die Intuition „ein Scan aus dem Einzug bildet das Blatt treuer ab als ein Foto aus der Hand“ fällt, wenn die Abweichung der Geometrie auf Scans größer ist als auf Fotos. Die Abweichung schreiben wir dem Einzug zu, wenn sie nach einer Drehung des Blatts um 180° im Koordinatensystem des Scanners bleibt und nicht in dem der Seite. Das Auslesen eines Codes bewerten wir dreistufig: schnell, nach langem Zielen, gar nicht. **Methode.** Auf dem Blatt verteilte Kontrollpunkte, verglichen mit der für ein ebenes Blatt vorgesehenen Lage; Abweichung in Millimetern auf dem Papier. Geräte wie in Richtung 2. Scanner: 18 Bilder vom 5.11.2026 und weitere Durchläufe vom 6.11.2026 an zwei weiteren Ausdrucken. Handy: 4 Fotos ganzer Seiten vom 5.11.2026 (JPEG 4096 × 3072). 2D-Codes: neun Varianten mit einem Modul von 0,25 bis 0,50 mm und verschiedenen Fehlerkorrekturstufen; der Leser in der Handykamera, jeder Code einzeln aus der Nähe (5. und 6.11.2026), und ein Messwerkzeug an ganzen Bildern von Scans und Fotos. Die Art des Auslesens und der Aufbau des Codes bleiben zurückgehalten. **Ergebnis.** Die Intuition fällt. Scanner mit Einzug: Abweichung im Mittel 0,12-0,24 mm auf dem ersten Blatt und 0,32-0,44 mm auf dem zweiten, höchstens 0,79 mm. Sie wächst entlang des Papiervorschubs bis auf ca. 0,7 mm und fällt gegen Ende des Blatts. Nach der Drehung des Blatts um 180° ändert sie im Koordinatensystem der Seite die Richtung und bleibt im Koordinatensystem des Scanners gleich - sie stammt also vom Einzug, nicht vom Drucker. Zwischen den Durchläufen schwankt sie um ca. ±0,2 mm, und an zwei weiteren Ausdrucken waren die Mittelwerte ähnlich (0,14-0,21 mm und 0,31-0,37 mm). Handy: im Mittel 0,16-0,20 mm, höchstens 0,29-0,50 mm, bei einer Auflösung auf dem Blatt von 271-339 dpi; das Foto hat keine Verzerrung durch den Papiervorschub. Codes: Aus Scans mit 150-600 dpi las das Messwerkzeug aus dem ganzen Bild alle Codes außer dem kleinsten bei 150 und 600 dpi; aus dem Foto der ganzen Seite nur einen Teil, vor allem die größeren. Der Leser in der Handykamera las Codes mit weniger Modulen schnell, dichtere sehr langsam oder gar nicht: Am 5.11. las er acht von neun Varianten, davon drei erst nach sehr langem Zielen; am 6.11., als die Codes mehr Daten trugen, las er drei praktisch nicht (einmal, nach sehr langem Zielen). Die Ergebnisse beider Tage sind nicht ganz konsistent: Der Code mit der niedrigsten Fehlerkorrekturstufe wurde am 5.11. nicht gelesen, am 6.11. schon. Dicht beieinanderliegende Codes erforderten langes Zielen, weil der Leser nur einen Code aus dem Bildausschnitt nimmt. Negatives Ergebnis zum Werkzeug: Eine der offenen Bibliotheken zum Lesen von Codes las alle Codes aus dem PDF-Rendering, aus dem Scan mit 300 dpi aber nur 4 von 9, und das erst aus einem entzerrten Ausschnitt; sie irrte sich auch bei einer gebrochenen Modulgröße auf einem scharfen Bild. Zur Messung der Lesbarkeit verwenden wir sie nicht. **Nächster Schritt.** Scans, Fotos und eine Fotokopie des neuen Ausdrucks in manuellen Versuchen (Richtung 4). **Status:** gemessen am 5.-6.11.2026. ### 4. Richtung 4 - Testmodell mit Urteilen, die vor dem Versuch festgelegt wurden **Problem.** Die Messung an der Testseite prüft das Auslesen, aber nicht den ganzen Weg des Dokuments - Ausstellung, Code, Zeit, Verifikation - und nicht das Verhalten des Verifizierers gegenüber im Voraus geplanten Fälschungen. Damit sich das Ergebnis nicht dem anpasst, was gerade herauskam, muss das erwartete Urteil jedes Versuchs vor dem Durchlauf festgehalten werden. **Stand der Technik (veröffentlicht).** ICAO Doc 9303, Teil 13 legt das Urteil über ein Siegel fest: gültig oder ungültig, mit Grund (u. a. Lesefehler, unbekanntes Zertifikat, ungültige Signatur). Der Prototyp von Fraunhofer SIT (2023) nennt keine Zahlenergebnisse. Auch ein eingeführtes Format kann unzuverlässig sein: France Titres-ANTS schrieb am 30. September 2025, dass 2D-Doc auf den Steuerbescheiden von 2025 beim Auslesen Fehler gibt, und empfahl, ein anderes Dokument einzureichen. **Kriterium (falsifizierbar).** Ein Katalog von Versuchen mit dem erwarteten Urteil jedes Versuchs und Abnahmekriterien, angenommen am 10.11.2026, vor dem Durchlauf: Keine veränderte Zeile erhält „übereinstimmend“ (eine vorab vorgesehene Ausnahme: ein Fälscher, der dieselbe Software hat und ein eigenes Siegel ausstellt - die Zeilen stimmen dann mit seinem Siegel überein, davor schützen die Zeitgrenzen, Richtung 1 (e)); keine ehrliche Zeile erhält „nicht übereinstimmend“, und auf Renderings auch nicht „unleserlich“; jeder falsche Zeitnachweis ist unbestätigt und jeder echte bestätigt; bösartige Eingaben führen weder zu Abstürzen noch zu einer Ablehnung ohne Meldung. Das Kriterium wird durch eine einzige Verifikation widerlegt, die nicht dem erwarteten Urteil entspricht. **Methode.** Modell in Docker mit dem vollständigen Weg des Dokuments: Test-Aussteller, echte Kryptografie, ein Zeitdienst zu Testzwecken statt des produktiven, Verifikation auf demselben Weg wie im Browser. Drei Dokumentmuster (zwei Arten von Zertifikaten und eine Rechnung), 75 Dokumente, 120 Versuche, 198 Verifikationen von Seitenbildern bei 150 und 300 dpi. Fälschungen entstehen auf zweierlei Weise: als PDF mit einem anderen Text als dem versiegelten und als Änderung des Bildes nach dem Rendering (Einfügen, Löschen, Austausch). Derselbe Durchlauf auf zwei PDF-Renderern: unter Windows (Windows.Data.Pdf) und in Docker unter Linux (poppler 22.12, sauberer Build aus dem Repository, ohne Netz). Dazu Robustheit: eine Million zufälliger und bösartiger Codetexte, 200.000 bösartige Eingaben der Verifikation, 22 Extrembilder (u. a. leer, nur Rauschen, sehr klein und sehr groß, gedreht, gespiegelt, im Negativ) und 21 Fälle an Formatgrenzen, zum Teil auch in der für den Browser bestimmten Fassung des Verifizierers; sowie eine Durchsicht, in der jedes Byte des Code-Inhalts auf mehrere Weisen verändert und der Code neu erzeugt wurde. Die Art des Auslesens und der Aufbau des Codes bleiben zurückgehalten. **Ergebnis.** 198 von 198 Verifikationen stimmten mit dem erwarteten Urteil überein, in beiden Umgebungen gleich. Robustheit: null Abstürze und null Ablehnungen ohne Meldung. Keine der 5232 Änderungen des Code-Inhalts ergab eine volle Bestätigung. Das Modell fand sechs Fehler des Lesers, die die Messung an Bildern der Testseite nicht aufzeigen konnte, weil jene Bilder solche Fälle nicht enthielten: - eine überklebte oder nicht gedruckte Zeile erhielt „übereinstimmend mit zweifelhaften Stellen“; - eine einzelne Ziffer, die unmittelbar hinter einer Zeile ergänzt wurde, ging als übereinstimmend durch; - der Code eines anderen Dokuments, der neben den Code des Dokuments geklebt war, wurde übergangen, statt eine Ablehnung auszulösen; - ein gespiegeltes Bild, z. B. von der Frontkamera eines Handys, ergab für eine ehrliche Zeile „nicht übereinstimmend“, im Browser nach 50 s; - ein mit einem 0,35-mm-Strich durchgestrichener Betrag kam bei 300 dpi als übereinstimmend heraus; diesen Fehler fand die Simulation manueller Versuche an Bildern (nach der Korrektur 28 von 28 im Einklang mit dem erwarteten Urteil); - eine Zeile mit dem Zeichen „@“ kam unleserlich heraus. Alle haben wir korrigiert, jeden mit einem Test; an 62 Bildern aus früheren Messungen (Scans, PDF-Renderings, Fotos) haben sich die Status der Zeilen nach den Korrekturen nicht geändert. Nach dem ersten Durchlauf haben wir außerdem vier erwartete Urteile korrigiert (10.11.2026) - zwei betrafen einen veränderten Code und Zusätze in der Zeile, zwei die Zeitprüfungen. Das ist eine Abweichung von der Regel „Urteil vor dem Versuch“, daher ist 198 von 198 der Stand nach diesen Korrekturen und nach den Korrekturen des Lesers. Bekannte Unvollkommenheiten: Bei 150 dpi wurde eine eingefügte Ziffer 8 als „S“ gelesen (das Urteil „nicht übereinstimmend“ war richtig), und nicht jeder feine Zusatz an Satzzeichen wird bei 300 dpi erkannt. Die automatischen Versuche sind PDF-Renderings und Bildänderungen, keine Ausdrucke. Das Modell beweist nicht die Fehlerfreiheit; es liefert ein messbares Ergebnis an einem im Voraus festgelegten Katalog von Versuchen. **Nächster Schritt.** Manuelle Versuche nach der fertigen Liste: 12 Seiten, jede als eigenes Dokument mit eigenem Siegel und erwartetem Urteil - Scans, Fotos, Fotokopie, skalierter Ausdruck, Korrekturen mit Kugelschreiber und Klebeband, aufgeklebte fremde Codes, zum Schluss ein zerknülltes Blatt. Danach die Bewertung der Darstellung des Urteils und eine unabhängige Durchsicht des Verifikationscodes. **Status:** automatischer Teil abgeschlossen am 10.11.2026. **Status der Richtung.** Abgeschlossen: die fünf Annahmen aus Richtung 1. Gemessen: Erkennung der Änderung eines einzelnen Zeichens bei null Fehlalarmen, Kosten in unentschiedenen Zeichen, Geometrie von Scanner und Handy sowie Lesbarkeit der Codes. Das Testmodell hat den automatischen Teil bestanden: 198 von 198. Grenzen der Messung: ein Drucker, ein Scanner, ein Handy und insgesamt 8 Fotos; die „Fälschungen“ hat der Autor gedruckt. Nächste Schritte: manuelle Versuche - Korrekturen mit Kugelschreiber, Fotokopie, skalierter Ausdruck - und eine unabhängige Durchsicht des Codes. --- --- # 🇬🇧 ENGLISH VERSION ## Koch Laboratory - a printout checked line by line: five refuted assumptions and first measurements A document issued as a PDF lives on as a printout, a scan or a phone photo. Whether an amount, a date or a number on such a copy is the same characters the document had at the moment of sealing is today usually decided by a person: the app shows the data from the code on the document, and the person compares it with the printout. This line of research, run since 31 October 2026, measures whether this can be checked automatically, line by line, from an ordinary scan and a phone photo, without ever treating an honest document as altered. The entry gives the results from the first ten days of November 2026: first five assumptions that did not hold, then the detection of a change to a single character, the differences between a sheet-fed scanner and a phone, and a test model with verdicts fixed before the trial. **What is research here and what is not.** Signed data in a visible 2D code on paper is a mature pattern (ICAO VDS, the BSI digital seal, the French 2D-Doc). Automatic checking of a printout with the altered fragment pointed out was described in 2006-2007 (University of Geneva), and checking a printout with a phone by, among others, Fraunhofer SIT (2023) and SealClub (ETH Zurich). The research content is measurement under a hard criterion: whether an honest character never comes out as altered, how many changes to a single character are then detected on a scan and on a photo, how many honest characters the image leaves undecided, and what distorts the geometry of the sheet - and the assumptions that did not hold along the way. Evidentiary claim: verification shows that the checked lines of the printout are as they were at the moment of the seal. It does not show that their content is true, who issued the document, or that the sheet is not a copy. **Method.** As in the rest of the laboratory: problem → state of the art → falsifiable criterion → method → result (confirmed, refuted or partial, with boundary conditions) → next step. A negative result is a result. A false alarm is an honest character or line judged to be altered. “Undecided” means the image does not settle the matter: the verifier accepts such a character neither as matching nor as altered, but shows it to a person as doubtful. The figures come from measurement notes and trial reports of 5-10 November 2026. ### 1. Direction 1 - five assumptions that did not hold **Problem.** The line's first assumptions - some from the concept of 31 October 2026, some from the first days of work - had not been checked. Each of them, if false, would give either apparent protection or false alarms. **State of the art (published).** Copy attack: a hidden mark in a document that does not depend on the content can be read from the protected document and applied in the same way to another, without knowing the key (Voloshynovskiy et al., SPIE 2006). OCR autocorrection: in the experiments of Villán et al. (SPIE 2007) the OCR read the forged word “aufhentication” as “authentication” and the forgery passed. BSI TR-03137 (part 1, version 3.0 of 2026, chap. 19) describes recovering data with error-tolerant OCR and recommends showing a person every corrected character. **Criterion (falsifiable).** An assumption fails when (1) an attack exists that satisfies it and nevertheless changes the content; (2) calculation shows an effect smaller than the resolution of the device; (3) measurement under the stated conditions gives an unreadable or doubtful reading where the assumption promised an unambiguous one. **Method.** We checked three assumptions by analysis and calculation: binding the content through the geometry of the page, the physics of printing at 10 pt and 600 dpi, and the role of the lower time bound. Two by measurement: OCR on 12 images of the test page (scans at 150-600 dpi and phone photos, 6 November 2026) and three monospaced fonts on PDF renders of the same page at 150 and 300 dpi (10 November 2026). The method of reading and the construction of the code remain withheld. **Result.** None of the five assumptions held. - **(a) Fine features of the page layout, computed from the open data of the document, bind the printout to its content.** They do not. Whoever knows these data computes the same seed, changes a character and lays it out according to it; the geometry check accepts the forgery as matching. In the literature this is the copy attack (Voloshynovskiy et al., 2006). Analysis. - **(b) Micro-shifts of letters by ±0.5-1.5% of their width carry bits that survive printing and scanning.** At 10 pt that is about 9-26 µm, and a 600 dpi printer pixel is about 42 µm. A single bit written with so fine a shift is very unreliable. A statistical signal from many pairs may survive, because rasterisation acts like dithering, but we did not measure this. Calculation, not measurement. - **(c) A general-purpose OCR can supply the text of a line for checking.** In the literature OCR “corrects” forgeries (the “aufhentication” case, 2007). In our case the OCR built into Windows - on the measurement computer with the Polish language pack only - read German characters with errors: “Hauptstrage” instead of “Hauptstraße”, “Kliche” instead of “Küche”, “Uber” instead of “über”, “OO” instead of “00”. It gave no false mismatch, but lines with German characters often remained unreadable. Measurement with a single OCR, without the German language pack. - **(d) In the DejaVu Sans Mono font the dotted zero distinguishes 0 from O.** At 10 pt the dot is too small. The same page in three fonts: DejaVu Sans Mono gave 14 doubtful characters at 150 dpi (6/G, 0/O, t/f, B/D) and 10 at 300 dpi (all 0/O), JetBrains Mono and Cascadia Mono 0 each. With one of these two fonts new documents have all lines matching at 300 dpi and one doubtful character per document at 150 dpi (S/5, g/q); previously 4-7 doubtful lines. Measurement on PDF renders, not on printouts. - **(e) On a printout the lower time bound is enough, that is, proof that the seal did not come into being earlier.** It is not enough: whoever has the same software can rework the content and issue a new seal with the same lower time bound. Only the upper bound protects against this. Analysis; the test model (direction 4) has a separate trial for this case. **Next step.** None - assumptions closed; (b) remains a calculation. **Status:** five assumptions closed: three by analysis and calculation, two by measurement. ### 2. Direction 2 - a change to a single character on a printout: zero false alarms and the price in undecided characters **Problem.** The smallest change to the content is one character: a digit of an amount or a date, a comma replaced by a full stop. A reader that is to detect it from a scan or a photo must not, in doing so, judge honest characters to be altered: a single false alarm on a genuine document undermines the whole verification. The question: how many single-character changes are detected at zero false alarms, and how many honest characters does the image then leave undecided. **State of the art (published).** The Geneva works (Voloshynovskiy et al., 2006; Villán et al., 2007) point out an altered block of text - a word, a line or a paragraph - after printing, scanning, photocopying and fax; in the 2007 experiments the addition, removal and substitution of a character were detected, but the forgery “aufhentication” was let through by the OCR. Fraunhofer SIT (Bugert, Heeger, Berchtold, IS&T Electronic Imaging 2023) checks signed text blocks read by OCR with a phone; every mismatch is decided by the user, and the paper gives no numerical results. SealClub (Ochoa, Toro-Pozo, Basin, ETH Zurich; arXiv 2022) authenticates a paper document from a short phone recording and, by comparing images, marks places suspected of forgery. **Criterion (falsifiable).** Zero false alarms: no honest character may be judged altered. A character the image does not settle gets the status “undecided” and is counted separately, as a cost. An altered character must not be judged matching. The criterion is refuted by one false alarm or by one change judged matching. **Method.** A test page on two A4 sheets. The first is an honest document. On the second, an invoice, four lines were printed differently from how they were sealed, each with one change: comma to full stop, 5 to 8, 3 to 8, 2 to 7; plus samples of type from 7 to 12 pt. Printing: Samsung Xpress C430W laser printer. Scans: HP ScanJet Pro 2000 s2 with a sheet feeder; 150, 200, 300 and 600 dpi in colour, 300 dpi as JPEG, in black and white, and with sheets rotated by 180°. Photos: Motorola Razr 50 Ultra, the whole page from above and at an angle in dimmer light. Measurement of 5 November 2026: 22 images (18 scans and 4 photos). Repeat of 6 November 2026: 40 images - scans of two editions of the test page, four photos and PDF renders at 150-600 dpi. Line verdicts: 9 November 2026, 60 images of three editions of the page that differ only in the code (scans, PDF renders and photos). The method of reading and the construction of the code remain withheld. **Result.** Criterion met. False alarms: 0 in 12,474 checks of honest characters (22 images, 5 November) and 0 in 22,680 honest characters (40 images, 6 November). Single-character changes on scans: 36 of 36 detected as altered, each time with a correct reading of what was printed. On photos: altered digits 6 of 6, while a comma replaced by a full stop was undecided in 2 of 2 cases, because the tail of the comma is not visible in a photo of the whole page. On 40 images 78 of 80 changes were detected; the other two are the same comma on photos, undecided. Price: honest characters undecided - on scans 0.5-4%, almost exclusively pairs of similar characters in a proportional font (l/I, i/I, j/J, ł/l, full stop and colon); on photos 2-10% on the first page and 20-29% on the second, where the blurred small samples of 7-9 pt lie. Line verdicts (60 images): no honest line came out as mismatching or unreadable; altered lines came out as mismatching: 4 of 4 on scans and renders (27 images) and 3 of 4 on photos (3 images), where the fourth, with the comma, remained undecided. Boundary conditions: (a) we developed the reader on the same images on which we report the result; its earlier version gave one false alarm on the 150 dpi render (a full stop in the 7 pt sample), which disappeared after the reader was fixed - the independent test is only new documents (direction 4) and new printouts; (b) a photo of the whole page is enough for digits, not for fine punctuation. **Next step.** Manual trials on a new printout (direction 4). **Status:** criterion met on images of the test page, with conditions (a)-(b); the cost in undecided characters measured. ### 3. Direction 3 - sheet-fed scanner and phone: sheet geometry and code readability **Problem.** Verification is meant to work from a scan and from a phone photo. Both devices distort the sheet, and the code reader in a phone does not read every code. Before assuming that a scan is a “better photo”, one has to measure how large these distortions are and where they come from. **State of the art (published).** ICAO Doc 9303, part 13 (8th ed., 2021) assumes that the seal can be checked even by an untrained person with inexpensive equipment, e.g. a smartphone app, and for inkjet printers recommends a code module of at least 0.3386 mm; BSI TR-03137 adopts this module as a requirement. Fraunhofer SIT (2023) cautions that the robustness of checking with a phone depends strongly on the quality of the photo and the straightening of the document, without giving numbers. **Criterion (falsifiable).** The intuition “a scan from the feeder reproduces the sheet more faithfully than a hand-held photo” fails when the geometry deviation is larger on scans than on photos. We attribute the deviation to the feeder if, after the sheet is rotated by 180°, it stays in the scanner's frame and not in the page's. We rate the reading of a code on three levels: quickly, after long aiming, not at all. **Method.** Control points distributed over the sheet compared with the position expected for a flat sheet; deviation in millimetres on the paper. Equipment as in direction 2. Scanner: 18 images of 5 November 2026 and further runs of 6 November 2026 on two subsequent printouts. Phone: 4 photos of whole pages of 5 November 2026 (JPEG 4096 × 3072). 2D codes: nine variants with a module from 0.25 to 0.50 mm and different error-correction levels; the reader in the phone camera, each code separately from close up (5 and 6 November 2026), and a measurement tool on whole images of scans and photos. The method of reading and the construction of the code remain withheld. **Result.** The intuition fails. Sheet-fed scanner: deviation on average 0.12-0.24 mm on the first sheet and 0.32-0.44 mm on the second, at most 0.79 mm. It grows along the paper feed to about 0.7 mm and falls towards the end of the sheet. After the sheet is rotated by 180° it changes direction in the page's frame and stays the same in the scanner's frame - so it comes from the feeder, not from the printer. Between runs it varies by about ±0.2 mm, and on two subsequent printouts the averages were similar (0.14-0.21 mm and 0.31-0.37 mm). Phone: on average 0.16-0.20 mm, at most 0.29-0.50 mm, at a resolution on the sheet of 271-339 dpi; the photo has no paper-feed distortion. Codes: from scans at 150-600 dpi the measurement tool read from the whole image all codes except the smallest at 150 and 600 dpi; from a photo of the whole page only some, mainly the larger ones. The reader in the phone camera read codes with fewer modules quickly, and denser ones very slowly or not at all: on 5 November it read eight of nine variants, three of them only after very long aiming; on 6 November, when the codes carried more data, it practically did not read three (once, after very long aiming). The results of the two days are not fully consistent: the code with the lowest error-correction level was not read on 5 November, and was on 6 November. Codes lying close together required long aiming, because the reader takes one code from the frame. Negative result as to the tool: one of the open libraries for reading codes read all codes from the PDF render, but from the 300 dpi scan only 4 of 9, and only from a straightened crop; it also erred at a fractional module size on a sharp image. We do not use it to measure readability. **Next step.** Scans, photos and a photocopy of the new printout in the manual trials (direction 4). **Status:** measured on 5-6 November 2026. ### 4. Direction 4 - a test model with verdicts fixed before the trial **Problem.** A measurement on the test page checks reading, but not the whole path of a document - issuance, code, time, verification - nor the verifier's behaviour towards forgeries planned in advance. So that the result does not fit itself to whatever came out, the expected verdict of each trial must be written down before the run. **State of the art (published).** ICAO Doc 9303, part 13 defines the verdict on a seal: valid or invalid, with a reason (among others read error, unknown certificate, invalid signature). The Fraunhofer SIT prototype (2023) gives no numerical results. A deployed format can also be unreliable: France Titres-ANTS wrote on 30 September 2025 that 2D-Doc on the 2025 tax notices gives errors on reading, and recommended submitting another document. **Criterion (falsifiable).** A catalogue of trials with the expected verdict of each trial and acceptance criteria adopted on 10 November 2026, before the run: no altered line gets “matching” (an exception foreseen in advance: a forger who has the same software and issues their own seal - the lines then agree with their seal, and the time bounds protect against that, direction 1 (e)); no honest line gets “mismatching”, and on renders also not “unreadable”; every false time proof is unconfirmed and every genuine one confirmed; malicious inputs cause neither crashes nor rejection without a message. The criterion is refuted by one verification that does not match the expected verdict. **Method.** A model in Docker with the full path of a document: a test issuer, real cryptography, a test time service instead of the production one, verification by the same route as in the browser. Three document templates (two kinds of certificates and an invoice), 75 documents, 120 trials, 198 verifications of page images at 150 and 300 dpi. Forgeries arise in two ways: as a PDF with a different text from the sealed one and as an image change after rendering (pasting, erasing, substitution). The same run on two PDF renderers: on Windows (Windows.Data.Pdf) and in Docker under Linux (poppler 22.12, a clean build from the repository, without network). In addition, robustness: a million random and malicious code texts, 200,000 malicious verification inputs, 22 extreme images (among others blank, noise only, very small and very large, rotated, mirrored, in negative) and 21 format-boundary cases, some also in the version of the verifier intended for the browser; and a review in which every byte of the code content was altered in several ways and the code was generated anew. The method of reading and the construction of the code remain withheld. **Result.** 198 of 198 verifications matched the expected verdict, the same in both environments. Robustness: zero crashes and zero rejections without a message. None of the 5232 alterations of the code content gave full confirmation. The model found six reader errors that the measurement on test-page images could not reveal, because those images did not contain such cases: - a covered-over or unprinted line got “matching with doubtful places”; - a single digit added right after a line passed as matching; - the code of another document stuck next to the document's code was ignored instead of causing a refusal; - a mirror-image picture, e.g. from the front camera of a phone, gave an honest line “mismatching”, in the browser after 50 s; - an amount struck through with a 0.35 mm line came out matching at 300 dpi; this error was found by the simulation of manual trials on images (after the fix 28 of 28 matched the expected verdict); - a line with the character “@” came out unreadable. We fixed them all, each with a test; on 62 images from earlier measurements (scans, PDF renders, photos) the line statuses did not change after the fixes. After the first run we also corrected four expected verdicts (10 November 2026) - two concerned an altered code and additions in a line, two the time checks. This is a departure from the rule “verdict before the trial”, so 198 of 198 is the state after these corrections and after the reader fixes. Known imperfections: at 150 dpi a pasted digit 8 was read as “S” (the verdict “mismatching” was correct), and not every fine addition next to punctuation marks is detected at 300 dpi. The automatic trials are PDF renders and image changes, not printouts. The model does not prove the absence of errors; it gives a measurable result on a catalogue of trials fixed in advance. **Next step.** Manual trials according to a ready list: 12 pages, each as a separate document with its own seal and expected verdict - scans, photos, photocopy, scaled printout, corrections with a ballpoint pen and tape, foreign codes stuck on, and finally a crumpled sheet. Then an assessment of how the verdict is presented and an independent review of the verification code. **Status:** automatic part completed on 10 November 2026. **Status of the direction.** Closed: the five assumptions from direction 1. Measured: detection of a change to a single character at zero false alarms, the cost in undecided characters, the geometry of the scanner and the phone, and code readability. The test model passed the automatic part: 198 of 198. Limits of the measurement: one printer, one scanner, one phone and 8 photos in total; the “forgeries” were printed by the author. Nearest steps: manual trials - corrections with a ballpoint pen, photocopy, scaled printout - and an independent code review.