IT-Experte zerlegt E-Rezept-Codes

Eigentlich waren die Apotheken bisher nicht Steins Metier, doch dann kam Corona: Mit seinem Unternehmen med3D schreibt Stein eigentlich Software für die sensor- und rechnergestützte Chirurgie, darunter Planungssoftware für chirurgische Eingriffe. Als es mit Beginn der Pandemie plötzlich wichtig wurde, wer wann mit wie vielen Personen wo Zeit verbringt, wurde Steins Software plötzlich auch außerhalb der Operationssäle relevant. Er schrieb Platzverwaltungssoftware erst für Kirchen, dann für Freibäder und schließlich, mit Einführung der kostenlosen Bürgertests im Frühjahr, auch Software für Schnellteststationen. „Das ist eine spannende und fruchtbare Zusammenarbeit mit den Apotheken, das macht Spaß“, sagt er.

Eine der Früchte seiner Zusammenarbeit mit den Apotheken war die Beschäftigung mit dem E-Rezept – doch hier erlebte Stein eine böse Überraschung: „Aus der Informatik kommend hat mich der Inhalt der Datamatrix-Codes des E-Rezepts erschreckt“, sagt er. „Die Codes enthalten manche Sachen, die mich sehr misstrauisch machen.“

Es fange schon damit an, dass die Codes viel zu viel enthalten. „Man könnte sie halb so groß machen“, erklärt Stein. Die Datamatrix-Codes sind nicht die eigentlichen E-Rezepte, sondern lediglich die Schlüssel zu den E-Rezepten auf dem zentralen Fachdienstserver innerhalb der Telematikinfrastruktur (TI). Werden sie von der Warenwirtschaft der Apotheke eingelesen, geben sie nur den Pfad und die Berechtigung zum Abrufen der Verordnung wieder – das ginge jedoch bedeutend einfacher als es derzeit umgesetzt wird.

Stein illustriert das an einem Datamatrix-Codes aus der E-Rezept-App der Gematik:

{"urls":["Task\/Task\/full detail rezept
3_1\/$accept?ac=594fd82d9cc3c991f8ffc90b92f12909d3c7a75bce88c6b98854ace5733be213"]}

Das ist in Klarschrift, was in den viereckigen Feldern verschlüsselt steht. „Ungefähr die Hälfte der Zeichen in diesem Beispiel ist redundant, weil sie bei jedem Datamatrix-Code gleich sind“, erklärt Stein. „Diese paar redundanten Bytes klingen nach wenig, sind aber sehr spannend, weil sie auf Fehlerkorrektur und Lesbarkeit Einfluss haben. Die Hälfte des Codes wird unnötig übertragen und kann unnötig die Lesbarkeit verschlechtern.“ Hinzu komme, dass es sich bei dem Code um einen „wilden Mix“ aus verschiedenen Formaten handele.

„Die äußere Hülle ist JSON, der Mittelteil ist ein Parameteraufruf nach FIHR und danach folgt eine Codierung, die nach POST/GET zum Beispiel bei PHP aussieht, also ein typisches Skript, mit dem man programmieren würde, wenn man einen Microsoft- oder Apache-Webserver verwendet“, so Stein. „Ich komme mit allen drei Wegen ans Ziel, aber das Ungewöhnliche und Unsinnige ist, dass die Gematik sie in einem Datamatrix-Code kombiniert. Als Programmierer muss man alle drei beherrschen, das ist also alles machbar, aber eben unnötig kompliziert. Der Inhalt ist redundant, unnötig komplex und dadurch fehleranfällig. Man sollte bedenken, dass wir über 80 Millionen Einwohner haben und entsprechend viele Rezepte – damit steigt also auch die Gefahr von Problemen in der Anwendung.“

Doch nicht nur die unnötige Komplexität bereite ihm Sorgen, sondern auch, dass der Code nicht den höchsten Sicherheitsstandards entspreche, die man aus seiner Sicht hätte anlegen können. So stehe das FIHR-Kommando unverschlüsselt im Code, was nicht nur sinnlos, sondern gegebenenfalls auch gefährlich sein könne. Denn es bilde ein Einfallstor, ähnlich wie man es aus ungezählten Webseiten-Hacks mit sogenannte SQL Injections kennt: Dabei geben Hacker in Formularen statt der erfragten Informationen einen Befehl für die dahinterliegende Datenbank ein und können so ihr Unwesen treiben.

„Wenn jemand Datamatrix-Codes manipuliert, kann er da möglicherweise Befehle einschleusen“, erklärt Stein. „Das kann man verhindern, aber es muss eben durch entsprechende Programmierung getan werden. Enthielte der Code nur die Nutzlast, wäre das gar kein Problem. Wenn ich als Apotheke authentifiziert bin, ist ja klar, wozu ich den Nutzlast-Code bei diesem Arbeitsschritt abrufe, dann brauche ich die Befehle im Datamatrix-Code gar nicht.“

Der Gematik sind diese Einfallstore durchaus bekannt. Auf dem Entwicklerportal Github hat sie bereits mögliche Angriffe mit fingierten Codes als Beispiele erläutert. „Nur ist das natürlich nicht erschöpfend, ein Angreifer kann da noch viel kreativer werden. Jeder Hacker überlegt sich bessere Testfälle als die angegebenen.“ Viel besser wäre ein sichereres Format, beispielsweise nur die eigentliche Nutzlast maximal mit technischen Erweiterungen oder Verlängerungen, so Stein. „Natürlich kann man all das abfangen, keine Frage. Aber durch die unnötige Komplexität ist es viel schwerer zu sichern.“

Wie die Abda auch stört sich der IT-Experte weiterhin daran, dass das E-Rezept ohne Ende-zu-Ende-Verschlüsselung funktioniert – es also innerhalb einer vertrauenswürdigen Ausführungsumgebung in der TI ausgelesen werden kann. Bei Ende-zu-Ende-Verschlüsselung könnten nur der Rezeptaussteller, der Patient und der Apotheker das Rezept lesen. „Ab dem Moment, in dem die Inhalte der Rezepte auf dem Server ein Mal ausgepackt werden, ist Game Over. Als Bürger stört mich das gewaltig, denn ich will nicht, dass der Staat alle meine Rezepte hat.“ Die korrekte Lösung wäre aus seiner Sicht, dass beim E-Rezept wie bei den digitalen Impfzertifikaten alle Daten lokal gespeichert werden und nur ein Hashcode erstellt wird. „Dann wüsste die Gematik nichts über den Inhalt meiner Rezepte.“ Zur Kontrolle, ob ein Rezept bereits eingelöst wurde, brauche es keine Kenntnis über den Inhalt des Rezepts, sondern nur einen Abgleich mit dem digitalen Fingerabdruck des Rezepts – dem sogenannten Hash – auf einem Server.

Er habe aber auch ein ganz grundlegendes Problem damit, dass die Gematik auf den Standard FHIR setzt, mit dem er aus seiner sonstigen Arbeit vertraut ist. „FHIR ist uralt, ungefähr zehn Jahre, hat sich seitdem technisch wenig weiterentwickelt, ist nur in wenigen Programmiersprachen implementiert, hat in letzter Zeit hauptsächlich Hype von nicht-technischer Seite erlebt“, sagt er. So habe FHIR teilweise Probleme mit einer uneindeutigen Nomenklatura, was zu Programmierfehlern führen könne. „Ich habe das Bauchgefühl, dass die Gematik sich auf einen Standard versteift, der sich am Markt nicht durchgesetzt hat. Der Wunsch einer vereinheitlichen Übertragung ist gut, aber FIHR ist vermutlich ein totes Pferd – ein wahnsinnig komplexes. Man kann damit alles machen, wenn man genug Zeit und Geld hat. Beides braucht man allerdings. So, wie es jetzt ist, wird es halt teuer und schlecht.“

Auch mit den Warnungen und Forderungen der Kassenärztlichen Bundesvereinigung (KBV) decken sich Steins Befunde. „Wenn ich kleine Test bei den einzelnen Anwendungen habe, ist das in vielen Fällen in Ordnung“, sagt er. „Die Frage ist aber, wie skalierbar das Ganze bei dieser Komplexität ist. Es gibt zahlreiche Fehlerquellen, die sich erst in einer Massentestung zeigen dürften. Ich frage mich, wie es sein kann, dass die bei der Gematik mit so viel Geld über so viele Jahre solche Ergebnisse wie diese Spezifikation des E-Rezepts produzieren.“