Einsatzmöglichkeiten kryptographischer Methoden zur Signatur und ...

Diplomarbeit
Einsatzmöglichkeiten
kryptographischer Methoden zur
Signatur und Verschlüsselung im
Krankenhaus
Friedhelm Poschadel
Matrikel 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 Eides
statt.
Ich habe alle benutzten Quellen angegeben und sämtliche Entlehnungen
aus anderen Arbeiten kenntlich gemacht.
Hannover, den
____________________________________________
(Friedhelm Poschadel)

Inhalt
Abbildungsverzeichnis................................................................................................. IV
Tabellenverzeichnis........................................................................................................V
Glossar........................................................................................................................... VI
1. Einleitung.................................................................................................................1
2. Anforderungen an die Übermittlung und Speicherung von medizinischen
Daten.........................................................................................................................3
3. Rechtlicher Rahmen der Kryptographie in Deutschland....................................6
4. Einsatzmöglichkeiten kryptographischer Verfahren im Krankenhaus.............8
4.1. Verschlüsselungsverfahren ...................................................................................8
4.1.1. Symmetrische Verschlüsselung ................................................................8
4.1.2. Asymmetrische Verschlüsselung ............................................................10
4.1.3. Hybride Verschlüsselung ........................................................................11
4.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......................................................................................22
5.1. Mathematische Grundlagen ................................................................................22
5.2. Die Algorithmen im Detail..................................................................................27
5.2.1. Rijndael - AES ........................................................................................27
5.2.2. RSA.........................................................................................................33
6. Ausgewählte Kommunikationsprozesse..............................................................37
6.1. Struktur der Betrachtung.....................................................................................37
6.2. Kommunikationsprozesse ...................................................................................41
6.2.1. Datenübermittlung zwischen Instituten...................................................41
6.2.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................42
I

6.2.3. Internetverbindung zu einem anderen Krankenhaus...............................43
6.2.4. Gesicherte Einwahl über ISDN, Modem oder Internet...........................44
6.2.5. Webbasierte Kommunikation..................................................................44
6.2.6. Multizentrische klinische Studien über das Internet ...............................45
6.2.7. Gesicherter interner Mailversand............................................................46
6.2.8. Gesicherter externer Mailversand ...........................................................47
7. Soll-Modell.............................................................................................................49
7.1. Vorbemerkungen.................................................................................................49
7.2. Tools zur Sicherung der Kommunikation...........................................................56
7.2.1. Router VPN.............................................................................................56
7.2.2. Firewall-Firewall VPN-Tunnel ...............................................................57
7.2.3. Anwender-Firewall VPN-Tunnel............................................................58
7.2.4. Direkter Tunnel zwischen Servern..........................................................59
7.2.5. Web-Server-Zertifikate ...........................................................................60
7.2.6. Web-Client-Zertifikate............................................................................61
7.2.7. Datei-Verschlüsselungsprogramm ..........................................................62
7.2.8. E-Mail Add-On .......................................................................................63
7.3. Modellvorstellung ...............................................................................................64
7.3.1. Datenübermittlung zwischen Instituten...................................................64
7.3.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................64
7.3.3. Internetverbindung zu einem anderen Krankenhaus...............................64
7.3.4. Gesicherte Einwahl über ISDN, Modem oder Internet...........................65
7.3.5. Webbasierte Kommunikation..................................................................65
7.3.6. Multizentrische klinische Studien über das Internet ...............................66
7.3.7. Gesicherter interner Mailversand............................................................66
7.3.8. Gesicherter externer Mailversand ...........................................................67
8. Pragmatisches Modell...........................................................................................68
8.1. Allgemeine Überlegungen ..................................................................................68
8.2. Auswahl der CA-Software ..................................................................................71
8.3. Tools zur Sicherung der Kommunikation...........................................................72
8.3.1. Router VPN.............................................................................................72
8.3.2. Firewall-Firewall VPN-Tunnel ...............................................................73
8.3.3. Anwender-Firewall VPN-Tunnel............................................................74
8.3.4. Direkter Tunnel zwischen Servern..........................................................75
8.3.5. Web-Server-Zertifikate ...........................................................................76
8.3.6. Web-Client-Zertifikate............................................................................77
8.3.7. Datei-Verschlüsselungsprogramm ..........................................................78
8.3.8. E-Mail Add-On .......................................................................................79
II

8.4. Umsetzung...........................................................................................................80
8.4.1. Datenübermittlung zwischen Instituten...................................................80
8.4.2. Direktgeschaltete Verbindung zu einer anderen Klinik ..........................80
8.4.3. Internetverbindung zu einem anderen Krankenhaus...............................81
8.4.4. Gesicherte Einwahl über ISDN, Modem oder Internet...........................81
8.4.5. Webbasierte Kommunikation..................................................................82
8.4.6. Multizentrische klinische Studien über das Internet ...............................82
8.4.7. Gesicherter interner Mailversand............................................................83
8.4.8. Gesicherter externer Mailversand ...........................................................83
9. Zusammenfassung.................................................................................................84
Anhang ...........................................................................................................................86
Literaturverzeichnis......................................................................................................88
III

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
IV

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
V

Glossar
3DES
Access Control List
ACL
AES
Dreimalige Anwendung des DES-Algorithmus
(mit verschiedenen Schlüsseln) zur Erweiterung
der effektiven Schlüssellänge auf 112 oder 168
Bit.
Befehle auf einem Router, um anhand von
TCP/IP Adressen oder Diensten (Ports) Berechtigungen
zur Kommunikation zu erteilen bzw. zu
verweigern.
siehe Access Control List
Advanced Encryption Standard, Nachfolger des
DES. Als Algorithmus wird Rijndael verwendet.
Asymmetrische Verschlüsselung Verfahren mit getrennten Schlüsseln zum Ver-
(Public Key bzw. öffentlicher Schlüssel) und Entschlüsseln
(Private Key, privater Schlüssel).
Backbone
BDSG
Brute Force
CA
Crossconnect Kabel
DES
Ethernet
Fast-Ethernet
Hauptkommunikationsleitungen, über die der
nicht-lokale Datenverkehr eines LAN bzw. WAN
läuft.
Bundesdatenschutzgesetz
Versuch, eine Verschlüsselung durch Ausprobieren
aller möglichen Schlüsselkombinationen (z.B.
2 128 ) zu brechen.
Certification Authority, Organisation welche,
durch ein Zertifikat die Echtheit eines Schlüssels
bestätigt.
Kabel (mit gedrehten Adern) zum direkten
Verbinden genau zweier Computer ohne den Einsatz
weiterer Komponenten wie Router, Switches
oder Hubs.
Digital Encryption Standard
Protokoll zur Kommunikation innerhalb eines
LAN mit einer Übertragungsrate von 10 MBit/s,
100 MBit/s (bei Fast-Ethernet), 1 GBit/s (Gigabit-Ethernet)
oder 10 GBit/s (10 Gigabit-Ethernet).
Variante von Ethernet mit 100 MBit/s.
VI

Firewall
Fingerabdruck
Fingerprint
Hash, kryptographischer
Hybride Verschlüsselung
Known Plaintext Attack
Netzwerkkomponente zur Absicherung von Netzen
vor Angriffen und zum Aufbau von VPNs.
siehe Fingerprint
Charakteristische Zahl, welche zur Identifizierung
eines Schlüssels eingesetzt werden kann und auf
kryptographischen Hash-Funktionen basiert.
Algorithmus zum Berechnen einer charakteristischen
Prüfzahl zu gegebenen Daten, bei der es
quasi unmöglich ist, andere sinnvolle Daten mit
derselben Prüfzahl zu erzeugen.
Kombination von asymmetrischer und symmetrischer
Verschlüsselung, bei der die Nutzdaten
symmetrisch verschlüsselt werden und der verwendete
Schlüssel asymmetrisch verschlüsselt
und den Nutzdaten hinzugefügt wird.
Angriff, bei welchem dem Angreifer der Quelltext
(zumindest in Teilen) bekannt ist und er versucht
dadurch Rückschlüsse auf dem Schlüssel
gewinnen zu können.
KV Kassenärztliche Vereinigung, Körperschaft
öffentlichen Rechts zur Selbstverwaltung der
Ärzte und zur Abrechnung mit den Krankenkassen.
LAN
PCA
Personal Firewall
PGP
PKI
Local Area Network – auf einen lokalen abgegrenzten
Bereich (z.B. Campus) beschränktes
Netzwerk.
Policy Certification Authority – Institution, welche
den Rahmen für die auszustellenden Zertifikate
einer hierarchischen Infrastruktur für mehrere
Certification Authorities darstellt.
Firewall-Software, die auf einem Client läuft und
diesen vor Angriffen schützen soll. Der Client
soll sowohl vor Angriffen von außen (z.B. aus
dem Internet) als auch vor Programmen geschützt
werden, die auf den Client eingeschleust wurden
(sogenannte Trojaner) und Daten ohne Wissen
des Anwenders nach außen senden sollen.
Pretty Good Privacy – vermutlich das meistgenutzte
Programm zur Verschlüsselung von
Dateien und Mails.
siehe Public Key Infrastructure
VII

Public Key Infrastructure
Pre Shared Secret
Notwendige Infrastruktur, die zum Einsatz von
Public-Key-Kryptographie notwendig ist. Diese
Infrastruktur besteht aus der oder den CAs, den
Anwendungen, welche die Zertifikate nutzen, und
auch den Anwendern, welche die Zertifikate
richtig interpretieren.
„Geheimnis“ bzw. Passwort oder Schlüssel, das
über einen sicheren Kanal zwischen Kommunikationspartnern
ausgetauscht wird.
Rijndael Verschlüsselungsalgorithmus, der zum AES
erklärt wurde.
Root-CA
Router
RSA
SecurID
Session Key
Sicherer Kanal
Signatur
SmardCard
Sniffer
CA, welche durch keine „übergeordnete“ CA
zertifiziert wird (z.B. innerhalb eines Unternehmens
oder als oberste CA eines Landes).
Netzwerkkomponente, welche Teile eines LAN
miteinander verbindet oder auch LANs über
Weitverkehrsstrecken miteinander verbindet.
Public Key Algorithmus, nach Rivest, Shamir
und Adelman benannt.
Karte von RSA Communications zum Erzeugen
von Einmalpassworten (jeweils eine 6-stellige
Zahl pro Minute), die zusammen mit einer persönlichen
PIN mit einem zentralen Server verglichen
werden und so eine (durch Wissen und
Besitz bedingte) sichere Authentisierung ohne
spezielle Chipkartenlesegeräte ermöglicht.
Schlüssel, der jedes Mal für die Übertragung von
Daten erzeugt und nicht wieder verwendet wird
(siehe auch Hybride Verschlüsselung).
Übermittlung von Daten über einen anderen Weg
als die spätere Übermittlung der verschlüsselten
Daten (z.B. bei einem direkten Treffen).
Elektronisch erstellte, kryptographisch gesicherte
Unterschrift.
Karte mit integriertem Chip, der Daten speichern
kann, die nur nach Authentisierung zugreifbar
sind oder in der komplexe Algorithmen (beispielsweise
signieren) ausgeführt werden.
Programm zum Mitlesen von Datenpaketen in
einem Netzwerk. Kann für Diagnosezwecke, aber
auch zum Ausspähen von Daten bzw. Kennungen
genutzt werden.
VIII

Switch
Symmetrische Verschlüsselung
Netzwerkkomponente, die (Ethernet-) Verbindungen
zwischen Computern direkt schaltet, die von
nicht an der Kommunikation beteiligten Computern
erschwert abhörbar ist.
Verschlüsselung, bei welcher derselbe Schlüssel
zum Ver- und zum Entschlüsseln verwendet wird.
Time Stamp „Zeitstempel”, der automatisch von einem
Computer an ein Dokument angehängt und mit
einer Signatur versehen wird. Der Time Stamp
erbringt den Nachweis, dass ein Dokument zu
einem bestimmten Zeitpunkt existiert hat.
TripleDES
Trust Center
Tunnel, verschlüsselter
VPN
WAN
Web of Trust
siehe 3DES
Institution, die als „vertrauenswürdiger Dritter“
fungiert und die Authentizität (die Zugehörigkeit
zu einer bestimmten Person) eines öffentlichen
Schlüssels bestätigt.
Logisch verschlüsselte Verbindung zwischen
zwei Computern, Netzen o.ä., durch die verschiedene
(an sich unverschlüsselte) Dienste auf verschiedenen
Computern sicher miteinander kommunizieren
können, ohne dass die Anwendungen
angepasst werden müssen.
Virtual Private Network-Verbindung zweier oder
mehrerer lokaler Netze über ein öffentliches
Netzwerk (z.B. das Internet) mittels Verschlüsselung.
Wide Area Network - Weitverkehrsnetz
Struktur, um die Zugehörigkeit eines öffentlichen
Schlüssels zu einer Person oder Institution ohne
einen „vertrauenswürdigen Dritten“ zu
bestätigen.
X.509 Standard für die Zertifizierung öffentlicher
Schlüssel.
Zertifikat
Bestätigung, welche die Zusammengehörigkeit
eines öffentlichen Schlüssels zu einer Person
(oder Institution) bestätigt.
IX

1. Einleitung
„Falls Sie glauben, dass Technologie Ihre Sicherheitsprobleme
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 Kommunikationsprozesse
aufzuzeigen, mit welchen Mitteln die Kommunikation sensibler Daten gegenüber
dem nicht autorisierten Lesen oder Verändern geschützt werden kann. Ebenfalls wird
darauf eingegangen, welche organisatorischen Maßnahmen notwendig sind, um die
Verfügbarkeit der Daten zu gewährleisten. Auch wird aufgezeigt, welche Anforderungen
an ein Trustcenter zu stellen sind, was die Ausstellung und den Rückruf von
Zertifikaten angeht. Als Beispiel werden Kommunikationsprozesse in der Medizinischen
Hochschule Hannover (MHH) vorgestellt.
Eine „absolute“ Sicherheit wird sich nicht erreichen lassen – die gibt es in der Realität
nirgends. Es ist auch klar, dass ein Sicherheitskonzept immer nur für den Rahmen,
für den es entworfen wurde, Gültigkeit besitzen kann. Wenn sich die Anforderungen
oder auch das Umfeld ändern, ist ein Sicherheitskonzept zu hinterfragen und
gegebenenfalls anzupassen. Unterlässt man dies, wiegt man sich in einer (trügerischen)
Sicherheit, die nicht gegeben ist. Sicherheit ist ein Prozess!
Diese Arbeit beschränkt sich auf Konzepte für den Einsatz kryptographischer Verfahren
in der Medizin und betrachtet weitestgehend die darunter liegenden Systeme
nicht näher. Es würde den Rahmen sprengen darüber hinaus ein Konzept für ein
sicheres LAN und eine abgesicherte Server-Infrastruktur zu erarbeiten. Es ist natürlich
eine Grundvoraussetzung, dass die verwendeten Systeme sicher sind und sich
der kryptographische Schutz nicht durch triviale Maßnahmen aushebeln lässt. Dieses
Konzept ist jedoch notwendig um einen umfassenden Schutz zu gewährleisten. Wenn
man einen Angriffsbaum (siehe [SchB2001]) aufstellt, wird man feststellen, dass die
einfachsten und erfolgversprechensten Angriffe nicht gegen die Kryptographie
selbst, sondern gegen das Umfeld durchgeführt werden können.
Aufgrund der Komplexität der gesamten Thematik kann im Rahmen dieser Arbeit
nicht darauf eingegangen werden, wie sich kryptographische Verfahren (insbes. Signaturen)
direkt in Applikationen wie z.B. Patientenadministrations-Systeme integrieren
lassen. Es werden hier Verfahren zur gesicherten Kommunikation außerhalb
integrierter Krankenhausinformationssysteme beschrieben, die unabhängig von kryptographischen
Verfahren in diesen Systemen einsetzbar sind.
Die Kapitel 2 (Anforderungen an die Übermittlung und Speicherung von
medizinischen Daten), 3 (Rechtlicher Rahmen der Kryptographie in Deutschland),
1

und 4 (Einsatzmöglichkeiten kryptographischer Verfahren im Krankenhaus) zeigen
die inhaltlichen Anforderungen auf, die Grundlage dieser Arbeit sind.
Im Kapitel 5 (Verwendete Algorithmen) werden die wichtigsten hier verwendeten
Algorithmen mit ihren mathematischen Grundlagen erläutert und Abschätzungen
gegeben, wie sicher diese Verfahren gegen ein Brechen des Schlüssels sind.
Eine Auswahl interessanter Kommunikationsprozesse und die Struktur der Kategorisierung
werden in Kapitel 6 (Ausgewählte Kommunikationsprozesse) getroffen.
In Kapitel 7 (Soll-Modell) wird ein Modell vorgestellt, wie die im vorhergehenden
Kapitel ausgewählten Prozesse wünschenswerterweise abgesichert werden sollten.
Diese Betrachtung erfolgt unabhängig davon, ob die dazu notwendigen Tools und
Anwendungen bereits heutzutage zur Verfügung stehen. Jedoch liegt ein Augenmerk
darauf, dass es im Laufe der nächsten Jahre möglich sein wird, dieses Modell umzusetzen.
Das Kapitel 8 (Pragmatisches Modell) stellt einen Kompromiss zwischen dem vorgestellten
Soll-Modell und den zur Zeit real verfügbaren Tools und Anwendungen dar,
der bereits heute mit begrenzten Mitteln realisierbar ist und ein hohes Sicherheitsniveau
erreicht.
Im Kapitel 9 (Zusammenfassung) werden die gewonnenen Erkenntnisse zusammengefasst.
Die in der Medizinischen Hochschule Hannover (MHH) vorhandene Netzwerk- und
Server-Infrastruktur wird im Anhang grob dargestellt.
2

2. Anforderungen an die Übermittlung und Speicherung
von medizinischen Daten
„Über alles, was ich während oder außerhalb der
Behandlung 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 ihre
Arbeit erlangen, etwas Besonderes sind und nicht in die falschen Hände gelangen
dürfen. Dies gilt heute in noch stärkerem Maße, da sich durch die globale Vernetzung
Informationen (selbst wenn diese nicht öffentlich zugänglich sein sollen) weltweit
verbreiten können. Die modernen Entsprechungen zu diesem Eid finden sich
sowohl im Standesrecht für Ärzte als auch im Strafrecht, welche die Vertraulichkeit
der Daten sicherstellen sollen.
Konkret sind hier der §203 (Verletzung von Privatgeheimnissen) des Strafgesetzbuches
(StGB) [StGb203] zu nennen, in dem es heißt:
(1) Wer unbefugt ein fremdes Geheimnis, namentlich ein zum persönlichen
Lebensbereich gehörendes Geheimnis oder ein Betriebs- oder
Geschäftsgeheimnis, offenbart, das ihm als
1. Arzt, Zahnarzt, Tierarzt, Apotheker oder Angehörigen eines
anderen Heilberufs, der für die Berufsausübung oder die Führung
der Berufsbezeichnung eine staatlich geregelte Ausbildung
erfordert,
2. Berufspsychologen mit staatlichen anerkannter wissenschaftlicher
Abschlußprüfung,
[...]
6. Angehörigen eines Unternehmens der privaten Kranken-,
Unfall- oder Lebensversicherung oder einer privatärztlichen
Verrechnungsstelle
anvertraut worden oder sonst bekannt geworden ist, wird mit Freiheitsstrafe
bis zu einem Jahr oder mit Geldstrafe bestraft.
(2) Ebenso wird bestraft, wer unbefugt ein fremdes Geheimnis, namentlich
ein zum persönlichen Lebensbereich gehörendes oder ein
Betriebs- oder Geschäftsgeheimnis offenbart [...]..
3

(3) Den im Absatz 1 Genannten stehen ihre berufsmäßig tätigen Gehilfen
und die Personen gleich, die bei ihnen zur Vorbereitung auf den Beruf
tätig sind. Den in Absatz 1 und den in Satz 1 Genannten steht nach
dem Tod des zur Wahrung des Geheimnisses Verpflichteten ferner
gleich, wer das Geheimnis von dem Verstorbenen oder aus dessen
Nachlaß erlangt hat.
(4) Die Absätze 1 bis 3 sind auch anzuwenden, wenn der Täter das fremde
Geheimnis nach dem Tod des Betroffenen unbefugt offenbart.
In der Muster-Berufsordnung für die deutschen Ärztinnen und Ärzte (MBO-Ä 1997
in der Fassung der Beschlüsse des 100. Deutschen Ärztetages) [DÄT1997] heißt es
zu diesem Thema:
§ 9 Schweigepflicht
(1) Der Arzt hat über das, was ihm in seiner Eigenschaft als Arzt anvertraut
oder bekannt geworden ist - auch über den Tod des Patienten
hinaus - zu schweigen. Dazu gehören auch schriftliche Mitteilungen
des Patienten, Aufzeichnungen über Patienten, Röntgenaufnahmen
und sonstige Untersuchungsbefunde.
(2) Der Arzt ist zur Offenbarung befugt, soweit er von der Schweigepflicht
entbunden worden ist oder soweit die Offenbarung zum Schutze eines
höherwertigen Rechtsgutes erforderlich ist. Gesetzliche Aussage- und
Anzeigepflichten bleiben unberührt. Soweit gesetzliche Vorschriften
die Schweigepflicht des Arztes einschränken, soll der Arzt den Patienten
darüber unterrichten.
(3) Der Arzt hat seine Mitarbeiter und die Personen, die zur Vorbereitung
auf den Beruf an der ärztlichen Tätigkeit teilnehmen, über die gesetzliche
Pflicht zur Verschwiegenheit zu belehren und dies schriftlich
festzuhalten.
(4) Wenn mehrere Ärzte gleichzeitig oder nacheinander denselben Patienten
untersuchen oder behandeln, so sind sie untereinander von der
Schweigepflicht insoweit befreit, als das Einverständnis des Patienten
vorliegt oder anzunehmen ist.
Zusätzlich ergibt sich die Notwendigkeit der Dokumentation dadurch [Ber1996],
dass speziell im Krankenhaus verschiedene Personen mit der Behandlung eines Patienten
betraut sind und diese sich nur so über den aktuellen Zustand angemessen
gegenseitig informieren können. Die Dauer der Behandlung kann sich auch über
Monate und Jahre erstrecken. Ebenfalls ergibt sich die Dokumentationspflicht daraus,
dass im Falle von Rechtsstreitigkeiten (im Nachhinein) belegbar sein muss,
weshalb welche Behandlung durchgeführt wurde (oder auch nicht). Hier ist primär
herauszustellen, dass nachweisbar sein muss, dass die Dokumentation authentisch ist
und 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 der
Speicherung und Archivierung ergibt sich die Notwendigkeit einer gesicherten
Übermittlung. Man könnte natürlich, um die Daten zu versenden, diese auf Disketten
4

(oder anderen Wechselmedien) speichern und per Post versenden, jedoch würde
dadurch der große Vorteil von elektronisch gespeicherten Daten, die schnelle Übermittlung,
verloren gehen. Da jedoch medizinische Daten über Datennetze (ISDN,
Internet z.B. per E-Mail etc.) nach Auffassung der Datenschutzbeauftragten oder
Kassenärztlichen Vereinigungen (KV) nur übertragen werden dürfen, wenn diese
hinreichend geschützt sind, wird dadurch eine sichere Verschlüsselung notwendig.
Da durch die elektronische Dokumentation ein wesentlich größeres Angriffspotenzial
vorhanden ist als in der konventionellen, papierbasierten, ist die Übertragung der
Daten ü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ürdiges“
Netz wie z.B. ein sogenanntes „medizinisches Netz“ geschieht.:
„Ausdrücklich muß in diesem Zusammenhang darauf hingewiesen werden, dass
die Verantwortung für die Einhaltung der ärztlichen Schweigepflicht und die
Wahrung des Datenschutzes nicht delegiert werden kann. Aus diesem Grund muß
jederzeit für den Anwender [Anm.: der Arzt] überprüfbar sein, dass entsprechende
Schutzmechanismen eingerichtet und jederzeit wirksam sind.[...] Dabei
ist von wesentlicher Bedeutung, dass evtl. zu verschlüsselnde Nachrichten jeweils
bereits im eigenen Einflußbereich so chiffriert werden, dass kein unbefugter
Dritter 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 im
Internet nur zulässig, wenn geeignete Sicherungsmaßnahmen getroffen werden.
Für den Aspekt der Vertraulichkeit bedeutet dies, dass ein nach dem heutigen
Stand der Technik ausreichend sicheres Verschlüsselungsverfahren zum Einsatz
kommen muss.“
In [Jac1996] Schreibt der Bundesbeauftragte für den Datenschutz, Jacob:
„Die Risiken der Übertragung sind – völlig unabhängig von der Zulässigkeit – so
gering wie möglich zu halten, hier sind wenn möglich kryptographische
Verschlüsselungsverfahren einzusetzen. Deshalb müssen die technischen
Vorkehrungen für planbare Telekonsikien [Anm.: ein Arzt beteiligt an der
Behandlung eines Patienten durch den Einsatz von Telekommunikationseinrichtungen
anderen Ärzte oder Fachleute] den Einsatz von Verschlüsselung
vorsehen.“
Daraus folgt, dass der Übermittlung von Patientendaten über Computernetzwerke
(geschlossene oder offene) keine prinzipiellen rechtlichen Vorbehalte entgegen stehen,
sofern diese nach dem heutigen Stand der Technik ausreichend geschützt sind.
5

3. Rechtlicher Rahmen der Kryptographie in
Deutschland
Einen direkten rechtlichen Rahmen für den Einsatz von Signaturen gibt es in
Deutschland seit der Einführung des Signatur Gesetzes (SigG) 1997. Vorher war es
den Gerichten im Rahmen der freien Beweiswürdigung möglich, Signaturen (ggf.
nach aufwendigen Gutachten) anzuerkennen - oder auch nicht, wenn das Gericht
nicht überzeugt wurde.
Mit der Einführung des SigG 1997 betrat Deutschland international Neuland, da es
bisher in dieser Form für ein landesweit geltendes Signaturgesetz keine Beispiele
gab.
In dem SigG wurde eine Genehmigungspflicht für Trustcenter definiert, die sehr
hohe Anforderungen an die räumlichen und administrativen Vorgänge der Zertifizierung
stellt und somit einen erheblichen finanziellen und organisatorischen Aufwand
für den Betrieb eines Trustcenters erforderlich macht. Vermutlich deshalb gab es nur
wenige Institutionen, welche eine Zulassung beantragten (siehe auch [SchC2001] ,
[LANL2001], [Mal2001]).
Im Rahmen einer europäischen Richtlinie zur Vereinheitlichung der Signaturgesetze
innerhalb der Europäischen Union wurde 2001 die Rechtslage in Deutschland angepasst.
Die neue Gesetzeslage unterscheidet sich in folgenden Punkten wesentlich von
dem bisherigen Gesetz:
• Die Genehmigungspflicht wurde zugunsten einer Anzeigepflicht gestrichen.
Es entstehen also keine Kosten für eine Zertifizierung. Zusätzlich gibt es jetzt
eine Haftungsregelung für die TrustCenter, welche in Kraft tritt, wenn aufgrund
eines Verschuldens des TrustCenters einem Dritten ein Schaden entsteht,
weil er einem (fehlerhaften) Zertifikat vertraute. Durch die Haftungsregelung
dürfte das Vertrauen in die Echtheit der Signaturen steigen.
• Es gibt jetzt drei Signaturen. Die „einfache Signatur“, die europaweit einheitliche
„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. Hier
bleibt es dem Anbieter überlassen, in welchem Rahmen er den Nutzern
gegenüber haftet [iX2001-04]. Bei der „Fortgeschrittenen Signatur“ haftet das
TrustCenter für die Richtigkeit und Vollständigkeit der zertifizierten Angaben
gegenüber Dritten, wenn diesen durch fahrlässiges Verhalten des Trust-
Centers ein Schaden entstanden ist. Die „Qualifizierte Signatur“ ist sozusagen
eine offiziell zertifizierte Signatur, bei welcher der Betreiber nachgewiesen
hat, dass er erfolgreich einen hohen Aufwand betreibt, um die Sicherheit zu
gewährleisten. Es handelt sich dabei sozusagen um eine an die Europäische
Signaturrichtlinie angepasste Variante des bisherigen Signaturgesetzes.
6

Ebenfalls aufgrund der europäischen Rechtslage wurde das „Gesetz zur Anpassung
der Formvorschriften des Privatrechts und anderer Vorschriften an den modernen
Rechtsgeschäftsverkehr“ verabschiedet, welches die nahezu vollständige Gleichstellung
der elektronischen Signatur und der eigenhändigen Unterschrift regelt. Es gibt
für einige Fälle Ausnahmen, die jedoch i.d.R. ohnehin nicht „digital“ erfolgen. So ist
eine „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 haben
jedoch einige Juristen Bedenken, da durch diese Regelung der Signatur eine höhere
Wertigkeit als der manuellen Unterschrift eingeräumt wird.
Da es in Deutschland – wie in den meisten Ländern – keine Reglementierung für den
Einsatz kryptographischer Verfahren zur Verschlüsselung gibt, kann dazu ein beliebiges
(sicheres oder unsicheres) Verfahren Einsatz finden. Beschränkt auf sichere
Verfahren wird diese Freiheit jedoch dadurch, dass bei der Anwendung im medizinischen
Umfeld die Vertraulichkeit der Patientendaten gefordert wird und dies nur mit
sicheren Verfahren zu gewährleisten ist.
Die USA sind nach wie vor international der größte Produzent von Standardsoftware
und so war die Exportbeschränkung von kryptographischen Produkten der USA ein
ernst zu nehmendes Problem für die Verbreitung sicherer Kryptographie in Standardprodukten.
Durch die Beschränkung durften nur Produkte mit einer relativ schwachen
Verschlüsselung (z.B. DES mit 40 Bit) exportiert werden, sofern keine besondere
Exportgenehmigung (z.B. für den Einsatz bei Banken) erteilt wurde. Erst nach
der Liberalisierung der US-amerikanischen Exportgesetze ist es möglich ohne eine
spezielle Genehmigung in Europa sichere Kryptographie (z.B. in Web-Browsern)
einzusetzen.
7

4. Einsatzmöglichkeiten kryptographischer Verfahren
im Krankenhaus
„Komplexität ist der schlimmste
Feind der Sicherheit.“
[Bruce Schneier, Secrets & Lies]
Es gibt zahlreiche Einsatzmöglichkeiten für die verschiedenen kryptographischen
Verfahren im Krankenhaus. In diesem Kapitel werden verschiedene Verfahren vorgestellt,
welche dazu eingesetzt werden können, die im nächsten Kapitel vorgestellten
Prozesse abzusichern.
4.1. Verschlüsselungsverfahren
4.1.1. Symmetrische Verschlüsselung
Bei der symmetrischen (konventionellen) Verschlüsselung verwenden alle Kommunikationspartner
denselben Schlüssel zum Ver- bzw. Entschlüsseln. Einer der größten
Vorteile der symmetrischen Verschlüsselung ist die Schnelligkeit der verwendeten
Algorithmen. Es ist heutzutage möglich, sowohl in Software als auch in Hardware
effiziente Implementierungen dieser Algorithmen für verschiedene Anwendungen
herzustellen. Einer der größten Nachteile dieser Verfahren ist der Austausch der
Schlüssel bei Kommunikationspartnern, die sich gegenseitig nicht kennen bzw. keinen
sicheren Kanal zum Austausch des gemeinsamen Schlüssels haben. Es existieren
zwar Protokolle für den sicheren Austausch von symmetrischen Schlüsseln, diese
setzen jedoch eine interaktive Verbindung voraus (ansonsten gestaltet sich der
Schlüsseltausch recht langwierig, da die Schlüssel per E-Mail o.ä. übertragen werden
müssen und eine Interaktion durch den Anwender erforderlich ist) und bieten keine
Gewähr für die Authentizität des Kommunikationspartners.
Da für jede mögliche Kommunikationsbeziehung ein eigener Schlüssel erzeugt werden
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 es
jedoch, ein Verzeichnis der Nutzer eines bestimmten Verfahrens zu erstellen, aufgrund
dessen die Partner ein Schlüsselaustauschprotokoll durchführen, bei dem ein
Schlüssel über einen nicht gesicherten Kanal übertragen wird.
Eine Signatur (oder präziser eine Nachrichtenauthentisierung) mit symmetrischen
Schlüsseln ist realisierbar. Jedoch ist es unmöglich, gegenüber einem Dritten zu
8

eweisen, dass der andere Kommunikationspartner ein Dokument signiert hat, da
jeweils beide Partner signieren können.
Die zur Zeit gebräuchlichen Schlüssellängen liegen bei 56 Bit (z.B. bei DES), 112
oder 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änge
von 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 werden
können. Demnach sind 90 Bit ausreichend um, eine Sicherheit bis 2016 zu gewährleisten.
Schlüssel mit einer Länge von 128 oder 256 Bit reichen aus, um in den
nächsten Jahrzehnten sicher zu sein. Das US National Institute of Standards and
Technology (NIST) geht beispielsweise davon aus, dass der neue Standard AES
(Advanced Encryption Standard) mit einer Schlüssellänge von 128 Bit die nächsten
30 Jahre sicher sein wird [Kre2000].
Es besteht natürlich immer die Gefahr, dass eine Schwachstelle eines Algorithmus
gefunden wird, die ein deutlich schnelleres Brechen des Algorithmus ermöglicht als
durch einen Brute-Force-Angriff. Jedoch dürfte diese Gefahr bei publizierten und
von anerkannten Experten überprüften Algorithmen relativ gering sein. Sie ist aber
nicht auszuschließen.
Ein Beweis dafür, dass ein symmetrisches Verfahren sicher ist (also nur durch Brute
Force zu knacken), ist aufgrund der komplexen Struktur eines Verfahrens wie DES
oder AES heutzutage praktisch nicht zu erbringen. Im Gegensatz zu den asymmetrischen
Verfahren, die zum größten Teil darauf beruhen, dass es heutzutage und möglicherweise
niemals möglich ist, bestimmte mathematische Operationen praktisch
durchzuführen (wie das Faktorisieren großer Zahlen), ist es bei den symmetrischen
Verfahren so, dass sie die Daten so „durcheinander würfeln“, dass sich aus dem
Chiffretext keinerlei Rückschlüsse auf die Quelldaten ziehen lassen.
Das einzige beweisbar sichere symmetrische Verschlüsselungsverfahren ist das
sogenannten OTP (One Time Pad), bei dem jede Nachricht mit einem genauso langen
und zufälligen Schlüssel verschlüsselt wird und der Schlüssel nur ein einziges
Mal verwendet wird und auf einem sicheren Weg zwischen Sender und Empfänger
ausgetauscht werden muss. Da die Erzeugung, Verwaltung und Verteilung solchermaßen
großer Schlüssel praktisch nicht durchführbar ist, wird das OTP kaum eingesetzt.
Wenn beispielsweise derselbe Schlüssel mehrmals verwendet wird, ist es möglich,
durch Häufigkeitsanalysen den Schlüssel zu erkennen und damit Zugriff auf alle
damit übertragenen Quelldaten zu erlangen.
Ein praktisches Beispiel dazu ist in [Smi1998] nachzulesen, in dem durch den fehlerhaften
Einsatz des OTP (von der Sowjetunion) im Zweiten Weltkrieg mehrere
OTP-Schlüssel gefunden werden konnten. Der Fehler der Sowjets lag darin, dass sie
nicht genügend zufällige Schlüssel erzeugen konnten und so denselben Schlüssel an
mehrere ihrer Auslandsvertretungen gegeben hatten (eine einzelne Vertretung hat
jeden Schlüssel nur ein einziges Mal genutzt). Da die USA aber entgegen der
Annahme der Sowjets Zugriff auf die Kommunikation mehrerer der Auslandsvertretungen
hatten, konnten die USA die verwendeten Schlüssel rekonstruieren und so die
übermittelten Nachrichten ermitteln.
9

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 unterschieden.
Mit dem öffentlichem Schlüssel kann jeder sozusagen einen Brief in den Hausbriefkasten
des Empfängers einwerfen und nur der Besitzer des privaten Schlüssels
kann den Briefkasten öffnen und den Brief lesen.
Der große Vorteil der asymmetrischen Verschlüsselung ist die Möglichkeit des Aufbaus
eines Verzeichnisses (sozusagen eines „Telefonbuches“), in dem die öffentlichen
Schlüssel von Nutzern des Verfahrens gespeichert werden. Dadurch ist es möglich,
einem unbekannten Kommunikationspartner verschlüsselte Nachrichten
zukommen zu lassen, ohne dass man mit diesem vorher Kontakt zum Austausch
eines gemeinsamen Schlüssels aufgenommen haben muss. Hier stellt sich das Problem
der Authentizität der dort gespeicherten Schlüssel. Diese Problematik wird in
Kapitel 4.3 (Zertifizierungsinfrastrukturen) behandelt.
Elektronische Signaturen sind mit einigen asymmetrischen Verfahren möglich (siehe
dazu 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 sicher
angesehen. Eine Länge von 1024 Bit gilt z.Zt. als sicher gegen Einzelpersonen und
2048 Bit gelten auch noch für die nächsten Jahre als sicher. In [SchB1996] empfiehlt
Bruce Schneier die folgenden Schlüssellängen:
Jahr
gegen
Einzelpersonen
gegen
Unternehmen
gegen
Regierungen
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 Operationen,
deren Ausführung im Vergleich zu den symmetrischen Verfahren langsam und
in Hardware auch nur aufwendig nachzubilden ist. Die Verfahren sind jedoch zum
Teil beweisbar sicher, oder man kann beweisen, dass unter Vorhandensein von
bestimmten Bedingungen ein Verfahren sicher ist. Durch Fortschritte in der Mathe-
10

matik oder den Einsatz von Quantencomputern, die eine schnelle Faktorisierung großer
Zahlen ermöglichen, ist es theoretisch möglich, z.B. den RSA-Algorithmus
schneller zu brechen. Jedoch ist das bereits seit vielen Jahren ein ungelöstes Problem
der 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, sondern
vielmehr um die Verknüpfung der symmetrischen und der asymmetrischen Verfahren,
um mit den Stärken des jeweiligen Verfahrens die Schwächen des Anderen zu
kompensieren. Bei der hybriden Verschlüsselung werden die zu verschlüsselnden
Daten mit einem konventionellen (schnellen symmetrischen) Verfahren und einem
zufälligen Schlüssel den zunächst nur der Sender kennt verschlüsselt. Dieser Schlüssel
(z.B. 128 Bit lang) wird dann durch den Einsatz des asymmetrischen Verfahrens
selbst verschlüsselt und zusammen mit den konventionell verschlüsselten
Daten an den Empfänger gesandt. Dieser kann nun mit Hilfe seines geheimen
Schlüssels den Schlüssel des konventionellen Verfahrens erhalten und damit die Originaldaten
wiederherstellen.
Der asymmetrische Schlüssel des Empfängers kann nun also in einem öffentlichen
Verzeichnis gespeichert werden und die Daten werden mit einem effizienteren symmetrischen
Verfahren verschlüsselt.
Da diese Art Verschlüsselung nur so stark ist wie das schwächste Glied, ist es wichtig
darauf zu achten, dass beide Schlüssellängen ausreichend sind. Es macht keinen
Sinn mit einem 4096 Bit langen Public Key zu verschlüsseln, wenn der symmetrische
Algorithmus nur einen 56-Bit-Schlüssel verwendet. Schneier vergleicht in
[SchB1996] die Schlüssellängen von symmetrischen und asymmetrischen Algorithmen
miteinander, die etwa gleich schwer (durch Brute Force) gebrochen werden
können. Wenn der symmetrische Algorithmus mit 128 Bit eingesetzt wird, ist es
nicht übertrieben für den asymmetrischen Teil 2048 Bit zu wählen, insbesondere
deshalb, weil der symmetrische Schlüssel meistens nur ein einziges Mal als Sitzungsschlüssel
(Session Key) verwendet wird und derselbe asymmetrische Schlüssel teilweise
über Jahre hinweg auch zum Signieren von Dokumenten eingesetzt wird.
11

symmetrisch
[Bit]
asymmetrisch
[Bit]
56 384
64 512
80 768
112 1792
128 2304
Tabelle 4-2: Symmetrische und asymmetrische Schlüssel ähnlicher
Resistenz [SchB1996]
4.1.4. Transcoding
Eine spezielle (zum Patent angemeldete) Variante der hybriden Verschlüsselung wird
bei dem Projekt „Community Health Information Network“ (CHIN) verwandt, das
auf dem Konzept „PaDok“ der Arbeitsgruppe Medizin-Technik des Fraunhofer-
Instituts für Biomedizinische Technik basiert. Die MHH nimmt an einem solchen
Pilotprojekt zur Vernetzung mit Arztpraxen niedergelassener Ärzte und Laboren teil.
Bei CHIN geht es darum, dass die Übermittlung der Behandlungsdaten bzw. der
Untersuchungsergebnisse zwischen den Ärzten auf elektronischem Wege stattfinden
soll. Dazu werden die zu übermittelnden Daten (beispielsweise Befundbriefe und
Laborwerte) verschlüsselt und auf einen zentralen Server gestellt. Auf diesen Server
kann wiederum der weiterbehandelnde Arzt (beispielsweise in der MHH) zugreifen
und die Daten in das Patientenverwaltungssystem integrieren.
Die Problematik ergibt sich daraus, dass der Patient das Recht der freien Arztwahl
hat und so der Erzeuger der Daten sie nicht speziell für einen Empfänger verschlüsseln
kann, da zu diesem Zeitpunkt nicht bekannt ist, wer der Empfänger ist. Es ist
lediglich 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 werden
symmetrisch verschlüsselt und der hier eingesetzte Schlüssel als Vorgangskennung
bezeichnet. Anschließend werden die Daten mit dem Public Key der Adressatengruppe
verschlüsselt und auf dem CHIN-Server abgelegt [IBMT2000].
Dem Patienten wird zusammen mit der Überweisung auch die Vorgangskennung
ausgehä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üsselung
für seine Adressatengruppe entfernen. Die Daten sind jedoch noch weiterhin
12

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 weiteren
Entschlü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 Arzt
in unverschlüsselter Form existieren (und sei es im Hauptspeichers des CHIN-Servers).
Die Daten sind selbst in dem Fall sicher, in dem der Patient die Vorgangskennung
verliert. Denn zum Entschlüsseln ist noch immer der passende Schlüssel der
Adressatengruppe notwendig. Als Adressatengruppen kommen beispielsweise alle
medizinischen Fachrichtungen in Frage, zu denen Patienten überwiesen werden können
(Orthopäden, Radiologen, Internisten etc.).
In der MHH nehmen zur Zeit die Klinik für Urologie und das Institut für Mikrobiologie
als Empfänger dieser elektronischen Überweisungen teil und übermitteln die
Behandlungs- oder Untersuchungsergebnisse an den Überweisenden zurück.
4.2. Authentisierungsverfahren
Authentisierungsverfahren sind quasi die Umkehrung der asymmetrischen Verschlüsselung.
Hier wird von dem Signierenden ein Dokument mit seinem privaten
Schlüssel verschlüsselt und kann dann von jedem durch den öffentlichen Schlüssel
wieder zurückgewandelt werden. Da dieser Vorgang relativ langsam ist (der Zeitaufwand
ist etwa genau so groß wie bei dem Einsatz als Verschlüsselungsverfahren)
und es (wenn man nur die Signatur betrachtet) nicht auf die Geheimhaltung des
Inhalts ankommt, wird in der Regel auch hier ein hybrider Ansatz gewählt. Es wird
nicht das Originaldokument verschlüsselt, sondern quasi ein „Fingerabdruck“, der
durch den Einsatz einer sogenannten kryptographischen Hashfunktion erzeugt wird.
Zur Überprüfung der Signatur wird nun ebenfalls ein Fingerabdruck des Dokuments
errechnet. Dieser Fingerabdruck wird nun nachdem er entschlüsselt worden ist, mit
dem Fingerabdruck des Signierenden verglichen. Genau dann, wenn die beiden Fingerabdrücke
gleich sind, ist das Dokument authentisch.
Ebenso wie bei der asymmetrischen Kryptographie können die öffentlichen Schlüssel
in einer Art Telefonbuch für jeden aufbewahrt werden und so die Überprüfung der
Echtheit von Dokumenten ermöglichen. Bei dem RSA-Verfahren kann ein und derselbe
Schlüssel sowohl für die Verschlüsselung als auch für die Signatur eingesetzt
werden. Auch bei diesem Verfahren stellt sich die Frage nach der Authentizität der
Schlüssel. Diese kann durch den Einsatz einer Zertifizierungsinfrastruktur gelöst
werden, wie im nächsten Abschnitt beschrieben wird.
4.3. Zertifizierungsinfrastrukturen
Bei dem Einsatz asymmetrischer Verfahren für die Verschlüsselung oder Signatur
stellt sich bei einem nicht mehr überschaubaren Personenkreis immer die Frage nach
13

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 Befundes
im Krankenhaus zweifelsfrei klar sein, wer die Signatur erstellt hat. Falls
keine Überprüfung möglich ist, könnte ein Unbekannter Diagnosen stellen oder
Behandlungen veranlassen. Noch folgenreicher könnte es sein, wenn ein Unbekannter
vorgibt im Namen eines bestimmten (existierenden) Arztes zu handeln und Fehlentscheidungen
zu Konsequenzen für den betroffenen Arzt – und schlimmer noch für
den Patienten - führen würden.
Diese Bindung eines öffentlichen Schlüssels an eine bestimmte Person geschieht
dadurch, dass eine vertrauenswürdige Stelle (Certification Authority, CA) eine
Überprüfung der Identität einer Person (z.B. durch Vorlage des Personalausweises
oder eines Dienstausweises) feststellt und den von ihr mitgebrachten öffentlichen
Schlüssel mit einem Zertifikat versieht. Dieses Zertifikat besagt, dass der Schlüssel
und der angegebene Name wirklich zu der genannten Person gehören. Dies wird
durch das Signieren des öffentlichen Schlüssels, der außer dem kryptographischen
Schlü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 notwendig
den öffentlichen CA-Schlüssel auf einem sicheren Weg zu erhalten und in das eigene
Verschlü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 flachen
Struktur gibt es eine einzige zentrale Stelle, welche alle Zertifikate ausstellt. Dies
könnten in der MHH z.B. die Rechtsabteilung, Personalabteilung (insbesondere für
die Schlüssel der Mitarbeiter), das Rechenzentrum oder die Medizinische Informatik
sein. Es ist auf jeden Fall darauf zu achten, dass in der verantwortlichen Abteilung
das notwendige (Hintergrund-) Fachwissen für die ordnungsgemäße Durchführung
vorhanden ist.
Abbildung 4-1: Flache Struktur [NiSc2001]
In einer hierarchischen Struktur gibt es eine zentrale CA (Root-CA, z.B. die
Policy Certification Authority des DFN-Vereins „Verein zur Förderung eines deutschen
Forschungsnetzes“, DFN PCA), welche wiederum Zertifikate für weitere
CAs erstellt (beispielsweise die der MHH). Dabei ist es nun ausreichend, wenn man
14

den öffentlichen Schlüssel der Root-CA hat. Dadurch werden transitiv (s.u.) alle
Zertifikate als authentisch akzeptiert, die innerhalb dieser Hierarchie erstellt wurden.
Da es bisher noch keine Institution gibt, die speziell für das Gesundheitswesen eine
allgemein anerkannte CA betreibt, haben sich vier Einrichtungen des Gesundheitswesens,
die Deutsche Krankenhaus TrustCenter und Informationsverarbeitungs
GmbH (DKTIG), Informationstechnische Servicestelle der Gesetzlichen Krankenversicherung
GmbH (ITSG), Verband Deutscher Rentenversicherungsträger GmbH
(VDR) und Bundesversicherungsanstalt für Angestellte (BfA) zu einer Kooperation
zusammengeschlossen 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, das
Land Niedersachsen, eine Institution des Gesundheitswesens oder einen kommerziellen
Anbieter betrieben wird.
Das folgende Beispiel verdeutlicht das „transitive Vertrauen“:
Abbildung 4-3: Transitives Vertrauen
15

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 dieser
Schlüssel von Marta signiert wurde, und besorgt sich ebenfalls den Public Key
von Marta.
Nun kann sie sehen, dass Bob von Marta zertifiziert wurde und Marta wiederum
von 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 einer
flachen Struktur entspricht), würde sie Bob nicht als authentisch ansehen.
Zusätzlich zu diesen beiden Modellen gibt es auch noch das „Web of trust“, welches
von dem Programm PGP verwendet wird und sozusagen als Verallgemeinerung des
hierarchischen Modells angesehen werden kann. In dem „Web of trust“ gibt es keine
speziellen CAs, sondern jeder kann Zertifikate für Schlüssel ausgeben. Es kann also
jeder 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 ist
für den Einsatz in der MHH nicht praktikabel, da es hier keine Trennung zwischen
den zur Zertifizierung berechtigten Stellen (der CA) und den Signaturen, die jeder
Schlü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 Transitivitä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 beispielsweise
in [CKLW2000].
16

Da der zentrale Server der CA, welcher die Zertifikate ausstellt, keinesfalls an ein
Netzwerk angeschlossen sein sollte [CKLW2000], ist es notwendig innerhalb der
MHH einen Server zu betreiben, der einen nur lesenden Zugriff auf die ausgestellten
und auch die widerrufenen Zertifikate erlaubt.
Wenn in der MHH ausgestellte Zertifikate auch außerhalb der MHH gültig überprüfbar
sein sollen (wovon bei der Integration in eine Zertifizierungshierarchie ausgegangen
werden kann), empfiehlt es sich, den Server für die Abfrage der Zertifikate
auch aus dem Internet erreichbar zu gestalten. Selbstverständlich muss der Server in
einem vom Netz der MHH abgeschotteten Segment aufgebaut werden. Sinnvoll wäre
auch die Bereitstellung der Zertifikatsinformationen über einen in der Hierarchie
hö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 zu
wissen, von wem es signiert wurde. Eine im Nachhinein erstellte und auf einen Zeitpunkt
vor der Ziehung rückdatierte „Vorhersage“ der Lottozahlen ist trotz einer gültigen
Signatur wertlos.
Da es technisch gesehen kein Problem ist, die Signatur eines Dokumentes vor- oder
zurückzudatieren, und der Einsatz eines unabhängigen Dritten bei der Signierung
vieler Dokumente nicht praktikabel ist, kann der Aufbau eines Zeitstempel-Dienstes
interessant sein. Ein solcher Dienst nimmt ein Dokument entgegen, versieht es mit
der aktuellen Zeit des Eintreffens, signiert dies 2-Tupel (bestehend aus aktuellem
Datum und Uhrzeit, sowie dem eingesandten Dokument) und sendet es an den
Absender zurück. Der Absender signiert nun das gesamte mit Zeitstempel und Signatur
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 Zeitpunkt
bescheinigt, ist es möglich dies automatisiert durch ein Programm durchzuführen,
das selbstverständlich sicherstellen muss, dass die aktuelle Uhrzeit bekannt ist. Dazu
kann z.B. eine Kombination aus DCF77- (Sender zur Übermittlung der offiziellen
Zeit in Deutschland) oder GPS-Empfänger (Global Position System, ermöglicht die
Positions- und Zeitbestimmung) und Anfrage von offiziellen Zeitservern (z.B. der
Physikalisch Technischen Bundesanstalt) sein. Da für einen solchen Zeitstempel
selbst das bereits signierte und verschlüsselte Dokument verwendet werden kann,
besteht auch keine Gefahr für die Vertraulichkeit der Daten.
17

4.5. Schlüsselverlust
Ein Problem bei dem Einsatz starker Kryptographie (das bedeutet, dass sie nach heutigem
Kenntnisstand nicht in vertretbarer Zeit zu brechen ist) ist das Problem des
Schlüsselverlustes. Wenn Daten nicht nur zur Übertragung, sondern auch bei der
Speicherung oder Archivierung verschlüsselt bleiben, ist es erforderlich bereits bei
der Erstellung des Konzeptes organisatorische Maßnahmen zu definieren, um den
Zugriff 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äter
ist der Schlüssel des Arztes nicht mehr nutzbar. 1
Nun steht die MHH vor dem Problem, dass sie Zugriff auf (rechtlich gesehen ihr
bzw. dem Patienten gehörenden) Daten benötigt, jedoch kein Schlüssel mehr
vorhanden ist. In diesem Fall gibt es mehrere Möglichkeiten auch weiterhin
Zugriff 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üsselungsprogramme
einen zusätzlichen Schlüssel verwenden (auch ADK – Additional
decryption Key – genannt). Durch den Einsatz dieses Schlüssels ist es möglich
auf offiziellem Wege auf alle innerhalb der MHH verschlüsselten Daten
zugreifen zu können.
Dieser Schlüssel ist natürlich entsprechend geschützt zu speichern und durch
ein Mehraugenprinzip zu schützen; beispielsweise muss – um durch den
ADK verschlüsselte Dokumente entschlüsseln zu können – immer der Vorstand
der MHH gemeinsam anwesend sein um den Zugriff zu ermöglichen.
• Eine weitere Möglichkeit besteht darin, dass die Schlüssel der Mitarbeiter
zusätzlich in einer zentralen Datenbank gespeichert werden, die wiederum
durch einen speziellen Schlüssel gesichert ist, auf den beispielsweise ebenfalls
nur gemeinsam durch die Vorstandmitglieder der MHH zugegriffen
werden kann. Jetzt kann im Falle des Schlüsselverlustes der Schlüssel selbst
wiederhergestellt werden (Key recovery). Dadurch ist es dann auch möglich
dem Besitzer des Schlüssels seinen Schlüssel wieder zur Verfügung zu stellen.
1 Diese Situation kann beispielsweise dadurch entstehen, dass das Medium, auf dem der Schlüssel
gespeichert war, verloren ging, der Arzt Opfer eines Unfalls wurde oder er im Streit mit seinem
Arbeitgeber liegt und den Schlüssel nicht herausgibt.
18

In diesem Fall ergibt sich jedoch die Problematik, dass – sollte derselbe
Schlüssel sowohl zur Verschlüsselung als auch zur Signatur eingesetzt werden
– es möglich wäre, Signaturen im Namen des Schlüsselbesitzers durchzuführen.
Das gleicht Blanko-Unterschriften, die jeder Arzt in der MHH hinterlegen
müsste und auf die beispielsweise der Vorstand Zugriff hätte. Ein
Szenario, welches der Akzeptanz kryptographischer Werkzeuge sicherlich
nicht zuträglich ist.
Eine Lösung für dieses Problem ist der Einsatz von getrennten Schlüsseln für
die Verschlüsselung und Signatur. Dann müsste nur noch der Verschlüsselungsschlüssel
hinterlegt werden und der Signierschlüssel bliebe einmalig
und geheim. Wenn der Verschlüsselungsschlüssel verloren geht, könnte er
wiederhergestellt werden. Sollte der Signierschlüssel verloren gehen, ist das
nicht weiter tragisch, dann würde ein neuer generiert und von der CA zertifiziert.
Die bereits getätigten Unterschriften blieben gültig (der Public Key
wäre ja noch verfügbar), nur für neue Signaturen müsste der neue Signierschlüssel
eingesetzt werden.
Viele Kryptographie-Experten empfehlen ohnehin, getrennte Schlüssel für Verschlüsselung
und Signatur zu verwenden, um so im Falle von noch verborgenen
Schwachstellen der Algorithmen weniger Angriffsmöglichkeiten auf den Signierschlüssel
zu bieten, da in der Regel weniger signiert als verschlüsselt wird. Ebenfalls
werden dadurch weitere Angriffe erschwert, wie die chosen-plaintext (bzw. cyphertext)-attack,
bei der vom Angreifer dem Opfer ein dem Angreifer bekannter Text
bzw. Chiffretext übermittelt wird, der dann vom Opfer entschlüsselt bzw. verschlüsselt
wird.
4.6. Bedrohungsmodelle
Ein wichtiges Kriterium für die Auswahl der geeigneten Verfahren zum Schutz der
medizinischen Daten ist eine Betrachtung des Bedrohungsmodells. Die wesentlichen
Kriterien 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 Methoden
zur Überwachung zugriffsberechtigter Personen (Tastendrücke mitschreiben
etc.)).
19

• Ist eine Verschlüsselung notwendig, oder ergibt sich der Schutz bereits
durch 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 Verfahren
ein höheres Maß an Sicherheit geboten werden muss, als es bisher mit konventionellen
Mitteln erreicht wurde, oder ob es ausreichend ist, das Niveau zu halten. Blobel
und Pommerening schreiben in [BlPo1997]: „Patientendaten sind nach dem Stand
der Technik zu schützen, wobei aber das Prinzip der Verhältnismäßigkeit zu beachten
ist.“
Das dieser Arbeit zugrundeliegende Bedrohungsmodell orientiert sich daran, die bisherige
Sicherheit innerhalb der MHH auch durch den Einsatz von Computern weiterhin
zu gewährleisten. Insbesondere ist dafür zu sorgen, dass bei der Datenübermittlung
über öffentliche Netze (zu denen in diesem Zusammenhang auch spezielle
Netze 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 die
Informationen Geld zu erhalten, sondern der Wunsch nach Rache (z.B. bei
unzufriedenen Mitarbeitern oder Studenten), die der MHH eins „auswischen“
wollen. Ebenfalls kann es sein, dass dieser Angreifer „nur“ zeigen
möchte, wie leicht es ist, an sensible Daten zu gelangen und den daraus
resultierenden Ruhm (unerkannt) zu genießen. Bei diesem Personenkreis
muss davon ausgegangen werden, dass sie die Strukturen kennen und so
einen gezielten Angriff auf die schwächsten Punkte durchführen können.
• Kriminelle Angreifer: Hier handelt es sich um MHH-fremde Personen, die
ein Interesse daran haben, Informationen über Patienten der MHH zu erhalten,
z.B. um sie zu erpressen. Es ist auch denkbar, dass die Angreifer nicht
Informationen über eine konkrete Person suchen, sondern solange alles mitschneiden,
bis etwas dabei ist, durch das sie zu Geld kommen können. Diese
Angreifer haben i.d.R. ausreichende Geldmittel zur Verfügung, jedoch häufig
nicht die Detailkenntnisse über die internen Strukturen. Dieses kann
jedoch durch „gekaufte“ Insider kompensiert werden.
• Presse 2 : Die Presse kann auch ein Interesse daran haben, an sensible Informationen
zu kommen. Einerseits wäre es denkbar, dass sie die neuesten
Informationen über den Gesundheitszustand Prominenter verbreiten möchte
(„Yellow Press“). Andererseits könnte sie auf Probleme im Datenschutz
hinweisen 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 oder
Verändern von Daten Aufmerksamkeit zu erregen und ggf. anonym die Aufmerksamkeit zu genießen,
die ihnen zuteil wird.
20

• Staat 3 : Es ist auch denkbar, dass die Polizei oder Geheimdienste Zugriff auf
die Patientendaten erhalten möchten. Diese Dienste haben i.d.R. die Möglichkeit
die gewünschten Informationen mitzuschneiden und sind der mächtigste
„Angreifer“. Sie haben im Gegensatz zu den anderen jedoch die Möglichkeit
legal Zugriff auf diese Informationen zu erhalten. Deshalb können
wir den Staat als „Angreifer“ in dieser Arbeit unberücksichtigt lassen.
In einem geswitchten Netz (in dem Daten also nicht auf alle Computer des Segmentes
übertragen werden, sondern nur auf den Zielcomputer) ist ein direktes Mitlesen
der übermittelten Daten nicht ohne weiteres möglich. Wenn (wie heute üblich) die
Backboneverkabelung (welche die verschiedenen Gebäude oder Gebäudeteile miteinander
verbindet) auf Lichtwellenleitern (LWL-Kabeln) basiert, ist ein einfaches
(passives) Mitlesen der übertragenen Daten nicht ohne weiteres möglich. Für Angreifer
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 Zielsysteme,
die sensible Daten übermitteln, auf ein notwendiges Minimum zu beschränken
(das sind z.B. physische Sicherheit der Computer, Firewalls, Access Control
Lists auf Routern, eine sichere Konfiguration der Server und ggf. der Einsatz von
serverbasierten 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 Staaten
versuchen Zugriff zu erlangen (ohne mittels eines Rechtshilfeersuchens ihren Wunsch zu legalisieren),
ist das in etwa mit kriminellen Angriffen gleichzusetzen. Jedoch stehen ihnen deutlich bessere Mittel
zur Verfügung als einem „gewöhnlichen Kriminellen“.
21

5. Verwendete Algorithmen
Im Folgenden werden exemplarisch zwei Algorithmen vorgestellt, welche im Kapitel
8 (Pragmatisches Modell) verwendet werden. Als symmetrischer Algorithmus wird
Rijndael vorgestellt, der sicherlich in Zukunft eine herausragende Bedeutung erlangen
wird. Er wurde Ende 2001 vom U.S. Handelsministerium für den Einsatz freigegeben,
nachdem er in einer Ausschreibung das US National Institute of Standards
und Technology (NIST) als neuer Standard definiert worden war. Rijndael bzw. AES
(Advanced Encryption Standard) löst somit DES (bzw. Triple DES) ab. Als asymmetrischer
Algorithmus wird RSA vorgestellt, da er z.Zt. der Public-Key-Algorithmus
mit der größten Verbreitung ist (RSA wird in Produkten wie PGP, SSH, SSL
etc. 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 relevante
Grundlagen 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 gezeigten
Sä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 Konventionen:
:= {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
für das gilt: a − b = k ⋅ n.
a ≡ b ) genau dann, wenn es ein k ∈ gibt,
n
22

Das bedeutet: n teilt (a-b) (symbolisch: n|(a-b)). a heißt Rest von b mod n und b heißt
Rest von a modulo n.
Definition 2:
Es sei i ∈{1, 2, ..., n}, r 1 , r 2 , ..., r n
∈ .
{r 1 ,r 2 ,...,r n } heißt vollständige Menge von Resten (auch vollständige Residuenmenge)
modulo n, wenn es für alle a genau ein r i mit a ≡ r i gibt.
n
Für ein beliebiges n bildet 3
={0,1,...,n-1}eine vollständige Menge von Resten
modulo n und kann als Menge der Kongruenzklassen ≡
n
betrachtet werden und wird
als 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 = b
mod n. In
n
(mit a, b ∈
3
) werden die folgenden Verknüpfungen definiert:
a ⊕ b = (a +
b) mod n
a ⊗ b = (a ⋅ b) mod n.
Bekanntlich ist (
3
, ⊕ , ⊗ ) ein Ring und f
n
:( , + , ⋅)
- > (
n
, ⊕,
⊗)
, gegeben durch
f (a) = a mod n, ein Ringhomomorphismus.
n
Definition 4:
*
n
:= {a ∈
n
| ggt(a,n) = 1} heißt die reduzierte Menge der Reste (oder auch reduzierte
Residuenmenge) modulo n.
23

Definition 5:
Die Eulersche Funktion ϕ (n) bezeichnet die Elementanzahl der reduzierten Residuenmenge
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 f
n
(a) = a mod n wird ein Homorphismus
definiert.
f
n
:( ,
+ , ⋅)
- > (
n
, ⊕,
⊗)
Satz 2:
Es gelte ggt(a,n) = 1, dann gilt für alle i, j ∈
0
mit 0 ≤ i < j < n die Beziehung:
Folgerung:
(a ⋅ i) mod n ≠ (a ⋅
j) mod n
Es gelte ggt(a,n) = 1. Dann liefern ( a ⋅ i ) mod n mit i = 0,1,...,n-1 die Reste modulo n,
welche die Menge = { ( a ⋅ i ) mod n | i = 0,1,...,n-1} bilden.
n
Satz 3:
Es sei n ≥ 2 und es gelte ggt(a,n) = 1. Dann existiert genau ein x ∈ , 0 < x < n für
das ( a ⋅ x ) mod n = 1 gilt.
Damit ist x das multiplikative Inverse von a.
Satz 4:
*
n
modulo n eine multipli-
Es sei n ≥ 2. Dann ist die reduzierte Residuenmenge
kative Gruppe.
24

Satz 5:
Es sei p eine Primzahl. Dann gilt:
i) ϕ (p) = p-1.
ii) ϕ (p k ) = p k-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:
a p-1 mod p = 1.
Satz 7:
Es seien e, d, n
Dann gilt:
Folgerung:
∈ Mit (ed) mod ϕ (n) = 1 und M ∈ [0, n-1] mit ggt(M,n) = 1.
(M e mod n) d mod n = M.
Da e und d symmetrisch sind, ist das Potenzieren mit e und d kommutativ und es gilt:
(M d mod n) e mod n = M de mod n = M.
Deshalb ist es möglich M e mod n = C als Verschlüsselung und C d mod n = M als
Entschlüsselung zu betrachten.
25

Galois-Felder und Polynome in Körpern
Galois-Felder ( oder GF(p)) sind endliche Körper mit der (Prim-) Charakteristik)
*
p
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 die
Addition 3+4 folgendermaßen durchgeführt:
3+4 mod 5 = 7 mod 5 = 2.
In einem Galois-Feld sind die Operationen Addition, Subtraktion, Multiplikation und
Division (mit Ausnahme durch 0) wohldefiniert. Dort ist die 0 das neutrale Element
bezüglich Addition und die 1 das neutrale Element bezüglich der Multiplikation. Für
jede Zahl ungleich 0 existiert ein inverses Element. Das Rechnen in diesen Feldern
ist 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örper
sind Addition und Subtraktion identisch und lassen sich effizient durch eine
XOR-Verknüpfung realisieren.
Es ist möglich ein Polynom f(x) des Grades n mit Koeffizienten aus dem Galois-Feld
GF(2) darzustellen:
f(x) = f
n
⋅ x
n
+
... + f
2
⋅ x
2
+ f
1
⋅ x + f , mit f ∈{0,1},
0 ≤ i ≤ n.
0
i
Die Addition der Polynome f(x) und g(x) vom Grad n wird wie folgt realisiert:
n
2
f(x) + g(x) = (f
n
+ g
n
)x + ... + (f
2
+ g
2
)x + (f1
+ g1)x
+ (f
0
+ g
0
)
.
Die Menge aller Polynome über GF(2) bildet einen Ring P(GF(2)). Analog zu
n
ist
es möglich die Operationen + und · durch ⊕ und ⊗ modulo eines bestimmten Polynoms
p(x) (des Grades m) zu ersetzen und erhält einen Ring von Polynomen des
Grades < m P(GF(2))/ (p(x)) .
Das Galois-Feld GF(2) lässt sich erweitern, indem 2 mit m potenziert wird, geschrieben
GF(2 m ). Wir fassen GF(2 m ) als die Menge aller m-Tupel von Elementen aus
GF(2) auf. Ein solches Tupel kann aufgefasst werden als Koeffizienten-Tupel eines
Polynoms vom Grad < m.
Polynome des Grades 2 mit Koeffizienten aus GF(2) (also 0 und 1) können durch
GF(2 3 ) dargestellt werden. Die Koeffizienten des Polynoms werden also (in diesem
Beispiel) von links gesehen hintereinandergeschrieben. Das Polynom:
f(x) = 1⋅
x
2
+ 1⋅
x + 0 = x
2
+ x
lässt sich durch das Element (110) aus GF(2 3 ) darstellen.
26

Alle in GF(2 3 ) enthaltenen Polynome sind:
0, 1, x, x+1, x 2 , x 2 +1, x 2 +x, x 2 +x+1.
Ein Polynom heißt irreduzibel, wenn es nicht das Produkt zweier Polynome geringeren
Grades über demselben Körpers ist (es ist dann sozusagen „prim“). Ein solches
Polynom über GF(2) ist beispielsweise:
f(x) = x 8 +x 4 +x 3 +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 die
Multiplikation zweier Elemente aus GF(2 m ) durch Multiplikation der zugehörigen
Polynome modulo p(x). Da p(x) irreduzibel ist, gibt es in GF(2 m ) zu jedem (von 0
verschiedenen) Element ein inverses Element.
Im Fall GF(2 8 ) werden die Koeffizienten häufig nicht in binärer, sondern in hexadezimaler
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 Algorithmus,
der mit 128, 192 oder 256 Bit Schlüssellänge und 128, 192 oder 256 Bit
Blocklänge betrieben werden kann. AES ist ein einfach zu implementierender Algorithmus,
der mit dem Ziel entworfen wurde, gegen bekannte Angriffsverfahren (beispielsweise
differentielle oder lineare Kryptoanalyse) resistent zu sein, und effizient
sowohl in Software als auch in Hardware implementiert werden kann. Beschrieben
wurde 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(2 8 ) aufgefasst, in dem die Multiplikation
modulo des irreduziblen Polynoms x 8 +x 4 +x 3 +x+1 durchgeführt wird.
Im Folgenden bezeichne M die Nachricht (bzw. den aktuellen Status während einer
Runde), L Block die Länge des Datenblockes (in Bits), L Key die Länge des Schlüssels
(in Bits), N V die Anzahl der Vektoren (Bytes) des Datenblocks, N b die Anzahl der
Spalten der Daten-Matrix M, N k die Anzahl der Spalten der Schlüssel-Matrix und N r
die Anzahl der Runden.
27

128 192
Im Folgenden sei M die 128, 192 oder 256 Bit lange Nachricht (aus
2
,
2
oder
256
2
), die verschlüsselt werden soll. Diese wird in 8-dimensionale Vektoren (aus
8
2
) aufgeteilt, die im folgenden als Bytes bezeichnet werden. In Abhängigkeit von
der Blocklänge ergeben sich die folgende Anzahl von Bytes:
Blocklänge
(L Block )
Anzahl Bytes
(N v )
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 einer
variablen Spaltenanzahl (N b = N v /4) betrachtet. Es ergeben sich also 4, 6 oder 8
Spalten.
Der (Original-) Schlüssel K wird (analog der Nachricht M) ebenfalls als Matrix dargestellt.
Jedoch wird nicht in jeder Runde derselbe Schlüssel verwendet, sondern in
jeder Runde ein anderer, der dieselbe Länge wie der Nachrichtenblock hat (siehe
auch RoundKey – Erzeugung) und aus K generiert wird.
Wie bei vielen symmetrischen Algorithmen werden auch bei AES die einzelnen Operationen
mehrmals in sogenannten Runden durchgeführt, damit jedes Bit des Chiffretextes
von möglichst vielen Bits des Quelltextes und möglichst vielen Bits des
Schlüssels abhängt und so quasi zufällig erscheint.
Die Anzahl der Runden (N r ) ist sowohl von der Block- als auch von der Schlüssellänge
abhängig. Die Rundenanzahl ist in der folgenden Tabelle dargestellt:
28

Rundenanzahl
N r
Blocklänge
Schlüssellänge
(L Key )
128
(N b =4)
192
(N b =6)
256
(N b =8)
128 (N k =4) 10 12 14
192 (N k =6) 12 12 14
256 (N k =8) 14 14 14
Tabelle 5-2: Rundenanzahl [DaRi1999]
Die Verschlüsselung wird durch die folgenden Operationen in insgesamt N r Runden
durchgeführt. Die Anzahl der Spalten der Datenmatrix ist N b , die Anzahl der Spalten
der Schlüsselmatrix ist N k . Der verwendete Schlüssel wird nur in der Operation
AddRoundKey verwendet. Alle anderen Operationen sind unabhängig vom Schlüssel.
Damit die Diffusion in jeder Runde erhöht wird, wird in jeder Runde ein eigener
Runden-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 zu
berechnen.
Um eine Known Plaintext Attack zu erschweren (die beispielsweise durch standardisierte
Bytefolgen bei bestimmten Datentypen vorkommt) wird vor der ersten Runde
(sozusagen in der Runde 0) der Originaldatenblock M mit den ersten Bits des Rundenschlüssels
(RK) mittels XOR verknüpft.
N r -1 mal werden die folgenden Operationen ausgeführt, die im Folgenden erläutert
werden:
• 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 insgesamt
L Block · (N r +1) Schlüssel Bits benötigt (bei 192 Bit Blocklänge und 12 Runden also
29

N b 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:
Zeile 1:
Zeile 2:
Zeile 3:
keine Änderung
verschiebe die Bytes um Z1 Positionen zyklisch nach links
verschiebe die Bytes um Z2 Positionen zyklisch nach links
verschiebe die Bytes um Z3 Positionen zyklisch nach links
Im Fall von 192 Bit Blocklänge (N b =6) und mit Buchstaben als Bytes sieht das dann
folgendermaßen aus:
a
g
m
s
b
h
n
t
c
i
o
u
d
j
p
v
e
k
q
w
f
l
r
x
ShiftRow
a
h
o
v
b
i
p
w
c
j
q
x
d
k
r
s
e
l
m
t
f
g
n
u
ShiftRow
MixColumn - Transformation
Die N b Spaltenvektoren (für N b =4: a 0 , a 1 , a 2 , a 3 ) von M bestehen jeweils aus 4 Bytes
und werden als Polynome über GF(2 8 ) betrachtet und mit dem festen Polynom c(x) =
03h·x 3 + 01h·x 2 + 01h·x + 02h (beim Entschlüsseln mit dem Inversen Polynom d(x)
= 0Bh·x 3 + 0Dh·x 2 + 09h·x + 0Eh) modulo x 4 +1 multipliziert (die Koeffizienten sind
jeweils in Hexadezimalschreibweise angegeben).
Die Polynommultiplikation modulo eines festen Polynoms lässt sich auch als Matrizenmultiplikation
darstellen, bei der die Koeffizienten (von rechts nach links) in die
unterste Zeile der Matrix geschrieben und jeweils in der darüber liegenden Zeile um
eine Position zirkulär nach links verschoben werden:
31

0
02
b1
=
01
b2
01
3
b
03
03
02
01
01
01
03
02
01
01
a0
01
×
a1
03
a2
02
3
a
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 RK 192 -RK 383, in der 2.
RK 384 -RK 575 usw.). Die Addition erfolgt als Matrizenaddition, die mittels eines XOR
realisiert werden kann.
Im Fall von N b =6 (192 Bit Blocklänge) sieht das folgendermaßen aus:
a
a
a
a
0,0
1,0
2,0
3,0
a
a
a
a
0,1
1,1
2,1
3,1
a
a
a
a
0,2
1,2
2,2
3,2
b
b
b
b
a
a
a
a
0,0
1,0
2,0
3,0
0,3
1,3
2,3
3,3
a
a
a
a
b
b
b
b
0,4
1,4
2,4
3,4
0,1
1,1
2,1
3,1
a
a
a
a
b
b
b
b
0,5
1,5
2,5
3,5
0,2
1,2
2,2
3,2
b
b
b
b
0,3
1,3
2,3
3,3
k
⊕
k
k
k
0,0
1,0
2,0
3,0
b
b
b
b
0,4
1,4
2,4
3,4
k
k
k
k
0,1
1,1
2,1
3,1
b0,5
b
1,5
=
b2,5
b3,5
k0,2
k
k
k
1,2
2,2
3,2
k
k
k
k
0,3
1,3
2,3
3,3
k
k
k
k
0,4
1,4
2,4
3,4
k
k
k
k
0,5
1,5
2,5
3,5
AddRoundKey
32

Für den Fall, dass die Blocklänge 128 Bit ist (N b =4), sieht der Ablauf einer Runde so
wie 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 Operationen
bearbeitet.
Abbildung 5-1: AES-Verschlüsselung [Sav2001]
5.2.2. RSA
Der Public Key Algorithmus RSA wurde 1977 von Rivest, Shamir und Adleman
entworfen und ist dazu in der Lage sowohl für Verschlüsselung als auch zur digitalen
Signatur eingesetzt zu werden.
Die Basis des RSA-Algorithmus besteht darin, dass es mit den heutigen Computern
einfach und schnell möglich ist, große Zahlen mit mehreren hundert Dezimalstellen
zu multiplizieren, es jedoch bisher unmöglich ist (in einer akzeptablen Zeit, s.u.) die
Primfaktoren einer ebenso großen Zahl, welche das Produkt zweier großer Primzahlen
ist, herauszufinden. In [SchB1996] schreibt Bruce Schneier, dass zur Faktorisierung
einer 2048-Bit-Zahl, wie sie für Public-Key-Systeme eingesetzt wird, mit einem
allgemeinen Zahlenkörpersieb 3·10 11 MIPS-Jahre und mit einem speziellen Zahlenkörpersieb
3·10 7 MIPS-Jahre erforderlich sind. Das heißt, ein Computer, der eine
Million Rechenoperationen in der Sekunde durchführt, 3·10 11 bzw. 3·10 7 Jahre zur
Lö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 Beispiel:
Der von IBM Ende 2001 vorgestellt Hochleistungscomputer p690 („Regatta“)
kann mit bis zu 32 POWER-4 CPUs ausgestattet werden. Die Taktfrequenz
jeder CPU beträgt 1,3 GHz. IBM gibt in [IBM2001] an, dass eine CPU bis zu
8 Befehle pro Taktzyklus auszuführen in der Lage ist und durchschnittlich 5
Befehle pro Zyklus abschließt.
33

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 5
Befehlen pro Zyklus) bzw. 332.800 MIPS (bei 8 Befehlen pro Zyklus) für ein
32-CPU System.
Das bedeutet, dass eine p690 mit 32 CPUs ca. 1,9 Milliarden Jahre (5 Befehle
pro Zyklus) bzw. ca. 1,2 Milliarden Jahre (8 Befehle pro Zyklus) benötigt, um
durch den Einsatz des speziellen Zahlenkörpersiebes (welches jedoch bei den
in der Regel verwendeten Schlüsseln nicht eingesetzt und eher als optimistisch
angesehen werden kann) einen einzigen 2048-Bit-Schlüssel durch Faktorisierung
zu brechen. Bei dem Einsatz des allgemeinen Zahlenkörpersiebes
sind die Zeiten noch erheblich höher (ca. Faktor 10 7 ).
Da dieser Computer (mit nur 16 anstatt der hier angenommenen 32 CPUs) für
ca. 450.000 US-$ zu erhalten ist [iX2002-03], handelt es sich hier auch um
ein sehr teures Unterfangen.
Selbst wenn man 24 dieser 32-CPU-Computer miteinander verbindet (wie auf
der CeBIT 2002 für das Projekt Hochleistungsrechenzentrum Nord (HLRN)
angekündigt), dauert die Berechnung noch immer ca. 79 Millionen Jahre (5
Befehle pro Zyklus) bzw. 50 Millionen Jahre (8 Befehle pro Zyklus) bei
Anschaffungskosten von ca. 20 Millionen Euro.
In vielen Public-Key-Systemen, wie beispielsweise in PGP, wird der RSA-Algorithmus
verwendet, der im Folgenden beschrieben wird.
Die Grundlage von RSA ist die Erzeugung des Schlüsselpaares. Dazu wird der folgende
Algorithmus verwendet. Es sei E Alice die Verschlüsselung mit Alices öffentlichen
Schlüssel, D Alice die Entschlüsselung mit Alices privatem Schlüssel (D Bob und
E Bob 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 eindeutige
Inverse zu e in
*
ϕ (n)
.
Alice erhält als öffentlichen Schlüssel das Tupel (e,n) und als privaten Schlüssel
(d,n).
34

Wenn nun Bob eine Nachricht M an Alice senden möchte, verwendet er, nachdem er
den öffentlichen Schlüssel von Alice (e,n) erhalten und die Authentizität überprüft
hat, 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 E Alice (M) = M e mod n = C.
c) Sende C an Alice.
ii. Alice
Berechne D Alice (C) = C d 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 D Alice (M) = M d mod n = C.
c) Sende C an Bob.
ii. Bob
Berechne E Alice (C) = C e mod n = M.
Wenn M einen sinnvollen Text ergibt, betrachtet Bob die Nachricht als authentisch
von Alice versand.
Es ist ebenfalls möglich die Verschlüsselung und Signatur zu kombinieren. Dazu
müssen Alice und Bob jeweils ein eigenes Schlüsselpaar besitzen. Wenn Alice nun
eine signierte Nachricht M verschlüsselt an Bob sendet, führt sie vorher die folgenden
Schritte aus:
E Bob (D Alice (M)) = C.
Bob erhält dann durch Anwendung von
E Alice (D Bob (C)) = M
die signierte Originalnachricht, die Alice gesendet hat.
Das funktioniert jedoch nur dann, wenn der für E Bob verwendete Modulus n größer
ist als der davon verschiedene für D Alice verwendete Modulus n. Falls das nicht der
Fall ist, funktioniert dieses Verfahren nicht, da korrekte Signaturen fälschlicherweise
als fehlerhaft geliefert würden.
35

Dieses Problem kann dadurch gelöst werden, dass jeder Nutzer zwei Schlüsselpaare
erzeugt: eines für die Signatur und eines für die Verschlüsselung. Dabei ist darauf zu
achten, dass der Modulus n Enc für jeden Verschlüsselungsschlüssel größer ist als der
Modulus n Sig für jeden verwendeten Signaturschlüssel. Damit das in einem komplexen
Umfeld funktioniert, muss es ein t geben, für das gilt:
n Sig < t ≤ n Enc
Es seien Enc Alice , Dec Alice die Ver- und Entschlüsselunsgschlüssel und Sig Alice und
Ver Alice die Signier- und Überprüfungsschlüssel von Alice (Bob analog). Dann lassen
sich das Signieren und Verschlüsseln einer Nachricht M von Alice an Bob folgendermaßen
umsetzen:
Enc Bob (Sig Alice (M)) = C.
Bob erhält dann durch Anwendung von:
Ver Alice (Dec Bob (C)) = M.
Wenn eine Nachricht verschlüsselt werden soll, die länger als der Modulus des
Schlüssels ist, muss sie in Blöcke aufgeteilt werden und diese müssen dann einzeln
verschlüsselt werden.
In der Praxis wird RSA jedoch meistens nicht direkt zum Verschlüsseln der Nutzdaten
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 Nachricht
mittels RSA signiert, sondern eine kryptographische Prüfsumme über die Nachricht
gebildet, diese signiert und von Alice zusammen mit der Nachricht an Bob übermittelt.
Der Empfänger berechnet dann mit demselben Algorithmus ebenfalls die Prüfsumme
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 der
Authentizität, wenn es keinen sicheren Kanal gibt, auf dem der öffentliche Schlüssel
ausgetauscht und die Identität des Absenders sichergestellt werden kann. Um das zu
erreichen kann ein Dritter, beispielsweise Charlie, dem sowohl Alice als auch Bob
vertrauen, die Echtheit der Schlüssel von Alice durch das Signieren des Paares
(E Alice , „Dieser Schlüssel gehört Alice“) zertifizieren (natürlich auch analog den
Schlüssel von Bob). In diesem Beispiel wäre Charlie eine CA und es gilt das in 4.3
(Zertifizierungsinfrastrukturen) Geschriebene.
36

6. Ausgewählte Kommunikationsprozesse
„Sicherheit ist ein Prozess und kein Produkt."
[Bruce Schneier, Secrets & Lies]
Im Folgenden werden exemplarisch einige Kommunikationsanwendungen beschrieben,
die Einsatzmöglichkeiten für verschiedene Verfahren geben. Die Beispiele wurden
so ausgewählt, dass sie einen großen und häufig vorkommenden Bereich der
Kommunikation abdecken bzw. strukturgleich auf andere Prozesse übertragen werden
können.
Die Darstellung gliedert sich in zwei Teile. Im ersten Teil wird der Prozess allgemein
beschrieben und im zweiten Teil (siehe Tabelle 7-2 (Auswahl kryptographischer
Verfahren)) sind charakteristische Parameter des Prozesses benannt. Dadurch ist es
möglich, andere – hier nicht genannte - Prozesse zu kategorisieren und Ähnlichkeiten
zu hier beschriebenen Prozessen zu erkennen, um das geeignete Verfahren leicht auswählen
zu können.
6.1. Struktur der Betrachtung
Um die Analyseergebnisse der im Folgenden vorgestellten Prozesse auch auf andere
Prozesse übertragen zu können, wird zu jedem Prozess eine Tabelle mit den (für die
Kryptographie signifikanten) charakteristischen Merkmalen aufgestellt. Diese
Merkmale schließen sich gegenseitig nicht aus. Die in der Tabelle verwendeten
Kürzel sind im folgenden in [] eingeklammert. Die Ergebnisse der Analyse lassen
sich dann auf ähnliche Prozesse, welche dieselben charakteristischen Merkmale
haben, leicht adaptieren.
Netz-Umgebung:
Die Umgebung, in welcher die Datenübertragung stattfindet, ist ein relevantes Kriterium
für die Auswahl der Verschlüsselung. Wenn beispielsweise zwei im Rechenzentrum
direkt nebeneinander stehende Computer über eine direkte Verbindung
(Crossconnect Kabel) verbunden sind, ist das Risiko, dass die Übermittlung abgehört
werden kann, sehr gering unter anderem schon deshalb, weil der physische Zugang
stark reglementiert werden kann. Werden die Daten hingegen über das Internet übertragen,
gibt es sehr viele Punkte, an denen die Daten mitgelesen werden können.
37

Merkmale der Netz-Umgebung:
• Kommunikation innerhalb eines physisch gesicherten Bereichs (z.B. gesicherter
Rechnerraum, in dem sowohl die Netzwerkkomponenten als auch
die 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 und
Web-Servers mittels HTTP durchgeführt, ist es relativ einfach, die Übertragung
durch den Einsatz von HTTPS zu verschlüsseln und auch zu authentisieren. Wenn
die Übertragung lediglich mit Standardprogrammen wie z.B. FTP erfolgt, ist es ggf.
möglich, zwischen der Erzeugung der Daten und der Übertragung (bzw. dem Empfang
und der Verarbeitung) Zwischenstufen zur Authentisierung oder Verschlüsselung
einzubauen. Wenn der Prozess proprietäre Protokolle verwendet, ist eine für die
Anwendung 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) gesichert
werden. [Transparent]
Kommunikationspartner:
Die Kommunikation kann direkt zwischen zwei oder mehr Menschen beispielsweise
E-Mail erfolgen, zwischen einem Menschen und einem Programm (z.B. Abfrage von
Web-Seiten) oder auch zwischen zwei Programmen (z.B. Übertragung von Daten des
Labors zu einer Klinik).
38

Merkmale der Kommunikationspartner:
• Die Kommunikation erfolgt zwischen Menschen (Mensch – Mensch, z.B.
Mail). [M-M]
• Die Kommunikation erfolgt zwischen einem Menschen und einem Programm
(Mensch – Programm, z.B. Webzugriffe). [M-P]
• Die Kommunikation erfolgt zwischen Programmen (Programm – Programm).
[P-P]
Bekanntheit des Kommunikationspartners:
Es ist wesentlich einfacher sich von der (elektronischen) Authentizität eines bekannten
Kommunikationspartners zu überzeugen als bei einem Unbekannten. Beim ersten
Beispiel kann der Schlüsseltausch manuell erfolgen oder ggf. per Telefon verifiziert
werden. Bei Unbekannten ist der Einsatz einer Zertifizierungsinstanz angeraten, der
beide 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üsselung
eingesetzt werden. So ist sicherlich die Tatsache, dass jemand Patient in
einem Krankenhaus war, weniger sensitiv, als die Tatsache, dass er HIV-positiv ist.
Aus der Einstufung heraus wäre es möglich, unterschiedlich starke Verschlüsselungen
zu wählen. Es sollte immer mit einer möglichst starken Verschlüsselung gearbeitet
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, wer
sie erstellt hat? Eine per E-Mail versandte Einladung zu einem Meeting muss in den
seltensten Fällen signiert werden. Eine per Internet-E-Mail versandte Diagnose eines
Arztes aus einem anderen Krankenhaus muss (siehe Kapitel 3 (Rechtlicher Rahmen
der Kryptographie in Deutschland)) genauso signiert werden wie ggf. im Vorfeld
übermittelte medizinische Daten (beispielsweise Laborwerte).
39

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 durch
den Aufruf eines externen Programms (z.B. FTP) übertragen werden, ist es ggf.
möglich, eine Zwischenstufe einzubauen, welche die gewünschten
kryptographischen 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 beliebige
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 keinen
Sinn machen, wenn durch die Verschlüsselung die verfügbare Bandbreite nicht
vollständig ausgeschöpft werden kann. Ebenfalls kann es relevant sein, wie groß die
Verzögerung in der Datenübermittlung ist. Wenn dadurch z.B. Telefon- oder Videokonferenzen
über TCP/IP beeinträchtigt werden, sollten leistungsfähigere Verschlüsselungskomponenten
eingesetzt werden.
40

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 verschlüsselt
gespeichert? Sofern nicht nur die Übertragung verschlüsselt wird, sondern
auch die Daten verschlüsselt archiviert werden, ist es notwendig Vorkehrungen für
den 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 der
automatischen Übertragung von Daten zwischen zwei Instituten (z.B. einem Labor
und einer Klinik) eingesetzt werden können. Es handelt sich dabei in der Regel um
Untersuchungsergebnisse, die durch einen speziellen Labor-Computer ermittelt und
auf ein Unix-System innerhalb des Labors übertragen wurden. Anschließend werden
sie auf das Unix-System in einer Klinik per FTP übertragen, um dann weiterverarbeitet
zu werden. Unabhängig vom Einsatz kryptographischer Verfahren ist es wünschenswert
automatisch zu überprüfen, ob die Daten das Zielsystem erreicht haben
um sie gegebenenfalls erneut automatisch zu übermitteln.
Zusätzlich zur elektronischen Übermittlung werden die Laborwerte auch in der Zielklinik
ausgedruckt. Da dieser Ausdruck nicht von einem Arzt unterschrieben werden
muss, ist eine Signatur der per FTP übertragenen Daten nicht aus rechtlichen Gründen
notwendig. Es ist sinnvoll, sie mit einem Signaturschlüssel des Labors zu versehen,
damit die Authentizität und die fehlerfreie Übermittlung sichergestellt werden
können.
41

Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
LAN
Standard, Transparent
P-P
bekannt
hoch
irrelevant, erwünscht
Ja
Ja
irrelevant
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 der
MHH zu koppeln, ohne dass Endanwender in ihren Möglichkeiten eingeschränkt
werden und alle Klinik-Anwendungen nutzen können, als wären sie auf dem Campus.
Das bedeutet auch, dass gegebenenfalls vertrauliche Daten über ungesicherte
Verbindungen übermittelt würden. Als Beispiele für diese Anwendungen könnte z.B.
die Anbindung des Oststadtkrankenhauses (welches teilweise zur MHH gehört) oder
einer Außenstelle in der Walderseestraße dienen.
Da es nicht möglich sein wird, alle Anwendungen auf den Einsatz von Kryptographie
umzustellen, wird es erforderlich sein, die Leitung zu verschlüsseln. Anschließend
sind die Anwendungen quasi auf demselben Sicherheitsniveau wie auf dem Campus
und eine gesonderte Betrachtung der Anwendungen ist nicht erforderlich.
Besonders wichtig ist die Verschlüsselung, wenn die Datenübermittlung nicht über
Kabel, sondern per (Richt-) Funk oder mittels optischer „Laser Links“ realisiert wird.
Denn ein Funksignal kann leichter unbemerkt abgehört werden als eine kabelgebundene
Verbindung.
42

Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Corporate LAN
Transparent
M-M, M-P, P-P
bekannt
hoch
irrelevant
nicht relevant
nicht relevant
relevant
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 es
wünschenswert sein, eine (durch einen Firewall gesicherte) Verbindung über das
Internet (bzw. GWIN) aufzubauen, über die beispielsweise Zugriffe auf Radiologische
Systeme geboten werden, welche eine hohe Bandbreite erfordern. Ebenso wie
bei der direkten Verbindung zu einer Außenstelle ist hier die Verschlüsselung der
Leitung über das Internet wichtig. Anwendungen werden hier nicht gesondert
betrachtet. Die Übermittlung von Behandlungsdaten an die Krankenkassen gemäß
Gesundheitsstrukturgesetz ([MDJP1998]) könnte anstatt über ISDN-Verbindungen
über einen solchen VPN-Tunnel erfolgen.
Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Internet
Transparent
M-M, M-P, P-P
unbekannt
hoch
irrelevant
nicht relevant
nicht relevant
relevant
Nein
Tabelle 6-3: Internetverbindung zu einem anderen Krankenhaus
43

6.2.4. Gesicherte Einwahl über ISDN, Modem oder Internet
Durch den immer stärker werdenden Einsatz der Computer wird es erforderlich, auch
von außerhalb einen transparenten Zugriff auf die Komponenten der MHH zu erhalten.
Ebenso kann es vorkommen, dass z.B. im Bereitschaftsdienst Zugriff auf wichtige
Systeme benötigt werden. Hierbei werden sensible Daten, oder zumindest
Benutzerkennungen und Passworte, übertragen, die unbedingt geschützt werden
müssen. Im Gegensatz zu den Festverbindungen handelt es sich hier um eine Vielzahl
von dynamisch aufgebauten Verbindungen, die möglichst ohne aufwendige
Hardware auf der Gegenseite funktionieren sollten. Ebenso wie bei der direkten Verbindung
zu einer Außenstelle ist hier die Verschlüsselung der Leitung über Modem,
ISDN oder das Internet wichtig. Anwendungen werden hier nicht gesondert betrachtet.
Im Prinzip ist eine solche Verbindung nichts anderes als ein VPN zwischen dem
einzelnen Anwender und der MHH mit dem Unterschied, dass der Anwender keinen
eigenen Firewall hat.
Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Internet
Transparent
M-M, M-P
bekannt
hoch
irrelevant
nicht relevant
nicht relevant
relevant
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 Zugriffe
auch wirklich auf den richtigen Server gehen. Ebenfalls sollten die Daten möglichst
verschlüsselt werden. Es ist damit beispielsweise möglich den Zugriff auf Interna nur
für Mitarbeiter bestimmter Kliniken oder Einrichtungen zu ermöglichen.
Dadurch ist es auch möglich, für berechtigte Externe über das Internet Ergebnisse
abrufbar zu machen. So könnte beispielsweise der Befundbrief der MHH von einem
niedergelassenen Arzt über das Internet abgerufen werden, nachdem er sich mit seinem
Client (PC) dem MHH-Server gegenüber authentisiert hat, dass für einen siche-
44

en Zugriff auf solch sensible Daten aus dem Internet noch mehr zu tun ist als nur
den Anfordernden eindeutig zu identifizieren und die Daten zu verschlüsseln, würde
den Rahmen dieser Arbeit sprengen und basiert auch weniger auf kryptographischen
Anwendungen, als auf allgemeiner IT-Sicherheit.
Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Sicher, LAN, Corporate
LAN, Internet
Standard
M-P
bekannt, unbekannt
mittel, hoch
erwünscht
Nein
Nein
relevant
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 von
klinischen Studien geht. Dazu wird in der MHH ein Server aufgestellt, der aus dem
Internet erreichbar ist und in den die Ergebnisse eingegeben werden. Die hier übermittelten
Daten sollen (trotz der Anonymisierung) nicht von Außenstehenden gelesen
werden können und unverändert in der MHH ankommen.
45

Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Internet
Spezifisch, Standard
M-P
bekannt
hoch
erwünscht, notwendig
Ja, Nein
Ja
relevant
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 der
täglichen Arbeit wird, desto mehr wird auch der Bedarf zur Übermittlung von medizinischen
Daten (Befunden, klinischen Werten oder Multimedia-Daten) wachsen.
Daraus ergibt sich die Notwendigkeit, dass die Inhalte der Mails verschlüsselt und
signiert werden können.
Nach [MeKü2000a] und [MeKü2000b] ist der Einsatz von E-Mail zur Kommunikation
über das Internet nur zulässig, wenn die Mails verschlüsselt werden. Da es keine
getrennten Mail-Systeme in der MHH für interne und externe Mails gibt (d.h. durch
das interne System wären nur Mitarbeiter der MHH und durch das externe wären nur
externe Adressen zu erreichen), ist das Risiko, versehentlich Mails mit Patientendaten
ohne Verschlüsselung in das Internet zu senden, zu groß.
Deshalb sollte grundsätzlich bei der Übermittlung medizinischer Daten (auch innerhalb
der MHH) eine Verschlüsselung vorgenommen werden. Man könnte evtl. sogar
soweit gehen, dass grundsätzlich alle Mails verschlüsselt werden müssen und der
Versand einer unverschlüsselten Mail grundsätzlich vom Absender bestätigt werden
müsste, um das Risiko des versehentlich unverschlüsselten Versandes von Patientendaten
zu reduzieren.
Der Einsatz von Signaturen ist in all den Fällen vorzusehen, in denen aufgrund einer
E-Mail Aktionen veranlasst werden oder auch deshalb unterbleiben, welche die
Gesundheit des Patienten beeinträchtigen können. Wer wäre haftbar, wenn ein Arzt
die Verabreichung eines wichtigen Medikamentes unterlässt, weil die per Mail
übermittelten Laborwerte einen Übermittlungsfehler enthielten, der anstatt eines
pathologischen einen normalen Wert enthielt? Durch den Einsatz einer Signatur
könnten solche Übermittlungsfehler sicher erkannt werden.
46

Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
LAN
Standard
M-M, M-P
bekannt
hoch
notwendig
Nein
Ja
irrelevant
Ja
Tabelle 6-7: Gesicherter interner Mailversand
6.2.8. Gesicherter externer Mailversand
Der Einsatz von Kryptographie beim Versand von Patientendaten über das Internet
ergibt sich zwingend aus [MeKü2000a]. Im Gegensatz zum internen Mailversand
kommt beim externen Mailversand hinzu, dass die Sicherstellung der Authentizität
problematischer ist und ohne eine Public Key Infrastructure (PKI), die nicht nur auf
die MHH beschränkt ist, praktisch nicht weiträumig durchgeführt werden kann.
Ebenfalls kann es sich als problematisch erweisen, dass im Gegensatz zum internen
Mailversand beim externen Mailversand verschiedene Mail-Clients eingesetzt werden
und zueinander nicht vollständig kompatibel sind.
47

Netz-Umgebung
Art der Kommunikation
Kommunikationspartner
Bekanntheit des Kommunikationspartner
Sensitivität
Rechtliche Verbindlichkeit/Beweisbarkeit:
Anpassung der Systeme möglich
Einsatz von Spezialsoftware möglich
Performance
Archivierung
Internet
Standard
M-M, M-P
unbekannt
hoch
notwendig
Nein
Nein
irrelevant
Ja
Tabelle 6-8: Gesicherter externer Mailversand
48

7. Soll-Modell
7.1. Vorbemerkungen
In diesem Kapitel wird ein Modell entworfen, welches die im vorigen Kapitel vorgestellten
Kommunikationsprozesse kryptographisch sichert. Dieses Modell stellt in
etwa das dar, was wünschenswert wäre – unabhängig davon, ob es in dieser Form
bereits zu realisieren ist oder ob es aufgrund von Inkompatibilitäten der momentan
verfügbaren Software noch nicht möglich ist. Eine eher praktikable Lösung, die auch
für einzelne Prozesse eine befriedigende Lösung bildet, wird im nächsten Kapitel
vorgestellt.
Es wäre wünschenswert alle Kommunikationsprozesse in einen einheitlichen Rahmen
zu integrieren. Dieser Rahmen könnte etwa folgendermaßen aussehen:
Alle an der Kommunikation beteiligten Personen und Systeme erhalten ein asymmetrisches
Schlüsselpaar, welches durch eine CA zertifiziert wird. Die öffentlichen
Schlüssel und Zertifikate liegen auf einem zentralen Server und können von allen
Beteiligten (ggf. nach einer weiteren Authentisierung bei externen Anfragen) direkt
angerufen werden.
Vor jeder Kommunikation wird der betreffende aktuelle Verschlüsselungsschlüssel
des Kommunikationspartners heruntergeladen bzw. geprüft, ob das Zertifikat noch
gültig ist und nicht zurückgerufen wurde (siehe Abbildung 7-2 (Modell der
Schlüssel- und Datenübermittlung)). Die CA ist dazu in der Lage, Zertifikate für alle
verwendeten Schlüsseltypen zu erstellen, sowohl für die Mailverschlüsselung, Web-
Server- und Web-Client-Zerifikate als auch für andere Verfahren, die in den
beschriebenen Prozessen verwendet werden.
Die privaten Schlüssel werden auf einem Wechselmedium gehalten, sodass sie beispielsweise
bei einem Diebstahl des Computers nicht mit entwendet werden. Als
Wechselmedium könnte eine SmartCard dienen, welche beispielsweise in einem
„intelligenten“ Kartenleseterminal steckt, in das der Benutzer eine PIN eingibt, um
den Schlüssel freizugeben.
In [MüPf1997] schreibt Arndt Weber, dass bei dem Einsatz eines herkömmlichen
Computers ein gewisses Restrisiko vorhanden ist, dass auf dem Computer eine
manipulierte Software (beispielsweise durch einen unbemerkt eingespielten Trojaner)
den privaten Schlüssel kopiert oder die zu unterzeichnenden Daten manipuliert.
Als Alternative schlägt er vor, sogenannte „sichere Geräte“ zu verwenden, die
sowohl die Schlüssel des Anwenders enthalten als auch die Ver- bzw. Entschlüsselung
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
49

Dokument signiert. Die Kommunikation mit dem stationären Computer könnte dann
beispielsweise per Kabel, Infrarot oder Funk (Bluetooth, Wireless LAN o.ä.) realisiert
werden. Es ist jedoch darauf zu achten, dass dadurch nicht neue Sicherheitsprobleme
entstehen.
Ein weiterer Vorteil dieser „sicheren Geräte“ wäre die Tatsache, dass sie deutlich
weniger komplex sind als herkömmliche PCs. Auf ihnen würde nur die spezielle
Software für kryptographische Anwendungen laufen. Dadurch wäre die Überprüfung
auf ein korrektes Verhalten einfacher möglich. Ebenfalls könnte man in die Geräte
zur Überprüfung der Identität des Nutzers biometrische Daten wie beispielsweise
einen Fingerabdruck speichern anstatt den Schlüssel nur per Passwort oder PIN zu
sichern.
Bei der Verschlüsselung der Kommunikation muss auch zwischen einer Verschlüsselung
auf Netzwerk/Leitungsebene, die sowohl für die Anwendung als auch für den
Anwender nicht sichtbar ist, und einer Verschlüsselung, die auf Anwendungsebene
abläuft, unterschieden werden, bei der sich beispielsweise ein Anwender durch ein
Zertifikat der Anwendung gegenüber ausweisen kann. Es gibt hier auch mehrere
Zwischenstufen. Die im Laufe dieser Arbeit verwendeten sind in der folgenden
Tabelle dargestellt. So sind bei den hier betrachten Kommunikationsbeziehungen alle
bis auf die direkte Kommunikation zweier Applikationen Leitungsverschlüsselungen.
Anpassung der Applikation bedeutet, dass eine Anwendung speziell für die gesicherte
Kommunikation angepasst werden muss.
Interaktion durch Anwender heißt, dass der Anwender sich beispielsweise speziell
für die Verschlüsselung anmelden muss.
Schlüssel des Anwenders gibt an, ob jeder Anwender einen persönlichen Schlüssel
besitzt oder ob ein Router, Firewall oder eine andere Netzwerkkomponente die Verschlü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.
50

Client Server Anpassung
der Applikation
Interaktion
durch
Anwender
Schlüssel
des
Anwenders
Art der
Verschlüsselung
Applikation Applikation Ja Ja Ja Applikation
Client Server Nein Ja Ja Leitung
Client
Router/
Firewall
Router/
Firewall
Router/
Firewall
Nein Ja Ja Leitung
Nein Nein Nein Leitung
Tabelle 7-1: Arten der Verschlüsselung
In der folgenden Grafik wird eine erstrebenswerte Zielstruktur dargestellt. Die dazu
notwendigen Tools werden detaillierter in Kapitel 7.2 (Tools zur Sicherung der
Kommunikation) anhand von Teilgrafiken beschrieben, in denen auch der Kommunikationsfluss
zwischen den beteiligten Komponenten dargestellt wird.
51

Abbildung 7-1: Zielstruktur
Wenn die Kommunikation zwischen wenigen dedizierten Systemen (z.B. zwischen
zwei Routern) stattfindet, ist zu überlegen, ob der Zusatzaufwand für das Einbinden
der CA sinnvoll ist oder ob in solchermaßen einfachen Fällen eine statische Authentisierung
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ähigkeit
der heutigen und zukünftigen Prozessoren wird im Folgenden nur der Einsatz einer
starken Verschlüsselung empfohlen. Das bedeutet bei einer symmetrischen
Verschlüsselung mindestens 128 Bit Schlüssellänge und bei der asymmetrischen
Verschlüsselung mindestens 1024 Bit Schlüssellänge. Es spricht jedoch nichts dagegen,
bei ausreichend vorhandener Rechenleistung für die symmetrische Verschlüs-
52

selung 192 bzw. 256 Bit und für die asymmetrische Verschlüsselung 2048 Bit zu
verwenden.
In diesem Soll-Modell wird davon ausgegangen, dass alle beteiligten Komponenten
(gegebenenfalls mit Ausnahme der Verschlüsselung der Festverbindung) Zugriff auf
die CA der MHH besitzen und sich so über neue bzw. für ungültig erklärte Schlüssel
zeitnah informieren können. Im Folgenden werden der Initiator der Kommunikation
als „Alice“, der Kommunikationspartner „Bob“ und die CA „Charlie“ genannt.
Der Ablauf der Kommunikation würde für alle Prozesse etwa folgendermaßen ablaufen:
Abbildung 7-2: Modell der Schlüssel- und Datenübermittlung
1. Alice sendet (sofern vorhanden) den lokal gespeicherten Schlüssel von Bob
bzw. einen „Fingerabdruck“ an die CA Charlie.
2. Charlie sendet als Antwort eine Bestätigung des Schlüssel, bzw. den neuen
Schlü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 gespeicherten
Schlüssel (bzw. den Fingerabdruck) von Alice an Charlie.
8. Charlie sendet eine Bestätigung des Schlüssels bzw. den aktuellen Schlüssel
an Bob.
9. Bob prüft die Echtheit von Alices Signatur.
53

Als Variante wäre es möglich, nicht bei jedem Kommunikationsvorgang den lokal
gespeicherten Schlüssel bei der CA bestätigen zu lassen, sondern nur dann, wenn seit
der letzten Kommunikation eine bestimmte Zeit vergangen ist (beispielsweise ein
Tag, eine Woche), oder spätestens, wenn das Gültigkeitsdatum des Schlüssels oder
des Zertifikates abgelaufen ist.
Im Folgenden werden Vorschläge für den Einsatz kryptographischer Methoden für
verschiedene Arten der Kommunikation gegeben. Anschließend werden die im vorigen
Kapitel betrachteten Kommunikationsanwendungen gemäß den Vorschlägen eingeordnet.
Das Ziel ist es, ein Verfahren auswählen zu können, das die notwendige
Sicherheit und Leistung bietet, ohne jedoch einen unnötigen Aufwand betreiben zu
müssen.
Die folgende Tabelle gibt den Rahmen vor, bei welchen Eigenschaften der Kommunikationsprozesse
der Einsatz welcher Verfahren (Verschlüsselung bzw. Signatur)
angeraten ist. Aufbauend auf diesen Anforderungen werden dann die Tools vorgestellt,
welche die Prozesse absichern (in dem Feld Performance und Verschlüsselung
bedeutet HW Verschlüsselung durch Hardware).
54

Gruppe Parameter Verschlüsselung Authentisierung
/
Signatur
Sicher
Netz-Umgebung
LAN
Ja
nicht
C-LAN
Ja
relevant
Internet
Ja
Art der Kommunikation
Kommunikationspartner
Spezifisch
Standard
Transparent
M-M
M-P
P-P
nicht relevant
nicht relevant
Bekanntheit
bekannt
unbekannt
symmetrisch,
asymmetrisch
asymmetrisch
nicht
relevant
Sensitivität
gering
mittel
hoch
Ja
Ja
nicht
relevant
Verbindlich-/ Beweisbarkeit
irrelevant
erwünscht
notwendig
zwingend
nicht relevant
Ja
Ja
Ja
Anpassung
Ja
Nein
nicht relevant
Performance
irrelevant
relevant
Software
HW, symmetrisch
nicht
relevant
Speicherung
Ja
Nein
nicht relevant
Tabelle 7-2: Auswahl kryptographischer Verfahren
Bei den Punkten Netz-Umgebung, Bekanntheit, Sensitivität, Verbindlich-/Beweisbarkeit
und Performance gibt die Reihenfolge der Nennung der Parameter die Abstufung
des Sicherheitsniveaus an. Hier gilt der Einsatz eines asymmetrischen (hybriden)
Verfahrens als „sicherer“ (da flexibler) als ein symmetrisches.
55

Wenn eine Anwendung in einem sicheren Netz läuft, weshalb dann im Allgemeinen
von Verschlüsselung abgesehen werden kann, jedoch die Sensitivität der Daten mittel
oder hoch ist, sollte dennoch eine starke Verschlüsselung gewählt werden um die
Angriffsmöglichkeiten weiter zu reduzieren.
Ebenso muss bei einer Anwendung, bei der die Performance relevant ist (symmetrische
Verschlüsselung), jedoch mit unbekannten Partnern (asymmetrisch) kommuniziert
wird, eine asymmetrische (bzw. hybride) Verschlüsselung gewählt werden.
Werden die Daten archiviert, sind Vorkehrungen aus 4.5 (Schlüsselverlust) zu treffen,
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 Leitung
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 ist
jedoch möglich über ACLs die Rechte für Netzwerkzugriffe zu beschränken, allerdings
ist dies bei komplexeren Konfigurationen ohne den Einsatz eines vollwertigen
Firewalls aufwendig.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent.
56

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 Internet
von den Firewalls gesichert, welche die Authentizität des jeweiligen Partners durch
die ausgestellten Zertifikate überprüfen können.
Durch die Firewalls können die beiderseitigen Zugriffe auf ein notwendiges Maß
beschränkt werden.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent.
57

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 transparent
auf das Netz der MHH zuzugreifen. Dabei ist es unerheblich, ob sie sich direkt
per ISDN oder Modem in einen RAS-Router in die MHH einwählen oder über eine
bereits bestehende Modem, ISDN oder DSL Verbindung über das Internet zugreifen.
Bei einem VPN-Tunnel über das Internet ist zu beachten, dass der Client gegen
Zugriffe aus dem Internet geschützt werden muss, damit dadurch nicht ein Angriffspunkt
auf die MHH entsteht. Das ist beispielsweise durch den zusätzlichen Einsatz
eines Personal-Firewall (Firewall-Software, die auf einem Client läuft und diesen vor
Angriffen schützen soll) oder eine kombinierte IPSec-Software mit integriertem Personal-Firewall
möglich, die bei bestehendem VPN jegliche Kommunikation mit dem
Internet unterbindet.
Die Überprüfung der Authentizität des Anwenders kann durch die Überprüfung von
Zertifikaten erfolgen, wobei der Client-Schlüssel auf einer SmartCard, einem USB
Flash-ROM (ein Modul, dass an den Universal Serial Bus des Clients angeschlossen
wird) oder der Festplatte gespeichert wird.
Es ist eine Interaktion durch den Anwender notwendig (er meldet sich am Firewall
der MHH an), eine Authentisierung eines einzelnen Anwenders ist möglich und seine
Netzwerkzugriffsberechtigungen in das Netz der MHH können auf Anwenderebene
beschränkt werden. Die Verschlüsselung erfolgt für die Anwendung transparent.
58

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 eine
gesicherte Punkt-zu-Punkt-Verbindung aufgebaut. Im Gegensatz zu dem in 6.2.3
(Internetverbindung zu einem anderen Krankenhaus) beschriebenen Tunnel wird
dieser Tunnel direkt zwischen den beteiligten Servern aufgebaut und nicht von
dahinterliegenden Netzwerkkomponenten. Das heißt, durch diesen Tunnel wird nur
eine 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 Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auch
möglich eine Authentisierung auf Anwenderebene durchzuführen, welche in dem
hier betrachteten Szenario nicht erwünscht ist.
59

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 Anwender
sicherzustellen, dass er den von ihm gewünschten Server erreicht hat und die Daten
nicht durch einen Man-in-the-Middle Angriff kompromittiert werden.
Es ist keine Interaktion durch den Anwender notwendig, eine Authentisierung eines
einzelnen Anwenders ist nicht möglich. Die Verschlüsselung erfolgt auf Anwendungsebene.
60

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 auf
geschützte Web-Seiten ermöglicht wird. Es ist natürlich möglich, diese Client-Zertifikate
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 es
gegebenenfalls durch Angabe eines Passwortes, eine Authentisierung eines einzelnen
Anwenders ist möglich und seine Zugriffsberechtigungen können innerhalb der
Anwendungsebene beschränkt werden. Die Verschlüsselung erfolgt auf Anwendungsebene.
61

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 beliebiges
Programm übertragen zu werden.
Es ist keine Interaktion durch einen Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auch
möglich, eine Authentisierung auf Anwenderebene durchzuführen, aber das ist in
dem hier betrachteten Szenario nicht erwünscht, da es hier um die automatisierte
gesicherte Datenübertragung geht.
62

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üsselung
durchgeführt. In diesem Modell sind die notwendigen Funktionen zur Verschlüsselung
in die E-Mail Anwendung integriert.
Die Mail kann vor dem Versenden durch den Anwender signiert und verschlüsselt
werden. Dann wird sie als gewöhnliche Mail dem Empfänger zugestellt, welcher sie
entschlüsselt und (sofern vorhanden) die Signatur des Absenders überprüft. Die Mail
kann dann sowohl verschlüsselt als auch unverschlüsselt archiviert werden.
Es ist eine Interaktion durch den Anwender notwendig (er muss seinen zertifizierten
Schlüssel auswählen und aktivieren), eine Authentisierung eines einzelnen Anwenders
ist möglich. Die Verschlüsselung erfolgt auf Anwendungsebene.
63

7.3. Modellvorstellung
In der Modellvorstellung werden die vorgestellten Tools so kombiniert, dass sie die
notwendigen Anforderungen in den Prozessen umsetzen.
7.3.1. Datenübermittlung zwischen Instituten
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üsselund
Datenübermittlung) dargestellt, erfolgen. Das Signieren und Verschlüsseln wird
dabei durch eine spezielle Anwendung, welche die genannten Überprüfungen der
Schlüssel durchführt, erfolgen. Als Übertragungsmethode kann dann ein beliebiges
Programm zur Datenübertragung eingesetzt werden.
Es wäre ebenfalls möglich die Daten nur zu signieren und sie ohne eine explizite
Verschlüsselung über einen durch entsprechende Software gesicherten Tunnel auf
den anderen Computer zu übertragen. Dabei werden ebenfalls von der CA ausgestellte
Zertifikate verwendet.
7.3.2. Direktgeschaltete Verbindung zu einer anderen Klinik
Verwendetes Tool:
7.2.1 (Router VPN)
Bei einer direktgeschalteten Leitung ist es ausreichend, wenn beidseitig auf den
Routern sichere symmetrische Schlüssel eingesetzt werden. Da es sich nur um sehr
wenige Verbindungen handelt, ist es nicht unbedingt notwendig asymmetrische
Schlüssel und eine CA zu verwenden. Es spricht jedoch auch nichts dagegen. Dann
ist sicherzustellen, dass die Router periodisch die Gültigkeit des Zertifikates des
jeweils anderen Routers überprüfen.
7.3.3. Internetverbindung zu einem anderen Krankenhaus
Verwendetes Tool:
7.2.2 (Firewall-Firewall VPN-Tunnel)
Zur gesicherten Übertragung der Daten über das Internet sollte ein VPN aufgebaut
werden. 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-
64

schen den Firewalls auf beiden Seiten 4 aufgebaut und nur die unbedingt notwendigen
Berechtigungen eingetragen.
Durch das VPN wird sichergestellt, dass im Internet niemand die Daten mitlesen
kann. 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 der
Gültigkeit der Schlüssel mit zunehmender Anzahl der VPNs zunimmt und die Überprüfung
auf ungültig gewordene Schlüssel versehentlich unterbleiben kann, sollte die
Authentisierung der Gegenstellen über eine beiderseitig bekannte CA erfolgen - insbesondere,
da davon auszugehen ist, dass nicht beide Firewalls von denselben Personen
administriert werden.
Der Einsatz weiterer Tools, um die Daten auch innerhalb der beiden Corporate LANs
zu sichern bzw. zu signieren, kann nun wie innerhalb eines Corporate LAN erfolgen.
7.3.4. Gesicherte Einwahl über ISDN, Modem oder Internet
Verwendetes Tool:
7.2.3 (Anwender-Firewall VPN-Tunnel)
Die gesicherte Einwahl in das Netz der MHH kann analog zu dem Aufbau eines
VPN zwischen MHH und einer anderen Klinik betrachtet werden, mit dem Unterschied,
dass die Client-IP-Adresse des Zugriffs in die MHH nicht fest ist. Es gibt
dabei im Prinzip lediglich zusätzlich die Möglichkeit direkt per ISDN oder Modem
auf einen RAS-Router zuzugreifen. Die Authentisierung der Clients könnte dann
über Zertifikate erfolgen, die beispielsweise auf einer SmartCard oder der lokalen
Festplatte gespeichert und per Passwort geschützt sind. Ebenfalls wäre der Einsatz
von Einmalpassworten (z.B. SecurID) vorstellbar – siehe Abbildung 7-5 (Anwender-
Firewall VPN (Ziel)).
7.3.5. Webbasierte Kommunikation
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 Internet
als auch im Intranet durch den beiderseitigen Einsatz von Zertifikaten abgesichert
werden. Dadurch kann einerseits der Client sicherstellen, dass er mit dem richtigen
Server 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 sonstige
Einrichtung des Gesundheitswesens über Firewalls gesichert ist. Eine Anbindung ohne Firewalls
würde dermaßen große Risiken bergen, dass sie vermutlich als zumindest fahrlässig angesehen
werden kann.
65

möglich die Berechtigungen des Nutzers abhängig von dem Zertifikat (Client-Zertifikate)
zu steuern.
Am besten wird das Client-Zertifikat auf einer SmartCard oder auf der Festplatte
gespeichert und mit einem Passwort geschützt. Es wäre ebenfalls erstrebenswert,
wenn einzelne Dokumente zusätzlich mit einer Signatur versehen sind und so beispielsweise
der Autor einer Anweisung zur Medikamentierung eindeutig identifiziert
werden kann.
7.3.6. Multizentrische klinische Studien über das Internet
Verwendete Tools:
7.2.5 (Web-Server-Zertifikate)
7.2.6 (Web-Client-Zertifikate)
7.2.3 (Anwender-Firewall VPN-Tunnel)
Die multizentrischen klinischen Studien können über ein Web-Interface gegebenenfalls
mit einem Java Applet, welches Plausibilitätsprüfungen durchführt, auf einen
Web-Server in der MHH zugreifen. Dabei würden sich Web-Server und Web-Client
gegenseitig durch den Austausch von Zertifikaten identifizieren.
Da Zugriffe aus dem Internet in diesem Fall nur von einer überschaubaren Anzahl
von Personen kommen können, wäre es ebenfalls möglich – und sinnvoll - den
Zugriff auf den Web-Server an sich noch über eine weitere Sicherheitsstufe zu
sichern, um weniger Angriffspunkte zu bieten. Vor dem Aufbau der Web-Verbindung
wäre ein Tunnel zu dem Firewall zu öffnen, durch den der Zugriff auf den
Web-Server erst ermöglicht würde. Dadurch wäre der Server auch für den Fall
geschützt, dass ein Konfigurationsfehler Zugriff auf die Daten freigeben würde, ohne
dass der Client sich hinreichend authentifiziert hat.
7.3.7. Gesicherter interner Mailversand
Verwendetes Tool:
7.2.8 (E-Mail Add-On)
Um eine möglichst reibungslose Nutzung von Signaturen und Verschlüsselung zu
ermöglichen, sollte das Mailprogramm die notwendige Funktionalität bzw. Schnittstellen
für entsprechende Tools bereitstellen. In diesem Fall würde die Kommunikation
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 angeben
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ätzlich
alle Mails zu verschlüsseln und den Anwender zu warnen, falls bei einem Kommunikationspartner
eine Verschlüsselung nicht möglich ist. Die umfassende Verschlüsse-
66

lung von Mails setzt ein funktionierendes Virenschutzkonzept voraus, welches auf
dem Client eine Prüfung der übermittelten Daten auf Viren sicherstellt. Eine Prüfung
auf einem zentralen Server ist dann nicht mehr möglich und ein Entschlüsseln der
Mails 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 nicht
nur um die Übertragung zu sichern, sondern es ist auch davon auszugehen, dass die
Mails verschlüsselt gespeichert bleiben. Deshalb könnte ein Schlüsselverlust den
Zugriff auf bereits gespeicherte Daten unterbinden. Es sollten daher entsprechende
Maßnahmen (z.B. ADK), wie in 4.5 (Schlüsselverlust) beschrieben, ergriffen werden.
Da es sich hier um rein internen Mailverkehr handelt, ist es auch möglich die
Nutzung von Mailprogrammen auf Programme zu beschränken, die den Anforderungen
entsprechen.
7.3.8. Gesicherter externer Mailversand
Verwendetes Tool:
7.2.8 (E-Mail Add-On)
Der gesicherte externe Mailversand wird analog zum gesicherten internen Mailversand
aufgebaut. Da jedoch bei externen Empfängern nicht davon ausgegangen werden
kann, dass eine Verschlüsselung möglich ist, kann darauf verzichtet werden,
automatisch jede Mail zu verschlüsseln. Es sollte jedoch explizit darauf hingewiesen
werden, 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 Absenders
(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.
67

8. Pragmatisches Modell
8.1. Allgemeine Überlegungen
Bisher ist ein ideales Modell, wie es im vorigen Kapitel vorgestellt wurde, nicht zu
realisieren. Mit einigen Abstrichen im Komfort (vor allem bei der Schlüsselverwaltung)
und geringen Einbußen in der Funktionalität lässt sich aber bereits heutzutage
ein Modell umsetzen, das durch die Kombination von mehreren Standard-Produkten
ein relativ hohes Sicherheitsniveau erreicht und auch mit begrenzten finanziellen
Mitteln realisierbar ist.
Zur Zeit ist es beispielsweise so, dass für Web-Server- und Client-Zertifikate X.509
eingesetzt wird, für die Verschlüsselung und Authentisierung von E-Mails oder einzelnen
Dateien jedoch häufig PGP. Bei Direktverbindungen zwischen Routern sind
häufig symmetrische Verschlüsselungen im Einsatz, die ohne jedwede Signatur auskommen.
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 mehrere
verschiedene und untereinander inkompatible Schlüssel benötigt. Das hat zur Folge,
dass evtl. auch mehrere Certificate Authorities (CAs) parallel für jedes eingesetzte
Protokoll 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 Anwendung
kein Redesign des Prozesses durchführen zu müssen.
Die privaten Schlüssel sollten möglichst auf einem Wechselmedium und nicht auf
einer Festplatte gespeichert werden, damit nur der Besitzer auf den in der Regel
zusätzlich per Passwort geschützten geheimen Schlüssel zugreifen kann. Als Speichermedium
ist eine SmartCard denkbar. Da bisher nicht flächendeckend entsprechende
Kartenleser vorhanden und auch nicht alle Anwendungen damit kompatibel
sind, wäre es evtl. möglich beispielsweise ein Flash-ROM an den USB-Port des
Computers anzuschließen, das anwendungsseitig als normales Wechselmedium
erkannt wird [CT2002-03]. Dadurch ist es zu allen gängigen Anwendungen kompatibel,
die den Schlüssel in einer frei wählbaren Datei speichern können. USB-Ports
sind heutzutage an allen aktuellen Computern zu finden und auch aktuelle Betriebssysteme
unterstützen diese Schnittstelle.
Wenn es lediglich darum geht, dass der Anwender sich gegenüber einem Server
identifizieren kann, ist es auch möglich auf Generatoren für Einmalpassworte
zurückzugreifen. Es wäre dann beispielsweise möglich, dass sich ein Anwender, der
68

sich über das Internet in die MHH einwählt, mittels einer PIN und einem durch eine
SecurID Karte (von RSA) generierten Einmalpasswort als legitimer Benutzer ausweist.
Selbst wenn einmal jemand die PIN und das Einmalpasswort mitgelesen haben
sollte, ist es für einen Replay-Angriff nicht zu verwenden. Die Karte allein wäre für
den 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 Kurzform
@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 Anwendungen
andererseits dar. Die dazu notwendigen Tools werden detaillierter in 8.3 (Tools
zur Sicherung der Kommunikation) anhand von Teilgrafiken beschrieben, in denen
auch der Kommunikationsfluss zwischen den beteiligten Komponenten dargestellt
wird.
69

Abbildung 8-1: Umzusetzende Struktur
Beim Einsatz der kommerziellen Version von PGP für Windows ist es möglich einen
ADK (siehe 4.5 (Schlüsselverlust)) für die Kommunikation zu erzwingen. Es ist
ebenfalls möglich, einen Schlüssel so aufzuteilen, dass er nur durch das Zusammenwirken
mehrerer (z.B. 3 von 3 oder auch 3 von 5) verwendet werden kann. Dadurch
kann ein Zugriff auf die hinterlegten Schlüssel ermöglicht werden.
70

8.2. Auswahl der CA-Software
Im Folgenden werden mehrere CAs zur Erstellung von Zertifikaten benötigt. Leider
sind diese CAs untereinander nicht kompatibel, sodass es notwendig sein wird, dass
ein Anwender (eine Person oder auch ein Institut) teilweise mehrere Schlüssel erhält,
die von verschiedenen CAs zertifiziert wurden. Weiterführende Hinweise zum Aufbau
von CAs im Allgemeinen finden sich in [CKLW2000] und speziell für eine
X.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 eingesetzt
werden. Es empfiehlt sich eine Variante einzusetzen, die für den Betrieb als CA
optimiert wurde, damit beispielsweise zwischen Signatur und Verschlüsselungsschlüsseln
unterschieden werden kann. Da die Bedienung des zentralen Zertifikats-
Servers nur durch speziell geschultes Personal erfolgt, ist es auch möglich Software
einzusetzen, die ohne graphische Benutzeroberfläche auskommt, dafür aber die notwendigen
Funktionen bietet.
Als Ergänzung der CA-Software wäre es auch möglich den PGP Certificate Server
Freeware (http://web.mit.edu/network/pgp.html) einzusetzen, der dann bei dem
Anwender als Zertifikats-Server eingetragen werden kann.
Es sind ebenfalls Programme erhältlich, welche eine Schnittstelle zwischen dem
Anwender und der CA bilden und es so ermöglichen, Zugriff auf die Zertifikate und
zurückgerufenen Schlüssel zu erlangen. Die Abfrage kann dabei sowohl per Webbrowser,
Mail-Server als auch aus einem entsprechenden Client heraus erfolgen.
Die PGP-Zertifikate können für alle Anwendungen von PGP verwendet werden, also
sowohl für die Mailverschlüsselung als auch für die Übertragung von PGP-verschlüsselten
Dateien. Es ist jedoch darauf zu achten, dass möglichst alle Programme
mit den verschiedenen asymmetrischen und symmetrischen Algorithmen zurechtkommen,
die bei PGP verwendet werden.
X.509 CA
Für die X.509 CA kann beispielsweise OpenSSL verwendet werden, das diverse
Tools 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 GPL
stehende IDX-PKI, http://idx-pki.idealx.org/). Da die Zertifikate bei X.509 deutlich
komplexer als die von PGP sind, wäre ein GUI vorteilhaft. Da die Bedienung - ebenfalls
wie bei der PGP CA – durch geschultes Personal erfolgt, ist dieser Nachteil zu
verschmerzen.
Es sollte ein Web-Server mit einer Liste der zurückgerufenen Zertifikate existieren
und diese Adresse in jedem Zertifikat gespeichert werden, damit ein Client online
überprüfen kann, ob ein Zertifikat möglicherweise zurückgerufen wurde. Dieser Ser-
71

ver oder ein Spiegel sollte auch aus dem Internet heraus erreichbar sein, damit die
Echtheitsü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 durch
die Installation eines pre shared Secrets auf beiden Endpunkten realisiert. Es ist aber
auch (z.B. bei Cisco Routern) möglich Zertifikate zu nutzen.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent.
72

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 von
Zertifikaten realisieren. In der Abbildung vertraut der Firewall der Partnerklinik der
CA der MHH transitiv.
Wenn die Partnerklinik ebenfalls eine CA betreibt, kann sie den Firewall der MHH
auch selbst zertifizieren. Anschließend können die Netze des jeweils anderen Kommunikationspartners
wie das eigene Campus-Netz genutzt werden. Es ist auch möglich
und empfehlenswert dem Kommunikationspartner keinen Zugriff auf das
gesamte Netz einzuräumen, sondern nur die absolut notwendigen Zugriffe freizuschalten.
Dann kann (muss jedoch nicht) die Kommunikation ohne weitere Verschlüsselung
genutzt werden.
Problematisch wird die Verbindung dann, wenn in beiden Campus-Netzen die selben
Adressbereiche verwendet werden. In den meisten Fällen ist es dann aber mittels
Network Address Translation (NAT) möglich, die Adresse für die Kommunikation
entsprechend umzusetzen.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent.
73

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 eines
VPN-Clients ermöglicht. Dieser VPN-Client baut den VPN-Tunnel zwischen dem
Client und dem Firewalls auf (im Gegensatz zum vorigen Tool, welches ein VPN
zwischen Firewalls bzw. Netzen aufbaut).
Im Gegensatz zum Anwender-Firewall VPN-Tunnel aus dem Soll-Modell kann hier
noch nicht von einer sicheren Authentisierung mittels CA und Smart-Cards ausgegangen
werden. Deshalb wird das Modell um eine starke Authentisierung mittels
RSA-SecurID-Karten erweitert. In diesem Fall gibt der Anwender als Passwort eine
PIN und eine (minütlich wechselnde) sechsstellige Zahl (das sogenannte Token) ein,
welche er auf der SecurID Karte ablesen kann (das daraus entstehende Passwort wird
Passcode genannt). Es gibt auch Varianten der Karte, bei welcher der Anwender
seine PIN in die Karte eintippt und diese daraus den Passcode erzeugt, der dann
direkt als Passwort verwendet werden kann. Der in der MHH stehende Server
„weiß“, welche Karte zu welchem Zeitpunkt welche Zahlenkombination anzeigt und
welchem Benutzer sie mit welcher PIN zugeordnet ist. Wenn die übermittelten Daten
korrekt sind (insbesondere unter Beachtung des Zeitpunktes, denn die Token sind nur
etwas mehr als eine Minute gültig), wird der Benutzer durch den Firewall als legitimierter
anerkannt und kann mit dem Netz der MHH gesichert kommunizieren. Die
SecurID-Karte kann im Übrigen auch noch als Mittel zur Authentisierung von
Anwendern bei der Anmeldung auf Server verwendet werden (beispielsweise für die
Unix-Anmeldung).
74

Wie in der Zielvorstellung bereits aufgeführt wurde, ist bei einer Verbindung über
das Internet der Client selbst noch vor Zugriffen aus dem Internet zu schützen. Das
sollte durch den Einsatz des VPN-Clients mit Personal-Firewall-Funktionalität
anstatt eines reinen VPN-Clients realisiert werden. Dann kann der Administrator des
MHH-Firewalls auch das Regelwerk auf dem Client vorgeben und so jegliche andere
Kommunikation mit dem Internet für die Zeitdauer, während derer der Tunnel
besteht, unterbinden.
Ein Vorschlag für einen in die Infrastruktur der MHH passenden VPN-Client findet
sich im Anhang unter Auswahl des VPN-Clients.
Es ist eine Interaktion durch den Anwender notwendig (er meldet sich am Firewall
der MHH an), eine Authentisierung eines einzelnen Anwenders ist möglich und seine
Netzwerkzugriffsberechtigungen in das Netz der MHH können auf Anwenderebene
beschrä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 OpenSSH
aufbauen. Durch diesen können die Applikationen der beiden Computer ohne nennenswerte
Änderungen kommunizieren. Die Authentisierung erfolgt durch das
direkte Abspeichern der öffentlichen Schlüssels des jeweils anderen Servers ohne
eine Interaktion durch den Anwender.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auch
möglich eine Authentisierung auf Anwenderebene durchzuführen, aber das ist in dem
hier betrachteten Szenario nicht erwünscht.
75

8.3.5. Web-Server-Zertifikate
Abbildung 8-6: Web-Server-Zertifikate
Die Server-Zertifikate können - wie in der Zielstruktur aufgezeigt - implementiert
werden.
76

8.3.6. Web-Client-Zertifikate
Abbildung 8-7: Web-Client-Zertifikate
Die Client-Zertifikate können - wie in der Zielstruktur aufgezeigt - implementiert
werden.
77

8.3.7. Datei-Verschlüsselungsprogramm
Abbildung 8-8: Datei-Verschlüsselungsprogramm
Als Programm zur Dateiverschlüsselung kann PGP eingesetzt werden. Da diese
Kommunikationsbeziehung relativ statisch ist, ist ein direkter Austausch der Schlüssel
(ggf. sogar ohne ein Zertifikat der MHH PGP CA) möglich. Das Modell der
Kommunikation würde also so, wie in Abbildung 7-2 (Modell der Schlüssel- und
Datenübermittlung) beschrieben, erfolgen. Der Austausch und die Überprüfung der
Schlüssel würden lediglich entfallen bzw. durch den Anwender vorgenommen.
Es ist keine Interaktion durch den Anwender notwendig, aber auch keine Authentisierung
eines einzelnen Anwenders möglich. Die Verschlüsselung erfolgt für die
Anwendung transparent. Durch ein Umkonfigurieren der Anwendung wäre es auch
möglich eine Authentisierung auf Anwenderebene durchzuführen, aber das ist in dem
hier betrachteten Szenario nicht erwünscht.
78

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 realisiert
werden. Anders ist zur Zeit eine preiswerte anwendungsübergreifende Public-Key-
Kryptographie nicht praktikabel realisierbar. Außerdem ist PGP auch noch der defacto-Standard
für E-Mail-Verschlüsselung und für die Kommunikation mit externen
Partnern notwendig. Die Deutsche Gesellschaft für Medizinische Informatik, Biometrie
und Epidemiologie (GMDS e.V.) schreibt in einer „Stellungnahme zur klinischen
Nutzung von E-Mail“ [GMDS-EMail], dass PGP zur Verschlüsselung und
Signatur eingesetzt werden kann.
Da keines der eingesetzten Programme von sich aus PGP nutzen kann, ist der Einsatz
eines entsprechendem Add-On notwendig. Bei PGP für Windows ist im Standardlieferumfang
bereits ein Modul zur Integration in Outlook vorhanden. Eine Integration
in Pegasus-Mail ist beispielsweise durch den Einsatz von QDPGP (http://www.
community.wow.net/grt/qdpgp.html) oder PMPGP (http://www.pmpgp.de/) möglich
und 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. eine
automatische Warnung, wenn eine Mail unverschlüsselt gesendet werden soll.
Die Mail kann vor dem Versenden durch den Anwender signiert und verschlüsselt
werden. Dann wird sie als gewöhnliche Mail dem Empfänger zugestellt, welcher sie
entschlüsselt und (sofern vorhanden) die Signatur des Absenders überprüft. Die Mail
kann verschlüsselt gespeichert werden. Eine unverschlüsselte Speicherung ist abhängig
von den verwendeten Tools und evtl. nicht möglich.
Es ist eine Interaktion durch den Anwender notwendig (er muss seinen zertifizierten
Schlüssel auswählen und aktivieren), eine Authentisierung eines einzelnen Anwenders
ist möglich. Die Verschlüsselung erfolgt auf Anwendungsebene.
79

8.4. Umsetzung
8.4.1. Datenübermittlung zwischen Instituten
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übermittlung
generiert 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. Da
jedoch für den automatischen Betrieb die Passworte zum Entsperren der Schlüssel
auf den an der Übertragung beteiligten Computern vorliegen müssen, empfiehlt sich
hierfür die Verwendung eines eigenen Schlüssels.
Die Übertragung der Daten läuft folgendermaßen ab:
Labor: Signieren der zu übertragenden Daten mit
Labor-Transfer@MHH
Labor: Verschlüsseln der (bereits signierten) Daten für
THG-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 per
FTP aus dem Labor abholt)
THG:
THG:
Entschlüsseln der Daten mit THG-Transfer@MHH
Überprüfen der Signatur auf Korrektheit mit
Labor-Transfer@MHH
8.4.2. Direktgeschaltete Verbindung zu einer anderen Klinik
Verwendete Tools:
8.3.1 (Router VPN)
Solange keine CA installiert ist, die durch die Router direkt angesprochen werden
kann, 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 zu
arbeiten, sozusagen einem Passwort, das auf beiden Routern exklusiv für diese Verbindung
eingetragen wird. Bei Cisco Routern, die z.B. auch in der MHH im Einsatz
sind erfolgt der Austausch von Session-Keys selbstständig durch die Router. Bei
80

Cisco-Routern ist es beispielsweise auch möglich mit Zertifikaten zu arbeiten und so
ohne die pre-shared-Secrets auszukommen.
Da die MHH nur relativ wenige solcher Verbindungen haben wird, die auch von
denselben Administratoren verwaltet werden, würden andere Lösungen keinen signifikanten
Vorteil bringen, jedoch die Komplexität erhöhen.
8.4.3. Internetverbindung zu einem anderen Krankenhaus
Verwendete Tools:
8.3.2 (Firewall-Firewall VPN-Tunnel)
Solange die Anzahl der VPNs zwischen der MHH und anderen Institutionen relativ
gering ist, bietet es sich an auch hier mit (keinesfalls erratbaren) pre-shared-Secrets
zu arbeiten oder bereits ohne den Einsatz von CAs mit innerhalb der VPN Software
generierten Zertifikaten zu arbeiten. Im Gegensatz zu der direktgeschalteten Verbindung
ist die Geheimhaltung dieser identifizierenden Daten essentiell, da – im Gegensatz
zu der direktgeschalteten Leitung – beliebige Angreifer ohne nennenswerten
Aufwand über das Internet eine Verbindung aufbauen können.
Der Aufbau des VPN sollte mittels IPSec über den bereits in der MHH im Einsatz
befindlichen Firewall laufen.
8.4.4. Gesicherte Einwahl über ISDN, Modem oder Internet
Verwendete Tools:
8.3.3 (Anwender-Firewall VPN-Tunnel)
Im Folgenden wird davon ausgegangen, dass der Weg des Verbindungsaufbaus zur
MHH für den weiteren Weg in die MHH nicht relevant ist. Bei der direkten Einwahl
via Modem oder ISDN würde diese auf einen Access-Router gehen, der an ein spezielles
Segment des (Internet-) Firewall angebunden ist. Es wird in jedem Fall ein
verschlüsselter Tunnel von dem Computer des Anwenders zu dem Firewall aufgebaut.
Um auch nur Berechtigten den Zugriff zu ermöglichen muss sich der Anwender beim
Aufbau des Tunnels dem Firewall gegenüber authentisieren. Als Software auf Clientseite
empfiehlt sich hier der zum Firewall gehörende VPN-Client (siehe im Anhang
Auswahl des VPN-Clients).
Sollte der Zugriff aus dem Internet heraus erfolgen, ist darauf zu achten, dass der
Client nicht ungeschützt im Internet steht und so als Brückenkopf missbraucht werden
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 Auswahl
des VPN-Clients).
81

Diese Authentisierung sollte keinesfalls mit statischen Passworten geschehen. Stattdessen
sollten Zertifikate, die beispielsweise auf einer Smart Card gespeichert sind,
verwendet werden. Alternativ können auch Einmalpassworte verwendet werden. Da
eine Liste mit Einmalpassworten nicht komfortabel handhabbar ist, würde es sich für
diese Anwendung empfehlen einen Einmalpasswortgenerator wie z.B. SecurID-Karten
von RSA einzusetzen, die jede Minute eine neue sechsstellige Zahl anzeigen, die
zusammen mit einer PIN für einen kurzen Zeitraum die Authentisierung ermöglicht.
Die Einmalpassworte könnten auch anstatt einfacher Passworte für den Zugriff auf
Computer innerhalb der MHH (Unix oder Windows NT/2000) verwendet werden.
8.4.5. Webbasierte Kommunikation
Verwendete Tools:
8.3.5 (Web-Server-Zertifikate)
8.3.6 (Web-Client-Zertifikate)
Der Einsatz der Client- und Server-Zertifikate ist bereits wie in der Zielvorstellung
beschrieben möglich. Es ist teilweise jedoch notwendig, entweder die Server-Zertifikate
manuell im Web-Client zu installieren oder die CA der MHH als vertrauenswürdig
zu klassifizieren, wodurch automatisch alle von ihr ausgestellten Zertifikate
akzeptiert werden. Letzteres ist auf jeden Fall bei den Clients innerhalb der MHH
durchzuführen. Es sollte jedoch die Option, dass eine Onlineprüfung der Zertifikate
erfolgt, aktiviert sein.
Client-Zertifikate können dann zur Steuerung der Berechtigungen bei Zugriffen
innerhalb der Web-Server eingesetzt werden, sodass beispielweise auch über das
Internet hinweg auf interne Daten zugegriffen werden kann.
8.4.6. Multizentrische klinische Studien über das Internet
Verwendete Tools:
8.3.5 (Web-Server-Zertifikate)
8.3.6 (Web-Client-Zertifikate)
8.3.3 (Anwender-Firewall VPN-Tunnel)
Für die multizentrischen klinischen Studien können die Methoden zur Sicherung der
webbasierten Kommunikation aus 8.4.5 (Webbasierte Kommunikation) eingesetzt
werden. Es ist auch noch möglich als weitere Sicherheitsstufe (um den Server selbst
zu schützen) einen Tunnel zwischen dem Studienclient und dem Firewall der MHH
aufzubauen und nur für den jetzt bereits am Firewall authentisierten Anwender den
Zugriff auf den Studienserver freizuschalten. Dazu können die Methoden der gesicherten
Einwahl aus 8.4.4 (Gesicherte Einwahl über ISDN, Modem oder Internet)
genutzt werden, wobei der spezielle Anwender jedoch nur auf den Studienserver
Zugriff erhält.
82

8.4.7. Gesicherter interner Mailversand
Verwendetes Tool:
8.3.8 (E-Mail Add-On)
Der gesicherte interne Mailversand lässt sich zu einem großen Teil (was die Qualität
der Sicherung angeht) bereits so wie im Soll-Modell vorgeschlagen realisieren. Es
gibt jedoch relativ große Komforteinbußen, da die Kryptographie nur durch den Einsatz
von Zusatzprogrammen auf die E-Mail-Programme aufgesetzt wird und noch
kein 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 abgehenden
Mails mit einer Warnung, wenn eine unverschlüsselte Mail versandt werden soll, bisher
nicht unterstützt. Dadurch besteht ein gewisses Restrisiko, dass ein Anwender in
dem Glauben, eine verschlüsselte Mail zu senden, versehentlich sensible Daten
unverschlüsselt sendet.
Durch die Technik ist es bisher kaum möglich dies zu unterbinden. Deshalb müssen
die Anwender regelmäßig darüber informiert werden, dass sie selbst die Vertraulichkeit
der übermittelten Daten sicherstellen müssen.
8.4.8. Gesicherter externer Mailversand
Verwendetes Tool:
8.3.8 (E-Mail Add-On)
Bei dem gesicherten externen Mailversand gilt das bereits zum gesicherten internen
Mailversand Gesagte. Es kommt allerdings hinzu, dass die Clients außerhalb der
MHH mit nicht kontrollierbarer Software im Einsatz sind und es so zu Kompatibilitätsproblemen
mit Kommunikationspartnern in der MHH kommen kann. Es gibt beispielsweise
verschiedene Versionen von PGP, die nur RSA und IDEA (die Versionen
2.x) beherrschen und nicht mit den Diffie-Hellmann-Schlüsseln der neueren Versionen
zurechtkommen. Auch gestaltet sich die Verteilung der Schlüssel im Vergleich
zur MHH schwierig, da es kein zentrales Verzeichnis aller PGP-Schlüssel
gibt.
Genauso, wie bei dem internen Mailversand existiert ein gewisses Restrisiko versehentlich
eine Mail mit sensiblen Daten über das Internet zu versenden.
Dieses Problem ist technisch gesehen bisher kaum abzusichern. Es ist daher notwendig
die Anwender regelmäßig darauf hinzuweisen, dass sie selbst dafür verantwortlich
sind die Vertraulichkeit der Übertragung sicherzustellen (siehe 3 (Rechtlicher
Rahmen der Kryptographie in Deutschland)).
83

9. Zusammenfassung
„We can only see a short distance ahead, but
we can see plenty there that needs to be done."
[Alan Turing, 1953]
Diese Arbeit hat die Anforderungen an die Übermittlung und Speicherung medizinischer
Daten aufgrund der aktuellen Gesetzeslage und der standesrechtlichen Bestimmungen
beleuchtet.
Anschließend wurde die rechtliche Lage der Signatur und Verschlüsselung in
Deutschland betrachtet, um dann auf Basis der Anforderungen und des gesetzlichen
Rahmens die Einsatzmöglichkeiten der verschiedenen kryptographischen Verfahren
zu erläutern.
Nach Erläuterung der Grundlagen wurden typische Kommunikationsprozesse aus
dem Alltag der MHH analysiert und die zur Verfügung stehende Infrastruktur
vorgestellt. Aufgrund dieser Analyse wurde dann ein Soll-Modell erarbeitet, das die
Prozesse im Rahmen der vorgegebenen Anforderungen sichern soll. In diesem Soll-
Modell wurde keine Rücksicht darauf genommen, ob dieses Modell bereits
vollständig umgesetzt werden kann. Es wurden aber primär Methoden vorgeschlagen,
von denen anzunehmen ist, dass sie in den nächsten Jahren zur Verfügung stehen
werden.
Danach wurde ein Modell vorgestellt, das eine ähnliche Sicherheit wie das Soll-
Modell bietet, jedoch bereits jetzt umgesetzt werden kann – insbesondere unter
Beachtung der knappen finanziellen Mittel eines Krankenhauses. Die Realisierbarkeit
wurde durch den Verzicht auf eine einheitliche Umgebung und durch den Einsatz
verschiedener Tools und Strukturen ermöglicht (beispielsweise der Einsatz
zweier getrennter CAs anstatt nur einer einzigen). Es wurde dabei darauf geachtet,
dass die verwendeten Methoden so einfach wie möglich, aber auch so sicher wie
nötig sind, damit die Sicherheit nicht durch Fehler bei der Umsetzung einer hochkomplexen
und theoretisch sicheren Kryptographieinfrastruktur zunichte gemacht
wird. Smith schreibt in [Smi1998]: „Beim Codeknacken wird entweder die Chiffrierung
selbst oder aber die Art ihres Einsatzes angegriffen. Gemessen an der Stärke
moderner Chiffrierungen besteht heute die eigentliche Gefahr eher in der Art und
Weise, wie die Chiffrierungen eingesetzt werden.“
Als Ergebnis kann festgehalten werden, dass bereits heute viele Kommunikationsprozesse
gesichert werden können. Allerdings ist dazu der Einsatz vieler Tools notwendig,
die zum Teil nicht miteinander kommunizieren und so für den Anwender
teilweise unbequem sein können. Es ist ebenfalls noch viel Arbeit zu leisten, um beispielsweise
sicherzustellen, dass auf verschlüsselt gespeicherte Daten auch nach dem
84

Verlust des Schlüssels zugegriffen werden kann. Auch ist es notwendig von Zeit zu
Zeit zu überprüfen, ob die verwendeten Methoden und deren Einsatz durch die
Anwender noch den möglicherweise geänderten Rahmenbedingungen entsprechen
und 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 das
Internet 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 ein
Virus ungeschützt auf Ressourcen der MHH zugreifen, beispielsweise Dateien über
das Internet an den Autor des Trojaners senden oder Dateien auf Netzwerklaufwerken
mit Viren verseuchen.
Ein weiteres Sicherheitsrisiko kann durch den Einsatz intelligenter Trojaner entstehen,
die während einer bestehenden getunnelten Verbindung Daten in der MHH
sammeln 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 diesem
Fall die Übermittlung der Daten in das Internet etwas problematischer ist.
Der Faktor „Mensch“ ist grundsätzlich in die Einführung einzubeziehen, um die
Akzeptanz zu erhöhen. Die Anwendung der Kryptographie sollte für den Anwender
so einfach wie möglich gestaltet werden. Es muss sich in der Praxis zeigen, wie der
zusätzliche Aufwand bei den Anwendern aufgenommen wird. Wenn die Akzeptanz
gering ist, ist nicht auszuschließen, dass die Anwender Möglichkeiten suchen, sich
das Leben bequemer zu machen – selbst mit dem Risiko, dass dadurch die Sicherheit
drastisch sinkt.
Um dieser Gefahr entgegenzuwirken sind Anwenderschulungen notwendig, in denen
für die Anwender deutlich gemacht wird, weshalb dieser Aufwand betrieben wird
und was möglicherweise die Konsequenzen sind, wenn diese Maßnahmen ausgehebelt
werden. Wenn ein Verständnis für die Probleme vorhanden ist, sind sie sicherlich
auch bereit, gewisse Komforteinbußen in Kauf zu nehmen. Das Abschließen von
Türen ist auch unbequem – trotzdem wird sicherlich jeder seine Wohnung bei
Verlassen abschließen. Der Einsatz von Kryptographie darf unbequem sein, den
Anwender allerdings nicht in seiner Arbeit behindern!
85

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 auf
das LAN zu haben. Ein weiteres Risiko besteht darin, dass es weder auf Client- noch
auf Server-Seite eine Trennung der Netze für Klinik, Verwaltung und Forschung gibt
(durch dedizierte Hardware oder VLANs) und so durch einfache Zugriffbeschränkungen
auf Routern oder Firewalls der Zugriff von einem Forschungsarbeitsplatz auf
einen Verwaltungsserver unterbunden werden könnte.
Ebenfalls gibt es bereits verschiedene Tools, welche den durch Switches existierenden
Schutz vor dem Mitlesen aushebeln und so die Bedrohung vergrößern.
Die Bedrohung durch die genannten Angriffe ist vermutlich als relativ gering einzustufen
(mit Ausnahme der Insider). Da es jedoch um sehr sensible Daten geht, deren
bekannt werden das Leben der Betroffenen massiv beeinträchtigen kann (z.B. können
sich Informationen über Aufenthalte in Psychiatrischen Kliniken auf die Karriere
des Betroffenen katastrophal auswirken), sind Schutzmaßnahmen unumgänglich.
Netzwerk-Infrastruktur des Campus-LAN
Die MHH hat ein durch das Medizinische Hochschulrechenzentrum (MHRZ) betriebenes
campusweites geswitchtes Fast-Ethernet-Netzwerk (100 MBit Ethernet), in
dem primär TCP/IP (das Kommunikationsprotokoll, auf dem zur Zeit die meiste
Netzkommunikation erfolgt und das auch im Internet verwendet wird), aber auch
noch teilweise IPX/SPX (Kommunikationsprotokoll, das von der Firma Novell und
einigen anderen eingesetzt wurde) eingesetzt werden. Es bestehen weiterhin Verbindungen
zu einigen Außenstellen über direktgeschaltete Datenverbindungen, auf
denen ausschließlich TCP/IP eingesetzt wird.
Zusätzlich hat die MHH eine durch einen CheckPoint Firewall-1 gesicherte Infrastruktur
Verbindung zum G-WIN des DFN-Vereins („Verein zur Förderung eines
deutschen Forschungsnetzes“) und damit eine Verbindung zum Internet.
Der Aufbau von dezentralen ISDN- oder Modem-Einwahlpunkten durch einzelne
Abteilungen ist nicht gestattet.
Server- und Client-Infrastruktur des Campus-LAN
In der MHH wird als Clientbetriebssystem fast durchgängig Windows NT, vereinzelt
auch Windows 2000, verwendet. Die Server laufen zum größten Teil unter Solaris
86

auf SUN SPARC Hardware bzw. unter Windows NT/2000 oder Linux auf Standard
PC Hardware. Es kann davon ausgegangen werden, dass alle Systeme (sowohl Server
als auch Client) per TCP/IP erreichbar sind.
Es existiert ein zentraler unter Unix laufender Mail-Server, über den alle Mails, welche
die MHH verlassen, gesendet werden. Auf diesem ist ein Verzeichnis aller in der
MHH verwendeten offiziellen Adressen vorhanden. Als Mailprogramm auf Seiten
der Benutzer wird zu einem großen Teil Pegasus-Mail verwendet. Teilweise sind
aber auch Netscape Mail oder Outlook im Einsatz.
Auswahl des VPN-Clients
Als VPN-Client kann das zum bereits eingesetzten Checkpoint Firewall-1 gehörende
und zur Zeit kostenlose SecuRemote verwendet werden. Wenn die Personal-Firewall-Funktionalität
gewünscht wird, kann der kostenpflichtige SecureClient eingesetzt
werden.
87

Literaturverzeichnis
[Ber1996]
[Blö2001]
[BlPo1997]
[CKLW2000]
[CT2002-03]
[DÄT1997]
Bernauer, J., „Medizinische Dokumentation – Terminologische
Grundlagen“, Universität Hildesheim, Skripten des Fachbereichs
Mathematik, Informatik, Naturwissenschaften, 1996
Blömer, J., Vorlesung „Angewandte Aspekte der Kryptographie“,
Universität Paderborn 2001
Blobel, B., Pommerening, K., „Datenschutz und Datensicherheit
in Informationssystemen des Gesundheitswesens”, f&w 2/97,
133-138, http://MZ98.IMSD.Uni-Mainz.DE/AGDatenschutz/
Empfehlungen/fuw.htm
Camphausen, I., Kelm, S., Liedtke, B., Weber, L., „Aufbau und
Betrieb einer Zertifizierungsinstanz“, DFN-PCA, 2000
„Transcend bietet USB-Speichermedien mit bis zu 512 MByte
an“, c´t 3/2002, S. 27
Deutscher Ärzte Tag, „Auszug aus der (Muster-) Berufsordnung
fü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]
[GMDS-EMail]
[HePa1996]
[IBM2001]
Fischer, V. G., Grossmann, V., „Abgehorcht – Public-Key-
Infrastrukturen im Gesundheitswesen“, iX 9/2001, S. 52ff.
Deutsche Gesellschaft für Medizinische Informatik, Biometrie
und Epidemiologie GMDS e.V., „Stellungnahme zur Klinischen
Nutzung von E-Mail“, http://WWW.Med.Uni-Muenchen.DE/
ibe/internet/em_email.htm
Hennessy, J. L., Patterson, D. A., „Computer Architecture - A
Quantitative Approch“, Morgan Kaufmann Publishers Inc., San
Fransisco, 1996
IBM Server Group, „POWER4 System Microarchitecture“,
http://www-1.ibm.com/servers/eserver/pseries/hardware/
whitepapers/power4.pdf, Oktober 2001
88

[IBMT2000]
[iX2002-03]
Fraunhofer Institut für Biomedizinische Technik, Arbeitsgruppe
Medizin-Telematik, „PaDok – Patientenbegleitende Dokumentation“,
http://www.ibmt.fhg.de/, 2000
Schmidt, K., „IBMs ‚Regatta’ als Number Cruncher“, iX
3/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“, Landesrundschreiben
1/1999, http://WWW.KVB.DE/mitteil/lrs991a2.htm
[LANL2001]
[Lös1999]
[Mal2001]
[MDJP1998]
[MeKü2000a]
[MeKü2000b]
[Mül2001]
[MüPf1997]
„Das neue Signaturgesetz“, LANline Spezial „Das sichere
Netz“, III/2001, S. 24ff
Löser, M., „Untersuchung zur Einrichtung von Echtzeitsignalen
mit variabler Bitrate über ATM-Netze (STM-4) am Beispiel von
verlustfrei codierten TV-Studiosignalen (SDI) unter Einsatz einer
geeigneten ATM-Adaptionsschicht (z.B. AAL5 und/oder
AALx)“, Diplomarbeit an der TU Ilmenau, 1999
Malakas, K., „Heilige Kuh – Gesetz zur elektronischen Signatur“,
c´t 7/2001, S. 47
Matthies, H. K., Dietzel, G. T. W., Jan, U. von, Poschadel, F.,
Porth, A. J., „Sicherheit in Informationssystemen: Informationssicherheit
in medizinischen Netzen“, vdf Zürich, 1998
Menzel, U., Kühn, U., „Stellungnahme des Hamburgischen
Datenschutzbeauftragten“, http://WWW.MediSec.DE/text/
20000215DaSchutzHH.htm
Menzel, U., Kühn, U., „Datenschutz und elektronisch vernetzte
Patientendaten“, Vorabveröffentlichung aus dem Hamburger
Ärzteblatt 2000, http://WWW.MediSec.DE/text/DaSchuHH.htm
Müller, A., Vorlesung „Mathematische Grundlagen der Kryptographie“,
HSR, 2001
Müller, G., Pfitzmann, A., „Mehrseitige Sicherheit in der Kommunikationstechnik“,
Addison-Wesley, 1997
89

[MPWJ1998a] Matthies, H. K., Poschadel, F., Wübbelt, P., v. Jan, U., Porth, A.
J., „Kryptographisch gesicherte Kommunikation und Datenerfassung
für multizentrische klinische Studien mit Web-Technologien“,
GMDS, 1998
[MPWJ1998b] Matthies, H. K., Poschadel, F., Wübbelt, P., v. Jan, U., Porth, A.
J., „Prague Stochastics '98: Cryptographically Secured Communication
and Data Acquisition for Multi-Centric Clinical Studies
Using Web Technologies“, JCMF Prag, 1998
[NiSc2001]
[Sav2001]
[SchB1996]
Niesing, M., Schmeh, K., „Schlüssel des Vertrauens – Digitale
Ausweise im Internet“, c´t 7/2001, S. 224ff
Savard, J., „A Cryptographic Compendium - The Advanced
Encryption Standard (Rijndael)“, http://home.ecn.ab.ca/
~jsavard/crypto/co040801.htm, 2001
Schneier, B., „Angewandte Kryptographie“, Addison-Wesley,
1996
[SchB2001] Schneier, B., „Secrets & Lies“, dpunkt.verlag, 2001
[SchC2001]
Schulzki-Haddouti, C., „Preisfrage – Neues Signaturgesetz ab
Anfang 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ät
Braunschweig 2000
90

Danksagung
„Gut Ding will Weile haben!“
Mein Dank gilt besonders Herrn Prof. Dr. Dietmar Wätjen von der Technischen
Universität Braunschweig und Herrn Prof. Dr. Herbert K. Matthies von der Medizinischen
Hochschule Hannover für die Möglichkeit diese Diplomarbeit bei ihnen
anfertigen zu können und die Unterstützung bei der Erstellung dieser Arbeit.
Ebenfalls gilt mein Dank meinen Eltern Rosa und Emil, die nicht lockergelassen
haben, dass ich endlich meine Diplomarbeit schreibe.
Norbert dafür, mir manch mathematische Frage beantwortet und sich damit abgefunden
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 und
Siegfried.
Meinem Chef Achim für das Verständnis und sowohl inhaltliche, als auch formelle
Ratschlä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 unendliche
Geschichte geworden.
Zum Schluss möchte ich mich bei allen bedanken, die das Internet zu einer Fundgrube
gemacht haben, die auf viele Fragen eine passende Antwort (nicht nur 42!)
liefert.