Völlig diffuse Sicherheit bei Internet-Awendungen

It’s not the encryption that‘s cryptography.It’s the random number generator!

SSL/TLS ist eine in Web Browsern integrierte Sicherheitstechnologie und schützt eine Unmenge von Internet-Anwendungen. Für die Sicherheit von SSL/TLS ist u.a. der Zufallszahlengenerator zentral. Über den Zufallszahlengenerator lässt sich eine von aussen fast nicht erkennbare Hintertür einbauen. Mit der Hintertür vermag ein Dritter (Carl), SSL/TLS mit definiertem Aufwand zu entschlüsseln; dies unabhängig vom Verschlüsselungsverfahren. Gegebenenfalls kann Carl die Verbindung sogar übernehmen. Er sammelt dazu nur alle SSL/TLS Pakete im Netz. Ein Zugang zum Client oder Server ist nicht nötig. Es bedarf lediglich einer Kooperation zwischen dem Browserhersteller und Carl.

Wie eine von aussen fast nicht erkennbare Hintertür in SSL/TLS eingebaut werden kann, wird hier kurz beschrieben. „Von aussen“ meint ohne Untersuchung der Operationen auf dem Betriebssystem des Browsers und ohne Zugang zum Quellcode. Da oft keine Schnittstelle zum Zufallszahlengenerator im Browser existiert, kann die Sicherheit von SSL/TLS nicht abgeschätzt werden und bleibt also völlig diffus.

Prinzip des SSL/TLS Verbindungsaufbaus

Der SSL/TLS Aufbau erfolgt vereinfacht dargestellt wie folgt, siehe [Res] und RFC Standards für Details:

  1. Einigung auf ein Geheimnis zwischen Client und Server
  2. Aus dem Geheimnis werden die Schlüssel für die Verschlüsselung und die Authentizität abgeleitet.
  3. Mittels Kontrollmeldung wird festgestellt, ob sich Client und Server auf dieselben Schlüssel geeinigt haben.
  4. Austausch von Daten über die geschützte Verbindung.

Ob sich der Client oder User auf Ebene SSL/TLS authentisiert, ist für die Schlüsselvereinbarung unbedeutend. Nur die dafür relevanten Abläufe werden beschrieben. Dabei wird unterschieden, ob die Vereinbarung mit RSA oder mit Diffie-Hellman erfolgt.

RSA Schlüssel beim Server

Der Server besitzt einen privaten RSA Schlüssel mit dazugehörigem Zertifikat. Für die Authentisierung muss er etwas korrekt entschlüsseln. Die Schlüsselvereinbarung läuft wie folgt ab:

  • Der Client sendet dem Server die von ihm erzeugte Zufallszahl RAC. (28 Byte).
  • Der Server erzeugt die Zufallszahl RAS (28 Byte.), sendet sie mit seinem Zertifikat dem Client.
  • Der Client generiert die Zufallszahl M (46 Byte) und verschlüsselt sie mit dem öffentlichen Schlüssel S im Server-Zertifikat. => ES(M). ES(M) wird dem Server zugestellt.
  • Der Server entschlüsselt ES(M) und erhält so M.
  • Aus M, RAC und RAS werden die Schlüssel für die SSL/TLS Verbindung abgeleitet.
  • Mittels Kontrollmeldung wird geprüft, ob sich Client und Server auf dieselben Schlüssel geeinigt haben.

Einbauen einer Hintertür

Hier eine Variante für den Einbau einer Hintertür:

  • M wird nicht zufällig erzeugt. M ist der Wert einer geheimen Funktion F. F kennen nur der Browser-Hersteller und Carl.
  • Input der Funktion F sind die Zufallszahlen RAC, RAS, eine Zufallszahl P, eine geheime Bitfolge, Informationen, welche pro Verbindung individuell sind, wie Teile vom Serverzertifikat, Versionsnummer von TLS, usw. Was als Input verwendet wird, kennen nur der Browser-Hersteller und Carl.
  • Die Funktion F erzeugt mit dem Input den Output M.

Carl kennt ausser P alle Bestandteile zur Bildung von M. Diese werden wie RAC, RAS im Klartext versandt! Bis Carl M gefunden hat, generiert er für jeden möglichen Wert P‘ einen Kandidaten M’, bestimmt daraus die Schlüssel für die SSL/TLS Verbindung. Er prüft mit der Kontrollmeldung, ob M = M‘ ist.

Diffie-Hellman

Der Server hat einen privaten Signaturschlüssel und dazugehöriges Zertifikat. Die Schlüsseleinigung läuft wie folgt ab:

  • Der Client sendet dem Server die Zufallszahl RAC (28 Byte).
  • Der Server erzeugt die Zufallszahl RAS (28 Byte) und sendet sie mit seinem Zertifikat dem Client.
  • Der Server erzeugt zufällig eine Bitfolge S und führt damit die Diffie-Hellman Operation durch => yS = gS mod p. Dies wird vor der Server Signatur dem Client zugestellt.
  • Der Client erzeugt die Zufallszahl C und führt die Diffie-Hellman Operation durch => yC = gC mod p. Dies wird dem Server zugestellt.
  • Aus gCS mod p, RAC und RAS werden die kryptographischen Schlüssel für Vertraulichkeit und Authentizität abgeleitet.
  • Mittels Kontrollmeldung wird geprüft, ob sich beide Seiten auf dieselben Schlüssel geeinigt haben.

Einbauen einer Hintertür

C wird nicht zufällig erzeugt. C ist der Wert einer geheimen Funktion F, die nur der Browser-Hersteller und Carl kennen. Die Inputs der Funktion sind, die Zufallszahlen RAC, RAS, die Zufallszahl P, eine geheime Bitfolge, Informationen, welche pro Verbindung individuell sind, wie der öffentliche Diffie-Hellman Schlüssel des Servers yS = gS mod p, Bestandteile des Serverzertifikats, Signatur des Servers, usw. Welche Information in welcher Form hinzugezogen wird, ist Aussenstehenden unbekannt.

Carl kennt ausser P aller Bestandteile zur Erzeugung von C. Für jeden möglichen Wert von P generiert er solange ein C‘, bis gC‘ = gC mod p.

Erfolgsfaktoren

Damit die Hintertür unerkannt bleibt, ist u.a. wichtig:

  • Die Funktion F vermag, M oder C von beiden Zufallszahlen RAC, RAS und weiterem Input statistisch loszulösen. Sie sollte den Zufallsgehalt des Input erhalten.
  • Viel Zufallsgehalt (Entropie) zur Bildung von M oder C.
  • RAC wird möglichst zufällig erzeugt.
  • Für die Inputs von F werden Werte hinzugezogen, welche durch die SSL/TLS Kontrollmeldung geprüft werden. Somit sind die Werte für M oder C mit SSL/TLS geschützt.

Von aussen kann die Hintertür nur entdeckt werden, wenn der Server bei jedem SSL/TLS Aufbau stets gleich antwortet (gleiche Zufallszahl usw.) Anhand einer Kollision bei M oder C könnte eine Unstimmigkeit entdeckt werden. Eine Kollision meint, wenn statistisch unerwartet früh, zwei gleiche M oder C generiert werden.

Rund 2T Versuche sind nötig, damit die Wahrscheinlichkeit grösser als ½ ist, dass eine Kollision bei M oder C stattfindet, d.h. zwei gleiche M oder C generiert werden. T = (¦RAC¦ + ¦P¦)/2, ¦P¦ = Bitlänge von P, ¦RAC¦ = Bitlänge von RAC = 224 Bit. Je länger P, desto höher der Aufwand für die Entschlüsselung, aber desto besser die Maskierung der Hintertür. Wird M oder C vor dem Verbindungsabbau bestimmt, so kann Carl in die SSL/TLS Verbindung eingreifen.

Schlussfolgerungen

Keinen Beweis für eine Hintertür zu finden, ist kein Beweis, dass es keine Hintertür gibt.

SSL/TLS weist Schwächen im Design auf, weil die Schlüssel für die Verschlüsselung und die Authentizität auf der Qualität nur eines Zufallszahlengenerators beruhen. Wie dieser funktioniert, ist oft unklar, damit auch die Sicherheit. Um dies zu ändern, müsste SSL/TLS angepasst werden.


Literaturangabe

[Res] Eric Rescorla, SSL and TLS, Addison-Wesley, 2001

SSL 3.0 The Secure Sockets Layer (SSL) Protocol Version 3.0, RFC 6101

TLS 1.2 The Transport Layer Security (TLS) Protocol Version 1.2, RFC 5246

Creative Commons Licence

AUTHOR: Daniel Muster

Daniel Muster, dipl. Physiker Universität Bern, Nachdiplomstudium in In-formationstechnik, Autor des Buches „Digitale Unterschriften und PKI“, unterrichtete während mehrerer Jahre in PKI und deren Anwendungen (u.a. SSL/TLS) an einer Fachhochschule.

Create PDF

Ähnliche Beiträge

Es wurden leider keine ähnlichen Beiträge gefunden.

0 Kommentare

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert