Netz - Rettung - Recht

Der Vortrag wurde bereits beim CCC 2004 in Berlin gehalten und erwies sich als hochinteressant und einer Wiederholung würdig, wie die breite Zusammensetzung des Publikums - neben den "üblichen Verdächtigen" auch Ärzte und Journalisten - bestätigte. Dabei waren die Grundasussagen auch mit Basiskenntnissen aus dem Bereich der IT-Sicherheit, namentlich der elektronischen Signatur und Verschlüsselung, verständlich. Es ging dabei auch nicht nur um die Schwächen des konkreten Systems, sondern um die Darstellung von Prinzipien der Sicherheits- und Kryptoanalyse an diesem konkreten Beispiel.

Zunächst einmal sei das System dargestellt. Es sollte die elektronische Übertragung einer Patientenakte von der Praxis eines überweisenden Arztes an die Zielpraxis ermöglichen und dabei sicherstellen, daß weder der Betreiber des Systems noch ein anderer Arzt noch ein unbefugter Dritter die übertragenen Daten belauschen oder verändern kann. Dazu wurden die Daten aus der Praxis-EDV in einen Übertragungsclient geladen, mittels Chipkarte mit dem Schlüssel des Arztes (der Arztpraxis) digital signiert und verschlüsselt. Der Schlüssel zu dieser Kodierung wurde als 21stelliges, alpha-numerisches Token auf die Überweisung gedruckt. Nach erneuter Signierung des verschlüsselten Pakets wurde dieses erneut mit dem öffentlichen Schlüssel des Betreibers verschlüsselt und dann auf dessen Server übertragen. Dort wurde die äußere Verschlüsselung (mit dem privaten Schlüssel des Betreibers) entfernt. Die Zielpraxis kann die Daten sodann dort abrufen; für die Übertragung an die Zielpraxis werden sie erneut mit derem öffentlichen Schlüssel verschlüsselt. Am Ziel wird die äußere verschlüsselt mit dem privaten Schlüssel entfernt und sodann durch Abtippen des Tokens von der Überweisung auch die innere Verschlüsselung entfernt. Die Integrität des inneren Verschlüsselungspaketes wie auch der unverschlüsselten Akte läßt sich anhand der digitalen Signatur der absendenden Praxis prüfen. Die Datenübertragung selbst findet auf Telefonleitungen via ISDN - also nicht über das Internet - statt, und zwar über ein Callback-Verfahren: der Computer des Arztes ruft den zentralen Server an, der erkennt ihn an der Rufnummer, trennt die Verbindung und ruft zurück.

Sieht erstmal nach einem sicheren System aus. Leider ist das nicht so. Es gibt nicht nur Implementationsmängel in einzelnen Teilen, über die man vielleicht noch hinwegsehen könnte, sondern der zentrale Bestandteil. Die Verschlüsselung der Patientenakte nämlich, die nur mit dem Token auf der Überweisung rückgängig gemacht werden können darf, ist auf so geradezu groteske Weise unsicher, daß man sich wundern muß, ob der "Erfinder" eines solchen Systems noch vertrauenswürdig genug sein kann, überhaupt irgendetwas in diesem Bereich zu implementieren. Das erscheint mir dann auch sehr viel schwerwiegender als die in dem Vortrag betonten Datenschutzfragen und Einzelprobleme; sicherlich sind Patientenakten sehr private und vertrauliche Daten, trotzdem würde ich meine Kreditkarten immer noch besser sichern als die Befunde meines Hausarztes. Und die Frage nach der praktisch erreichbaren Sicherheit einer Anwendung, die von zigtausend Ärzten und Arzthelferinnen in teilweise unsicheren Praxisnetzen bedient werden soll, ist sowieso sicherlich nicht einfach zu beantworten.

Aber greifen wir erstmal einige Beispiele aus der konkreten Implementation heraus. Bereits die verwendete Übertragungstechnik ist interessant. Zwar ist eine Datenübertragung per Telefon sicherer als eine solche über das Internet; dennoch erscheint es recht blauäugig, auf jede Sicherung von Server oder Client durch - bspw. - Firewalls zu verzichten (die explizit als unnötig bezeichnet werden), ebenso wie auf die Verschlüsselung der Übertragung und der dort verwendeten Paßworte (wobei offenbar ein Paßwort zudem fest im Programmcode verdrahtet ist und dort im Klartext ausgelesen werden kann). Das verzichtet auf weitere mögliche Sicherheitsebenen und beläßt als Schutz einzig und alleine die Sicherheit der Telefonleitung an sich (die natürlich durchaus angezapft werden kann, bspw. im Hausanschlußraum; zudem entsteht die Gefahr, daß ein einziger böswilliger Client den Server oder ein böswilliger - oder "gehackter" - Server alle Clients angreifen kann. Denn auf der Telefonleitung wird dann doch vollständiges TCP/IP gesprochen, d.h. eine ungeschützte Intranet-Verbindung hergestellt - und die Verwundbarkeit von Windows-Rechnern, die (mangels Internet-Verbindung!) vermutlich nicht regelmäßig geupdatet werden, ist keine neue Nachricht. (Daß über die ISDN-Verbindung auch Röntgen- und CT-Bilder mit Dateigrößen im Bereich vieler Megabyte übertragen werden sollen, woraus bei der vorhandenen Bandbreite Übetragungszeiten von mehreren Stunden (!) für jeden Einzelfall resultieren, weil sich diese Daten auch nicht sinnvoll komprimieren lassen, sei hier nur am Rande angemerkt; ebenso wie die Tatsache, daß die Implementation offensichtlich so ineffizient ist, daß aus unklaren Gründen gerade einmal 10% der theoretischen Bandbreite genutzt werden.)

Noch interessanter wird es bei der Betrachtung der digitalen Signatur mittels Chipkarte. Dem Gutachter fiel auf, daß ein Zugriff auf den Chipkartenleser nur genau einmal, beim Start des Systems, erfolgte, nicht aber bei jeder Unterschrift, wie es eigentlich erforderlich wäre; denn damit der private Schlüssel die sichere Chipkarte nicht verläßt, müßte für jeden Signaturvorgang erneut auf die Karte zugegriffen werden (und eine erneute PIN-Eingabe erfolgen). Nachdem das offensichtlich nicht der Fall war, ja das System nach dem Start auch mit abgestöpseltem Kartenleser funktionierte, ergab eine genauere Betrachtung, daß mit dem gesicherten privaten Schlüssel auf der Chipkarte nur ein anderer (!) privater Schlüssel auf dem Computer entschlüsselt wurde, der dann - unverschlüsselt - während der gesamten Laufzeit des Systems im Computer verblieb (und auch unverschlüsselt vom Chipkartenleser über die serielle Schnittstelle an den Rechner übertragen wurde). Bei dieser Implementation kann man sich den Aufwand eines Chipkartenlesers natürlich auch sparen (und muß damit leben, daß bei unbefugtem Zugriff auf den Computer oder ein "einhacken" auch der private Schlüssel kompromittiert wird, was wiederum bedeutet, daß unbemerkte Änderungen an den damit signierten Patientenakten möglich werden).

Eigentlicher Knackpunkt des Systems ist aber die Verschlüsselung der Daten mittels des Tokens, daß der Patient auf der Überweisung ausgedruckt erhält, die die Patientenakte nicht nur gegen außenstehende Dritte, sondern vor allem auch gegen den Systembetreiber und andere Ärzte sichern soll. Die Sicherheits des Systems steht und fällt damit, daß das Token - also quasi der Schlüssel, das Paßwort, mit dem die Daten entschlüsselt werden können - nicht erraten oder durch Ausprobieren gefunden werden kann, jedenfalls nicht in vertretbarer Zeit von Tagen, Wochen, Monaten oder Jahren, auch nicht bei Einsatz entsprechend großer Computerressourcen. Abhängig ist das zum einen von der Länge des Schlüssels, zum anderen von der Art, wie er gewählt wird. Ist der Schlüssel nur zwei Zeichen im Zeichenraum von 0-9 lang, gibt es nur 100 Möglichkeiten; die sind binnen Sekunden durch einen Computer ausprobiert. Ist der Schlüssel 100 Stellen lang, beginnt aber bei 00000….0001 und zählt dann immer eins weiter, ist er ebenfalls trivial angreifbar, nachdem man mal eine Handvoll dieser Schlüssel gesehen hat.

Die gewählte Schlüssellänge mit 21 alphanumerischen Zeichen (also A-Z und 0-9) erfüllt an sich bereits nur knapp die Anforderung, nach heutigem Stand der Mathematik und Kryptologie 70 Jahre lang sicher zu sein (d.h. das "Ausprobieren" aller möglichen Kombinationen führt dazu, daß im Durchschnitt erst nach 70 Jahren der richtige Schlüssel gefunden wird, obwohl man hinreichend starke Computer darauf ansetzt, die viele, viele Möglichkeiten pro Sekunde austesten können), wie dies für bestimmte Anwendungen im behördlichen Bereich gefordert wird; das wäre allerdings für die Übertragung von Patientenakten m.E. noch ein hinnehmbares Risiko. Immerhin gibt es dann 36 hoch 21 verschiedene Möglichkeiten für einen Schlüssel; eine kaum mehr faßbare Zahl von rund 500 Quintillionen (wenn ich mich nicht verrechnet habe ), eine Zahl mit 33 Stellen. Für eine Bewertung der Schlüsselsicherheit kann man dann zunächst statistische Untersuchungen anstellen; zu denen braucht man hinreichend viele (nämlich ein paar zigtausend) Schlüssel/Token, die der Gutachter dann auch erzeugt hat.

Dabei fielen zwei Dinge auf: Zum einen ergibt die Erzeugung von zwei Tokens innerhalb der selben Sekunde das identische (!) Token, d.h. es wird ein zeitabhängiger Algorithmus eingesetzt, der nur auf eine Sekunde genau auflöst. Ist bereits das alarmierend, ergibt ein einziger Blick auf zwei Dutzend Tokens auch für den Laien im Publikum eine schon geradezu groteske Feststellung - die ersten Zeichen dieser Tokens sind nämlich alle gleich! Eine genauere Betrachtung ergibt dann, daß von dem 21 Zeichen langen Schlüssel gerade mal 5 Zeichen wirklich "zufällig" erzeugt werden. Der Rest ist eine ID-Nummer des Arztes bzw. des Rechners, das Tagesdatum und ein jeden Tag bei 1 beginnender Zähler - für die Frage der Datensicherheit also ohne Relevantz, weil ohne Mühe bestimmbar. Der Schlüssel ist also in Wahrheit nicht 21, sondern nur 5 Stellen lang und damit bereits in handhabbarer Zeit zu brechen.

Doch es kommt noch schlimmer. Die Sicherheit eines Schlüssels ist nämlich auch davon abhängig, wie zufällig er gewählt ist, d.h. ob alle Zeichen (A-Z, 0-9) wirklich zufällig verteilt gleichmäßig häufig vorkommen. Bei einem guten Algorithmus sollte eine graphische Darstellung daher eine wilde, unstrukturierte Wolke von Punkten darstellen, aber keinesfalls geometrische Muster, die auf eine dahinterliegende Funktion rückschließen lassen. Leider ist auch das bei dem ohnehin schon kurzen Token nicht der Fall. Bei einer graphischen Darstellung der Abhängigkeiten zwischen aufeinanderfolgenden Token ergeben sich … drei verschiedene Geraden. Daraus folgt, daß es für einen zu einer gegebenen Zeit erzeugten Schlüssel noch genau drei (!) verschiedene Möglichkeiten gibt. Dafür hingegen braucht es kaum mehr einen Computer …

Nun könnte man natürlich sagen, der Angreifer müsse dazu ja die genaue Zeit kennen, zu der die betreffende verschlüsselte Datei erzeugt wurde (sonst braucht er vielleicht nicht drei Versuche, sondenr muß doch einen Computer ein paar Tage rechnen lassen). Bei der Antwort des Referenten auf diesen Einwand brach sich dann übrigens schallendes Gelächter im Publikum Bahn: Man muß nämlich wissen, daß die übertragenen Dateien auf dem Server umbenannt werden. Und was erhalten sie als Namen? Genau - unter anderem die Uhrzeit ihrer Erzeugung …

Keine Fragen mehr, euer Ehren.

(Nein, ich bin selbst kein IT-Sicherheitsfachmann. Und wenn ich weiter oben Unsinn geschrieben haben sollte, dann dürfte das an mir liegen, nicht am Referenten. Ich lasse mich aber gerne belehren. )