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.

KAPITEL 5. KRYPTOGRAPHISCHE VERFAHREN<br />

heimnis. Alice sendet h zusammen mit M an Bob. Bob, der G kennt, kann ebenfalls H´MGµ bilden<br />

und das Ergebnis mit h vergleichen. Wenn die Werte übere<strong>in</strong>stimmen, weiß Bob, daß die Nachricht M<br />

wirklich von Alice geschickt wurde. Da nur er und Alice das Geheimnis G kennen, hätte niemand außer<br />

Alice den Hashwert h generieren können, und da H e<strong>in</strong>e E<strong>in</strong>weg-Hashfunktion ist, ist es für dritte<br />

auch trotz der Kenntnis von h und M unmöglich G zu berechnen. Bob weiß außerdem, daß der Text<br />

M unverändert angekommen ist. Hätte e<strong>in</strong>e dritte Partei die Nachricht M durch e<strong>in</strong>e andere Nachricht<br />

M ¼ ersetzt, wäre der resultierende Hashwert h ¼ H´M ¼ Gµ unterschiedlich zu dem mitgeschickten<br />

h H´MGµ. Diese Art der Authentifizierung f<strong>in</strong>det u.a. bei IPSec Verwendung.<br />

Der Nachteil dieses Verfahrens ist es, daß es dritten gegenüber ke<strong>in</strong>e Authentifizierung bietet (“nonrepudiation”).<br />

Alice kann sich zwar von der Identität Bobs überzeugen, hat aber ke<strong>in</strong>e Möglichkeit,<br />

e<strong>in</strong>er dritten Person Clara zu beweisen, daß die Nachricht tatsächlich von Bob stammt, da Clara weder<br />

das Geheimnis G kennt, noch, bei Offenlegung des Geheimnisses, aus G auf Bob schließen kann.<br />

Der Geburtstagsangriff<br />

Der Geburtstagsangriff beruht auf dem sogenannten Geburtstagsparadoxon und verdeutlicht, warum<br />

man darauf achten sollte, ke<strong>in</strong>e E<strong>in</strong>weg-Hashfunktion mit zu kle<strong>in</strong>em Hashwert zu benutzen. Mit<br />

dem Geburtstagsparadoxon hat es folgende Bewandtnis: Die kle<strong>in</strong>ste Anzahl an Personen <strong>in</strong> e<strong>in</strong>em<br />

Raum, so daß die Wahrsche<strong>in</strong>lichkeit, daß e<strong>in</strong>e dieser Personen den selben Geburtstag wie man selbst<br />

hat, größer als 50% ist, beträgt 253. Doch die kle<strong>in</strong>ste Anzahl an Personen, die <strong>in</strong> e<strong>in</strong>em Raum se<strong>in</strong><br />

müssen, so daß die Wahrsche<strong>in</strong>lichkeit, daß zwei dieser Personen am selben Tag Geburtstag haben,<br />

größer als 50% ist, beträgt nur 23. Dieses erklärt sich durch die Tatsache, daß man mit 23 Personen<br />

253 verschiedene Paare bilden kann. Diesen Umstand macht sich der Geburtstagsangriff zu nutze: Der<br />

gewöhnliche Brute Force Angriff auf e<strong>in</strong>en Hashwert ist, daß man für e<strong>in</strong>en Hashwert H´Mµ e<strong>in</strong>en<br />

Text M ¼ sucht mit H´M ¼ µH´Mµ. Bei e<strong>in</strong>er Hashlänge von 64 Bit s<strong>in</strong>d so bis zu 2 64 Hashwerte<br />

zu berechnen. Bei e<strong>in</strong>er Rechenleistung von 1.000.000 Berechnungen pro Sekunde wäre die Dauer<br />

e<strong>in</strong>es solchen Angriffs 600.000 Jahre. Der Geburtstagsangriff verschiebt die Aufgabenstellung des<br />

Angriffs e<strong>in</strong> wenig. Anstatt daß zu e<strong>in</strong>em existierenden H´Mµ e<strong>in</strong> M ¼ gefunden werden soll, werden<br />

hier zwei Dokumente M und M ¼ gesucht, die den selben Hashwert ergeben. Dieses geschieht i.a.<br />

so, daß am Anfang zwei Texte existieren, die so modifiziert werden sollen, daß sie am Ende den<br />

gleichen Hashwert ergeben. Dieses geschieht, <strong>in</strong>dem an beiden Dokumenten unauffällige, nur bei<br />

e<strong>in</strong>gehender Untersuchung der Dokumente erkennbare Veränderungen vorgenommen werden (z.B.<br />

E<strong>in</strong>fügen von Leerzeichen oder ähnliches). Die Hashwerte für die verschiedenen Versionen der beiden<br />

Dokumente werden berechnet und zwischengespeichert. Nun haben wir die Situation, <strong>in</strong> der wir nur<br />

e<strong>in</strong> Paar mit gleichem Hashwert benötigen. Im allgeme<strong>in</strong>en s<strong>in</strong>d bei e<strong>in</strong>em Hashwert von 64 Bit<br />

nicht mehr als 2 32 Hashwerte zu berechnen, bis zwei passende Versionen gefunden s<strong>in</strong>d. Bei e<strong>in</strong>er<br />

Rechenleistung von 1.000.000 Berechnungen pro Sekunde wäre die Dauer e<strong>in</strong>es solchen Angriffs<br />

etwa e<strong>in</strong>e Stunde. Also sollte man von Hashfunktionen mit e<strong>in</strong>em Hashwert, der kle<strong>in</strong>er als 128 Bit<br />

ist, Abstand nehmen. Bedenkt man weiterh<strong>in</strong>, daß <strong>in</strong> vielen kryptographischen Protokollen, die zum<br />

Abschließen von Verträgen dienen, nicht der eigentliche Text des Vertrags signiert wird, sondern nur<br />

der Hashwert des Vertrags, ist es <strong>in</strong> solchen Fällen ratsam, bevor man den Vertrag unterzeichnet, e<strong>in</strong>e<br />

kle<strong>in</strong>e unmerkliche Veränderung an dem Dokument vorzunehmen und den Hashwert neu zu bilden.<br />

Wenn man nun diesen Hashwert unterzeichnet, kann man sicher se<strong>in</strong>, daß der Vertragspartner nicht<br />

noch e<strong>in</strong>en weiteren, mittels des Geburtstagsangriffs generierten, Vertrag <strong>in</strong> der H<strong>in</strong>terhand hat, der<br />

über denselben Hashwert verfügt, aber e<strong>in</strong>en anderen Inhalt hat. Denn im nachh<strong>in</strong>e<strong>in</strong> wäre dann nicht<br />

mehr festzustellen, welcher der beiden Verträge unterzeichnet wurde.<br />

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

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

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!