beA-Panne: Welche Daten enthält die Signatur?
by Volker Weber
Eine Analyse zu meinem Artikel bei Heise.de: Wieder eine beA-Panne: Archive ohne Signatur
Wenn der Rechtsanwalt ein Schreiben aus beA herunterlädt, bekommt er eine ZIP-Datei und eine PKCS #7 Signaturdatei, die die Echtheit der ZIP-Datei rechtssicher nachweisen soll:
Im Rahmen der Speicherung fasst das beA-System nun den Nachrichteninhalt sowie den Anhang in der ZIP-Datei zusammen (1). Gleichzeitig bringt das beA eine gesonderte Signaturdatei (mit einem fortgeschrittenen Zertifikat) an die ZIP-Datei an (2). Diese Signaturdatei stellt sicher, dass der Inhalt dieser ZIP-Datei nicht mehr geändert werden kann, ohne dass eine Signaturprüfung zu einem Fehler führen würde. Mit anderen Worten: Der Inhalt der ZIP-Datei kann nicht mehr unbemerkt verändert werden (vgl. beA-Newsletter 50/2017). Sowohl ZIP-Ordner als auch Signaturdatei müssen gemeinsam abgespeichert werden, um zu einem späteren Zeitpunkt einen rechtssicheren Nachweis führen zu können.
Versucht man diese Prüfung bei einer beliebigen aus beA archivierten Nachricht, heißt es, die Signaturdatei sei ungültig.
Das ist nicht ganz richtig. In der Datei ist tatsächlich eine Signatur, der eine Statusmeldung "Operation Okay" vorangestellt ist. PKCS #7 sind als ASN.1 kodiert, man braucht also einen passenden Editor, um sie zu lesen. Man erkennt zwei Nodes, erst die Statusmeldung, dann die Signatur:
Wenn man den Knoten mit der Signatur als neue Datei exportiert, erhält man eine gültige Datei, die sich prüfen lässt:
Das Ergebnis dieser Prüfung ist allerdings unbefriedigend:
Der entscheidende Teil steht in der mittleren rosa Zeile:
Die Signatur enthält also einen Zeitstempel mit dem Datum, zu dem diese Signatur erstellt wurde. Mit anderen Worten: Sie beweist lediglich, wann eine Nachricht als ZIP-Datei heruntergeladen wurde. Für jeden Download der selben Nachricht enthält man einen neuen Wert. Bislang ist es mir nicht gelungen, eine Bestätigung zu erhalten, dass diese Datei unversehrt ist.
Ich habe nicht die geringste Ahnung, was das soll, hege aber den Verdacht, dass sich hier ein Debug-Test aus der Anwendungsentwicklung bis in die Produktion gerettet hat, ohne dass dies jemandem aufgefallen wäre.
Update: Die Signaturdatei ist zwar ungültig, aber nicht verloren. Man kann sie retten, denn sie enthält alle wichtigen Informationen. Ich zitiere einen SAP-Sicherheitsexperten, der sich das genauer angeschaut hat:
Die signierten Daten im PKCS#7 entsprechen der ZIP-Datei. Die sind dann mit einem qualifizierten Zeitstempel signiert. Damit kann man sowohl die Integrität des Inhalts als auch den Zeitpunkt des Zugriffs bestätigen, was für den Anwendungsfall durchaus sinnvoll ist.
Qualifizierte Zeitstempel nimmt man gerne, weil man dann nicht jeden Endpunkt mit Signaturinfrastruktur versorgen muss, sondern das an einen Dienstleister auslagern kann.
Jetzt braucht es nur noch ein Hilfsprogramm, das nachträglich defekte Signaturdateien repariert sowie ein Update für beA, damit das in Zukunft korrekte Signaturen produziert. Und natürlich eine viel bessere Qualitätssicherung beim Hersteller und beim Abnehmer.
Comments
Interessante Analyse. Wäre nen ordentlicher weiterer QS Fail. Eventuell passte da halt dann die Zeitplanung und Budgetierung des Auftragnehmers nicht zu den Vorstellungen des Auftraggebers. Soll vorkommen.
Off-Topic: Wäre es möglich Screenshots im Blog in Zukunft auch in nicht runterskaliertem Format (verlinkt oder halt per rechte Taste öffnen in neuem Tab) einzubetten? Meine Augen werden mittlerweile zu alt um die hier ordentlich entziffern zu können. Geht vermutlich anderen langjährigen Bloglesern ähnlich.
Die meisten Screenshots sind doppelt so groß, wie Du sie hier siehst.
Das ist so nicht ganz richtig. Ein Zeitstempel hat zwar die Funktion zu bestätigen, wann eine Datei (mit diesem Zeitstempel) signiert wurde, aber auch die Funktion die Integrität der Daten sicherzustellen, weil die gehashten Daten mit dem Zeitstempel verknüpft werden. Es ist also ein technischer Fehler bei der Erstellung, grundsätzlich ist ein Zeitstempel aber das Mittel der Wahl bei dieser Funktionalität des beA.
Danke für die Erklärung. Dann besteht ja noch Hoffnung, dass man die erstellten Signaturen retten kann.
Tjo, dann mal her mit den passenden Editoren... wenn "es" denn - richtig? - verknüpft hat.
Eine Software, die beim Archivieren, beim Weiterleiten an EGVP und wo sonst noch so eklatant daneben haut, soll ernsthaft für sich in Anspruch nehmen können, dass das, was sie ansonsten produziert, definitiv und immer das Maß und die Grundlage aller davon abhängenden Rechtsstaatlichkeit ist? Wo soll das Vertrauen noch herkommen?
Wenn eine Signatur mal nicht passt, passt sie dann wegen Manipulation nicht - oder wegen einer sporadischen Fehlfunktion der Software irgendwo davor? Wie viel Murks braucht es, um diese und entsprechende Fragen ernst zu nehmen?
Danke. Ich kann das auch so bestätigen. Um zumindest eine valide Signatur-Datei zu bekommen, genügt es, die ersten 27 Byte zu entfernen. Mit Bord-Mitteln von Windows ist das leider nicht möglich.
Ansonsten kann ich die Angabe des SAP-Experten auch nachvollziehen. In der Original-Datei ab Offset 115 (bzw. in der validen Signatur-Datei ab Offset 88) die SHA256-Prüfsumme des ZIP-Archives der beA-Nachricht abgelegt.
