Universität Karlsruhe
Fakultät für Informatik

Institut für Algorithmen und Kognitive Systeme

Diplomarbeit

Analyse, Verifikation und Realisierung
kryptographischer Protokolle für
flexible Zugriffe auf medizinische Datenbanken

Erik-Oliver Blafl
Betreuer: Prof. Dr. Thomas Beth
Betreuender Mitarbeiter: Dipl. Inform. Jörg Moldenhauer

8. Oktober 2001

Kurzfassung
Der Umgang mit sensiblen Patientendaten stellt hohe Anforderungen an deren Vertraulichkeit und Integrität. Für einen entfernten, elektronischen Zugriff auf solche Daten und deren elektronische Verarbeitung sind besondere Sicherheitsvorkehrungen nötig, um Geheimhaltung und Schutz vor Mißbrauch zu gewährleisten. Ein Problem dabei sind insbesondere die zeitlich veränderlichen Zuständigkeiten und Verantwortlichkeiten für Patientendaten im klinischen Alltag.

In dieser Arbeit werden auf bestehenden kryptographischen Komponenten basierende Protokolle zum Zugriff auf medizinische Daten entwickelt, die diese Anforderungen gezielt umsetzen. Dazu gehören die gesicherte Speicherung der medizinischen Daten in speziell hierfür entwickelten Datenbanken sowie eine funktionsspezifische Rechtverwaltung und Zugangskontrolle mittels sogenannter Rollen.

Die erarbeiteten Protokolle und das Umfeld ihres Einsatzes werden auf verschiedenen Ebenen analysiert und ihre Sicherheit formal bewiesen. Mit einer Implementierung in Java wird die Einsatzfähigkeit der Protokolle gezeigt. Die Verwendung von CORBA-Kommunikationsmechanismen erlaubt die Einbindung in ein verteiltes medizinisches Informationssystem, das vom IAKS im Rahmen des Teilprojekts Q6 des SFB 414 "Informationstechnik in der Medizin" als Prototopy entwickelt wird.

Inhaltsverzeichnis

1 Einleitung ... 1
    1.1 Aufgabenstellung ... 2
    1.2 Sicherheitsrelevante Anforderungen ... 4

2 Kryptographie ... 7
    2.1 Chiffren ... 7
        2.1.1 AES ... 8
        2.1.2 RSA ... 9
    2.2 Digitale Signaturen ... 10
        2.2.1 SHA-1... 11
        2.2.2 Zertifikate und Zertifizierungsstellen ... 12
    2.3 Shared-Secrets ... 13
    2.4 Kommutative Chiffren ... 15
        2.4.1 One-Time-Pad ... 15
        2.4.2 Drei-Wege-XOR ... 16
    2.5 Zufallszahlen ... 16
    2.6 Logic of Authentication ... 19
        2.6.1 Notation der Logic of Authentication ... 20
        2.6.2 RVLogik, eine Erweiterung der BAN-Logik ... 24

3 Protokolle ... 29
    3.1 Gemeinsamkeiten der entwickelten Protokolle ... 29
    3.2 Shared Protokoll ... 30
        3.2.1 Zertifikate ... 32
        3.2.2 Formalisierte Nachrichten ... 33
    3.3 Zyklisches Protokoll ... 41
        3.3.1 Ablauf ... 42
        3.3.2 Formalisierte Nachrichten ... 44
    3.4 Geschwindigkeit und Bewertung ... 49
    3.5 Update-Mechanismus ... 51

4 Analyse ... 53
    4.1 Verwendete Chiffren ... 54
        4.1.1 AES, RSA und SHA-1 ... 54
        4.1.2 Shared-Secrets ... 56
        4.1.3 FIPS 140-1 ... 56
        4.1.4 Bewertung ... 57
    4.2 Logic of Authentication ... 58
        4.2.1 Grundlagen ... 58
        4.2.2 Erforderliche Anpassungen ... 58
        4.2.3 Shared Protokoll ... 59
        4.2.4 Zyklisches Protokoll ... 63
    4.3 Laufzeitumgebung ... 67
        4.3.1 Vom Quell-Code zur JVM ... 67
        4.3.2 Risiken und Schutzmechanismen der JVM ... 67
        4.3.3 CORBA ... 70
    4.4 Implementierung ... 71
    4.5 Denial of Service ... 73
        4.5.1 Verbrauch begrenzter Ressourcen ... 73
        4.5.2 Verändern der Konfiguration ... 74
        4.5.3 Physikalische Zerstörung ... 75

5 Implementierung ... 77
    5.1 iSaSilk ... 77
    5.2 Shared-Secrets ... 78
    5.3 Generieren von Zufallszahlen ... 79
    5.4 ProcessQueryWrapper ... 81
    5.5 Rollenproxy ... 82
        5.5.1 Crypt ... 83
        5.5.2 Rollenverwaltung ... 83
        5.5.3 Durchführung der Protokolle ... 84
        5.5.4 Sicherheit der RoleProxy-Klasse ... 85
    5.6 Update-Mechanismus ... 86
    5.7 Benutzen der Protokolle ... 87
    5.8 CORBA ... 88
    5.9 Änderungen am RVChecker ... 89
    5.10 Werkzeuge ... 90
        5.10.1 Annotationen ... 90
        5.10.2 Pseudonymisierer ... 95

6 Zusammenfassung ... 99

Abbildungsverzeichnis
1.1 Schema des Datenzugriffs im Szenario ... 4
2.1 Struktur eines X.509 Zertifikat ... 12
3.1 Übersicht Shared Protokoll ... 31
3.2 Reihenfolge der Nachrichten im Shared Protokoll ... 32
3.3 Man in the Middle ... 34
3.4 Übersicht Zyklisches Protokoll ... 42
3.5 Reihenfolge der Nachrichten im Zyklischen Protokoll ... 44
4.1 Aufteilung der Analyse in Ebenen der Entwicklung ... 53
4.2 Vom Quell-Code zur individuellen Plattform ... 68
5.1 UML-Diagramm des Zufallszahlengenerators ... 80
5.2 UML-Diagramm des Rollenproxys ... 82
5.3 UML-Diagramm des zyklischen Datenbank-Servers ... 87
5.4 Kaskade von drei Annotationen ... 90
5.5 Pseudonymisieren in zwei Stufen ... 95

Tabellenverzeichnis
2.1 Prädikate der BAN-Logik ... 22
2.2 Grundlegende BAN-Ableitungsregeln ... 23
3.1 Geschwindigkeit der beiden Protokolle ... 50
4.1 FIPS 140-1 Runs Test ... 57

Listings
Secret.java ... 78
MISRandom.java ... 79
QueryData.java ... 81
ProcessQueryWrapper.java ... 82
Crypt.java ... 83
RoleProxy.java ... 84
GetUpdate.java ... 86
RV.java ... 89
PatientAnnotation.java ... 91
PatientRecord.java ... 92
MISPseudo.java ... 96

Kapitel 1
Einleitung
Das Institut für Algorithmen und kognitive Systeme (IAKS [1]) der Universität Karlsruhe arbeitet im Sonderforschungsbereich 414 der Deutschen Forschungsgemeinschaft (DFG) am Datenschutz und der Systemsicherheit in medizinischen Informationssystemen. Ein Szenario hierbei ist die elektronische Verwaltung von Patientendaten, d. h. ein rechnerbasiertes Abspeichern und ein entfernter Zugriff auf diese.

Elektronisch gespeicherte medizinische Daten eines Patienten haben als Ersatz für die klassische Papier-Patientenakte einige Vorteile: Sie bieten neben verwaltungstechnischen oder abrechnungstechnischen Vorzügen eines einzelnen Krankenhauses noch die Möglichkeit des computer-unterstützten, eventuell weltweiten Zugriffs auf komplette Krankengeschichten und somit einen enormen Vorteil für neue Diagnosen und Behandlungen. Denkbar sind außerdem Dinge wie das Anlegen von großen Statistiken bestimmter Krankheitsbilder über einen langen Zeitraum hinweg mit anonymen Patientendaten oder der internationale Austausch und das gegenseitige Helfen bei Problemfällen.

Auf der anderen Seite muß der elektronische Zugriff auf die persönlichen Daten eines Patienten entsprechend gesichert werden. Unberechtigtes Lesen, Ändern oder Löschen einer Akte kann nicht nur die wichtige Intimsphäre des Patienten verletzen, sondern auch fatale Auswirkungen auf Leib und Leben haben. Auch darf der entsprechend autorisierte behandelnde Arzt nur Zugang zu den für ihn relevanten Patienteninformationen haben. Bei einer Grippebehandlung sind mögliche Allergien relevant, ein vorhergehender Aufenthalt in einer Psychiatrie jedoch nicht. Die genauen Rahmenbedingungen und Anforderungen im medizinischen Umfeld sind in Abschnitt 1.2 beschrieben.

1.1 Aufgabenstellung
In dieser Arbeit geht es um die Frage, wie Protokollabläufe für lesende, schreibende und löschende Datenzugriffe auf eine medizinische Datenbank mit sensitiven Daten kryptographisch sicher durchgeführt werden können.

Im Fokus der Arbeit steht die Analyse von solchen Protokollen zum Zugriff auf medizinische Datenbanken im Hinblick auf die noch zu beschreibenden Anforderungen.

Den zweiten Schwerpunkt bildet die Realisierung der Protokolle. Sie sollen die Grundlage für ein prototypisches medizinisches Informationssystem bilden, das derzeit am IAKS im Rahmen des Projekts Q6 des SFB 414 entwickelt wird. Die Implementierung soll in Java erfolgen und Kommunikationsabläufe zwischen beteiligten Protokollinstanzen über CORBA [28] abgewickelt werden.

Beschreibung des Szenarios
Im behandelten Szenario sollen beliebige medizinische Daten, d. h. Daten über Patienten, Krankengeschichten, prinzipiell alles, was in klinischem Umfeld an Daten anfallen kann, elektronisch abgelegt und wieder zugreifbar gemacht werden. Benutzer dieses Systems sind z. B. Ärzte, Schwestern oder auch Patienten selbst.

Zugriffe dieser Benutzer auf den Datenbestand können entweder statischer oder dynamischer Struktur sein [2]. Bei statischen Systemen sind einzelne Datensätze fest an bestimme Personen gebunden. Nur die Person, die den Datenbestand angelegt und verschlüsselt hat, kann in der Regel darauf zurückgreifen. Die Zugriffsfreigabe auf den angelegten Datenbestand für Dritte stellt insofern ein technisches Problem dar, da nur der Erzeuger der Daten im Besitz des entsprechenden Schlüssels zum Dechiffrieren ist.

Gerade im medizinischen Umfeld treten jedoch häufig Fälle ein, die eine etwas kompliziertere Zuordnung benötigen. Behandelt beispielsweise ein Stationsarzt einen Patienten, wird jedoch am nächsten Tag auf Grund eines Schichtwechsels von einem Kollegen abgelöst, so muß der neue Kollege auch auf die Patientenakte zugreifen können. Der bisherige Arzt darf jedoch die Krankengeschichte des Patienten dann nicht mehr oder nur sehr eingeschränkt weiterverfolgen. Welcher Arzt gerade genau welche Möglichkeiten des Zugriffs hat, wird durch verschiedene Regeln entschieden, die abhängig vom Dienstplan, der aktuellen Situation, z. B. einem Notfall, und der eigentlichen Funktion des Arztes ausgewertet werden müssen. Der Zugriff auf die persönlichen Daten geschieht somit dynamisch - die häufig wechselnden Zuständigkeiten sind durch die statischen Strukturen nicht zu erfassen.

Ein grundlegendes Prinzip des Systementwurfs ist daher zunächst die Vergabe von Rollen an Benutzer, bzw. das Auftreten der Benutzer innerhalb einer Rolle. Im System selbst handeln verschiedene Benutzer, d. h. im Sinne von verschiedenen Individuen, z. B. "Christian Müller" oder "Hans Schmidt", idealerweise nur innerhalb einer Rolle, so z. B. in den Rollen "Chefarzt" oder "Stationsarzt". Benutzer treten im System nicht mehr als Personen oder Individuen auf, sondern funktionsorientiert. Geheimnisse wie Schlüssel zum Entschlüsseln von Daten können damit bestimmten Funktionen zugeordnet werden, etwa je ein Schlüssel für die Rollen "Chefarzt" und "Stationsarzt". Ein Benutzer, der sich am System anmeldet, bekommt dynamisch eine Rolle zugeordnet oder bewirbt sich bei einem zentralen Rollenserver um eine Rolle. Dieser Server entscheidet nach bestimmten Regeln, wie den Vorgaben eines vorher erstellen Dienstplans, oder nach Maßnahmen der Notfallbehandlung, ob ein Benutzer zu diesem Zeitpunkt eine Rolle einnimmt. Danach tritt der Benutzer im System nur noch unter dieser Rolle auf. Er bekommt vom Rollenserver die Schlüssel zum Entschlüsseln der entsprechenden Daten zugeordnet. Alle Transaktionen (Zugriffe) auf den Datenbestand geschehen, wie oben erwähnt, im Namen dieser Rolle. Der Benutzer kreiert sich dabei einen sogenannten Rollenproxy, der für ihn den Datenzugriff stellvertretend im Namen seiner Rolle, sowie sämtlichen kryptographischen Protokolle transparent durchführt. Zu einem späteren Zeitpunkt kann der Nutzer diese Rolle, und damit das Geheimnis, freiwillig wieder abgeben oder wird dazu durch ein Regelsystem gezwungen.

Das Schema dieser Zugriffsregelung ist in Abbildung 1.1 dargestellt. Von fundamentaler Bedeutung für dieses Schema ist neben dem Rollenserver auch der Rechteserver. Alle Transaktionen werden von dieser Entität aus genehmigt respektive abgelehnt. Will ein Benutzer bzw. die ihn repräsentierende Rolle durch den Rollenproxy eine Transaktion durchführen, so benötigt er dazu zunächst eine entsprechende Autorisierung durch den Rechteserver. Anhand dieser Autorisierung kann später die angesprochene Datenbank verifizieren, ob der aktuelle Zugriff der Rolle legal ist. In Abbildung 1.1 ist bereits die Position der zu analysierenden Protokolle innerhalb des Systems zu erkennen. Sie werden zwischen Benutzern/Rollen und den Datenbanken vermitteln, um Anfragen sicher durchzuführen. Genauso werden die gestrichelten Verbindung zu sichern sein. Dies wird in Kapitel 3 ausführlich erklärt.

Das Auftreten von Benutzern als Rollen im System steuert bereits in gewissem Maße auch zur Sicherheit bei. Es müssen keine Rechte bestimmt oder Sicherheitsvorkehrungen mehr für jeden einzelnen Benutzer getroffen werden, sondern nur noch für Rollen. Dies hilft bei Änderungen, die am Rechtesystem durchgeführt werden müßten, wenn neue Benutzer dem System hinzugefügt werden oder alte Benutzer das System verlassen, siehe hierzu [21].

!! Abbildung in dieser Vorschau nicht verfügbar !!
Abbildung 1.1: Schema des Datenzugriffs im Szenario

1.2 Sicherheitsrelevante Anforderungen
Die Arbeiten [2] und [21] geben eine Übersicht über die sicherheitsrelevanten Anforderungen in medizinischen Informationssystemen. Zunächst gelten für alle gespeicherten oder übertragenen (Patienten-)Daten die vier klassischen kryptographischen Anforderungen, wie sie allgemein für alle sicheren Systeme vorausgesetzt werden:

1. Vertraulichkeit
   Diese Anforderung ist die offensichtlichste der vier. Es geht um die Geheimhaltung der Informationen gegenüber unbefugtem Mitlesen während einer Datenübertragung oder beim unberechtigten Zugriff direkt auf den Speicherort der Daten. In Falle klinischer Informationssysteme muß beispielsweise sichergestellt sein, daß nur der entsprechend autorisierte Arzt die angeforderten Informationen über einen Patienten lesen darf. Dies macht nicht nur eine Form von Rechtesystem erforderlich, z. B. einen Rechteserver, der verwaltet, welcher Arzt genau wie zugreifen darf, sondern auch die Notwendigkeit der Verschlüsselung/Chiffrierung der eigentlichen Daten. Ziel dieser 1.2 Sicherheitsrelevante Anforderungen 5
   Vertraulichkeitsanforderung ist es, daß ein potentieller Angreifer aus dem zufälligen oder unberechtigten Mitlesen der chiffrierten Nutzdaten keinerlei Rückschlüsse auf die eigentlichen Nutzdaten ziehen kann [31].
2. Integrität
   Es muß sichergestellt sein, daß Daten unverändert vom Sender zum Empfänger gelangen. Die verschlüsselten gesendeten Daten müssen gleich den entschlüsselten empfangenen Daten sein. Auf keinen Fall darf durch unabsichtliche Übertragungsfehler oder gar absichtliche Manipulation während der Übertragung der Inhalt der Daten unbemerkt verändert werden. Sind Daten verändert worden, so muß dies den Benutzern sofort ersichtlich sein. Es ist von außerordentlicher Wichtigkeit, daß nicht autorisierte Personen keine Patientendaten verändern können.

[...]