Eintagsfliegen Kurzzeitzertifikate als Alternative zum Widerruf

Ordnungsmerkmale

erschienen in: <kes> 2006^#1, Seite 85

Autor: Von Christian Kirsch, Cambridge (US), und Jon Callas, Palo Alto (US)

Zusammenfassung: Die Möglichkeit des Widerrufs von Public-Key-Zertifikaten bereitet manchem Sicherheitsexperten Kopfschmerzen. Dieser Artikel diskutiert zwei gebräuchliche Methoden – Sperrlisten und Abfrage per OCSP – sowie als Alternative kurzlebige Zertifikate.

Beim Widerruf (Revocation) eines Zertifikats oder Krypto-Schlüssels wird dieses beziehungsweise dieser vor dem vorgesehenen Ablaufdatum für ungültig erklärt. Doch wie erfahren Anwender hiervon? Die verbreiteten Methoden setzen hierzu regelmäßig eine Aktion des Anwender­(programm)s voraus und sind je nach Anwendungsumfeld mit teilweise erheblichen Nachteilen behaftet. Wo diese zum Tragen kommen, können kurzlebige Zertifikate (Short-lived Certificates, SLCs) eine Alternative darstellen.

Sperrlisten (CRLs)

Die klassische Widerrufs-Lösung in Public-Key Infrastructures (PKIs) sind so genannte Sperrlisten (Certificate Revocation Lists, CRLs), die eine Zertifizierungsstelle (Certificate Authority, kurz CA) digital signiert herausgibt. Darin enthalten sind Seriennummern von Zertifikaten, die nicht mehr verwendet werden sollten. Natürlich sind solche Listen mit einem Zeitstempel versehen und besitzen selbst ein Ablaufdatum, nach dem eine neue Sperrliste abgerufen werden muss.

Die größte Herausforderung für CRLs ist Skalierbarkeit: Die Sperrliste des US-amerikanischen Verteidigungsministeriums (Department of Defense, DoD) hat 2005 eine Größe von 40 MByte erreicht (vgl. [1]); alle DoD-Anwender benötigen für die Liste des aktuellen Tages also viel Bandbreite. Etliche Benutzer dürften zudem Kontakt mit der Außenwelt haben und müssen zusätzlich externe Sperrlisten herunterladen; zudem gibt es externe Partner, welche die DoD-Sperrliste benötigen. Der hierdurch verursachte enorme Netzwerk-Verkehr erscheint besonders überzogen, wenn man bedenkt, dass 99 % – oft sogar 100 % – der abgerufenen Informationen überhaupt nicht benötigt werden, da sie Zertifikate betrifft, die der jeweilige Anwender nicht nutzt.

Die PKI-Gemeinschaft hat versucht, dieses Problem mit zwei technischen Herangehensweisen zu beantworten: Delta-CRLs und so genannte "Partitioned CRLs". Erstere ermöglichen das Herunterladen von Aktualisierungen existierender Sperrlisten (statt jeweils vollständiger Listen), letzteres teilt Sperrlisten in kleinere Teile auf. Die Umsetzung dieser Vorschläge ist jedoch so komplex und fehleranfällig, dass Softwarehersteller sie bislang kaum in ihre Produkte einbauen.

Sperrlisten sind per Definition Negativlisten und sagen dem Benutzer daher nicht, ob ein bestimmtes Zertifikat gültig ist; naturgemäß geben sie nicht einmal Auskunft darüber, ob ein bestimmtes Zertifikat überhaupt jemals von einer Zertifizierungsstelle ausgestellt wurde (vgl. [2]). Wenn ein öffentlicher Schlüssel zur Verifizierung einer Unterschrift oder zur Verschlüsselung verwendet wird, möchte der Benutzer aber letztlich wissen, ob der Schlüssel genau in diesem Moment gültig ist. CRLs können diese Aktualität nicht gewähren: Sperrlisten haben oft eine beträchtliche Gültigkeitsdauer, etwa von einer Woche – erst nach deren Ablauf muss beziehungsweise soll eine neue Liste angefordert werden. Dies bedeutet, dass derartige CRLs durchschnittlich eine halbe Woche veraltet sind – eine solche Verzögerung kann je nach Anwendungsfall durchaus wesentlich sein.

Schlimmer ist jedoch, dass viele der heutigen Anwendungen Sperrlisten generell nicht abrufen. Bei Internet-Browsern ist es üblich, beim Zugriff auf eine SSL-geschützte Seite keine CRL anzufordern, weil der Seitenaufbau dadurch so stark verzögert würde, dass Anwender den Browser als "langsam" empfänden. In diesem Fall ist faktisch überhaupt kein Widerruf von Zertifikaten möglich. Das Gleiche gilt bei vielen Anwendungen für sichere E-Mails, da das Herunterladen einer CRL beim Öffnen einer Nachricht die gesamte Anwendung blockieren würde [3].

Leider verwenden etliche Organisationen zudem CRL Distribution Points (CDPs), die nicht vom Internet aus erreichbar sind; dies macht eine Widerrufs-Prüfung über Organisationsgrenzen hinweg gegebenenfalls unmöglich.

Abschließend bleibt festzustellen, dass Sperrlisten nur für X.509-Zertifikate und nicht für alternative Standards wie OpenPGP verwendet werden. In Anwendungen beispielsweise zur E-Mail-Sicherung, wo häufig neben dem X.509-basierten S/MIME-Protokoll auch OpenPGP zum Einsatz kommt, um die Kompatibilität mit bestimmten Partnern sicherzustellen, ist eine jedoch identische Widerrufsmethode wünschenswert, um die Komplexität für den Systemadministrator gering zu halten.

Online Certificate Status Protocol (OCSP)

Um die Probleme von Sperrlisten zu umgehen, wurde das Online Certificate Status Protocol (OCSP, RFC 2560) entworfen. Es sieht vor, dass eine Sicherheitsanwendung eine Anfrage an einen Server (den sog. OCSP-Responder) sendet, der Statusinformationen für das angefragte Zertifikat liefert: Die Anwendung schickt den Ausstellernamen (CA) und die Seriennummer an den OCSP-Responder und erhält in einer (üblicherweise signierten) Antwort zurück, ob das Zertifikat widerrufen worden ist. OCSP löst somit das Problem der Skalierbarkeit, da es die Abfrage des Zertifikatsstatus auf Anfrage und nur für bestimmte Zertifikate möglich macht – das periodische Herunterladen großer Dateien entfällt.

Unglücklicherweise übernimmt OCSP jedoch auch Nachteile von CRLs – entweder aufgrund des Standards oder der praktischen Umsetzung: Da das Protokoll ebenfalls keine positive Statusinformationen über ein Zertifikat liefert, arbeiten beispielsweise viele OCSP-Responder einfach auf der Basis ohnehin vorhandener Sperrlisten. Selbst wenn dies nicht der Fall wäre, bietet OCSP keine Möglichkeit, eine positive Antwort zu geben ("Response Extensions" sind lt. RFC 2560 möglich, aber inhaltlich nicht standardisiert). Die Arbeitsgruppe für ISIS-MTT des TeleTrusT Deutschland e. V. hat zwar eine entsprechende Erweiterung von OCSP vorgeschlagen, diese fand aber keine Verbreitung.

OCSP-Responder, die auf Daten von Sperrlisten basieren, erben aber naturgemäß den Nachteil der Zeitverzögerung. Während das OCSP-Protokoll selbst in der Lage wäre, Antworten aktuell zu halten, ist die darunter liegende Sperrliste dennoch oft mehrere Tage alt. Zudem ist auch OCSP nur auf den X.509-Standard anwendbar und nicht für andere Verfahren wie OpenPGP vorgesehen.

Kurzlebige Zertifikate

Fragt man sich, was eine OCSP-Antwort oder Sperrlistenrecherche im Kern ausmacht, so geht es letztlich um eine digital signierte Aussage zur Gültigkeit der Verbindung zwischen einem Namen und einem öffentlichen Schlüssel zu einem gegebenen Zeitpunkt. Ein Zertifikat selbst kann dies ebenfalls beantworten, sofern es "aktuell" ist. Der Unterschied zwischen einer Widerrufs-Anfrage und einem Zertifikat ist daher nicht ihre Natur, sondern vor allem ihr Format (vgl. [5]). Dieser Gedanke führt zu einer erstaunlich einfachen Alternative: kurzlebige Zertifikate.

Während Zertifikate üblicherweise eine Lebensdauer in der Dimension von Jahren haben, besitzen kurzlebige Zertifikate eine Lebensdauer von Wochen oder Stunden, manchmal sogar nur Minuten. Das dahinter liegende Konzept besagt, dass ein Zertifikat erst gar nicht widerrufen werden muss, wenn seine Lebensdauer kürzer ist als das Intervall zwischen zwei "nachprüfbaren" Widerrufs-Zeitpunkten, beispielsweise zwischen zwei Sperrlistenaktualisierungen. Die Länge dieses Intervalls hängt von der jeweiligen Anwendung ab.

Die kurze Lebensdauer solcher Zertifikate lässt sie also verfallen, bevor ein Widerruf jemals (sinnvoll) notwendig würde. Somit eliminieren sie die Notwendigkeit eines gesonderten Mechanismus für Widerrufe. Verschlüsselungsexperten haben verschiedene Wege vorgeschlagen, wie man kurzlebige Zertifikate praktisch umsetzen könnte. Die gängigste Ansicht ist, dass dieselbe Verbindung zwischen einem öffentlichen Schlüssel und seinen Identifizierungsmerkmalen (z. B. Name oder E-Mail-Adresse) jeweils mit neuen kurzlebigen Signaturen erneut zertifiziert wird. Andere schlagen vor, das übliche Langzeit-Zertifikat weiterhin auszustellen und zusätzlich die Möglichkeit zu schaffen, kurzlebige Zertifikate mit demselben Schlüssel und Identifikationsmerkmal bei der CA anzufordern, um die Gültigkeit des Zertifikats zu bestätigen.

Die erste Methode hat große Vorteile: Sie erfordert keine Veränderung des Verhaltens existierender Anwendungen. Erstens können alle PKI-Anwendungen ohnehin zwischen abgelaufenen und nicht abgelaufenen Zertifikaten unterscheiden. Zweitens sollte jede PKI-Anwendung in der Lage sein, automatisch an bekannten Quellen nach neuen Zertifikaten zu suchen (z. B. in LDAP-Verzeichnisdiensten). Diese Quelle liefert dann das aktuelle Zertifikat oder generiert es womöglich sogar erst auf Anfrage. Selbstverständlich erfordern kurzlebige Zertifikate somit eine Onlineverbindung, die aber auch für OCSP und (zumindest zum Zeitpunkt des CRL-Downloads) bei Sperrlisten notwendig ist.

Während Sperrlisten und OCSP gegebenenfalls nur negative Aussagen (zu einem bestehenden "Langzeit"-Zertifikat) treffen, liefern kurzlebige Zertifikate eine positive Aussage. Umgekehrt ist allerdings der Administrator einer Zertifizierungsstelle bei Kurzzeitzertifikaten dazu verdammt, den regulären Ablauf des Zertifikats abzuwarten, wenn der Schlüssel kompromittiert wurde. Während dies auf den ersten Blick heikel erscheint, besteht doch – zumindest auf Nutzerseite – ein ähnliches Problem mit Sperrlisten: Der Administrator kann das Zertifikat in einem solchen Fall zwar sofort widerrufen und die Seriennummer zur Sperrliste hinzufügen, aber die Anwendungen werden davon nichts erfahren, bis ihre Sperrliste abgelaufen ist und sie die aktuelle Liste heruntergeladen haben; wo OCSP-Daten auf Sperrlisten basieren, bleibt dieses Problem sogar bei der Online-Anfrage bestehen.

Für die Anforderung zur Verlängerung eines kurzlebigen Zertifikats gibt es zwei mögliche Wege: Entweder bittet der Benutzer die CA um eine Verlängerung der Zertifizierung oder die CA fährt jeweils automatisch bis auf Widerruf mit der Re-Zertifizierung fort. Die zweite Methode sollte vorgezogen werden: Erstens sind die Benutzer nicht immer online. Wenn ein Geschäftspartner dem Benutzer eine verschlüsselte E-Mail senden will, während dieser offline ist, sollte die Zertifizierungsstelle immer noch in der Lage sein, ein aktuelles Zertifikat auszustellen. Zweitens erzeugt der Einsatz dieser Funktionalität in der Zertifizierungsstelle weniger Datenverkehr und ist weniger fehleranfällig.

Ein Problem mit kurzlebigen Zertifikaten sind die Zertifikate der Zertifizierungsstellen. Um eine stabile Basis für die Re-Zertifizierung von kurzlebigen Schlüsseln zu schaffen, müssen CA-Zertifikate weiterhin eine lange Lebensdauer besitzen. Für eine Widerrufsmöglichkeit von CA-Zertifikaten wieder zu Sperrlisten zurückzukehren, würde jedoch das Konzept der kurzlebigen Zertifikate infrage stellen. Ein möglicher Ausweg ist, dass Benutzer kurzlebige Zertifikate von der Zertifizierungsstelle anfordern können, die dasselbe Identifikationsmerkmal und denselben Schlüssel enthalten wie der langlebige CA-Haupt-Schlüssel. Ein solches "Gesundheitszertifikat" bestätigt dann die fortwährende Gültigkeit des CA-Schlüssels.

Ein rechtlicher Aspekt, der für den Einsatz von kurzlebigen Zertifikaten spricht, könnte sein, dass sich Gesetze zur digitalen Signatur notgedrungen mit Zertifikaten und ihrer Lebensdauer auseinandersetzen müssen, aber nicht unbedingt neue Widerufs-Methoden wie OCSP abdecken. Die Verwendung standardisierter Zertifikate als Ersatz für Widerrufe benötigt daher keine Aktualisierung bestehender Gesetze und unterstützt eine einfachere und "dauerhaftere" Gesetzgebung.

Natürlich ist das regelmäßige Neuausstellen und Abrufen von kurzlebigen Zertifikaten mit einem gewissen Aufwand bei der CA und eventuell auch beim Anwender verbunden. Ob dieser Mehraufwand gerechtfertigt oder überhaupt machbar erscheint, wird nicht zuletzt davon abhängen, ob diese Funktionen – aus organisatorischen, rechtlichen oder technischen Gründen – automatisierbar sind oder zumindest für eine Stapelverarbeitung regelmäßig menschliche Eingriffe oder Autorisierungen notwendig werden. Auch die Frage, ob und wie lange ausgestellte Zertifikate zu dokumentieren und zu archivieren sind, dürfte eine Rolle spielen.

Fazit

Die Sicherheitsbranche hat seit langem auf eine Vereinfachung für Anwender hingearbeitet und die Vereinfachung von Implementierung und Administration weitgehend ignoriert. Die Vorteile von kurzlebigen Zertifikaten liegen in etlichen Anwendungen so deutlich auf der Hand, dass schwer nachvollziehbar ist, warum sie so lange übersehen wurden. Sie verwenden den existierenden Aufbau von Zertifikaten für einen neuen Zweck und machen Sperrlisten und OCSP überflüssig.

Bestehende Anwendungen benötigen dabei entweder keine oder nur sehr wenige Änderungen, um sie mit kurzlebigen Zertifikaten kompatibel zu machen. In einigen Bereichen, wo die Zertifizierungsstelle und die PKI-Anwendung fast nicht mehr zu unterscheiden sind, wie es bei Gateways für E-Mail-Verschlüsselung der Fall ist, haben sich kurzlebige Zertifikate bereits als effektive Widerrufsmethode bewährt.

Im Übrigen bleibt beim Abwägen eines geeigneten Widerrufs­(prüf)­verfahrens zu betrachten, wie häufig in einer Anwendungsumgebung beziehungsweise PKI ein Widerruf vorkommt, wie zeitkritisch seine Verbreitung ist und wie bedeutsam seine Auswirkungen sind. Wo ein Widerruf die extreme Ausnahme ist und genügend Karenzzeit oder geringe Schäden bei einer illegitimen Nutzung eines kompromittierten Schlüssels zu erwarten sind, bleiben womöglich Sperrlisten eine handhabbare Lösung.

Bei höheren Aktualitätsanforderungen und einer sinnvollen Umsetzung von OCSP-Respondern ist deren Betriebsaufwand und Nutzen gegen die regelmäßige Neuerstellung von Kurzzeitzertifikaten abzuwägen – hier dürfte nicht zuletzt die Größe und "Abgeschlossenheit" der betrachteten PKI eine Rolle spielen. Wo Neuzertifizierungen und Aktualisierung von Zertifikaten ohnehin automatisiert ablaufen, dürfte hingegen die alleinige Nutzung von kurzlebigen Zertifikaten ohne zusätzliche Widerrufsmechanismen die einfachste Lösung sein.

Christian Kirsch ist Product Marketing Manager bei der PGP Corporation in Cambridge (MA, USA). Jon Callas ist Hauptautor des OpenPGP-Standards der Internet Engineering Task Force (IETF), Chief Technology Officer und Chief Security Officer bei der PGP Corporation in Palo Alto (CA, USA).

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006^#1, Seite 85