Zusammenfassung

  • Der Verstoß von DigiNotar aus dem Jahr 2011 führte zur Ausstellung gefälschter Zertifikate, darunter ein Zertifikat, das bei versuchten Man-in-the-Middle-Angriffen gegen Google-Nutzer, hauptsächlich im Iran, verwendet wurde, und zwang Browser- und Betriebssystemhersteller, DigiNotar-Zertifikate zu entfernen oder ihnen zu misstrauen.
  • Mozilla kritisierte DigiNotar öffentlich, weil das Unternehmen mehrere gefälschte Zertifikate Wochen zuvor entdeckt und widerrufen hatte, ohne Mozilla zu benachrichtigen. Microsoft erklärte später alle DigiNotar-Zertifikate für nicht vertrauenswürdig. ENISA bezeichnete das Ereignis als Angriff auf die Grundlagen der sicheren elektronischen Kommunikation.
  • Die Abhängigkeit des niederländischen öffentlichen Sektors machte das Ereignis zu mehr als nur einer Bereinigung durch Browseranbieter. DigiNotar stellte Zertifikate aus, die mit staatlichen PKI-Diensten verbunden waren, und der Vertrauensverlust verursachte ein Kontinuitätsproblem für Regierungswebsites und -dienste, die unter Notfalldruck migriert werden mussten.
  • Die Aufzeichnungen stützen eine hochsichere Feststellung der Rechenschaftspflicht in Bezug auf die operative Kontrolle der CA, die verspätete Benachrichtigung und die Governance der Root-Programme. Sie stützen nicht die Behauptung, dass jedes Zertifikat missbraucht wurde, dass jeder Regierungsdienst ausfiel oder dass die aktuellen PKI-Praktiken seit 2011 unverändert sind.

Beweisaufnahme und ihre Verwendung

Dieser Artikel nutzt Quellen von Fox-IT, ENISA, Mozilla, Google, Microsoft, VASCO, HKCERT, CCDCOE, akademische Quellen, CA/Browser Forum, Root-Programme, RFC, Certificate Transparency, NIST und ENISA DNS, um Fakten zum Vorfall, zur Governance des öffentlichen Vertrauens und zu Lehren für die operative Kontinuität zu trennen.

#Öffentliche AufzeichnungVerwendung in dieser Analyse
1Fox-IT-Zwischenbericht, Operation Black TulipPrimäre Untersuchungsbeweise für den Zeitplan des Verstoßes, den Zweck der Warnung der Beteiligten und die Grenzen der offengelegten forensischen Details.
2ENISA, Operation Black Tulip: Zertifizierungsstellen verlieren AutoritätEuropäische Bewertung von Kontrollversagen, Reaktion von Browsern und Regierungen und Lehren für das öffentliche Vertrauen.
3Mozilla Security Blog, Nachbereitung der DigiNotar-EntfernungMaßnahmen des Mozilla-Root-Programms, Analyse der unterlassenen Benachrichtigung und vollständige Entfernungserklärung.
4Google Online Security Blog, versuchte Man-in-the-Middle-AngriffeGoogles Aussage, dass gefälschte DigiNotar-Zertifikate bei versuchten MITM-Angriffen hauptsächlich gegen Nutzer im Iran eingesetzt wurden.
5Microsoft MSRC, mehr zu Microsofts Reaktion auf DigiNotarMicrosofts Reaktion, Entfernung und Kontext des nicht vertrauenswürdigen Zertifikatsspeichers.
6Microsoft MSRC, aktualisiert Sicherheitsempfehlung 2607712Microsofts Feststellung, dass alle DigiNotar-Zertifikate nicht vertrauenswürdig waren.
7Mozilla-Sicherheitsempfehlung MFSA 2011-34Browser-Sicherheitshinweis als Beweis für aktive MITM-Angriffe, fehlerhaft ausgestellte Zertifikate und unbekanntes volles Ausmaß der Kompromittierung.
8HKCERT, DigiNotar CA-SicherheitsverstoßCSIRT-Warnkontext, Beispiele für gefälschte Zertifikate und Anleitung zur Risikominderung für Endnutzer.
9VASCO, Konkursanmeldung von DigiNotarUnternehmensinsolvenzaufzeichnung und Zeitpunkt nach dem Vertrauensentzug.
10CCDCOE Cyber Law Toolkit, DigiNotar 2011Rechtliche und strategische Zusammenfassung der Kompromittierung, Beteiligung der niederländischen Regierung und Einordnung in das internationale Cyberrecht.
11Journal of Strategic Security, DigiNotar: Die erste niederländische digitale Katastrophe analysiertAkademische Analyse der Abhängigkeit der nationalen Regierung und warum das Ereignis zu einem niederländischen Digitalkatastrophen-Fall wurde.
12CA/Browser Forum Baseline RequirementsModernes Vokabular und Lebenszyklusanforderungen für die Governance öffentlich vertrauenswürdiger Zertifikate.
13Mozilla Root Store PolicyAktuelle Root-Programm-Governance und konditionaler Browser-Vertrauenskontext.
14Microsoft Trusted Root Program requirementsPlattform-Root-Vertrauensgovernance und betriebliche Bedeutung von Misstrauensspeichern.
15RFC 5280Vokabular zu Zertifikatsketten, CAs, CRLs und vertrauenden Parteien.
16Google Certificate Transparency projectSpäterer Ökosystem-Reaktionskontext: Öffentliche Protokollierung und Überwachung zur Reduzierung des Risikos stiller Fehlausstellungen.
17NIST SP 800-57 Part 1 Rev. 5Lebenszyklus des Schlüsselmanagement und Erwartungen an den Schutz kryptografischer Schlüssel.
18ENISA DNS Identity reportBeziehung zwischen Domain-Identität, delegierter Kontrolle und Grenzen des öffentlichen Vertrauens.

Eine CA-Kompromittierung verändert die Realität des Nutzers, bevor dieser es merkt

Das DigiNotar-Ereignis war schwerwiegend, weil Zertifizierungsstellen im Pfad des unsichtbaren Vertrauens sitzen. Ein Nutzer, der eine vertraute Website besucht, wählt normalerweise keine CA aus. Der Browser oder das Betriebssystem vertraut bereits einer Reihe von Wurzeln. Wenn eine CA ein gefälschtes Zertifikat für eine Domain ausstellen kann, die sie nicht kontrolliert, kann ein Angreifer diese Domain gegenüber Clients, die der CA vertrauen, möglicherweise imitieren. Der Nutzer sieht eine gültige verschlüsselte Verbindung, während die Vertrauensaussage falsch ist.

Googles Sicherheitsbeitrag vom August 2011 beschrieb Berichte über versuchte SSL-Man-in-the-Middle-Angriffe gegen Google-Nutzer, hauptsächlich im Iran, unter Verwendung eines von DigiNotar ausgestellten gefälschten Zertifikats. Die Mozilla-Empfehlung beschrieb ebenfalls einen aktiven MITM-Angriff auf sichere SSL-Verbindungen zu Google-Servern und stellte fest, dass das gefälschte Zertifikat von DigiNotar fehlerhaft ausgestellt worden war. Dies sind keine abstrakten PKI-Risiken. Sie sind nutzerseitige Folgen von Kontrollversagen der CA.

Der von Fox-IT über eine VASCO-SEC-Einreichung veröffentlichte Zwischenbericht formulierte seinen Zweck dahingehend, den Beteiligten genügend Informationen für ihre eigene Risikoanalyse zu geben und gleichzeitig einige sensible Details zurückzuhalten. Genau das ist die Spannung bei einem CA-Vorfall. Die Öffentlichkeit benötigt genügend Informationen, um zu entscheiden, ob das Vertrauen noch sicher ist. Der Ermittler kann nicht jede Technik veröffentlichen, die Angreifern helfen würde. Die CA hat Anreize, das Vertrauen zu wahren. Browseranbieter müssen schnell handeln, weil ihre Nutzer exponiert sind.

DigiNotars Kontrolle über den Schaden bestand daher, bevor die Öffentlichkeit vom Schaden wusste. Die CA kontrollierte Ausstellungssysteme, Netzwerksegmentierung, Protokollierung, Widerruf, Vorfallserkennung, Benachrichtigung und die Integrität regierungsbezogener Zwischenstellen. Sobald gefälschte Zertifikate existierten, kontrollierten Browserhersteller und Regierungen das Notfall-Misstrauen und die Migration. Nutzer kontrollierten fast nichts, außer ob sie Software aktualisierten oder die Nutzung betroffener Dienste einstellten, nachdem jemand anderes sie gewarnt hatte.

Die Verzögerung der Benachrichtigung war kein Fehler der Öffentlichkeitsarbeit

Die Nachbereitung von Mozilla zur Entfernung ist eines der klarsten Rechenschaftsdokumente in der Aufzeichnung. Darin heißt es, dass DigiNotar sechs Wochen zuvor einige gefälschte Zertifikate entdeckt und widerrufen hatte, ohne Mozilla zu benachrichtigen, und dass einige dieser Zertifikate für Mozillas eigene Domains galten. Das Problem ist keine Frage der Etikette. Root-Programme sind auf rechtzeitige Vorfallsmeldungen angewiesen, denn Browseranbieter sind diejenigen, die Nutzer durch Aktualisierung von Vertrauensentscheidungen in großem Maßstab schützen können.

Eine CA könnte glauben, sie habe bekannte schädliche Zertifikate widerrufen und einen Eindringling eingedämmt. Dieser Glaube reicht nicht aus, wenn die CA das volle Ausmaß der Kompromittierung nicht nachweisen kann. Die Mozilla-Empfehlung besagte, dass DigiNotar Beweise dafür gemeldet hatte, dass weitere gefälschte Zertifikate ausgestellt und aktiv verwendet wurden, das volle Ausmaß jedoch unbekannt war. Microsoft entfernte zunächst zwei DigiNotar-Stammzertifikate aus den Vertrauenslisten und aktualisierte dann seine Reaktion, um alle DigiNotar-Zertifikate in den nicht vertrauenswürdigen Zertifikatsspeicher zu verschieben.

Die Unsicherheit trieb die Eskalation voran.

Die Verzögerung der Benachrichtigung verändert die Schadenskurve. Während der Verzögerung vertrauen vertrauende Parteien weiterhin Zertifikaten, die möglicherweise nicht vertrauenswürdig sind. Browseranbieter können keine Misstrauens-Updates ausliefern. Domaininhaber wissen nicht, dass sie nach gefälschten Zertifikaten suchen müssen. Regierungsdienste planen möglicherweise weiter, als ob die CA intakt wäre. Nutzer können Ziel von MITM-Angriffen sein, ohne eine sinnvolle Chance, das CA-Versagen zu erkennen.

Deshalb muss die Vorfallsoffenlegung durch eine CA schneller und vollständiger sein als die Offenlegung durch normale Anbieter. Die CA schützt nicht nur ihre eigenen Kunden. Sie schützt jeden, dessen Software ihrer Wurzel vertraut. Eine verspätete Benachrichtigung verwandelt das gesamte Ökosystem der vertrauenden Parteien in eine ungewarnte Risikopopulation.

Die Abhängigkeit der niederländischen Regierung veränderte den Explosionsradius

DigiNotar war nicht nur eine kommerzielle CA. Öffentliche Quellen beschreiben ihre Rolle in der Zertifikatsinfrastruktur der niederländischen Regierung. Diese Rolle machte das Misstrauen betrieblich schwierig. Wenn ein Browseranbieter alles DigiNotar-Vertrauen sofort entfernte, konnten Regierungsdienste, die mit DigiNotar verbundene Zertifikate verwendeten, schwer oder gar nicht mehr erreichbar sein. Wenn das Vertrauen vorübergehend bestehen blieb, konnten Nutzer gefälschten Zertifikaten ausgesetzt sein. Das ist die Falle der PKI-Abhängigkeit des öffentlichen Sektors.

Die Zusammenfassung von ENISA zur Operation Black Tulip besagt, dass gefälschte Zertifikate für Hunderte von Websites, darunter Google und Skype, erstellt wurden und dass die niederländische Regierung und die Browseranbieter Maßnahmen ergriffen, als der Vorfall öffentlich wurde. Die Analyse des Journal of Strategic Security behandelt das Ereignis als die erste niederländische digitale Katastrophe, da es das private CA-Versagen mit der nationalen Abhängigkeit von öffentlichen Diensten verknüpfte.

Die Insolvenzankündigung von VASCO zeigt den Unternehmensendpunkt: DigiNotar meldete freiwillig Insolvenz an und wurde im September 2011 für bankrott erklärt.

Das Kontinuitätsproblem war nicht theoretisch. Regierungsdienste verlassen sich auf TLS-Zertifikate für Identität, Vertraulichkeit und Vertrauen. Der Austausch von Zertifikaten über Behörden und Systeme hinweg erfordert Koordination: neue Anbieter, Validierung, Bereitstellung, Tests, Nutzeranleitungen und Browserkompatibilität. Wenn die CA das Vertrauen verloren hat, birgt jeder Tag der Übergabe ein Risiko. Wenn die Übergabe überstürzt wird, können Dienste ausfallen.

Damit wird DigiNotar zu einem Fall von Kontinuität im öffentlichen Sektor. Eine Regierung kann die Zertifikatsausstellung auslagern, aber sie kann die öffentlichen Folgen eines Vertrauenszusammenbruchs nicht auslagern. Die Beschaffung muss fragen, ob eine CA über starke operative Kontrollen, unabhängige Audits, Pflichten zur Vorfallbenachrichtigung, Notfall-Migrationspläne und eine Stellung im Root-Programm verfügt. Sie muss auch fragen, wie schnell Zertifikate ersetzt werden können, wenn das Vertrauen plötzlich entzogen wird.

Browseranbieter handelten als Notfall-Gouverneure

Wenn das öffentliche Vertrauenssystem versagt, werden Browser- und Betriebssystemanbieter zu Notfall-Gouverneuren. Mozilla entzog das Vertrauen. Microsoft verschob DigiNotar-Zertifikate in den nicht vertrauenswürdigen Zertifikatsspeicher. Google warnte die Nutzer und nutzte Browser-Sicherheitsmechanismen, um zu reagieren. HKCERT gab öffentliche Leitlinien heraus. Diese Maßnahmen schützten die Nutzer, brachen aber auch die Erreichbarkeit von Diensten, die auf DigiNotar angewiesen waren, oder drohten damit.

Diese Doppelrolle ist unbequem, aber notwendig. Ein Root-Programm ist keine passive Liste. Es ist ein Governance-System. Die Mozilla Root Store Policy und die Anforderungen des Microsoft Trusted Root Program machen heute explizit, was der DigiNotar-Fall gezeigt hat: Die Aufnahme ist an die fortdauernde Einhaltung von Vorschriften, Offenlegung, Audits und Sicherheitskontrollen gebunden. Eine vertrauenswürdige Wurzel ist ein öffentliches Sicherheitsprivileg, kein dauerhaftes Eigentumsrecht.

Notfall-Misstrauen ist eine stumpfe Kontrolle. Es kann Nutzer vor gefälschten Zertifikaten schützen, aber es kann nicht jedes legitime Altzertifikat von jedem bösartigen unterscheiden, und zwar so, dass die gesamte Dienstkontinuität erhalten bleibt. Deshalb sind CA-Kontrollen und rechtzeitige Offenlegung im Vorfeld so wichtig. Wenn Browseranbieter zwischen globalem Misstrauen und fortgesetzter Exposition wählen müssen, ist die CA bereits auf einem Niveau gescheitert, das nachgelagerte Akteure nicht mehr elegant reparieren können.

Das Ereignis trug auch dazu bei, stärkere Ökosystem-Mechanismen zu motivieren. Certificate Transparency, heute ein zentraler Bestandteil der öffentlichen Web-PKI, macht Zertifikate öffentlich sichtbar, sodass Domaininhaber, Browser und Monitore Fehlausstellungen früher erkennen können. CT ersetzt die CA-Sicherheit nicht vollständig, verringert aber die Wahrscheinlichkeit, dass ein gefälschtes Zertifikat wochenlang verborgen bleiben kann. DigiNotar ist Teil der Geschichte, die stilles CA-Verhalten weniger akzeptabel machte.

Die operative Kontrolle folgt der Fähigkeit, Schaden zu begrenzen

Der Begriff operative Kontrolle über den Schaden ist bewusst gewählt. DigiNotar kontrollierte den Angreifer nicht. Sie kontrollierte jedoch, ob ihre CA-Systeme segmentiert, gepatcht, überwacht, protokolliert und mit angemessenem Schlüsselschutz verwaltet wurden. Sie kontrollierte, ob anomale Ausstellungen erkannt und eskaliert wurden. Sie kontrollierte, ob Browseranbieter benachrichtigt wurden, als gefälschte Zertifikate entdeckt wurden. Sie kontrollierte, wie viele Beweise Ermittler wiederherstellen konnten.

Die Materialien von Fox-IT und ENISA weisen auf grundlegende Mängel bei den Sicherheitsmaßnahmen und breite Bedenken hinsichtlich der Kompromittierung hin. Die genauen technischen Details sollten sorgfältig behandelt werden, aber die öffentliche Aufzeichnung ist stark genug, um zu zeigen, dass die Kontrollpraktiken für eine öffentlich vertrauenswürdige CA unzureichend waren. Die Systeme einer CA sind keine gewöhnliche Unternehmens-IT. Sie sind Maschinen zur Erstellung von Behauptungen, die Browser und Betriebssysteme global akzeptieren. Ein grundlegendes Kontrollversagen auf dieser Ebene wird zu öffentlichem Schaden.

Die Baseline Requirements des CA/B Forums und die Leitlinien des NIST zum Schlüsselmanagement liefern modernes Vokabular für diese Pflicht: Lebenszyklusmanagement, Identitätsnachweis, Auditierung, Schlüsselschutz, Widerruf und Systemsicherheit. Diese Standards sollten nicht so gelesen werden, als ob jede Kontrolle von 2026 im Jahr 2011 identisch existierte. Sie sind nützlich, weil sie zeigen, was das Ökosystem gelernt hat zu formalisieren. Eine CA muss nicht nur nachweisen können, dass Zertifikate ausgestellt werden, sondern auch, dass die Ausstellungsautorität nicht unbemerkt übernommen werden kann.

Zur operativen Kontrolle gehört auch die Kommunikation über den Schaden. Eine CA, die die Menge der gefälschten Zertifikate nicht eingrenzen kann, kann die Welt nicht verantwortungsbewusst bitten, ihr weiter zu vertrauen. Eine CA, die von gefälschten Zertifikaten weiß und die Benachrichtigung verzögert, kontrolliert ein Zeitfenster, in dem andere unwissentlich exponiert sind. Eine CA, die Regierungsfunktionen bedient, kontrolliert den Zeitplan, nach dem Behörden migrieren müssen. In jedem Fall ist die Kontrolle über die Beweise gleichbedeutend mit der Kontrolle über den Schaden.

Der Widerruf war unzureichend, weil das Vertrauen bereits zusammengebrochen war

Im normalen Zertifikatsbetrieb ist der Widerruf der Mechanismus, mit dem gesagt wird, dass einem bestimmten Zertifikat nicht mehr vertraut werden sollte. Das DigiNotar-Ereignis ging über den normalen Widerruf hinaus. Wenn der Aussteller selbst kompromittiert ist und den vollständigen Satz gefälschter Zertifikate nicht nachweisen kann, können vertrauende Parteien nicht sicher davon ausgehen, dass nur bekannte Zertifikate schlecht sind. Deshalb gingen die Browseranbieter vom Widerruf oder Misstrauen gegenüber bestimmten Wurzeln zu einem breiteren Misstrauen über.

Diese Unterscheidung ist zentral. Der Widerruf behandelt bekannte schlechte Blätter. Das Misstrauen gegenüber der Wurzel behandelt die Unzuverlässigkeit des Ausstellers. Ersteres ist chirurgisch. Zweiteres ist systemisch. Das Versagen von DigiNotar wurde systemisch, weil die öffentliche Aufzeichnung nicht das Vertrauen stützen konnte, dass die CA-Umgebung vertrauenswürdig war und alle gefälschten Zertifikate bekannt und widerrufen waren.

Die Nutzer verstehen diese Unterscheidung selten. Sie erleben sie als Software-Updates, Warnseiten oder blockierte Dienste. Dienstbetreiber erleben sie als notfallmäßigen Zertifikatsaustausch. Regierungen erleben sie als Kontinuitätsplanung. Browseranbieter erleben sie als Risikoentscheidung unter Unsicherheit. Die Unfähigkeit der CA, den Umfang nachzuweisen, zwingt alle anderen zu teuren Reaktionen.

Moderne CT-Protokollierung, strengere Audits und die Vorfallsprozesse der Root-Programme sind darauf ausgelegt, diese Unsicherheit zu verringern. Sie beseitigen sie nicht. Eine CA, die die Ausstellungskontrolle verliert, verursacht immer noch eine Krise. Die operative Frage bleibt, ob der Umfang schnell genug gemessen werden kann, um Misstrauen auf Wurzelebene zu vermeiden.

Käufer öffentlicher Dienste sollten die CA-Auswahl nicht als Ware behandeln

TLS-Zertifikate sind oft billig, automatisiert und Routine. Das macht es verlockend, die CA-Auswahl als nebensächliche Beschaffungsfrage zu behandeln. DigiNotar zeigt, warum dies für öffentliche Dienste gefährlich ist. Der Vertrauensstatus der CA kann bestimmen, ob Bürger sicher auf Regierungsseiten zugreifen können. Die Vorfallsbearbeitung der CA kann bestimmen, ob Browseranbieter das Vertrauen aufrechterhalten. Die Auditqualität der CA kann bestimmen, ob eine Kompromittierung erkannt wird, bevor gefälschte Zertifikate missbraucht werden.

Käufer öffentlicher Dienste sollten nach Belegen fragen. Welche Root-Programme enthalten die CA? Welche Audits sind öffentlich? Wie sind die Ausstellungssysteme segmentiert? Wie werden private Schlüssel geschützt? Wie wird anomale Ausstellung erkannt? Wie schnell werden Vorfälle an Root-Programme, Regulierungsbehörden, Abonnenten und betroffene Domaininhaber gemeldet? Wie viele alternative CAs können Notfall-Ersatzzertifikate ausstellen? Wie sind die Zertifikate über die Behörden hinweg inventarisiert? Wie schnell kann eine vollständige Migration durchgeführt werden?

Sie sollten auch Konzentration vermeiden. Eine einzelne CA oder ein verwalteter Zertifikatsanbieter mag effizient sein, kann aber zu einer einheitlichen Abhängigkeit werden. Eine Regierung, die sich auf eine CA für viele Behörden verlässt, sollte einen Notfallpfad zu anderen Anbietern unterhalten, einschließlich Validierungsdatensätzen, Automatisierung und getesteten Bereitstellungsverfahren. Andernfalls wird das Misstrauen gegenüber einem Anbieter zu einem Ausfall öffentlicher Dienste.

Die DNS-Delegationsmacht ist hier wichtig, weil Zertifikate Domainnamen an öffentliche Schlüssel binden. Domainkontrolle, CA-Validierung, DNS-Einträge und öffentliches Vertrauen sind miteinander verbunden. Wenn die Prozesse zur Domain-Identität schwach sind, kann die Zertifikatsausstellung missbraucht werden. Wenn Zertifikate nicht vertrauenswürdig sind, können Domainnamen korrekt aufgelöst werden, scheitern jedoch sicher am Browser. Die öffentliche Kontinuität hängt sowohl von der DNS- als auch von der PKI-Kontrolle ab.

Was die Aufzeichnung nicht beweist

Die öffentliche Aufzeichnung beweist nicht, dass jedes gefälschte Zertifikat bei einem aktiven Angriff verwendet wurde. Sie beweist nicht, dass alle niederländischen Regierungsdienste für dieselbe Dauer oder aus demselben Grund nicht verfügbar waren. Sie beweist nicht, dass jeder Mitarbeiter von DigiNotar den Fehler kannte oder verursachte. Sie beweist keine vollständige endgültige Zuordnung für den Angreifer. Sie beweist auch nicht, dass die aktuelle CA-Governance mit der von 2011 identisch ist.

Diese Grenzen schwächen die Feststellung der Rechenschaftspflicht nicht. Sie schärfen sie. Ein CA-Vorfall ist gerade dann gefährlich, wenn die vollständige Menge der gefälschten Zertifikate, ihre Verwendungen und die betroffenen Parteien ungewiss ist. Das Fehlen vollständigen Wissens ist kein Grund, das Vertrauen zu bewahren. Es ist ein Grund, warum Root-Programme das Vertrauen möglicherweise entziehen müssen.

Die Aufzeichnung sollte auch nicht verwendet werden, um zu behaupten, dass jegliches Outsourcing von CA-Diensten unsicher sei. Die öffentliche Vertrauens-PKI ist ein Ökosystem, weil keine einzelne Website oder Behörde das globale Browser-Vertrauen allein aufrechterhalten kann. Die Lektion ist nicht die selbst ausgestellte Isolation. Die Lektion ist diszipliniertes Outsourcing mit öffentlichen Nachweisen, Notfall-Migration und klarer Verantwortung für die Benachrichtigung.

Der Konkurs von DigiNotar ist relevant, aber nicht das Maß für den Schaden. Ein Unternehmen kann kommerziell scheitern, nachdem es das Vertrauen verloren hat, aber der größere öffentliche Schaden ist der Zeitraum, in dem Nutzer, Regierungen und Browser unter Unsicherheit operieren mussten. Das ist die Rechenschaftsoberfläche.

Praktische Rechenschaftstests

Eine Zertifizierungsstelle sollte in der Lage sein, vor einem Vorfall mehrere Fragen zu beantworten. Kann sie nachweisen, dass die Ausstellungssysteme von gewöhnlichen Unternehmenskompromittierungen isoliert sind? Kann sie nicht autorisierte Zertifikatserstellung schnell erkennen? Kann sie eine vollständige Zertifikatsinventur erstellen? Kann sie in großem Maßstab widerrufen? Kann sie Root-Programme und Abonnenten sofort benachrichtigen? Kann sie Protokolle gegen Löschung durch Angreifer schützen? Kann sie nachweisen, dass regierungs- oder risikoreiche Zwischenstellen separat geschützt sind?

Root-Programme sollten fragen, ob Vorfallsmeldungen zeitnah, spezifisch und unabhängig überprüfbar sind. Sie sollten genügend öffentliche Informationen verlangen, damit Domaininhaber und vertrauende Parteien handeln können. Sie sollten Notfall-Misstrauensmechanismen bereithalten, denn der Schutz der Nutzer kann nicht auf einen perfekten rechtlichen Nachweis warten.

Regierungsbehörden sollten Zertifikatsinventuren und Notfall-Ersatzpläne unterhalten. Sie sollten wissen, welche öffentlichen Dienste von welcher CA abhängen, welche alternative CA Ersatzzertifikate ausstellen kann, welche DNS-Validierungsschritte erforderlich sind und welche Behörde die Befugnis hat, Änderungen während einer Krise voranzutreiben. Sie sollten nutzerseitige Nachrichten testen, die einen Vertrauensbruch erklären, ohne zu unsicherem Klickverhalten zu ermutigen.

Domaininhaber sollten die Zertifikatsausstellung für ihre Domains über CT-Protokolle und verwandte Dienste überwachen. Sie sollten nicht davon ausgehen, dass keine Nachrichten bedeuten, dass keine Fehlausstellung vorliegt. Die Aufzeichnung von DigiNotar zeigt, wie ein gefälschtes Zertifikat außerhalb der CA und außerhalb des normalen Betriebs des betroffenen Domaininhabers entdeckt werden kann.

Schadenskontrolle beginnt in der ersten Vorfallstunde

Die erste Stunde eines CA-Vorfalls dient nicht nur der Eindämmung. Sie dient der Entscheidung, wer sonst noch eindämmen können muss. Die Verzögerung von DigiNotar zeigt, warum. Wenn die CA den Vorfall innerhalb ihrer eigenen Mauern behält, bis sie alles versteht, mag sie sich Optionen bewahren, verweigert aber Browsern, Betriebssystemen, Domaininhabern, Regierungen und Nutzern die Optionen. Diese nachgelagerten Akteure verfügen möglicherweise über die einzigen Kontrollen, die vertrauende Parteien in großem Maßstab schützen können.

Ein moderner CA-Vorfallsplan sollte daher zwei Spuren enthalten. Die forensische Spur bewahrt Beweise, identifiziert die Bewegungen des Angreifers, listet Zertifikate auf und bestimmt die Exposition von Wurzeln oder Zwischenstellen. Die Ökosystemspur benachrichtigt Root-Programme, Abonnenten, betroffene Domaininhaber, Browseranbieter, Regulierungsbehörden und öffentliche Dienstpartner mit eingegrenzten Fakten. Die Ökosystemspur sollte nicht auf perfekte forensische Klärung warten. Sie sollte mitteilen, was bekannt ist, was vermutet wird, was widerrufen wurde, was noch nicht ausgeschlossen werden kann und wann das nächste Update erfolgt.

Für Regierungsdienste erfordert die Schadenskontrolle auch Migrationsbefugnis. Wenn eine CA das Vertrauen verliert, muss jemand den Zertifikatsaustausch über Behörden hinweg anordnen, neue Zertifikate validieren, DNS- oder ACME-Änderungen koordinieren, die Dokumentation aktualisieren, die Bürger benachrichtigen und die Wiederherstellung der Dienste messen können. Eine Zertifikatsinventur des öffentlichen Sektors, die nur aus verstreuten Tabellen besteht, reicht nicht aus. Die Notfall-Migration muss geprobt werden, da das Misstrauen gegenüber der Wurzel normale Beschaffungs- und Änderungsfenster auf Stunden oder Tage komprimiert.

Die Aufzeichnung von DigiNotar ist daher eine Warnung vor der Latenz von Beweisen. Je länger es dauert, die betroffene Zertifikatsmenge zu kennen, desto länger müssen Browser zwischen Vertrauen und breitem Misstrauen wählen. Je länger es dauert, die Regierungsbetreiber zu benachrichtigen, desto weniger Zeit haben sie für eine elegante Migration. Je länger Nutzer ohne Updates bleiben, desto wahrscheinlicher ist es, dass sie einer ungültigen Zusicherung weiter vertrauen. Die operative Schadenskontrolle beginnt, wenn die CA dem Ökosystem genug mitteilt, um handeln zu können.

Das Regierungsdienstproblem war die Migration unter Misstrauen

Das schwierigste operative Problem in der Aufzeichnung von DigiNotar war nicht einfach die Entscheidung, dass das Vertrauen gescheitert war. Es war die Migration legitimer Dienste von einem Vertrauensanker nach dieser Entscheidung. Regierungsdienste können öffentliche Zertifikate normalerweise nicht improvisieren. Sie benötigen Validierung, Bereitstellungsfenster, Tests, DNS- oder ACME-Schritte, die Genehmigung des Diensteigentümers, Nutzeranleitungen und eine Möglichkeit zu überprüfen, ob alte Zertifikate nicht mehr benötigt werden.

Wenn eine CA das Vertrauen verliert, werden diese normalen Schritte durch die Sicherheitsdringlichkeit komprimiert.

Diese Kompression erzeugt zwei Risiken. Eine zu langsame Migration setzt Nutzer weiterhin gefälschten Zertifikaten oder der Unsicherheit aus, ob ein Dienst authentisch ist. Eine zu schnelle Migration kann den öffentlichen Zugang unterbrechen, insbesondere bei Systemen mit anfälligen Clients, fest codierten Zwischenstellen, gepinnten Zertifikaten oder von Lieferanten verwalteten Endpunkten.

Der rechenschaftspflichtige Regierungsabnehmer sollte daher vor einer Krise wissen, welche Behörden welche CA verwenden, welche alternativen Anbieter Ersatzzertifikate ausstellen können, welche Validierungsdatensätze bereit sind und welche technischen Eigentümer Änderungen bereitstellen können. DigiNotar zeigt, dass eine Zertifikatsinventur kein bürokratischer Vermögenswert ist. Es ist ein Kontinuitätsvermögenswert.

Das Problem der öffentlichen Kommunikation ist ebenso wichtig. Wenn Bürger Zertifikatswarnungen auf Regierungsseiten während einer CA-Krise sehen, müssen die Verantwortlichen zwei schlechte Botschaften vermeiden. Die erste schlechte Botschaft lautet: Ignorieren Sie die Warnung. Das lehrt unsicheres Verhalten. Die zweite lautet: Nutzen Sie digitale Dienste auf unbestimmte Zeit nicht mehr. Das kann gesetzliche Pflichten, Leistungen, Genehmigungen und wesentliche Kommunikation unterbrechen.

Eine reife Reaktion teilt den Bürgern mit, welche offiziellen Domains betroffen sind, wann der Ersatz erwartet wird, welche Kanäle sicher bleiben und wie man Updates überprüft.

Hier wird DigiNotar zu einem Governance-Fall und nicht nur zu einem Fall der CA-Sicherheit. Ein privater CA-Fehler zwang die öffentlichen Behörden, den Vertrauensentzug für öffentliche Dienste zu verwalten. Der Staat musste eine Sicherheitsentscheidung des Root-Programms in bürgerliche Kontinuität umwandeln. Diese Umwandlung sollte für jeden kritischen digitalen öffentlichen Dienst im Voraus geplant werden.

Audit reicht nicht aus, wenn die Vorfallsbeweise verspätet sind

Zertifizierungsstellen werden seit langem mit Audits, Richtlinien und Compliance-Artefakten in Verbindung gebracht. Diese Artefakte sind wichtig, aber DigiNotar zeigt ihre Grenzen während einer aktiven Kompromittierung. Ein Audit kann eine Kontrollumgebung zu einem bestimmten Zeitpunkt beschreiben. Ein Vorfall erfordert Beweise darüber, was passiert ist, was ausgestellt wurde, was widerrufen wurde, welche Systeme betroffen waren, welchen Protokollen vertraut werden kann und wer benachrichtigt wurde. Wenn diese Beweise verspätet oder unvollständig sind, können die vertrauenden Parteien nicht auf den nächsten Auditzyklus warten.

Die Vorfallsbeweise einer CA sollten als eine lebendige öffentliche Sicherheitsfunktion behandelt werden. Die wichtigsten Fakten sind nicht nur intern: betroffene Zertifikatsnamen und Seriennummern, Ausstellungszeit, Widerrufszeit, vermuteter Umfang, Exposition von Wurzeln oder Zwischenstellen, aufbewahrte Protokolle, kontaktierte Abonnenten, benachrichtigte Root-Programme und empfohlene Client-Maßnahmen. Einige sensible Details können vertraulich bleiben, aber die Handlungsfakten müssen schnell übermittelt werden.

Die Kritik von Mozilla an der verzögerten Benachrichtigung ist aussagekräftig, weil sie ein Versagen der Beweisweiterleitung identifiziert, nicht nur ein Versagen der technischen Verteidigung.

Die moderne öffentliche PKI verfügt über mehr Mechanismen dafür als 2011. Certificate-Transparency-Protokolle können ausgestellte Zertifikate offenlegen. CCADB und Root-Programm-Richtlinien können Vorfallmeldungen strukturieren. Browseranbieter können Misstrauensentscheidungen koordinieren. Die Anforderungen des CA/B Forums können Erwartungen definieren. Aber Mechanismen helfen nicht, wenn eine CA zögert, sie zu nutzen. Die Governance-Lektion von DigiNotar lautet, dass Vertrauen vom Verhalten während eines Fehlers abhängt und nicht nur von erfolgreichen jährlichen Papieren.

Für Kunden und Regierungen bedeutet dies, dass die Sorgfaltspflicht ausdrücklich nach Vorfallsbeweisen fragen sollte. Wie schnell wird die CA die Root-Programme benachrichtigen? Wie werden Domaininhaber auf verdächtige Ausstellungen aufmerksam gemacht? Wie vollständig sind die Protokolle? Was passiert, wenn die CA den Umfang nicht nachweisen kann? Welcher öffentliche Bericht wird verfügbar sein? Ein Anbieter, der diese Fragen nicht beantworten kann, ist nicht bereit, das öffentliche Vertrauen für kritische Dienste zu tragen.

DigiNotar erklärt, warum Misstrauen gegenüber der Wurzel die am wenigsten schlechte Option sein kann

Das Misstrauen gegenüber der Wurzel ist disruptiv, daher besteht immer Druck, es zu vermeiden. Websites können ausfallen. Regierungsportale können versagen. Alte Clients können den Zugang verlieren. Unternehmen können schwere wirtschaftliche Folgen erleiden. Der Konkurs von DigiNotar zeigt, dass Misstrauen kommerziell tödlich sein kann. Diese Kosten sind real und sollten nicht einfach abgetan werden.

Dennoch kann die Alternative schlimmer sein. Wenn eine CA nicht nachweisen kann, welche Zertifikate betrügerisch ausgestellt wurden, bedeutet fortgesetztes Vertrauen, dass jeder vertrauende Nutzer einer unbekannten Menge möglicher Identitätsdiebstähle ausgesetzt bleibt. Der Browseranbieter wird dann dafür verantwortlich, die Nutzer mit unvollständigen Beweisen zu schützen. In dieser Situation kann Misstrauen die am wenigsten schlechte Option sein, weil es nach dem Fail-Closed-Prinzip funktioniert. Es priorisiert den Nutzerschutz vor der Kontinuität einer Vertrauensbeziehung, die nicht mehr verifiziert werden kann.

Deshalb ist die operative Rechenschaftspflicht der CA strenger als die gewöhnliche Lieferantenverantwortlichkeit. Ein normaler SaaS-Ausfall kann durch Warten auf die Wiederherstellung gemildert werden. Ein Vertrauensverlust der CA kann das Ökosystem dazu zwingen, dem Anbieter nicht mehr zu vertrauen, bevor der Anbieter die Untersuchung abgeschlossen hat. Die Unfähigkeit der CA, Sicherheit nachzuweisen, wird zum Beweis gegen fortgesetztes Vertrauen. Das ist ein harter Standard, aber er ergibt sich aus dem Privileg der CA: Sie kann für fremde Domains Behauptungen aufstellen, die Browser global akzeptieren.

Die Lektion für die Kontinuität des öffentlichen Sektors lautet, dass Notfall-Misstrauen in die Planung einbezogen werden muss. Eine Regierung kann nicht davon ausgehen, dass jede vertrauenswürdige Wurzel vertrauenswürdig bleibt. Sie sollte wissen, wie sie Zertifikate in großem Maßstab ersetzen, wie sie ein Misstrauensereignis kommunizieren und wie sie den Dienstzugang bewahren kann, ohne die Nutzersicherheit zu schwächen. DigiNotar machte diese Notwendigkeit sichtbar.

Die Nutzersicherheitslinse sollte die Behebung leiten

Eine CA-Kompromittierung kann leicht zu einem Streit zwischen Institutionen werden: der CA, ihrer Muttergesellschaft, den Prüfern, den Browseranbietern, den Regierungen und den Regulierungsbehörden. Die Nutzersicherheitslinse hält die Argumentation bodenständig. Was braucht der Nutzer, um vor Identitätsdiebstahl geschützt zu sein? Was braucht der Bürger, um einen legitimen öffentlichen Dienst zu erreichen? Was muss der Domaininhaber wissen, ob sein Name missbraucht wurde? Was braucht der Browseranbieter, um ein sicheres Update auszuliefern? Was braucht die Regierung, um zu migrieren, ohne den Leuten zu sagen, sie sollen Warnungen ignorieren?

Wenn diese Fragen die Behebung leiten, wird die Verantwortungskarte klarer. DigiNotar musste Beweise liefern und die unsichere Ausstellung stoppen. Browseranbieter mussten das Vertrauen entziehen, wo die Beweise nicht ausreichten. Regierungsbetreiber mussten migrieren und kommunizieren. Domaininhaber mussten überwachen und reagieren. Nutzer mussten Updates erhalten, sollten aber nicht gebeten werden, das PKI-Problem selbst zu lösen.

Diese Nutzersicherheitslinse begrenzt auch Überbeanspruchung. Sie erfordert nicht den Beweis, dass jedes gefälschte Zertifikat ausgenutzt wurde, bevor Maßnahmen ergriffen werden. Sie erfordert nicht, jeder vertrauenden Partei die Schuld zu geben, einer Wurzel vertraut zu haben, die vom Ökosystem vertrauenswürdig eingestuft wurde. Sie erfordert nicht, so zu tun, als ob Notfall-Misstrauen schmerzlos sei. Sie fragt, welche Maßnahme den Schaden für diejenigen am besten begrenzt, die die Interna der CA nicht einsehen können.

Der bleibende Wert von DigiNotar liegt darin, dass es die verborgene CA-Governance in sichtbare öffentliche Sicherheit verwandelt. Die Kompromittierung machte deutlich, dass das Vertrauensgewebe des Webs nur so stark ist wie sein schwächster vertrauenswürdiger Aussteller und nur so rechenschaftspflichtig wie sein schnellster ehrlicher Beweis. Das bleibt ein relevanter Standard für jede öffentlich vertrauenswürdige CA.

Die Kontinuitätsplanung muss die Verteilung von Vertrauensspeicher-Updates umfassen

DigiNotar offenbart auch ein Verteilungsproblem, das leicht unterschätzt wird. Browser- und Betriebssystemhersteller können schnell entscheiden, einer CA nicht mehr zu vertrauen, aber der Schutz erreicht die Nutzer erst, wenn Software-Updates eintreffen, verwaltete Unternehmen sie genehmigen, alte Geräte sie erhalten und Anwendungen den aktualisierten Speicher tatsächlich nutzen. Einige Clients verwenden möglicherweise private Bundles oder Appliances, die dem Betriebssystem nicht folgen. Andere befinden sich möglicherweise hinter Unternehmensproxys, die das Verhalten der Zertifikatsüberprüfung ändern.

Eine Root-Programm-Entscheidung ist daher ein Beginn des Schutzes, nicht das Ende.

Für Regierungsdienste bedeutet das, dass die Kontinuitätsplanung beide Seiten der Migration verfolgen muss. Der öffentliche Dienst muss seine eigenen verdächtigen Zertifikate ersetzen, aber er muss auch verstehen, ob Bürger und öffentliche Angestellte das Misstrauens-Update erhalten haben, das sie vor Nachahmung schützt. Ein Callcenter muss möglicherweise erklären, warum ein Browser-Update wichtig ist. Ein Systemadministrator muss möglicherweise überprüfen, ob verwaltete Desktops, Kioske und mobile Geräte über aktuelle Stammspeicher verfügen. Ein Sicherheitsteam muss möglicherweise überwachen, ob noch Verkehr die misstraute Kette akzeptiert.

Dieses Verteilungsproblem ist ein weiterer Grund, warum die Verzögerung der Benachrichtigung so schwerwiegend ist. Jeder verlorene Tag, bevor Browseranbieter und Regierungen genug erfahren, um zu handeln, wird zu einem Tag, der einer bereits langsamen Verteilungskette hinzugefügt wird. Die CA kann ein Zertifikat nach der Entdeckung schnell widerrufen, aber der praktische Nutzerschutz hängt immer noch von den nachgelagerten Aktualisierungspfaden ab.

Die Aufzeichnung von DigiNotar zeigt, dass der Betriebsschaden nur dann begrenzt wird, wenn Beweise, Misstrauensentscheidungen, Zertifikatsersetzungen und die Verteilung von Client-Updates die vertrauende Bevölkerung erreichen.

Dieselbe Verteilungskette sollte vor einer Krise getestet werden. Ein Ministerium, ein Krankenhausnetzwerk, eine Bank oder ein Gerichtssystem, das auf öffentliches TLS angewiesen ist, sollte wissen, ob die verwalteten Desktops den Betriebssystemspeicher, einen Browserspeicher, einen Proxyspeicher, ein Java-Bundle, ein Mobile-Device-Management-Profil oder ein Appliance-Trust-Bundle verwenden. Es sollte wissen, wer jeden Speicher wie schnell aktualisieren kann. Es sollte auch wissen, welche öffentlich zugänglichen Dienste Zertifikate ohne Ausfallzeit ersetzen können.

DigiNotar war bedeutsam, weil es diese stillen Inventarfragen in dringende Kontinuitätsfragen verwandelte. Die Organisation, die sie beantworten kann, bevor das Misstrauen eintritt, hat die Chance, Nutzer zu schützen, ohne ihnen beizubringen, Warnungen zu umgehen.

Der Beweisstandard sollte ähnlich konkret sein. Ein öffentlicher Dienst sollte nicht nur behaupten, dass Zertifikate ersetzt wurden; er sollte eine Liste der betroffenen Endpunkte, Ersetzungszeiten, Nutzerhinweise, Anbieterkontakte und Client-Populationen aufbewahren, die sich möglicherweise noch auf veraltetes Vertrauen stützen. Diese Aufzeichnung hilft späteren Prüfern, unvermeidbaren Übergangsschmerz von vermeidbarer Verzögerung zu trennen. Sie schützt auch die Öffentlichkeit vor einer falschen Wahl zwischen Zugang und Sicherheit. Das Ziel ist es nicht, einen gescheiterten Vertrauensanker der Bequemlichkeit halber am Leben zu erhalten.

Das Ziel ist es, legitime Dienste schnell genug zu migrieren, damit das Misstrauen die Nutzer schützen kann, ohne sie im Stich zu lassen.

Das Fazit für die Rechenschaftspflicht

Das Versagen von DigiNotar veränderte die praktische Bedeutung des CA-Vertrauens. Es zeigte, dass die internen Kontrollen einer Zertifizierungsstelle zu einem globalen Problem der Nutzersicherheit werden können; dass eine verzögerte Benachrichtigung so folgenschwer sein kann wie der ursprüngliche Eindringling; dass die PKI-Abhängigkeiten der Regierung ein Risiko für die öffentliche Kontinuität darstellen; und dass Browseranbieter unter Umständen zu Notfall-Misstrauen greifen müssen, wenn eine CA den Umfang nicht nachweisen kann.

Der rechenschaftspflichtige Standard ist nicht Perfektion gegen jeden Angreifer. Es ist der Nachweis. Eine öffentliche CA muss nachweisen, dass die Ausstellungsautorität geschützt ist, dass Protokolle und Inventuren Missbrauch aufdecken können, dass Vorfälle schnell offengelegt werden, dass Widerruf und Migration betrieblich möglich sind und dass das Vertrauen des Root-Programms kontinuierlich verdient wird. Wenn sie dies nicht kann, ist der Schaden nicht mehr auf die Kundenliste der CA beschränkt.

DigiNotar ist daher nicht nur eine historische Warnung. Es ist eine Kontrollkarte für jede Organisation, die auf die öffentliche Web-PKI angewiesen ist. Vertrauen wird delegiert, aber Schaden wird lokal von Nutzern, Behörden, Banken, Krankenhäusern, Gerichten, Schulen und Unternehmen erfahren. Die Partei, die die Vertrauensmaschinerie kontrolliert, kontrolliert die erste Chance, diesen Schaden zu begrenzen.