Erkl¨ arung

Ich versichere, diese Arbeit selbst¨ andig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt zu haben.

Karlsruhe, den 8. Oktober 2001

(Erik-Oliver Blaß)

Kurzfassung

Der Umgang mit sensiblen Patientendaten stellt hohe Anforderungen an deren Vertraulichkeit und Integrit¨ at. F¨ ur einen entfernten, elektronischen Zugriff auf solche Daten und deren elektronische Verarbeitung sind besondere Sicherheitsvorkehrungen n¨ otig, um Geheimhaltung und Schutz vor Mißbrauch zu gew¨ ahrleisten. Ein Problem dabei sind insbesondere die zeitlich ver¨ anderlichen Zust¨ andigkeiten und Verantwortlichkeiten f¨ ur 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¨ oren die gesicherte Speicherung der medizinischen Daten in speziell hierf¨ ur 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¨ ahigkeit 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.

v

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

vii

viii

Inhaltsverzeichnis

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 andern der Konfiguration  74

4.5.3  Physikalische Zerst orung  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

ix

Inhaltsverzeichnis

5.5.1  Crypt  83

5.5.2  Rollenverwaltung  83

5.5.3  Durchf uhrung 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   

  Anderungen am RVChecker  89

5.10  Werkzeuge  90

5.10.1  Annotationen  90

5.10.2  Pseudonymisierer  95

6  Zusammenfassung  99

x Inhaltsverzeichnis

  Abbildungsverzeichnis  

1.1  Schema des Datenzugriffs im Szenario  4

2.1  Struktur eines X.509 Zertifikat  12

3.1   

  Ubersicht Shared Protokoll  31

3.2  Reihenfolge der Nachrichten im Shared Protokoll  32

3.3  Man in the Middle  34

3.4   

  Ubersicht 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

xi

xii

  Abbildungsverzeichnis  

  Tabellenverzeichnis  

2.1  Pr adikate 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

xiii

xiv Tabellenverzeichnis

Listings

xv

Kapitel 1

Einleitung

Das Institut f¨ ur Algorithmen und kognitive Systeme (IAKS [1]) der Universit¨ at 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¨ ur die klassische Papier-Patientenakte einige Vorteile: Sie bieten neben verwal- tungstechnischen oder abrechnungstechnischen Vorz¨ ugen eines einzelnen Kran- kenhauses noch die M¨ oglichkeit des computer-unterst¨ utzten, eventuell weltweiten Zugriffs auf komplette Krankengeschichten und somit einen enormen Vorteil f¨ ur neue Diagnosen und Behandlungen. Denkbar sind außerdem Dinge wie das Anle- gen von großen Statistiken bestimmter Krankheitsbilder ¨ uber einen langen Zeit-

und das gegenseitige Helfen bei Problemf¨ allen.

Auf der anderen Seite muß der elektronische Zugriff auf die pers¨ onlichen Daten eines Patienten entsprechend gesichert werden. Unberechtigtes Lesen, ¨ Andern oder

L¨ oschen einer Akte kann nicht nur die wichtige Intimsph¨ are des Patienten verlet- zen, sondern auch fatale Auswirkungen auf Leib und Leben haben. Auch darf der entsprechend autorisierte behandelnde Arzt nur Zugang zu den f¨ ur ihn relevanten Patienteninformationen haben. Bei einer Grippebehandlung sind m¨ ogliche Aller- gien relevant, ein vorhergehender Aufenthalt in einer Psychiatrie jedoch nicht.

Die genauen Rahmenbedingungen und Anforderungen im medizinischen Umfeld sind in Abschnitt 1.2 beschrieben.

1

2 Kapitel 1 Einleitung

1.1 Aufgabenstellung

In dieser Arbeit geht es um die Frage, wie Protokollabl¨ aufe f¨ ur lesende, schreibende und l¨ oschende Datenzugriffe auf eine medizinische Datenbank mit sensitiven Daten kryptographisch sicher durchgef¨ uhrt werden k¨ onnen. 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¨ ur 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¨ aufe zwischen beteiligten Protokollinstanzen ¨ uber CORBA [28] abgewickelt werden.

Beschreibung des Szenarios

Im behandelten Szenario sollen beliebige medizinische Daten, d. h. Daten ¨ uber

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. ¨ Arzte, Schwestern oder auch Patienten selbst.

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

Gerade im medizinischen Umfeld treten jedoch h¨ aufig F¨ alle ein, die eine etwas kompliziertere Zuordnung ben¨ otigen. Behandelt beispielsweise ein Stationsarzt einen Patienten, wird jedoch am n¨ achsten Tag auf Grund eines Schichtwechsels von einem Kollegen abgel¨ ost, so muß der neue Kollege auch auf die Patientenakte zugreifen k¨ onnen. Der bisherige Arzt darf jedoch die Krankengeschichte des Patienten dann nicht mehr oder nur sehr eingeschr¨ ankt weiterverfolgen. Welcher Arzt gerade genau welche M¨ oglichkeiten des Zugriffs hat, wird durch verschiedene Regeln entschieden, die abh¨ angig vom Dienstplan, der aktuellen Situation, z. B. einem Notfall, und der eigentlichen Funktion des Arztes ausgewertet werden m¨ ussen. Der Zugriff auf die pers¨ onlichen Daten geschieht somit dynamisch - die h¨ aufig wechselnden Zust¨ andigkeiten sind durch die statischen Strukturen nicht zu erfassen.

Ein grundlegendes Prinzip des Systementwurfs ist daher zun¨ achst die Vergabe von Rollen an Benutzer, bzw. das Auftreten der Benutzer innerhalb einer Rolle.

1.1 Aufgabenstellung

Im System selbst handeln verschiedene Benutzer, d. h. im Sinne von verschiedenen Individuen, z. B. ” Christian M¨ uller“ 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¨ ussel zum Entschl¨ usseln von Daten k¨ onnen damit bestimmten Funktionen zugeordnet werden, etwa je ein Schl¨ ussel f¨ ur die Rollen Chefarzt“ und ” Stationsarzt“. Ein Benutzer, der sich am System anmeldet, be-

kommt 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¨ ussel zum Entschl¨ usseln der entsprechenden Daten zugeordnet. Alle Transaktionen (Zugriffe) auf den Datenbestand geschehen, wie oben erw¨ ahnt, im Namen dieser Rolle. Der Benutzer kreiert sich dabei einen sogenannten Rollenproxy, der f¨ ur ihn den Datenzugriff stellvertretend im Namen seiner Rolle, sowie s¨ amtlichen kryptographischen Protokolle transparent durchf¨ uhrt. Zu einem sp¨ ateren 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¨ ur dieses Schema ist neben dem Rollenserver auch der Rechteserver. Alle Transaktionen werden von dieser Entit¨ at aus genehmigt respektive abgelehnt. Will ein Benutzer bzw. die ihn repr¨ asentierende Rolle durch den Rollenproxy eine Transaktion durchf¨ uhren, so ben¨ otigt er dazu zun¨ achst eine entsprechende Autorisierung durch den Rechteserver. Anhand dieser Autorisierung kann sp¨ ater 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¨ uhren. Genauso werden die gestrichelten Verbindung zu sichern sein. Dies wird in Kapitel 3 ausf¨ uhrlich erkl¨ art.

Das Auftreten von Benutzern als Rollen im System steuert bereits in gewissem Maße auch zur Sicherheit bei. Es m¨ ussen keine Rechte bestimmt oder Sicherheitsvorkehrungen mehr f¨ ur jeden einzelnen Benutzer getroffen werden, sondern nur noch f¨ ur Rollen. Dies hilft bei ¨ Anderungen, die am Rechtesystem durchgef¨ uhrt

werden m¨ ußten, wenn neue Benutzer dem System hinzugef¨ ugt werden oder alte Benutzer das System verlassen, siehe hierzu [21].

4 Kapitel 1 Einleitung

1.2 Sicherheitsrelevante Anforderungen

Die Arbeiten [2] und [21] geben eine ¨ Ubersicht ¨ uber die sicherheitsrelevanten Anforderungen in medizinischen Informationssystemen. Zun¨ achst gelten f¨ ur alle gespeicherten oder ¨ ubertragenen (Patienten-)Daten die

vier klassischen kryptographischen Anforderungen, wie sie allgemein f¨ ur alle si- cheren Systeme vorausgesetzt werden:

1.2 Sicherheitsrelevante Anforderungen

2. Integrit¨ at

3. Authentizit¨ at

4. Verbindlichkeit

haben.

Spezielle Anforderungen im medizinischen Bereich

Speziell f¨ ur das in dieser Arbeit untersuchte medizinisch/klinische Umfeld gelten zus¨ atzliche Anforderungen, die ber¨ ucksichtigt werden m¨ ussen:

6 Kapitel 1 Einleitung

Kapitel 2

Kryptographie

Dieses Kapitel soll zun¨ achst ein kurze Einf¨ uhrung in grundlegende kryptographische Techniken, wie symmetrische und asymmetrische Chiffren, Zufallszahlen, sowie Signaturen und Zertifikate, die in Kapitel 3 Verwendung finden und die der Klarheit der Analyse dienen. Auch die Verfahren wie Shared-Secrets oder kommutative Chiffren, auf denen die Sicherheit der Protokolle basieren, werden hier zum besseren Verst¨ andnis von Kapitel 3 bereits erkl¨ art. Schließlich wird die formale Protokoll-Analysemethode Logic of Authentication beschrieben

2.1 Chiffren

Das Verschl¨ usseln bzw. Chiffrieren von Daten dient in erster Linie der Vertraulichkeit, also dem Schutz vor unberechtigtem Mitlesen von Geheimnissen. Jedes Chiffriersystem arbeitet nach folgendem Prinzip [39]:

Da bei dieser Form von Verschl¨ usselungssystemen die Sicherheit von der Ge- ¹ ,sind die Funktionen E und D meistens heimhaltung von E und D abh¨ angt

¹ ist einem Angreifer D bekannt, so kann er M = D(C) berechnen

7

8 Kapitel 2 Kryptographie

uber (mindestens) einen zus¨ atzlichen Parameter k parametrisiert. k ist der gehei¨

me Schl¨ ussel des Chiffriersystems. Es sollte gelten k 1 = k 2 → E ^k 1 (M ) = E ^k 2 (M ). Dies hat zur Konsequenz, daß mehrere Benutzer dasselbe ¨ offentlich bekannte Chiffriersystem benutzen k¨ onnen, ohne gegenseitig vertrauliche Daten mitzulesen, solange sie nicht im Besitz des geheimen Schl¨ ussels sind. Die Sicherheit einer solchen parametrisierten Chiffre h¨ angt dann nur vom Schl¨ ussel und nicht von der Geheimhaltung des Chiffriersystems ab, es sei denn, die Chiffre an sich h¨ atte eine ausnutzbare Schw¨ ache.

Je nach Schl¨ usseltyp unterscheidet man Chiffren in

Nutzdaten verwendet wird.

2.1.1 AES

Das National Institute of Standards and Technology (NIST) hat auf der Suche nach einem offiziellen Nachfolger des veralteten Data Encryption Standard (DES [23]) mehrere verschiedene Verschl¨ usselungs-Algorithmen auf ihre Sicherheit, Geschwindigkeit und Flexibilit¨ at hin ¨ uberpr¨ uft und schließlich den Algo-

2.1 Chiffren

rithmus Rijndael ausgew¨ ahlt. Eine Beschreibung ¨ uber den Aufbau und die Arbeitsweise von Rijndael findet sich in [16]. Rijndael wird Ende 2001 der offizielle Nachfolger von DES und heißt dann Advanced Encryption Standard (AES [9]). AES wird sowohl im ¨ offentlichen als auch im privaten Datenverkehr zur Verschl¨ usselung von sensitiven Daten dienen. Der Rijndael/AES Algorithmus verschl¨ usselt Daten(-bl¨ ocke) mit einer Gr¨ oße von 128 Bits. Er ist ein Beispiel f¨ ur eine symmetrische Chiffre, denn es gibt nur einen geheimen Schl¨ ussel zur Ver-und Entschl¨ usselung. Rijndael gilt bisher als sicher: Der effizienteste Weg Rijndael zu brechen ist nach heutigem Ermessen das Erraten des richtigen Schl¨ ussels. ²⁵⁶ verschiedene Bei einer Schl¨ ussell¨ ange zwischen 128 und 256 Bit gibt es bis zu 2 m¨ ogliche Schl¨ ussel, die ein Angreifer probieren m¨ ußte. Dies ist eine sogenannte Brute-Force Attacke, wobei der Angreifer sukzessive alle m¨ oglichen Schl¨ ussel ausprobiert. ²³³ Zum Vergleich: die Anzahl der Atome in unserer Galaxie wird auf nur 2 gesch¨ atzt. Selbst bei einer Schl¨ ussell¨ ange von 128 Bit br¨ auchte ein Supercom- ²⁵ puter, der eine Millionen Schl¨ ussel pro Sekunde probieren kann, immernoch 10 Jahre [4]. AES ist nicht nur sehr sicher, sondern auch portabel, schnell und effektiv. Außerdem kann er effizient auf Chipkarten implementiert werden [5]. Der Rijndael-Code paßt in 52 Bytes. Er ist im Gegensatz zu anderen symmetrischen Algorithmen, wie IDEA [4] flexibel in seiner Schl¨ ussell¨ ange und es existieren keine Patentprobleme. Jeder darf AES benutzen.

Auf Grund dieser Vorteile wird er in dieser Arbeit bei der Implementierung der entwickelten Protokolle als symmetrische Chiffre verwendet.

2.1.2 RSA

Rivest, Shamir und Adlemann haben 1978 den nach ihnen benannten, sehr erfolgreichen Public-Key Algorithmus RSA vorgestellt. Aufbau und Arbeitsweise sind beschrieben in [33]. Zum Erzeugen von ¨ offentlichem und privatem Schl¨ ussel werden zwei m¨ oglichst gleichgroße Primzahlen p und q gew¨ ahlt und

n = pq

berechnet. Der ¨ offentliche Schl¨ ussel e wird zuf¨ allig aus dem Bereich 3 ≤ e < n

gew¨ ahlt und zusammen mit n ver¨ offentlicht. e hat die Eigenschaft: ggT (e, (p − 1)(q − 1)) = 1.

Der private Schl¨ ussel d ist das Inverse zu e mod (p − 1)(q − 1) und kann durch den erweiterten euklidischen Algorithmus eggT (e, (p − 1)(q − 1))

10 Kapitel 2 Kryptographie

ermittelt werden. F¨ ur das Chiffrieren eines Klartextes M wird das Chiffrat C durch ^e mod n C = M

berechnet. Das Entschl¨ usseln funktioniert ¨ uber

^d mod n. M = C

Ein Angreifer ist nicht im Besitz von p oder q, sondern kennt nur n. Um von n und e auf d zu schließen, w¨ urde er p und q (die Primfaktorzerlegung von n) f¨ ur den erweiterten Euklid brauchen. Die Sicherheit von RSA basiert nach bisherigen Erkenntnissen auf dem Problem, f¨ ur sehr große Zahlen eine Primfaktorzerlegung ²⁰⁴⁸ . Das ist zu finden. Große Zahlen sind Zahlen in der Gr¨ oßenordnung von etwa 2 eine Zahl mit 617 Ziffern. Die Faktorisierung einer solchen Zahl mit den bisher bekannten mathematischen Techniken, wie dem speziellen Zahlk¨ orpersieb, dau- ⁶ Jahre.Allerdings werden in Zukunft mit ert selbst auf Großrechnern etwa 10

Sicherheit neue, schnellere Algorithmen zum Faktorisieren entwickelt werden. RSA ist weit verbreitet und gut untersucht. Die Schl¨ ussell¨ angen und damit auch die zu faktorisierenden Zahlen sind beliebig vergr¨ oßerbar. Da RSA außerdem in der Lage ist, Signaturen (s. Abschnitt 2.2) zu erstellen, wird diese Chiffre bei der Implementierung des Protokolls als Public-Key Algorithmus eingesetzt.

2.2 Digitale Signaturen

Wie in Abschnitt 1.2 bereits angedeutet, werden digitale Signaturen zum Sicherstellen von Authentizit¨ at in den Protokollen ben¨ otigt. Digitale Signaturen werden genauso oder ¨ ahnlich wie handschriftliche Unterschriften arbeiten. Sie werden, fest mit einem Dokument verbunden, einem ” Verifizierer“ den Beweis liefern, daß

ein bestimmter Autor dieses Dokument unterschrieben hat - mit den entsprechenden Konsequenzen (Authentizit¨ at, siehe 3). Zudem soll das unterschriebene (elektronische) Dokument nach der Unterschrift nicht mehr ver¨ anderbar sein (In- tegrit¨at). Außerdem darf ein Autor eine Unterschrift m¨ oglichst nicht mehr abstreiten k¨ onnen (Verbindlichkeit).

Asymmetrische (Public-Key) Chiffren eignen sich zum Anfertigen und ¨ Uberpr¨ ufen von Signaturen ganz besonders. Wenn Benutzer A ein Dokument M unterschreiben will, und B diese Signatur zu dem Dokument ¨ uberpr¨ ufen will, so geschieht dies folgerndermaßen:

Unterschrift von A zum Dokument M .

2.2 Digitale Signaturen

2. A sendet das Tupel (M, C) an B, also das Dokument selbst und die dazu passende Unterschrift.

3. B will die Unterschrift ¨

Da der eigentliche Signaturvorgang (1.) mit Public-Key Systemen beim Unterschreiben von großen Datenmengen meist sehr langwierig ist, beschr¨ ankt man sich oftmals auf die Unterschrift des Hash-Wertes eines elektronischen Dokumentes. Der Hash-Wert eines elektronischen Dokumentes ist die Ausgabe einer (kryptographischen) Hash-Funktion H, mit dem Dokument als Eingabe. Eine Hash-Funktion berechnet aus einer beliebig langen Eingabe eine Art Zusammenfassung oder Fingerabdruck, d.h. aus der langen Eingabe wird eine wesentlich k¨ urzere aber doch das Dokument fast eindeutig repr¨ asentierende Ausgabe erzeugt. Kryptographische Hash-Funktionen sind ” Einweg-Funktionen“, d. h. aus

einem Hash-Wert ist es nur sehr schwierig oder unm¨ oglich zur¨ uck auf die Eingabe der Hash-Funktion zu schließen.

Der erzeugte kurze Hashwert h = H(M ) wird dann von A unterschrieben, also C = D d (h) , und wiederum das Tupel (M, C) an B gesendet. Auf der anderen Seite berechnet B ebenso zun¨ achst den Hashwert h 2 aus M und ¨ uberpr¨ uft dann ^! die Signatur C durch Berechnen von E e (C) = h 2 . Ist diese wie erwartet, so kann

B annehmen, daß entsprechend A den Hash-Wert und damit auch das Dokument unterzeichnet hat. Diese Methode der Signatur ist nat¨ urlich wesentlich unsicherer als die obige, denn es kann beim Erzeugen von Hash-Werten nat¨ urlich zu sogenannten Kollisionen kommen: Werden Dokumente mit der L¨ ange mehrerer Mega-Byte auf 128 Bit Fingerabdr¨ ucke abgebildet, so gibt es mit Sicherheit mehrere verschiedene Dokumente, die den selben Hash-Wert besitzen. B kann dann nicht wirklich sicher sein, daß A auch M und nicht zuf¨ allig ein M 2 unterschrieben hat. Es k¨ onnte n¨ amlich sein, daß gilt: H(M ) = h = H(M 2 ). Hat ein Angreifer eine Unterschrift f¨ ur ein h eines ” harmlosen“ Textes, und findet er ein oder mehrere M 2 mit obigen Eigenschaften, so kann er B die M 2 mit der alten Unterschrift untergeschoben - B wird sie als von A signiert akzeptieren.

2.2.1 SHA-1

Der Secure Hash Algorithm [26] ist ein vom NIST und der National Securicy Agency (NSA) gemeinsam entwickeltes Hash-Verfahren. SHA-1 wurde urspr¨ unglich als sichere Hash-Funktion f¨ ur ein neues Signaturverfahren, den Digital Signature Algorithm (DSA) entwickelt, hat sich allerdings auch unabh¨ angig davon ⁶⁴ Bit durchgesetzt. Der Algorithmus produziert f¨ ur jede Eingabe der L¨ ange < 2 einen Hash-Wert der L¨ ange 160 Bit. Es gibt in dem Algorithmus selbst bisher keine bekannte Schwachstelle. Dies bedeutet f¨ ur einen eine Kollision suchenden