Analyse, Verifikation und Realisierung kryptographischer Protokolle fuer flexible Zugriffe auf medizinische Datenbanken

Inhaltsverzeichnis

1 Einleitung
1.1 Aufgabenstellung
1.2 Sicherheitsrelevante Anforderungen

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

3 Protokolle
3.1 Gemeinsamkeiten der entwickelten Protokolle
3.2 Shared Protokoll
3.2.1 Zertifikate
3.2.2 Formalisierte Nachrichten
3.3 Zyklisches Protokoll
3.3.1 Ablauf
3.3.2 Formalisierte Nachrichten
3.4 Geschwindigkeit und Bewertung .
3.5 Update-Mechanismus

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

5 Implementierung
5.1 iSaSilk
5.2 Shared-Secrets
5.3 Generieren von Zufallszahlen
5.4 ProcessQueryWrapper
5.5 Rollenproxy
5.5.1 Crypt
5.5.2 Rollenverwaltung
5.5.3 Durchführung der Protokolle
5.5.4 Sicherheit der RoleProxy-Klasse
5.6 Update-Mechanismus
5.7 Benutzen der Protokolle
5.8 CORBA
5.9 Änderungen am RVChecker
5.10 Werkzeuge
5.10.1 Annotationen
5.10.2 Pseudonymisierer

6 Zusammenfassung

Abbildungsverzeichnis

1.1 Schema des Datenzugriffs im Szenario

2.1 Struktur eines X.509 Zertifikat

3.1 Übersicht Shared Protokoll

3.2 Reihenfolge der Nachrichten im Shared Protokoll

3.3 Man in the Middle

3.4 Übersicht Zyklisches Protokoll

3.5 Reihenfolge der Nachrichten im Zyklischen Protokoll

4.1 Aufteilung der Analyse in Ebenen der Entwicklung

4.2 Vom Quell-Code zur individuellen Plattform

5.1 UML-Diagramm des Zufallszahlengenerators

5.2 UML-Diagramm des Rollenproxys

5.3 UML-Diagramm des zyklischen Datenbank-Servers

5.4 Kaskade von drei Annotationen

5.5 Pseudonymisieren in zwei Stufen

Tabellenverzeichnis

2.1 Prädikate der BAN-Logik

2.2 Grundlegende BAN-Ableitungsregeln

3.1 Geschwindigkeit der beiden Protokolle

4.1 FIPS 140-1 Runs Test

Listings

Abbildung in dieser Leseprobe nicht enthalten

Kapitel 1 Einleitung

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

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

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

1.1 Aufgabenstellung

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

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

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

Beschreibung des Szenarios

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

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

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

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

Im System selbst handeln verschiedene Benutzer, d. h. im Sinne von verschiedenen Individuen, z. B.

”ChristianMüller“oder ”HansSchmidt“,idealerweisenurinner- halb einer Rolle, so z. B. in den Rollen ”Chefarzt“oder ”Stationsarzt“.Benutzer treten im System nicht mehr als Personen oder Individuen auf, sondern funktions- orientiert. Geheimnisse wie Schlüssel zum Entschlüsseln von Daten können damit bestimmten Funktionen zugeordnet werden, etwa je ein Schlüssel für die Rollen ”Chefarzt“und ”Stationsarzt“.EinBenutzer,dersichamSystemanmeldet,be- kommt dynamisch eine Rolle zugeordnet oder bewirbt sich bei einem zentralen Rollenserver um eine Rolle. Dieser Server entscheidet nach bestimmten Regeln, wie den Vorgaben eines vorher erstellen Dienstplans, oder nach Maßnahmen der Notfallbehandlung, ob ein Benutzer zu diesem Zeitpunkt eine Rolle einnimmt. Danach tritt der Benutzer im System nur noch unter dieser Rolle auf. Er be- kommt vom Rollenserver die Schlüssel zum Entschlüsseln der entsprechenden Daten zugeordnet. Alle Transaktionen (Zugriffe) auf den Datenbestand gesche- hen, wie oben erwähnt, im Namen dieser Rolle. Der Benutzer kreiert sich dabei einen sogenannten Rollenproxy, der für ihn den Datenzugriff stellvertretend im Namen seiner Rolle, sowie sämtlichen kryptographischen Protokolle transparent durchführt. Zu einem späteren Zeitpunkt kann der Nutzer diese Rolle, und damit das Geheimnis, freiwillig wieder abgeben oder wird dazu durch ein Regelsystem gezwungen.

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

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

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Schema des Datenzugriffs im Szenario

1.2 Sicherheitsrelevante Anforderungen

Die Arbeiten [2] und [21] geben eine Übersicht über die sicherheitsrelevanten Anforderungen in medizinischen Informationssystemen.

Zunächst gelten für alle gespeicherten oder übertragenen (Patienten-)Daten die vier klassischen kryptographischen Anforderungen, wie sie allgemein für alle sicheren Systeme vorausgesetzt werden:

1. Vertraulichkeit

Diese Anforderung ist die offensichtlichste der vier. Es geht um die Geheim- haltung der Informationen gegenüber unbefugtem Mitlesen während einer Datenübertragung oder beim unberechtigten Zugriff direkt auf den Spei- cherort der Daten. In Falle klinischer Informationssysteme muß beispiels- weise sichergestellt sein, daß nur der entsprechend autorisierte Arzt die an- geforderten Informationen über einen Patienten lesen darf. Dies macht nicht nur eine Form von Rechtesystem erforderlich, z. B. einen Rechteserver, der verwaltet, welcher Arzt genau wie zugreifen darf, sondern auch die Notwen- digkeit der Verschlüsselung/Chiffrierung der eigentlichen Daten. Ziel dieser

1.2 Sicherheitsrelevante Anforderungen 5

Vertraulichkeitsanforderung ist es, daß ein potentieller Angreifer aus dem zufälligen oder unberechtigten Mitlesen der chiffrierten Nutzdaten keinerlei Rückschlüsse auf die eigentlichen Nutzdaten ziehen kann [31].

2. Integrität

Es muß sichergestellt sein, daß Daten unverändert vom Sender zum Empfänger gelangen. Die verschlüsselten gesendeten Daten müssen gleich den entschlüsselten empfangenen Daten sein. Auf keinen Fall darf durch unabsichtliche Übertragungsfehler oder gar absichtliche Manipulation während der Übertragung der Inhalt der Daten unbemerkt verändert werden. Sind Daten verändert worden, so muß dies den Benutzern sofort ersichtlich sein. Es ist von außerordentlicher Wichtigkeit, daß nicht autorisierte Personen keine Patientendaten verändern können.

3. Authentizität

Im Vordergrund der Authentizität steht die Frage nach dem Nachweis der Echtheit bzw. der Herkunft von Daten. Benutzer A bzw. Rolle A muß seine Identität und seine Daten über ein Verfahren authentifizieren, so daß später andere Benutzer überprüfen können, daß diese Daten wirklich genau von A stammen. Im klassischen Briefverkehr erkennt der Empfänger eines Briefes z. B. anhand der Unterschrift, daß dieser Brief vom Absender stammt. Bei elektronischer Datenübertragung gibt es ähnliche Mechanismen, digitale Signaturen (siehe Abschnitt 2.2), die - unter bestimmten Voraussetzungen - genauso arbeiten, wie die handschriftlichen. Änderungen an Patientendaten dürfen nicht nur von ganz bestimmten Benutzern gemacht werden, sondern es muß später ersichtlich sein, wer die Änderungen gemacht hat.

4. Verbindlichkeit

Ein weiteres Problem ist die Verbindlichkeit von Daten. Hat ein Sender A Daten an Empfänger B gesendet, so ist dies für A verbindlich. A kann danach nicht mehr abstreiten (non repudiation), diese Daten gesendet zu haben und muß für diese Daten haften. Verbindlichkeit und Authentizität hängen miteinander zusammen, sind jedoch nicht äquivalent. Kennt B die Unterschrift von A, so erkennt B zwar ein von A signiertes Dokument als authentisch an, kann jedoch nicht gegenüber einem dritten C beweisen, daß dieses Dokument von A stammt - außer C kennt ebenso die Unterschrift von A. A kann gegenüber C leugnen, dieses Dokument je unterschrieben zu haben.

Spezielle Anforderungen im medizinischen Bereich

Speziell für das in dieser Arbeit untersuchte medizinisch/klinische Umfeld gelten zusätzliche Anforderungen, die berücksichtigt werden müssen:

1. Unbeobachtbarkeit

Im geplanten System werden mehrere Computer über wahrscheinlich ab- hörbaren Leitungen viele Daten übertragen. Es soll einem Angreifer nicht möglich sein, aus dem Fluß der Daten irgendwelche Rückschlüsse auf deren Inhalt zu ziehen. Greift der Rechner eines Arztes auf eine Datenbank zu, so darf nicht klar sein, ob es sich hierbei um einen Lese- oder Schreibzu- griff handelt, sondern nur, daß es sich um einen Zugriff handelt. Auch das mehrmalige Zugreifen auf ein und denselben Datensatz darf nach außen hin nicht als solches erkannt werden.

2. Nichtverfolgbarkeit

Außerdem existiert das Bedürfnis nach Nichtverfolgbarkeit des Datenflus- ses. Es muß schwierig sein, zurück zu verfolgen, wer wann welche Zugriffe getätigt hat.

3. Anonymisierung und Pseudonymisierung

Unter Umständen sollen die Namen der Patienten pseudonymisiert werden, beispielsweise zum Anlegen von Statistiken. Hier werden die Daten des Pa- tienten benötigt, nicht jedoch der Name. Er wird hinter einem Pseudonym verborgen. Im Gegensatz zur kompletten Anonymisierung ist die Pseudo- nymisierung gegebenenfalls jedoch wieder umkehrbar. Gewinnt ein Arzt aus einer pseudonymisierten Akte zufällig eine neue bedeutende Erkenntnis zum Wohl des Patienten, so muß aus dem Pseudonym der richtige Name abgeleitet werden können.

4. Erhalt der Sicherheit bei Manipulation einzelner Server und Sta- tionen

Wie in Abbildung 1.1 dargestellt, wird der Datenzugriff über mehrere Sta- tionen verwirklicht. Eine Station kann ein eigener Computer sein, es können aber auch mehrere Stationen auf einem Computer arbeiten. Stationen sind z. B. die Datenbank, der Rollenserver, der Regelserver etc. Problematisch ist, wenn eine solche Station von einem Angreifer korrumpiert wird. Beispielsweise könnte der Rollenserver von einem Eindringling unter seine Kontrolle gebracht werden. Eine wichtige grundsätzliche Anforderung ist, daß das gesamte Zugriffs-System solange sicher gegen einen möglichen Mißbrauch bleiben soll, solange nur maximal eine einzelne Station korrumpiert wird. Ist also nur der Rollenserver manipuliert, so sind die geheimen Patientendaten noch nicht verloren. Bei einem Zugriff auf eine korrumpierte Station muß das System einen Fehler erkennen.

Kapitel 2 Kryptographie

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

2.1 Chiffren

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

-Gegeben sei ein Klartext M , also die zu verschlüsselnden Daten,
-eine Verschlüsselungsfunktion E, die aus dem Klartext M durch Anwenden von E auf M ein Chiffrat C = E(M ) produziert,
-eine Entschlüsselungsfunktion D, die aus dem Chiffrat C wieder den Klartext M = D(C) errechnet. Natürlich sollte D(E(M )) = M gelten.
-Sinn und Zweck einer Verschlüsselung ist, daß es unmöglich bzw. sehr schwierig und aufwendig ist, aus der Kenntnis von Chiffrat C zurück auf Klartext M zu schließen. Das Berechnen von E(M ) sowie D(C) ist allerdings mit geringem Aufwand verbunden.

Da bei dieser Form von Verschlüsselungssystemen die Sicherheit von der Ge- heimhaltung von E und D abhängt^[1], sind die Funktionen E und D meistens über (mindestens) einen zusätzlichen Parameter k parametrisiert. k ist der gehei- me Schlüssel des Chiffriersystems. Es sollte gelten k1 = k2 → Ek (M ) = Ek2(M ).

Dies hat zur Konsequenz, daß mehrere Benutzer dasselbe öffentlich bekannte Chiffriersystem benutzen können, ohne gegenseitig vertrauliche Daten mitzule- sen, solange sie nicht im Besitz des geheimen Schlüssels sind. Die Sicherheit einer solchen parametrisierten Chiffre hängt dann nur vom Schlüssel und nicht von der Geheimhaltung des Chiffriersystems ab, es sei denn, die Chiffre an sich hätte eine ausnutzbare Schwäche.

Je nach Schlüsseltyp unterscheidet man Chiffren in

-Symmetrische Chiffren

Hier gibt es, wie oben bereits beschrieben, nur einen Schlüssel k zum Parametrisieren von E und D. Es gilt Dk(Ek(M )) = M und Ek(Dk(C)) = C. Der Schlüssel k ist geheim. Die Sicherheit einer symmetrischen Chiffre hängt von der Geheimhaltung von k ab.

-Asymmetrische Chiffren

Bei asymmetrischen oder auch Public-Key Chiffren wird mit zwei zusam- mengehörenden Schlüsseln gearbeitet. Ein offentlicher Schlüssel e zum Ver- schlüsseln, sowie ein geheimer oder privater Schlüssel d zum Entschlüsseln von Daten. Aus dem öffentlichen Schlüssel kann man nicht bzw. nur mit unvertretbar hohem Aufwand den privaten Schlüssel errechnen. Bei asym- metrischen Chiffren gilt: Ee(M ) = C, Dd(C) = M . Der öffentliche Schlüssel heißt öffentlich, weil er ohne Risiko veröffentlicht werden kann - d. h. er steht jedem Interessierten zur Verfügung. Hat A ein Schlüsselpaar aus zusammen- gehörenden e und d, so kann er e an jeden anderen Nutzer B verteilen. Will B nun A geheime Daten schicken, so chiffriert B Ee(M ) = C und schickt C an A, der dies mit seinem geheimen d entschlüsselt.

-Hybridsysteme

Da asymmetrische Chiffren deutlich langsamer sind als symmetrische, wer- den häufig Hybridsysteme, eine Kombination aus symmetrischen und asym- metrischen Chiffren, eingesetzt. Dabei wird zunächst mit dem Public-Key Algorithmus ein symmetrischer Schlüssel chiffriert, der dann als Parame- ter eines symmetrischen Algorithmus zur Verschlüsselung der eigentlichen Nutzdaten verwendet wird.

2.1.1 AES

Das National Institute of Standards and Technology (NIST) hat auf der Su- che nach einem offiziellen Nachfolger des veralteten Data Encryption Standard (DES [23]) mehrere verschiedene Verschlüsselungs-Algorithmen auf ihre Sicher- heit, Geschwindigkeit und Flexibilität hin überprüft und schließlich den Algo- rithmus Rijndael ausgewählt. Eine Beschreibung über den Aufbau und die Ar- beitsweise von Rijndael findet sich in [16]. Rijndael wird Ende 2001 der offizielle Nachfolger von DES und heißt dann Advanced Encryption Standard (AES [9]). AES wird sowohl im öffentlichen als auch im privaten Datenverkehr zur Ver- schlüsselung von sensitiven Daten dienen. Der Rijndael/AES Algorithmus ver- schlüsselt Daten(-blöcke) mit einer Größe von 128 Bits. Er ist ein Beispiel für eine symmetrische Chiffre, denn es gibt nur einen geheimen Schlüssel zur Ver- und Entschlüsselung. Rijndael gilt bisher als sicher: Der effizienteste Weg Rijn- dael zu brechen ist nach heutigem Ermessen das Erraten des richtigen Schlüssels. Bei einer Schlüssellänge zwischen 128 und 256 Bit gibt es bis zu 2[256] verschiedene mögliche Schlüssel, die ein Angreifer probieren müßte. Dies ist eine sogenann- te Brute-Force Attacke, wobei der Angreifer sukzessive alle möglichen Schlüssel ausprobiert.

Zum Vergleich: die Anzahl der Atome in unserer Galaxie wird auf nur 2[233] geschätzt. Selbst bei einer Schlüssellänge von 128 Bit bräuchte ein Supercomputer, der eine Millionen Schlüssel pro Sekunde probieren kann, immernoch 10[25] Jahre [4]. AES ist nicht nur sehr sicher, sondern auch portabel, schnell und effektiv. Außerdem kann er effizient auf Chipkarten implementiert werden [5]. Der Rijndael-Code paßt in 52 Bytes. Er ist im Gegensatz zu anderen symmetrischen Algorithmen, wie IDEA [4] flexibel in seiner Schlüssellänge und es existieren keine Patentprobleme. Jeder darf AES benutzen.

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

2.1.2 RSA

Rivest, Shamir und Adlemann haben 1978 den nach ihnen benannten, sehr erfolgreichen Public-Key Algorithmus RSA vorgestellt. Aufbau und Arbeitsweise sind beschrieben in [33]. Zum Erzeugen von öffentlichem und privatem Schlüssel werden zwei möglichst gleichgroße Primzahlen p und q gewählt und

Abbildung in dieser Leseprobe nicht enthalten

berechnet. Der öffentliche Schlüssel e wird zufällig aus dem Bereich 3≤e<n

gewählt und zusammen mit n veröffentlicht. e hat die Eigenschaft: ggT(e,(p − 1)(q − 1)) = 1.

Der private Schlüssel d ist das Inverse zu e mod (p − 1)(q − 1) und kann durch den erweiterten euklidischen Algorithmus

Abbildung in dieser Leseprobe nicht enthalten

ermittelt werden. Für das Chiffrieren eines Klartextes M wird das Chiffrat C durch

Abbildung in dieser Leseprobe nicht enthalten

berechnet. Das Entschlüsseln funktioniert über M = Cd mod n.

Ein Angreifer ist nicht im Besitz von p oder q, sondern kennt nur n. Um von n und e auf d zu schließen, würde er p und q (die Primfaktorzerlegung von n) für den erweiterten Euklid brauchen. Die Sicherheit von RSA basiert nach bisherigen Erkenntnissen auf dem Problem, für sehr große Zahlen eine Primfaktorzerlegung zu finden. Große Zahlen sind Zahlen in der Größenordnung von etwa 2[2048]. Das ist eine Zahl mit 617 Ziffern. Die Faktorisierung einer solchen Zahl mit den bisher bekannten mathematischen Techniken, wie dem speziellen Zahlkörpersieb, dau- ert selbst auf Großrechnern etwa 10[6] Jahre. Allerdings werden in Zukunft mit Sicherheit neue, schnellere Algorithmen zum Faktorisieren entwickelt werden.

RSA ist weit verbreitet und gut untersucht. Die Schlüssellängen und damit auch die zu faktorisierenden Zahlen sind beliebig vergrößerbar. Da RSA außerdem in der Lage ist, Signaturen (s. Abschnitt 2.2) zu erstellen, wird diese Chiffre bei der Implementierung des Protokolls als Public-Key Algorithmus eingesetzt.

2.2 Digitale Signaturen

Wie in Abschnitt 1.2 bereits angedeutet, werden digitale Signaturen zum Sicher- stellen von Authentizität in den Protokollen benötigt. Digitale Signaturen werden genauso oder ähnlich wie handschriftliche Unterschriften arbeiten. Sie werden, fest mit einem Dokument verbunden, einem ”Verifizierer“denBeweisliefern,daß ein bestimmter Autor dieses Dokument unterschrieben hat - mit den entsprechenden Konsequenzen (Authentizität, siehe [3]). Zudem soll das unterschriebene (elektronische) Dokument nach der Unterschrift nicht mehr veränderbar sein (Integrität). Außerdem darf ein Autor eine Unterschrift möglichst nicht mehr abstreiten können (Verbindlichkeit).

Asymmetrische (Public-Key) Chiffren eignen sich zum Anfertigen und Über- prüfen von Signaturen ganz besonders. Wenn Benutzer A ein Dokument M unterschreiben will, und B diese Signatur zu dem Dokument überprüfen will, so geschieht dies folgerndermaßen:

[1]. Der öffentliche Schlüssel e von A ist jedermann (also auch B) bekannt. A errechnet C = Dd(M ) mit Hilfe seines privaten Schlüssels d. C ist die Unterschrift von A zum Dokument M .

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

3. B will die Unterschrift überprüfen und testet, ob Ee(C) = M . Ist dies der Fall, so kann B sicher sein, daß A Dokument M unterschrieben hat.

Da der eigentliche Signaturvorgang (1.) mit Public-Key Systemen beim Unter- schreiben von großen Datenmengen meist sehr langwierig ist, beschränkt man sich oftmals auf die Unterschrift des Hash-Wertes eines elektronischen Doku- mentes. Der Hash-Wert eines elektronischen Dokumentes ist die Ausgabe einer (kryptographischen) Hash-Funktion H, mit dem Dokument als Eingabe. Eine Hash-Funktion berechnet aus einer beliebig langen Eingabe eine Art Zusammen- fassung oder Fingerabdruck, d.h. aus der langen Eingabe wird eine wesentlich kürzere aber doch das Dokument fast eindeutig repräsentierende Ausgabe er- zeugt. Kryptographische Hash-Funktionen sind ”Einweg-Funktionen“,d.h.aus einem Hash-Wert ist es nur sehr schwierig oder unmöglich zurück auf die Eingabe der Hash-Funktion zu schließen.

Der erzeugte kurze Hashwert h = H(M ) wird dann von A unterschrieben, also C = Dd(h) , und wiederum das Tupel (M,C) an B gesendet. Auf der anderen Seite berechnet B ebenso zunächst den Hashwert h2 aus M und überprüft dann die Signatur C durch Berechnen von Ee(C)!= h2. Ist diese wie erwartet, so kann B annehmen, daß entsprechend A den Hash-Wert und damit auch das Dokument unterzeichnet hat. Diese Methode der Signatur ist natürlich wesentlich unsiche- rer als die obige, denn es kann beim Erzeugen von Hash-Werten natürlich zu sogenannten Kollisionen kommen: Werden Dokumente mit der Länge mehrerer Mega-Byte auf 128 Bit Fingerabdrücke abgebildet, so gibt es mit Sicherheit meh- rere verschiedene Dokumente, die den selben Hash-Wert besitzen. B kann dann nicht wirklich sicher sein, daß A auch M und nicht zufällig ein M2 unterschrieben hat. Es könnte nämlich sein, daß gilt: H(M ) = h = H(M2). Hat ein Angreifer eine Unterschrift für ein h eines ”harmlosen“Textes,undfindetereinodermeh- rere M2 mit obigen Eigenschaften, so kann er B die M2 mit der alten Unterschrift untergeschoben - B wird sie als von A signiert akzeptieren.

2.2.1 SHA-1

Der Secure Hash Algorithm [26] ist ein vom NIST und der National Securicy Agency (NSA) gemeinsam entwickeltes Hash-Verfahren. SHA-1 wurde ursprüng- lich als sichere Hash-Funktion für ein neues Signaturverfahren, den Digital Si- gnature Algorithm (DSA) entwickelt, hat sich allerdings auch unabhängig davon durchgesetzt. Der Algorithmus produziert für jede Eingabe der Länge < 2[64] Bit einen Hash-Wert der Länge 160 Bit. Es gibt in dem Algorithmus selbst bisher keine bekannte Schwachstelle. Dies bedeutet für einen eine Kollision suchenden Angreifer, daß er zu einem bekannten M etwa 2[159] andere M2 ausprobieren muß, bis gilt H(M ) = H(M2), das ist sehr aufwendig. Um das Erzeugen von Signa- turen deutlich zu beschleunigen - mit einem überschaubar begrenztem Nachteil für die Sicherheit - wird in der Implementierung SHA-1 zum Hashen der Daten benutzt.

2.2.2 Zertifikate und Zertifizierungsstellen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Struktur eines X.509 Zertifikat

Die Überprüfung digitaler Signaturen geschieht folgendermaßen: In einem Public- Key System könnte jeder Benutzer bzw. jede Rolle allen anderen Benutzern seinen öffentlichen Schlüssel zukommen lassen. Die Idee ist eigentlich gut, weil sie elek- tronisch einfach durchsetzbar ist - der öffentliche Schlüssel wird auch elektronisch vor der eigentlichen Kommunikation, in deren Verlauf eine Signatur erzeugt und überprüft wird, übertragen. Bevor A seine Daten und die Signatur an B schickt, sendet er vorneweg seinen öffentlichen Schlüssel an B. Dies allerdings ist sehr gefährlich: ein Angreifer könnte den öffentlichen Schlüssel von A abfangen und stattdessen seinen eigenen öffentlichen Schlüssel an B schicken. Dieses Szenario heißt Man in the Middle-Angriff, siehe Abbildung 3.3. B würde, da er eigentlich keine Möglichkeit hat, genau zu überprüfen, von wem der öffentliche Schlüssel ist, den öffentlichen Schlüssel des Angreifers zum Verifizieren empfangener Un- terschriften benutzen.

Um diesem Problem entgegenzutreten werden anstatt einfacher öffentlicher Schlüs- sel Zertifikate eingesetzt. Ein Zertifikat ist eine Art digitaler Ausweis. Auf einem Zertifikat stehen neben dem öffentlichen Schlüssel des Inhabers auch sein Name und weitere Daten, wie z. B. eine Gültigkeitsdauer, siehe Abbildung 2.1. Zertifika- te werden von einer vertrauenswürdigen Instanz digital unterzeichnet [4]. Jeder, der im Besitz des öffentlichen Schlüssel dieser Instanz, auch Certificate Autho- rity (CA) oder RootCA genannt, ist, kann ein Zertifikat verifizieren und damit die Gültigkeit der Zuordnung öffentlicher Schlüssel und zugehöriger Eigentümer des Schlüssels überprüfen. Vertrauen die Teilnehmer des Protokolls der CA, so können sie auch den von der CA unterschriebenen Zertifikaten vertrauen.

Zwei Probleme bleiben natürlich. Wie gelangen die Teilnehmer des Protokolls sicher an den öffentlichen Schlüssel der CA, ohne der Man in the Middle-Gefahr, und wie lassen sich neue Teilnehmer im System ihren neuen öffentlichen Schlüssel bei der CA zu einem Zertifikat zertifizieren. Beide Probleme lassen sich bei einem initialen Benutzer-Registriervorgang so lösen: Ein neuer Benutzer muß persönlich bei der CA erscheinen und sich so - auf kryptographisch sicherem Wege - sein Zertifikat unterschreiben und sich den öffentlichen Schlüssel der CA aushändigen lassen.

Diese Art der Vertrauensbildung über eine Zertifizierungskette - vertraut man der CA, so vertraut man auch den Benutzerzertifikaten - ist sicherlich fraglich, denn schließlich kann selbst die CA korrumpiert sein. Sie hat sich in der Praxis aber durchgesetzt: SSL und damit der komplette elektronische Zahlungsverkehr im Internet basiert auf dieser Form des Vertrauens. Daher werden in dieser Im- plementierung Zertifikate benutzt, und zwar X.509v3 Zertifikate [32].

2.3 Shared-Secrets

Shared-Secrets behandeln das grundsätzliche Problem, wie man ein Geheimnis derart zerlegen und auf k verschiedene Personen aufteilen kann, daß nur diese k Personen zusammen und nicht einzelne bzw. bis zu k − 1 Personen das Ge- heimnis zusammensetzen können. Viele Konzepte von Shared-Secrets sind vom US-amerikanischen Militär motiviert. Ein Anwendungsbeispiel ist das berühmte Starten einer Atomrakete: eine einzelne Person alleine kann mit ihren Codes die Rakete nicht starten, nur wenn zwei Personen (z. B. der Präsident und der Gene- ral) im Einverständnis ihre Codes in ein Kontrollsystem eingeben, wird die Rakete gestartet. Mit Shared-Secrets sind sogar (k, n)-Threshold Schemes (Schwellwert- verfahren) möglich. Das Geheimnis wird hierbei in insgesamt n Teile (Shares) zerlegt und kann dann restauriert werden, sobald mindestens k verschiedene Teile davon zusammengefügt werden. Eine recht umfassende Übersicht über die Theo- rie und Praxis von Shared-Secret-Systemen geben [12] und [13].

Das in dieser Arbeit entwickelte Protokoll aus Abschnitt 3.2 benötigt jedoch eine einfachere Variante ohne Schwellenwertverfahren, die dem Atomraketen- Problem gleicht. Für einen Zugriff auf chiffrierte Daten soll sich ein Benutzer einen Schlüssel von zwei verschiedenen Schlüsselservern besorgen. Jeder Server liefert dabei einen Teil des Schlüssel, der Benutzer kann die Teile zusammenset- zen und erhält so den kompletten Schlüssel. Die erste Idee, die vielleicht sehr naheliegt, ist den kompletten Schlüssel, z. B. mit 128-Bit Breite, in genau zwei 64-Bit breite Teile zu zerlegen und auf jeweils einen Schlüssel-Server zu speichern. Die Idee ist gut, denn bekommt ein potentieller Angreifer nur Zugriff auf einen der Teilschlüssel, so kann er damit den gesamten Schlüssel nicht rekonstruieren und damit auch auf die mit dem gesamten Schlüssel chiffrierten Daten nicht zu- greifen. Die Anzahl der Versuche, die der Angreifer bei einer Brute-Force Attacke betreiben müßte, wäre bei entsprechend sicherem Chiffriersystem allerdings nur noch etwa 2[64], um die restlichen 64 Schlüssel-Bit zu errechnen (s. Abschnitt 2.1.1). Ein solches Shared-Secret-System heißt dann nicht perfekt: Aus dem Wissen eines Teils des Geheimnisses kann man Informationen über das komplette Geheimnis sammeln.

Es gibt jedoch ein perfektes, wirksameres, d. h. für den Angreifer aufwendiger zu brechenendes Shared-Secret System, das Gus Simmons in [12] vorstellt. Bei die- sem System werden zwei Zahlen a und b zufällig von einem endlichen Zahlenstrahl aus dem Intervall 0 ≤ a, b < 2[128] gewählt. Die Summe c = a + b mod 2[128] ist das Geheimnis, also hier der geheime Schlüssel, mit dem Daten verschlüsselt werden und a, b sind die Shares, die in unserem Falle auf die beiden Schlüssel-Server ver- teilt werden. Kann nun ein Angreifer ein einzelnes Share a oder b erlangen, so muß er das andere Share konstruieren. Dies kostet ihn allerdings im Gegensatz zu obigem Verfahren diesmal 2[128] Versuche, da alle 2[128] Zahlen auf dem Zahlen- strahl gleich wahrscheinlich sind. Der Angreifer hat also durch das Wissen über ein Teilgeheimnis keinerlei Vorteil in Bezug auf das Gesamtgeheimnis. Bei 128- Bit Schlüsselbreite gibt es 2[128] verschiedene Schlüssel. Der Angreifer kann sogar ein beliebiges a′ aus dem Zahlenstrahl auswählen und versuchen c zu errechnen, denn es gibt für jedes a′ ein b′, mit a′ + b′ = c mod 2[128]. Das Errechnen von b′ kostet allerdings wieder etwa 2[127] Versuche.

2.4 Kommutative Chiffren

Im Verlauf des zweiten Protokolls aus Abschnitt 3.3 müssen Daten umverschlüsselt werden. Dazu werden kommutative Chiffren benötigt:

1. Ein Klartext M wird mit Schlüssel k1 zu C1 = Ek1 (M ) verschlüsselt.
2. C1 wird nochmals mit einem zweiten Schlüssel k2 zu C2 = Ek2(C1) = Ek2(Ek1(M)) weiterverschlüsselt.
3. Es ist jetzt nötig, durch Dk1 (C2) = Ek2 (M ) = C3 die erste Verschlüsse- lung zu lösen. Der originale Klartext M soll einfach über M = Dk (C3) rekonstruiert werden. Dies sind Anforderungen!

Für die Chiffre (E, D) muß folglich gelten C = (M ⊗ k1) ⊗ k2 = (M ⊗ k2) ⊗ k1, wobei ⊗ für ”wirdverschlüsseltmit“steht.EineChiffre,dieobigeAnforderungen

erfüllt, heißt kommutative Chiffre. Leider sind im allgemeinen symmetrische oder asymmetrische Chiffren wegen Einbußen der Sicherheit nicht ohne weiteres kom- mutativ. Zum Beispiel könnte RSA durch Benutzen eines gemeinsamen Modulus zu einer kommutativen Chiffre umfunktioniert werden, jedoch ist RSA dann leicht brechbar (siehe [[41]]). Auch andere Systeme, wie z. B. das [3]-Wege-Exponieren [[31]] sind zwar kommutativ aber unsicher. Hinzukommt, daß die möglichen Public- Key-Systeme mit Exponieren in endlichen Körpern arbeiten, was sehr aufwendig und langsam ist. AES mit einer Schlüssellänge von [128] Bit ist um den Faktor [1],[8] schneller als RSA mit einer Schlüssellänge von [2048] Bit, wobei die Schlüssellägen vergleichbare Sicherheit bieten.

2.4.1 One-Time-Pad

Es gibt aber auch wirksame kommutative Chiffren, die hinsichtlich ihrer Effi- zienz keine Einschränkungen aufweisen. Beispielsweise eignet sich das einfache bitweise ”exklusiveOder“XOR.AlsSchlüsselk1 undk2 fürXORwerdendann entsprechend dem Klartext lange One-Time-Pads verwendet. Ein One-Time-Pad ist eine einmalige Zufallszahlenfolge (siehe Abschnitt [2].[5]), die mindestens die gleiche Länge wie der zu verschlüsselnde Klartext hat. Der One-Time-Pad ist das einzige bisher bekannte Chiffriersystem für das bewiesen wurde, daß es keinen Angriff dagegen geben kann [[39]]. Der One-Time-Pad als Schlüssel steht und fällt natürlich mit seiner ”Zufälligkeit“bzw.Pseudo-Zufälligkeit,deshalbmußdarauf ein großes Augenmerk liegen. Aus diesem Grund wird im nächsten Abschnitt die Theorie zum Erzeugen von Zufallszahlen gezielt diskutiert.

2.4.2 Drei-Wege-XOR

Es gibt eine Attacke gegen XOR, wenn es als kommutative Chiffre eingesetzt wird. Dieses Drei-Wege-XOR [31] zwischen den Benutzern A und B stellt sich folgendermaßen dar:

Abbildung in dieser Leseprobe nicht enthalten

Dabei ist m der Klartext und kA sowie kB sind zwei One-Time-Pads.

Die folgende Rechnung widerlegt, daß das Versenden von c1, c2 und c3 sicher ist, denn der Klartext läßt sich einfach aus der Verknüpfung der Chiffrate rekonstru- ieren:

Abbildung in dieser Leseprobe nicht enthalten

Ist ein Big-Brother, ein Angreifer, der sämtlichen Netzverkehr abhören kann, in der Lage, alle Chiffrate mitzulesen, so hat er dadurch die Möglichkeit, m zu rekonstruieren. In Abschnitt 3.3 wird eine Maßnahme zur Verteidigung gegen dieses Drei-Wege-XOR beschrieben.

2.5 Zufallszahlen

In jedem kryptographisch arbeitenden System werden Zufallszahlen benötigt. Sei es zum Generieren von geheimen symmetrischen oder asymmetrisch Schlüsseln, oder, wie in dieser Arbeit, zum Erzeugen eines One-Time-Pads.

Das Problem ist allerdings, Zufallszahlen zu generieren, die wirklich ”zufällig“ sind. Man spricht hier von echten Zufallszahlen. Echter Zufall bedeutet, daß un- abhängig von allen vorherigen Ausgaben für die Wahrscheinlichkeit p der nächsten Bit-Ausgabe eines Zufallszahlen-Generators immer gilt: p([0]) =[1] und p(1) =[1]

Das heißt, es ist gleichwahrscheinlich, ob das nächste Bit eine 0 oder eine 1 wird.

Obwohl diese Eigenschaft sehr einfach klingt, sind Generatoren, die echte Zu- fallszahlen liefern, selten und teuer. Bekannte Beispiele für echte Zufallszahlen- Generatoren sind z. B. Geiger-Zähler, die zufällige atomare Zerfallsprozesse erfas- sen oder Mikrophone, die Meeresgeräusche aufnehmen und daraus Zahlen produ- zieren.

Da echter Zufall für die meisten Anwendungen zu teuer oder nicht einsetzbar ist, werden in der Praxis sogenannte Pseudozufallszahlen eingesetzt. Pseudozu- fallszahlen sind keine echten Zufallszahlen, mit obigen Eigenschaften, sondern nur Zahlen, die zufällig aussehen. Sie sind nicht wirklich zufällig, sondern werden nach einer bestimmten Vorschrift berechnet und sind damit, bei bekannter Vorschrift, auch vorhersagbar.

Pseudozufallszahlen sind bei unbekannter Berechnungsvorschrift, oder unbekann- tem Startwert (s. unten) innerhalb einer bestimmten Periode, d. h. Länge der Generatorausgabe scheinbar zufällig und nicht vorhersagbar. Danach aber wie- derholen sie sich gemäß der Periode. Pseudozufallszahlen-Generatoren (PRNG^[1]) arbeiten meist mit einem kleinen initialen Zufallswert, der mehr oder weniger echten Zufall repräsentiert, wie z. B. die aktuelle Systemzeit oder zufällige Maus- bewegungen des Benutzers. Aus diesem Initialen Wert (engl. Seed) wird dann die ganze Pseudo-Zufallsfolge abgeleitet. Viele Pseudo-Generatoren sind anfällig ge- gen bestimmte Attacken, daher wird für die One-Time-Pads unseres Zyklischen Protokolls eine von [17] zunächst kryptanalysierte und danach verbesserte Version des Pseudozufallszahlen-Generators des DSA-Standards aus [27] verwendet.

Zuerst zur Beschreibung der Arbeitsweise des DSA-Generators: Dargestellt ist die Berechnung der nächsten Pseudo-Zufallszahl output[i] zum Zeitpunkt i.

1. Der PRNG hat einen internen Zustand Xi, dieser wird am Anfang (i = 0) mit dem Seed initialisiert.
2. Der PRNG akzeptiert in jedem Schritt i eine optionale Eingabe Wi, diese sollte möglichst echter Zufall sein und dem System Entropie hinzufügen
3. Es wird berechnet:

-output[i] = hash(Wi + Xi mod 2[160]) hash bezeichnet eine HAsh-Funktion, beispielsweise SHA-1.
-Xi+1 = Xi + output[i] + 1 mod 2[160]

output[i] ist die nächste Zufallszahl. Da die nächste Zufallszahl vom Berechnen von output, also in erster Linie von der Qualität der Hash-Funktion abhängt, ist die ausgegebene Pseudo-Zufallszahlenfolge output[i] bei entsprechend guter Hash-Funktion wie z. B. SHA-1 schwer von einer echten zu unterscheiden. Die kryptographische Analyse dieses Generators wird Abschnitt 4.1 vorweggenommen, da aus der Analyse heraus ein neuer Generator entsteht, der den bekannten Attacken standhält. Im Folgenden wird beschrieben, wie sich der DSA-PRNG bei typische GeneratorAttacken aus [17] verhält und gegebenenfalls verbessert werden kann.

Falls ein Angreifer per Zufall an den initialen Seed, oder zu irgendeinem Zeitpunkt i an den internen Zustand Xi gelangt, so kann er daraus bei diesem Generator im Gegensatz zu vielen anderen keinen Gewinn erzielen, da durch das wiederholte Eingeben weiterer Entropie Wi der Angreifer die nächsten Ausgaben und internen Zustände des Generators nicht vorherberechnen kann. (Gäbe es die Entropie Wi nicht, so könnte er alle Ausgaben vorhersagen.)

Input based Attack

Problematisch ist jedoch eine sogenannte Input Based Attack, bei der der Angrei- fer die Eingaben Wi beliebig verändern kann. Dies ist nicht unrealistisch. Wird z. B. die Systemzeit als zusätzliche Entropie verwendet, und kann der Angreifer diese festlegen, so wird durch das Setzen von Wi = Wi−1 − output[i − 1] − 1 die Ausgabe output[i] konstant gehalten. Der Angreifer erreicht dadurch, daß immerwieder die gleiche Zahl vom PRNG ausgegeben wird. Da für den internen Zustand Xi gilt Xi = Xi−1+output[i − 1]+1, ist output[i] = hash(Wi + Xi mod 2[160]) = hash(Wi−1 − output[i − 1] − 1 + Xi−1 + output[i − 1] + 1 mod 2[160]) = hash(Wi−1 + Xi−1 mod 2[160]) = output[i − 1]. Auf diese Weise wird zwar der interne Zustand Xi nicht erraten, aber die Ausgabe des PRNG festgesetzt. Eine einfache Abhilfe gegen die Input Based Attack bietet hier das Hashen sämtlicher Eingabe-Entropien mit Hilfe einer kryptographischen Einweg-Funktion, also Wi = hash(Entropie). Der Angreifer kann keine Entropie bestimmen, die gehasht sein gewünschtes Wi ergibt.

Filling in the Gaps

Ein anderes Problem ist die Filling in the Gaps-Atta>hier Xi, Xi+2 und output[i + 1]. Er benötigt output[i], das Gap, die Zufallszahl, die vor der aktuellen Zahl vom Generator produziert wurde. Er kann dies über output[i] = Xi+2 − Xi − 2 − output[i + 1] berechnen. Abhilfe für diese Sicherheitslücke bringt hier das Hashen der Ausgabe, vor der Berechnung von Xi+1: Xi+1 = Xi + hash(output[i] + Wi) mod 2[160].

Mit den beschriebenen Verbesserungen scheint der DSA-PRNG sehr sicher zu sein und allen Attacken zu widerstehen. Er wird in dieser Arbeit nicht nur als Generator für Schlüsselpaare verwendet, sondern auch zum Erzeugen von One- Time-Pads.

Es können mit diesem Generator keine symmetrischen Schlüssel länger als 160-Bit sicher erzeugt werden, denn der SHA-Algorithmus hasht alle Entropie-Eingaben auf 160-Bit. Dies bedeutet, es steht für die Erzeugung eines geheimen Schlüssels auch nicht mehr Entropie als 160 Bit zur Verfügung. Das Erzeugen längerer Schlüssel erhöht nicht die Sicherheit. Ähnliches gilt für das Generieren von asym- metrischen Schlüsseln, z. B. beim Erzeugen von Primzahlen beim RSA-Algorith- mus. Auch hier kann nur mit einer Unsicherheit von 160 Bit gerechnet werden. Allerdings sind 160 Bit ausreichend sicher, wie bereits mehrfach erwähnt.

Die Güte der generierten Zufallszahlen wird in Abschnitt 4.1.3 mit dem sogenannten FIPS 140-1 Test untersucht.

2.6 Logic of Authentication

Ein Protokoll ist eine Kette von Aktionen und Vorschriften, an der mehrere Par- teien beteiligt sind. Bei den Aktionen handelt es sich zumeist um das Versenden von Nachrichten. Nach dem erfolgreichen Durchführen aller Aktionen ist ein be- stimmtes Protokollziel erreicht. Ein kryptographisches Protokoll dient meist dem Austausch geheimer Informationen oder der gegenseitigen Authentifizierung von Protokollteilnehmern.

In [19] wurde mit der Logic of Authentication oder BAN-Logik^[1] eine formale Lo- gik zur Analyse kryptographischer Protokolle entworfen. Aufgabe dieser Logik ist es, die Protokollziele genauer zu identifizieren sowie zu überprüfen, welche Infor- mationen die Teilnehmer miteinander ausgetauscht haben bzw. glauben, mitein- ander ausgetauscht zu haben. Der Zentrale Begriff der BAN-Logik ist der Glaube der Teilnehmer an bestimmte wahre oder unwahre Tatsachen. Die Teilnehmer des Protokolls können Nachrichten oder Informationen vertrauen und diesen glauben. Glaubt ein Protokoll-Teilnehmer einer Information, heißt das allerdings noch lan- ge nicht, daß diese wirklich gültig ist. Er kann sich dabei unter Umständen geirrt haben.

Der erste Schritt bei der Analyse eines Protokolls mit der BAN-Logik ist es, initia- le Annahmen über die Protokollumgebung, sowie das Wissen, bzw. den Glauben der am Protokoll beteiligten Parteien zu identifizieren und entsprechend der Logik zu formulieren. Solche sog. Assumptions können z. B. die Annahmen über den Besitz öffentlicher, privater bzw. geheimer Schlüssel der verschiedenen Protokollteilnehmer sein. Es wird bestimmt, welcher Teilnehmer in Besitz von welchem Schlüssel ist, und welchem anderen Teilnehmer er was glaubt.

Im zweiten Schritt werden die einzelnen Nachrichten des Protokolls in eine ideali- sierte, formalisierte Form gebracht und nacheinander von der Logik interpretiert.

Analog zu einem Expertensystem gibt es eine Menge von Ableitungsregeln und eine Menge von Fakten bzw. Prädikaten, nämlich die formalisierten Nachrichten des Protokolls und die initialen Annahmen. Iterativ werden dann auf jede Nach- richt die Ableitungsregeln angewandt und somit neue Prädikate erzeugt. Läßt sich keine weitere Ableitungsregel mehr anwenden, so ist die BAN-Verifikation schließlich beendet. Aus der dann vorhandenen großen Menge von abgeleiteten Prädikaten versucht man die Protokollziele (Goals) zu finden. Diese sind ebenso im vorhinein formalisierte Prädikate, die den gewollten Schlüsselaustausch oder die durchgeführte Authentifizierung, das Ziel des Protokolls, beschreiben. So wäre z. B. ”TeilnehmerAglaubt,daßKdergeheimeSchlüsselzwischenAundTeil-

nehmer B ist.“ ein Protokollziel. Werden solche Prädikate gefunden, so erfüllt das Protokoll zunächst einmal zumindest seine Aufgabe.

Es ist weiterhin interessant, die Menge der abgeleiteten Prädikate zu analysieren und mögliche Schwachstellen zu finden. Außerdem kann das Protokoll mit anderen, schwächeren Annahmen und veränderten Nachrichten getestet und optimiert werden. Dadurch können u. U. überflüssige Nachrichten oder Voraussetzungen erkannt und entfernt werden.

2.6.1 Notation der Logic of Authentication

Im Hinblick auf Lesbarkeit und die später folgenden Analysen in Abschnitt 4.2, wird hier die Prädikatschreibweise aus [8] vorgestellt. Im folgenden bezeichnet A eine Entität. Entitäten sind die einzelnen Teilnehmer des Protokolls. X stellt irgendeine beliebige Information oder einen Sachverhalt dar. K oder Ka sind Schlüssel, wobei K einen symmetrischen und Ka einen asymmetrischen Schlüssel bezeichnet.

Prädikate

In Tabelle 2.1 sind die grundlegenden BAN-Prädikate aufgelistet. Prädikate P (Q) sind Aussagen über Eigenschaften. Das Prädikat P (Q) ist die Aussage, daß Q die Eigenschaft P erfüllt.

Abbildung in dieser Leseprobe nicht enthalten

A glaubt die Information X, d. h. A handelt so, als wäre X wahr. Dies ist das zentrale Prädikat der Logik. A sieht die Information X. Dies geschieht z. B. durch das Empfangen einer Nachricht mit Inhalt X. A hat, zu einem Zeitpunkt der (längeren) Vergangen- heit, einmal X in einer Nachricht verschickt. Die Information X, bzw. der Sachverhalt X ist aktuell, beispielsweise vor kurzer Zeit von jemandem gesendet worden. Zeit wird in der BAN-Logik in zwei Teile ein- geteilt: Vergangenheit und Gegenwart. Die Gegenwart ist der Zeitpunkt der gerade aktuellen Ausführung des Protokolls. Vergangenheit alles, was zeitlich davor liegt. Damit kann man sich gegen Replay-Attacken, bei denen Nachrichten aus vergangenen Protokoll-Durchläufen er- neut verwendet werden, schützen. fresh(X) gilt, wenn X davor in noch keiner Nachricht verschickt wurde. In der Praxis wird die Auswertung von fresh() meist durch Zeitstempel realisiert.

Ka ist der öffentliche Schlüssel von A, den dazu passen- den geheimen Schlüssel K−[1] a kenntnurA,bzw.einevon A später autorisierte Person.

Der Schlüssel K−[1]a istbzgl.derChiffreinverszumöffent- lichen Schlüssel Ka. K−[1] a istderprivateSchlüssel. Der Schlüssel K ist ein geheimer symmetrischer Schlüssel zwischen A und B. Nur A und B, bzw. von ihnen autorisierte Teilnehmer kennen K.

A ist zuständig für den Sachverhalt X, und kontrolliert ihn, d. h. A ist eine Autorität in Bezug auf X. Zum Bei- spiel müssen in manchen Protokollen geheime Schlüssel von einer dafür zuständigen Autorität generiert werden. Mit diesem Prädikat gesteht man A die Fähigkeit zum Generieren guter geheimer Schlüssel zu. encrypt(X, K) X ist mit dem Schlüssel K verschlüsselt worden. Aus dem Chiffrat kann X ohne Kenntnis von K nicht rekon- struiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Prädikate der BAN-Logik

Ableitungsregeln der BAN-Logik haben die Form: P1,P2,...,Pn P′ Die Schreibweise bedeutet, daß aus der Gültigkeit der Prädikate P1, . . . , Pn die Gültigkeit des Prädikats P′ folgt.Tabelle 2.2 führt einige der grundlegenden Ableitungsregeln der BAN-Logik auf.

Glaubt A, daß K ein symmetrischer Schlüssel zwischen A und B ist, und empfängt A ein mit K verschlüsseltes Datum, so glaubt A, daß B dieses geschickt hat. believes(A, shared key(K, A, B)), sees(A, encrypt(X, K)) believes(A, said(B, X)) Für öffentliche Schlüssel gilt ähnliches. Glaubt A, daß Kb der öffentliche Schlüssel von B ist, und empfängt A eine mit K−[1]a verschlüsselteNachricht,soglaubtA,daß diese von B stammt.

believes(A, public key(Kb, B)), sees(A, encrypt(X, K−[1]b )) believes(A, said(B, X)) Glaubt A, daß X aktuell ist, und daß B den Sachverhalt X gesendet hat, so glaubt A, daß B auch an X glaubt. believes(A, f resh(X)), believes(A, said(B, X)) believes(A, believes(B, X)) Diese Regel ist gefährlich: Sie impliziert, daß jeder Sender auch wirklich das glaubt, was er verschickt. Ein Sender lügt also nicht. Man spricht von Honesty, wenn kein Protokollteilnehmer lügt. In den Erweiterungen zur BAN-Logik wird auf dieses Pro- blem eingegangen.

Wenn A glaubt, daß B Kontrolle über X hat, und A glaubt, daß B an X glaubt, so glaubt auch A an X. believes(A, controls(B, X)), believes(A, believes(B, X)) believes(A, X)

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Grundlegende BAN-Ableitungsregeln

Die Menge der BAN Regeln wird vervollständigt durch Regeln zum Auftrennen von Nachrichten. Glaubt A z. B. einer Nachricht X = X1, X2, . . . , Xn, so glaubt A auch allen einzelnen X1, X2, . . . , Xn. Eine Übersicht über die vollständige Regelmenge findet sich in [19] oder [20].

Beispielableitung Zur Verdeutlichung wird im Folgenden eine Ableitung nach BAN-Regeln demon- striert.

Gegeben sei das Prädikat believes(A, shared key(K, A, B)).

Protokoll-Entität A glaubt, daß K ein geheimer Sitzungsschlüssel zwischen A und Entität B ist. Nun schickt B die Nachricht encrypt(X, K) an A. Dies bedeutet, daß ein neues Prädikat, sees(A, encrypt(X, K)) der Menge der Prädikate hinzugefügt wird. Daher kann beispielsweise die erste oben vorgestellte Regel angewendet werden, welche ein weiteres Prädikat believes(A, said(B, X)) erzeugt.

Die Menge der Prädikate nach dem Verschicken der Nachricht besteht demnach aus den Prädikaten:

believes(A, shared key(K, A, B)), sees(A, encrypt(X, K)), believes(A, said(B, X)). Sukzessiv wächst auf diese Weise die Menge der Prädikate. Kommen neue Prädikate hinzu, können weitere Regeln angewendet werden, die wiederum neue Prädikate produzieren. Nach dem Versand einer Nachricht, werden solange Regeln auf die Prädikate angewendet, bis keine Regel mehr anwendbar ist. Dann wird mit der nächsten Nachricht fortgefahren.

2.6.2 RVLogik, eine Erweiterung der BAN-Logik

Wird ein Protokoll erfolgreich mit der BAN-Logik verifiziert, so ist dieses Proto- koll noch lange nicht wirklich sicher. Bei der initialen Festlegung der Assumptions kann der Verifizierer genauso von falschen Voraussetzungen ausgegangen sein, wie bei der Abstraktion und Idealisierung der jeweiligen Nachrichten. Die Assump- tions in der realen Welt können ganz andere sein, als der Verifizierer angenom- men hat. Beispielsweise wird in [8] beschrieben, wie bei der Durchführung der ur- sprünglichen BAN-Analyse aus [19] für das Public-Key-Protokoll nach Needham- Schroeder von einer falschen Idealisierung ausgegangen wurde, die lange unent- deckt geblieben ist. Genauso können die gesuchten Protokollziele falsch formuliert werden. Daneben fehlt die Möglichkeit, negative Aussagen zu überprüfen. Es ist ohne Weiteres nicht möglich, zu testen, ob A ein bestimmtes X nicht glaubt.

Daneben geht die BAN-Logik von bestimmten kryptographischen Idealen aus, z. B. der perfekten Sicherheit der im Protokoll benutzten Chiffriersysteme. Die Information X aus encrypt(X, K) kann wirklich nur derjenige lesen, der K besitzt, unabhängig von der gewählten Schlüssellänge von K oder der Sicherheit der Chiffre, die encrypt() zugrunde liegt. Genauso können böswillige oder kompromittierte Protokollteilnehmer, die neben dem Big-Brother-Abhören des kompletten Netzverkehrs auch noch Insider-Informationen besitzen nur schwer simuliert werden. Hierfür wären mehrere Simulationsdurchläufe mit verschiedenen Szenarien für kompromittierte Teilnehmer notwendig.

Die genannten Probleme fordern aus diesen Gründen einen bewußten Umgang mit der BAN-Logik und lassen sich nicht durch Veränderungen der Logik beheben. Der Verifizierer muß entsprechend vorsichtige und gewissenhafte Idealisierungen und treffende Annahmen bestimmen, sowie die Ergebnisse einer Analyse entsprechend interpretieren.

Für andere Nachteile gibt es allerdings Erweiterungen, wie die ReVere-Logik (kurz RVLogik) aus [8], die die Analysemethoden verstärken und so die Fehlersuche in Protokollen ohne großen Mehraufwand sicherer macht.

Explizite Interpretationsregeln Im allgemeinen entsteht durch das Formalisieren der Nachrichten ein Unterschied zwischen der Bedeutung der tatsächlichen Nachricht, die laut Protokollspezifika- tion geschickt wird, sowie der formalisierten Nachricht, die während der Analyse verschickt wird.

Die RVLogik versucht durch das explizite Angeben von Nachrichten-Interpreta- tionen diesen Unterschied zu minimieren. Ein Beispiel: empfängt Entität A von B einen Schlüssel K, so wird dies auf believes(A, said(B, K)) formalisiert. Im tatsächlichen Protokoll soll A aber jetzt K als gemeinsamen Schlüssel von A und B interpretieren. Eine derartige Formulierung ist in der BAN-Logik so ohne weiteres nicht möglich. Die RVLogik jedoch erlaubt eine Interpretationsregel, die im Klartext lauten würde:

”empfängtAvonBirgendein K, so glaubt A, daß dieses K ein gemeinsamer Schlüssel zwischen A und B ist”. Formal läßt sich das ausdrücken durch believes(A, said(B, K)) believes(A, shared key(K, A, B)). Allgemein erweitert die RVLogik BAN um die Regeltypen believes(A, said(B, N )) ([1]) und believes(A, said(B, N′)) sees(A, N ) (2) sees(A, N′), wobei N eine konkrete formale Nachricht aus dem Protokollablauf ist und N′ eine Formel, die die Interpretation der Nachricht repräsentiert. In N′ können Variablen aus N vorkommen (siehe obiges Beispiel). Die Regeln vom Typ (1) dienen der Interpretation aller authentischen Nachrichten, da hier A bereits weiß, daß die Nachricht von B kommt. Hingegen interpretieren Regeln vom Typ (2) Nachrichten unbekannten Ursprungs. Die RVLogik legt einige Rahmenbedingungen für Interpretationsregeln fest, z. B. daß auf jede formale Nachricht innerhalb des Protokolls höchstens eine Interpretationsregel zutrifft, oder daß in N′ das Schlüsselwort encrypt nicht enthalten sein darf. Mit der entsprechenden Interpretationsregel bekommt so jede Nachricht eine realistische und doch formalisierte Bedeutung.

[...]

---

^[1]ist einem Angreifer D bekannt, so kann er M = D(C) berechnen

^[1]Pseudo-Random-Number-Generator

^[1]Nach M. Burrows, M. Abadi und R. Needham