Definition

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

Sie müssen verwendet werden, sobald in einem offenen System eine der Grundforderungen der Verlässlichkeit verlangt wird:

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

[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. 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. (Das Erschließen von Informationen ist ein Spezialfall des Transformierens, also des Erzeugens.)

Beispiel: Wer k (den Schlüssel) kennt, kann m (den Klartext) bestimmen.

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),
• Implementation der Algorithmen (Programmierfehler),
• Fehler in der Spezifikation des Protokolls,
• kryptographische Infrastruktur, Techniken und Geräte (z. B. Schlüsselerzeugung, PC-Tastatur).

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

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 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 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 (u. a.) (können auch zeitabhängig sein):

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.
• ...

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. Man sollte stets mehrere (alle?) Modelle betrachten, um möglichst viele Seiteneffekte zu erkennen. [Für Funktionsnachweise reicht, im Gegensatz zu Sicherheitsnachweisen, in der Regel ein Modell.]

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.]
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 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 erzeugt hat.

»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 erhält),
• nicht aber zum Beweis der Sicherheit (z. B., dass niemand sonst ein Datenobjekt sehen kann).

Beispiel: Hybride Verschlüsselung