Man-in-the-middle-Angriff
Material:
- 03_iud_ab_man-in-the-middle.odt
- 00_krypto.odp (Folien 21-29)
Nachdem die SuS das Prinzip der asymmetrischen Verschlüsselung verstanden haben, wird die Frage aufgeworfen, ob es bei dieser Art der Kommunikation wirklich keinen Angriffspunkt gibt.
Beim symmetrischen Verfahren ist der Schlüsseltausch das zentrale Problem. Das Verteilen des öffentlichen Schlüssels sollte beim asymmetrischen Verfahren kein Problem darstellen, da der öffentliche Schlüssel (wie der Name schon sagt) kein Geheimnis darstellt. Dennoch gibt es genau hier eine Schwachstelle, die die SuS finden sollen.
Die SuS spielen in Aufgabe 1 das Szenario durch, das beginnt, bevor Alice ihren öffentlichen Schlüssel verteilt hat und erstellen dazu das Sequenzdiagramm.
Gearbeitet wird wieder in Dreiergruppen. Jede Dreiergruppe erhält drei Schlüsselpaare (für Alice, Bob, Mal). Alternativ kann man zuerst nur Alice ein Schlüsselpaar (mit zwei öffentlichen Schlüsseln) geben. Das zusätzliche Schlüsselpaar für Mal erhält die Gruppe erst wenn die SuS die Notwendigkeit erkennen, dass Mal auch ein eigenes Schlüsselpaar benötigt. Oder sie erhalten Mals Schlüsselpaar bei Bedarf als Tipp.
Für Mal ist es leicht, die Nachricht mit dem öffentlichen Schlüssel von Alice zu lesen und eine Kopie des öffentlichen Schlüssels für sich zu erstellen. Allerdings stellt das kein Problem da, da Alice Schlüssel ohnehin öffentlich ist. Problematisch ist allerdings, wenn Mal die Nachricht abfängt, den Schlüssel von Alice entfernt und durch seinen eigenen öffentlichen Schlüssel ersetzt. Bob erhält scheinbar eine Nachricht von Alice mit einem Schlüssel. Er geht davon aus, dass dies Alice Schlüssel ist und verschlüsselt damit vertrauliche Nachrichten an Alice. Diese kann Mal lesen, weil er ja den passenden privaten Schlüssel hat. Leitet er die Nachricht weiter an Alice (unverändert oder manipuliert) verschlüsselt er sie zuvor mit Alice öffentlichem Schlüssel. Alice denkt nun, die verschlüsselte Nachricht käme von Bob.
Das zentrale Problem (siehe Aufgabe 2) ist also, dass nicht sichergestellt werden kann, ob der erhaltene öffentliche Schlüssel tatsächlich vom scheinbaren Absender stammt. Die Lösung könnte in einem persönlichen Treffen liegen oder in einer Person, der beide Kommunikationspartner vertrauen und deren öffentlichen Schlüssel sie bereits auf sicherem Weg erhalten haben. Sie wird im Folgenden CAty genannt, von C ertification Authority. Zentraler Punkt ist, dass Alice und Bob Caty vertrauen, es ist hingegen nicht notwendig, dass Caty jemandem vertraut.
Auf dem Arbeitsblatt wird in Aufgabe 3 die man-in-the-middle-Problematik mit dem bereits bekannten Chat-Tool praktisch umgesetzt.
Aufgabe 4 führt hin zur Idee und Notwendigkeit eines Zertifikats. Diese Aufgabe ist nicht zwingend notwendig und man kann stattdessen auch gleich zu den Zertifikaten übergehen. Es soll nicht der Eindruck erweckt werden, dass CAty eine Art Schlüsseldatenbank ist, an die alle ihre Schlüsselanfragen stellen. Tatsächlich prüft die CA die Identität der Antragsteller und stellt ihnen das Zertifikat aus. Für die Verteilung sind die Zertifikat-Eigentümer selber verantwortlich.
Bob fragt in Aufgabe 4 Alice nach ihrem öffentlichen Schlüssel. Alice bittet CAty zu bestätigen, dass es sich um Alice Schlüssel handelt. CAty wendet auf die Nachricht mit Alice Schlüssel ihren eigenen privaten Schlüssel an und schickt sie zu Bob. Bob wendet Catys öffentlichen Schlüssel an, verifiziert also die Nachricht und hat Alice öffentlichen Schlüssel. Mal kann Alice Nachricht mit der Bitte um Bestätigung nicht lesen, weil Alice sie mit CAtys öffentlichen Schlüssel verschlüsselt hat. Die Vertraulichkeit der Nachricht ist sichergestellt. Die Nachricht, die Alice Schlüssel beinhaltet, kann Mal lesen, weil er CAtys öffentlichen Schlüssel hat. Das ist aber nicht problematisch, da es sich um den öffentlichen Schlüssel von Alice handelt, den jeder haben darf. Weil CAty auf die Nachricht, die Alice Schlüssel beinhaltet, ihrem eigenen privaten Schlüssel anwendet, kann Bob sicher sein, dass die Nachricht von CAty stammt.
Eine Schwachstelle (siehe Aufgabe 4 d) liegt z.B. darin, dass Mal eine verschlüsselte Nachricht von Alice an CAty sieht und vermutet, dass dies eine Schlüsselanfrage sein könnte (weil CAty ja als vertrauenswürdige Person bekannt ist). Spätestens mit diesem Hinweis können die SuS erkennen, dass Mal Bobs Nachricht abfängt und statt dessen eine eigene Schlüsselanfrage nach seinem, Mals, Schlüssel an CAty schickt. CAty kennt Mals öffentlichen Schlüssel, wendet auf die Nachricht mit Mals Schlüssel ihrem eigenen privaten Schlüssel an (Authentifizierung) und schickt sie zurück. Mal braucht nichts weiter zu tun, als diese Nachricht an Bob weiterzuleiten. Da die Nachricht als Antwort auf seine Schlüsselanfrage kommt und zudem von CAty signiert ist, geht er fälschlicherweise davon aus, dass es sich um Alice Schlüssel handelt. Nun kann Mal Bobs Nachrichten an Alice lesen und ändern. Weiterhin kann Mal in Bobs Namen Nachrichten an Alice schicken.
Die Lösung dieses Dilemmas (siehe Aufgabe 4 e) besteht darin, dass CAty nicht nur den Schlüssel von Alice signiert, sondern zusätzlich Alice Namen. Nun würde es sofort auffallen, wenn die Nachricht nicht Alice sondern Mals Schlüssel (und auch seinen Namen) beinhaltet.
|
Aufgabe auf dem AB |
zugehörige Folie in der Präsentation |
|
Nr. 1 |
21 - 23 |
|
Nr. 2 |
24 - 25 |
|
Nr. 4 a-c, d, e |
26, 27, 28 (- 29) |
Unterrichtsverlauf: Herunterladen [odt][28 MB]
Unterrichtsverlauf: Herunterladen [pdf][407 kB]
Weiter zu Zertifikate