8.4. Sicherheitstechniken der Anwendungsschicht

8.4.1. Kryptographische Protokolle

Wir werden nachfolgend einige praxisrelevante kryptographische Protokolle diskutieren, die jeweils eine bestimmte Menge von Aufgaben erfüllen. Zuvor sollen kurz noch einige allgemeine Bemerkungen dazu erfolgen.

Generell versteht Menezes unter einem kryptographischen Protokoll (bzw. kurz nur Protokoll genannt) einen verteilten Algorithmus, der durch eine Folge von Schritten definiert wird, die exakt die Aktionen spezifiziert, die zwei oder mehr Partner ausführen müssen, um ein bestimmtes Sicherheitsziel zu erreichen.

Dagegen handelt es sich bei einem Mechanismus um einen allgemeineren Begriff, der Protokolle, Algorithmen und nichtkryptographische Techniken (z.B. Hardware-Schutz oder Schutzmechanismen des Betriebssystems) umfaßt, die im Zusammenspiel ein bestimmtes Sicherheitsziel erreichen sollen. Die Algorithmen legen dabei die Schritte fest, die durch einen einzelnen Partner auszuführen sind.

Protokolle spielen in der Kryptographie und natürlich auch auf dem Gebiet der Netzwerk-Sicherheit eine ganz entscheidende Rolle. Gerade in den von uns betrachteten Fällen interagieren in der Regel zwei oder mehrere Partner. Nur durch kryptographisch starke Protokolle können sie ihre Sicherheitsziele erreichen. Dazu gehören die Vertraulichkeit, Integrität, Authentizität und ggf. auch die Unleugbarkeit von Kommunikationsbeziehungen.

Die im Abschnitt 8.2. behandelten Chiffren, digitalen Signaturen, Einweg-Hashfunktionen und Pseudozufallszahlen-Generatoren stellen wichtige Werkzeuge bzw. Bausteine (Menezes spricht von cryptographic tools oder primitives und Schneier von protocol building blocks) dar, die genutzt werden können, um Protokolle aufzubauen. Allerdings gilt generell, daß die Verwendung sicherer kryptographischer Bausteine keineswegs automatisch ein sicheres Protokoll garantiert.

Wir sprechen von einem Protokoll- oder Mechanismus-Fehler, wenn es einem Angreifer gelingt, ein mit dem Protokoll bzw. Mechanismus angestrebtes Sicherheitsziel zu vereiteln, ohne daß er dazu die als Basis verwendeten Algorithmen (z.B. Chiffren und Einweg-Hashfunktionen) brechen muß. Ein Beispiel dafür hatten wir mit der Reflection Attack kennengelernt.

Die real eingesetzten Protokolle sind deshalb sehr sorgfältig zu entwerfen und zu implementieren, wobei es auf die kleinsten Details ankommen kann. Wie viele praktische Beispiele belegen, können geringe Modifikationen an sicheren Mechanismen verheerende Wirkungen haben.

Bevor man also eigene Lösungen entwickelt bzw. implementiert, sollte man sich in der einschlägigen Literatur über potentielle Fallen, Schwächen und Probleme genau informieren und das eigene Werk daraufhin kritisch untersuchen bzw. von Experten untersuchen lassen. Wer keine unnötigen Risiken eingehen will, der sollte Protokolle und deren Implementierungen (Programme und Bibliotheken) einsetzen, die einer gründlichen öffentlichen Analyse unterzogen wurden und die allgemein als sicher angesehen werden.

Welche Folgen eine mangelhafte Implementierung eines an sich als sicher geltenden Protokolls haben kann, wird am Beispiel der PPTP-Implementierung von Microsoft deutlich. PPTP ist das in einem Internet-Draft beschriebene Point-to-Point Tunneling Protocol, das zum Aufbau von virtuellen privaten Netzen (Virtual Private Networks, kurz VPN) genutzt werden kann und wird.

Am 1.6.1998 veröffentlichte die von Bruce Schneier geleitete Firma Counterpane Systems eine Pressemitteilung, in der sie auf eine Reihe ernster Fehler in der von Microsoft entwickelten und kostenfrei verteilten PPTP-Implementierung hinwies. Diese Fehler waren im Rahmen einer von Bruce Schneier und dem "expert hacker" Peter Mudge durchgeführten kryptoanalytischen Untersuchung gefunden worden. In den dazu existierenden FAQ schreibt Schneier:

1. What did Bruce Schneier and Mudge actually do?
They found security flaws in Microsoft PPTP that allow attacks to sniff passwords across the network, break the encryption scheme and read confidential data, and mount denial of service attacks against PPTP servers. They did not find flaws in PPTP, only in Microsoft's implementation of it.
Die beiden Autoren haben im Internet eine detaillierte Beschreibung ihrer Resultate veröffentlicht: http://www.counterpane.com/pptp.html.

An mehreren Stellen in der Pressemitteilung sowie in den FAQ wird auf die Bedeutung der öffentlichen Analyse von Protokollen und deren Implementierungen hingewiesen. Das ist ein sehr wichtiger, generell zu beachtender Punkt. Die folgenden Zitate sollen das noch einmal unterstreichen.

In den FAQ bewertet Schneier die gefundenen Fehler so:

The mistakes they made are not subtle; they're "kindergarten cryptographer" mistakes.
In der Pressemitteilung findet sich eine ähnliche Einschätzung:
According to Mark Chen, CTO of VeriGuard, Inc, a Menlo Park based computer security company, "The flaws in this implementation are quite amateurish." Chen continued, "A competent cryptographic review would have prevented the product from shipping in this form."

Auf die Frage, ob es Alternativen zu PPTP gibt, antwortet Schneier folgendermaßen:

The main alternative is IPSec. It is an open standard, designed under the direction of the IETF. It has been developed completely in public, and is not owned by any one company. It will be used in future VPN products. The gross cryptographic mistakes that we found in Microsoft's PPTP only happen with proprietary protocols, not with public ones such as IPSec.


© Holger Trapp, 14.10.1998