Validatorenvielfalt kann einen einzelnen Vertrauensanker nicht beheben

Zusammenfassung

• Die globale RPKI ist nicht buchstäblich auf einem einzigen universellen Vertrauensanker aufgebaut. Die Nutzerseite-Software verwendet üblicherweise TALs für AFRINIC, APNIC, ARIN, LACNIC und das RIPE NCC. Aber der gültige Zertifizierungspfad für eine bestimmte Ressource endet normalerweise bei einer einzigen akzeptierten Autorität, sodass die Ausführung mehrerer Validatoren nicht mehrere unabhängige Aussteller für diese Ressource schafft.
• Die Vielfalt der Validatoren ist wertvoll. Unabhängige Codebasen können unterschiedliche Analysefehler, Speichersicherheitslücken, Transportverhalten, Caching-Strategien und Veröffentlichungszyklen aufweisen. Getrennte Instanzen verringern auch die Wahrscheinlichkeit, dass ein Prozessausfall oder ein Wartungsereignis den gesamten für ein Netzwerk verfügbaren validierten Strom entfernt.
• Jeder konforme Validator bewertet signierte Objekte stets im Rahmen der Autorität, die durch seine konfigurierten Vertrauensanker bereitgestellt wird. Wenn eine akzeptierte übergeordnete Zertifizierungsstelle ein untergeordnetes Zertifikat widerruft, Ressourcen daraus entfernt oder eine konkurrierende Kette ausgibt, sollen die Validatoren den resultierenden kryptografischen Zustand anerkennen, anstatt über die Berechtigung der Handlung des übergeordneten Zertifikats abzustimmen.
• Die Vielfalt der Repositories und des Transports kann die Verfügbarkeit verbessern, aber Spiegel können keine Autorität erzeugen. Ein perfekt repliziertes widriges Zertifikat oder eine perfekt replizierte Sperrung bleibt widrig, während eine unsignierte Korrektur von einem unabhängigen Spiegel kein gültiger Ersatz ist.
• Mehrheitsabstimmung unter den Validatorausgaben ist keine institutionelle Abhilfe. Zwei veraltete Caches können einen aktuellen Cache überstimmen; zwei Implementierungen können eine Bibliothek oder Interpretation gemeinsam nutzen; und eine echte Autoritätsänderung kann zunächst als Uneinigkeit erscheinen. Betreiber benötigen Belege, die jeden Unterschied erklären, nicht nur eine einfache Zählung.
• Die Resilienz des Vertrauensankers liegt in der Autoritätsschicht: geschützte Schlüsselverwahrung, gemeinsame Genehmigung, öffentliche Übergangspläne, Vorbereitung des Nachfolgeschlüssels, unabhängige Beobachtung, abgegrenzte Zertifikatsänderungen, begründete Entscheidungen, Rechtsbehelfe und Kontinuitätsvorkehrungen. RFC 9691 macht geplante Vertrauensankerschlüsselübergänge sicherer, schützt aber nicht ausdrücklich vor der Kompromittierung des aktuellen privaten Vertrauensankerschlüssels.
• Lokale Ausnahmen wie SLURM können die Autonomie eines Betreibers während einer widrigen Handlung bewahren, aber sie sind lokal und können die Validierungsansichten fragmentieren. Sie sind eine Notfallkontrolle, keine globale Ersatzautorität oder automatische Abhilfe für angefochtene Registerentscheidungen.
• Eine Gesellschaft für Nummernressourcen kann die Konzentration der Autorität rechenschaftspflichtiger machen, indem sie Vertrauensankerbelege, Schlüsselzeremoniennachweise, Änderungsmitteilungen, Anfechtungsverfahren und Validatorvergleichsberichte standardisiert. Sie sollte unabhängige Software ergänzen, anstatt Softwarevielfalt als Beweis dafür zu vermarkten, dass die Macht des Registers dezentralisiert wurde.

Die Vielfalt beginnt, nachdem die erste Entscheidung bereits getroffen wurde

Ein RPKI-Validator entdeckt Autorität nicht, indem er BGP inspiziert und die Institution auswählt, die er für überzeugend hält. Er beginnt mit dem vom Betreiber konfigurierten Vertrauensankermaterial. Ein Vertrauensankerlokalisierer liefert Standorte und einen öffentlichen Schlüssel, der verwendet wird, um ein selbstsigniertes Zertifikat einer Zertifizierungsstelle abzurufen und zu authentifizieren. Von diesem akzeptierten Ausgangspunkt aus folgt der Validator Zertifikatspfaden, überprüft Ressourcenerweiterungen, Manifeste, Sperrlisten und signierte Objekte und leitet daraus validierte Nutzlasten ab.

Zwei Validatoren, die in unterschiedlichen Sprachen geschrieben sind, können diese Arbeit unabhängig ausführen. Einer könnte eine fehlerhaft codierte Eingabe ablehnen, die ein anderer inkorrekt verarbeitet. Einer könnte sich von einer Repository-Unterbrechung erholen, während ein anderer abstürzt. Einer könnte ein abgelaufenes Manifest klar anzeigen, während ein anderer einen weniger nützlichen Fehler produziert. Diese Unterschiede sind wichtig, weil der Repository-Inhalt eine unzuverlässige Eingabe ist und die Validierungsoberfläche komplex ist.

Aber die Validatoren entscheiden nicht unabhängig, wer der ultimative Aussteller ist. Wenn beide mit demselben öffentlichen TAL-Schlüssel konfiguriert sind, akzeptieren beide denselben Vertrauensanker als Startautorität für die in seinem Zertifikat beschriebenen Ressourcen. Sie können sich über die syntaktische oder kryptografische Gültigkeit eines abgeleiteten Objekts uneinig sein. Wenn sie sich über die Eingaben und Standards einig sind, sollten sie nicht einfach deshalb abweichen, weil einer den Inhaber und der andere die übergeordnete Zertifizierungsstelle bevorzugt.

Die institutionelle Konzentration liegt daher vorgelagert zur Implementierung. Ein Validator kann beweisen, dass ein Objekt gemäß festgelegten Regeln von der akzeptierten Wurzel abstammt. Er kann nicht beweisen, dass die Governance der Wurzel fair ist, dass eine erzwungene Sperrung verhältnismäßig ist oder dass die Registrierung des Inhabers durch das Register alle privaten rechtlichen Interessen widerspiegelt. Die kryptografische Validierung beantwortet eine engere Frage.

Deshalb kann ein Beschaffungsplan, der drei Validierungsprodukte erwirbt, die Dezentralisierung überschätzen. Er schafft drei Computerzeugen einer einzigen konfigurierten Autorität. Das ist eine nützliche Resilienz, aber es sind nicht drei unabhängige Quellen der Zertifizierungsmacht.

Fünf regionale Anker geben nicht jedem Präfix fünf unabhängige Stimmen

Die Produktionssoftware der Nutzerseite enthält normalerweise Vertrauensankerlokalisierer für die fünf regionalen Internetregister: AFRINIC, APNIC, ARIN, LACNIC und das RIPE NCC. RFC 8897 gibt an, dass jeder Nutzer seine Vertrauensanker auswählt und IANA und die fünf RIR als offensichtliche Standardkandidaten identifiziert, der Hierarchie der Nummernressourcenzuweisung entsprechen. Die Documentation von Routinator und FORT zeigt die TALs der fünf RIR in der üblichen Konfiguration.

Diese Struktur ist verteilter als eine einzige globale Wurzel, die von einer einzelnen Organisation betrieben wird. Ein auf einen regionalen Baum beschränkter Ausfall macht nicht unbedingt Ressourcen ungültig, die ausschließlich unter einem anderen zertifiziert sind. Auch regionale Gemeinschaften, Verträge und Governance unterscheiden sich. Jede Analyse, die behauptet, dass die gesamte RPKI nur einen einzigen buchstäblichen Vertrauensanker hat, wäre falsch.

Die Konzentration tritt wieder auf, wenn die Analyseeinheit eine Ressource wird. Ein Präfix liegt normalerweise in einem Zertifizierungspfad, der von dem Vertrauensanker absteigt, der seine Zuweisung abdeckt. Sein Inhaber kann nicht drei nicht verwandte RIR-Wurzeln bitten, drei Zertifikate mit gleicher Autorität auszustellen, nur weil der Betreiber drei Validatoren ausführt. Während eines legitimen Interregio-Transfers können die Pfade kurzzeitig wechseln oder sich überschneiden, aber das ist eine kontrollierte Ausnahme und keine routinemäßige Multi-Root-Abstimmung.

Die Softwarevielfalt operiert daher horizontal auf der Nutzerseite, während die Zertifizierungsautorität vertikal organisiert ist. Mehrere Validatoren können beispielsweise den APNIC-Baum durchlaufen, aber sie verwandeln die APNIC-Wurzelentscheidung nicht in fünf regionale Entscheidungen. Wenn eine Ressource in eine andere Region wechselt, ändert sich der Autoritätspfad durch die Übertragungsbestimmungen; die Anzahl der Validatoren ist nicht die Ursache der Verschiebung.

Diese Unterscheidung ermöglicht eine genauere Risikoaussage. Das globale System weist eine regionale Trennung auf. Innerhalb des aktiven Pfades für eine Ressource kann eine übergeordnete Autorität jedoch jedes abhängige untergeordnete Objekt beeinflussen. Ein Zertifikatswiderruf der Zertifizierungsstelle kann dazu führen, dass Nutzer untergeordnete signierte Objekte für ungültig erklären. Unabhängige Validatoren können dieses Ergebnis mit bewundernswerter Konsistenz bestätigen. Ihre Übereinstimmung demonstriert dann eine konzentrierte Autorität, die wie vorgesehen funktioniert, und keine verteilte Autorität.

Softwarevielfalt ist eine echte Kontrolle und sollte nicht herabgesetzt werden

Das Argument gegen Übertreibung ist kein Argument für Monokultur. RPKI-Nutzer verarbeiten Zertifikate, Sperrlisten, Manifeste, ROAs und andere signierte Objekte, die von vielen Veröffentlichungspunkten abgerufen werden. Sie handhaben ASN.1, kryptografische Signaturen, URI-Entdeckung, RRDP, rsync, Cache-Zustand, Objektablauf und außergewöhnliche Veröffentlichungsbedingungen. Ein Fehler kann die Ausgabe beschädigen, Ressourcen verbrauchen oder validierte Daten für Router unverfügbar machen.

Unabhängige Implementierungen reduzieren gemeinsame Softwareausfälle, wenn ihre Unabhängigkeit echt ist. rpki-client wird im OpenBSD-Ökosystem entwickelt und legt Wort auf eine kleine Codebasis, Privilegientrennung und eingeschränkten Prozesszugriff. Routinator ist eine Rust-Implementierung mit eigenem Abruf-, Speicher- und Validierungsdesign. FORT ist ein weiterer Open-Source-Nutzer mit unterschiedlichen Betriebskontrollen. Ihr Code, ihre Veröffentlichungspfade und ihre Sicherheitsannahmen sind nicht identisch.

Das Ökosystem hat bereits gezeigt, dass sich das Softwaremanagement weiterentwickelt. Im Jahr 2021 beendete das RIPE NCC den Support für seinen Validator und riet den Betreibern, zu Alternativen zu migrieren, anstatt nicht gewarteten Code weiterzuverwenden. Diese Entscheidung schwächte die RPKI-Autorität nicht; sie erkannte an, dass Nutzerseite-Software von einem unabhängigen Ökosystem bereitgestellt werden kann und sollte.

Netzwerke ziehen mehrere Schutzmaßnahmen aus der Verwendung von mehr als einer gewarteten Implementierung. Eine kritische Analyse-Schwachstelle muss nicht alle Ströme entfernen. Ein Repository-Grenzfall kann verglichen werden. Eine neue Standardfunktion kann getestet werden, bevor sie zur einzigen Produktionsquelle wird. Wartung kann durchgeführt werden, ohne blind zu operieren. Unterschiedliche Telemetrie kann einen Fehler aufdecken, den eine Schnittstelle verbirgt.

Diese Vorteile rechtfertigen den technischen Aufwand. Der Fehler besteht darin, sie als Beweis für einen anderen Vorschlag zu verwenden: dass die Zertifizierungs- und Registrierungsautorität dezentralisiert wurde. Eine Brandschutztür diversifiziert nicht den Eigentümer des Gebäudes. Sie macht das Gebäude sicherer gegenüber einer Kategorie von Ausfällen. Die Validatorenvielfalt sollte mit ebenso präzisen Begriffen verteidigt werden.

Die gemeinsame Vertrauenseingabe definiert die Grenze des unabhängigen Urteils

RFC 8630 macht die Vertrauensentscheidung ungewöhnlich sichtbar. Ein TAL enthält einen oder mehrere Standorte und Informationen zum öffentlichen Schlüssel. Der Nutzer ruft ein selbstsigniertes Zertifizierungsstellenzertifikat ab, überprüft, ob sein öffentlicher Schlüssel übereinstimmt, und entscheidet, ob er bereit ist, diese Entität als Vertrauensanker für die im Zertifikat beschriebenen Ressourcen zu akzeptieren. Einmal akzeptiert, ist der Anker nicht einfach eine weitere Datenquelle. Er ist die Grundlage, auf der abgeleitete Beglaubigungen gültig werden.

Die RFC gibt auch die Schwere einer Kompromittierung an. Ein Angreifer mit dem privaten Schlüssel des Vertrauensankers kann die Autorität fälschen. Das Vertrauen in einen unangemessenen oder falschen Anker kann ebenso schwerwiegende Folgen haben. Der Aussteller kann den Ressourcensatz seines Zertifikats ändern, ohne den TAL-Schlüssel neu zu verteilen, eine notwendige Flexibilität, da sich regionale Ressourcenzuweisungen ändern. Dieses Design bedeutet, dass der Nutzer der Zurückhaltung des Ausstellers erhebliches Vertrauen schenkt.

Mehrere Validatoren, die denselben TAL verwenden, treffen keine unterschiedlichen Vertrauensentscheidungen, es sei denn, ihre Betreiber konfigurieren sie bewusst anders. Gebündelte TALs können die Wahl nahezu unsichtbar machen: Die Installation erzeugt eine nützliche Standardkonfiguration, und jede Implementierung beginnt mit denselben regionalen Schlüsseln. Die Bequemlichkeit ist für die Einführung wünschenswert, sollte aber nicht mit einer unabhängig ausgehandelten Vertrauensbeziehung verwechselt werden.

Das Abrufen des Vertrauensankerzertifikats von mehreren URLs schafft auch keine mehreren Autoritäten. RFC 8630 erlaubt mehrere Standorte, um den Abruf zu verbessern. Jeder Standort wird anhand desselben öffentlichen Schlüssels überprüft. Ein Spiegel kann das Zertifikat verfügbar halten; er kann keinen anderen Autoritätszustand ohne den vertrauenswürdigen privaten Schlüssel signieren.

Diese Grenze stellt Betreiber vor eine praktische Inventarfrage. Für jede Validatorinstanz: Welche TAL-Schlüssel sind konfiguriert, wie wurden sie bezogen, wer kann sie aktualisieren und welches Softwarepaket kann sie bei einem Upgrade ändern? Wenn drei Instanzen TAL-Änderungen über einen einzigen Paketkanal ohne Überwachung erhalten, beinhaltet ihre scheinbare Unabhängigkeit eine gemeinsame Bootstrap-Abhängigkeit. Die Codebasen können sich unterscheiden, während die Wurzelkonfiguration betrieblich konzentriert bleibt.