17.06.2014 Aufrufe

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

Sicherheit in vernetzten Systemen - RRZ Universität Hamburg

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

10.2. EINFÜHRUNG IN PUBLIC-KEY-VERFAHREN<br />

Kommunikationspartner verteilt werden muß. Aber auch die Verteilung des öffentlichen Schlüssels<br />

ist nicht ganz unproblematisch und soll im folgenden Abschnitt näher erläutert werden.<br />

10.2.2 Schlüsselverteilung<br />

Gerade bei Public-Key-Verfahren ist die Authentizität der öffentlichen Schlüssel e<strong>in</strong> wichtiges Kriterium,<br />

da sie die Voraussetzung für „<strong>Sicherheit</strong>“ ist. Allerd<strong>in</strong>gs können die öffentlichen Schlüssel<br />

bei der Schlüsselverteilung, die häufig auf unsicheren Wegen, z.B. per E-Mail, erfolgt, diversen Angriffen<br />

ausgesetzt se<strong>in</strong>. Man denke nur an das <strong>in</strong> Abbildung 10.1 dargestellte Szenario: Benutzer A<br />

bittet Benutzer B um Zusendung se<strong>in</strong>es Public Keys. Diese Kommunikation wird von e<strong>in</strong>em Angreifer<br />

X abgehört, der anschließend den von B abgeschickten Public Key abfängt und se<strong>in</strong>erseits e<strong>in</strong>en<br />

entsprechend gefälschten Public Key an Benutzer A weiterleitet mit dem Vermerk „Hier kommt der<br />

Public Key von Benutzer B“. Die Folge dieses gefälschten untergeschobenen Schlüssels ist die Kompromittierung<br />

des Verfahrens. Daraus wiederum resultiert e<strong>in</strong> Verlust der Vertraulichkeit, da <strong>in</strong> diesem<br />

Beispiel Benutzer A nicht mehr vertraulich mit Benutzer B kommunizieren kann.<br />

Benutzer A: "Bitte um Zusendung Ihres Public Keys"<br />

Benutzer A<br />

Angreifer sendet stattdessen<br />

se<strong>in</strong>en Public Key:<br />

"Hier ist der Key von B..."<br />

Benutzer B<br />

Angreifer X<br />

Abbildung 10.1: E<strong>in</strong> mögliches Angriffsszenario<br />

Bei der Verteilung des öffentlichen Schlüssels muß deshalb zum e<strong>in</strong>en die Authentizität des Public<br />

Keys sichergestellt werden, zum anderen muß der Empfänger des Public Keys, diesen auch auf geeignete<br />

Art und Weise verifizieren können. Bei „PGP“ (Pretty Good Privacy, vgl. hierzu auch [PGP]) erfolgt<br />

die Verifikation des öffentlichen Schlüssels über den Abgleich des F<strong>in</strong>gerpr<strong>in</strong>ts, der sich (z.B. auf<br />

Visitenkarten) gut verteilen läßt. Gerade im Zusammenhang mit PGP treten immer wieder Mißverständnisse<br />

bzgl. der Schlüsselverteilung und Authentizität dieser Schlüssel auf. In den letzten Jahren<br />

haben sich PGP-Key-Server zur Verteilung der öffentlichen Schlüssel durchgesetzt. Was jedoch häufig<br />

übersehen wird: Diese Key-Server dienen nur der Verteilung der öffentlichen Schlüssel und bieten<br />

ke<strong>in</strong>e Garantie für die Echtheit der dort vorgehaltenen Schlüssel. Die Überprüfung der Echtheit des<br />

Schlüssels bleibt dem jeweiligen Benutzer überlassen.<br />

Der mit Abstand sicherste Weg die öffentlichen Schlüssel zu verteilen, ist diese bei e<strong>in</strong>em persönlichen<br />

Kontakt zu übergeben. Innerhalb kle<strong>in</strong>er, lokal begrenzter Benutzergruppen läßt sich dies vielleicht<br />

noch realisieren, aber wie soll der öffentliche Schlüssel mit e<strong>in</strong>em Kommunikationspartner <strong>in</strong> Australien<br />

ausgetauscht werden. Und wer will ständig herumreisen, um se<strong>in</strong>en öffentlichen Schlüssel an die<br />

Kommunikationspartner zu verteilen, wenn dafür auch wesentlich e<strong>in</strong>fachere Methoden wie E-Mail<br />

zur Verfügung stehen. Demzufolge müssen Lösungen zur gesicherten Schlüsselverteilung gefunden<br />

werden. E<strong>in</strong> Ansatz ist zunächst, e<strong>in</strong>en sicheren Kanal zur Übermittlung der öffentlichen Schlüssel zu<br />

nutzen. Dies kann beispielsweise e<strong>in</strong>e Standleitung se<strong>in</strong>. Aber bei vielen Kontakten, z.B. nach Australien,<br />

läßt sich e<strong>in</strong> sicherer Kanal nicht immer und nicht überallh<strong>in</strong> etablieren. In diesem Fall könnte<br />

SS 99, Sem<strong>in</strong>ar 18.416: <strong>Sicherheit</strong> <strong>in</strong> <strong>vernetzten</strong> <strong>Systemen</strong> 147

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!