Das Fundament des Internets ist erstaunlich ungeschützt. Das Border Gateway Protocol (BGP) entscheidet, über welche Netze Datenpakete fließen, vertraut Routing-Ansagen aber bis heute weitgehend blind. RPKI (Resource Public Key Infrastructure) soll genau das mit kryptografischen Signaturen korrigieren. Doch im Juni 2026 zeigt eine neue Forschungsarbeit, dass auch der Schutzschild selbst Risse hat: 55 Publikationspunkte des RPKI-Systems sind angreifbar, und deutsche Sicherheitsforscher hatten zuvor bereits 18 Schwachstellen in der zentralen Validator-Software dokumentiert.
Die Zahlen markieren einen heiklen Moment. RPKI deckt inzwischen rund 58 Prozent der per BGP angekündigten IPv4-Präfixe ab, aber nur 28,9 Prozent der autonomen Systeme filtern aktiv ungültige Routen. Dieser Beitrag ordnet die aktuelle Lage ein: Was bei der Routing-Sicherheit gerade passiert, warum die Lücken für den DACH-Raum relevant sind, was deutsche Forschungseinrichtungen wie ATHENE beitragen und wohin sich das Feld bis 2028 bewegt.
RPKI-Sicherheit 2026: Das ist gerade passiert
Mitte Juni 2026 rückte die Sicherheit der Routing-Infrastruktur wieder in den Fokus der DACH-Fachmedien. Eine auf dem Network and Distributed System Security Symposium (NDSS 2026) vorgestellte Arbeit untersuchte nicht die bekannten Hijacking-Angriffe auf BGP, sondern die darunterliegende Infrastruktur von RPKI selbst. Das Ergebnis: 55 sogenannte Publication Points, also die Server-Repositories, aus denen Netzbetreiber die signierten Routing-Freigaben laden, weisen ausnutzbare Schwachstellen auf.
Der größte Anteil hat eine überraschend banale Ursache. Bei 44 dieser 55 Publication Points fehlt eine ROA-Registrierung für die Nameserver der zuständigen Top-Level-Domains. Anders gesagt: Die kryptografische Kette, die das Routing absichern soll, hängt an DNS-Servern, deren eigene IP-Präfixe nicht durch RPKI geschützt sind. Fünf weitere Publication Points registrieren keine ROAs für die IP-Adressen ihrer eigenen Repository-Server. Von 60 Publication Points, die auf eine einzige IP-Adresse auflösen, sind vier ohne ROA-Schutz. Ein Angreifer, der genau diese Achillesfersen trifft, könnte die Auslieferung der Validierungsdaten manipulieren oder blockieren.
Diese Befunde reihen sich in eine längere Linie deutscher Forschung ein. Bereits 2024 hatte ein Team des Nationalen Forschungszentrums für angewandte Cybersicherheit ATHENE und des Fraunhofer-Instituts für Sichere Informationstechnologie (SIT) unter Leitung von Prof. Dr. Haya Schulmann 18 Schwachstellen in wichtigen Softwarekomponenten der RPKI offengelegt. Betroffen waren die verbreiteten Relying-Party-Programme, mit denen Provider die Gültigkeit von Routen prüfen. Die Botschaft beider Arbeiten ist dieselbe: Kryptografie schützt nur so gut wie ihre Implementierung und ihre Betriebsumgebung.
Was ist RPKI? Kryptografie für das BGP-Routing
RPKI ist eine spezialisierte Public-Key-Infrastruktur, definiert in RFC 6480. Sie verbindet Internet-Nummernressourcen, also IP-Adressblöcke und AS-Nummern, kryptografisch mit ihren rechtmäßigen Inhabern. Das Prinzip ähnelt dem von TLS-Zertifikaten im Web: Eine vertrauenswürdige Stelle signiert eine Aussage, die jeder Dritte verifizieren kann. Bei RPKI sind die Trust Anchors die fünf regionalen Internet-Registrare (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC).
Das zentrale Objekt heißt Route Origin Authorization (ROA). Eine ROA ist eine signierte Erklärung, die festlegt, welches autonome System einen bestimmten IP-Präfix ankündigen darf. Wer etwa den Block 212.219.0.0/16 hält, kann per ROA bestätigen, dass nur AS786 ihn originieren darf. Router oder vorgelagerte Validatoren vergleichen jede eingehende BGP-Ansage gegen diese signierten Daten und stufen sie als valid, invalid oder not-found ein. Ungültige Routen lassen sich dann verwerfen.
Wichtig ist die Grenze des Verfahrens. RPKI prüft die Origin Validation, also ob das ankündigende AS überhaupt berechtigt ist. Es sichert nicht den gesamten AS-Pfad ab. Manipulationen, die einen plausiblen, aber gefälschten Weg vortäuschen, bleiben außerhalb der Reichweite. RPKI ist damit eine notwendige, aber keine hinreichende Antwort auf die strukturelle Vertrauensschwäche von BGP. Wer tiefer in asymmetrische Verfahren und digitale Signaturen einsteigen will, findet die Grundlagen in unserem Beitrag zu ECDSA-Signaturen in Node.js.
BGP-Hijacking: Wie Angreifer Datenströme umleiten
BGP wurde Ende der 1980er Jahre entworfen, als das Internet eine Gemeinschaft kooperierender Netze war. Vertrauen war eingebaut, Authentifizierung nicht. Ein autonomes System kann grundsätzlich jeden Präfix ankündigen, und Nachbarn übernehmen diese Ansage oft ungeprüft. Beim Präfix-Hijacking nutzt ein Angreifer das aus, indem er einen fremden IP-Block für sich beansprucht. Besonders wirksam ist die Ankündigung eines spezifischeren Präfixes: Router bevorzugen nach dem Longest-Prefix-Match-Prinzip stets die genauere Route.
Die Folgen reichen von Zensur über Spionage bis zu direktem Diebstahl. Datenströme lassen sich abfangen, mitlesen oder auf gefälschte Server umleiten. Gerade im Finanz- und Kryptosektor sind solche Umleitungen lukrativ, weil sie kurzzeitig den Datenverkehr zu Wallet- oder Börsen-Diensten kapern. Routenlecks dagegen entstehen meist versehentlich, etwa wenn ein Provider intern gedachte Routen nach außen weitergibt und so ganze Dienste lahmlegt.
RPKI mit aktivierter Route Origin Validation (ROV) entschärft die häufigste Variante, das Origin-Hijacking. Sobald ein Netzbetreiber ungültige Routen verwirft, kann ein gefälschter Origin keine breite Wirkung mehr entfalten. Genau deshalb ist die Lückenanalyse von 2024 und 2026 brisant: Wenn die Validierungssoftware oder die Repository-Infrastruktur selbst angreifbar ist, lässt sich der Schutz aushebeln oder per Denial-of-Service abschalten.
Die neuen Schwachstellen im Detail
Die NDSS-2026-Analyse verschiebt den Blick von der Software auf die Betriebsinfrastruktur. RPKI funktioniert nur, wenn Validatoren rund um die Uhr aktuelle Daten aus den Publication Points beziehen. Diese Repositories sind über das Domain Name System erreichbar, und genau hier setzen die Forscher an. Wenn die Nameserver-Präfixe einer Top-Level-Domain nicht selbst durch ROAs geschützt sind, kann ein Angreifer per DNS- oder BGP-Manipulation die Auslieferung der Validierungsdaten stören.
Die Konsequenz ist subtiler als ein klassischer Hijack. Ein Validator, der keine frischen ROAs mehr erhält, kann in einen unsicheren Zustand fallen. Je nach Konfiguration behandelt er veraltete oder fehlende Daten als not-found und akzeptiert dann Routen, die er eigentlich hätte ablehnen müssen. Aus einem Verfügbarkeitsproblem wird so ein Sicherheitsproblem. Die zentrale Kennzahl der Studie, 44 von 55 verwundbaren Publication Points wegen fehlender ROA-Registrierung für gTLD-Nameserver, zeigt, dass es sich nicht um Einzelfälle handelt, sondern um eine systematische Lücke im Betriebsmodell.
Für Betreiber heißt das: Die kryptografische Stärke der Signaturen ist nicht das Problem. Schwach sind die Annahmen über die Erreichbarkeit und Integrität der Datenquellen. Dieselbe Erkenntnis prägt die Diskussion um andere PKI-Systeme, etwa bei Zertifikaten im Web. Wie eine saubere Zertifikatskette aufgebaut wird, zeigt unser Leitfaden zu Let’s Encrypt-Zertifikaten.
Routinator, rpki-client und Co: Die verwundbare Validator-Software
Die Prüfung der Routing-Daten läuft nicht auf dem Router selbst, sondern auf separaten Relying-Party-Programmen, oft Validatoren genannt. Sie laden die signierten Objekte aus den Repositories, verifizieren die kryptografische Kette und stellen das Ergebnis per RPKI-to-Router-Protokoll (RTR) den Routern bereit. Genau diese Software stand im Zentrum der ATHENE-Untersuchung von 2024, die 18 Schwachstellen in den gängigen Implementierungen dokumentierte.
Das ist sicherheitskritisch, weil ein einziger erfolgreicher Angriff auf einen Validator die Routing-Entscheidungen vieler nachgelagerter Router beeinflusst. Fällt der Validator durch einen Denial-of-Service aus oder lässt er sich zu Fehlurteilen verleiten, ist der gesamte RPKI-Schutz dahinter wertlos. Der Markt der Relying-Party-Software ist überschaubar, was die Lage zusätzlich zuspitzt: Wenige Programme tragen einen großen Teil der globalen Validierung.
| Validator | Entwickler | Sprache | Herkunft |
|---|---|---|---|
| Routinator | NLnet Labs | Rust | Niederlande |
| rpki-client | OpenBSD-Projekt | C | USA/global |
| FORT | NIC.MX / LACNIC | C | Lateinamerika |
| OctoRPKI | Cloudflare | Go | USA |
| RTRTR | NLnet Labs | Rust | Niederlande |
Auffällig ist die Sprachwahl. Zwei der fünf Kernprogramme setzen auf Rust, das speichersichere Fehlerklassen weitgehend ausschließt. Andere basieren auf C, wo klassische Bugs wie Pufferüberläufe oder Path-Traversal-Fehler grundsätzlich möglich bleiben. Die ATHENE-Forscher argumentieren seit Jahren, dass eine größere Diversität und ein byzantinisch-resilientes Design der Validierung die Abhängigkeit von einzelnen verwundbaren Implementierungen verringern würde.
RPKI-Verbreitung in Zahlen
Trotz aller Schwachstellen ist RPKI eine Erfolgsgeschichte mit Tempo. 2020 waren laut Cloudflare nur rund 25 Prozent der Routen signiert und 20 Prozent der Netze führten Origin Validation durch. Heute liegt die globale ROA-Abdeckung der angekündigten IPv4-Präfixe bei etwa 58 bis 61 Prozent, je nach Messmethode, und bei IPv6 sogar bei rund 63 Prozent. Die folgende Tabelle zeigt die regionale Verteilung der gültigen IPv4-Präfixe.
| Region / RIR | Gültige IPv4-Präfixe (ROA) | Veränderung seit Feb. 2025 |
|---|---|---|
| RIPE NCC (Europa, DACH) | 74,1 % | +2 % |
| LACNIC (Lateinamerika) | 66,6 % | +5 % |
| Global | 60,9 % | +6 % |
| AFRINIC (Afrika) | 56,6 % | +18 % |
| APNIC (Asien-Pazifik) | 55,5 % | +3 % |
| ARIN (Nordamerika) | 52,5 % | +10 % |
Europa führt das Feld klar an: Mit 74,1 Prozent gültiger IPv4-Präfixe liegt die RIPE-NCC-Region, zu der auch Deutschland, Österreich und die Schweiz zählen, deutlich über dem globalen Schnitt. Die Validierung hinkt der Signierung allerdings hinterher. Nur 28,9 Prozent der autonomen Systeme filterten im Juli 2025 ungültige Routen aktiv heraus. Cloudflare schätzt, dass rund 261 Millionen Nutzer hinter 686 AS mit nahezu vollständiger ROV-Abdeckung wirksam geschützt sind. Im globalen RPKI-System existieren laut Cloudflare 393.344 IPv4- und 86.306 IPv6-ROAs, verteilt auf die Trust Anchors APNIC (28 Prozent), ARIN (27 Prozent) und RIPE (36 Prozent).
Historischer Kontext: Die großen BGP-Hijacks
Warum überhaupt der Aufwand? Weil ungesichertes Routing eine lange Geschichte teurer Pannen und Angriffe hat. Der Klassiker ereignete sich am 24. Februar 2008: Pakistan Telecom (AS17557) begann um 18:47 UTC, den Präfix 208.65.153.0/24 anzukündigen, um YouTube landesweit zu sperren. Der Upstream-Provider PCCW Global (AS3491) reichte die Ansage ungefiltert an das restliche Internet weiter. Weil 208.65.153.0/24 spezifischer war als YouTubes eigener Block 208.65.152.0/22, zogen Router weltweit die gefälschte Route vor. Schätzungen zufolge sah mehr als zwei Drittel des Internets die Fehlroute. Erst um 21:01 UTC, nach gut zwei Stunden, war der Spuk vorbei.
Der YouTube-Vorfall war kein Einzelfall, sondern ein Muster. Schon 1997 hatte das berüchtigte AS-7007-Ereignis, ausgelöst durch einen kleinen Provider in Florida, weite Teile des Sprint-Netzes vom Internet getrennt. Akademische Quellen beschreiben, dass es historisch ein bis zwei schwere Vorfälle dieser Art pro Jahr gab. Mit der zunehmenden Kommerzialisierung kam die kriminelle Motivation hinzu.
| Jahr | Vorfall | Auswirkung | Ursache |
|---|---|---|---|
| 1997 | AS-7007-Vorfall (Florida-ISP) | Großteil des Sprint-Netzes offline | Routenleck |
| 2008 | Pakistan Telecom / YouTube | YouTube ~2 Std. global gestört | Präfix-Hijack (/24) |
| 2018 | MyEtherWallet / Amazon Route 53 | rund 152.000 $ Krypto entwendet (laut Berichten) | Umleitung via BGP/DNS |
| 2022 | KLAYswap (Südkorea) | Krypto-Diebstahl bei Börsendienst | BGP-Hijack |
| 2024 | Orange España / RIPE-Konto | stundenlange Routing-Störung | Kontoübernahme |
Die Kryptobranche ist besonders exponiert. 2018 leiteten Angreifer über eine BGP-Manipulation, die Amazons Route-53-DNS betraf, den Verkehr von MyEtherWallet um und entwendeten Berichten zufolge Kryptowährung im Wert von rund 152.000 US-Dollar. 2024 zeigte die Übernahme des RIPE-NCC-Kontos von Orange España, dass auch Verwaltungszugänge eine kritische Angriffsfläche sind. Genau hier setzt RPKI an, indem es die ungültige Route signaturbasiert erkennbar macht.
Markt- und Wirtschaftsfolgen für den DACH-Raum
Für Deutschland, Österreich und die Schweiz ist Routing-Sicherheit kein akademisches Nischenthema. Die RIPE-Region führt mit 74,1 Prozent ROA-Abdeckung, doch die Validierung bleibt lückenhaft. Jeder große Carrier, jeder Internetknoten und jeder Cloud-Anbieter, der ungültige Routen nicht filtert, lässt ein Einfallstor offen. Der DE-CIX in Frankfurt zählt zu den größten Internetknoten der Welt, was die DACH-Region zu einem strategisch wichtigen Knotenpunkt macht.
Die wirtschaftliche Dimension ergibt sich aus der Abhängigkeit. Finanzdienstleister, Industrie 4.0, vernetzte Lieferketten und der gesamte E-Commerce hängen an verlässlichem Routing. Ein erfolgreicher Hijack gegen einen Zahlungsdienstleister oder eine Bank kann binnen Minuten Schäden verursachen und das Vertrauen langfristig beschädigen. Die Investitionen in RPKI-Validatoren und ROV sind dagegen vergleichsweise gering, was den Schutz zu einem der günstigsten Sicherheitsgewinne im Netzbetrieb macht.
Gleichzeitig verschärft sich der regulatorische Druck. Mit der NIS2-Richtlinie und ihrer deutschen Umsetzung rücken Risikomanagement und technische Schutzmaßnahmen für tausende Unternehmen in den Pflichtbereich. Routing-Sicherheit ist dabei ein naheliegender Baustein. Wer die Pflichtenlage einordnen will, findet die Details in unserer Analyse zur NIS2-Umsetzung in Deutschland und zum Cyber Resilience Act.
Stimmen aus der Forschung
Die deutsche Cybersicherheitsforschung spielt bei RPKI eine sichtbare Rolle. ATHENE in Darmstadt gilt als eines der größten Forschungszentren für angewandte Cybersicherheit in Europa und treibt die kritische Analyse der Routing-Infrastruktur voran.
“RPKI ist kryptografisch solide, aber Sicherheit entsteht erst in der Implementierung und im Betrieb. Genau dort finden wir immer wieder Schwachstellen, die den gesamten Schutz aushebeln können.”
Prof. Dr. Haya Schulmann, Goethe-Universität Frankfurt und ATHENE
Schulmanns Team hat mehrfach gezeigt, dass die Relying-Party-Software die verwundbarste Stelle der Kette ist. Auch Michael Waidner, der ATHENE leitet und an der TU Darmstadt sowie am Fraunhofer SIT forscht, verweist auf die strukturelle Dimension.
“Wir müssen die Resilienz der Validierung erhöhen, statt uns auf einzelne Programme zu verlassen. Eine fehlertolerante, diverse Architektur ist der nächste logische Schritt für die Internet-Sicherheit.”
Prof. Dr. Michael Waidner, Direktor ATHENE und Fraunhofer SIT
Aus Sicht der Netzbetreiber argumentiert das Routing-Sicherheitsteam von Cloudflare, das mit OctoRPKI selbst einen Validator entwickelt und früh begann, ungültige Routen zu verwerfen.
“BGP wird sicherer, lange bevor RPKI flächendeckend ausgerollt ist. Sobald die verbleibenden Transitprovider Origin Validation aktivieren, schafft es ein Hijack kaum noch auf die Titelseiten.”
Cloudflare, Routing-Sicherheitsteam
Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) rahmt das Thema breiter. BSI-Präsidentin Claudia Plattner betont, dass grundlegende Maßnahmen der IT-Sicherheit für mehr Unternehmen verbindlich werden und dass das Ziel eine geschützte Wirtschaft sei. Routing-Sicherheit fügt sich in diese Linie ein, auch wenn RPKI im behördlichen Diskurs bislang weniger prominent ist als Themen wie Verschlüsselung oder Meldepflichten.
Was Deutschland, die EU und die USA unternehmen
Die Regulierung holt langsam auf. In den USA hat das Weiße Haus RPKI in seiner Roadmap als ausgereifte Lösung für BGP-Schwachstellen empfohlen. Die US-Regierung strebt an, 60 Prozent des angekündigten IP-Raums unter eine ARIN-Vereinbarung zu bringen und damit ROAs für föderale Netze zu ermöglichen. Die Telekom-Aufsicht FCC schlug zudem jährliche Risikomanagement-Pläne zur BGP-Sicherheit für Internetdienstanbieter vor.
In Europa ist der Ansatz dezentraler, aber konkret. Die niederländische Forum Standaardisatie verlangte bereits Ende 2024 ein “Comply or Explain” für alle staatlichen Stellen, das sowohl ROAs als auch ROV umfasst. Große Betreiber wie NTT, AT&T und Cloudflare verwerfen ungültige Routen seit Jahren auf Basis ihrer RPKI-Gültigkeit. Im DACH-Raum treiben Internetknoten und Carrier die Validierung schrittweise voran, getragen von der hohen ROA-Abdeckung der RIPE-Region.
Der regulatorische Hebel über NIS2 ist offensichtlich. Sobald Risikomanagement gesetzlich vorgeschrieben ist, wird die Frage nach Routing-Sicherheit unausweichlich. Es wäre überraschend, wenn ROV nicht mittelfristig als anerkannte Mindestmaßnahme für Betreiber kritischer Infrastruktur eingestuft würde. Bis dahin bleibt die Umsetzung freiwillig, getrieben von Branchen-Best-Practices wie MANRS und dem Eigeninteresse der Betreiber.
Validatoren im Wettbewerb: Welche Software führt?
Der Markt der RPKI-Validatoren ist klein, aber technisch ausdifferenziert. Routinator von NLnet Labs gilt als verbreiteter Standard und setzt konsequent auf Rust, um speicherbezogene Fehlerklassen auszuschließen. rpki-client aus dem OpenBSD-Projekt punktet mit minimalistischem, gehärtetem C-Code und einer disziplinierten Sicherheitskultur. FORT wird von NIC.MX und LACNIC gepflegt und ist in Lateinamerika stark vertreten.
Cloudflares OctoRPKI in Go und das ebenfalls von NLnet Labs stammende RTRTR runden das Feld ab, wobei RTRTR weniger ein Validator als ein Verteiler validierter Daten ist. Die ATHENE-Forschung von 2024 traf alle gängigen Implementierungen quer durch die Sprachen, was zeigt: Speichersicherheit allein genügt nicht, wenn Logikfehler oder fehlerhafte Annahmen über die Datenquellen bestehen bleiben.
Für Betreiber ergibt sich daraus eine pragmatische Empfehlung: mehrere Validatoren parallel betreiben, regelmäßig patchen und die Erreichbarkeit der Publication Points überwachen. Diese Diversität ist genau das, was die deutschen Forscher als byzantinisch-resilientes Design beschreiben. Wer Post-Quantum-Aspekte mitdenkt, sollte zudem beobachten, wie sich die Signaturverfahren entwickeln. Einen Einstieg bietet unser Beitrag zu ML-KEM (Kyber) in Node.js.
Was Netzbetreiber jetzt tun sollten
Die konkreten Schritte sind klar und überschaubar. Erstens: ROAs für alle eigenen Präfixe erstellen, damit fremde Ankündigungen als ungültig erkennbar werden. Zweitens: Route Origin Validation aktivieren und ungültige Routen tatsächlich verwerfen, nicht nur markieren. Drittens: die Validierungssoftware aktuell halten und idealerweise mehr als eine Implementierung einsetzen, um die Abhängigkeit von einer einzigen Codebasis zu verringern.
Viertens, und das ist die Lehre aus den 2026er Befunden: die Betriebsinfrastruktur überwachen. Wenn ein Validator keine frischen ROAs mehr erhält, muss das alarmieren, statt stillschweigend in den not-found-Zustand zu kippen. Fünftens gehört Routing-Sicherheit in die Risikoanalyse nach NIS2, sodass sie nicht als optionales Extra, sondern als Teil der Sorgfaltspflicht behandelt wird.
Der wirtschaftliche Charme dieser Maßnahmen liegt im Verhältnis von Kosten zu Nutzen. RPKI ist kostenlos nutzbar, die Validatoren sind quelloffen, und der Betriebsaufwand ist im Vergleich zu vielen anderen Sicherheitsprojekten gering. Wer die Lage in Deutschland breiter einordnen möchte, findet aktuelle Bedrohungsdaten im BSI-Lagebericht.
Fünf Prognosen für die Routing-Sicherheit bis 2028
1. Die globale ROA-Abdeckung übersteigt 2027 die 70-Prozent-Marke. Bei den aktuellen Zuwächsen, in Afrika zuletzt plus 18 Prozent binnen eines Jahres, ist das ein realistisches Szenario. Europa könnte sich der 80-Prozent-Schwelle nähern.
2. ROV wird zur regulatorischen Mindestmaßnahme. Über NIS2 und vergleichbare Rahmenwerke dürfte die Validierung für Betreiber kritischer Infrastruktur faktisch verpflichtend werden, auch ohne dass RPKI namentlich im Gesetzestext steht.
3. Angriffe verlagern sich vom Origin- zum Pfad-Hijacking. Je besser Origin Validation greift, desto attraktiver werden Manipulationen des AS-Pfads. Verfahren wie ASPA (Autonomous System Provider Authorization) rücken in den Fokus.
4. Validator-Diversität wird zum Designprinzip. Die Forderung der ATHENE-Forscher nach byzantinisch-resilienter Validierung dürfte in Best-Practice-Empfehlungen einfließen. Betreiber setzen zunehmend mehrere Implementierungen parallel ein.
5. Die Infrastruktur der Publication Points wird gehärtet. Als direkte Reaktion auf die 2026er Befunde ist zu erwarten, dass Registrare und TLD-Betreiber ROAs für ihre eigenen Nameserver-Präfixe nachziehen und so die größte gefundene Lücke schließen.
Häufige Fragen zu RPKI und BGP-Sicherheit
Was bedeutet RPKI?
RPKI steht für Resource Public Key Infrastructure. Es ist eine kryptografische Infrastruktur, die IP-Adressblöcke und AS-Nummern signiert mit ihren rechtmäßigen Inhabern verknüpft, um das BGP-Routing gegen Hijacking abzusichern.
Verhindert RPKI alle BGP-Angriffe?
Nein. RPKI sichert die Origin Validation, also ob ein AS einen Präfix überhaupt ankündigen darf. Manipulationen des AS-Pfads bleiben außerhalb der Reichweite. Dafür sind ergänzende Verfahren wie ASPA in Entwicklung.
Wie hoch ist die RPKI-Abdeckung in Europa?
In der RIPE-NCC-Region, zu der der gesamte DACH-Raum gehört, sind rund 74,1 Prozent der angekündigten IPv4-Präfixe durch gültige ROAs gedeckt. Das ist der höchste Wert aller Weltregionen.
Was sind die neuen Schwachstellen von 2026?
Eine NDSS-2026-Arbeit identifizierte 55 verwundbare Publication Points. Bei 44 davon fehlt eine ROA-Registrierung für die Nameserver der zuständigen Top-Level-Domains, was die Auslieferung der Validierungsdaten angreifbar macht.
Welche Rolle spielt die deutsche Forschung?
Das Forschungszentrum ATHENE und das Fraunhofer SIT, unter anderem mit Prof. Dr. Haya Schulmann und Prof. Dr. Michael Waidner, gehören zu den führenden Analysten der RPKI-Sicherheit. 2024 legten sie 18 Schwachstellen in der Validator-Software offen.
Was sollten Unternehmen jetzt konkret tun?
ROAs für alle eigenen Präfixe anlegen, ROV aktivieren und ungültige Routen verwerfen, die Validatoren aktuell halten, möglichst mehrere Implementierungen parallel betreiben und die Erreichbarkeit der Publication Points überwachen. Im DACH-Raum gehört das zudem in die NIS2-Risikoanalyse.
Related Coverage
- ECDSA in Node.js: Signaturen in 11 Schritten
- Let’s Encrypt: Zertifikat in 12 Schritten
- ML-KEM (Kyber) in Node.js: 12 Schritte
- NIS2 Deutschland: 29.500 Firmen, 10 Mio € Strafe
- Cyber Resilience Act: 90 Tage bis zur Meldepflicht
- BSI Lagebericht: 280.000 Schadprogramme pro Tag
- GPG Verschlüsselung: 12 Schritte mit GnuPG
