Definition

Kryptographische Protokolle sind Protokolle, bei denen kryptographische Transformationen der Nachrichten ausgeführt werden.

Sie kommen in Betracht, sobald in einem offenen System eine der Grundforderungen der Verlässlichkeit verlangt wird:

• Echtheit,
• Verbindlichkeit,
• Vertraulichkeit,
• Einmaligkeit.

Wesentliche zusätzliche Design-Gesichtspunkte bei kryptographischen Protokollen

• Wer sieht welche Nachrichten? Was kann er daraus herleiten?
• Wer darf sie sehen?
• Wann?
• 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.
• Es ist ausgeschlossen, dass es hierüber zwischen den Beteiligten jemals zu einem Rechtsstreit kommen wird.

Man sollte bei der Konstruktion eines kryptographischen Protokolls möglichst wenig Notwendigkeit für Vertrauen voraussetzen und dieses genau spezifizieren. [Vertrauen ist gut, Kontrolle ist besser. (Lenin) Verhindern ist noch besser. (K. P.)]

Schlüssel sind Informationen, mit deren Hilfe andere Informationen algorithmisch erschlossen werden können.

• Spezialfall des Transformierens.
• Beispiel: Wer c (den Geheimtext) und k (den Schlüssel) kennt, kann m (den Klartext) bestimmen.

Bei kryptographischen Protokollen sind - mehr als sonst bei der Modellierung - alle Modellannahmen kritisch zu hinterfragen.

Typen von Angriffen

Passive Angriffe: Lauschangriff.

Aktive Angriffe: Fälschen von Nachrichten. Auch unterdrücken, erzeugen oder wiederholen (»replay«) von Nachrichten gehört hierzu.

Angriffe durch Teilnehmer (»Cheater«, Mogler) oder Außenstehende (ungebetene Teilnehmer, z. B. »Man in the middle«).

Angriffe durch Kooperation zwischen Teilnehmern untereinander oder zwischen Teilnehmern und Außenstehenden.

Allgemein: Angriffe durch Regelverstöße.

Mögliche Angriffsziele:

• kryptographische Algorithmen (durch Kryptoanalyse),
• Implementation der Algorithmen (Suche nach Programmierfehlern durch »Reverse Engineering«),
• Fehler in der Spezifikation des Protokolls,
• kryptographische Infrastruktur, Techniken und Geräte (z. B. Schlüsselerzeugung, PC-Tastatur),
• Teilnehmer (social engineering),
• Verfügbarkeit (z. B. DoS = Denial of Service oder Message Blocking).

Darsteller in kryptographischen Protokollen

Durch die Annahme des mächtigen Treuhänders T lassen sich viele Protokolle deutlich vereinfachen, insbesondere wenn nur symmetrische Verschlüsselung verwendet wird - auf Kosten verstärker Vertrauensannahmen. (Vgl. den Ticket-Server bei Kerberos, also die Needham-Schroeder-Authentisierung).

Bei Authentisierungs- oder Zero-Knowledge-Protokollen werden Alice und Bob manchmal ersetzt durch

Vorteil dieser (semi-) formalisierten Rollenbesetzung: Man übersieht nicht so leicht Vertrauensannahmen und Angriffsmöglichkeiten auf das Protokoll.

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 (Relationen) bestehen. (Z. B.: Objekt c entsteht durch AES-Verschlüsselung aus Objekt m mit Objekt k als Schlüssel - c = AES_k(m).)

T = Menge von Zeitpunkten (i. a. 0, 1, 2, ..., n, also ein Intervall natürlicher Zahlen, eine diskrete Zeitachse oder eine durchnummerierte Folge von Protokollschritten.)

Relationen (können auch zeitabhängig sein):

Die Folge von Aktionen des Protokolls ist mit T indiziert und besteht aus Instanzen der Relationen creates (oder deren Verfeinerungen) 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.
• ...

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. Und in jedem Einzelfall gibt es nicht das richtige Modell. Es kann wichtig sein, mehrere Modelle zu betrachten, um möglichst viele Seiteneffekte zu erkennen.

Zu beweisen ist:

1. Wenn es um Vertraulichkeit geht, dass jedes Objekt nur von den dafür berechtigten Subjekten gesehen wird.
   [Bei einfachen Protokollen ist dabei oft die gesamte Zeitdauer zusammenfassbar, so dass insgesamt nur die Einhaltung der Zugriffsmatrix nachzuweisen ist, s. u.]
2. Wenn es um Echtheit geht, dass jedes Subjekt auch wirklich jedes Objekt sieht, das es sehen soll, und zwar in unveränderter Form.
3. Wenn es um Verbindlichkeit geht, dass ein Subjekt nachweisbar ein bestimmtes Objekt gesehen (oder erzeugt) hat.
4. Wenn es um Einmaligkeit geht, dass ein Subjekt von einem Objekt, das es gesehen hat, keine Kopie erzeugen kann
   [oder keine unbemerkte Kopie erzeugen kann].

»Gewöhnliche« formale Spezifikationsmethoden (aus dem Software-Engineering)

• sind vom Ansatz her nur zum Beweis der Korrektheit geeignet (z. B., dass B eine Nachricht m wirklich sieht),
• nicht aber zum Beweis der Sicherheit (z. B., dass niemand sonst m sehen kann).

Beispiel: Hybride Verschlüsselung