Zertifikate

In der realen Welt kann man die Identität seines Kommunikationspartners z.B. über die Stimmfarbe oder die Handschrift verifizieren – im digitalen Kontext ist das schwieriger. Wie also funktionieren digitale Signaturen oder Zertifikate?

MATERIALIEN

Signaturen.pptx.pdf

 

Moderne Asymmetrische Verschlüsselungsverfahren garantieren (mit an Sicherheit grenzender Wahrscheinlichkeit), dass nur der Urheber des öffentlichen Schlüssels eine mit ebendiesem public key verschlüsselte Nachricht dechiffrieren kann. Die solcherart verschlüsselten Inhalte garantieren also den vertraulichen Austausch von Informationen mit einem Kommunikationspartner – es gibt aber dennoch ein Problem: Wie stellt man sicher, dass man mit dem richtigen Partner kommuniziert, bzw. dass ein bestimmter public key auch tatsächlich von diesem Partner stammt?

Funktion digitaler Zertifikate

Um die Authentizität eines Kommunikationspartners zu verifizieren, werden digitale Zertifikate eingesetzt.

Digitale Zertifikate

Erstellt von Seraina Hohl

Ein digitales Zertifikat dient dazu, die Authentizität eines öffentlichen Schlüssels und seinen zulässigen Anwendungs- und Geltungsbereich zu bestätigen. Das digitale Zertifikat ist selbst durch eine digitale Signatur geschützt, deren Echtheit mit dem öffentlichen Schlüssel des Ausstellers des Zertifikates geprüft werden kann. Um die Authentizität des Ausstellerschlüssels zu prüfen, wird wiederum ein digitales Zertifikat benötigt. Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen, die jeweils die Authentizität des öffentlichen Schlüssels bestätigen, mit dem das vorhergehende Zertifikat geprüft werden kann. Eine solche Kette von Zertifikaten wird Validierungspfad oder Zertifizierungspfad genannt. Das letzte Element (das Root-Zertifikat) gehört zu einer Zertifizierungsstelle und kann nicht weiter überprüft werden, die Zertifizierungsstelle ist also die Wurzel der Vertrauenskette.
Zertifikate sind im Wesentlichen digitale Beglaubigungen. Somit stellt das Vertrauen zwischen dem Prüfer und dem Aussteller eines Zertifikates sowie die Art und Weise, wie dieses Vertrauen zustande kommt, die wesentliche Basis für die Verwendung digitaler Zertifikate dar. Umgekehrt lassen sich solche Vertrauensmodelle in der Regel erst durch Zertifikate technisch umsetzen. Das gesamte System hinter der Validierung von Zertifikaten nennt man public-key-infrastructure. 

Quelle: Wikipedia, Public Key Infrastruktur

Analogie

fairtrade.net
 

Auch Zertifikate in der analogen Welt koppeln das Vertrauen in die Richtigkeit von Angaben an eine (per definitionem vertrauenswürdige) Zertifizierungsstelle. Klebt beispielsweise auf einem Produkt das Fairtrade-Label, dann bestätigt damit die hinter dem Fairtrade-Zertifikat stehende Organisation, dass dieses Produkt die von ihnen aufgestellten Regeln für den fairen Warenhandel einhält. Zur Überprüfung der Echtheit des Zertifikats müsste man als Kunde eigentlich bei der entsprechenden Organisation nachschauen, ob diese dem Produkt das Label auch tatsächlich verliehen hat. Dieser Überprüfungsvorgang geschieht bei digitalen Zertifikaten automatisch, er basiert auf einem zusätzlichen, von der Zertifizierungsstelle bereitgestellten asymmetrischen Schlüsselpaar.

Der für normale Nutzer wichtigste Anwendungsfall für Zertifikate ist das HTTPS-Protokoll. Wie auch HTTP dient dieses Protokoll zum Aufruf einer Webseite, nur dass die zugehörigen Datenpakete verschlüsselt übertragen werden. Das ist immer dann essentiell, wenn der Benutzer auf dieser Website vertrauliche Informationen einträgt (z.B. Login, Bankdaten, usw.) oder abruft (z.B. persönliche Bilder oder Dokumente), weil andernfalls die transportierten Inhalte direkt aus abgefangenen Datenpaketen ausgelesen werden können.
Aus Gründen der Performanz kommt für die eigentliche Datenübertragung hier ein symmetrisches Verfahren zum Einsatz, der dafür notwendige (symmetrische) Schlüssel wird beim Aufbau der Verbindung zwischen Server und Client jedoch in einer asymmetrisch verschlüsselten Form übertragen. Dabei wird der dafür zu Beginn auszutauschende öffentliche Schlüssel des Servers mithilfe eines weiteren – von einer anerkannten Zertifizierungsstelle bereitgestellten – asymmetrischen Schlüsselpaars signiert und vom Client überprüft. In einzelnen Schritten:

  1. Um die Authentizität des Servers sicherzustellen, schickt er dem Client seinen öffentlichen Schlüssel in signierter Form, der Hashwert wird also nochmal verschlüsselt (mit einem von der Zertifizierungsstelle – nach Überprüfung – bereitgestellten private key). Das nennt man Zertifikat.
  2. Um den Server zu authentifizieren wird dann vom Client das zugehörige Zertifikat überprüft – letztendlich geht es darum, ob das übermittelte Zertifikat sich entlang des Validierungspfads auf ein (vom Browserhersteller) anerkanntes Root-Zertifikat zurückführen lässt.
  3. Das Root-Zertifikat einer Zertifizierungsstelle (enthält deren öffentlich bereitgestellten public key) kehrt dann Vorgang der Signierung um, jetzt können die Hash-Werte verglichen und damit die Authentizität des Servers – bzw. seines öffentlichen Schlüssels – bestätigt werden.
  4. Der Client generiert einen symmetrischen Sitzungsschlüssel, verschlüsselt diesen asymmetrisch mithilfe des gerade empfangenen, authentifizierten public key, und schickt diesen an den Server zurück.
  5. Jetzt haben sich beide Kommunikationspartner in sicherer und (einseitig) authentifizierter Weise auf einen symmetrischen Schlüssel geeinigt. Dieser wird dann (für die Dauer dieser Sitzung) benutzt, um alle ausgetauschten Informationen – genauer: die payload jedes Datenpakets – zu verschlüsseln.

Sollte es bei der Überprüfung des Zertifikats zu Schwierigkeiten kommen, wird der Browser üblicherweise eine Warnmeldung anzeigen und ggf. dem Benutzer die Entscheidung überlassen, ob die Verbindung trotzdem aufgebaut werden soll – also mit einem Schlüssel, der beispielsweise nicht authentifiziert werden konnte oder schon abgelaufen ist.

Probleme mit Zertifikaten bzw. public-key-infrastructure

  • Es kostet Zeit und Geld, ein Zertifikat von einer (weitgehend) anerkannten Zertifizierungsstelle zu bekommen.
  • Die Überprüfung der Vertrauenswürdigkeit des Antragsstellers durch die Zertifizierungsstelle ist (notwendigerweise) lückenhaft.
  • Auch Zertifizierungsstellen wurden schon gehackt.
  • Auch korrekt zertifizierte Webseiten können gehackt sein.
  • Zertifikate haben eine begrenzte Gültigkeitsdauer – evtl. vergisst ein vertrauenswürdiger Anbieter das Zertifikat zu erneuern.
  • Browser unterscheiden sich darin, welche Root-Zertifikate sie akzeptieren und wie schnell sie auf bekannt gewordene Zertifikat-Hacks reagieren.
  • Die wenigsten Benutzer wissen genug von Zertifikaten, um mit einer allfälligen Browserwarnung angemessen umgehen zu können.

Public Key-Kryptographie und -Zertifizierung als “IKEA”-Anleitung: PUBLIK KEY KRYPTO

Nächste Seite: Privatsphäre