Digitale Signatur

Zweck der Signatur ist es, nachzuweisen, dass ein Text sicher von einer bestimmten Person erstellt wurde. Der RSA-Algorithmus kann so abgewandelt werden, dass mit dem privaten Schlüssel verschlüsselt und mit dem öffentlichen Schlüssel entschlüsselt wird. Ein Absender generiert daher ein RSA-Schlüsselpaar und veröffentlicht den öffentlichen Schlüssel.

Einfache (nicht praktizierte) Variante zum Signieren einer Nachricht: Der Absender könnte die Nachricht digital signieren, indem er sie mit seinem privaten Schlüssel verschlüsselt und den verschlüsselten Text mit zum Empfänger sendet. Der Empfänger entschlüsselt mithilfe des öffentlichen Schlüssels den verschlüsselten Text und vergleicht ihn mit der Nachricht. Falls beide gleich sind, weiß er, dass die Nachricht vom Sender stammt und unverfälscht ist.

Das obige Verfahren wird in der Praxis nicht so gehandhabt, da die Entschlüsselung mit dem RSA-Algorithmus sehr rechenintensiv ist und die Datenmenge zum Versenden verdoppelt wird. Man geht daher wie folgt vor:

a) Der Sender erzeugt mithilfe einer kryptographischen Hashfunktion einen Hashwert des Textes.
b) Der Sender verschlüsselt den Hashwert mit seinem privaten Schlüssel und hängt ihn an den Text an.
c) Der Empfänger entschlüsselt den übermittelten Hashwert ( = hash1)
d) Der Empfänger berechnet den Hashwert des übermittelten Textes ( = hash2)
e) Der Empfänger vergleicht hash1 und hash2. Stimmen sie überein, so weiß er, dass der Text vom Sender stammt und unverfälscht ist.

Anwendung: SSL-Handshake

Immer dann, wenn wir eine Seite im Browser per https-Protokoll aufrufen, z.B. zur URL https://www.learnj.de/11, zeigt uns dieser durch ein Vorhängeschloss-Symbol an, dass er das Zertifikat des Servers überprüft hat und dass die Kommunikation sicher sei. Dies sichert uns zweierlei zu:

Der Server, der auf unsere Anfrage geantwortet hat, ist berechtigt, Webseiten für die angegebene URL auszuliefern. Es handelt sich also nicht um den Server eines Angreifers, der die Webseite imitiert.
Die Übertragung der Daten vom Browser zum Server und umgekehrt erfolgt verschlüsselt.

Es stellen sich folgende Fragen:

Wie stellt der Browser sicher, dass der antwortende Server wirklich zur Domain www.learnj.de gehört und nicht ein man in the middle-Server die Anfrage beantwortet?
Wie können sich der Browser und der Server auf eine Schlüssel zur Verschlüsselung einigen, ohne dass ein man in the middle diesen abgreifen und die nachfolgende Kommunikation dann belauschen kann?

Lösungsansatz (vereinfachte Darstellung):

Eine Zertifizierungsstelle (certificate authority, kurz: CA) überprüft die Identität der Domaininhaber/innen und stellt signierte Zertifikate aus. Diese enthalten den Domainnamen und einen public key der Domaininhaberin/des Domaininhabers.
Der public key der Zertifizierungsstelle ist fest in den Browsern integriert.
Auf den ersten Request des Browsers antwortet der Server, indem er das Zertifikat vorweist.
Mithilfe des public key im Zertifikat kann der Browser sowohl die Identität des Servers überprüfen als auch einen geheimen Schlüssel für die weitere Kommunikation übermitteln, Details dazu in den folgenden Darstellungen.

Inwiefern ist die Darstellung vereinfacht?

Der Handshake ist in Wirklichkeit noch deutlich ausgefeilter.
Im Browser hinterlegt ist meist nicht direkt der public key der certificate authority, sondern der public-key von wenigen sogenannten root certificate authorities. Diese signieren die public-keys untergeordneter CAs, die wiederum die public-keys weiterer CAs signieren usw…
Man spricht von einer Zertifikatskette (certificate chain), durch die dann letztlich das Zertifikat des Webservers beglaubigt wird.