Kryptographische Protokolle
... sind Protokolle, bei denen kryptographische Transformationen
der Nachrichten ausgeführt werden.
... müssen verwendet werden, sobald in einem offenen System
eine der Grundforderungen an Sicherheit verlangt wird:
- Vertraulichkeit,
- Integrität,
- Verbindlichkeit.
Kryptographische Protokolle können nicht die Verfügbarkeit schützen.
[Anonymität kann als Teil der Vertraulichkeit angesehen werden
(Vertraulichkeit der Identität); ebenso Authentizität
als Teil der Integrität (Integrität der Identität).
Nichtabstreitbarkeit ist Teil der Verbindlichkeit.]
Wesentliche zusätzliche Design-Gesichtspunkte bei kryptographischen
Protokollen
- Wer sieht welche Nachrichten?
- Wann?
- Wer darf sie sehen?
- Wer kann die Nachrichten ändern?
- Wer vertraut wem?
- Welche Angriffe auf das Protokoll sind möglich?
- Mit welchen Ressourcen?
- Was bewirken Protokollverstöße (z. B. Mogeln)?
»Vertrauen« bedeutet: Alles (oder ein spezifizierter Teil dessen) was A weiß, darf auch B wissen. &emdash;
Man sollte möglichst wenig Notwendigkeit für Vertrauen voraussetzen,
dieses genau spezifizieren.
(Vertrauen ist gut, Kontrolle ist besser: Lenin)
Schlüssel sind Informationen, mit deren Hilfe andere
Informationen algorithmisch erschlossen werden können.
(Das Erschließen von Informationen ist ein Spezialfall
des Transformierens, also des Erzeugens.)
Alle Modellannahmen sind kritisch zu hinterfragen.
Typen von Angriffen
Passive Angriffe: Lauschangriff.
Aktive Angriffe: Fälschen von Nachrichten. Auch unterdrücken, erzeugen oder wiederholen (`replay') von Nachrichten.
Angriffe durch Außenstehende (z. B. `Man in the middle')
oder Teilnehmer (`Cheater', Mogler).
Angriffe durch Kooperation zwischen Teilnehmern untereinander
oder zwischen Teilnehmern und Außenstehenden.
Mögliche Angriffsziele:
- kryptographische Algorithmen (durch Kryptoanalyse),
- kryptographische Techniken und Geräte
(z. B. Schlüsselerzeugung, PC-Tastatur),
- Implementation der Algorithmen
(Programmierfehler),
- Fehler in der Spezifikation des Protokolls.
Ferner sind Angriffe auf Teilnehmer (social engineering)
oder auf die Verfügbarkeit möglich (DOS = Denial of Service
oder Message Blocking).
Darsteller in kryptographischen Protokollen
| A | Alice | Teilnehmerin jedes Protokolls
|
|---|
| B | Bob | Zweiter Teilnehmer, falls benötigt
|
|---|
| C | Carol | Dritte Teilnehmerin, falls benötigt
|
|---|
| D | Dave | Vierter Teilnehmer, falls benötigt
|
|---|
| ... | | (Weitere Teilnehmer bei Bedarf ad hoc)
|
|---|
| E | Eve | Eavesdropper, passive Angreiferin
|
|---|
| M | Mallory | Man in the Middle, aktiver Angreifer
|
|---|
| N | Nancy | Notar, mehr oder weniger vertrauenswürdig
|
|---|
| T | Trent | Vertrauenswürdiger Vermittler (Trusted Arbitrator)
|
|---|
Durch die Annahme eines Vermittlers T lassen sich viele
Protokolle deutlich vereinfachen, insbesondere wenn nur
symmetrische Verschlüsselung verwendet wird.
(Vgl. den Ticket-Server bei Kerberos, also die
Needham-Schroeder-Authentisierung).
Bei Authentisierungs- oder Zero-Knowledge-Protokollen werden
Alice und Bob manchmal ersetzt durch
| P | Peggy | Prover
|
|---|
| V | Victor | Verifier, Kontrolleur
|
|---|
Modellierung eines kryptographischen Protokolls
S = Menge von Subjekten (Teilnehmern, z. B. Alice, Bob, ...)
D = Menge von (Daten-)Objekten (Nachrichten)
Zwischen verschiedenen Objekten können Beziehungen bestehen.
(Z. B.: Objekt c entsteht durch DES-Verschlüsselung aus
Objekt m mit Objekt k als Schlüssel - c = DESk(m).)
T = Menge von Zeitpunkten (i.a. 0,1,2,...,n, also ein Intervall natürlicher Zahlen)
Relationen (u. a.) (können auch zeitabhängig sein):
| trusts Teilmenge von S×S | »A vertraut B«
|
|---|
| sees Teilmenge von S×D | »A sieht m«,
|
|---|
| creates Teilmenge von S×D | »A erzeugt m«,
|
|---|
| transmits Teilmenge von S×D×S | »A übermittelt m an B«.
|
|---|
Die Folge von Aktionen des Protokolls ist mit T indiziert
und besteht aus Instanzen der Relationen creates
oder transmits.
Modellannahmen (»Axiome«)
(Zur besseren Verständlichkeit nur semiformal aufgeschrieben.)
- A erzeugt m ===> A sieht m.
- A sieht m und A übermittelt m an B ===> B sieht m.
- ...
Weitere bei Bedarf, je nach Modell; evtl. ist es auch wichtig, Zeitpunkte zu berücksichtigen.
E = Eve, die passive Angreiferin, ist gekennzeichnet durch
- A übermittelt m an B ===> E sieht m.
Es gibt kein kanonisches Modell für alle Zwecke.
Zu beweisen ist:
- Wenn es um Vertraulichkeit geht, daß jedes Objekt
nur von den dafür berechtigten Subjekten gesehen
wird.
[Bei einfachen Protokollen ist dabei oft die gesamte Zeitdauer zusammenfaßbar,
so daß insgesamt nur die Einhaltung der Zugriffsmatrix
nachzuweisen ist.]
- Wenn es um Integrität geht, daß jedes Subjekt auch
wirklich jedes Objekt (in unveränderter Form) sieht,
das es sehen soll.
- Wenn es um Verbindlichkeit geht, daß ein Subjekt ein bestimmtes Objekt gesehen
(oder erzeugt) hat.
Dabei wird die Sicherheit der kryptographischen Grundfunktionen
und der Implementation angenommen.
»Gewöhnliche« formale Spezifikationsmethoden
(aus dem Software-Engineering)
- sind vom Ansatz her nur zum Beweis der Korrektheit geeignet
(z. B., daß B eine Nachricht m wirklich erhält),
- nicht aber zum Beweis der Sicherheit
(z. B., daß niemand sonst ein Datenobjekt sehen kann).
Z. B. sind Angreifer und Mogler nicht modellierbar.
Vorlesung Datenschutz und Datensicherheit
Sommersemester 1996, Fachbereich Mathematik
Johannes-Gutenberg-Universität Mainz
Zurück zum Inhaltsverzeichnis
Autor: Klaus Pommerening, 24. Juni 1996; letzte Änderung: 24. September 1996.
E-Mail an Pommerening@imsd.uni-mainz.de.