Grundlagen zu Zertifikaten
Die Verwendung von Zertifikaten zur verschlüsselten Kommunikation und Signierung von Daten wie E-Mails steht bei vielen Unternehmen ganz oben auf der Wunschliste. Dafür ist es aber in erstaunlich vielen Fällen noch nicht umgesetzt.
Ich möchte daher einen kurzen Überblick zum technischen Verfahren bieten das beim Einsatz von Zertifikaten zum Tragen kommt. Als Beispiel soll der gesicherte, verschlüsselte Zugriff auf eine Web-Site „webmail.company.de“ über das HTTPS-Protokoll dienen.
Das Zertifikatsverfahren basiert auf drei Säulen:
- Eine allgemein anerkannte und vertrauenswürdige Autorität: Die zentrale Zertifikatsausgabestelle
- Dem Private-Public-Key Verschlüsselungsverfahren
- Dem Zertifikat, was die Eigenschaft eines Subjektes oder Objektes bestätigt
Index
Gesicherter und verschlüsselter Zugriff auf eine Web-Site
Zusammenspiel der drei Säulen am Beispiel
Um die Grundlagen zu Zertifikaten besser zu verstehen, wollen wir eine WebMail-Site für unsere Mitarbeiter im Internet mit verschlüsselter Kommunikation zur Verfügung stellen. Ein öffentlicher DNS-Eintrag für die Adresse webmail.company.de ist registriert und jetzt fehlt uns noch ein Zertifikat was die Echtheit dieser Adresse bestätigt. An diesem Punkt kommt die zentrale Zertifikatsausgabestelle ins Spiel. Denn bei dieser Stelle lassen wir unser ein Zertifikat für unseren Web-Server ausstellen. Bekanntere Stammzertifizierungsstellen sind zum Beispiel GlobalSign, VeriSign oder Thawte.
Und schon sind wir bei der zweiten Säule des Zertifikatsverfahrens: Der Private-Public-Key Verschlüsselung. Da das Verfahren hier nur Mittel zum Zweck ist will ich nur kurz seine besondere Eignung für die Zertifikate erläutern. Es gibt darüber hinaus mehrere Bücher die sich ausschließlich mit diesem Verschlüsselungsverfahren beschäftigen da es eine zentrale Stellung in der Kryptografie einnimmt. Wie der Name „Private-Public-Key“ schon sagt gibt es hier nicht einen einzelnen Schlüssen für die Verschlüsselung von Nachrichten sondern derer zwei. Ein Schlüssel ist privat und geheim, er wird niemals nach außen gegeben. Der andere Schlüssel ist dagegen sozusagen der extrovertierte Zwilling, er ist geradezu dafür gemacht unter die Menge geschleudert zu werden. Und warum kann man so sorglos mit dem öffentlichen Schlüssel umgehen? Weil er nichts über den privaten Schlüssel verraten wird.
Das führt zu zwei ganz besonderen Möglichkeiten:
- Nachrichten die mit dem öffentlichen Schlüssel verschlüsselt wurden können nur vom privaten Schlüssel wieder entschlüsselt werden. Das bedeutet nur der Empfänger kann die für ihn verschlüsselte Nachricht lesen.
- Nachrichten die mit dem privaten Schlüssel verschlüsselt wurden können nur vom öffentlichen Schlüssel wieder entschlüsselt werden. Da man davon ausgehen kann dass der private Schlüssel nur an einer Stelle existiert kann der Absender der Nachricht sicher bestätigt werden. Damit kann ein Signaturverfahren aufgebaut werden.
Die dritte Säule, die mit dem Zertifikat zu bestätigende Eigenschaft, ist in unserem Beispiel die DNS-Adresse „webmail.company.de“ für unsere WebMail-Site.
Das Zertifizierungsverfahren – so werden alle notwendigen Bestandteile eingesetzt
- Für unseren Web-Server wird ein Zertifikatsantrag erzeugt. Mit diesem Zertifikatsantrag wird das Private-Public-Key Paar für unsere WebMail-Site erzeugt. Der private Schlüssel verbleibt bei uns. Das Antragsformular enthält neben dem öffentlichen Schlüssel unsere DNS Web-Adresse und einige weitere Informationen wie zum Beispiel den Standort unseres Servers.
- Der fertig ausgefüllte Zertifikatsantrag wird an die Stammzertifizierungsstelle unserer Wahl geschickt um für uns ein Zertifikat auszustellen.
- Die Stammzertifizierungsstelle erzeugt mit unseren Informationen ein Zertifikat und signiert es mit ihrem privaten Schlüssel. Außerdem enthält das Zertifikat noch eine Gültigkeitsdauer und Informationen wo das Stammzertifikat sowie die Zertifikatssperrliste (Certificate Revocation List) zu finden ist.
- Das fertige Zertifikat kommt zu uns zurück und wir spielen es auf unseren Web-Server ein. Jetzt ist die verschlüsselte Kommunikation mit unserer WebMail-Site möglich.
Wir der aufmerksame Leser gemerkt hat wurde in dem ganzen Prozess niemals der private Schlüssel nach außen gegeben. Das ist auch essentiell denn das ganze Verfahren beruht auf der Vertrauenswürdigkeit des privaten Schlüssels. Wenn sein Geheimnis nicht mehr sicher ist kann auch nicht mehr sichergestellt werden das Nachrichten nur von dem für sie bestimmten Empfänger entschlüsselt werden können bzw. von dem bekannten Absender signiert wurden.
Der Aufbau eines verschlüsselten Kommunikationskanals mit unserer Site webmail.company.de erfolgt nun nach einem festgelegten Zertifikatsprüfung- und Schlüsselaustauschverfahren.
1. Echtheit des Zertifikats prüfen
- Der Internet-Browser macht eine erste Anfrage zu unserem Web-Server auf der Adresse: https://webmail.company.de. Mittels https geben wir an das wir eine verschlüsselte Kommunikation zum Web-Server aufbauen werden.
- Der Web-Server übermittelt dem Internet-Browser unser Zertifikat was die Echtheit der Adresse webmail.company.de bestätigt.
- Der Internet-Browser prüft nun die Echtheit unseres Zertifikates. Dazu werden alle ausstellenden Zertifikate in der Zertifikatskette bis zum Stammzertifikat ermittelt. In unserem Fall ist das nur eins. Üblicherweise werden Zertifikate aber von untergeordneten Zertifikatsausgabestellen erstellt und nicht von der Stammzertifizierungsstelle. Die Zertifikate der Ausgabestellen und der Stammzertifizierungsstelle sind meistens im CryptoAPI-Cache des Rechners enthalten und können vom Internet-Browser abgerufen werden. Ist das nicht der Fall können sie über die Authority Information Access (AIA) URL, welche im Web-Server Zertifikat hinterlegt ist, nachgeladen werden.
- Wenn alle Zertifikate der Kette ermittelt sind wird bei jedem Zertifikat geprüft ob es sich noch im Gültigkeitszeitraum befindet.
- Danach wird für jedes Zertifikat die Certificate Revocation List (CRL) abgerufen. Die URL dafür ist ebenfalls im Zertifikat hinterlegt. Damit wird geprüft ob unser Web-Server Zertifikat gesperrt wurde. Ab Windows Server 2008 wird auch das Online Certificate Status Protocol (OCSP) unterstützt. Mit einem OCSP-Responder kann der Zertifikatsstatus zeitnah abgefragt werden denn eine CRL wird nur in einem bestimmten Zeitraum aktualisiert.
- Stimmt auch noch die Adresse im Zertifikat mit der aufgerufenen Web-Adresse sowie der Verwendungszweck, in unserem Fall „Web-Server“, und werden die Informationen durch die Zertifikatssignatur bestätigt wird das Zertifikat als gültig akzeptiert und der verschlüsselte Kanal kann etabliert werden.
2. Austausch der Schlüssel:
- Der Internet-Browser erzeugt einen symmetrischen Schlüssel mit dem für die Dauer der Sitzung der Datenverkehr zwischen Web-Server und Internet-Browser verschlüsselt wird. Das Private-Public-Key Verfahren ist sehr rechenintensiv, daher wird es nur für den Austausch des eigentlichen Datenschlüssels verwendet. Der Datenschlüssel ist ein symmetrischer Schlüssel, d.h. er wird für die Verschlüsselung als auch für die Entschlüsselung verwendet was wesentlich weniger Rechenleistung benötigt. Da er nur für die aktuelle Sitzung verwendet wird ist er sehr kurzlebig und die Gefahr dass er ausspioniert wird gering.
- Der Internet-Browser verschlüsselt den Datenschlüssel mit dem öffentlichen Schlüssel unseres Web-Servers aus dem Zertifikat. Dieses Paket wird dann an den Web-Server zurückgeschickt.
- Nur unser Web-Server ist in der Lage mit dem passenden privaten Zertifikatschlüssel den Datenschlüssel wieder zu entschlüsseln. Alle weiter Kommunikation mit dem Internet-Browser erfolgt dann mit dem ausgetauschten Datenschlüssel.
- Da sich der Internet-Browser sicher sein kann das nur der Web-Server den Datenschlüssel verwendet ist die Kommunikation zum Web-Server nun gesichert.
Ich hoffe Ihr habe nun einen ersten, vielleicht etwas ausfühtlicheren Einblick in die Grundlagen zu Zertifikaten erhalten. Anmerkungen und Ergänzungen sind natürlich jederzeit willkommen. Bitte einfach einen Kommentar hinterlassen.
Leave a Reply
<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>