Seite 4: Digitale Signaturen und Zertifikate

Inhaltsverzeichnis

DSA- und ECDSA-Signaturen

Digitale Signaturen nach dem DSA-Verfahren (Digital Signature Algorithm) und dem ECDSA-Verfahren (Elliptic Curve Digital Signature Algorithm) benötigen neben dem eigentlichen Signaturschlüssel bei jeder Signaturerzeugung noch eine vom Signaturersteller geheimzuhaltene Zufallszahl. Kennt ein Angreifer diese Zufallszahl, so kann er anhand der Signatur auf den verwendeten DSA- oder ECC-Key schließen.

Diese Eigenschaft ist der Grund dafür, dass auch eigentlich sichere DSA-Schlüssel als kompromittiert gelten müssen, wenn sie von einem unsicheren Debian-System als Client zur DSA-Public-Key-Authentisierung benutzt wurden. Existiert beispielsweise ein Mitschnitt einer solchen SSH-Session, lässt sich aus dieser nachträglich der geheime DSA-Schlüssel rekonstruieren.

X.509-Zertifikate

Da OpenSSH bei der Schlüsselerzeugung einen öffentlichen Exponenten von 35 benutzt, das OpenSSL-Kommando zur RSA-Schlüsselerzeugung jedoch den Exponent 65537 verwendet, kann das von Debian veröffentlichte Testprogramm dowkd.pl keine X.509-Schlüssel prüfen. Das für Ubuntu Linux verfügbare Packet openssl-blacklist enthält jedoch zusätzliche Blacklists, mit denen auch der Test von OpenSSL-Schlüsseln möglich ist. Inzwischen ist es auch als Debian-Backport erhältlich.

Dabei gilt grundsätzlich das gleiche wie bei OpenSSH: mit einem verwundbaren Debian erzeugtes Schlüsselmaterial ist schwach und sollte als gebrochen gelten. Ausstellende CAs sollten betroffene Zertifikate umgehend sperren und neu ausgestellen. Alle TLS/SSL-geschützten Server – etwa Webserver und Server, die wie SMTPS-fähige MTAs und Mailserver mit POP3S oder IMAPS das Protokoll-Kommando STARTTLS verwenden, sollten auf verwundbares Schlüsselmaterial überprüft werden.

Auf unsicheren Schlüsseln basierende Webserver-Zertifikate dürfte es in größerer Zahl geben – erste Stichproben ergaben bei einigen im Internet erreichbaren Webservern schwache Schlüssel. Angreifer können den privaten Schlüssel von solchen Webservern erraten und mit ihm beispielsweise eigene Server mit dessen Zertifikat ausstatten. Auch ist es recht einfach möglich, die mit TLS/SSL verschlüsselte Kommunikation mit dem Originalserver abzuhören: Das Analysetool Wireshark kann SSL-Kommunikation entschlüsseln, wenn man ihm den privaten Schlüssel gibt.

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite zu dirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Hier sind auch in der Zukunft durchaus noch Probleme zu erwarten, weil das Thema der Zertifikatssperrung von den aktuellen Browsern derzeit eher stiefmütterlich behandelt wird. In ihrer Standardeinstellung prüfen viele Browser den Gültigkeitsstatus von Server-Zertifikaten nicht, sodass sie nicht erkennen, wenn eine CA ein Zertifikat in ihrer Certification Revocation List (CRL) widerrufen hat. Wer auf Nummer Sicher gehen möchte, sollte das Prüfen von CRLs in den Browser-Einstellungen aktivieren.

Ein Angreifer kann daher ein gesperrtes Zertifikat bis zum Ende seiner vorgesehenen Gültigkeitsdauer verwenden; die meisten Browser würden es klaglos akzeptieren. Die Prüfung von Sperrinformationen per OCSP (Online Certificate Status Protocol) durch die Browser könnte künftig Abhilfe schaffen. Die meisten Browser beherrschen inzwischen zwar OCSP, die Funktion ist aber in der Regel standardmäßig deaktiviert. Außerdem unterstützen nicht alle CAs das Protokoll.

Die Wurzel

Der schlimmste Fall wäre eine Certificate Authority (CA), die verwundbare Zertifikate eingesetzt hat, um Zertifikate zu signieren. Alle von Microsoft und Firefox mitgelieferten CA-Zertifikate mit 1024 oder 2048 Bit Länge und einem öffentlichen Exponenten von 65537 stellten sich in einem ersten Test als nicht verwundbar heraus, sodass die großen, öffentlichen CAs nicht mit unmittelbaren Problemen zu rechnen haben. Probleme könnte es jedoch für Firmen und Organisationen geben, die eigene PKIs auf einem verwundbaren Debian Linux mit OpenSSL aufgesetzt haben – die Betreiber könnten möglicherweise gezwungen sein ihre komplette PKI neu aufzusetzen.