Mittwoch, 6. Juni 2012


Topthema

Donnerstag, 16. November 2006 | Topthema

About Security #81: Kryptographie — Hierarchische Zertifizierungssysteme

(Link zum Artikel: http://www.entwickler.de/php/kolumnen/032514)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Der Aufbau eines hierarchischen Zertifizierungssystems unterscheidet sich vom in About Security #80 vorgestellten Web of Trust in einem entscheidenden Punkt: W�hrend sich beim Web of Thrust die Benutzer gegenseitig zertifizieren, geschieht dies bei einem hierarchischen System ausschlie�lich durch extra daf�r eingerichtete, vertrauensw�rdige Instanzen. Diese Zertifizierungsstellen (Certificate Authority, CA) zertifizieren sich untereinander gegenseitig und best�tigen damit die Vertrauensw�rdigkeit des jeweils anderen. 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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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, z.B. 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.

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.

Ein praktisches Beispiel: Einsatz von Zertifikaten bei SSL/TLS

Das bereits in About Security #73 erw�hnte Secure Sockets Layer (SSL)-Protokoll und sein Nachfolger Transport Layer Security (TLS) (definiert in RFC 4346) verwenden ein hierarchisches Zertifizierungssystem.

About Security: Die komplette Serie

TLS besteht aus zwei Schichten, dem TLS Record Protocol und den darauf aufbauenden Protokollen TLS Alert, TLS Change Cipher 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, siehe About Security #29) 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, siehe About Security #77) 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 Cipher 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 z.B. HTTPS (siehe About Security #29).

TLS im TCP/IP-Schichtenmodell:

Anwendungsschicht
Protokolle: z.B. HTTPS, ...
TLS-Protokoll:
TLS Handshake Protocol
TLS Record Protocol
Transportschicht
Protokolle: TCP und UDP
Netzwerkschicht
Protokolle: IP und ICMP
Netzzugangsschicht
Protokoll: ARP
physikalisches Netzwerk
z.B. Ethernet

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 in RFC 3280 standardisiert wurden.

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Kryptographie - Anwendungen"

Kommentare

Folgende Links könnten Sie auch interessieren

  • Go Enterprise  [04.03.2003]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,323,.html]
  • Web Security  [05.04.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,396,.html]
  • Security mit Smartcards  [23.06.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,832,.html]
  • Praxisrelevantes Know-how  [08.06.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,851,.html]
  • J2EE Security  [23.06.2006]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,837,.html]