Einsatzmöglichkeiten kryptographischer Methoden zur ... · Eidesstattliche Versicherung Die selbstständige und eigenhändige Anfertigung versichere ich an Eides statt. Ich habe

Diplomarbeit

Einsatzmöglichkeitenkryptographischer Methoden zurSignatur und Verschlüsselung im

Krankenhaus

Friedhelm PoschadelMatrikel Nr.: 2519737

März 2002

Technische Universität Braunschweig

Institut für Theoretische Informatik

Prof. Dr. Dietmar Wätjen

Medizinische Hochschule Hannover

Institut für Medizinische Informatik

Prof. Dr. Herbert K. Matthies

Eidesstattliche Versicherung

Die selbstständige und eigenhändige Anfertigung versichere ich an Eidesstatt.

Ich habe alle benutzten Quellen angegeben und sämtliche Entlehnungenaus anderen Arbeiten kenntlich gemacht.

Hannover, den

____________________________________________

(Friedhelm Poschadel)

I

Inhalt

Abbildungsverzeichnis................................................................................................. IV

Tabellenverzeichnis........................................................................................................V

Glossar........................................................................................................................... VI

1. Einleitung.................................................................................................................1

2. Anforderungen an die Übermittlung und Speicherung von medizinischenDaten.........................................................................................................................3

3. Rechtlicher Rahmen der Kryptographie in Deutschland....................................6

4. Einsatzmöglichkeiten kryptographischer Verfahren im Krankenhaus.............84.1. Verschlüsselungsverfahren ...................................................................................8

4.1.1. Symmetrische Verschlüsselung ................................................................84.1.2. Asymmetrische Verschlüsselung ............................................................104.1.3. Hybride Verschlüsselung ........................................................................114.1.4. Transcoding.............................................................................................12

4.2. Authentisierungsverfahren ..................................................................................13

4.3. Zertifizierungsinfrastrukturen .............................................................................13

4.4. Zeitstempel-Dienst ..............................................................................................17

4.5. Schlüsselverlust...................................................................................................18

4.6. Bedrohungsmodelle.............................................................................................19

5. Verwendete Algorithmen......................................................................................225.1. Mathematische Grundlagen ................................................................................225.2. Die Algorithmen im Detail..................................................................................27

5.2.1. Rijndael - AES ........................................................................................275.2.2. RSA.........................................................................................................33

6. Ausgewählte Kommunikationsprozesse..............................................................376.1. Struktur der Betrachtung .....................................................................................37

6.2. Kommunikationsprozesse ...................................................................................416.2.1. Datenübermittlung zwischen Instituten...................................................416.2.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................42

II

6.2.3. Internetverbindung zu einem anderen Krankenhaus...............................436.2.4. Gesicherte Einwahl über ISDN, Modem oder Internet ...........................446.2.5. Webbasierte Kommunikation..................................................................446.2.6. Multizentrische klinische Studien über das Internet ...............................456.2.7. Gesicherter interner Mailversand............................................................466.2.8. Gesicherter externer Mailversand ...........................................................47

7. Soll-Modell .............................................................................................................497.1. Vorbemerkungen.................................................................................................49

7.2. Tools zur Sicherung der Kommunikation ...........................................................567.2.1. Router VPN.............................................................................................567.2.2. Firewall-Firewall VPN-Tunnel ...............................................................577.2.3. Anwender-Firewall VPN-Tunnel............................................................587.2.4. Direkter Tunnel zwischen Servern..........................................................597.2.5. Web-Server-Zertifikate ...........................................................................607.2.6. Web-Client-Zertifikate............................................................................617.2.7. Datei-Verschlüsselungsprogramm ..........................................................627.2.8. E-Mail Add-On .......................................................................................63

7.3. Modellvorstellung ...............................................................................................647.3.1. Datenübermittlung zwischen Instituten...................................................647.3.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................647.3.3. Internetverbindung zu einem anderen Krankenhaus...............................647.3.4. Gesicherte Einwahl über ISDN, Modem oder Internet ...........................657.3.5. Webbasierte Kommunikation..................................................................657.3.6. Multizentrische klinische Studien über das Internet ...............................667.3.7. Gesicherter interner Mailversand............................................................667.3.8. Gesicherter externer Mailversand ...........................................................67

8. Pragmatisches Modell ...........................................................................................688.1. Allgemeine Überlegungen ..................................................................................68

8.2. Auswahl der CA-Software ..................................................................................71

8.3. Tools zur Sicherung der Kommunikation ...........................................................728.3.1. Router VPN.............................................................................................728.3.2. Firewall-Firewall VPN-Tunnel ...............................................................738.3.3. Anwender-Firewall VPN-Tunnel............................................................748.3.4. Direkter Tunnel zwischen Servern..........................................................758.3.5. Web-Server-Zertifikate ...........................................................................768.3.6. Web-Client-Zertifikate............................................................................778.3.7. Datei-Verschlüsselungsprogramm ..........................................................788.3.8. E-Mail Add-On .......................................................................................79

III

8.4. Umsetzung...........................................................................................................808.4.1. Datenübermittlung zwischen Instituten...................................................808.4.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................808.4.3. Internetverbindung zu einem anderen Krankenhaus...............................818.4.4. Gesicherte Einwahl über ISDN, Modem oder Internet ...........................818.4.5. Webbasierte Kommunikation..................................................................828.4.6. Multizentrische klinische Studien über das Internet ...............................828.4.7. Gesicherter interner Mailversand............................................................838.4.8. Gesicherter externer Mailversand ...........................................................83

9. Zusammenfassung.................................................................................................84

Anhang ...........................................................................................................................86

Literaturverzeichnis......................................................................................................88

IV

Abbildungsverzeichnis

Abbildung 4-1: Flache Struktur [NiSc2001].............................................................. 14

Abbildung 4-2: Hierarchische Struktur [NiSc2001] .................................................. 15

Abbildung 4-3: Transitives Vertrauen ....................................................................... 15

Abbildung 4-4: Web of Trust [NiSc2001] ................................................................. 16

Abbildung 5-1: AES-Verschlüsselung [Sav2001] ..................................................... 33

Abbildung 7-1: Zielstruktur ....................................................................................... 52

Abbildung 7-2: Modell der Schlüssel- und Datenübermittlung................................. 53

Abbildung 7-3: Router VPN (Ziel) ............................................................................ 56

Abbildung 7-4: Firewall-Firewall VPN (Ziel) ........................................................... 57

Abbildung 7-5: Anwender-Firewall VPN (Ziel)........................................................ 58

Abbildung 7-6: Direkter Tunnel zwischen Servern (Ziel) ......................................... 59

Abbildung 7-7: Web-Server-Zertifikate (Ziel)........................................................... 60

Abbildung 7-8: Web-Client-Zertifikate (Ziel) ........................................................... 61

Abbildung 7-9: Datei-Verschlüsselungsprogramm (Ziel) ......................................... 62

Abbildung 7-10: E-Mail Add-On (Ziel)..................................................................... 63

Abbildung 8-1: Umzusetzende Struktur..................................................................... 70

Abbildung 8-2: Router VPN ...................................................................................... 72

Abbildung 8-3: Firewall-Firewall VPN ..................................................................... 73

Abbildung 8-4: Anwender-Firewall VPN.................................................................. 74

Abbildung 8-5: Direkter Tunnel zwischen Servern ................................................... 75

Abbildung 8-6: Web-Server-Zertifikate..................................................................... 76

Abbildung 8-7: Web-Client-Zertifikate ..................................................................... 77

Abbildung 8-8: Datei-Verschlüsselungsprogramm.................................................... 78

Abbildung 8-9: E-Mail Add-On................................................................................. 79

V

Tabellenverzeichnis

Tabelle 4-1: Empfohlene Länge öffentlicher Schlüssel [in Bit] [SchB1996] ............ 10

Tabelle 4-2: Symmetrische und asymmetrische Schlüssel ähnlicher Resistenz[SchB1996]............................................................................................ 12

Tabelle 5-1: Blockgröße in Bytes .............................................................................. 28

Tabelle 5-2: Rundenanzahl [DaRi1999] .................................................................... 29

Tabelle 5-3: Zeilenverschiebung (ShiftRow) [DaRi1999]......................................... 31

Tabelle 6-1: Datenübermittlung zwischen Instituten ................................................. 42

Tabelle 6-2: Direktgeschaltete Verbindung zu einer anderen Klinik......................... 43

Tabelle 6-3: Internetverbindung zu einem anderen Krankenhaus ............................. 43

Tabelle 6-4: Gesicherte Einwahl über ISDN, Modem oder Internet ......................... 44

Tabelle 6-5: Webbasierte Kommunikation ................................................................ 45

Tabelle 6-6: Multizentrische klinische Studien über das Internet.............................. 46

Tabelle 6-7: Gesicherter interner Mailversand........................................................... 47

Tabelle 6-8: Gesicherter externer Mailversand.......................................................... 48

Tabelle 7-1: Arten der Verschlüsselung..................................................................... 51

Tabelle 7-2: Auswahl kryptographischer Verfahren.................................................. 55

VI

Glossar

3DES Dreimalige Anwendung des DES-Algorithmus(mit verschiedenen Schlüsseln) zur Erweiterungder effektiven Schlüssellänge auf 112 oder 168Bit.

Access Control List Befehle auf einem Router, um anhand vonTCP/IP Adressen oder Diensten (Ports) Berechti-gungen zur Kommunikation zu erteilen bzw. zuverweigern.

ACL siehe Access Control List

AES Advanced Encryption Standard, Nachfolger desDES. Als Algorithmus wird Rijndael verwendet.

Asymmetrische Verschlüsselung Verfahren mit getrennten Schlüsseln zum Ver-(Public Key bzw. öffentlicher Schlüssel) und Ent-schlüsseln (Private Key, privater Schlüssel).

Backbone Hauptkommunikationsleitungen, über die dernicht-lokale Datenverkehr eines LAN bzw. WANläuft.

BDSG Bundesdatenschutzgesetz

Brute Force Versuch, eine Verschlüsselung durch Ausprobie-ren aller möglichen Schlüsselkombinationen (z.B.2128) zu brechen.

CA Certification Authority, Organisation welche,durch ein Zertifikat die Echtheit eines Schlüsselsbestätigt.

Crossconnect Kabel Kabel (mit gedrehten Adern) zum direktenVerbinden genau zweier Computer ohne den Ein-satz weiterer Komponenten wie Router, Switchesoder Hubs.

DES Digital Encryption Standard

Ethernet Protokoll zur Kommunikation innerhalb einesLAN mit einer Übertragungsrate von 10 MBit/s,100 MBit/s (bei Fast-Ethernet), 1 GBit/s (Giga-bit-Ethernet) oder 10 GBit/s (10 Gigabit-Ether-net).

Fast-Ethernet Variante von Ethernet mit 100 MBit/s.

VII

Firewall Netzwerkkomponente zur Absicherung von Net-zen vor Angriffen und zum Aufbau von VPNs.

Fingerabdruck siehe Fingerprint

Fingerprint Charakteristische Zahl, welche zur Identifizierungeines Schlüssels eingesetzt werden kann und aufkryptographischen Hash-Funktionen basiert.

Hash, kryptographischer Algorithmus zum Berechnen einer charakteristi-schen Prüfzahl zu gegebenen Daten, bei der esquasi unmöglich ist, andere sinnvolle Daten mitderselben Prüfzahl zu erzeugen.

Hybride Verschlüsselung Kombination von asymmetrischer und symmetri-scher Verschlüsselung, bei der die Nutzdatensymmetrisch verschlüsselt werden und der ver-wendete Schlüssel asymmetrisch verschlüsseltund den Nutzdaten hinzugefügt wird.

Known Plaintext Attack Angriff, bei welchem dem Angreifer der Quell-text (zumindest in Teilen) bekannt ist und er ver-sucht dadurch Rückschlüsse auf dem Schlüsselgewinnen zu können.

KV Kassenärztliche Vereinigung, Körperschaftöffentlichen Rechts zur Selbstverwaltung derÄrzte und zur Abrechnung mit den Krankenkas-sen.

LAN Local Area Network – auf einen lokalen abge-grenzten Bereich (z.B. Campus) beschränktesNetzwerk.

PCA Policy Certification Authority – Institution, wel-che den Rahmen für die auszustellenden Zertifi-kate einer hierarchischen Infrastruktur für meh-rere Certification Authorities darstellt.

Personal Firewall Firewall-Software, die auf einem Client läuft unddiesen vor Angriffen schützen soll. Der Clientsoll sowohl vor Angriffen von außen (z.B. ausdem Internet) als auch vor Programmen geschütztwerden, die auf den Client eingeschleust wurden(sogenannte Trojaner) und Daten ohne Wissendes Anwenders nach außen senden sollen.

PGP Pretty Good Privacy – vermutlich das meistge-nutzte Programm zur Verschlüsselung vonDateien und Mails.

PKI siehe Public Key Infrastructure

VIII

Public Key Infrastructure Notwendige Infrastruktur, die zum Einsatz vonPublic-Key-Kryptographie notwendig ist. DieseInfrastruktur besteht aus der oder den CAs, denAnwendungen, welche die Zertifikate nutzen, undauch den Anwendern, welche die Zertifikaterichtig interpretieren.

Pre Shared Secret „Geheimnis“ bzw. Passwort oder Schlüssel, dasüber einen sicheren Kanal zwischen Kommuni-kationspartnern ausgetauscht wird.

Rijndael Verschlüsselungsalgorithmus, der zum AESerklärt wurde.

Root-CA CA, welche durch keine „übergeordnete“ CAzertifiziert wird (z.B. innerhalb eines Unterneh-mens oder als oberste CA eines Landes).

Router Netzwerkkomponente, welche Teile eines LANmiteinander verbindet oder auch LANs überWeitverkehrsstrecken miteinander verbindet.

RSA Public Key Algorithmus, nach Rivest, Shamirund Adelman benannt.

SecurID Karte von RSA Communications zum Erzeugenvon Einmalpassworten (jeweils eine 6-stelligeZahl pro Minute), die zusammen mit einer per-sönlichen PIN mit einem zentralen Server vergli-chen werden und so eine (durch Wissen undBesitz bedingte) sichere Authentisierung ohnespezielle Chipkartenlesegeräte ermöglicht.

Session Key Schlüssel, der jedes Mal für die Übertragung vonDaten erzeugt und nicht wieder verwendet wird(siehe auch Hybride Verschlüsselung).

Sicherer Kanal Übermittlung von Daten über einen anderen Wegals die spätere Übermittlung der verschlüsseltenDaten (z.B. bei einem direkten Treffen).

Signatur Elektronisch erstellte, kryptographisch gesicherteUnterschrift.

SmardCard Karte mit integriertem Chip, der Daten speichernkann, die nur nach Authentisierung zugreifbarsind oder in der komplexe Algorithmen (bei-spielsweise signieren) ausgeführt werden.

Sniffer Programm zum Mitlesen von Datenpaketen ineinem Netzwerk. Kann für Diagnosezwecke, aberauch zum Ausspähen von Daten bzw. Kennungengenutzt werden.

IX

Switch Netzwerkkomponente, die (Ethernet-) Verbindun-gen zwischen Computern direkt schaltet, die vonnicht an der Kommunikation beteiligten Compu-tern erschwert abhörbar ist.

Symmetrische Verschlüsselung Verschlüsselung, bei welcher derselbe Schlüsselzum Ver- und zum Entschlüsseln verwendet wird.

Time Stamp „Zeitstempel”, der automatisch von einemComputer an ein Dokument angehängt und miteiner Signatur versehen wird. Der Time Stamperbringt den Nachweis, dass ein Dokument zueinem bestimmten Zeitpunkt existiert hat.

TripleDES siehe 3DES

Trust Center Institution, die als „vertrauenswürdiger Dritter“fungiert und die Authentizität (die Zugehörigkeitzu einer bestimmten Person) eines öffentlichenSchlüssels bestätigt.

Tunnel, verschlüsselter Logisch verschlüsselte Verbindung zwischenzwei Computern, Netzen o.ä., durch die verschie-dene (an sich unverschlüsselte) Dienste auf ver-schiedenen Computern sicher miteinander kom-munizieren können, ohne dass die Anwendungenangepasst werden müssen.

VPN Virtual Private Network-Verbindung zweier odermehrerer lokaler Netze über ein öffentlichesNetzwerk (z.B. das Internet) mittels Verschlüs-selung.

WAN Wide Area Network - Weitverkehrsnetz

Web of Trust Struktur, um die Zugehörigkeit eines öffentlichenSchlüssels zu einer Person oder Institution ohneeinen „vertrauenswürdigen Dritten“ zubestätigen.

X.509 Standard für die Zertifizierung öffentlicherSchlüssel.

Zertifikat Bestätigung, welche die Zusammengehörigkeiteines öffentlichen Schlüssels zu einer Person(oder Institution) bestätigt.

1

1. Einleitung

„Falls Sie glauben, dass Technologie Ihre Sicherheits-probleme lösen kann, verstehen Sie die Probleme nicht,

und Sie haben von Technologie keine Ahnung.“

[Bruce Schneier, Secrets & Lies]

Das Ziel dieser Diplomarbeit ist es, anhand ausgewählter Kommunikationsprozesseaufzuzeigen, mit welchen Mitteln die Kommunikation sensibler Daten gegenüberdem nicht autorisierten Lesen oder Verändern geschützt werden kann. Ebenfalls wirddarauf eingegangen, welche organisatorischen Maßnahmen notwendig sind, um dieVerfügbarkeit der Daten zu gewährleisten. Auch wird aufgezeigt, welche Anforde-rungen an ein Trustcenter zu stellen sind, was die Ausstellung und den Rückruf vonZertifikaten angeht. Als Beispiel werden Kommunikationsprozesse in der Medizi-nischen Hochschule Hannover (MHH) vorgestellt.

Eine „absolute“ Sicherheit wird sich nicht erreichen lassen – die gibt es in der Reali-tät nirgends. Es ist auch klar, dass ein Sicherheitskonzept immer nur für den Rah-men, für den es entworfen wurde, Gültigkeit besitzen kann. Wenn sich die Anforde-rungen oder auch das Umfeld ändern, ist ein Sicherheitskonzept zu hinterfragen undgegebenenfalls anzupassen. Unterlässt man dies, wiegt man sich in einer (trügeri-schen) Sicherheit, die nicht gegeben ist. Sicherheit ist ein Prozess!

Diese Arbeit beschränkt sich auf Konzepte für den Einsatz kryptographischer Ver-fahren in der Medizin und betrachtet weitestgehend die darunter liegenden Systemenicht näher. Es würde den Rahmen sprengen darüber hinaus ein Konzept für einsicheres LAN und eine abgesicherte Server-Infrastruktur zu erarbeiten. Es ist natür-lich eine Grundvoraussetzung, dass die verwendeten Systeme sicher sind und sichder kryptographische Schutz nicht durch triviale Maßnahmen aushebeln lässt. DiesesKonzept ist jedoch notwendig um einen umfassenden Schutz zu gewährleisten. Wennman einen Angriffsbaum (siehe [SchB2001]) aufstellt, wird man feststellen, dass dieeinfachsten und erfolgversprechensten Angriffe nicht gegen die Kryptographieselbst, sondern gegen das Umfeld durchgeführt werden können.

Aufgrund der Komplexität der gesamten Thematik kann im Rahmen dieser Arbeitnicht darauf eingegangen werden, wie sich kryptographische Verfahren (insbes. Sig-naturen) direkt in Applikationen wie z.B. Patientenadministrations-Systeme integrie-ren lassen. Es werden hier Verfahren zur gesicherten Kommunikation außerhalbintegrierter Krankenhausinformationssysteme beschrieben, die unabhängig von kryp-tographischen Verfahren in diesen Systemen einsetzbar sind.

Die Kapitel 2 (Anforderungen an die Übermittlung und Speicherung vonmedizinischen Daten), 3 (Rechtlicher Rahmen der Kryptographie in Deutschland),

2

und 4 (Einsatzmöglichkeiten kryptographischer Verfahren im Krankenhaus) zeigendie inhaltlichen Anforderungen auf, die Grundlage dieser Arbeit sind.

Im Kapitel 5 (Verwendete Algorithmen) werden die wichtigsten hier verwendetenAlgorithmen mit ihren mathematischen Grundlagen erläutert und Abschätzungengegeben, wie sicher diese Verfahren gegen ein Brechen des Schlüssels sind.

Eine Auswahl interessanter Kommunikationsprozesse und die Struktur der Kategori-sierung werden in Kapitel 6 (Ausgewählte Kommunikationsprozesse) getroffen.

In Kapitel 7 (Soll-Modell) wird ein Modell vorgestellt, wie die im vorhergehendenKapitel ausgewählten Prozesse wünschenswerterweise abgesichert werden sollten.Diese Betrachtung erfolgt unabhängig davon, ob die dazu notwendigen Tools undAnwendungen bereits heutzutage zur Verfügung stehen. Jedoch liegt ein Augenmerkdarauf, dass es im Laufe der nächsten Jahre möglich sein wird, dieses Modell umzu-setzen.

Das Kapitel 8 (Pragmatisches Modell) stellt einen Kompromiss zwischen dem vorge-stellten Soll-Modell und den zur Zeit real verfügbaren Tools und Anwendungen dar,der bereits heute mit begrenzten Mitteln realisierbar ist und ein hohes Sicherheitsni-veau erreicht.

Im Kapitel 9 (Zusammenfassung) werden die gewonnenen Erkenntnisse zusammen-gefasst.

Die in der Medizinischen Hochschule Hannover (MHH) vorhandene Netzwerk- undServer-Infrastruktur wird im Anhang grob dargestellt.

3

2. Anforderungen an die Übermittlung und Speiche-rung von medizinischen Daten

„Über alles, was ich während oder außerhalb derBehandlung im Leben der Menschen sehe oder höre

und das man nicht nach draußen tragen darf,werde ich schweigen und es geheimhalten.“

[Auszug aus dem Eid des Hippokrates Übersetzung Prof. Dr. med. Axel W. Bauer]

Bereits in der Antike war bekannt, dass die Informationen, die Ärzte durch ihreArbeit erlangen, etwas Besonderes sind und nicht in die falschen Hände gelangendürfen. Dies gilt heute in noch stärkerem Maße, da sich durch die globale Vernet-zung Informationen (selbst wenn diese nicht öffentlich zugänglich sein sollen) welt-weit verbreiten können. Die modernen Entsprechungen zu diesem Eid finden sichsowohl im Standesrecht für Ärzte als auch im Strafrecht, welche die Vertraulichkeitder Daten sicherstellen sollen.

Konkret sind hier der §203 (Verletzung von Privatgeheimnissen) des Strafgesetz-buches (StGB) [StGb203] zu nennen, in dem es heißt:

(1) Wer unbefugt ein fremdes Geheimnis, namentlich ein zum persönli-chen Lebensbereich gehörendes Geheimnis oder ein Betriebs- oderGeschäftsgeheimnis, offenbart, das ihm als1. Arzt, Zahnarzt, Tierarzt, Apotheker oder Angehörigen eines

anderen Heilberufs, der für die Berufsausübung oder die Füh-rung der Berufsbezeichnung eine staatlich geregelte Ausbil-dung erfordert,

2. Berufspsychologen mit staatlichen anerkannter wissenschaftli-cher Abschlußprüfung,

[...]6. Angehörigen eines Unternehmens der privaten Kranken-,

Unfall- oder Lebensversicherung oder einer privatärztlichenVerrechnungsstelle

anvertraut worden oder sonst bekannt geworden ist, wird mit Freiheitsstrafebis zu einem Jahr oder mit Geldstrafe bestraft.(2) Ebenso wird bestraft, wer unbefugt ein fremdes Geheimnis, nament-

lich ein zum persönlichen Lebensbereich gehörendes oder einBetriebs- oder Geschäftsgeheimnis offenbart [...]..

4

(3) Den im Absatz 1 Genannten stehen ihre berufsmäßig tätigen Gehilfenund die Personen gleich, die bei ihnen zur Vorbereitung auf den Beruftätig sind. Den in Absatz 1 und den in Satz 1 Genannten steht nachdem Tod des zur Wahrung des Geheimnisses Verpflichteten fernergleich, wer das Geheimnis von dem Verstorbenen oder aus dessenNachlaß erlangt hat.

(4) Die Absätze 1 bis 3 sind auch anzuwenden, wenn der Täter das fremdeGeheimnis nach dem Tod des Betroffenen unbefugt offenbart.

In der Muster-Berufsordnung für die deutschen Ärztinnen und Ärzte (MBO-Ä 1997in der Fassung der Beschlüsse des 100. Deutschen Ärztetages) [DÄT1997] heißt eszu diesem Thema:

§ 9 Schweigepflicht(1) Der Arzt hat über das, was ihm in seiner Eigenschaft als Arzt anver-

traut oder bekannt geworden ist - auch über den Tod des Patientenhinaus - zu schweigen. Dazu gehören auch schriftliche Mitteilungendes Patienten, Aufzeichnungen über Patienten, Röntgenaufnahmenund sonstige Untersuchungsbefunde.

(2) Der Arzt ist zur Offenbarung befugt, soweit er von der Schweigepflichtentbunden worden ist oder soweit die Offenbarung zum Schutze eineshöherwertigen Rechtsgutes erforderlich ist. Gesetzliche Aussage- undAnzeigepflichten bleiben unberührt. Soweit gesetzliche Vorschriftendie Schweigepflicht des Arztes einschränken, soll der Arzt den Pati-enten darüber unterrichten.

(3) Der Arzt hat seine Mitarbeiter und die Personen, die zur Vorbereitungauf den Beruf an der ärztlichen Tätigkeit teilnehmen, über die gesetz-liche Pflicht zur Verschwiegenheit zu belehren und dies schriftlichfestzuhalten.

(4) Wenn mehrere Ärzte gleichzeitig oder nacheinander denselben Patien-ten untersuchen oder behandeln, so sind sie untereinander von derSchweigepflicht insoweit befreit, als das Einverständnis des Patientenvorliegt oder anzunehmen ist.

Zusätzlich ergibt sich die Notwendigkeit der Dokumentation dadurch [Ber1996],dass speziell im Krankenhaus verschiedene Personen mit der Behandlung eines Pati-enten betraut sind und diese sich nur so über den aktuellen Zustand angemessengegenseitig informieren können. Die Dauer der Behandlung kann sich auch überMonate und Jahre erstrecken. Ebenfalls ergibt sich die Dokumentationspflicht dar-aus, dass im Falle von Rechtsstreitigkeiten (im Nachhinein) belegbar sein muss,weshalb welche Behandlung durchgeführt wurde (oder auch nicht). Hier ist primärherauszustellen, dass nachweisbar sein muss, dass die Dokumentation authentisch istund nicht manipuliert wurde. Andernfalls könnte es unmöglich sein nachzuweisen,dass ein bzw. kein Kunstfehler vorlag.

Zusätzlich zur Sicherstellung der Vertraulichkeit und Integrität der Daten bei derSpeicherung und Archivierung ergibt sich die Notwendigkeit einer gesichertenÜbermittlung. Man könnte natürlich, um die Daten zu versenden, diese auf Disketten

5

(oder anderen Wechselmedien) speichern und per Post versenden, jedoch würdedadurch der große Vorteil von elektronisch gespeicherten Daten, die schnelle Über-mittlung, verloren gehen. Da jedoch medizinische Daten über Datennetze (ISDN,Internet z.B. per E-Mail etc.) nach Auffassung der Datenschutzbeauftragten oderKassenärztlichen Vereinigungen (KV) nur übertragen werden dürfen, wenn diesehinreichend geschützt sind, wird dadurch eine sichere Verschlüsselung notwendig.

Da durch die elektronische Dokumentation ein wesentlich größeres Angriffspotenzialvorhanden ist als in der konventionellen, papierbasierten, ist die Übertragung derDaten über unsichere Kanäle nur dann statthaft, wenn diese verschlüsselt sind.

Die KV Bayern schreibt im Landesrundschreiben 1/1999 „Leitlinien für den E-Mail-Versand im Gesundheitswesen“ [KVB1999], dass ein „Offener E-Mail Versand“grundsätzlich nicht geschehen darf – selbst wenn dieser über ein „vertrauenswürdi-ges“ Netz wie z.B. ein sogenanntes „medizinisches Netz“ geschieht.:

„Ausdrücklich muß in diesem Zusammenhang darauf hingewiesen werden, dassdie Verantwortung für die Einhaltung der ärztlichen Schweigepflicht und dieWahrung des Datenschutzes nicht delegiert werden kann. Aus diesem Grund mußjederzeit für den Anwender [Anm.: der Arzt] überprüfbar sein, dass entspre-chende Schutzmechanismen eingerichtet und jederzeit wirksam sind.[...] Dabeiist von wesentlicher Bedeutung, dass evtl. zu verschlüsselnde Nachrichten jeweilsbereits im eigenen Einflußbereich so chiffriert werden, dass kein unbefugterDritter von diesen Daten Kenntnis nehmen kann.“

In einer Stellungsnahme des Hamburgischen Datenschutzbeauftragten durch Dr.Hans-Joachim Menzel und Ulrich Kühn [MeKü2000a] vom 15.2.2000 heißt es:

„[...] Aus diesem Grund ist der Versand personenbezogener Patientendaten imInternet nur zulässig, wenn geeignete Sicherungsmaßnahmen getroffen werden.Für den Aspekt der Vertraulichkeit bedeutet dies, dass ein nach dem heutigenStand der Technik ausreichend sicheres Verschlüsselungsverfahren zum Einsatzkommen muss.“

In [Jac1996] Schreibt der Bundesbeauftragte für den Datenschutz, Jacob:

„Die Risiken der Übertragung sind – völlig unabhängig von der Zulässigkeit – sogering wie möglich zu halten, hier sind wenn möglich kryptographischeVerschlüsselungsverfahren einzusetzen. Deshalb müssen die technischenVorkehrungen für planbare Telekonsikien [Anm.: ein Arzt beteiligt an derBehandlung eines Patienten durch den Einsatz von Telekommunikationseinrich-tungen anderen Ärzte oder Fachleute] den Einsatz von Verschlüsselungvorsehen.“

Daraus folgt, dass der Übermittlung von Patientendaten über Computernetzwerke(geschlossene oder offene) keine prinzipiellen rechtlichen Vorbehalte entgegen ste-hen, sofern diese nach dem heutigen Stand der Technik ausreichend geschützt sind.

6

3. Rechtlicher Rahmen der Kryptographie inDeutschland

Einen direkten rechtlichen Rahmen für den Einsatz von Signaturen gibt es inDeutschland seit der Einführung des Signatur Gesetzes (SigG) 1997. Vorher war esden Gerichten im Rahmen der freien Beweiswürdigung möglich, Signaturen (ggf.nach aufwendigen Gutachten) anzuerkennen - oder auch nicht, wenn das Gerichtnicht überzeugt wurde.

Mit der Einführung des SigG 1997 betrat Deutschland international Neuland, da esbisher in dieser Form für ein landesweit geltendes Signaturgesetz keine Beispielegab.

In dem SigG wurde eine Genehmigungspflicht für Trustcenter definiert, die sehrhohe Anforderungen an die räumlichen und administrativen Vorgänge der Zertifizie-rung stellt und somit einen erheblichen finanziellen und organisatorischen Aufwandfür den Betrieb eines Trustcenters erforderlich macht. Vermutlich deshalb gab es nurwenige Institutionen, welche eine Zulassung beantragten (siehe auch [SchC2001] ,[LANL2001], [Mal2001]).

Im Rahmen einer europäischen Richtlinie zur Vereinheitlichung der Signaturgesetzeinnerhalb der Europäischen Union wurde 2001 die Rechtslage in Deutschland ange-passt. Die neue Gesetzeslage unterscheidet sich in folgenden Punkten wesentlich vondem bisherigen Gesetz:

• Die Genehmigungspflicht wurde zugunsten einer Anzeigepflicht gestrichen.Es entstehen also keine Kosten für eine Zertifizierung. Zusätzlich gibt es jetzteine Haftungsregelung für die TrustCenter, welche in Kraft tritt, wenn auf-grund eines Verschuldens des TrustCenters einem Dritten ein Schaden ent-steht, weil er einem (fehlerhaften) Zertifikat vertraute. Durch die Haftungsre-gelung dürfte das Vertrauen in die Echtheit der Signaturen steigen.

• Es gibt jetzt drei Signaturen. Die „einfache Signatur“, die europaweit einheit-liche „Fortgeschrittene Signatur“ und die „Qualifizierte Signatur“. Bei der„einfachen Signatur“ gibt es keine gesetzlich geregelte Haftung für Schäden,die aus der Nutzung eines fahrlässig fehlerhaften Zertifikates entstehen. Hierbleibt es dem Anbieter überlassen, in welchem Rahmen er den Nutzerngegenüber haftet [iX2001-04]. Bei der „Fortgeschrittenen Signatur“ haftet dasTrustCenter für die Richtigkeit und Vollständigkeit der zertifizierten Anga-ben gegenüber Dritten, wenn diesen durch fahrlässiges Verhalten des Trust-Centers ein Schaden entstanden ist. Die „Qualifizierte Signatur“ ist sozusageneine offiziell zertifizierte Signatur, bei welcher der Betreiber nachgewiesenhat, dass er erfolgreich einen hohen Aufwand betreibt, um die Sicherheit zugewährleisten. Es handelt sich dabei sozusagen um eine an die EuropäischeSignaturrichtlinie angepasste Variante des bisherigen Signaturgesetzes.

7

Ebenfalls aufgrund der europäischen Rechtslage wurde das „Gesetz zur Anpassungder Formvorschriften des Privatrechts und anderer Vorschriften an den modernenRechtsgeschäftsverkehr“ verabschiedet, welches die nahezu vollständige Gleichstel-lung der elektronischen Signatur und der eigenhändigen Unterschrift regelt. Es gibtfür einige Fälle Ausnahmen, die jedoch i.d.R. ohnehin nicht „digital“ erfolgen. So isteine „digitale Heirat“ oder ein „digitaler Hauskauf“ auch zukünftig nicht möglich.

Neu ist, dass die durch die Signatur bestätigte Willenserklärung solange als echt gilt,bis der (vermeintliche) Unterzeichner den Gegenbeweis angetreten hat. Hier habenjedoch einige Juristen Bedenken, da durch diese Regelung der Signatur eine höhereWertigkeit als der manuellen Unterschrift eingeräumt wird.

Da es in Deutschland – wie in den meisten Ländern – keine Reglementierung für denEinsatz kryptographischer Verfahren zur Verschlüsselung gibt, kann dazu ein belie-biges (sicheres oder unsicheres) Verfahren Einsatz finden. Beschränkt auf sichereVerfahren wird diese Freiheit jedoch dadurch, dass bei der Anwendung im medizini-schen Umfeld die Vertraulichkeit der Patientendaten gefordert wird und dies nur mitsicheren Verfahren zu gewährleisten ist.

Die USA sind nach wie vor international der größte Produzent von Standardsoftwareund so war die Exportbeschränkung von kryptographischen Produkten der USA einernst zu nehmendes Problem für die Verbreitung sicherer Kryptographie in Standard-produkten. Durch die Beschränkung durften nur Produkte mit einer relativ schwa-chen Verschlüsselung (z.B. DES mit 40 Bit) exportiert werden, sofern keine beson-dere Exportgenehmigung (z.B. für den Einsatz bei Banken) erteilt wurde. Erst nachder Liberalisierung der US-amerikanischen Exportgesetze ist es möglich ohne einespezielle Genehmigung in Europa sichere Kryptographie (z.B. in Web-Browsern)einzusetzen.

8

4. Einsatzmöglichkeiten kryptographischer Verfahrenim Krankenhaus

„Komplexität ist der schlimmsteFeind der Sicherheit.“


Es gibt zahlreiche Einsatzmöglichkeiten für die verschiedenen kryptographischenVerfahren im Krankenhaus. In diesem Kapitel werden verschiedene Verfahren vor-gestellt, welche dazu eingesetzt werden können, die im nächsten Kapitel vorgestell-ten Prozesse abzusichern.

4.1. Verschlüsselungsverfahren

4.1.1. Symmetrische Verschlüsselung

Bei der symmetrischen (konventionellen) Verschlüsselung verwenden alle Kommu-nikationspartner denselben Schlüssel zum Ver- bzw. Entschlüsseln. Einer der größ-ten Vorteile der symmetrischen Verschlüsselung ist die Schnelligkeit der verwende-ten Algorithmen. Es ist heutzutage möglich, sowohl in Software als auch in Hard-ware effiziente Implementierungen dieser Algorithmen für verschiedene Anwendun-gen herzustellen. Einer der größten Nachteile dieser Verfahren ist der Austausch derSchlüssel bei Kommunikationspartnern, die sich gegenseitig nicht kennen bzw. kei-nen sicheren Kanal zum Austausch des gemeinsamen Schlüssels haben. Es existierenzwar Protokolle für den sicheren Austausch von symmetrischen Schlüsseln, diesesetzen jedoch eine interaktive Verbindung voraus (ansonsten gestaltet sich derSchlüsseltausch recht langwierig, da die Schlüssel per E-Mail o.ä. übertragen werdenmüssen und eine Interaktion durch den Anwender erforderlich ist) und bieten keineGewähr für die Authentizität des Kommunikationspartners.

Da für jede mögliche Kommunikationsbeziehung ein eigener Schlüssel erzeugt wer-den muss, der Dritten nicht bekannt sein darf, ist es nicht möglich, ein sinnvolles„Telefonbuch“ zu erstellen, über das ein Schlüssel erhältlich ist. Umsetzbar ist esjedoch, ein Verzeichnis der Nutzer eines bestimmten Verfahrens zu erstellen, auf-grund dessen die Partner ein Schlüsselaustauschprotokoll durchführen, bei dem einSchlüssel über einen nicht gesicherten Kanal übertragen wird.

Eine Signatur (oder präziser eine Nachrichtenauthentisierung) mit symmetrischenSchlüsseln ist realisierbar. Jedoch ist es unmöglich, gegenüber einem Dritten zu

9

beweisen, dass der andere Kommunikationspartner ein Dokument signiert hat, dajeweils beide Partner signieren können.

Die zur Zeit gebräuchlichen Schlüssellängen liegen bei 56 Bit (z.B. bei DES), 112oder 168 Bit (z.B. bei Triple DES), 128 Bit (z.B. bei IDEA) oder bis zu 256 Bit (z.B.bei AES). 56 Bit gelten heutzutage nicht mehr als ausreichend sicher. Eine Längevon 128 Bit gilt z.Zt. als sicher. Eine Arbeitsgruppe hat sich 1996 [SchB2001]Gedanken über die Länge der Schlüssel von symmetrischen Verfahren gemacht,unter der Annahme, dass sie nur durch einen Brute-Force-Angriff gebrochen werdenkönnen. Demnach sind 90 Bit ausreichend um, eine Sicherheit bis 2016 zu gewähr-leisten. Schlüssel mit einer Länge von 128 oder 256 Bit reichen aus, um in dennächsten Jahrzehnten sicher zu sein. Das US National Institute of Standards andTechnology (NIST) geht beispielsweise davon aus, dass der neue Standard AES(Advanced Encryption Standard) mit einer Schlüssellänge von 128 Bit die nächsten30 Jahre sicher sein wird [Kre2000].

Es besteht natürlich immer die Gefahr, dass eine Schwachstelle eines Algorithmusgefunden wird, die ein deutlich schnelleres Brechen des Algorithmus ermöglicht alsdurch einen Brute-Force-Angriff. Jedoch dürfte diese Gefahr bei publizierten undvon anerkannten Experten überprüften Algorithmen relativ gering sein. Sie ist abernicht auszuschließen.

Ein Beweis dafür, dass ein symmetrisches Verfahren sicher ist (also nur durch BruteForce zu knacken), ist aufgrund der komplexen Struktur eines Verfahrens wie DESoder AES heutzutage praktisch nicht zu erbringen. Im Gegensatz zu den asymmetri-schen Verfahren, die zum größten Teil darauf beruhen, dass es heutzutage und mög-licherweise niemals möglich ist, bestimmte mathematische Operationen praktischdurchzuführen (wie das Faktorisieren großer Zahlen), ist es bei den symmetrischenVerfahren so, dass sie die Daten so „durcheinander würfeln“, dass sich aus demChiffretext keinerlei Rückschlüsse auf die Quelldaten ziehen lassen.

Das einzige beweisbar sichere symmetrische Verschlüsselungsverfahren ist dassogenannten OTP (One Time Pad), bei dem jede Nachricht mit einem genauso lan-gen und zufälligen Schlüssel verschlüsselt wird und der Schlüssel nur ein einzigesMal verwendet wird und auf einem sicheren Weg zwischen Sender und Empfängerausgetauscht werden muss. Da die Erzeugung, Verwaltung und Verteilung solcher-maßen großer Schlüssel praktisch nicht durchführbar ist, wird das OTP kaum einge-setzt. Wenn beispielsweise derselbe Schlüssel mehrmals verwendet wird, ist es mög-lich, durch Häufigkeitsanalysen den Schlüssel zu erkennen und damit Zugriff auf alledamit übertragenen Quelldaten zu erlangen.

Ein praktisches Beispiel dazu ist in [Smi1998] nachzulesen, in dem durch den feh-lerhaften Einsatz des OTP (von der Sowjetunion) im Zweiten Weltkrieg mehrereOTP-Schlüssel gefunden werden konnten. Der Fehler der Sowjets lag darin, dass sienicht genügend zufällige Schlüssel erzeugen konnten und so denselben Schlüssel anmehrere ihrer Auslandsvertretungen gegeben hatten (eine einzelne Vertretung hatjeden Schlüssel nur ein einziges Mal genutzt). Da die USA aber entgegen derAnnahme der Sowjets Zugriff auf die Kommunikation mehrerer der Auslandsvertre-tungen hatten, konnten die USA die verwendeten Schlüssel rekonstruieren und so dieübermittelten Nachrichten ermitteln.

10

4.1.2. Asymmetrische Verschlüsselung

Bei der asymmetrischen Verschlüsselung (auch „Public Key Cryptography“ genannt)wird zwischen dem öffentlichem Schlüssel und dem privaten Schlüssel unterschie-den. Mit dem öffentlichem Schlüssel kann jeder sozusagen einen Brief in den Haus-briefkasten des Empfängers einwerfen und nur der Besitzer des privaten Schlüsselskann den Briefkasten öffnen und den Brief lesen.

Der große Vorteil der asymmetrischen Verschlüsselung ist die Möglichkeit des Auf-baus eines Verzeichnisses (sozusagen eines „Telefonbuches“), in dem die öffentli-chen Schlüssel von Nutzern des Verfahrens gespeichert werden. Dadurch ist es mög-lich, einem unbekannten Kommunikationspartner verschlüsselte Nachrichtenzukommen zu lassen, ohne dass man mit diesem vorher Kontakt zum Austauscheines gemeinsamen Schlüssels aufgenommen haben muss. Hier stellt sich das Pro-blem der Authentizität der dort gespeicherten Schlüssel. Diese Problematik wird inKapitel 4.3 (Zertifizierungsinfrastrukturen) behandelt.

Elektronische Signaturen sind mit einigen asymmetrischen Verfahren möglich (siehedazu auch 4.2 (Authentisierungsverfahren)).

Die Schlüssellängen, die bei den asymmetrischen Verfahren angewendet werden,liegen zwischen 768 und 2048 Bit. 768 Bit werden heutzutage nicht mehr als sicherangesehen. Eine Länge von 1024 Bit gilt z.Zt. als sicher gegen Einzelpersonen und2048 Bit gelten auch noch für die nächsten Jahre als sicher. In [SchB1996] empfiehltBruce Schneier die folgenden Schlüssellängen:

Jahr gegenEinzelpersonen

gegenUnternehmen

gegenRegierungen

1995 768 1280 1536

2000 1024 1280 1536

2005 1280 1536 2048

2010 1280 1536 2048

2015 1536 2048 2048

Tabelle 4-1: Empfohlene Länge öffentlicher Schlüssel [in Bit][SchB1996]

Die asymmetrischen Verfahren basieren auf komplexen mathematischen Operatio-nen, deren Ausführung im Vergleich zu den symmetrischen Verfahren langsam undin Hardware auch nur aufwendig nachzubilden ist. Die Verfahren sind jedoch zumTeil beweisbar sicher, oder man kann beweisen, dass unter Vorhandensein vonbestimmten Bedingungen ein Verfahren sicher ist. Durch Fortschritte in der Mathe-

11

matik oder den Einsatz von Quantencomputern, die eine schnelle Faktorisierung gro-ßer Zahlen ermöglichen, ist es theoretisch möglich, z.B. den RSA-Algorithmusschneller zu brechen. Jedoch ist das bereits seit vielen Jahren ein ungelöstes Problemder Mathematik, von dem nicht einmal sicher ist, dass es eine solche „Abkürzung“gibt.

4.1.3. Hybride Verschlüsselung

Bei den hybriden Verfahren handelt es sich nicht um ein weiteres Verfahren, sondernvielmehr um die Verknüpfung der symmetrischen und der asymmetrischen Verfah-ren, um mit den Stärken des jeweiligen Verfahrens die Schwächen des Anderen zukompensieren. Bei der hybriden Verschlüsselung werden die zu verschlüsselndenDaten mit einem konventionellen (schnellen symmetrischen) Verfahren und einemzufälligen Schlüssel den zunächst nur der Sender kennt verschlüsselt. Dieser Schlüs-sel (z.B. 128 Bit lang) wird dann durch den Einsatz des asymmetrischen Verfah-rens selbst verschlüsselt und zusammen mit den konventionell verschlüsseltenDaten an den Empfänger gesandt. Dieser kann nun mit Hilfe seines geheimenSchlüssels den Schlüssel des konventionellen Verfahrens erhalten und damit die Ori-ginaldaten wiederherstellen.

Der asymmetrische Schlüssel des Empfängers kann nun also in einem öffentlichenVerzeichnis gespeichert werden und die Daten werden mit einem effizienteren sym-metrischen Verfahren verschlüsselt.

Da diese Art Verschlüsselung nur so stark ist wie das schwächste Glied, ist es wich-tig darauf zu achten, dass beide Schlüssellängen ausreichend sind. Es macht keinenSinn mit einem 4096 Bit langen Public Key zu verschlüsseln, wenn der symmetri-sche Algorithmus nur einen 56-Bit-Schlüssel verwendet. Schneier vergleicht in[SchB1996] die Schlüssellängen von symmetrischen und asymmetrischen Algorith-men miteinander, die etwa gleich schwer (durch Brute Force) gebrochen werdenkönnen. Wenn der symmetrische Algorithmus mit 128 Bit eingesetzt wird, ist esnicht übertrieben für den asymmetrischen Teil 2048 Bit zu wählen, insbesonderedeshalb, weil der symmetrische Schlüssel meistens nur ein einziges Mal als Sitzungs-schlüssel (Session Key) verwendet wird und derselbe asymmetrische Schlüssel teil-weise über Jahre hinweg auch zum Signieren von Dokumenten eingesetzt wird.

12

symmetrisch[Bit]

asymmetrisch[Bit]

56 384

64 512

80 768

112 1792

128 2304

Tabelle 4-2: Symmetrische und asymmetrische Schlüssel ähnlicherResistenz [SchB1996]

4.1.4. Transcoding

Eine spezielle (zum Patent angemeldete) Variante der hybriden Verschlüsselung wirdbei dem Projekt „Community Health Information Network“ (CHIN) verwandt, dasauf dem Konzept „PaDok“ der Arbeitsgruppe Medizin-Technik des Fraunhofer-Instituts für Biomedizinische Technik basiert. Die MHH nimmt an einem solchenPilotprojekt zur Vernetzung mit Arztpraxen niedergelassener Ärzte und Laboren teil.

Bei CHIN geht es darum, dass die Übermittlung der Behandlungsdaten bzw. derUntersuchungsergebnisse zwischen den Ärzten auf elektronischem Wege stattfindensoll. Dazu werden die zu übermittelnden Daten (beispielsweise Befundbriefe undLaborwerte) verschlüsselt und auf einen zentralen Server gestellt. Auf diesen Serverkann wiederum der weiterbehandelnde Arzt (beispielsweise in der MHH) zugreifenund die Daten in das Patientenverwaltungssystem integrieren.

Die Problematik ergibt sich daraus, dass der Patient das Recht der freien Arztwahlhat und so der Erzeuger der Daten sie nicht speziell für einen Empfänger verschlüs-seln kann, da zu diesem Zeitpunkt nicht bekannt ist, wer der Empfänger ist. Es istlediglich bekannt, welche Adressatengruppe Zugriff auf die Daten erhalten soll.Adressatengruppen können Radiologen, Allgemeinmediziner etc. sein.

Um dieses Problem zu lösen, wurde der folgende Weg gewählt: Die Daten werdensymmetrisch verschlüsselt und der hier eingesetzte Schlüssel als Vorgangskennungbezeichnet. Anschließend werden die Daten mit dem Public Key der Adressaten-gruppe verschlüsselt und auf dem CHIN-Server abgelegt [IBMT2000].

Dem Patienten wird zusammen mit der Überweisung auch die Vorgangskennungausgehändigt, die er dem Arzt seiner Wahl mitteilt. Nun kann der Arzt sich gegen-über dem CHIN Server durch den Besitz des Schlüssels der Adressatengruppe (z.B.Urologe) ausweisen und Patientendaten herunterladen. Er kann jetzt die Verschlüs-selung für seine Adressatengruppe entfernen. Die Daten sind jedoch noch weiterhin

13

verschlüsselt. Ein Zugriff auf die Daten ist nur für den behandelnden Arzt möglich,da er durch den Patienten Zugriff auf die Vorgangskennung hat, die zur weiterenEntschlüsselung benötigt wird.

Der Vorteil dieses Konzeptes besteht darin, dass die Daten zu keinem Zeitpunkt(nach der Übergabe an den CHIN-Server) bis zum vom Patienten gewünschten Arztin unverschlüsselter Form existieren (und sei es im Hauptspeichers des CHIN-Ser-vers). Die Daten sind selbst in dem Fall sicher, in dem der Patient die Vorgangsken-nung verliert. Denn zum Entschlüsseln ist noch immer der passende Schlüssel derAdressatengruppe notwendig. Als Adressatengruppen kommen beispielsweise allemedizinischen Fachrichtungen in Frage, zu denen Patienten überwiesen werden kön-nen (Orthopäden, Radiologen, Internisten etc.).

In der MHH nehmen zur Zeit die Klinik für Urologie und das Institut für Mikrobio-logie als Empfänger dieser elektronischen Überweisungen teil und übermitteln dieBehandlungs- oder Untersuchungsergebnisse an den Überweisenden zurück.

4.2. Authentisierungsverfahren

Authentisierungsverfahren sind quasi die Umkehrung der asymmetrischen Ver-schlüsselung. Hier wird von dem Signierenden ein Dokument mit seinem privatenSchlüssel verschlüsselt und kann dann von jedem durch den öffentlichen Schlüsselwieder zurückgewandelt werden. Da dieser Vorgang relativ langsam ist (der Zeit-aufwand ist etwa genau so groß wie bei dem Einsatz als Verschlüsselungsverfahren)und es (wenn man nur die Signatur betrachtet) nicht auf die Geheimhaltung desInhalts ankommt, wird in der Regel auch hier ein hybrider Ansatz gewählt. Es wirdnicht das Originaldokument verschlüsselt, sondern quasi ein „Fingerabdruck“, derdurch den Einsatz einer sogenannten kryptographischen Hashfunktion erzeugt wird.Zur Überprüfung der Signatur wird nun ebenfalls ein Fingerabdruck des Dokumentserrechnet. Dieser Fingerabdruck wird nun nachdem er entschlüsselt worden ist, mitdem Fingerabdruck des Signierenden verglichen. Genau dann, wenn die beiden Fin-gerabdrücke gleich sind, ist das Dokument authentisch.

Ebenso wie bei der asymmetrischen Kryptographie können die öffentlichen Schlüsselin einer Art Telefonbuch für jeden aufbewahrt werden und so die Überprüfung derEchtheit von Dokumenten ermöglichen. Bei dem RSA-Verfahren kann ein und der-selbe Schlüssel sowohl für die Verschlüsselung als auch für die Signatur eingesetztwerden. Auch bei diesem Verfahren stellt sich die Frage nach der Authentizität derSchlüssel. Diese kann durch den Einsatz einer Zertifizierungsinfrastruktur gelöstwerden, wie im nächsten Abschnitt beschrieben wird.

4.3. Zertifizierungsinfrastrukturen

Bei dem Einsatz asymmetrischer Verfahren für die Verschlüsselung oder Signaturstellt sich bei einem nicht mehr überschaubaren Personenkreis immer die Frage nach

14

der Authentizität der öffentlichen Schlüssel. Eine Signatur ist ohne die Gewissheit,durch wen sie erstellt wurde, nichts wert. So muss z.B. bei der Signatur eines Be-fundes im Krankenhaus zweifelsfrei klar sein, wer die Signatur erstellt hat. Fallskeine Überprüfung möglich ist, könnte ein Unbekannter Diagnosen stellen oderBehandlungen veranlassen. Noch folgenreicher könnte es sein, wenn ein Unbekann-ter vorgibt im Namen eines bestimmten (existierenden) Arztes zu handeln und Fehl-entscheidungen zu Konsequenzen für den betroffenen Arzt – und schlimmer noch fürden Patienten - führen würden.

Diese Bindung eines öffentlichen Schlüssels an eine bestimmte Person geschiehtdadurch, dass eine vertrauenswürdige Stelle (Certification Authority, CA) eineÜberprüfung der Identität einer Person (z.B. durch Vorlage des Personalausweisesoder eines Dienstausweises) feststellt und den von ihr mitgebrachten öffentlichenSchlüssel mit einem Zertifikat versieht. Dieses Zertifikat besagt, dass der Schlüsselund der angegebene Name wirklich zu der genannten Person gehören. Dies wirddurch das Signieren des öffentlichen Schlüssels, der außer dem kryptographischenSchlüssel eben auch noch die Identität des Eigentümers enthält, erklärt.

Damit man diese CA zur Überprüfung der Identität nutzen kann, ist es notwendigden öffentlichen CA-Schlüssel auf einem sicheren Weg zu erhalten und in das eigeneVerschlüsselungssystem zu integrieren, sodass ab diesem Zeitpunkt alle Schlüssel,die ein Zertifikat dieser Stelle tragen, als authentisch angesehen werden können.

Es gibt verschiedene Arten einer Zertifizierungsinfrastruktur. In einer flachenStruktur gibt es eine einzige zentrale Stelle, welche alle Zertifikate ausstellt. Dieskönnten in der MHH z.B. die Rechtsabteilung, Personalabteilung (insbesondere fürdie Schlüssel der Mitarbeiter), das Rechenzentrum oder die Medizinische Informatiksein. Es ist auf jeden Fall darauf zu achten, dass in der verantwortlichen Abteilungdas notwendige (Hintergrund-) Fachwissen für die ordnungsgemäße Durchführungvorhanden ist.

Abbildung 4-1: Flache Struktur [NiSc2001]

In einer hierarchischen Struktur gibt es eine zentrale CA (Root-CA, z.B. diePolicy Certification Authority des DFN-Vereins „Verein zur Förderung eines deut-schen Forschungsnetzes“, DFN PCA), welche wiederum Zertifikate für weitereCAs erstellt (beispielsweise die der MHH). Dabei ist es nun ausreichend, wenn man

15

den öffentlichen Schlüssel der Root-CA hat. Dadurch werden transitiv (s.u.) alleZertifikate als authentisch akzeptiert, die innerhalb dieser Hierarchie erstellt wurden.Da es bisher noch keine Institution gibt, die speziell für das Gesundheitswesen eineallgemein anerkannte CA betreibt, haben sich vier Einrichtungen des Gesundheits-wesens, die Deutsche Krankenhaus TrustCenter und InformationsverarbeitungsGmbH (DKTIG), Informationstechnische Servicestelle der Gesetzlichen Kranken-versicherung GmbH (ITSG), Verband Deutscher Rentenversicherungsträger GmbH(VDR) und Bundesversicherungsanstalt für Angestellte (BfA) zu einer Kooperationzusammengeschlossen und bieten für ihre Mitglieder entsprechende Dienste an[FiGr2001].

Abbildung 4-2: Hierarchische Struktur [NiSc2001]

Es ist auch denkbar, dass die MHH eine CA nutzt, die durch den DFN-Verein, dasLand Niedersachsen, eine Institution des Gesundheitswesens oder einen kommer-ziellen Anbieter betrieben wird.

Das folgende Beispiel verdeutlicht das „transitive Vertrauen“:

Abbildung 4-3: Transitives Vertrauen

16

Rahmenbedingungen:

• Dave (die DFN-CA) hat Marta (die MHH-CA) als CA zertifiziert,

• Alice vertraut Dave, kennt aber Marta nicht näher,

• Bob hat ein Zertifikat von Marta erhalten.

Alice bekommt von Bob eine signierte Mail. Zunächst besorgt sie sich von einemöffentlichen Schlüsselserver den Public Key von Bob. Dort sieht sie, dass dieserSchlüssel von Marta signiert wurde, und besorgt sich ebenfalls den Public Keyvon Marta.

Nun kann sie sehen, dass Bob von Marta zertifiziert wurde und Marta wiederumvon Dave. Da Alice Dave vertraut und Dave Marta vertraut, ist sie sich sicher,dass Bob authentisch ist.

Würde Alice nur direkt von Dave zertifizierten Schlüsseln vertrauen (was einerflachen Struktur entspricht), würde sie Bob nicht als authentisch ansehen.

Zusätzlich zu diesen beiden Modellen gibt es auch noch das „Web of trust“, welchesvon dem Programm PGP verwendet wird und sozusagen als Verallgemeinerung deshierarchischen Modells angesehen werden kann. In dem „Web of trust“ gibt es keinespeziellen CAs, sondern jeder kann Zertifikate für Schlüssel ausgeben. Es kann alsojeder seine eigene CA betreiben und jeder Nutzer kann in seinem System einstellen,welcher CA er vertraut und ob dieses Vertrauen auch transitiv ist. Dieses Modell istfür den Einsatz in der MHH nicht praktikabel, da es hier keine Trennung zwischenden zur Zertifizierung berechtigten Stellen (der CA) und den Signaturen, die jederSchlüsselinhaber tätigen kann, gibt.

Wenn Denise eine signierte Mail von Carol empfängt und Carol nicht näher kennt,kann sie auf die Authentizität von Carol vertrauen, wenn sie Alice oder Bob vertraut(zweistufige Transitivität). Wenn ihre Einstellung restriktiver ist (einstufige Transiti-vität), nur dann, wenn sie Bob vertraut.

Abbildung 4-4: Web of Trust [NiSc2001]

Weitere Informationen über den Aufbau und Betrieb einer CA finden sich beispiels-weise in [CKLW2000].

17

Da der zentrale Server der CA, welcher die Zertifikate ausstellt, keinesfalls an einNetzwerk angeschlossen sein sollte [CKLW2000], ist es notwendig innerhalb derMHH einen Server zu betreiben, der einen nur lesenden Zugriff auf die ausgestelltenund auch die widerrufenen Zertifikate erlaubt.

Wenn in der MHH ausgestellte Zertifikate auch außerhalb der MHH gültig überprüf-bar sein sollen (wovon bei der Integration in eine Zertifizierungshierarchie ausge-gangen werden kann), empfiehlt es sich, den Server für die Abfrage der Zertifikateauch aus dem Internet erreichbar zu gestalten. Selbstverständlich muss der Server ineinem vom Netz der MHH abgeschotteten Segment aufgebaut werden. Sinnvoll wäreauch die Bereitstellung der Zertifikatsinformationen über einen in der Hierarchiehöherrangigen Server, damit kein eigener Server betrieben werden muss.

4.4. Zeitstempel-Dienst

Häufig ist es genauso wichtig zu wissen, wann ein Dokument erstellt wurde, wie zuwissen, von wem es signiert wurde. Eine im Nachhinein erstellte und auf einen Zeit-punkt vor der Ziehung rückdatierte „Vorhersage“ der Lottozahlen ist trotz einer gül-tigen Signatur wertlos.

Da es technisch gesehen kein Problem ist, die Signatur eines Dokumentes vor- oderzurückzudatieren, und der Einsatz eines unabhängigen Dritten bei der Signierungvieler Dokumente nicht praktikabel ist, kann der Aufbau eines Zeitstempel-Dienstesinteressant sein. Ein solcher Dienst nimmt ein Dokument entgegen, versieht es mitder aktuellen Zeit des Eintreffens, signiert dies 2-Tupel (bestehend aus aktuellemDatum und Uhrzeit, sowie dem eingesandten Dokument) und sendet es an denAbsender zurück. Der Absender signiert nun das gesamte mit Zeitstempel und Sig-natur des Zeitstempeldienstes versehene Dokument und hat somit den Nachweis,wann das Dokument erstellt wurde.

Da der Zeitstempeldienst keine inhaltliche Aussage über das Dokument macht (z.B.ob ein Befund korrekt ist), sondern nur die Existenz zu einem bestimmten Zeitpunktbescheinigt, ist es möglich dies automatisiert durch ein Programm durchzuführen,das selbstverständlich sicherstellen muss, dass die aktuelle Uhrzeit bekannt ist. Dazukann z.B. eine Kombination aus DCF77- (Sender zur Übermittlung der offiziellenZeit in Deutschland) oder GPS-Empfänger (Global Position System, ermöglicht diePositions- und Zeitbestimmung) und Anfrage von offiziellen Zeitservern (z.B. derPhysikalisch Technischen Bundesanstalt) sein. Da für einen solchen Zeitstempelselbst das bereits signierte und verschlüsselte Dokument verwendet werden kann,besteht auch keine Gefahr für die Vertraulichkeit der Daten.

18

4.5. Schlüsselverlust

Ein Problem bei dem Einsatz starker Kryptographie (das bedeutet, dass sie nach heu-tigem Kenntnisstand nicht in vertretbarer Zeit zu brechen ist) ist das Problem desSchlüsselverlustes. Wenn Daten nicht nur zur Übertragung, sondern auch bei derSpeicherung oder Archivierung verschlüsselt bleiben, ist es erforderlich bereits beider Erstellung des Konzeptes organisatorische Maßnahmen zu definieren, um denZugriff auf die Daten auch dauerhaft zu ermöglichen.

Das folgenden Beispiel verdeutlich die Problematik:

Ein Arzt speichert Informationen über einen Patienten verschlüsselt ab. Späterist der Schlüssel des Arztes nicht mehr nutzbar.1

Nun steht die MHH vor dem Problem, dass sie Zugriff auf (rechtlich gesehen ihrbzw. dem Patienten gehörenden) Daten benötigt, jedoch kein Schlüssel mehrvorhanden ist. In diesem Fall gibt es mehrere Möglichkeiten auch weiterhinZugriff auf die Daten zu erlangen.

Um den faktischen Verlust der Daten zu verhindern, sind die folgenden Maßnahmen(siehe auch [MPWJ1998a], [MPWJ1998b]) Alternativen:

• Eine Möglichkeit besteht darin, dass die eingesetzten Verschlüsselungspro-gramme einen zusätzlichen Schlüssel verwenden (auch ADK – Additionaldecryption Key – genannt). Durch den Einsatz dieses Schlüssels ist es mög-lich auf offiziellem Wege auf alle innerhalb der MHH verschlüsselten Datenzugreifen zu können.

Dieser Schlüssel ist natürlich entsprechend geschützt zu speichern und durchein Mehraugenprinzip zu schützen; beispielsweise muss – um durch denADK verschlüsselte Dokumente entschlüsseln zu können – immer der Vor-stand der MHH gemeinsam anwesend sein um den Zugriff zu ermöglichen.

• Eine weitere Möglichkeit besteht darin, dass die Schlüssel der Mitarbeiterzusätzlich in einer zentralen Datenbank gespeichert werden, die wiederumdurch einen speziellen Schlüssel gesichert ist, auf den beispielsweise eben-falls nur gemeinsam durch die Vorstandmitglieder der MHH zugegriffenwerden kann. Jetzt kann im Falle des Schlüsselverlustes der Schlüssel selbstwiederhergestellt werden (Key recovery). Dadurch ist es dann auch möglichdem Besitzer des Schlüssels seinen Schlüssel wieder zur Verfügung zu stel-len.

1 Diese Situation kann beispielsweise dadurch entstehen, dass das Medium, auf dem der Schlüsselgespeichert war, verloren ging, der Arzt Opfer eines Unfalls wurde oder er im Streit mit seinemArbeitgeber liegt und den Schlüssel nicht herausgibt.

19

In diesem Fall ergibt sich jedoch die Problematik, dass – sollte derselbeSchlüssel sowohl zur Verschlüsselung als auch zur Signatur eingesetzt wer-den – es möglich wäre, Signaturen im Namen des Schlüsselbesitzers durchzu-führen. Das gleicht Blanko-Unterschriften, die jeder Arzt in der MHH hin-terlegen müsste und auf die beispielsweise der Vorstand Zugriff hätte. EinSzenario, welches der Akzeptanz kryptographischer Werkzeuge sicherlichnicht zuträglich ist.

Eine Lösung für dieses Problem ist der Einsatz von getrennten Schlüsseln fürdie Verschlüsselung und Signatur. Dann müsste nur noch der Verschlüsse-lungsschlüssel hinterlegt werden und der Signierschlüssel bliebe einmaligund geheim. Wenn der Verschlüsselungsschlüssel verloren geht, könnte erwiederhergestellt werden. Sollte der Signierschlüssel verloren gehen, ist dasnicht weiter tragisch, dann würde ein neuer generiert und von der CA zertifi-ziert. Die bereits getätigten Unterschriften blieben gültig (der Public Keywäre ja noch verfügbar), nur für neue Signaturen müsste der neue Signier-schlüssel eingesetzt werden.

Viele Kryptographie-Experten empfehlen ohnehin, getrennte Schlüssel für Ver-schlüsselung und Signatur zu verwenden, um so im Falle von noch verborgenenSchwachstellen der Algorithmen weniger Angriffsmöglichkeiten auf den Signier-schlüssel zu bieten, da in der Regel weniger signiert als verschlüsselt wird. Ebenfallswerden dadurch weitere Angriffe erschwert, wie die chosen-plaintext (bzw. cypher-text)-attack, bei der vom Angreifer dem Opfer ein dem Angreifer bekannter Textbzw. Chiffretext übermittelt wird, der dann vom Opfer entschlüsselt bzw. verschlüs-selt wird.

4.6. Bedrohungsmodelle

Ein wichtiges Kriterium für die Auswahl der geeigneten Verfahren zum Schutz dermedizinischen Daten ist eine Betrachtung des Bedrohungsmodells. Die wesentlichenKriterien sind dabei die folgenden:

• Wie vertraulich sind die Daten (z.B. anonymisierte Studienergebnisse vs.Liste der HIV-Patienten)?

• Vor wem sollten die Daten geschützt werden (vor neugierigen Mitpatienten,nichtautorisiertem Personal, Hackern, Strafverfolgungsbehörden bzw.Geheimdiensten)?

• Welcher Aufwand ist erforderlich, um den Schutz zu umgehen (brute-force-Angriff auf schwach verschlüsselte Daten vs. nachrichtendienstliche Metho-den zur Überwachung zugriffsberechtigter Personen (Tastendrücke mit-schreiben etc.)).

20

• Ist eine Verschlüsselung notwendig, oder ergibt sich der Schutz bereitsdurch den physischen Schutz (Übermittlung der Daten innerhalb eines RZ vs.Übertragung über ein öffentliches Netz)?

Es stellt sich weiterhin die Frage, ob durch den Einsatz kryptographischer Verfahrenein höheres Maß an Sicherheit geboten werden muss, als es bisher mit konventionel-len Mitteln erreicht wurde, oder ob es ausreichend ist, das Niveau zu halten. Blobelund Pommerening schreiben in [BlPo1997]: „Patientendaten sind nach dem Standder Technik zu schützen, wobei aber das Prinzip der Verhältnismäßigkeit zu beach-ten ist.“

Das dieser Arbeit zugrundeliegende Bedrohungsmodell orientiert sich daran, die bis-herige Sicherheit innerhalb der MHH auch durch den Einsatz von Computern weiter-hin zu gewährleisten. Insbesondere ist dafür zu sorgen, dass bei der Datenübermitt-lung über öffentliche Netze (zu denen in diesem Zusammenhang auch spezielleNetze für das Gesundheitswesen gezählt werden, wenn diese keine sichere Punkt-zu-Punkt-Verschlüsselung bieten) die notwendige Sicherheit gewährleistet bleibt.

Für die MHH dürften zumindest vier Angreifermodelle bzw. drei interessant sein:

• Insider: Bei Insidern steht nicht der Wunsch im Vordergrund, durch dieInformationen Geld zu erhalten, sondern der Wunsch nach Rache (z.B. beiunzufriedenen Mitarbeitern oder Studenten), die der MHH eins „auswi-schen“ wollen. Ebenfalls kann es sein, dass dieser Angreifer „nur“ zeigenmöchte, wie leicht es ist, an sensible Daten zu gelangen und den darausresultierenden Ruhm (unerkannt) zu genießen. Bei diesem Personenkreismuss davon ausgegangen werden, dass sie die Strukturen kennen und soeinen gezielten Angriff auf die schwächsten Punkte durchführen können.

• Kriminelle Angreifer: Hier handelt es sich um MHH-fremde Personen, dieein Interesse daran haben, Informationen über Patienten der MHH zu erhal-ten, z.B. um sie zu erpressen. Es ist auch denkbar, dass die Angreifer nichtInformationen über eine konkrete Person suchen, sondern solange alles mit-schneiden, bis etwas dabei ist, durch das sie zu Geld kommen können. DieseAngreifer haben i.d.R. ausreichende Geldmittel zur Verfügung, jedoch häu-fig nicht die Detailkenntnisse über die internen Strukturen. Dieses kannjedoch durch „gekaufte“ Insider kompensiert werden.

• Presse2: Die Presse kann auch ein Interesse daran haben, an sensible Infor-mationen zu kommen. Einerseits wäre es denkbar, dass sie die neuestenInformationen über den Gesundheitszustand Prominenter verbreiten möchte(„Yellow Press“). Andererseits könnte sie auf Probleme im Datenschutzhinweisen wollen. Die Presse kann außerdem versuchen, durch „gekaufte“Insider leichter Zugriff zu erlangen.

2 Analog zur Presse ist es auch vorstellbar, dass externe Angreifer versuchen durch Ausspähen oderVerändern von Daten Aufmerksamkeit zu erregen und ggf. anonym die Aufmerksamkeit zu genießen,die ihnen zuteil wird.

21

• Staat3: Es ist auch denkbar, dass die Polizei oder Geheimdienste Zugriff aufdie Patientendaten erhalten möchten. Diese Dienste haben i.d.R. die Mög-lichkeit die gewünschten Informationen mitzuschneiden und sind der mäch-tigste „Angreifer“. Sie haben im Gegensatz zu den anderen jedoch die Mög-lichkeit legal Zugriff auf diese Informationen zu erhalten. Deshalb könnenwir den Staat als „Angreifer“ in dieser Arbeit unberücksichtigt lassen.

In einem geswitchten Netz (in dem Daten also nicht auf alle Computer des Segmen-tes übertragen werden, sondern nur auf den Zielcomputer) ist ein direktes Mitlesender übermittelten Daten nicht ohne weiteres möglich. Wenn (wie heute üblich) dieBackboneverkabelung (welche die verschiedenen Gebäude oder Gebäudeteile mit-einander verbindet) auf Lichtwellenleitern (LWL-Kabeln) basiert, ist ein einfaches(passives) Mitlesen der übertragenen Daten nicht ohne weiteres möglich. Für Angrei-fer mit großen finanziellen Mitteln oder hohem Fachwissen, wäre es jedoch möglich,an zentralen Stellen die Daten mitzulesen.

Damit die Verschlüsselung der Daten das gewünschte Ziel erreicht, ist es notwendig,mit entsprechenden organisatorischen Maßnahmen, Zugriffe auf die Quell- und Ziel-systeme, die sensible Daten übermitteln, auf ein notwendiges Minimum zu beschrän-ken (das sind z.B. physische Sicherheit der Computer, Firewalls, Access ControlLists auf Routern, eine sichere Konfiguration der Server und ggf. der Einsatz vonserverbasierten Firewall-Modulen).

Weitere Informationen zur Bedrohung der MHH sind im Anhang zu finden.

3 In diesem Fall ist als Staat die Bundesrepublik Deutschland gemeint. Sollten andere Staatenversuchen Zugriff zu erlangen (ohne mittels eines Rechtshilfeersuchens ihren Wunsch zu legalisieren),ist das in etwa mit kriminellen Angriffen gleichzusetzen. Jedoch stehen ihnen deutlich bessere Mittelzur Verfügung als einem „gewöhnlichen Kriminellen“.

22

5. Verwendete Algorithmen

Im Folgenden werden exemplarisch zwei Algorithmen vorgestellt, welche im Kapitel8 (Pragmatisches Modell) verwendet werden. Als symmetrischer Algorithmus wirdRijndael vorgestellt, der sicherlich in Zukunft eine herausragende Bedeutung erlan-gen wird. Er wurde Ende 2001 vom U.S. Handelsministerium für den Einsatz freige-geben, nachdem er in einer Ausschreibung das US National Institute of Standardsund Technology (NIST) als neuer Standard definiert worden war. Rijndael bzw. AES(Advanced Encryption Standard) löst somit DES (bzw. Triple DES) ab. Als asym-metrischer Algorithmus wird RSA vorgestellt, da er z.Zt. der Public-Key-Algorith-mus mit der größten Verbreitung ist (RSA wird in Produkten wie PGP, SSH, SSLetc. eingesetzt).

5.1. Mathematische Grundlagen

Die mathematische Grundlage der hier vorgestellten kryptographischen Algorithmen(und vieler anderer) ist das Rechnen in modularer Arithmetik. Für den Public-Key-Algorithmus RSA werden zusätzlich auch noch für Exponentialchiffren relevanteGrundlagen vorgestellt.

Im Folgenden werden einige wesentliche Definitionen und Sätze aus [Wät2000] und[SchB1996] angegeben. In [Wät2000] können auch die Beweise der hier gezeigtenSätze nachgelesen werden. Einige Ideen zur Darstellung der Galois-Felder sind durch[Lös1999] inspiriert.

Für diesen Abschnitt gelten (sofern nicht anderes vereinbart) die folgenden Konven-tionen:

� := {1,2,3,…}, (die Menge der natürlichen Zahlen)

0� := � ∪ {0}, (die Menge der natürlichen Zahlen mit 0)

� := {0,1,-1,2,-2,…}, (die Menge der ganzen Zahlen)

n ∈ � ,

a, b ∈ � .

Definition 1:

a heißt kongruent b mod n (als Symbol ba n≡ ) genau dann, wenn es ein � k ∈ gibt,für das gilt: n.kba ⋅=−

23

Das bedeutet: n teilt (a-b) (symbolisch: n|(a-b)). a heißt Rest von b mod n und b heißtRest von a modulo n.

Definition 2:

Es sei i ∈{1, 2, ..., n}, r1, r2, ..., rn �∈ .

{r1,r2,...,rn} heißt vollständige Menge von Resten (auch vollständige Residuenmenge)modulo n, wenn es für alle a genau ein ri mit a n≡ ri gibt.

Für ein beliebiges n bildet �

� ={0,1,...,n-1}eine vollständige Menge von Restenmodulo n und kann als Menge der Kongruenzklassen n≡ betrachtet werden und wirdals Restklasse modulo n bezeichnet.

Definition 3:

a mod n bezeichne den Rest von a mod n im Intervall [0,n-1].

Aus a mod n = r folgt a n≡ r (die Umkehrung gilt nicht) und a n≡ b ⇔ a mod n = bmod n. In n� (mit a, b

�� ∈ ) werden die folgenden Verknüpfungen definiert:

n. mod b)(a ban mod b)(aba

⋅=⊗+=⊕

Bekanntlich ist ( ⊗⊕ , ,�

� ) ein Ring und ) , ,( - ) , ,( : f nn ⊗⊕>⋅+ �� , gegeben durch

nf (a) = a mod n, ein Ringhomomorphismus.

Definition 4:

*n� := {a n�∈ | ggt(a,n) = 1} heißt die reduzierte Menge der Reste (oder auch redu-

zierte Residuenmenge) modulo n.

24

Definition 5:

Die Eulersche Funktion ϕ (n) bezeichnet die Elementanzahl der reduzierten Residu-enmenge modulo n.

Sie entspricht der Anzahl der Zahlen x mit 1 ≤ x < n für die ggt(x,n)=1 gilt.

Satz 1:

Es sei ( ⋅+ , ,� ) der Ring der ganzen Zahlen. Durch nf (a) = a mod n wird ein Homor-phismus

) , ,( - ) , ,( : f nn ⊗⊕>⋅+ ��

definiert.

Satz 2:

Es gelte ggt(a,n) = 1, dann gilt für alle i, j 0 �∈ mit 0 ≤ i < j < n die Beziehung:

n mod j)(a n mod i)(a ⋅≠⋅

Folgerung:

Es gelte ggt(a,n) = 1. Dann liefern ( ia ⋅ ) mod n mit i = 0,1,...,n-1 die Reste modulo n,welche die Menge n� = { ( ia ⋅ ) mod n | i = 0,1,...,n-1} bilden.

Satz 3:

Es sei n ≥ 2 und es gelte ggt(a,n) = 1. Dann existiert genau ein x � ∈ , 0 < x < n fürdas ( xa ⋅ ) mod n = 1 gilt.

Damit ist x das multiplikative Inverse von a.

Satz 4:

Es sei n ≥ 2. Dann ist die reduzierte Residuenmenge *n� modulo n eine multipli-

kative Gruppe.

25

Satz 5:

Es sei p eine Primzahl. Dann gilt:

i) ϕ (p) = p-1.

ii) ϕ (pk) = pk-1 (p-1) für k ��∈

iii) Ist q ebenfalls prim und verschieden von p, dann folgt

ϕ (pq) = ϕ (q) ϕ (q) = (p-1)(q-1).

Satz 6: (Fermat)

Es sei p eine Primzahl und es gelte ggt(a,p) = 1. Dann folgt:

ap-1 mod p = 1.

Satz 7:

Es seien e, d, n ��∈ Mit (ed) mod ϕ (n) = 1 und M ∈ [0, n-1] mit ggt(M,n) = 1.Dann gilt:

(Me mod n)d mod n = M.

Folgerung:

Da e und d symmetrisch sind, ist das Potenzieren mit e und d kommutativ und es gilt:

(Md mod n)e mod n = Mde mod n = M.

Deshalb ist es möglich Me mod n = C als Verschlüsselung und Cd mod n = M alsEntschlüsselung zu betrachten.

26

Galois-Felder und Polynome in Körpern

Galois-Felder ( *p� oder GF(p)) sind endliche Körper mit der (Prim-) Charakteristik)

p, in denen alle Operationen Modulo-p durchgeführt werden und p eine Primzahl ist.Die Elemente des Körpers GF(p) sind {1, 2, ..., p-1}. Beispielsweise wird für p=5 dieAddition 3+4 folgendermaßen durchgeführt:

3+4 mod 5 = 7 mod 5 = 2.

In einem Galois-Feld sind die Operationen Addition, Subtraktion, Multiplikation undDivision (mit Ausnahme durch 0) wohldefiniert. Dort ist die 0 das neutrale Elementbezüglich Addition und die 1 das neutrale Element bezüglich der Multiplikation. Fürjede Zahl ungleich 0 existiert ein inverses Element. Das Rechnen in diesen Feldernist kommutativ, assoziativ und distributiv.

Für den (in der Informatik besonders interessanten) Fall p=2 ergibt sich ein Körper,der als Binärkörper bezeichnet wird und die Elemente {0,1} enthält. In diesem Kör-per sind Addition und Subtraktion identisch und lassen sich effizient durch eineXOR-Verknüpfung realisieren.

Es ist möglich ein Polynom f(x) des Grades n mit Koeffizienten aus dem Galois-FeldGF(2) darzustellen:

n. i 0 {0,1}, fmit ,fx f xf ... xf f(x) i012

2n

n ≤≤∈+⋅+⋅++⋅=

Die Addition der Polynome f(x) und g(x) vom Grad n wird wie folgt realisiert:

)gf()x g(f )xg(f ... )xg(f g(x) f(x) 00112

22n

nn ++++++++=+ .

Die Menge aller Polynome über GF(2) bildet einen Ring P(GF(2)). Analog zu n� istes möglich die Operationen + und · durch ⊕ und ⊗ modulo eines bestimmten Poly-noms p(x) (des Grades m) zu ersetzen und erhält einen Ring von Polynomen desGrades < m P(GF(2))/(p(x)).

Das Galois-Feld GF(2) lässt sich erweitern, indem 2 mit m potenziert wird, geschrie-ben GF(2m). Wir fassen GF(2m) als die Menge aller m-Tupel von Elementen ausGF(2) auf. Ein solches Tupel kann aufgefasst werden als Koeffizienten-Tupel einesPolynoms vom Grad < m.

Polynome des Grades 2 mit Koeffizienten aus GF(2) (also 0 und 1) können durchGF(23) dargestellt werden. Die Koeffizienten des Polynoms werden also (in diesemBeispiel) von links gesehen hintereinandergeschrieben. Das Polynom:

x x 0x1 x1 f(x) 22 +=+⋅+⋅=

lässt sich durch das Element (110) aus GF(23) darstellen.

27

Alle in GF(23) enthaltenen Polynome sind:

0, 1, x, x+1, x2, x2+1, x2+x, x2+x+1.

Ein Polynom heißt irreduzibel, wenn es nicht das Produkt zweier Polynome geringe-ren Grades über demselben Körpers ist (es ist dann sozusagen „prim“). Ein solchesPolynom über GF(2) ist beispielsweise:

f(x) = x8+x4+x3+x+1.

Für ein irreduzibles Polynom p(x) ist der genannte Ring P(GF(2))/(p(x)) ein Körper.Durch Wahl eines geeigneten (irreduziblen) Polynoms p(x) vom Grad m erfolgt dieMultiplikation zweier Elemente aus GF(2m) durch Multiplikation der zugehörigenPolynome modulo p(x). Da p(x) irreduzibel ist, gibt es in GF(2m) zu jedem (von 0verschiedenen) Element ein inverses Element.

Im Fall GF(28) werden die Koeffizienten häufig nicht in binärer, sondern in hexade-zimaler Schreibweise geschrieben, was durch ein angefügtes „h“ symbolisiert wird.Das Element (10100101) kann also auch als A5h geschrieben werden.

5.2. Die Algorithmen im Detail

5.2.1. Rijndael - AES

Der Rijndael-Algorithmus (im Folgenden AES genannt) ist ein symmetrischer Algo-rithmus, der mit 128, 192 oder 256 Bit Schlüssellänge und 128, 192 oder 256 BitBlocklänge betrieben werden kann. AES ist ein einfach zu implementierender Algo-rithmus, der mit dem Ziel entworfen wurde, gegen bekannte Angriffsverfahren (bei-spielsweise differentielle oder lineare Kryptoanalyse) resistent zu sein, und effizientsowohl in Software als auch in Hardware implementiert werden kann. Beschriebenwurde der Algorithmus von den Autoren Joan Daemen und Vincent Rijmen in[DaRi1999], von Blömer in [Blö2001] und von Müller in [Mül2001].

Bytes hier werden als Elemente des Körpers GF(28) aufgefasst, in dem die Multipli-kation modulo des irreduziblen Polynoms x8+x4+x3+x+1 durchgeführt wird.

Im Folgenden bezeichne M die Nachricht (bzw. den aktuellen Status während einerRunde), LBlock die Länge des Datenblockes (in Bits), LKey die Länge des Schlüssels(in Bits), NV die Anzahl der Vektoren (Bytes) des Datenblocks, Nb die Anzahl derSpalten der Daten-Matrix M, Nk die Anzahl der Spalten der Schlüssel-Matrix und Nrdie Anzahl der Runden.

28

Im Folgenden sei M die 128, 192 oder 256 Bit lange Nachricht (aus 1282� , 192

2� oder2562� ), die verschlüsselt werden soll. Diese wird in 8-dimensionale Vektoren (aus82� ) aufgeteilt, die im folgenden als Bytes bezeichnet werden. In Abhängigkeit von

der Blocklänge ergeben sich die folgende Anzahl von Bytes:

Blocklänge(LBlock)

Anzahl Bytes(Nv)

128 16

192 24

256 32

Tabelle 5-1: Blockgröße in Bytes

Zur weiteren Berechnung werden die Bytes in M als Matrix mit 4 Zeilen und einervariablen Spaltenanzahl (Nb = Nv/4) betrachtet. Es ergeben sich also 4, 6 oder 8Spalten.

Der (Original-) Schlüssel K wird (analog der Nachricht M) ebenfalls als Matrix dar-gestellt. Jedoch wird nicht in jeder Runde derselbe Schlüssel verwendet, sondern injeder Runde ein anderer, der dieselbe Länge wie der Nachrichtenblock hat (sieheauch RoundKey – Erzeugung) und aus K generiert wird.

Wie bei vielen symmetrischen Algorithmen werden auch bei AES die einzelnen Ope-rationen mehrmals in sogenannten Runden durchgeführt, damit jedes Bit des Chiff-retextes von möglichst vielen Bits des Quelltextes und möglichst vielen Bits desSchlüssels abhängt und so quasi zufällig erscheint.

Die Anzahl der Runden (Nr) ist sowohl von der Block- als auch von der Schlüssel-länge abhängig. Die Rundenanzahl ist in der folgenden Tabelle dargestellt:

29

RundenanzahlNr

Blocklänge

Schlüssellänge(LKey)

128(Nb=4)

192(Nb=6)

256(Nb=8)

128 (Nk=4) 10 12 14

192 (Nk=6) 12 12 14

256 (Nk=8) 14 14 14

Tabelle 5-2: Rundenanzahl [DaRi1999]

Die Verschlüsselung wird durch die folgenden Operationen in insgesamt Nr Rundendurchgeführt. Die Anzahl der Spalten der Datenmatrix ist Nb, die Anzahl der Spaltender Schlüsselmatrix ist Nk. Der verwendete Schlüssel wird nur in der OperationAddRoundKey verwendet. Alle anderen Operationen sind unabhängig vom Schlüs-sel. Damit die Diffusion in jeder Runde erhöht wird, wird in jeder Runde ein eigenerRunden-Schlüssel verwendet, der sich aus dem gegebenen Schlüssel ableiten lässt.Es ist möglich die Rundenschlüssel vor Beginn der Runden für alle Runden zuberechnen.

Um eine Known Plaintext Attack zu erschweren (die beispielsweise durch standardi-sierte Bytefolgen bei bestimmten Datentypen vorkommt) wird vor der ersten Runde(sozusagen in der Runde 0) der Originaldatenblock M mit den ersten Bits des Run-denschlüssels (RK) mittels XOR verknüpft.

Nr-1 mal werden die folgenden Operationen ausgeführt, die im Folgenden erläutertwerden:

• ByteSub(M)

• ShiftRow(M)

• MixColumn(M)

• AddRoundKey(M, RK)

Die letzte Runde sieht folgendermaßen aus:

• ByteSub(M)

• ShiftRow(M)

• AddRoundKey(M, RK)

RoundKey – Erzeugung

Da in jeder Runde ein eigener Rundenschlüssel verwendet wird, werden insgesamtLBlock · (Nr+1) Schlüssel Bits benötigt (bei 192 Bit Blocklänge und 12 Runden also

30

2496 Bits). Da der Schlüssel K aber nur 128, 192 oder 256 Bits lang ist, muss er aufdie notwendige Länge expandiert werden. Dieser expandierte Schlüssel RK kann alslineares Bit-Feld betrachtet werden, dessen einzelne Bits als RKi angesprochen wer-den.

Die ersten LKey Bits von RK entsprechen dem Schlüssel K. Die folgenden Bits wer-den wie in [DaRi1999] beschrieben rekursiv aus diesen Bits erzeugt. Es sei r � ∈ dieNummer der aktuellen Runde. Dann werden in der Runde r die Schlüsselbits RKr·Nbbis RK((r+1)·Nb)-1 verwendet.

ByteSub – Transformation

Die ByteSub-Transformation besteht aus einer nichtlinearen bijektiven Byte-Substi-tution, die jeweils auf M angewendet wird und invertierbar ist. Diese sogenannte S-Box besteht aus der konstanten Matrix B (8x8-Bit) und dem konstanten Vektor z (8Bit, 1 Byte). Jedes Byte x (an der Position i,j) aus M wird mit dieser S-Box transfor-miert und bildet so y (an der Position i,j). Die Transformation sieht folgendermaßenaus: y = B · x + z.

��

�

�

��

�

�

+

��

�

�

��

�

�

×

��

�

�

��

�

�

=

��

�

�

��

�

�

01100011

xxxxxxxx

1111100001111100001111100001111110001111110001111110001111110001

yyyyyyyy

7

6

5

4

3

2

1

0

7

6

5

4

3

2

1

0

S-Box

ShiftRow - Transformation

Die Zeilen von M werden in Abhängigkeit von der Blockgröße zirkulär nach linksverschoben.

31

Nb Z1 Z2 Z3

4 (128 Bit) 1 2 3

6 (192 Bit) 1 2 3

8 (256 Bit) 1 3 4

Tabelle 5-3: Zeilenverschiebung (ShiftRow) [DaRi1999]

In der Matrix M werden nun die Bytes in den Zeilen nach links verschoben.

Zeile 0: keine Änderung

Zeile 1: verschiebe die Bytes um Z1 Positionen zyklisch nach links



Im Fall von 192 Bit Blocklänge (Nb=6) und mit Buchstaben als Bytes sieht das dannfolgendermaßen aus:

��

�

�

��

�

�

�

��

�

�

��

�

�

utsxwvnmrqpoglkjihfedcba

xwvutsrqponmlkjihgfedcba

ShiftRow

ShiftRow

MixColumn - Transformation

Die Nb Spaltenvektoren (für Nb=4: a0, a1, a2, a3) von M bestehen jeweils aus 4 Bytesund werden als Polynome über GF(28) betrachtet und mit dem festen Polynom c(x) =03h·x3 + 01h·x2 + 01h·x + 02h (beim Entschlüsseln mit dem Inversen Polynom d(x)= 0Bh·x3 + 0Dh·x2 + 09h·x + 0Eh) modulo x4+1 multipliziert (die Koeffizienten sindjeweils in Hexadezimalschreibweise angegeben).

Die Polynommultiplikation modulo eines festen Polynoms lässt sich auch als Matri-zenmultiplikation darstellen, bei der die Koeffizienten (von rechts nach links) in dieunterste Zeile der Matrix geschrieben und jeweils in der darüber liegenden Zeile umeine Position zirkulär nach links verschoben werden:

32

��

�

�

��

�

�

×

��

�

�

��

�

�

=

��

�

�

��

�

�

3

2

1

0

3

2

1

0

aaaa

02010103030201010103020101010302

bbbb

MixColumn

AddRoundKey – Schlüsseladdition

Zur Addition des Schlüssels wird der aktuelle Rundenschlüssel als Matrix betrachtet,die aus den jeweiligen Bits von RK besteht (in der 1. Runde RK192-RK383, in der 2.RK384-RK575 usw.). Die Addition erfolgt als Matrizenaddition, die mittels eines XORrealisiert werden kann.

Im Fall von Nb=6 (192 Bit Blocklänge) sieht das folgendermaßen aus:

��

�

�

��

�

�

⊕

��

�

�

��

�

�

=

��

�

�

��

�

�

3,53,43,33,23,13,0

2,52,42,32,22,12,0

1,51,41,31,21,11,0

0,50,40,30,20,10,0

3,53,43,33,23,13,0

2,52,42,32,22,12,0

1,51,41,31,21,11,0

0,50,40,30,20,10,0

3,53,43,33,23,13,0

2,52,42,32,22,12,0

1,51,41,31,21,11,0

0,50,40,30,20,10,0

kkkkkkkkkkkkkkkkkkkkkkkk

aaaaaaaaaaaaaaaaaaaaaaaa

bbbbbbbbbbbbbbbbbbbbbbbb

AddRoundKey

33

Für den Fall, dass die Blocklänge 128 Bit ist (Nb=4), sieht der Ablauf einer Runde sowie in Abbildung 5-1 (AES-Verschlüsselung [Sav2001]) dargestellt aus. Die Bytes„fließen“ quasi von oben in die Runde hinein und werden mit den genannten Opera-tionen bearbeitet.

Abbildung 5-1: AES-Verschlüsselung [Sav2001]

5.2.2. RSA

Der Public Key Algorithmus RSA wurde 1977 von Rivest, Shamir und Adlemanentworfen und ist dazu in der Lage sowohl für Verschlüsselung als auch zur digitalenSignatur eingesetzt zu werden.

Die Basis des RSA-Algorithmus besteht darin, dass es mit den heutigen Computerneinfach und schnell möglich ist, große Zahlen mit mehreren hundert Dezimalstellenzu multiplizieren, es jedoch bisher unmöglich ist (in einer akzeptablen Zeit, s.u.) diePrimfaktoren einer ebenso großen Zahl, welche das Produkt zweier großer Primzah-len ist, herauszufinden. In [SchB1996] schreibt Bruce Schneier, dass zur Faktorisie-rung einer 2048-Bit-Zahl, wie sie für Public-Key-Systeme eingesetzt wird, mit einemallgemeinen Zahlenkörpersieb 3·1011 MIPS-Jahre und mit einem speziellen Zahlen-körpersieb 3·107 MIPS-Jahre erforderlich sind. Das heißt, ein Computer, der eineMillion Rechenoperationen in der Sekunde durchführt, 3·1011 bzw. 3·107 Jahre zurLösung der Aufgabe benötigen würde.

Dass ein Faktorisierungsangriff (quasi ein Brute-Force-Angriff auf RSA) auf einenöffentlichen Schlüssel mit 2048 Bit keinen Sinn ergibt, verdeutlich das folgende Bei-spiel:

Der von IBM Ende 2001 vorgestellt Hochleistungscomputer p690 („Regatta“)kann mit bis zu 32 POWER-4 CPUs ausgestattet werden. Die Taktfrequenzjeder CPU beträgt 1,3 GHz. IBM gibt in [IBM2001] an, dass eine CPU bis zu8 Befehle pro Taktzyklus auszuführen in der Lage ist und durchschnittlich 5Befehle pro Zyklus abschließt.

34

Daraus ergeben sich nach [HePa1996] die theoretisch maximalen MIPS-Leistungen von 6.500 MIPS (bei 5 Befehlen pro Zyklus) bzw. 10.400 MIPS(bei 8 Befehlen pro Zyklus) pro CPU. Das entspricht 208.000 MIPS (bei 5Befehlen pro Zyklus) bzw. 332.800 MIPS (bei 8 Befehlen pro Zyklus) für ein32-CPU System.

Das bedeutet, dass eine p690 mit 32 CPUs ca. 1,9 Milliarden Jahre (5 Befehlepro Zyklus) bzw. ca. 1,2 Milliarden Jahre (8 Befehle pro Zyklus) benötigt, umdurch den Einsatz des speziellen Zahlenkörpersiebes (welches jedoch bei denin der Regel verwendeten Schlüsseln nicht eingesetzt und eher als optimis-tisch angesehen werden kann) einen einzigen 2048-Bit-Schlüssel durch Fak-torisierung zu brechen. Bei dem Einsatz des allgemeinen Zahlenkörpersiebessind die Zeiten noch erheblich höher (ca. Faktor 107).

Da dieser Computer (mit nur 16 anstatt der hier angenommenen 32 CPUs) fürca. 450.000 US-$ zu erhalten ist [iX2002-03], handelt es sich hier auch umein sehr teures Unterfangen.

Selbst wenn man 24 dieser 32-CPU-Computer miteinander verbindet (wie aufder CeBIT 2002 für das Projekt Hochleistungsrechenzentrum Nord (HLRN)angekündigt), dauert die Berechnung noch immer ca. 79 Millionen Jahre (5Befehle pro Zyklus) bzw. 50 Millionen Jahre (8 Befehle pro Zyklus) beiAnschaffungskosten von ca. 20 Millionen Euro.

In vielen Public-Key-Systemen, wie beispielsweise in PGP, wird der RSA-Algorith-mus verwendet, der im Folgenden beschrieben wird.

Die Grundlage von RSA ist die Erzeugung des Schlüsselpaares. Dazu wird der fol-gende Algorithmus verwendet. Es sei EAlice die Verschlüsselung mit Alices öffentli-chen Schlüssel, DAlice die Entschlüsselung mit Alices privatem Schlüssel (DBob undEBob analog für Bob).

RSA-Algorithmus zur Schlüsselerzeugung:

Alice:

i. Erzeuge zwei (etwa gleichgroße) Primzahlen p und q.

ii. Berechne n = pq und ϕ (n) = (p-1)(q-1).

iii. Wähle ein e (1 < e < ϕ (n)) mit ggt(e, ϕ (n)) = 1.

iv. Berechne d (1 < d < ϕ (n)) mod ϕ (n) mit ed mod ϕ (n) = 1, das eindeu-tige Inverse zu e in *

n)(ϕ� .

Alice erhält als öffentlichen Schlüssel das Tupel (e,n) und als privaten Schlüssel(d,n).

35

Wenn nun Bob eine Nachricht M an Alice senden möchte, verwendet er, nachdem erden öffentlichen Schlüssel von Alice (e,n) erhalten und die Authentizität überprüfthat, den folgenden Algorithmus.

RSA-Algorithmus zur Ver- und Entschlüsselung:

i. Bob

a) Betrachte M als Zahl aus dem Intervall [0, n-1].

b) Berechne EAlice(M) = Me mod n = C.

c) Sende C an Alice.

ii. Alice

Berechne DAlice(C) = Cd mod n = M.

Neben der Ver- und Entschlüsselung ist es mit dem RSA-Algorithmus auch möglich,digital zu signieren. Wenn Alice an Bob eine signierte Nachricht M senden möchte,wird der folgende Algorithmus verwendet, nachdem Bob den öffentlichen Schlüssel(e,n) erhalten hat.

RSA-Algorithmus zur Signatur:

i. Alice

a) Betrachte M als Zahl aus dem Intervall [0, n-1].

b) Berechne DAlice(M) = Md mod n = C.

c) Sende C an Bob.

ii. Bob

Berechne EAlice(C) = Ce mod n = M.

Wenn M einen sinnvollen Text ergibt, betrachtet Bob die Nachricht als authentischvon Alice versand.

Es ist ebenfalls möglich die Verschlüsselung und Signatur zu kombinieren. Dazumüssen Alice und Bob jeweils ein eigenes Schlüsselpaar besitzen. Wenn Alice nuneine signierte Nachricht M verschlüsselt an Bob sendet, führt sie vorher die folgen-den Schritte aus:

EBob(DAlice(M)) = C.

Bob erhält dann durch Anwendung von

EAlice(DBob(C)) = M

die signierte Originalnachricht, die Alice gesendet hat.

Das funktioniert jedoch nur dann, wenn der für EBob verwendete Modulus n größerist als der davon verschiedene für DAlice verwendete Modulus n. Falls das nicht derFall ist, funktioniert dieses Verfahren nicht, da korrekte Signaturen fälschlicherweiseals fehlerhaft geliefert würden.

36

Dieses Problem kann dadurch gelöst werden, dass jeder Nutzer zwei Schlüsselpaareerzeugt: eines für die Signatur und eines für die Verschlüsselung. Dabei ist darauf zuachten, dass der Modulus nEnc für jeden Verschlüsselungsschlüssel größer ist als derModulus nSig für jeden verwendeten Signaturschlüssel. Damit das in einem komple-xen Umfeld funktioniert, muss es ein t geben, für das gilt:

nSig < t ≤ nEnc

Es seien EncAlice, DecAlice die Ver- und Entschlüsselunsgschlüssel und SigAlice undVerAlice die Signier- und Überprüfungsschlüssel von Alice (Bob analog). Dann lassensich das Signieren und Verschlüsseln einer Nachricht M von Alice an Bob folgender-maßen umsetzen:

EncBob(SigAlice(M)) = C.

Bob erhält dann durch Anwendung von:

VerAlice(DecBob(C)) = M.

Wenn eine Nachricht verschlüsselt werden soll, die länger als der Modulus desSchlüssels ist, muss sie in Blöcke aufgeteilt werden und diese müssen dann einzelnverschlüsselt werden.

In der Praxis wird RSA jedoch meistens nicht direkt zum Verschlüsseln der Nutzda-ten eingesetzt, sondern zum Verschlüsseln eines Sitzungsschlüssels (Session Key),der für eine symmetrische Verschlüsselung verwendet wurde (siehe auch 4.1.3(Hybride Verschlüsselung)). Ebenfalls wird normalerweise nicht die ganze Nachrichtmittels RSA signiert, sondern eine kryptographische Prüfsumme über die Nachrichtgebildet, diese signiert und von Alice zusammen mit der Nachricht an Bob übermit-telt. Der Empfänger berechnet dann mit demselben Algorithmus ebenfalls die Prüf-summe und vergleicht sie mit der von Alice gesendeten (siehe auch 4.2(Authentisierungsverfahren)).

Das Problem bei öffentlichen Schlüsseln ist in der Regel die Überprüfung derAuthentizität, wenn es keinen sicheren Kanal gibt, auf dem der öffentliche Schlüsselausgetauscht und die Identität des Absenders sichergestellt werden kann. Um das zuerreichen kann ein Dritter, beispielsweise Charlie, dem sowohl Alice als auch Bobvertrauen, die Echtheit der Schlüssel von Alice durch das Signieren des Paares(EAlice, „Dieser Schlüssel gehört Alice“) zertifizieren (natürlich auch analog denSchlüssel von Bob). In diesem Beispiel wäre Charlie eine CA und es gilt das in 4.3(Zertifizierungsinfrastrukturen) Geschriebene.

37

6. Ausgewählte Kommunikationsprozesse

„Sicherheit ist ein Prozess und kein Produkt."


Im Folgenden werden exemplarisch einige Kommunikationsanwendungen beschrie-ben, die Einsatzmöglichkeiten für verschiedene Verfahren geben. Die Beispiele wur-den so ausgewählt, dass sie einen großen und häufig vorkommenden Bereich derKommunikation abdecken bzw. strukturgleich auf andere Prozesse übertragen wer-den können.

Die Darstellung gliedert sich in zwei Teile. Im ersten Teil wird der Prozess allgemeinbeschrieben und im zweiten Teil (siehe Tabelle 7-2 (Auswahl kryptographischerVerfahren)) sind charakteristische Parameter des Prozesses benannt. Dadurch ist esmöglich, andere – hier nicht genannte - Prozesse zu kategorisieren und Ähnlichkeitenzu hier beschriebenen Prozessen zu erkennen, um das geeignete Verfahren leicht aus-wählen zu können.

6.1. Struktur der Betrachtung

Um die Analyseergebnisse der im Folgenden vorgestellten Prozesse auch auf andereProzesse übertragen zu können, wird zu jedem Prozess eine Tabelle mit den (für dieKryptographie signifikanten) charakteristischen Merkmalen aufgestellt. DieseMerkmale schließen sich gegenseitig nicht aus. Die in der Tabelle verwendetenKürzel sind im folgenden in [] eingeklammert. Die Ergebnisse der Analyse lassensich dann auf ähnliche Prozesse, welche dieselben charakteristischen Merkmalehaben, leicht adaptieren.

Netz-Umgebung:

Die Umgebung, in welcher die Datenübertragung stattfindet, ist ein relevantes Krite-rium für die Auswahl der Verschlüsselung. Wenn beispielsweise zwei im Rechen-zentrum direkt nebeneinander stehende Computer über eine direkte Verbindung(Crossconnect Kabel) verbunden sind, ist das Risiko, dass die Übermittlung abgehörtwerden kann, sehr gering unter anderem schon deshalb, weil der physische Zugangstark reglementiert werden kann. Werden die Daten hingegen über das Internet über-tragen, gibt es sehr viele Punkte, an denen die Daten mitgelesen werden können.

38

Merkmale der Netz-Umgebung:

• Kommunikation innerhalb eines physisch gesicherten Bereichs (z.B. gesi-cherter Rechnerraum, in dem sowohl die Netzwerkkomponenten als auchdie beteiligten Server stehen). [Sicher]

• Kommunikation innerhalb einer Institution. [LAN]

• Kommunikation über ungesicherte, direktgeschaltete WAN Strecken.[Corporate LAN]

• Kommunikation über ein ungesichertes Netz. [Internet]

Art der Kommunikation:

Die Kommunikation kann mit verschiedenen Kommunikationsprotokollen erfolgen.Wird beispielsweise die Übertragung durch den Einsatz eines Webbrowsers undWeb-Servers mittels HTTP durchgeführt, ist es relativ einfach, die Übertragungdurch den Einsatz von HTTPS zu verschlüsseln und auch zu authentisieren. Wenndie Übertragung lediglich mit Standardprogrammen wie z.B. FTP erfolgt, ist es ggf.möglich, zwischen der Erzeugung der Daten und der Übertragung (bzw. dem Emp-fang und der Verarbeitung) Zwischenstufen zur Authentisierung oder Verschlüsse-lung einzubauen. Wenn der Prozess proprietäre Protokolle verwendet, ist eine für dieAnwendung transparente Verschlüsselung notwendig.

Merkmale der Art der Kommunikation:

• Die Kommunikation erfolgt mit anwendungsspezifischen Protokollen.[Spezifisch]

• Die Kommunikation erfolgt mit Standardprotokollen. [Standard]

• Die Kommunikation kann transparent (auf Übertragungsebene) gesichertwerden. [Transparent]

Kommunikationspartner:

Die Kommunikation kann direkt zwischen zwei oder mehr Menschen beispielsweiseE-Mail erfolgen, zwischen einem Menschen und einem Programm (z.B. Abfrage vonWeb-Seiten) oder auch zwischen zwei Programmen (z.B. Übertragung von Daten desLabors zu einer Klinik).

39

Merkmale der Kommunikationspartner:

• Die Kommunikation erfolgt zwischen Menschen (Mensch – Mensch, z.B.Mail). [M-M]

• Die Kommunikation erfolgt zwischen einem Menschen und einem Pro-gramm (Mensch – Programm, z.B. Webzugriffe). [M-P]

• Die Kommunikation erfolgt zwischen Programmen (Programm – Pro-gramm). [P-P]

Bekanntheit des Kommunikationspartners:

Es ist wesentlich einfacher sich von der (elektronischen) Authentizität eines bekann-ten Kommunikationspartners zu überzeugen als bei einem Unbekannten. Beim erstenBeispiel kann der Schlüsseltausch manuell erfolgen oder ggf. per Telefon verifiziertwerden. Bei Unbekannten ist der Einsatz einer Zertifizierungsinstanz angeraten, derbeide Teilnehmer vertrauen.

Merkmale der Bekanntheit der Kommunikationspartner:

• Kommunikationspartner kennen sich gegenseitig. [bekannt]

• Kommunikationspartner kennen sich gegenseitig nicht. [unbekannt]

Sensitivität:

Abhängig von der Sensitivität der Daten kann eine unterschiedlich starke Verschlüs-selung eingesetzt werden. So ist sicherlich die Tatsache, dass jemand Patient ineinem Krankenhaus war, weniger sensitiv, als die Tatsache, dass er HIV-positiv ist.Aus der Einstufung heraus wäre es möglich, unterschiedlich starke Verschlüsselun-gen zu wählen. Es sollte immer mit einer möglichst starken Verschlüsselung gear-beitet werden.

Merkmale der Sensitivität:

• Die Sensitivität der Daten ist gering. [gering]

• Die Sensitivität der Daten ist mittel. [mittel]

• Die Sensitivität der Daten ist hoch. [hoch]

Rechtliche Verbindlichkeit/Beweisbarkeit:

Ist es bei bestimmten Daten wichtig (ggf. vor Gericht), nachweisen zu können, wersie erstellt hat? Eine per E-Mail versandte Einladung zu einem Meeting muss in denseltensten Fällen signiert werden. Eine per Internet-E-Mail versandte Diagnose einesArztes aus einem anderen Krankenhaus muss (siehe Kapitel 3 (Rechtlicher Rahmender Kryptographie in Deutschland)) genauso signiert werden wie ggf. im Vorfeldübermittelte medizinische Daten (beispielsweise Laborwerte).

40

Merkmale der rechtlichen Verbindlichkeit/Beweisbarkeit:

• Die Verbindlichkeit/Beweisbarkeit ist irrelevant. [irrelevant]

• Die Verbindlichkeit/Beweisbarkeit ist erwünscht. [erwünscht]

• Die Verbindlichkeit/Beweisbarkeit ist notwendig. [notwendig]

• Die Verbindlichkeit/Beweisbarkeit ist durch Gesetze vorgeschrieben.[zwingend]

Anpassung der Systeme möglich (z.B. Zertifikate):

Ist es möglich, die Programme, die zur Übermittlung der Daten eingesetzt werden,anzupassen? Wenn in einem kommerziellen Programm beispielsweise Daten durchden Aufruf eines externen Programms (z.B. FTP) übertragen werden, ist es ggf.möglich, eine Zwischenstufe einzubauen, welche die gewünschtenkryptographischen Aktionen durchführt.

Merkmale der Systemanpassung:

• Eine Anpassung des Systems ist möglich. [Ja]

• Eine Anpassung des Systems ist nicht möglich. [Nein]

Einsatz von Spezialsoftware möglich:

Wird die Kommunikation durch selbsterstellte Software durchgeführt, in die belie-bige Methoden zur Verschlüsselung integriert werden können?

Merkmale des Einsatzes von Spezialsoftware:

• Spezialsoftware kann eingesetzt werden. [Ja]

• Spezialsoftware kann nicht eingesetzt werden. [Nein]

Performance:

Ist die Performance bei der Durchführung sehr wichtig oder ist sie weniger wichtig?Wenn beispielweise eine direktgeschaltete Leitung verschlüsselt wird, würde es kei-nen Sinn machen, wenn durch die Verschlüsselung die verfügbare Bandbreite nichtvollständig ausgeschöpft werden kann. Ebenfalls kann es relevant sein, wie groß dieVerzögerung in der Datenübermittlung ist. Wenn dadurch z.B. Telefon- oder Video-konferenzen über TCP/IP beeinträchtigt werden, sollten leistungsfähigere Verschlüs-selungskomponenten eingesetzt werden.

41

Merkmale der Performance:

• Die Performance der Datenübertragung ist wichtig. [relevant]

• Die Performance der Datenübertragung ist nicht wichtig. [irrelevant]

Archivierung:

Werden die Daten nur für eine Übertragung gespeichert oder werden sie auch ver-schlüsselt gespeichert? Sofern nicht nur die Übertragung verschlüsselt wird, sondernauch die Daten verschlüsselt archiviert werden, ist es notwendig Vorkehrungen fürden Fall des Schlüsselverlustes zu treffen.

Merkmale der Archivierung:

• Die Daten werden im übermittelten Format archiviert. [Ja]

• Die Daten werden nicht im übermittelten Format archiviert. [Nein]

6.2. Kommunikationsprozesse

6.2.1. Datenübermittlung zwischen Instituten

In diesem Szenario wird untersucht, welche kryptographischen Verfahren bei derautomatischen Übertragung von Daten zwischen zwei Instituten (z.B. einem Laborund einer Klinik) eingesetzt werden können. Es handelt sich dabei in der Regel umUntersuchungsergebnisse, die durch einen speziellen Labor-Computer ermittelt undauf ein Unix-System innerhalb des Labors übertragen wurden. Anschließend werdensie auf das Unix-System in einer Klinik per FTP übertragen, um dann weiterverar-beitet zu werden. Unabhängig vom Einsatz kryptographischer Verfahren ist es wün-schenswert automatisch zu überprüfen, ob die Daten das Zielsystem erreicht habenum sie gegebenenfalls erneut automatisch zu übermitteln.

Zusätzlich zur elektronischen Übermittlung werden die Laborwerte auch in der Ziel-klinik ausgedruckt. Da dieser Ausdruck nicht von einem Arzt unterschrieben werdenmuss, ist eine Signatur der per FTP übertragenen Daten nicht aus rechtlichen Grün-den notwendig. Es ist sinnvoll, sie mit einem Signaturschlüssel des Labors zu verse-hen, damit die Authentizität und die fehlerfreie Übermittlung sichergestellt werdenkönnen.

42

Netz-Umgebung LAN

Art der Kommunikation Standard, Transparent

Kommunikationspartner P-P

Bekanntheit des Kommunikationspartner bekannt

Sensitivität hoch

Rechtliche Verbindlichkeit/Beweisbarkeit irrelevant, erwünscht

Anpassung der Systeme möglich Ja

Einsatz von Spezialsoftware möglich Ja

Performance irrelevant

Archivierung Nein

Tabelle 6-1: Datenübermittlung zwischen Instituten

6.2.2. Direktgeschaltete Verbindung zu einer anderen Klinik

Dieses Szenario zielt darauf ab, entfernte Standorte transparent mit dem Netz derMHH zu koppeln, ohne dass Endanwender in ihren Möglichkeiten eingeschränktwerden und alle Klinik-Anwendungen nutzen können, als wären sie auf dem Cam-pus. Das bedeutet auch, dass gegebenenfalls vertrauliche Daten über ungesicherteVerbindungen übermittelt würden. Als Beispiele für diese Anwendungen könnte z.B.die Anbindung des Oststadtkrankenhauses (welches teilweise zur MHH gehört) odereiner Außenstelle in der Walderseestraße dienen.

Da es nicht möglich sein wird, alle Anwendungen auf den Einsatz von Kryptographieumzustellen, wird es erforderlich sein, die Leitung zu verschlüsseln. Anschließendsind die Anwendungen quasi auf demselben Sicherheitsniveau wie auf dem Campusund eine gesonderte Betrachtung der Anwendungen ist nicht erforderlich.

Besonders wichtig ist die Verschlüsselung, wenn die Datenübermittlung nicht überKabel, sondern per (Richt-) Funk oder mittels optischer „Laser Links“ realisiert wird.Denn ein Funksignal kann leichter unbemerkt abgehört werden als eine kabelgebun-dene Verbindung.

43

Netz-Umgebung Corporate LAN

Art der Kommunikation Transparent

Kommunikationspartner M-M, M-P, P-P


Sensitivität hoch

Rechtliche Verbindlichkeit/Beweisbarkeit irrelevant

Anpassung der Systeme möglich nicht relevant

Einsatz von Spezialsoftware möglich nicht relevant

Performance relevant

Archivierung Nein

Tabelle 6-2: Direktgeschaltete Verbindung zu einer anderen Klinik

6.2.3. Internetverbindung zu einem anderen Krankenhaus

Im Zuge einer engen Zusammenarbeit mit anderen weit entfernten Kliniken kann eswünschenswert sein, eine (durch einen Firewall gesicherte) Verbindung über dasInternet (bzw. GWIN) aufzubauen, über die beispielsweise Zugriffe auf Radiologi-sche Systeme geboten werden, welche eine hohe Bandbreite erfordern. Ebenso wiebei der direkten Verbindung zu einer Außenstelle ist hier die Verschlüsselung derLeitung über das Internet wichtig. Anwendungen werden hier nicht gesondertbetrachtet. Die Übermittlung von Behandlungsdaten an die Krankenkassen gemäßGesundheitsstrukturgesetz ([MDJP1998]) könnte anstatt über ISDN-Verbindungenüber einen solchen VPN-Tunnel erfolgen.

Netz-Umgebung Internet


Kommunikationspartner M-M, M-P, P-P

Bekanntheit des Kommunikationspartner unbekannt

Sensitivität hoch





Archivierung Nein

Tabelle 6-3: Internetverbindung zu einem anderen Krankenhaus

44

6.2.4. Gesicherte Einwahl über ISDN, Modem oder Internet

Durch den immer stärker werdenden Einsatz der Computer wird es erforderlich, auchvon außerhalb einen transparenten Zugriff auf die Komponenten der MHH zu erhal-ten. Ebenso kann es vorkommen, dass z.B. im Bereitschaftsdienst Zugriff auf wich-tige Systeme benötigt werden. Hierbei werden sensible Daten, oder zumindestBenutzerkennungen und Passworte, übertragen, die unbedingt geschützt werdenmüssen. Im Gegensatz zu den Festverbindungen handelt es sich hier um eine Viel-zahl von dynamisch aufgebauten Verbindungen, die möglichst ohne aufwendigeHardware auf der Gegenseite funktionieren sollten. Ebenso wie bei der direkten Ver-bindung zu einer Außenstelle ist hier die Verschlüsselung der Leitung über Modem,ISDN oder das Internet wichtig. Anwendungen werden hier nicht gesondert betrach-tet. Im Prinzip ist eine solche Verbindung nichts anderes als ein VPN zwischen demeinzelnen Anwender und der MHH mit dem Unterschied, dass der Anwender keineneigenen Firewall hat.



Kommunikationspartner M-M, M-P


Sensitivität hoch





Archivierung Nein

Tabelle 6-4: Gesicherte Einwahl über ISDN, Modem oder Internet

6.2.5. Webbasierte Kommunikation

Wenn in zunehmendem Maße sensible Daten auf Web-Servern gespeichert werden,ist es wichtig, dass nur Berechtigte auf die Daten zugreifen und dass die Zugriffeauch wirklich auf den richtigen Server gehen. Ebenfalls sollten die Daten möglichstverschlüsselt werden. Es ist damit beispielsweise möglich den Zugriff auf Interna nurfür Mitarbeiter bestimmter Kliniken oder Einrichtungen zu ermöglichen.

Dadurch ist es auch möglich, für berechtigte Externe über das Internet Ergebnisseabrufbar zu machen. So könnte beispielsweise der Befundbrief der MHH von einemniedergelassenen Arzt über das Internet abgerufen werden, nachdem er sich mit sei-nem Client (PC) dem MHH-Server gegenüber authentisiert hat, dass für einen siche-

45

ren Zugriff auf solch sensible Daten aus dem Internet noch mehr zu tun ist als nurden Anfordernden eindeutig zu identifizieren und die Daten zu verschlüsseln, würdeden Rahmen dieser Arbeit sprengen und basiert auch weniger auf kryptographischenAnwendungen, als auf allgemeiner IT-Sicherheit.

Netz-Umgebung Sicher, LAN, CorporateLAN, Internet

Art der Kommunikation Standard

Kommunikationspartner M-P

Bekanntheit des Kommunikationspartner bekannt, unbekannt

Sensitivität mittel, hoch

Rechtliche Verbindlichkeit/Beweisbarkeit erwünscht

Anpassung der Systeme möglich Nein

Einsatz von Spezialsoftware möglich Nein


Archivierung Nein

Tabelle 6-5: Webbasierte Kommunikation

6.2.6. Multizentrische klinische Studien über das Internet

Das Internet bietet sich an, wenn es um die dezentrale Eingabe der Ergebnisse vonklinischen Studien geht. Dazu wird in der MHH ein Server aufgestellt, der aus demInternet erreichbar ist und in den die Ergebnisse eingegeben werden. Die hier über-mittelten Daten sollen (trotz der Anonymisierung) nicht von Außenstehenden gelesenwerden können und unverändert in der MHH ankommen.

46


Art der Kommunikation Spezifisch, Standard

Kommunikationspartner M-P


Sensitivität hoch

Rechtliche Verbindlichkeit/Beweisbarkeit erwünscht, notwendig

Anpassung der Systeme möglich Ja, Nein



Archivierung Nein

Tabelle 6-6: Multizentrische klinische Studien über das Internet

6.2.7. Gesicherter interner Mailversand

Je mehr die Nutzung von E-Mail innerhalb der MHH ein normaler Bestandteil dertäglichen Arbeit wird, desto mehr wird auch der Bedarf zur Übermittlung von medi-zinischen Daten (Befunden, klinischen Werten oder Multimedia-Daten) wachsen.Daraus ergibt sich die Notwendigkeit, dass die Inhalte der Mails verschlüsselt undsigniert werden können.

Nach [MeKü2000a] und [MeKü2000b] ist der Einsatz von E-Mail zur Kommunika-tion über das Internet nur zulässig, wenn die Mails verschlüsselt werden. Da es keinegetrennten Mail-Systeme in der MHH für interne und externe Mails gibt (d.h. durchdas interne System wären nur Mitarbeiter der MHH und durch das externe wären nurexterne Adressen zu erreichen), ist das Risiko, versehentlich Mails mit Patienten-daten ohne Verschlüsselung in das Internet zu senden, zu groß.

Deshalb sollte grundsätzlich bei der Übermittlung medizinischer Daten (auch inner-halb der MHH) eine Verschlüsselung vorgenommen werden. Man könnte evtl. sogarsoweit gehen, dass grundsätzlich alle Mails verschlüsselt werden müssen und derVersand einer unverschlüsselten Mail grundsätzlich vom Absender bestätigt werdenmüsste, um das Risiko des versehentlich unverschlüsselten Versandes von Patienten-daten zu reduzieren.

Der Einsatz von Signaturen ist in all den Fällen vorzusehen, in denen aufgrund einerE-Mail Aktionen veranlasst werden oder auch deshalb unterbleiben, welche dieGesundheit des Patienten beeinträchtigen können. Wer wäre haftbar, wenn ein Arztdie Verabreichung eines wichtigen Medikamentes unterlässt, weil die per Mailübermittelten Laborwerte einen Übermittlungsfehler enthielten, der anstatt einespathologischen einen normalen Wert enthielt? Durch den Einsatz einer Signaturkönnten solche Übermittlungsfehler sicher erkannt werden.

47

Netz-Umgebung LAN




Sensitivität hoch

Rechtliche Verbindlichkeit/Beweisbarkeit notwendig




Archivierung Ja

Tabelle 6-7: Gesicherter interner Mailversand

6.2.8. Gesicherter externer Mailversand

Der Einsatz von Kryptographie beim Versand von Patientendaten über das Internetergibt sich zwingend aus [MeKü2000a]. Im Gegensatz zum internen Mailversandkommt beim externen Mailversand hinzu, dass die Sicherstellung der Authentizitätproblematischer ist und ohne eine Public Key Infrastructure (PKI), die nicht nur aufdie MHH beschränkt ist, praktisch nicht weiträumig durchgeführt werden kann.Ebenfalls kann es sich als problematisch erweisen, dass im Gegensatz zum internenMailversand beim externen Mailversand verschiedene Mail-Clients eingesetzt wer-den und zueinander nicht vollständig kompatibel sind.

48




Bekanntheit des Kommunikationspartner unbekannt

Sensitivität hoch

Rechtliche Verbindlichkeit/Beweisbarkeit: notwendig


Einsatz von Spezialsoftware möglich Nein


Archivierung Ja

Tabelle 6-8: Gesicherter externer Mailversand

49

7. Soll-Modell

7.1. Vorbemerkungen

In diesem Kapitel wird ein Modell entworfen, welches die im vorigen Kapitel vorge-stellten Kommunikationsprozesse kryptographisch sichert. Dieses Modell stellt inetwa das dar, was wünschenswert wäre – unabhängig davon, ob es in dieser Formbereits zu realisieren ist oder ob es aufgrund von Inkompatibilitäten der momentanverfügbaren Software noch nicht möglich ist. Eine eher praktikable Lösung, die auchfür einzelne Prozesse eine befriedigende Lösung bildet, wird im nächsten Kapitelvorgestellt.

Es wäre wünschenswert alle Kommunikationsprozesse in einen einheitlichen Rah-men zu integrieren. Dieser Rahmen könnte etwa folgendermaßen aussehen:

Alle an der Kommunikation beteiligten Personen und Systeme erhalten ein asymmet-risches Schlüsselpaar, welches durch eine CA zertifiziert wird. Die öffentlichenSchlüssel und Zertifikate liegen auf einem zentralen Server und können von allenBeteiligten (ggf. nach einer weiteren Authentisierung bei externen Anfragen) direktangerufen werden.

Vor jeder Kommunikation wird der betreffende aktuelle Verschlüsselungsschlüsseldes Kommunikationspartners heruntergeladen bzw. geprüft, ob das Zertifikat nochgültig ist und nicht zurückgerufen wurde (siehe Abbildung 7-2 (Modell derSchlüssel- und Datenübermittlung)). Die CA ist dazu in der Lage, Zertifikate für alleverwendeten Schlüsseltypen zu erstellen, sowohl für die Mailverschlüsselung, Web-Server- und Web-Client-Zerifikate als auch für andere Verfahren, die in denbeschriebenen Prozessen verwendet werden.

Die privaten Schlüssel werden auf einem Wechselmedium gehalten, sodass sie bei-spielsweise bei einem Diebstahl des Computers nicht mit entwendet werden. AlsWechselmedium könnte eine SmartCard dienen, welche beispielsweise in einem„intelligenten“ Kartenleseterminal steckt, in das der Benutzer eine PIN eingibt, umden Schlüssel freizugeben.

In [MüPf1997] schreibt Arndt Weber, dass bei dem Einsatz eines herkömmlichenComputers ein gewisses Restrisiko vorhanden ist, dass auf dem Computer einemanipulierte Software (beispielsweise durch einen unbemerkt eingespielten Troja-ner) den privaten Schlüssel kopiert oder die zu unterzeichnenden Daten manipuliert.Als Alternative schlägt er vor, sogenannte „sichere Geräte“ zu verwenden, diesowohl die Schlüssel des Anwenders enthalten als auch die Ver- bzw. Entschlüsse-lung und das Signieren selbst durchführen. Das hätte für den Anwender den Vorteil,dass er seinen Schlüssel sozusagen nicht „aus der Hand“ geben müsste, wenn er ein

50

Dokument signiert. Die Kommunikation mit dem stationären Computer könnte dannbeispielsweise per Kabel, Infrarot oder Funk (Bluetooth, Wireless LAN o.ä.) reali-siert werden. Es ist jedoch darauf zu achten, dass dadurch nicht neue Sicherheits-probleme entstehen.

Ein weiterer Vorteil dieser „sicheren Geräte“ wäre die Tatsache, dass sie deutlichweniger komplex sind als herkömmliche PCs. Auf ihnen würde nur die spezielleSoftware für kryptographische Anwendungen laufen. Dadurch wäre die Überprüfungauf ein korrektes Verhalten einfacher möglich. Ebenfalls könnte man in die Gerätezur Überprüfung der Identität des Nutzers biometrische Daten wie beispielsweiseeinen Fingerabdruck speichern anstatt den Schlüssel nur per Passwort oder PIN zusichern.

Bei der Verschlüsselung der Kommunikation muss auch zwischen einer Verschlüs-selung auf Netzwerk/Leitungsebene, die sowohl für die Anwendung als auch für denAnwender nicht sichtbar ist, und einer Verschlüsselung, die auf Anwendungsebeneabläuft, unterschieden werden, bei der sich beispielsweise ein Anwender durch einZertifikat der Anwendung gegenüber ausweisen kann. Es gibt hier auch mehrereZwischenstufen. Die im Laufe dieser Arbeit verwendeten sind in der folgendenTabelle dargestellt. So sind bei den hier betrachten Kommunikationsbeziehungen allebis auf die direkte Kommunikation zweier Applikationen Leitungsverschlüsselungen.

Anpassung der Applikation bedeutet, dass eine Anwendung speziell für die gesi-cherte Kommunikation angepasst werden muss.

Interaktion durch Anwender heißt, dass der Anwender sich beispielsweise speziellfür die Verschlüsselung anmelden muss.

Schlüssel des Anwenders gibt an, ob jeder Anwender einen persönlichen Schlüsselbesitzt oder ob ein Router, Firewall oder eine andere Netzwerkkomponente die Ver-schlüsselung für den Anwender transparent durchführt.

Art der Verschlüsselung gibt an, auf welcher Ebene die Verschlüsselung (im OSI –Open System Interconnection – Modell) abläuft.

51

Client Server Anpassungder Appli-

kation

Interaktiondurch

Anwender

Schlüsseldes

Anwenders

Art derVerschlüs-

selung

Applikation Applikation Ja Ja Ja Applikation

Client Server Nein Ja Ja Leitung

Client Router/Firewall

Nein Ja Ja Leitung

Router/Firewall

Router/Firewall

Nein Nein Nein Leitung

Tabelle 7-1: Arten der Verschlüsselung

In der folgenden Grafik wird eine erstrebenswerte Zielstruktur dargestellt. Die dazunotwendigen Tools werden detaillierter in Kapitel 7.2 (Tools zur Sicherung derKommunikation) anhand von Teilgrafiken beschrieben, in denen auch der Kommuni-kationsfluss zwischen den beteiligten Komponenten dargestellt wird.

52

Abbildung 7-1: Zielstruktur

Wenn die Kommunikation zwischen wenigen dedizierten Systemen (z.B. zwischenzwei Routern) stattfindet, ist zu überlegen, ob der Zusatzaufwand für das Einbindender CA sinnvoll ist oder ob in solchermaßen einfachen Fällen eine statische Authen-tisierung mit vorher vereinbarten Schlüsseln (Pre Shared Secrets) ausreichend ist.

Wenn eine asymmetrische Verschlüsselung genutzt wird, bedeutet dies in der Regel,dass eine hybride Verschlüsselung gewählt wird. Aufgrund der Leistungsfähigkeitder heutigen und zukünftigen Prozessoren wird im Folgenden nur der Einsatz einerstarken Verschlüsselung empfohlen. Das bedeutet bei einer symmetrischenVerschlüsselung mindestens 128 Bit Schlüssellänge und bei der asymmetrischenVerschlüsselung mindestens 1024 Bit Schlüssellänge. Es spricht jedoch nichts dage-gen, bei ausreichend vorhandener Rechenleistung für die symmetrische Verschlüs-

53

selung 192 bzw. 256 Bit und für die asymmetrische Verschlüsselung 2048 Bit zuverwenden.

In diesem Soll-Modell wird davon ausgegangen, dass alle beteiligten Komponenten(gegebenenfalls mit Ausnahme der Verschlüsselung der Festverbindung) Zugriff aufdie CA der MHH besitzen und sich so über neue bzw. für ungültig erklärte Schlüsselzeitnah informieren können. Im Folgenden werden der Initiator der Kommunikationals „Alice“, der Kommunikationspartner „Bob“ und die CA „Charlie“ genannt.

Der Ablauf der Kommunikation würde für alle Prozesse etwa folgendermaßen ablau-fen:

Abbildung 7-2: Modell der Schlüssel- und Datenübermittlung

1. Alice sendet (sofern vorhanden) den lokal gespeicherten Schlüssel von Bobbzw. einen „Fingerabdruck“ an die CA Charlie.

2. Charlie sendet als Antwort eine Bestätigung des Schlüssel, bzw. den neuenSchlüssel und informiert den Nutzer über den Grund des Schlüsselwechsels(z.B. Verlust des alten Schlüssels) an Alice.

3. Alice signiert mit dem eigenen Signier-Schlüssel (sofern gewünscht) die zuübermittelnden Daten.

4. Alice verschlüsselt die Daten mit Bobs öffentlichem Schlüssel.

5. Alice sendet die Daten an Bob.

6. Bob entschlüsselt mit seinem privaten Schlüssel die Nachricht.

7. Bob sendet (sofern vorhanden bzw. sofern gewünscht) den lokal gespeicher-ten Schlüssel (bzw. den Fingerabdruck) von Alice an Charlie.

8. Charlie sendet eine Bestätigung des Schlüssels bzw. den aktuellen Schlüsselan Bob.

9. Bob prüft die Echtheit von Alices Signatur.

54

Als Variante wäre es möglich, nicht bei jedem Kommunikationsvorgang den lokalgespeicherten Schlüssel bei der CA bestätigen zu lassen, sondern nur dann, wenn seitder letzten Kommunikation eine bestimmte Zeit vergangen ist (beispielsweise einTag, eine Woche), oder spätestens, wenn das Gültigkeitsdatum des Schlüssels oderdes Zertifikates abgelaufen ist.

Im Folgenden werden Vorschläge für den Einsatz kryptographischer Methoden fürverschiedene Arten der Kommunikation gegeben. Anschließend werden die im vori-gen Kapitel betrachteten Kommunikationsanwendungen gemäß den Vorschlägen ein-geordnet. Das Ziel ist es, ein Verfahren auswählen zu können, das die notwendigeSicherheit und Leistung bietet, ohne jedoch einen unnötigen Aufwand betreiben zumüssen.

Die folgende Tabelle gibt den Rahmen vor, bei welchen Eigenschaften der Kommu-nikationsprozesse der Einsatz welcher Verfahren (Verschlüsselung bzw. Signatur)angeraten ist. Aufbauend auf diesen Anforderungen werden dann die Tools vorge-stellt, welche die Prozesse absichern (in dem Feld Performance und Verschlüsselungbedeutet HW Verschlüsselung durch Hardware).

55

Gruppe Parameter Verschlüsselung Authenti-sierung /Signatur

SicherLAN Ja

C-LAN JaNetz-Umgebung

Internet Ja

nichtrelevant

SpezifischStandardArt der Kommunikation

Transparentnicht relevant

M-MM-PKommunikationspartnerP-P

nicht relevant

bekannt symmetrisch,asymmetrischBekanntheit

unbekannt asymmetrisch

nichtrelevant

geringmittel JaSensitivitäthoch Ja

nichtrelevant

irrelevanterwünscht Janotwendig JaVerbindlich-/ Beweisbarkeit

zwingend

nicht relevant

Ja

JaAnpassung Nein nicht relevant

irrelevant SoftwarePerformance relevant HW, symmetrischnicht

relevant

JaSpeicherung Nein nicht relevant

Tabelle 7-2: Auswahl kryptographischer Verfahren

Bei den Punkten Netz-Umgebung, Bekanntheit, Sensitivität, Verbindlich-/Beweis-barkeit und Performance gibt die Reihenfolge der Nennung der Parameter die Abstu-fung des Sicherheitsniveaus an. Hier gilt der Einsatz eines asymmetrischen (hybri-den) Verfahrens als „sicherer“ (da flexibler) als ein symmetrisches.

56

Wenn eine Anwendung in einem sicheren Netz läuft, weshalb dann im Allgemeinenvon Verschlüsselung abgesehen werden kann, jedoch die Sensitivität der Daten mit-tel oder hoch ist, sollte dennoch eine starke Verschlüsselung gewählt werden um dieAngriffsmöglichkeiten weiter zu reduzieren.

Ebenso muss bei einer Anwendung, bei der die Performance relevant ist (symmetri-sche Verschlüsselung), jedoch mit unbekannten Partnern (asymmetrisch) kommuni-ziert wird, eine asymmetrische (bzw. hybride) Verschlüsselung gewählt werden.

Werden die Daten archiviert, sind Vorkehrungen aus 4.5 (Schlüsselverlust) zu tref-fen, um im Falle eines Schlüsselverlustes weiterhin den Zugriff zu ermöglichen.

7.2. Tools zur Sicherung der Kommunikation

7.2.1. Router VPN

Abbildung 7-3: Router VPN (Ziel)

Bei dem Router VPN erfolgt die Verschlüsselung auf einer direktgeschalteten Lei-tung direkt durch die Router, welche die Authentizität des Kommunikationspartnersüber die von der CA ausgestellten Zertifikate überprüfen.

Durch diese Verbindung bilden die beiden Institutionen quasi ein Netzwerk. Es istjedoch möglich über ACLs die Rechte für Netzwerkzugriffe zu beschränken, aller-dings ist dies bei komplexeren Konfigurationen ohne den Einsatz eines vollwertigenFirewalls aufwendig.

Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authenti-sierung eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für dieAnwendung transparent.

57

7.2.2. Firewall-Firewall VPN-Tunnel

Abbildung 7-4: Firewall-Firewall VPN (Ziel)

Bei dem Firewall-Firewall-VPN-Tunnel wird die Kommunikation über das Internetvon den Firewalls gesichert, welche die Authentizität des jeweiligen Partners durchdie ausgestellten Zertifikate überprüfen können.

Durch die Firewalls können die beiderseitigen Zugriffe auf ein notwendiges Maßbeschränkt werden.


58

7.2.3. Anwender-Firewall VPN-Tunnel

Abbildung 7-5: Anwender-Firewall VPN (Ziel)

Der Anwender-Firewall-VPN-Tunnel ermöglicht es, Mitarbeitern der MHH transpa-rent auf das Netz der MHH zuzugreifen. Dabei ist es unerheblich, ob sie sich direktper ISDN oder Modem in einen RAS-Router in die MHH einwählen oder über einebereits bestehende Modem, ISDN oder DSL Verbindung über das Internet zugreifen.Bei einem VPN-Tunnel über das Internet ist zu beachten, dass der Client gegenZugriffe aus dem Internet geschützt werden muss, damit dadurch nicht ein Angriffs-punkt auf die MHH entsteht. Das ist beispielsweise durch den zusätzlichen Einsatzeines Personal-Firewall (Firewall-Software, die auf einem Client läuft und diesen vorAngriffen schützen soll) oder eine kombinierte IPSec-Software mit integriertem Per-sonal-Firewall möglich, die bei bestehendem VPN jegliche Kommunikation mit demInternet unterbindet.

Die Überprüfung der Authentizität des Anwenders kann durch die Überprüfung vonZertifikaten erfolgen, wobei der Client-Schlüssel auf einer SmartCard, einem USBFlash-ROM (ein Modul, dass an den Universal Serial Bus des Clients angeschlossenwird) oder der Festplatte gespeichert wird.

Es ist eine Interaktion durch den Anwender notwendig (er meldet sich am Firewallder MHH an), eine Authentisierung eines einzelnen Anwenders ist möglich und seineNetzwerkzugriffsberechtigungen in das Netz der MHH können auf Anwenderebenebeschränkt werden. Die Verschlüsselung erfolgt für die Anwendung transparent.

59

7.2.4. Direkter Tunnel zwischen Servern

Abbildung 7-6: Direkter Tunnel zwischen Servern (Ziel)

Bei dem direkten Tunnel zwischen Servern wird analog zu dem Firewall VPN einegesicherte Punkt-zu-Punkt-Verbindung aufgebaut. Im Gegensatz zu dem in 6.2.3(Internetverbindung zu einem anderen Krankenhaus) beschriebenen Tunnel wirddieser Tunnel direkt zwischen den beteiligten Servern aufgebaut und nicht vondahinterliegenden Netzwerkkomponenten. Das heißt, durch diesen Tunnel wird nureine Verbindung zwischen diesen Servern (ggf. auch nur eines speziellen Dienstes)gesichert und es werden keine Daten anderer Systeme getunnelt.

Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authenti-sierung eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für dieAnwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auchmöglich eine Authentisierung auf Anwenderebene durchzuführen, welche in demhier betrachteten Szenario nicht erwünscht ist.

60

7.2.5. Web-Server-Zertifikate

Abbildung 7-7: Web-Server-Zertifikate (Ziel)

Bei der Kommunikation mittels https ist es möglich, mittels eines Server-Zertifikates, welches auf den Namen des Servers ausgestellt wird, für den Anwendersicherzustellen, dass er den von ihm gewünschten Server erreicht hat und die Datennicht durch einen Man-in-the-Middle Angriff kompromittiert werden.

Es ist keine Interaktion durch den Anwender notwendig, eine Authentisierung eineseinzelnen Anwenders ist nicht möglich. Die Verschlüsselung erfolgt auf Anwen-dungsebene.

61

7.2.6. Web-Client-Zertifikate

Abbildung 7-8: Web-Client-Zertifikate (Ziel)

Um die Identität des Anwenders zu überprüfen, der auf einen Web-Server zugreift,ist es möglich, dem Anwender ein Zertifikat zu geben, durch das ihm der Zugriff aufgeschützte Web-Seiten ermöglicht wird. Es ist natürlich möglich, diese Client-Zerti-fikate mit den Server-Zertifikaten zu kombinieren.

Es ist eine Interaktion durch den Anwender notwendig, er meldet sich am Web-Server z.B. durch die Auswahl des zu verwendenden Zertifikates an und entsperrt esgegebenenfalls durch Angabe eines Passwortes, eine Authentisierung eines einzelnenAnwenders ist möglich und seine Zugriffsberechtigungen können innerhalb derAnwendungsebene beschränkt werden. Die Verschlüsselung erfolgt auf Anwen-dungsebene.

62

7.2.7. Datei-Verschlüsselungsprogramm

Abbildung 7-9: Datei-Verschlüsselungsprogramm (Ziel)

Die Daten werden ggf. signiert und verschlüsselt, um anschließend durch ein belie-biges Programm übertragen zu werden.

Es ist keine Interaktion durch einen Anwender notwendig, aber auch keine Authenti-sierung eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für dieAnwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auchmöglich, eine Authentisierung auf Anwenderebene durchzuführen, aber das ist indem hier betrachteten Szenario nicht erwünscht, da es hier um die automatisiertegesicherte Datenübertragung geht.

63

7.2.8. E-Mail Add-On

Abbildung 7-10: E-Mail Add-On (Ziel)

Bei der E-Mail-Verschlüsselung wird auf der Anwendungsebene die Verschlüsse-lung durchgeführt. In diesem Modell sind die notwendigen Funktionen zur Ver-schlüsselung in die E-Mail Anwendung integriert.

Die Mail kann vor dem Versenden durch den Anwender signiert und verschlüsseltwerden. Dann wird sie als gewöhnliche Mail dem Empfänger zugestellt, welcher sieentschlüsselt und (sofern vorhanden) die Signatur des Absenders überprüft. Die Mailkann dann sowohl verschlüsselt als auch unverschlüsselt archiviert werden.

Es ist eine Interaktion durch den Anwender notwendig (er muss seinen zertifiziertenSchlüssel auswählen und aktivieren), eine Authentisierung eines einzelnen Anwen-ders ist möglich. Die Verschlüsselung erfolgt auf Anwendungsebene.

64

7.3. Modellvorstellung

In der Modellvorstellung werden die vorgestellten Tools so kombiniert, dass sie dienotwendigen Anforderungen in den Prozessen umsetzen.


Verwendete Tools:7.2.7 (Datei-Verschlüsselungsprogramm)

7.2.4 (Direkter Tunnel)

Die Übermittlung der Daten könnte so, wie in Abbildung 7-2 (Modell der Schlüssel-und Datenübermittlung) dargestellt, erfolgen. Das Signieren und Verschlüsseln wirddabei durch eine spezielle Anwendung, welche die genannten Überprüfungen derSchlüssel durchführt, erfolgen. Als Übertragungsmethode kann dann ein beliebigesProgramm zur Datenübertragung eingesetzt werden.

Es wäre ebenfalls möglich die Daten nur zu signieren und sie ohne eine expliziteVerschlüsselung über einen durch entsprechende Software gesicherten Tunnel aufden anderen Computer zu übertragen. Dabei werden ebenfalls von der CA ausge-stellte Zertifikate verwendet.


Verwendetes Tool:7.2.1 (Router VPN)

Bei einer direktgeschalteten Leitung ist es ausreichend, wenn beidseitig auf denRoutern sichere symmetrische Schlüssel eingesetzt werden. Da es sich nur um sehrwenige Verbindungen handelt, ist es nicht unbedingt notwendig asymmetrischeSchlüssel und eine CA zu verwenden. Es spricht jedoch auch nichts dagegen. Dannist sicherzustellen, dass die Router periodisch die Gültigkeit des Zertifikates desjeweils anderen Routers überprüfen.


Verwendetes Tool:7.2.2 (Firewall-Firewall VPN-Tunnel)

Zur gesicherten Übertragung der Daten über das Internet sollte ein VPN aufgebautwerden. Es bietet sich an dieses VPN auf Standardprotokollen (IPSec) aufzubauen,um (relativ) unabhängig von den Herstellern zu sein. Am besten wird das VPN zwi-

65

schen den Firewalls auf beiden Seiten4 aufgebaut und nur die unbedingt notwendigenBerechtigungen eingetragen.

Durch das VPN wird sichergestellt, dass im Internet niemand die Daten mitlesenkann. Es wäre zwar ausreichend auch in diesem Fall mit symmetrischen Schlüsseln(und pre shared secrets) zu arbeiten, da jedoch der Aufwand zur Überprüfung derGültigkeit der Schlüssel mit zunehmender Anzahl der VPNs zunimmt und die Über-prüfung auf ungültig gewordene Schlüssel versehentlich unterbleiben kann, sollte dieAuthentisierung der Gegenstellen über eine beiderseitig bekannte CA erfolgen - ins-besondere, da davon auszugehen ist, dass nicht beide Firewalls von denselben Per-sonen administriert werden.

Der Einsatz weiterer Tools, um die Daten auch innerhalb der beiden Corporate LANszu sichern bzw. zu signieren, kann nun wie innerhalb eines Corporate LAN erfolgen.


Verwendetes Tool:7.2.3 (Anwender-Firewall VPN-Tunnel)

Die gesicherte Einwahl in das Netz der MHH kann analog zu dem Aufbau einesVPN zwischen MHH und einer anderen Klinik betrachtet werden, mit dem Unter-schied, dass die Client-IP-Adresse des Zugriffs in die MHH nicht fest ist. Es gibtdabei im Prinzip lediglich zusätzlich die Möglichkeit direkt per ISDN oder Modemauf einen RAS-Router zuzugreifen. Die Authentisierung der Clients könnte dannüber Zertifikate erfolgen, die beispielsweise auf einer SmartCard oder der lokalenFestplatte gespeichert und per Passwort geschützt sind. Ebenfalls wäre der Einsatzvon Einmalpassworten (z.B. SecurID) vorstellbar – siehe Abbildung 7-5 (Anwender-Firewall VPN (Ziel)).


Verwendete Tools:7.2.5 (Web-Server-Zertifikate)

7.2.6 (Web-Client-Zertifikate)

Die Kommunikation zwischen Web-Servern und Web-Clients kann sowohl im Inter-net als auch im Intranet durch den beiderseitigen Einsatz von Zertifikaten abgesichertwerden. Dadurch kann einerseits der Client sicherstellen, dass er mit dem richtigenServer verbunden ist (Server-Zertifikate), und auf der Seite des Servers ist es dann

4 Es ist davon auszugehen, dass jedes an das Internet angeschlossene Krankenhaus oder sonstigeEinrichtung des Gesundheitswesens über Firewalls gesichert ist. Eine Anbindung ohne Firewallswürde dermaßen große Risiken bergen, dass sie vermutlich als zumindest fahrlässig angesehenwerden kann.

66

möglich die Berechtigungen des Nutzers abhängig von dem Zertifikat (Client-Zerti-fikate) zu steuern.

Am besten wird das Client-Zertifikat auf einer SmartCard oder auf der Festplattegespeichert und mit einem Passwort geschützt. Es wäre ebenfalls erstrebenswert,wenn einzelne Dokumente zusätzlich mit einer Signatur versehen sind und so bei-spielsweise der Autor einer Anweisung zur Medikamentierung eindeutig identifiziertwerden kann.




7.2.3 (Anwender-Firewall VPN-Tunnel)

Die multizentrischen klinischen Studien können über ein Web-Interface gegebenen-falls mit einem Java Applet, welches Plausibilitätsprüfungen durchführt, auf einenWeb-Server in der MHH zugreifen. Dabei würden sich Web-Server und Web-Clientgegenseitig durch den Austausch von Zertifikaten identifizieren.

Da Zugriffe aus dem Internet in diesem Fall nur von einer überschaubaren Anzahlvon Personen kommen können, wäre es ebenfalls möglich – und sinnvoll - denZugriff auf den Web-Server an sich noch über eine weitere Sicherheitsstufe zusichern, um weniger Angriffspunkte zu bieten. Vor dem Aufbau der Web-Verbin-dung wäre ein Tunnel zu dem Firewall zu öffnen, durch den der Zugriff auf denWeb-Server erst ermöglicht würde. Dadurch wäre der Server auch für den Fallgeschützt, dass ein Konfigurationsfehler Zugriff auf die Daten freigeben würde, ohnedass der Client sich hinreichend authentifiziert hat.


Verwendetes Tool:7.2.8 (E-Mail Add-On)

Um eine möglichst reibungslose Nutzung von Signaturen und Verschlüsselung zuermöglichen, sollte das Mailprogramm die notwendige Funktionalität bzw. Schnitt-stellen für entsprechende Tools bereitstellen. In diesem Fall würde die Kommunika-tion ebenfalls wie in Abbildung 7-2 (Modell der Schlüssel- und Datenübermittlung)ablaufen. Der Anwender müsste lediglich die E-Mail-Adresse des Empfänger ange-ben und das E-Mail-Programm sucht automatisch den zugehörigen Schlüssel undüberprüft die Authentizität z.B. mittels eines CA-Zertifikates.

Aufgrund der in der MHH verarbeiteten Daten erscheint es sinnvoll, grundsätzlichalle Mails zu verschlüsseln und den Anwender zu warnen, falls bei einem Kommuni-kationspartner eine Verschlüsselung nicht möglich ist. Die umfassende Verschlüsse-

67

lung von Mails setzt ein funktionierendes Virenschutzkonzept voraus, welches aufdem Client eine Prüfung der übermittelten Daten auf Viren sicherstellt. Eine Prüfungauf einem zentralen Server ist dann nicht mehr möglich und ein Entschlüsseln derMails ist aufgrund der Tatsache, dass die ADKs nicht maschinell verfügbar sind,unmöglich.

Im Gegensatz zu den bisherigen Anwendungen erfolgt hier die Verschlüsselung nichtnur um die Übertragung zu sichern, sondern es ist auch davon auszugehen, dass dieMails verschlüsselt gespeichert bleiben. Deshalb könnte ein Schlüsselverlust denZugriff auf bereits gespeicherte Daten unterbinden. Es sollten daher entsprechendeMaßnahmen (z.B. ADK), wie in 4.5 (Schlüsselverlust) beschrieben, ergriffen wer-den. Da es sich hier um rein internen Mailverkehr handelt, ist es auch möglich dieNutzung von Mailprogrammen auf Programme zu beschränken, die den Anforderun-gen entsprechen.


Verwendetes Tool:7.2.8 (E-Mail Add-On)

Der gesicherte externe Mailversand wird analog zum gesicherten internen Mailver-sand aufgebaut. Da jedoch bei externen Empfängern nicht davon ausgegangen wer-den kann, dass eine Verschlüsselung möglich ist, kann darauf verzichtet werden,automatisch jede Mail zu verschlüsseln. Es sollte jedoch explizit darauf hingewiesenwerden, wenn eine unverschlüsselte Mail versendet werden soll.

Ein gesicherter externer Mailversand ist dem gesicherten internen Mailversand sehrähnlich. Nur kann es sich als problematisch erweisen, die in 4.5 (Schlüsselverlust)vorgeschlagene Maßnahme des ADK einzusetzen, wenn das Mailprogramm des Ab-senders (außerhalb der MHH) das nicht unterstützt.

Auch sollte die CA möglichst in eine Hierarchie eingebunden sein, um die Überprü-fung der in der MHH ausgestellten Zertifikate auch außerhalb überprüfbar zu halten.Die CA sollte dann natürlich auch von außen erreichbar sein, damit eine Onlineprü-fung der Zertifikate möglich ist.

68

8. Pragmatisches Modell

8.1. Allgemeine Überlegungen

Bisher ist ein ideales Modell, wie es im vorigen Kapitel vorgestellt wurde, nicht zurealisieren. Mit einigen Abstrichen im Komfort (vor allem bei der Schlüsselverwal-tung) und geringen Einbußen in der Funktionalität lässt sich aber bereits heutzutageein Modell umsetzen, das durch die Kombination von mehreren Standard-Produktenein relativ hohes Sicherheitsniveau erreicht und auch mit begrenzten finanziellenMitteln realisierbar ist.

Zur Zeit ist es beispielsweise so, dass für Web-Server- und Client-Zertifikate X.509eingesetzt wird, für die Verschlüsselung und Authentisierung von E-Mails oder ein-zelnen Dateien jedoch häufig PGP. Bei Direktverbindungen zwischen Routern sindhäufig symmetrische Verschlüsselungen im Einsatz, die ohne jedwede Signatur aus-kommen. Firewalls und einige Router können IPSec-konforme VPNs aufzubauen,welche neben der Authentisierung über pre shared Secrets auch eine Authentisierungüber Zertifikate bieten.

Durch diese Heterogenität werden teilweise für eine Person oder Institution mehrereverschiedene und untereinander inkompatible Schlüssel benötigt. Das hat zur Folge,dass evtl. auch mehrere Certificate Authorities (CAs) parallel für jedes eingesetzteProtokoll existieren müssen.

Im Folgenden wird versucht – wenn möglich – einen Public-Key-Algorithmus (bzw.ein hybrides Verfahren) zu verwenden, um bei einer Erweiterung der Anwendungkein Redesign des Prozesses durchführen zu müssen.

Die privaten Schlüssel sollten möglichst auf einem Wechselmedium und nicht aufeiner Festplatte gespeichert werden, damit nur der Besitzer auf den in der Regelzusätzlich per Passwort geschützten geheimen Schlüssel zugreifen kann. Als Spei-chermedium ist eine SmartCard denkbar. Da bisher nicht flächendeckend entspre-chende Kartenleser vorhanden und auch nicht alle Anwendungen damit kompatibelsind, wäre es evtl. möglich beispielsweise ein Flash-ROM an den USB-Port desComputers anzuschließen, das anwendungsseitig als normales Wechselmediumerkannt wird [CT2002-03]. Dadurch ist es zu allen gängigen Anwendungen kompati-bel, die den Schlüssel in einer frei wählbaren Datei speichern können. USB-Portssind heutzutage an allen aktuellen Computern zu finden und auch aktuelle Betriebs-systeme unterstützen diese Schnittstelle.

Wenn es lediglich darum geht, dass der Anwender sich gegenüber einem Serveridentifizieren kann, ist es auch möglich auf Generatoren für Einmalpasswortezurückzugreifen. Es wäre dann beispielsweise möglich, dass sich ein Anwender, der

69

sich über das Internet in die MHH einwählt, mittels einer PIN und einem durch eineSecurID Karte (von RSA) generierten Einmalpasswort als legitimer Benutzer aus-weist. Selbst wenn einmal jemand die PIN und das Einmalpasswort mitgelesen habensollte, ist es für einen Replay-Angriff nicht zu verwenden. Die Karte allein wäre fürden Finder ebenso nichts wert, da ihm dann noch die zugehörige PIN fehlt.

Die Schlüssel bekommen im Folgenden als Identifikationskriterium eine E-Mail-Adresse zugewiesen. Der besseren Übersicht halber verwende ich hier nur die Kurz-form @MHH. Bei einer Implementierung müsste selbstverständlich mit @MH-Hannover.DE gearbeitet werden.

Der Schlüssel des Trust-Centers der MHH lautet Trust.Center@MHH

Die folgende Grafik stellt einen Kompromiss aus der in Abbildung 7-1 (Zielstruktur)vorgestellten Struktur einerseits und den heute zur Verfügung stehenden Anwendun-gen andererseits dar. Die dazu notwendigen Tools werden detaillierter in 8.3 (Toolszur Sicherung der Kommunikation) anhand von Teilgrafiken beschrieben, in denenauch der Kommunikationsfluss zwischen den beteiligten Komponenten dargestelltwird.

70

Abbildung 8-1: Umzusetzende Struktur

Beim Einsatz der kommerziellen Version von PGP für Windows ist es möglich einenADK (siehe 4.5 (Schlüsselverlust)) für die Kommunikation zu erzwingen. Es istebenfalls möglich, einen Schlüssel so aufzuteilen, dass er nur durch das Zusammen-wirken mehrerer (z.B. 3 von 3 oder auch 3 von 5) verwendet werden kann. Dadurchkann ein Zugriff auf die hinterlegten Schlüssel ermöglicht werden.

71

8.2. Auswahl der CA-Software

Im Folgenden werden mehrere CAs zur Erstellung von Zertifikaten benötigt. Leidersind diese CAs untereinander nicht kompatibel, sodass es notwendig sein wird, dassein Anwender (eine Person oder auch ein Institut) teilweise mehrere Schlüssel erhält,die von verschiedenen CAs zertifiziert wurden. Weiterführende Hinweise zum Auf-bau von CAs im Allgemeinen finden sich in [CKLW2000] und speziell für eineX.509 CA mit OpenSSL in [DFN2000].

Benötigt werden die folgenden CAs:

PGP CA

Als CA-Software kann direkt PGP in einer der verschiedenen Versionen eingesetztwerden. Es empfiehlt sich eine Variante einzusetzen, die für den Betrieb als CAoptimiert wurde, damit beispielsweise zwischen Signatur und Verschlüsselungs-schlüsseln unterschieden werden kann. Da die Bedienung des zentralen Zertifikats-Servers nur durch speziell geschultes Personal erfolgt, ist es auch möglich Softwareeinzusetzen, die ohne graphische Benutzeroberfläche auskommt, dafür aber die not-wendigen Funktionen bietet.

Als Ergänzung der CA-Software wäre es auch möglich den PGP Certificate ServerFreeware (http://web.mit.edu/network/pgp.html) einzusetzen, der dann bei demAnwender als Zertifikats-Server eingetragen werden kann.

Es sind ebenfalls Programme erhältlich, welche eine Schnittstelle zwischen demAnwender und der CA bilden und es so ermöglichen, Zugriff auf die Zertifikate undzurückgerufenen Schlüssel zu erlangen. Die Abfrage kann dabei sowohl per Web-browser, Mail-Server als auch aus einem entsprechenden Client heraus erfolgen.

Die PGP-Zertifikate können für alle Anwendungen von PGP verwendet werden, alsosowohl für die Mailverschlüsselung als auch für die Übertragung von PGP-ver-schlüsselten Dateien. Es ist jedoch darauf zu achten, dass möglichst alle Programmemit den verschiedenen asymmetrischen und symmetrischen Algorithmen zurecht-kommen, die bei PGP verwendet werden.

X.509 CA

Für die X.509 CA kann beispielsweise OpenSSL verwendet werden, das diverseTools zur Verwaltung von X.509-Schlüsseln und Zertifikaten zur Verfügung stellt.Leider gibt es nur sehr wenige GUI-basierte Tools (beispielsweise die unter der GPLstehende IDX-PKI, http://idx-pki.idealx.org/). Da die Zertifikate bei X.509 deutlichkomplexer als die von PGP sind, wäre ein GUI vorteilhaft. Da die Bedienung - eben-falls wie bei der PGP CA – durch geschultes Personal erfolgt, ist dieser Nachteil zuverschmerzen.

Es sollte ein Web-Server mit einer Liste der zurückgerufenen Zertifikate existierenund diese Adresse in jedem Zertifikat gespeichert werden, damit ein Client onlineüberprüfen kann, ob ein Zertifikat möglicherweise zurückgerufen wurde. Dieser Ser-

72

ver oder ein Spiegel sollte auch aus dem Internet heraus erreichbar sein, damit dieEchtheitsüberprüfung auch von externen Clients aus durchgeführt werden kann.

Die X.509 Zertifikate können für die folgenden Anwendungen genutzt werden:

• Web-Server-Zertifikate

• Web-Client-Zertifikate

• VPN / Firewall Zertifikate

8.3. Tools zur Sicherung der Kommunikation

8.3.1. Router VPN

Abbildung 8-2: Router VPN

Das Router VPN bei einer geschalteten Festverbindung wird am einfachsten durchdie Installation eines pre shared Secrets auf beiden Endpunkten realisiert. Es ist aberauch (z.B. bei Cisco Routern) möglich Zertifikate zu nutzen.


73

8.3.2. Firewall-Firewall VPN-Tunnel

Abbildung 8-3: Firewall-Firewall VPN

Das Firewall-Firewall (IPSec) VPN wird jeweils zwischen zwei Firewalls aufgebaut,welche die Authentizität des jeweils anderen Firewalls durch die Überprüfung vonZertifikaten realisieren. In der Abbildung vertraut der Firewall der Partnerklinik derCA der MHH transitiv.

Wenn die Partnerklinik ebenfalls eine CA betreibt, kann sie den Firewall der MHHauch selbst zertifizieren. Anschließend können die Netze des jeweils anderen Kom-munikationspartners wie das eigene Campus-Netz genutzt werden. Es ist auch mög-lich und empfehlenswert dem Kommunikationspartner keinen Zugriff auf dasgesamte Netz einzuräumen, sondern nur die absolut notwendigen Zugriffe freizu-schalten. Dann kann (muss jedoch nicht) die Kommunikation ohne weitere Ver-schlüsselung genutzt werden.

Problematisch wird die Verbindung dann, wenn in beiden Campus-Netzen die selbenAdressbereiche verwendet werden. In den meisten Fällen ist es dann aber mittelsNetwork Address Translation (NAT) möglich, die Adresse für die Kommunikationentsprechend umzusetzen.


74

8.3.3. Anwender-Firewall VPN-Tunnel

Abbildung 8-4: Anwender-Firewall VPN

Der VPN-Tunnel wird zwischen dem Client und der MHH durch den Einsatz einesVPN-Clients ermöglicht. Dieser VPN-Client baut den VPN-Tunnel zwischen demClient und dem Firewalls auf (im Gegensatz zum vorigen Tool, welches ein VPNzwischen Firewalls bzw. Netzen aufbaut).

Im Gegensatz zum Anwender-Firewall VPN-Tunnel aus dem Soll-Modell kann hiernoch nicht von einer sicheren Authentisierung mittels CA und Smart-Cards ausge-gangen werden. Deshalb wird das Modell um eine starke Authentisierung mittelsRSA-SecurID-Karten erweitert. In diesem Fall gibt der Anwender als Passwort einePIN und eine (minütlich wechselnde) sechsstellige Zahl (das sogenannte Token) ein,welche er auf der SecurID Karte ablesen kann (das daraus entstehende Passwort wirdPasscode genannt). Es gibt auch Varianten der Karte, bei welcher der Anwenderseine PIN in die Karte eintippt und diese daraus den Passcode erzeugt, der danndirekt als Passwort verwendet werden kann. Der in der MHH stehende Server„weiß“, welche Karte zu welchem Zeitpunkt welche Zahlenkombination anzeigt undwelchem Benutzer sie mit welcher PIN zugeordnet ist. Wenn die übermittelten Datenkorrekt sind (insbesondere unter Beachtung des Zeitpunktes, denn die Token sind nuretwas mehr als eine Minute gültig), wird der Benutzer durch den Firewall als legiti-mierter anerkannt und kann mit dem Netz der MHH gesichert kommunizieren. DieSecurID-Karte kann im Übrigen auch noch als Mittel zur Authentisierung vonAnwendern bei der Anmeldung auf Server verwendet werden (beispielsweise für dieUnix-Anmeldung).

75

Wie in der Zielvorstellung bereits aufgeführt wurde, ist bei einer Verbindung überdas Internet der Client selbst noch vor Zugriffen aus dem Internet zu schützen. Dassollte durch den Einsatz des VPN-Clients mit Personal-Firewall-Funktionalitätanstatt eines reinen VPN-Clients realisiert werden. Dann kann der Administrator desMHH-Firewalls auch das Regelwerk auf dem Client vorgeben und so jegliche andereKommunikation mit dem Internet für die Zeitdauer, während derer der Tunnelbesteht, unterbinden.

Ein Vorschlag für einen in die Infrastruktur der MHH passenden VPN-Client findetsich im Anhang unter Auswahl des VPN-Clients.

Es ist eine Interaktion durch den Anwender notwendig (er meldet sich am Firewallder MHH an), eine Authentisierung eines einzelnen Anwenders ist möglich und seineNetzwerkzugriffsberechtigungen in das Netz der MHH können auf Anwenderebenebeschränkt werden. Die Verschlüsselung erfolgt für die Anwendung transparent.

8.3.4. Direkter Tunnel zwischen Servern

Abbildung 8-5: Direkter Tunnel zwischen Servern

Ein direkter Tunnel zwischen Servern lässt sich durch den Einsatz von OpenSSHaufbauen. Durch diesen können die Applikationen der beiden Computer ohne nen-nenswerte Änderungen kommunizieren. Die Authentisierung erfolgt durch dasdirekte Abspeichern der öffentlichen Schlüssels des jeweils anderen Servers ohneeine Interaktion durch den Anwender.

Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authenti-sierung eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für dieAnwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auchmöglich eine Authentisierung auf Anwenderebene durchzuführen, aber das ist in demhier betrachteten Szenario nicht erwünscht.

76

8.3.5. Web-Server-Zertifikate

Abbildung 8-6: Web-Server-Zertifikate

Die Server-Zertifikate können - wie in der Zielstruktur aufgezeigt - implementiertwerden.

77

8.3.6. Web-Client-Zertifikate

Abbildung 8-7: Web-Client-Zertifikate

Die Client-Zertifikate können - wie in der Zielstruktur aufgezeigt - implementiertwerden.

78

8.3.7. Datei-Verschlüsselungsprogramm

Abbildung 8-8: Datei-Verschlüsselungsprogramm

Als Programm zur Dateiverschlüsselung kann PGP eingesetzt werden. Da dieseKommunikationsbeziehung relativ statisch ist, ist ein direkter Austausch der Schlüs-sel (ggf. sogar ohne ein Zertifikat der MHH PGP CA) möglich. Das Modell derKommunikation würde also so, wie in Abbildung 7-2 (Modell der Schlüssel- undDatenübermittlung) beschrieben, erfolgen. Der Austausch und die Überprüfung derSchlüssel würden lediglich entfallen bzw. durch den Anwender vorgenommen.

Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authenti-sierung eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für dieAnwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auchmöglich eine Authentisierung auf Anwenderebene durchzuführen, aber das ist in demhier betrachteten Szenario nicht erwünscht.

79

8.3.8. E-Mail Add-On

Abbildung 8-9: E-Mail Add-On

Die E-Mail-Verschlüsselung und Signatur soll durch den Einsatz von PGP realisiertwerden. Anders ist zur Zeit eine preiswerte anwendungsübergreifende Public-Key-Kryptographie nicht praktikabel realisierbar. Außerdem ist PGP auch noch der de-facto-Standard für E-Mail-Verschlüsselung und für die Kommunikation mit externenPartnern notwendig. Die Deutsche Gesellschaft für Medizinische Informatik, Bio-metrie und Epidemiologie (GMDS e.V.) schreibt in einer „Stellungnahme zur klini-schen Nutzung von E-Mail“ [GMDS-EMail], dass PGP zur Verschlüsselung undSignatur eingesetzt werden kann.

Da keines der eingesetzten Programme von sich aus PGP nutzen kann, ist der Einsatzeines entsprechendem Add-On notwendig. Bei PGP für Windows ist im Standardlie-ferumfang bereits ein Modul zur Integration in Outlook vorhanden. Eine Integrationin Pegasus-Mail ist beispielsweise durch den Einsatz von QDPGP (http://www.community.wow.net/grt/qdpgp.html) oder PMPGP (http://www.pmpgp.de/) möglichund bei Netscape Mail (oder beliebigen anderen Mailprogrammen unter Windows)durch ein Ver- bzw. Entschlüsseln (bzw. Signieren) der Zwischenablage.

Diese Programme bieten leider nicht die gewünschten Funktionen, wie z.B. eineautomatische Warnung, wenn eine Mail unverschlüsselt gesendet werden soll.

Die Mail kann vor dem Versenden durch den Anwender signiert und verschlüsseltwerden. Dann wird sie als gewöhnliche Mail dem Empfänger zugestellt, welcher sieentschlüsselt und (sofern vorhanden) die Signatur des Absenders überprüft. Die Mailkann verschlüsselt gespeichert werden. Eine unverschlüsselte Speicherung ist abhän-gig von den verwendeten Tools und evtl. nicht möglich.

Es ist eine Interaktion durch den Anwender notwendig (er muss seinen zertifiziertenSchlüssel auswählen und aktivieren), eine Authentisierung eines einzelnen Anwen-ders ist möglich. Die Verschlüsselung erfolgt auf Anwendungsebene.

80

8.4. Umsetzung


Verwendete Tools:8.3.7 (Datei-Verschlüsselungsprogramm)

8.3.4 (Direkter Tunnel zwischen Servern)

Im Vorfeld werden die folgenden Schlüssel für eine automatische Datenübermittlunggeneriert und durch Trust.Center@MHH signiert:

Labor-Transfer@MHH

THG-Transfer@MHH

Es ließen sich natürlich auch die offiziellen Schlüssel der Institute verwenden. Dajedoch für den automatischen Betrieb die Passworte zum Entsperren der Schlüsselauf den an der Übertragung beteiligten Computern vorliegen müssen, empfiehlt sichhierfür die Verwendung eines eigenen Schlüssels.

Die Übertragung der Daten läuft folgendermaßen ab:

Labor: Signieren der zu übertragenden Daten mitLabor-Transfer@MHH

Labor: Verschlüsseln der (bereits signierten) Daten fürTHG-Transfer@MHH

Labor/THG: Übertragen der Daten per FTP auf den FTP-Server der THG(es ist natürlich auch möglich, dass die THG die Daten perFTP aus dem Labor abholt)

THG: Entschlüsseln der Daten mit THG-Transfer@MHHTHG: Überprüfen der Signatur auf Korrektheit mit

Labor-Transfer@MHH


Verwendete Tools:8.3.1 (Router VPN)

Solange keine CA installiert ist, die durch die Router direkt angesprochen werdenkann, ist es sinnvoll (da es sich hier um reine Punkt-zu-Punkt-Verbindungen handelt)auf beiden Routern mit einem sicheren und nicht erratbarem pre-shared-Secret zuarbeiten, sozusagen einem Passwort, das auf beiden Routern exklusiv für diese Ver-bindung eingetragen wird. Bei Cisco Routern, die z.B. auch in der MHH im Einsatzsind erfolgt der Austausch von Session-Keys selbstständig durch die Router. Bei

81

Cisco-Routern ist es beispielsweise auch möglich mit Zertifikaten zu arbeiten und soohne die pre-shared-Secrets auszukommen.

Da die MHH nur relativ wenige solcher Verbindungen haben wird, die auch vondenselben Administratoren verwaltet werden, würden andere Lösungen keinen signi-fikanten Vorteil bringen, jedoch die Komplexität erhöhen.


Verwendete Tools:8.3.2 (Firewall-Firewall VPN-Tunnel)

Solange die Anzahl der VPNs zwischen der MHH und anderen Institutionen relativgering ist, bietet es sich an auch hier mit (keinesfalls erratbaren) pre-shared-Secretszu arbeiten oder bereits ohne den Einsatz von CAs mit innerhalb der VPN Softwaregenerierten Zertifikaten zu arbeiten. Im Gegensatz zu der direktgeschalteten Verbin-dung ist die Geheimhaltung dieser identifizierenden Daten essentiell, da – im Gegen-satz zu der direktgeschalteten Leitung – beliebige Angreifer ohne nennenswertenAufwand über das Internet eine Verbindung aufbauen können.

Der Aufbau des VPN sollte mittels IPSec über den bereits in der MHH im Einsatzbefindlichen Firewall laufen.


Verwendete Tools:8.3.3 (Anwender-Firewall VPN-Tunnel)

Im Folgenden wird davon ausgegangen, dass der Weg des Verbindungsaufbaus zurMHH für den weiteren Weg in die MHH nicht relevant ist. Bei der direkten Einwahlvia Modem oder ISDN würde diese auf einen Access-Router gehen, der an ein spe-zielles Segment des (Internet-) Firewall angebunden ist. Es wird in jedem Fall einverschlüsselter Tunnel von dem Computer des Anwenders zu dem Firewall aufge-baut.

Um auch nur Berechtigten den Zugriff zu ermöglichen muss sich der Anwender beimAufbau des Tunnels dem Firewall gegenüber authentisieren. Als Software auf Client-seite empfiehlt sich hier der zum Firewall gehörende VPN-Client (siehe im AnhangAuswahl des VPN-Clients).

Sollte der Zugriff aus dem Internet heraus erfolgen, ist darauf zu achten, dass derClient nicht ungeschützt im Internet steht und so als Brückenkopf missbraucht wer-den kann, durch den Dritte in die MHH eindringen. Dazu sollte noch ein Personal-Firewall eingesetzt werden, der den Client selbst schützt (siehe im Anhang Auswahldes VPN-Clients).

82

Diese Authentisierung sollte keinesfalls mit statischen Passworten geschehen. Statt-dessen sollten Zertifikate, die beispielsweise auf einer Smart Card gespeichert sind,verwendet werden. Alternativ können auch Einmalpassworte verwendet werden. Daeine Liste mit Einmalpassworten nicht komfortabel handhabbar ist, würde es sich fürdiese Anwendung empfehlen einen Einmalpasswortgenerator wie z.B. SecurID-Kar-ten von RSA einzusetzen, die jede Minute eine neue sechsstellige Zahl anzeigen, diezusammen mit einer PIN für einen kurzen Zeitraum die Authentisierung ermöglicht.

Die Einmalpassworte könnten auch anstatt einfacher Passworte für den Zugriff aufComputer innerhalb der MHH (Unix oder Windows NT/2000) verwendet werden.




Der Einsatz der Client- und Server-Zertifikate ist bereits wie in der Zielvorstellungbeschrieben möglich. Es ist teilweise jedoch notwendig, entweder die Server-Zertifi-kate manuell im Web-Client zu installieren oder die CA der MHH als vertrauens-würdig zu klassifizieren, wodurch automatisch alle von ihr ausgestellten Zertifikateakzeptiert werden. Letzteres ist auf jeden Fall bei den Clients innerhalb der MHHdurchzuführen. Es sollte jedoch die Option, dass eine Onlineprüfung der Zertifikateerfolgt, aktiviert sein.

Client-Zertifikate können dann zur Steuerung der Berechtigungen bei Zugriffeninnerhalb der Web-Server eingesetzt werden, sodass beispielweise auch über dasInternet hinweg auf interne Daten zugegriffen werden kann.




8.3.3 (Anwender-Firewall VPN-Tunnel)

Für die multizentrischen klinischen Studien können die Methoden zur Sicherung derwebbasierten Kommunikation aus 8.4.5 (Webbasierte Kommunikation) eingesetztwerden. Es ist auch noch möglich als weitere Sicherheitsstufe (um den Server selbstzu schützen) einen Tunnel zwischen dem Studienclient und dem Firewall der MHHaufzubauen und nur für den jetzt bereits am Firewall authentisierten Anwender denZugriff auf den Studienserver freizuschalten. Dazu können die Methoden der gesi-cherten Einwahl aus 8.4.4 (Gesicherte Einwahl über ISDN, Modem oder Internet)genutzt werden, wobei der spezielle Anwender jedoch nur auf den StudienserverZugriff erhält.

83


Verwendetes Tool:

8.3.8 (E-Mail Add-On)

Der gesicherte interne Mailversand lässt sich zu einem großen Teil (was die Qualitätder Sicherung angeht) bereits so wie im Soll-Modell vorgeschlagen realisieren. Esgibt jedoch relativ große Komforteinbußen, da die Kryptographie nur durch den Ein-satz von Zusatzprogrammen auf die E-Mail-Programme aufgesetzt wird und nochkein integraler Bestandteil ist. Es sind beispielsweise keine Funktionen vorhanden,um eine verschlüsselt empfangene Mail unverschlüsselt zu speichern, also nur dieÜbertragung zu schützen.

Ebenso wird die Option, einer automatischen Verschlüsselung aller abgehendenMails mit einer Warnung, wenn eine unverschlüsselte Mail versandt werden soll, bis-her nicht unterstützt. Dadurch besteht ein gewisses Restrisiko, dass ein Anwender indem Glauben, eine verschlüsselte Mail zu senden, versehentlich sensible Datenunverschlüsselt sendet.

Durch die Technik ist es bisher kaum möglich dies zu unterbinden. Deshalb müssendie Anwender regelmäßig darüber informiert werden, dass sie selbst die Vertraulich-keit der übermittelten Daten sicherstellen müssen.


Verwendetes Tool:

8.3.8 (E-Mail Add-On)

Bei dem gesicherten externen Mailversand gilt das bereits zum gesicherten internenMailversand Gesagte. Es kommt allerdings hinzu, dass die Clients außerhalb derMHH mit nicht kontrollierbarer Software im Einsatz sind und es so zu Kompatibili-tätsproblemen mit Kommunikationspartnern in der MHH kommen kann. Es gibt bei-spielsweise verschiedene Versionen von PGP, die nur RSA und IDEA (die Versio-nen 2.x) beherrschen und nicht mit den Diffie-Hellmann-Schlüsseln der neueren Ver-sionen zurechtkommen. Auch gestaltet sich die Verteilung der Schlüssel im Ver-gleich zur MHH schwierig, da es kein zentrales Verzeichnis aller PGP-Schlüsselgibt.

Genauso, wie bei dem internen Mailversand existiert ein gewisses Restrisiko verseh-entlich eine Mail mit sensiblen Daten über das Internet zu versenden.

Dieses Problem ist technisch gesehen bisher kaum abzusichern. Es ist daher notwen-dig die Anwender regelmäßig darauf hinzuweisen, dass sie selbst dafür verantwort-lich sind die Vertraulichkeit der Übertragung sicherzustellen (siehe 3 (RechtlicherRahmen der Kryptographie in Deutschland)).

84

9. Zusammenfassung

„We can only see a short distance ahead, butwe can see plenty there that needs to be done."

[Alan Turing, 1953]

Diese Arbeit hat die Anforderungen an die Übermittlung und Speicherung medizini-scher Daten aufgrund der aktuellen Gesetzeslage und der standesrechtlichen Bestim-mungen beleuchtet.

Anschließend wurde die rechtliche Lage der Signatur und Verschlüsselung inDeutschland betrachtet, um dann auf Basis der Anforderungen und des gesetzlichenRahmens die Einsatzmöglichkeiten der verschiedenen kryptographischen Verfahrenzu erläutern.

Nach Erläuterung der Grundlagen wurden typische Kommunikationsprozesse ausdem Alltag der MHH analysiert und die zur Verfügung stehende Infrastrukturvorgestellt. Aufgrund dieser Analyse wurde dann ein Soll-Modell erarbeitet, das dieProzesse im Rahmen der vorgegebenen Anforderungen sichern soll. In diesem Soll-Modell wurde keine Rücksicht darauf genommen, ob dieses Modell bereitsvollständig umgesetzt werden kann. Es wurden aber primär Methoden vorgeschla-gen, von denen anzunehmen ist, dass sie in den nächsten Jahren zur Verfügung ste-hen werden.

Danach wurde ein Modell vorgestellt, das eine ähnliche Sicherheit wie das Soll-Modell bietet, jedoch bereits jetzt umgesetzt werden kann – insbesondere unterBeachtung der knappen finanziellen Mittel eines Krankenhauses. Die Realisierbar-keit wurde durch den Verzicht auf eine einheitliche Umgebung und durch den Ein-satz verschiedener Tools und Strukturen ermöglicht (beispielsweise der Einsatzzweier getrennter CAs anstatt nur einer einzigen). Es wurde dabei darauf geachtet,dass die verwendeten Methoden so einfach wie möglich, aber auch so sicher wienötig sind, damit die Sicherheit nicht durch Fehler bei der Umsetzung einer hoch-komplexen und theoretisch sicheren Kryptographieinfrastruktur zunichte gemachtwird. Smith schreibt in [Smi1998]: „Beim Codeknacken wird entweder die Chiff-rierung selbst oder aber die Art ihres Einsatzes angegriffen. Gemessen an der Stärkemoderner Chiffrierungen besteht heute die eigentliche Gefahr eher in der Art undWeise, wie die Chiffrierungen eingesetzt werden.“

Als Ergebnis kann festgehalten werden, dass bereits heute viele Kommunikations-prozesse gesichert werden können. Allerdings ist dazu der Einsatz vieler Tools not-wendig, die zum Teil nicht miteinander kommunizieren und so für den Anwenderteilweise unbequem sein können. Es ist ebenfalls noch viel Arbeit zu leisten, um bei-spielsweise sicherzustellen, dass auf verschlüsselt gespeicherte Daten auch nach dem

85

Verlust des Schlüssels zugegriffen werden kann. Auch ist es notwendig von Zeit zuZeit zu überprüfen, ob die verwendeten Methoden und deren Einsatz durch dieAnwender noch den möglicherweise geänderten Rahmenbedingungen entsprechenund sind dann gegebenenfalls anzupassen.

Ein potenzielles und nicht zu unterschätzendes Sicherheitsrisiko stellen Clients dar,die nicht unter der Kontrolle der MHH stehen und sowohl Verbindungen in dasInternet unterhalten als auch gleichzeitig einen VPN Tunnel direkt per RAS oderüber das Internet in die MHH aufbauen. In diesem Fall könnten ein Trojaner oder einVirus ungeschützt auf Ressourcen der MHH zugreifen, beispielsweise Dateien überdas Internet an den Autor des Trojaners senden oder Dateien auf Netzwerklaufwer-ken mit Viren verseuchen.

Ein weiteres Sicherheitsrisiko kann durch den Einsatz intelligenter Trojaner entste-hen, die während einer bestehenden getunnelten Verbindung Daten in der MHHsammeln und diese nach Terminierung des Tunnels direkt in das Internet senden.Dieses Problem besteht aber auch bei den Clients im Netz der MHH, wobei in die-sem Fall die Übermittlung der Daten in das Internet etwas problematischer ist.

Der Faktor „Mensch“ ist grundsätzlich in die Einführung einzubeziehen, um dieAkzeptanz zu erhöhen. Die Anwendung der Kryptographie sollte für den Anwenderso einfach wie möglich gestaltet werden. Es muss sich in der Praxis zeigen, wie derzusätzliche Aufwand bei den Anwendern aufgenommen wird. Wenn die Akzeptanzgering ist, ist nicht auszuschließen, dass die Anwender Möglichkeiten suchen, sichdas Leben bequemer zu machen – selbst mit dem Risiko, dass dadurch die Sicherheitdrastisch sinkt.

Um dieser Gefahr entgegenzuwirken sind Anwenderschulungen notwendig, in denenfür die Anwender deutlich gemacht wird, weshalb dieser Aufwand betrieben wirdund was möglicherweise die Konsequenzen sind, wenn diese Maßnahmen ausgehe-belt werden. Wenn ein Verständnis für die Probleme vorhanden ist, sind sie sicher-lich auch bereit, gewisse Komforteinbußen in Kauf zu nehmen. Das Abschließen vonTüren ist auch unbequem – trotzdem wird sicherlich jeder seine Wohnung beiVerlassen abschließen. Der Einsatz von Kryptographie darf unbequem sein, denAnwender allerdings nicht in seiner Arbeit behindern!

86

Anhang

Bedrohungen in der MHH

Aufgrund der offenen Struktur der MHH als Hochschule ist es relativ leicht möglich,physischen Zugang in weite Teile der Gebäude zu erhalten und von dort Zugriff aufdas LAN zu haben. Ein weiteres Risiko besteht darin, dass es weder auf Client- nochauf Server-Seite eine Trennung der Netze für Klinik, Verwaltung und Forschung gibt(durch dedizierte Hardware oder VLANs) und so durch einfache Zugriffbeschrän-kungen auf Routern oder Firewalls der Zugriff von einem Forschungsarbeitsplatz aufeinen Verwaltungsserver unterbunden werden könnte.

Ebenfalls gibt es bereits verschiedene Tools, welche den durch Switches existieren-den Schutz vor dem Mitlesen aushebeln und so die Bedrohung vergrößern.

Die Bedrohung durch die genannten Angriffe ist vermutlich als relativ gering einzu-stufen (mit Ausnahme der Insider). Da es jedoch um sehr sensible Daten geht, derenbekannt werden das Leben der Betroffenen massiv beeinträchtigen kann (z.B. kön-nen sich Informationen über Aufenthalte in Psychiatrischen Kliniken auf die Karrieredes Betroffenen katastrophal auswirken), sind Schutzmaßnahmen unumgänglich.

Netzwerk-Infrastruktur des Campus-LAN

Die MHH hat ein durch das Medizinische Hochschulrechenzentrum (MHRZ) betrie-benes campusweites geswitchtes Fast-Ethernet-Netzwerk (100 MBit Ethernet), indem primär TCP/IP (das Kommunikationsprotokoll, auf dem zur Zeit die meisteNetzkommunikation erfolgt und das auch im Internet verwendet wird), aber auchnoch teilweise IPX/SPX (Kommunikationsprotokoll, das von der Firma Novell undeinigen anderen eingesetzt wurde) eingesetzt werden. Es bestehen weiterhin Verbin-dungen zu einigen Außenstellen über direktgeschaltete Datenverbindungen, aufdenen ausschließlich TCP/IP eingesetzt wird.

Zusätzlich hat die MHH eine durch einen CheckPoint Firewall-1 gesicherte Infra-struktur Verbindung zum G-WIN des DFN-Vereins („Verein zur Förderung einesdeutschen Forschungsnetzes“) und damit eine Verbindung zum Internet.

Der Aufbau von dezentralen ISDN- oder Modem-Einwahlpunkten durch einzelneAbteilungen ist nicht gestattet.

Server- und Client-Infrastruktur des Campus-LAN

In der MHH wird als Clientbetriebssystem fast durchgängig Windows NT, vereinzeltauch Windows 2000, verwendet. Die Server laufen zum größten Teil unter Solaris

87

auf SUN SPARC Hardware bzw. unter Windows NT/2000 oder Linux auf StandardPC Hardware. Es kann davon ausgegangen werden, dass alle Systeme (sowohl Ser-ver als auch Client) per TCP/IP erreichbar sind.

Es existiert ein zentraler unter Unix laufender Mail-Server, über den alle Mails, wel-che die MHH verlassen, gesendet werden. Auf diesem ist ein Verzeichnis aller in derMHH verwendeten offiziellen Adressen vorhanden. Als Mailprogramm auf Seitender Benutzer wird zu einem großen Teil Pegasus-Mail verwendet. Teilweise sindaber auch Netscape Mail oder Outlook im Einsatz.

Auswahl des VPN-Clients

Als VPN-Client kann das zum bereits eingesetzten Checkpoint Firewall-1 gehörendeund zur Zeit kostenlose SecuRemote verwendet werden. Wenn die Personal-Fire-wall-Funktionalität gewünscht wird, kann der kostenpflichtige SecureClient einge-setzt werden.

88

Literaturverzeichnis

[Ber1996] Bernauer, J., „Medizinische Dokumentation – TerminologischeGrundlagen“, Universität Hildesheim, Skripten des FachbereichsMathematik, Informatik, Naturwissenschaften, 1996

[Blö2001] Blömer, J., Vorlesung „Angewandte Aspekte der Kryptogra-phie“, Universität Paderborn 2001

[BlPo1997] Blobel, B., Pommerening, K., „Datenschutz und Datensicherheitin Informationssystemen des Gesundheitswesens”, f&w 2/97,133-138, http://MZ98.IMSD.Uni-Mainz.DE/AGDatenschutz/Empfehlungen/fuw.htm

[CKLW2000] Camphausen, I., Kelm, S., Liedtke, B., Weber, L., „Aufbau undBetrieb einer Zertifizierungsinstanz“, DFN-PCA, 2000

[CT2002-03] „Transcend bietet USB-Speichermedien mit bis zu 512 MBytean“, c´t 3/2002, S. 27

[DÄT1997] Deutscher Ärzte Tag, „Auszug aus der (Muster-) Berufsordnungfür die deutschen Ärztinnen und Ärzte“, Beschlüsse des 100.Deutschen Ärztetages in Eisenach, http://WWW.MediSec.DE/text/mbo97.htm

[DaRi1999] Daemen, J., Rijmen, V., „AES Proposal: Rijndael“, 1999

[DFN2000] „Das OpenSSL Handbuch“, DFN-PCA, 2000

[FiGr2001] Fischer, V. G., Grossmann, V., „Abgehorcht – Public-Key-Infrastrukturen im Gesundheitswesen“, iX 9/2001, S. 52ff.

[GMDS-EMail] Deutsche Gesellschaft für Medizinische Informatik, Biometrieund Epidemiologie GMDS e.V., „Stellungnahme zur KlinischenNutzung von E-Mail“, http://WWW.Med.Uni-Muenchen.DE/ibe/internet/em_email.htm

[HePa1996] Hennessy, J. L., Patterson, D. A., „Computer Architecture - AQuantitative Approch“, Morgan Kaufmann Publishers Inc., SanFransisco, 1996

[IBM2001] IBM Server Group, „POWER4 System Microarchitecture“,http://www-1.ibm.com/servers/eserver/pseries/hardware/whitepapers/power4.pdf, Oktober 2001

89

[IBMT2000] Fraunhofer Institut für Biomedizinische Technik, ArbeitsgruppeMedizin-Telematik, „PaDok – Patientenbegleitende Dokumen-tation“, http://www.ibmt.fhg.de/, 2000

[iX2002-03] Schmidt, K., „IBMs ‚Regatta’ als Number Cruncher“, iX3/2002, S. 52ff

[Jac1996] Jacob, J., „Datenschutz – ärztliche Schweigepflicht –Telekommunikation“, http://Gauss.Med.Uni-Bonn.DE/datenschutz/bfd.htm

[Kre2000] Krempel, S., „Von Lucifer zu Rijndael“, Telepolis,http://www.heise.de/tp/deutsch/inhalt/te/8848/1.html

[KVB1999] Kassenärztliche Vereinigung Bayern, „Leitlinien für den E-Mail-Versand im Gesundheitswesen“, Landesrundschreiben1/1999, http://WWW.KVB.DE/mitteil/lrs991a2.htm

[LANL2001] „Das neue Signaturgesetz“, LANline Spezial „Das sichereNetz“, III/2001, S. 24ff

[Lös1999] Löser, M., „Untersuchung zur Einrichtung von Echtzeitsignalenmit variabler Bitrate über ATM-Netze (STM-4) am Beispiel vonverlustfrei codierten TV-Studiosignalen (SDI) unter Einsatz ei-ner geeigneten ATM-Adaptionsschicht (z.B. AAL5 und/oderAALx)“, Diplomarbeit an der TU Ilmenau, 1999

[Mal2001] Malakas, K., „Heilige Kuh – Gesetz zur elektronischen Signa-tur“, c´t 7/2001, S. 47

[MDJP1998] Matthies, H. K., Dietzel, G. T. W., Jan, U. von, Poschadel, F.,Porth, A. J., „Sicherheit in Informationssystemen: Informations-sicherheit in medizinischen Netzen“, vdf Zürich, 1998

[MeKü2000a] Menzel, U., Kühn, U., „Stellungnahme des HamburgischenDatenschutzbeauftragten“, http://WWW.MediSec.DE/text/20000215DaSchutzHH.htm

[MeKü2000b] Menzel, U., Kühn, U., „Datenschutz und elektronisch vernetztePatientendaten“, Vorabveröffentlichung aus dem HamburgerÄrzteblatt 2000, http://WWW.MediSec.DE/text/DaSchuHH.htm

[Mül2001] Müller, A., Vorlesung „Mathematische Grundlagen der Krypto-graphie“, HSR, 2001

[MüPf1997] Müller, G., Pfitzmann, A., „Mehrseitige Sicherheit in der Kom-munikationstechnik“, Addison-Wesley, 1997

90

[MPWJ1998a] Matthies, H. K., Poschadel, F., Wübbelt, P., v. Jan, U., Porth, A.J., „Kryptographisch gesicherte Kommunikation und Datener-fassung für multizentrische klinische Studien mit Web-Techno-logien“, GMDS, 1998

[MPWJ1998b] Matthies, H. K., Poschadel, F., Wübbelt, P., v. Jan, U., Porth, A.J., „Prague Stochastics '98: Cryptographically Secured Commu-nication and Data Acquisition for Multi-Centric Clinical StudiesUsing Web Technologies“, JCMF Prag, 1998

[NiSc2001] Niesing, M., Schmeh, K., „Schlüssel des Vertrauens – DigitaleAusweise im Internet“, c´t 7/2001, S. 224ff

[Sav2001] Savard, J., „A Cryptographic Compendium - The AdvancedEncryption Standard (Rijndael)“, http://home.ecn.ab.ca/~jsavard/crypto/co040801.htm, 2001

[SchB1996] Schneier, B., „Angewandte Kryptographie“, Addison-Wesley,1996

[SchB2001] Schneier, B., „Secrets & Lies“, dpunkt.verlag, 2001

[SchC2001] Schulzki-Haddouti, C., „Preisfrage – Neues Signaturgesetz abAnfang Mai“, iX 4/2001, S.48f

[Smi1998] Smith, R. E., „Internet Kryptographie“, Addison-Wesley, 1998

[StGb203] Strafgesetzbuch, §203

[Wät2000] Wätjen, D., Vorlesung „Kryptologie“, Technische UniversitätBraunschweig 2000

Danksagung

„Gut Ding will Weile haben!“

Mein Dank gilt besonders Herrn Prof. Dr. Dietmar Wätjen von der TechnischenUniversität Braunschweig und Herrn Prof. Dr. Herbert K. Matthies von der Medizi-nischen Hochschule Hannover für die Möglichkeit diese Diplomarbeit bei ihnenanfertigen zu können und die Unterstützung bei der Erstellung dieser Arbeit.

Ebenfalls gilt mein Dank meinen Eltern Rosa und Emil, die nicht lockergelassenhaben, dass ich endlich meine Diplomarbeit schreibe.

Norbert dafür, mir manch mathematische Frage beantwortet und sich damit abge-funden zu haben, dass die Mathematik mich nicht sehr interessiert.

Für die fachliche Unterstützung und Anregungen danke ich Ute und Nico.

Für die Suche nach den ganzen Rächtschraipfeelern danke ich Renate, Ralf undSiegfried.

Meinem Chef Achim für das Verständnis und sowohl inhaltliche, als auch formelleRatschläge.

Ohne die „Moralische Unterstützung“ und Rücksichtnahme durch Corinna, Jörg,Kathrin, Kay und alle die mich sonst so kennen, wäre es wohl eine unendlicheGeschichte geworden.

Zum Schluss möchte ich mich bei allen bedanken, die das Internet zu einer Fund-grube gemacht haben, die auf viele Fragen eine passende Antwort (nicht nur 42!)liefert.

Documents

Einsatzmöglichkeiten kryptographischer Methoden zur ... · Eidesstattliche Versicherung Die selbstständige und eigenhändige Anfertigung versichere ich an Eides statt. Ich habe