Zertifikatsinsuffizienz: Wenn Informationssicherheit zu kompliziert wird

Kommentieren Drucken

Zertifikatsbasierte Authentisierung ist an allen Ecken und Enden der IT zu finden. Beim Click auf eine HTTPS-Seite authentisiert sich der Web-Server beim Browser. Nutzer oder Geräte wie PCs, IP-Telefone, Drucker authentisieren sich an einem Server, am Netzbetriebssystem oder an einem Netzzugangspunkt. Zertifikate sind standardisiert und seit Jahren ein bewährtes und sicheres Authentisierungsinstrument, das man offensichtlich mit akzeptablem Aufwand in den Griff bekommt (sonst hätte es sich ja nicht durchgesetzt).

Zumindest letzteres ist eine dreiste Übertreibung.

Zunächst ist es in der Vergangenheit durchaus vorgekommen, dass bei einem Einbruch in einer (Stamm-)Zertifizierungsstelle Zertifikate (natürlich inklusive des privaten geheimen Schlüssels) in die falschen Hände gelangt sind. Nun ja, das ist wie mit einem Passwort: Wer es kennt, ist drin, zumindest solange das Passwort gültig bzw. der zugehörige Account nicht gesperrt ist. Daher sollten solche Ereignisse (abgesehen von Schwächen bei der Absicherung von kritischen Infrastrukturen wie Zertifizierungsstellen) nicht überbewertet werden.

Spannender war da schon ein Vorfall von Anfang November 2009, bei dem Sicherheitsexperten eine Schwachstelle in der TLS1-Spezifikation selbst gefunden hatten2. Die Funktion der Renegotiation in TLS (RFC 5246, inkl. SSL v3 und früher) konnte durch verschiedene Angriffe vom Typ Man-in-the-Middle (MITM) missbräuchlich ausgenutzt werden. Der MITM konnte dabei authentisiert durch einen legitimen Nutzer (das Opfer der MITM-Attacke) und geschützt durch TLS eine beliebige HTTP-Transaktion seiner Wahl ausführen. Fehler, die sich für Angriffe ausnutzen lassen, kommen nun mal nicht nur bei der Implementierung vor, sondern schon bei der Protokollspezifikation. Mit hektischem Patchen und einer Ergänzung des Standards (siehe RFC 5746) lässt sich so etwas natürlich wieder reparieren.

So interessant diese Schwachstelle war, es sind nicht solche Aspekte, an denen die zertifikatsbasierte Authentisierung krankt: Wir leiden unter mangelhaftem und uneinheitlichem Zertifikatsmanagement. Dies betrifft unter anderem das automatisierte Ausrollen von Zertifikaten, die Überprüfung von Zertifikaten und den Umgang mit Sperrlisten.

Auch wenn beispielsweise Microsoft Certificate Services hier wunderbar funktionieren mögen (im Detail sind natürlich auch hier manchmal Klimmzüge nötig), es bleibt zu einem gewissen Grad eine Lösung für reine Windows-Umgebungen. Was ist mit Linux, MacOS, iOS, Android und anderen Betriebssystemen? Als Standard für das Zertifikatsmanagement wird hier schnell der Ruf nach dem Simple Certificate Enrollment Protocol (SCEP) laut. Leider entpuppt sich der vermeintliche allgemein etablierte Standard SCEP immer noch als Internet Draft. Nun gibt es mit dem Certificate Management Protocol (CMP) gemäß RFC 4210 auch einen Standard, dessen Komplexität ist allerdings nicht zu unterschätzen.

Daher ist es nicht überraschend, dass sich manche Hersteller mit dem Zertifikatsmanagement schwer tun und es sogar vorkommt, dass ein Hersteller zwar eine zertifikatsbasierte Authentisierung implementiert, er sich jedoch über ein automatisiertes Zertifikatsmanagement keine (sinnvollen) Gedanken macht. Was tut man als Nutzer hier oft notgedrungen? Man verwendet ein Zertifikat für alle Geräte mit sehr, sehr langer Gültigkeit, d.h. man verletzt die Kernanforderungen einer Authentisierung nach individuellen und regelmäßig gewechselten Berechtigungsnachweisen. Das ist leider häufiger der Fall als es einem lieb ist. Ohne konkrete Hersteller zu nennen, man wird bei IP-Telefonen, Netzwerkdruckern, Thin Clients und allen möglichen Spezialgeräten fündig, die über LAN oder WLAN angebunden werden.

Selbst wenn alle relevanten IT-Systeme eine zertifikatsbasierte Authentisierung mit automatisiertem Zertifikatsmanagement zufriedenstellend unterstützten, müssten wir trotzdem damit rechnen, dass parallel mit unterschiedlichsten und weitgehend inkompatiblen Implementierungen eines Zertifikatsmanagements zu arbeiten wäre. Das erhöht zumindest den Betriebsaufwand signifikant.

Natürlich gibt es noch eine Vielzahl weiterer immer wieder auftauchender Probleme, etwa der nachlässige Umgang mit Zertifikaten (z.B. der Verzicht auf eine Prüfung eines Serverzertifikats durch den Client, was sofort zu MITM einlädt) und nachlässige Implementierungen der Hersteller.

Ein sehr schönes aktuelles Beispiel liefert Apple iOS 6. Hier hat Apple eine höchst gefährliche Nachlässigkeit beim Umgang mit Zertifikaten beseitigt, die bereits seit Januar 2010 bekannt ist3. Diese Schwachstelle ist so gravierend, dass bei Geräten vor iOS 6 die Informationssicherheit für den Enterprise-Einsatz streng genommen beide Augen zudrücken muss. Interessanterweise ist die Schwachstelle eng mit dem Apple Mobile Device Management (MDM) verbunden. Wenn im Rahmen von MDM geänderte Konfigurationsparameter auf ein mobiles Endgerät eingespielt werden sollen, ist es natürlich entscheidend, dass das Endgerät prüfen kann, ob die Konfigurationsdatei wirklich von einer vertrauenswürdigen und berechtigten Partei stammt. Es ist naheliegend, hier mit einer zertifikatsbasierten Signatur zu arbeiten. Nur sollte der Kreis der Zertifizierungsstellen, deren Zertifikaten man hier traut, sehr kritisch bedacht werden, und es sollte natürlich genau geprüft werden, ob der Verwendungszweck, für den ein Zertifikat ausgestellt wurde, auch passt (und das Zertifikat nicht beispielsweise für die Signatur und Verschlüsselung von E-Mails gedacht ist). Ist dies nicht der Fall (wie vor iOS 6), darf man sich nicht wundern, wenn einem iOS-Endgerät eine schadenstiftende Konfiguration untergejubelt werden kann, ohne dass der Zertifikatsschutz hier Alarm schlägt.

Insgesamt muss festgestellt werden, dass eine zertifikatsbasierte Authentisierung offensichtlich nicht nur für viele Nutzer, sondern auch für Hersteller zu kompliziert ist.

Ist nun das Prinzip einer zertifikatsbasierten Authentisierung in Frage zu stellen?

Nein, es ist sogar das Gegenteil der Fall. Die theoretischen, mathematischen Grundlagen behalten ihre Gültigkeit und sie sind gut. Wir müssen also an organisatorischen Aspekten arbeiten. Warum fehlen uns also z.B. etablierte Standards für die Zertifikatsverwaltung, die auch wirklich systemübergreifend breite Anwendung finden?

Vielleicht, weil wir als Nutzer hier nicht genau genug unsere Anforderungen in Ausschreibungen formuliert und entsprechend Druck ausgeübt haben, denn das ist eines der wenigen Argumente, die bei Herstellern wirklich ankommen. Außerdem müssen wir als Nutzer Kompetenz aufbauen und die Konzepte der zertifikatsbasierten Authentisierung besser verstehen, denn wir müssen den Umgang mit den verschiedenen Implementierungen bewerten und planen können und die Nachlässigkeiten von Herstellern in den Griff bekommen. Nur passt so etwas nicht zum klassischen Outsourcing-Gedanken vieler Entscheider, bei dem die IT letztendlich wie Strom aus der Steckdose kommt und wir uns um die Komplexität keine Sorgen mehr machen müssen.

zugeordnete Kategorien: IT-Sicherheit
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

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

*

.