Sicherheit in Rechnernetzen: - Professur Datenschutz und ...

392
A. Pfitzmann: Datensicherheit und Kryptographie; Lösungen, TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr
391
A. Pfitzmann: Datensicherheit und Kryptographie; Lösungen, TU Dresden, WS2000/2001, 15.10.2000, 15:52 Uhr
problems seit langem bewiesen, vgl. [LaSP_82]). Entweder geben die Teilnehmer auf oder sie
wechseln, sofern möglich, die Schlüsselverteilzentrale.
Mehrere Schlüsselverteilzentralen in Serie: Werden zwischen den Teilnehmern Inkonsistenzen
ihrer Schlüssel festgestellt, so sollten auch die Schlüsselverteilzentralen untereinander die
Konsistenz der Schlüssel auf genau die gleiche Weise testen und, wenn möglich, verändernd
angreifende Schlüsselverteilzentralen umgehen. Dies entspricht dem Wechseln der Schlüsselverteilzentrale
bei „einer Schlüsselverteilzentrale“.
Mehrere Schlüsselverteilzentralen parallel: Stellen die Teilnehmer eine Inkonsistenz der
Summe ihrer Schlüssel fest, so wiederholen sie das Testprotokoll für Schlüsselgleichheit für
jeden einzelnen der addierten Schlüssel und lassen alle inkonsistenten in der Summe weg.
Bleiben nicht mehr genug zu addierende Schlüssel übrig, sollten die Teilnehmer entweder
zusätzliche Schlüsselverteilzentralen verwenden oder ggf. auf ihre Kommunikation unter diesen
Umständen verzichten. Sonst kann ein verändernder Angreifer zwischen den Teilnehmern
die Aufnahme aller ihm unbekannten Schlüssel in die Summe verhindern.
der zur Schlüsselverteilung verwendeten Nachrichten, dann ist der Kreis der jeweils
möglichen Täter auf Schlüsselverteilzentralen und die beiden Teilnehmer beschränkt.
Die Teilnehmer sollten sich direkt nach dem Schlüsselaustausch durch ein Testprotokoll für
Schlüsselgleichheit Gewißheit darüber verschaffen, ob sie den gleichen Schlüssel haben. Dies
kann geschehen, indem sie sich gegenseitig konzelierte Zufallszahlen zuschicken und vom
Partner die Zufallszahl jeweils im Klartext zurückerwarten. (Dieses kleine Kryptoprotokoll ist
natürlich nur sicher, wenn das verwendete symmetrische Konzelationssystem erstens
mindestens einem gewählten Schlüsseltext-Klartext-Angriff, vgl. §3.1.3.2, widersteht und
zweitens ein verändernder Angreifer mit Kenntnis der inkonsistenten Schlüssel zwischen den
beiden Teilnehmern ausgeschlossen wird. Zusätzlich muß noch der in 3-18a erwähnte
Spiegelangriff verhindert werden, etwa indem jeweils nur einer der Teilnehmer Zufallszahlen
schickt und erst alle Antworten abwartet, bevor er selbst Antworten generiert. Zu guter Letzt
kann in diesem kleinen Kryptoprotokoll die Vernam-Chiffre nicht verwendet werden! Denn
bei ihr erführe der Angreifer immer genau den Bereich des Schlüssels, der auf Schlüsselgleichheit
getestet wird. Kurzum: Wir brauchen ein besseres Testprotokoll oder eine sehr sehr
gute Blockchiffre. Ersteres wird nachfolgend vorgestellt.)
f) Lösungsideen (möglicherweise nicht vollständig, weitere sind erwünscht):
1. Schlüssel haben von Anfang an einen Teil, der ihren Verfallszeitpunkt angibt. Dann
brauchen die Teilnehmer zu ihrer Sicherheit nur noch richtig gehende Uhren. Nachteil:
Wird ein Schlüssel vor seinem Verfallszeitpunkt kompromittiert, dann ist seine Verwendung
so nicht zu stoppen.
(Eine verwandte Lösung wäre, die maximale Anzahl von Benutzungen des Schlüssels festzulegen.
Dies macht allerdings nur bei symmetrischen kryptographischen Systemen Sinn,
wo alle – beiden – Betroffenen jeweils mitzählen können. Sie müssen sich dann allerdings
auch abgelaufene Schlüssel auf Dauer merken.)
2. Expliziter Rückruf von Schlüsseln – sei es durch den Schlüsselinhaber selbst oder die
seinen öffentlichen Schlüssel zertifizierende Stelle(n). Realisiert werden kann dies mittels
einer digital signierten Nachricht, die neben dem zurückgerufenen öffentlichen Schlüssel
bzw. Zertifikat möglichst auch den genauen Zeitpunkt des Rückrufs und natürlich den
Rückrufer enthalten sollte. (Bei Rückruf durch den Schlüsselinhaber selbst ist die Authentisierung
dieses Rückrufs die letzte Aktion mit dem zugehörigen geheimen Signierschlüssel.)
Expliziter Rückruf von Schlüsseln geht natürlich nur bezüglich der Teilnehmer, die ein
verändernder Angreifer vom Rückrufer nicht abschneiden kann. Diese zusätzliche Einschränkung
gegenüber 1. ist der Preis für die größere Flexibilität.
(Allerdings gibt es Protokolle, mit deren Hilfe die Teilnehmer ihre Isolation schnell erkennen
können: Sie senden sich spätestens nach einer jeweils zu vereinbarenden Anzahl Zeiteinheiten
eine Nachricht, wobei alle Nachrichten durchnumeriert und authentisiert sind
(inkl. ihrer Durchnumerierung!). Kommt dann zu lange keine Nachricht oder fehlen
zwischendrin welche, dann wissen die Teilnehmer, daß sie jemand zumindest temporär zu
isolieren trachtet(e).)
3. Wir kombinieren 1. und 2., so daß wir die Vorteile von beidem haben.
4. Vor Verwendung eines Schlüssels wird beim Schlüsselinhaber nachgefragt, ob er noch
aktuell ist. Nachteil: Wenn Teilnehmer(geräte) nicht immer online sind, entstehen
möglicherweise lange zusätzliche Verzögerungszeiten, falls auf die Antwort ohne Timeout
gewartet wird.
5. Variante von 4., indem nur eine relativ kurze Zeit auf eine Antwort gewartet wird. Da ein
verändernder Angreifer eine Antwort unbemerkt für eine kurze Zeit unterdrücken kann,
sollte dies mit 3. kombiniert werden.
Als Hinführung zunächst eine falsche Lösung, die aber in die richtige Richtung weist:
Im Netz sei bekannt, wie eine Prüfsumme über Zeichenketten gebildet wird (Sie kennen sowas
sicher unter den Namen Paritätsbit, Cyclic Redundancy Check (CRC), o.ä.). Die Teilnehmer
bilden nach einem Verfahren solch eine Prüfsumme und einer schickt sein Ergebnis an den
andern. Stimmen die Prüfsummen-Werte überein, so meinen unsere beiden Teilnehmer, dann
haben sie mit großer Wahrscheinlichkeit den gleichen Schlüssel. Was ist ihr Denkfehler? Nun,
Prüfsummen sind für dumme Fehler, nicht aber für intelligente Angreifer entworfen. Bei
üblichen Prüfsummen ist es leicht, viele unterschiedliche Werte zu finden, die die gleiche
Prüfsumme ergeben. Also könnte dies der Angreifer tun und solche inkonsistenten Schlüssel
verteilen. Dann würden dies die beiden Teilnehmer erst dann bemerken, wenn sie den
Schlüssel tatsächlich brauchen. Geschickt wäre also eine Prüfsumme, deren Bildung der
Angreifer nicht vorhersehen kann!
In [BeBE_92 Seite 30] findet sich unter Verweis auf [BeBR_88] folgende nette Idee für ein
informationstheoretisch sicheres Testprotokoll für Schlüsselgleichheit: Die Teilnehmer wählen
mehrmals hintereinander, jeweils unabhängig zufällig die Hälfte aller Schlüsselbits aus und
teilen sich deren bitweise Summe mod 2 mit. (Stimmen die Schlüssel nicht überein, so wird
dies in jedem Schritt mit der Wahrscheinlichkeit 1/2 entdeckt.) Damit ein Angreifer, der dies
mithört, durch solch einen Schritt nichts über den zukünftig zu verwendenden Schlüssel
erfährt, wird eins der Bits, über die die Summe mod 2 öffentlich kommuniziert wurde, aus
dem Schlüssel entfernt, beispielsweise immer das letzte Bit. Der Schlüssel wird bei jedem
Schritt also um ein Bit kürzer. Dies ist nicht schlimm, denn man braucht nur wenige Schritte:
Nach n Schritten ist die Wahrscheinlichkeit, daß das Testergebnis stimmt, 1-2-n , also
spätestens für n = 50 genügend groß genug. (Auch bei diesem Testprotokoll für Schlüsselgleichheit
muß ein verändernder Angreifer mit Kenntnis der inkonsistenten Schlüssel zwischen
den beiden Teilnehmern ausgeschlossen werden: Er könnte die von den Teilnehmern
geschickten Summen so ändern, daß aus Sicht der Teilnehmer alles stimmt.)
Eine Schlüsselverteilzentrale: Wird beim Schlüsselaustausch nur symmetrische Authentikation
verwendet (also weder digitale Signaturen noch unbedingt sichere Pseudosignaturen, vgl.
§3.9.3), könnten aus Sicht jedes der beiden Teilnehmer jeweils der Partner oder die Schlüsselverteilzentrale
lügen (dies ist im Kontext des sogenannten Byzantinischen Übereinstimmungs-