Cryptography Reference
In-Depth Information
die typischerweise durch unterschiedliche Firmen und Organisationen geführt werden,
den zugehörigen öffentlichen Schlüssel kennen, damit er möglichst viele Zertifikate über-
prüfen kann. Für jeden solchen Schlüssel muss ein Kommunikationsteilnehmer natürlich
das Bindungsproblem lösen. Ein Kommunikationsteilnehmer sollte auch jeweils selbst
entscheiden, ob er eine Zertifizierungsstelle für vertrauenswürdig hält.
Das gerade beschriebene Modell ist das in der Praxis vorherrschende, insbesondere für
Web-Anwendungen. Die öffentlichen Schlüssel der Zertifizierungsstellen sind dabei direkt
im Web-Browser gespeichert und werden mit diesem ausgeliefert. Benutzer verlassen sich
meist darauf, dass der Browser-Hersteller das Bindungsproblem für die aufgeführten Zer-
tifizierungsstellen gelöst hat, also sichergestellt hat, dass die gespeicherten öffentlichen
Schlüssel tatsächlich der jeweils angegebenen Zertifizierungsstelle gehören. Zudem ist
standardmäßig im Browser eingestellt, dass ein Benutzer allen diesen Zertifizierungsstel-
len vertraut, Schlüsselbindungen gewissenhaft zu prüfen. Benutzer haben allerdings die
Möglichkeit, eine im Browser aufgelistete Zertifizierungsstelle als nicht vertrauenswür-
dig einzustufen. Von einer solchen Zertifizierungsstelle ausgestellte Zertifikate würden
dann vom Browser nicht mehr akzeptiert werden. Ein Benutzer ist in der Tat gut bera-
ten, die Vertrauenswürdigkeit von im Browser aufgelisteten Zertifizierungsstellen selbst
zu beurteilen, da die Vertrauenswürdigkeit einer Zertifizierungsstelle in der Regel nicht
das ausschlaggebende Kriterium für die Aufnahme des entsprechenden Schlüssels in den
Browser ist, sondern lediglich, ob eine entsprechende Gebühr entrichtet wurde.
Ein typisches Szenarium, in dem Zertifikate in Browsern verwendet werden, ist das
folgende: Um eine sichere Verbindung zu einem Server herzustellen, benutzt ein Browser
das SSL/TLS-Protokoll. In diesem Protokoll tauschen Client (Browser) und Server (z.B.
ein Bankserver) zunächst einen gemeinsamen geheimen symmetrischen Schlüssel aus, der
dann anschließend von Client und Server für die sichere Kommunikation benutzt wird.
In der Schlüsselaustauschphase sendet der Server u. a. sein Zertifikat an den Client, um
dem Client seinen öffentlichen Schlüssel mitzuteilen. Wurde dieses Zertifikat von einer
Zertifizierungsstelle signiert, die im Browser (samt ihrem öffentlichen Schlüssel) gespei-
chert ist und ist diese Zertifizierungsstelle vom Benutzer als vertrauenswürdig eingestuft,
dann akzeptiert der Browser das Zertifikat. Läuft das SSL/TLS-Protokoll auch ansonsten
erfolgreich durch, dann geht der Browser davon aus, dass eine sichere Verbindung mit
dem im Zertifikat angegebenen Server hergestellt wurde; dies wird dem Benutzer vom
Browser entsprechend angezeigt, der dann auch von einer sicheren Verbindung mit dem
angegeben Server ausgeht. Es ist deshalb äußerst wichtig, dass die im Zertifikat ange-
gebene Schlüsselbindung gültig ist: Wäre die im Zertifikat angegebene Schlüsselbindung
(
B,k
)
, sagen wir für eine Bank
B
, obwohl der angegebene öffentliche Schlüssel
k
von ei-
nem böswilligen Charlie stammt, dann würde der Benutzer davon ausgehen, dass er eine
sichere Verbindung mit seiner Bank
B
aufgebaut hat, obwohl er eigentlich mit Charlie
spricht, dem er dann evtl. seine PIN und dergleichen anvertrauen würde. Umgekehrt be-
deutet dies, dass ein Benutzer sich genau überlegen sollte, welchen Zertifizierungsstellen
er für die Ausstellung von Zertifikaten vertraut.
Es sei noch bemerkt, dass im Browser hinterlegten Paare aus öffentlichem Schlüssel
und Name der zugehörigen Zertifizierungsstelle in Form von Zertifikaten im Browser
gespeichert sind. Diese Zertifikate sind dabei mit dem jeweiligen privaten Schlüsseln der
Zertifizierungsstelle signiert. Man spricht deshalb von
selbstsignierten Zertifikaten
(siehe
auch Aufgabe 10.7.13).
