Dipl.-Inform. Carsten Eilers

Benutzer können daher den von einer beliebigen CA signierten Schlüsseln vertrauen, sofern deren Zertifikat von einer, in ihren Augen vertrauenswürdigen, CA signiert wurde. Das Ganze kann als Baumstruktur betrachtet werden, in der das eigene Zertifikat jeder CA sowohl von den über, als auch den unter ihr liegenden CAs signiert wurde. An der Spitze kann eine Master-CA stehen, sodass im Idealfall jeder Benutzer die Zertifikate jedes anderen Benutzers prüfen kann.

Möchte Alice Bobs signierte Nachricht prüfen, besorgt sie sich seinen öffentlichen Schlüssel und prüft das Zertifikat. Vertraut sie der ausstellenden CA, zum Beispiel weil sie ihr bereits als zuverlässig bekannt ist, kann sie den Schlüssel danach sofort verwenden. Andernfalls muss sie eine andere CA finden, die ein Zertifikat für die von Bob verwendete CA ausgestellt hat und der sie vertraut, siehe Abbildung 1.

Abb. 1: Hierarchisches Zertifizierungssystem

In der Abbildung wurde Alices Schlüssel von CA A zertifiziert, Bobs von CA B. Beide kennen die Schlüssel der jeweils "eigenen" CA und vertrauen den damit signierten Zertifikaten.

CA A hat CA 1 zertifiziert, sodass Alice Zertifikaten vertrauen kann, die von CA 1 ausgestellt wurden. Jetzt muss sie sich in der Hierarchie nach oben durcharbeiten, bis sie eine CA findet, von der aus sie zu CA B gelangt. In der Abbildung ist dies CA 5: Deren Zertifikaten vertraut CA 3, und CA 5 selbst vertraut CA 4. Den Schlüssel von CA 3 vertraut Alice, nachdem sie das zugehörige Zertifikat mit der Signatur von CA 1 geprüft hat. Nachdem Alice also CA 3 ihr Vertrauen geschenkt hat, kann sie der Reihe nach die Zertifikate von CA 5, CA 4, CA 2 und schließlich CA B prüfen.

Es ist durchaus möglich, dass es keinen Weg von Alice zu Bob gibt, da niemand bereit ist, die Vertrauenswürdigkeit von CA B zu bezeugen. Dann muss entweder Bob ein Zertifikat einer anderen CA vorweisen, deren Vertrauenswürdigkeit von Alice geprüft werden kann, oder Alice muss sich selbst davon überzeugen, ob sie CA B für vertrauenswürdig hält. Ist beides erfolglos, darf Alice Bobs Signatur nicht trauen.

Soweit die Theorie. In der Realität wurde das ganze stark vereinfacht oder besser verschlechtert. Beim häufigsten Einsatz im Rahmen von HTTPS ist das "durchhangeln" durch den CA-Baum nicht nötig, da die aktuellen Betriebssysteme und Browser sehr vielen CAs "ab Werk" vertrauen. Es kommt also sehr selten vor, dass ein Benutzer auf ein Zertifikat einer CA stößt, dem sein System oder Browser nicht von Haus aus vertrauen. Nur in diesen vereinzelten Sonderfällen käme die Zertifizierung der CAs untereinander zum Tragen.

Ein praktisches Beispiel: Einsatz von Zertifikaten bei SSL/TLS

Das Secure Sockets Layer (SSL)-Protokoll (neueste Version 3.0 definiert in RFC 6101, inzwischen veraltet ("deprecated")) und sein Nachfolger Transport Layer Security (TLS) (aktuelle Version 1.2 definiert in RFC 5246) verwenden ein hierarchisches Zertifizierungssystem.

TLS besteht aus zwei Schichten:

• Dem TLS Record Protocol und
• den darauf aufbauenden Protokollen TLS Alert, TLS Change Chipher Spec, TLS Handshake und TLS Application Data.

Das TLS Record Protocol ist die untere der Schichten und sichert die Verbindung. Es setzt auf die Transportschicht auf (in der Regel TCP ) und stellt eine Ende-zu-Ende-Verschlüsselung durch Anwendung symmetrischer Verschlüsselungsalgorithmen und die Sicherung von Integrität und Authentizität durch Hinzufügen eines Message Authentication Code (MAC) zur Verfügung.

Das TLS Handshake Protocol in der oberen Schicht ist für die Prüfung der Identität der Kommunikationspartner sowie die Aushandlung und den Austausch des Schlüssels für die symmetrische Verschlüsselung durch das TLS Record Protocol zuständig. Die Aufgaben der weiteren Protokolle in der oberen Schicht:

• Das TLS Change Chipher Spec Protocol startet die geschützte Kommunikation im ausgehandelten Kontext.
• Das TLS Alert Protocol wird für den Austausch von Alarmmeldungen verwendet.
• Das TLS Application Data Protocol dient der transparenten Übertragung der Daten über das TLS Record Protocol.

Über dem TLS-Protokoll befindet sich die Anwendungsschicht mit Protokollen wie zum Beispiel HTTPS.

TLS im TCP/IP-Schichtenmodell:

Der Handshake kann vereinfacht in vier Schritte unterteilt werden:

1. Der Client sendet eine 'ClientHello'-Nachricht an den Server.
2. Der Server antwortet mit einer 'ServerHello'-Nachricht, sendet sein Zertifikat an den Client und schließt seine Aktionen mit einer 'ServerHelloDone'-Nachricht ab.
3. Der Client prüft das Zertifikat. Ist das Ergebnis positiv, startet er die Aushandlung des symmetrischen Schlüssels.
4. Der Server beantwortet die Schlüsselaushandlung. Danach ist der Handshake abgeschlossen und die Daten der Anwendungsschicht können geschützt übertragen werden.

Der hier interessierende Punkt ist das Prüfen des Zertifikats. SSL und TLS verwenden X.509-Zertifikate, die erstmals als Version 1 in RFC 3280 standardisiert wurden, aktuell ist die Beschreibung der Version 3 in RFC 5280.

X.509-Zertifikat

Allgemeiner Aufbau eines X.509-Zertifikats:

• Version
  legt das Format des Zertifikats fest. Meist wird die aktuelle Version 3 verwendet.
• Serial Number
  ist eine eindeutige Nummer innerhalb der ausstellenden CA.
• Signature Algorithm Identifier
  enthält Angaben zu dem für das Zertifikat benutzten Algorithmus:
  • Algorithm
    Name des Algorithmus
  • Parameters
    ggf. vom Algorithmus benötigte Parameter
• Issuer
  Aussteller, d.h. Name der CA
• Validity (Begin/End)
  Geltungsdauer
• Subject
  Name des Schlüsselinhabers
• Subject Public Key Info
  Öffentlicher Schlüssel des Schlüsselinhabers
  • Algorithm
    Name des vom Schlüsselinhaber benutzten Algorithmus
  • Parameters
    ggf. vom Algorithmus benötigte Parameter
  • Public Key
    der öffentliche Schlüssel des Schlüsselinhabers
• Unique Identifiers
  enthält je eine eindeutige ID der CA und das Schlüsselinhabers.
• Extensions
  Raum für Erweiterungen
• Signature
  ist die Signatur der CA für das gesamte Zertifikat

Die Arbeit mit X.509-Zertifikaten wird in der nächsten Folge beschrieben.

Carsten Eilers