Gegevens via internet veilig uitwisselen met het Resource Public Key Infrastructure protocol
Pakketten op internet kunnen door fouten of aanvallen op een dwaalspoor raken. De mechanismen van een weinig bekende public-key-infrastructuur RPKI bieden daar bescherming tegen.
Lees verder na de advertentie
Meer dan HTTPS: beveiliging van internetroutes
Public-key-infrastructuren zorgen voor de beveiliging van het internet. Je kent waarschijnlijk wel de Web-PKI – al is het niet per se onder die naam – met die kleine slotjes in de browser. Die geven aan dat je gegarandeerd op het aangegeven domein zit en dat het dataverkeer versleuteld is.
Maar het internet is meer dan alleen het web en aanvallers hebben ook andere manieren om de HTTP-verbinding met een webservice aan te vallen. Om überhaupt verbinding te kunnen maken, moeten de browser en de server gegevenspakketjes uitwisselen. Over de route die deze pakketjes nemen, kan de Web-PKI net zo min iets zeggen als dat garandeert kan worden dat de pakketjes überhaupt aankomen.
Tip
Download het e-book en krijg direct inzicht in de stappen die jouw organisatie moet zetten.
En dat is juist heel belangrijk: een fout waardoor gegevens in de vergetelheid verdwijnen, schakelt een gebruiker of dienst in feite uit, en aanvallers die de gegevensstroom via zichzelf leiden, kunnen iets uit de metadata afleiden – zelfs als de eigenlijke inhoud via Web-PKI versleuteld is.
Tegen dergelijke aanvallen moet een veel minder bekende variant van de Web-PKI bescherming bieden: de Resource Public Key Infrastructure (RPKI). Die vormt de basis voor verschillende mechanismen die de routebepaling van pakketten op internet moeten beveiligen. Het belang en de verspreiding van de RPKI groeien al jaren gestaag, maar grotendeels onopgemerkt.
Routing uit andere tijden
Welke route een datapakket neemt, wordt op internet (hét netwerk der netwerken) dynamisch geregeld. Subnetten die deel uitmaken van internet (Autonomous Systems, AS) communiceren via het Border Gateway Protocol (BGP) en leren zo wie welke IP-adressen in het eigen netwerk heeft, wie ze via andere netwerken kunnen bereiken en hoe direct of indirect die verbinding is.
Zo worden datapakketten van AS naar AS doorgestuurd totdat ze hun bestemming bereiken. Veranderingen in de netwerkstructuur worden continu via BGP uitgewisseld, bijvoorbeeld als er een nieuwe verbinding bijkomt of een AS offline gaat. Het resultaat is een netwerk dat uiterst veerkrachtig is tegen externe invloeden en opmerkelijk goed kan omgaan met voortdurend veranderende verbindingsmogelijkheden en zelfs grote rampen: updates via BGP maken duidelijk wie er nog waar verbinding mee heeft, waaruit nieuwe routes ontstaan waarnaar datapakketten automatisch doorgestuurd worden.
Interne issues zijn lastiger
Het netwerk reageert echter aanzienlijk slechter op interne problemen. BGP heeft geen autorisatiemechanisme, waardoor ook verkeerd aangekondigde routes overgenomen worden. Die gaan de concurrentie aan met de tegelijkertijd aangekondigde echte routes en dan, afhankelijk van de aard van de vermeende route, maken datapakketten mogelijk onnodige omwegen of komen ze helemaal niet meer op hun bestemming aan.
Dan kan zijn omdat de vermeende route niet bestaat of omdat een klein AS in het zogenaamd gunstigste pad het begeeft onder de belasting of als grote delen van het netwerkverkeer via de verkeerd aangekondigde route moeten stromen. Dergelijke route-leaks hoeven niet per se kwaadwillig te zijn. Heel vaak zijn ze gewoon het gevolg van configuratiefouten.
De Resource Public Key Infrastructure (RPI) moet aanvallen en fouten in die route-aankondigingen voorkomen. Dat is, net als bij de web-PKI, een hiërarchische structuur van certificeringsinstanties. Die weerspiegelt de hiërarchie van internetproviders en Local Internet Registries (LIR’s), evenals de wereldwijd verspreide vijf Regional Internet Registries (RIR’s), en legt vast wie welke IP-adressen beheert.
In repository’s slaan de betrokkenen hun certificaten, intrekkingslijsten en ondertekende objecten op. Een groot aantal RFC-standaarden regelt hoe al die gegevensstructuren eruitzien, waar ze te vinden zijn en hoe ze met elkaar gesynchroniseerd worden (zie het kader), zodat idealiter alle betrokkenen altijd op de hoogte zijn van de actuele stand van zaken.
Routing zonder dalen
Als je de relaties tussen klanten en providers weergeeft als stijgende flanken, dan zouden routes op het internet valley free moeten zijn, dus zonder dalen, zoals links in de afbeelding. Je kunt van het ene Autonome Systeem (AS) naar het andere gaan door van provider naar provider omhoog te gaan, dan eventueel een peering-verbinding op gelijke hoogte te gebruiken en vervolgens af te dalen naar de providers van de bestemming. De route in de rechtergrafiek laat daarentegen een ongewenste daling zien.
De ‘ondertekende objecten’ in de RPKI zijn net zo algemeen als de term klinkt: in principe kun je de RPKI gebruiken om willekeurige gegevens met een RPKI-certificaat te authenticeren.
In de praktijk zijn verschillende routeringsstandaarden en ook sommige andere ideeën gebaseerd op de RPKI, maar het oorspronkelijke en belangrijkste nut van de RPKI zijn Route Origin Authorizations (ROA’s).
Route Origin Authorizations
De in RFC 9582 gespecificeerde ROA’s zijn ondertekende objecten die aantonen dat een AS de bron mag zijn van routes voor de IP-adressen die in de ROA genoemd worden. Idealiter zou bijvoorbeeld een internetprovider elke keer dat hij een route voor een IP-blok aankondigt, ook een bijbehorende ROA in de RPKI opslaan.
De ROA valideert de herkomst van de route op een voor iedereen controleerbare manier. De RPKI bepaalt namelijk wie de betreffende IP-adressen beheert, en alleen die instantie kan de ROA met haar privésleutel ondertekenen. Als een AS ten onrechte beweert de oorsprong van een IP-adresblok te zijn, wat een fout of een BGP-hijacking-aanval kan zijn, dan kan er geen geldige ROA voor die route-aankondiging bestaan.
Maar als de echte provider ROA’s gebruikt, is zo’n verificatie voor de route die hij aankondigt er wel. Dan volgen de datapakketten de juiste route, ook al lijkt de andere, niet-geverifieerde route voordeliger. ROA’s zijn daarom een goed middel om de gevolgen van route-aankondigingen met een verkeerd opgegeven oorsprong op te vangen.
Er blijven echter nog andere mazen in het net voor fouten en voor aanvallers. Die kunnen bijvoorbeeld routes aankondigen die zogenaamd naar het juiste AS leiden, maar het verkeer omleiden in het voordeel van de aanvaller. Als die routes een smaller adresbereik aankondigen dan de echte routes van het juiste AS, krijgen ze voorrang boven de juiste informatie.
ROA’s bieden hier alleen bescherming tegen als ze het specifiekere doeladresbereik van de verkeerde route niet dekken. Maar dat is precies wat ze vaak doen vanwege een twijfelachtige functie van ROA’s: ze hebben een attribuut genaamd maxlength, dat je zo kunt instellen dat ze ook specifiekere routes dekken dan die in de ROA staan vermeld.
Synchronisatieproblemen
Bij de RPKI gaat het in feite om bestanden die via URI’s toegankelijk zijn. Het is echter niet eenvoudig om die gegevens bij alle betrokkenen altijd up-to-date te houden. Het oorspronkelijke plan in RFC 6481 voorziet erin om de gegevens met elkaar te synchroniseren via de bekende tool rsync. Maar rsync is niet goed schaalbaar met de kleine, maar enorm talrijke bestanden waaruit de RPKI bestaat.
De server moet dan voor elke overdracht relatief veel moeite doen, wat niet goed uitpakt voor een systeem met vrij weinig servers en veel clients. Enkele jaren later werd daarom het RPKI Repository Delta Protocol (RRDP) gespecificeerd in RFC 8182. Dat verbetert de prestaties, maar is ook niet ideaal. Het zorgt er namelijk voor dat er relatief veel gegevens worden uitgewisseld die clients nog wel niet kennen, maar die al verouderd en dus eigenlijk irrelevant zijn.
Er wordt al gewerkt aan een verdere verbetering, die de overhead moet voorkomen door slim gebruik te maken van hash-trees. De specificatie voor dit Erik Synchronization Protocol (zie de link, net als voor alle overige specificaties) is echter nog niet afgerond en al helemaal niet als RFC.
Als een AS een ROA instelt met zo’n maxlength-regeling, maar niet voor alle specifiekere doeladresruimtes die daardoor worden gedekt zelf routes aankondigt, ontstaat er een gat waar aanvallers misbruik van kunnen maken. Ze kondigen dan een route aan die via de aanvaller naar het echte doel-AS leidt en een specifieker adresbereik noemt dan alle echte routes, maar dat nog steeds onder de maxlength-regel van de echte ROA valt.
Vervolgens stroomt er data richting de aanvaller, omdat diens route zogenaamd naar het juiste AS leidt, overeenkomt met een ROA en specifieker is dan de echte routes. AS-beheerders stellen dergelijke ROA’s in met een flexibele maxlength omdat ze soms heel dynamisch nieuwe routes willen aankondigen, bijvoorbeeld bij een DoS-aanval.
Om dat af te weren, moeten er mogelijk sneller nieuwe routes worden ingesteld dan dat bijbehorende ROA’s zich via de RPKI kunnen verspreiden, want dat duurt een paar minuten.
ROA’s die via maxlength ruimte creëren voor toekomstige gedetailleerde routes, lossen dat probleem op en creëren tegelijkertijd het beschreven aanvalsoppervlak.
Een uitweg bieden Autonomous System Provider Authorizations (ASPA’s), een andere gegevensstructuur in de RPKI. Daarin kunnen AS’en op een fraudebestendige manier vastleggen welke andere AS’en voor hen als directe upstream fungeren, dus wie hun verbindingen verzorgt.
Routes die valley-free zijn en uitsluitend bestaan uit door ASPA’s beveiligde koppelingen, maken aanvallen zoals hierboven beschreven aanzienlijk moeilijker.
Aanvallers kunnen niet zomaar willekeurige valse routes aankondigen, maar moeten plausibele routes bedenken die overeenkomen met de ASPA-informatie en er vervolgens ook baat bij hebben om pakketten via zo’n route te versturen.
Toch bieden ASPA’s, zelfs in combinatie met ROA’s, geen absolute bescherming. Ze kunnen routes plausibel of inplausibel laten lijken, maar bieden geen garantie dat een vermeende route ook daadwerkelijk door alle daarin genoemde autonome systemen wordt aangekondigd.
Stap voor stap
Het idee om BGP-routes volledig cryptografisch te authenticeren bestaat al: BGPsec (RFC 8205) definieert een nieuw, met een handtekening beveiligd veld voor routes in het Border Gateway Protocol en valideert de handtekeningen via RPKI. Het is een heel zinvolle aanvulling op ROA’s en ASPAs, maar BGPsec komt al jaren niet echt van de grond.
Toen het protocol bijna tien jaar geleden gespecificeerd werd, stelde het hardware-eisen die veel routers problemen bezorgden. Inmiddels is de hardware meestal krachtig genoeg, maar het ondersteunen van BGPsec blijft een flinke implementatie-inspanning vergen, die pas op de middellange termijn loont en die tot nu toe vrijwel niemand wil doen. De eenvoudigere ROA’s en ASPAs waren daarentegen relatief makkelijk te implementeren en hebben daarom in de praktijk een flinke voorsprong.
Het aantal routes dat via ROA’s wordt beveiligd, stijgt inderdaad al geruime tijd rustig, maar ook opmerkelijk gestaag, en ligt inmiddels boven de 60 procent. ASPA’s zijn nog lang niet zo wijdverbreid. Het is echter ook een nieuwer concept en de specificaties zijn nog niet eens helemaal afgerond (zie de link). Toch ligt de verspreiding in bijvoorbeeld Europa op ruim drie procent, aldus de Regional Internet Registry RIPE NCC (Réseaux IP Européens Network Coordination Centre).
Bovendien ziet RIPE de laatste tijd een duidelijke stijging in de verspreiding van ASPA’s. RPKI-expert Job Snijders spreekt zelfs de hoop uit dat 2026 wel eens ‘het jaar van de ASPA’s’ zou kunnen worden.
Conclusie
De RPKI is een geheime superheld, zijn beveiligingsmechanismen zijn essentieel en verspreiden zich grotendeels onopgemerkt steeds verder. Uiteindelijk is het een compliment voor de RPKI dat hij zo onopvallend is – kritieke systemen vallen immers vaak pas op als ze niet goed werken.
Op dit moment zijn de mechanismen van de RPKI nog niet overal ingebouwd en sluiten ze ook niet absoluut alle denkbare aanvallen uit. Maar ze beperken de speelruimte van aanvallers steeds verder.
Het voorkomen van onbedoelde route-leaks en verkeerde herkomstgegevens is op zich al een winst, maar ook belangrijk voor de veiligheid, zoals Job Snijders uitlegt: vroeger waren er door verkeerde configuraties zoveel verkeerde routes dat aanvallen in al die ruis soms niet eens opvielen.
Een internet dat dankzij ROA’s en ASPA’s foutloos geconfigureerd is, maakt kwaadwillige ingrepen beter zichtbaar.
Links
The Erik Synchronization Protocol
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-erik-protocol/
Tip
Download het e-book en krijg direct inzicht in de stappen die jouw organisatie moet zetten.
Praat mee