Alice und Bob haben mit der asymmetrischen Verschlüsselung ein Verfahren, wie die beiden über einen unsicheren Kanal einen gemeinsamen Schlüssel vereinbaren können. Solange Eve den Kanal nur abhören kann, geht alles gut: Sie kann die Nachricht nicht entschlüsseln.

Was passiert nun, wenn Mallory auftaucht, der den Kanal nicht nur abhören sondern auch gezielt manipulieren kann? Er schnappt sich Bobs public key bei der Übertragung und ersetzt ihn mit seinem eigenen, ohne dass Alice etwas bemerkt. Wenn Alice die verschlüsselte Botschaft zurücksendet, verwendet sie unwissenderweise Mallorys Schlüssel; dieser entschlüsselt die Nachricht und verschlüsselt sie erneut mit Bobs Schlüssel, so dass auch dieser nichts bemerkt.

Mallory führt eine Man-in-the-Middle-Attacke aus.

Hätten wir eine vertrauenswürdige Instanz, die uns mit digitalen Signaturen überprüfen lässt, ob wir es wirklich mit Bobs Schlüssel zu tun haben, könnten wir das Problem lösen:

Trent stellt in unserem System eine solche vertrauenswürdige Instanz dar. Er nimmt sich die Zeit, jeden Teilnehmer gründlich zu authentifizieren, zum Beispiel indem er eine Identitätskarte überprüft. Erst dann stellt er ein Zertifikat aus, das belegt, dass Bobs public key wirklich zu Bob gehört. Dazu nutzt er digitale Signaturen.

Das HTTPS-Protokoll funktioniert genau so: Sogenannte Certificate Authorities überprüfen die Identität von Webseiten-Betreibern. Die IT-Abteilung der KSR hat irgendwann bewiesen, dass sie wirklich zuständig für die Webseite der KSR ist, und erhielt dafür von einer Certificate Authority ein Zertifikat ausgehändigt.

Rufen wir die Webseite https://www.ksr.ch auf, so überprüft der Browser zuerst, ob ein gültiges Zertifikat vorliegt. Die Root-Zertifikate der Certificate Authorities werden dabei vom Browser oder dem Betriebssystem vorinstalliert.

  • gf_informatik/verschluesselung/zertifikate.txt
  • Zuletzt geändert: 2022-03-17 22:28
  • von hof