Afstudeeronderzoek: PQC voor de RPKI

Op zichzelf is BGP ontzettend onveilig: het vertrouwt erop dat elk AS eerlijk is over de adressen die het zegt te bezitten en de routes waarvan het zegt te hebben gehoord. Aanvallen zijn mogelijk wanneer een netwerk een ogenschijnlijk uitstekende route deelt naar een adres dat het niet bezit of waar het geen goed pad naartoe heeft. Dit zorgt ervoor dat andere netwerken verkeer omleiden naar het kwaadaardige of verkeerd geconfigureerde netwerk, waar het kan worden onderschept om te worden afgeluisterd of gemanipuleerd.

De Resource Public Key Infrastructure (RPKI) is uitgegroeid tot het voornaamste instrument om deze beveiligingsproblemen aan te pakken. De RPKI maakt echter gebruik van digitale handtekeningen waarvan de verwachting is dat ze uiteindelijk gekraakt zullen worden, wanneer er kwantumcomputers beschikbaar komen die daar krachtig genoeg voor zijn. Voordat het zover is, moet de RPKI worden aangepast om te gaan werken met post-kwantumhandtekeningen, die bestand zijn tegen zowel klassieke als kwantumcomputers. Mijn afstudeeronderzoek legt de basis voor zo'n migratie door te onderzoeken welke post-kwantumhandtekeningen kunnen worden gebruikt en hoe deze kunnen worden geïntroduceerd. Je vindt het volledige onderzoek op deze website.

Resource Public Key Infrastructure

De RPKI is een gedecentraliseerde database met behulp waarvan rechtmatige houders van internetresources (zoals IP-adressen) cryptografisch verifieerbare uitspraken kunnen doen over hoe de routering zou moeten plaatsvinden.

Het systeem wordt gebruikt als basis voor verschillende technieken die elk bepaalde aanvallen moeilijker of onmogelijk kunnen maken. De meest prominente techniek is Route Origin Validation (ROV). De rechtmatige houder van een IP-adres publiceert (verifieerbaar) welke AS'en het adres mogen origineren, in een Route Origin Authorization (ROA). Wanneer een netwerk BGP-paden voor een adres ontvangt, wordt er gezocht naar ROA's voor dat adres. Als het AS van bestemming geautoriseerd is door een ROA in de RPKI of als er helemaal geen informatie over het adres is, is het mogelijk dat het om een legitiem pad gaat. Zijn er echter ROA's voor het adres die het betreffende AS niet autoriseren, dan is het pad zeker niet legitiem en moet het worden verworpen. Deze methode heeft sinds de introductie ervan een gestaag groeiende adoptie doorgemaakt.

Daarnaast zijn er nog 2 aanvullende technieken:

• ASPA, een nieuwe techniek die de plausibiliteit van AS-paden controleert aan de hand van gepubliceerde informatie over klant-providerrelaties tussen AS'en.

• BGPsec, dat verifieert of een pad inderdaad door elk AS langs de route is geautoriseerd.

Op dit moment wordt alleen ROV op grote schaal toegepast en de adoptie van ASPA zal waarschijnlijk binnenkort op gang komen. BGPsec bestaat al lang, maar is nog nooit in de praktijk gebruikt. Deze 3 RPKI-gebaseerde beveiligingsmaatregelen vullen elkaar aan door elk een ander probleem aan te pakken.

Post-kwantumcryptografie

De RPKI maakt gebruik van RSA-handtekeningen. Deze 'klassieke' digitale handtekeningen zullen naar verwachting kwetsbaar zijn voor aanvallen met krachtige kwantumcomputers. Hoewel er op dit moment nog geen kwantumcomputers bestaan die klassieke cryptografie kunnen kraken, verloopt de ontwikkeling ervan snel. Het kan een paar jaar of meerdere decennia duren, maar het is de verwachting dat dergelijke computers uiteindelijk in staat zullen zijn om RSA en andere klassieke cryptografische algoritmen te kraken.

Dit heeft geleid tot de ontwikkeling van post-kwantumcryptografie (PQC), dat wil zeggen, cryptografie die erop gericht is bestand te zijn tegen zowel klassieke als kwantumcomputers. Er lopen onderzoeken naar hoe verschillende protocollen kunnen migreren naar PQC. Sommige kijken bijvoorbeeld naar TLS en SIDN Labs werkt aan DNSSEC. Voor de RPKI is dit soort onderzoek tot nu toe nog niet gedaan. Mijn afstudeeronderzoek heeft als doel die leemte op te vullen.

Hoe werkt de RPKI?

De RPKI bestaat uit een hiërarchie van certificeringsinstanties (Certificate Authorities of CA's) die allemaal resourcehouder zijn (houders van IP-adresblokken). CA's kunnen deze resources aan onderliggende CA's delegeren door het uitgeven van RPKI-certificaten. Elke CA kan vervolgens objecten aanmaken zoals Route Origin Authorizations (ROA's), die gepubliceerd worden in repository's.

Vertrouwende partijen (Relying Parties of RP's), die ook wel validators worden genoemd, downloaden periodiek alle certificaten en ROA's uit deze repository's. Vervolgens valideren ze de gedownloade certificaten en ROA's, wat resulteert in een geverifieerde lijst van IP-adressen en de AS'en waardoor ze mogen worden georigineerd. Daarna wordt deze lijst doorgestuurd naar daadwerkelijke BGP-routers, die de informatie gebruiken bij de routering.

Onderstaand een overzicht van de rollen binnen de RPKI:

Wat kan een kwantumaanvaller doen met BGP?

Een kwantumcomputer die RSA kan kraken, geeft een aanvaller 2 mogelijkheden:

• Handtekeningen vervalsen die in de RPKI wordt gebruikt, waaronder RPKI-certificaten en ROA's. Dit is een direct gevolg van het kraken van RSA.

• Objecten publiceren zodat validators deze zullen verwerken. Dit kan op verschillende manieren worden bewerkstelligd (zie het volledige onderzoek), bijvoorbeeld door een bericht van een onderliggende CA aan de bovenliggende CA te vervalsen om zich overtuigend voor te doen als de onderliggende CA.

Met deze mogelijkheden is een aanvaller niet alleen maar in staat om de ROV-beveiliging te omzeilen (door een ROA te vervalsen die zijn kwaadaardige route autoriseert). Hij kan ROV zelfs gebruiken als wapen en BGP-aanvallen effectiever maken dan ze zouden zijn zonder ROV.

Hier is hoe: in plaats van alleen een ROA te maken die zijn kwaadaardige route autoriseert (om ROV te omzeilen), kan de aanvaller ook legitieme ROA's intrekken. Daarmee worden legitieme routes aangemerkt als 'ROV-Invalid' en de route van de aanvaller als 'ROV-Valid' (in plaats van dat ze allebei 'ROV-Valid' worden). De kwaadaardige route wordt zo de enige beschikbare optie en hoeft niet te concurreren (bijvoorbeeld in lengte) met legitieme routes, wat de aanval effectiever maakt dan een klassieke BGP-aanval zonder ROV.

Dit creëert een gevaarlijke paradox: het gebruik van ROV met kwantumkwetsbare cryptografie kan BGP minder veilig maken dan wanneer er helemaal géén gebruik wordt gemaakt van ROV. Als de kwantumdreiging werkelijkheid wordt, zullen netwerkbeheerders in de praktijk geen andere keuze hebben dan Route Origin Validation volledig uit te schakelen en gaan we weer terug naar de oude, onbeveiligde BGP-routering. Het kwantumveilig maken van de RPKI is dus niet zomaar een leuke beveiligingsupgrade, maar een noodzakelijke maatregel om de RPKI in de toekomst levensvatbaar te houden.

Om de RPKI kwantumveilig te maken, moeten we de RSA-handtekeningen vervangen door een post-kwantum alternatief. Daarnaast speelt de beveiliging van andere protocollen, zoals TLS en DNSSEC, ook een rol. Het uitzoeken over welke beveiligingseigenschappen andere protocollen precies moeten beschikken en het updaten daarvan is een essentiële stap die niet over het hoofd mag worden gezien, maar die binnen dit afstudeeronderzoek niet aan de orde komt.

Op welke handtekeningen kunnen we overstappen?

Aangezien we hebben geconstateerd dat het nodig is om de RSA-handtekeningen te vervangen, moeten we nu een geschikte vervanging zien te vinden. Eerst zoeken we uit aan welke vereisten een vervangend handtekeningenschema moet voldoen. Daarna gaan we kijken welke kandidaten daaraan tegemoetkomen.

Waar moet een vervangend schema aan voldoen?

Vergeleken met RSA hebben post-kwantumalgoritmen meestal grotere sleutels en handtekeningen, en tragere ondertekenings- en verificatietijden (of in elk geval een of meer van die eigenschappen). Onze belangrijkste overwegingen zijn dus:

• dat een vervangend schema uiteraard veilig moet zijn, en

• dat het de performance van de RPKI als geheel zo min mogelijk mag beïnvloeden.

Beveiliging

NIST heeft 5 beveiligingsniveaus voor post-kwantumschema's ingesteld, waarbij niveau 1 even veilig is als AES-128 (128 bits beveiliging) en niveau 5 overeenkomt met AES-256. Het huidige RSA-2048 biedt slechts 112 bits beveiliging tegen een klassieke aanvaller, dus zelfs een schema op NIST-niveau 1 levert al een licht verbeterde beveiliging op tegen klassieke aanvallen. We accepteren daarom elke handtekening die gericht is op NIST-niveau 1 of hoger.

Naast het beoogde NIST-niveau zijn er nog een paar overwegingen:

• Veel post-kwantumhandtekeningenschema's zijn relatief jong en daarom is het nog niet geheel duidelijk hoe veilig ze zijn. Om beschermd te blijven tegen klassieke aanvallen is het, voor het geval een post-kwantumschema onveilig blijkt te zijn, verstandig om een hybride handtekening te gebruiken. Zo'n handtekening bestaat uit een combinatie van een post-kwantumhandtekening en een klassieke handtekening, zodat de veiligheid gewaarborgd blijft als een van de componenten gekraakt wordt.

• Post-kwantumschema's zijn gebaseerd op diverse moeilijke wiskundige problemen. Sommige schema's zijn zeer betrouwbaar (zoals het hash-gebaseerde SLH-DSA), terwijl andere minder te vertrouwen zijn. Een mogelijke optie is om 2 nieuwe post-kwantumhandtekeningenschema's in te voeren, gebaseerd op verschillende complexiteitsaannames. Een ervan is dan een reserveschema waarop we snel kunnen overschakelen als het andere wordt gekraakt.

• De schema's verschillen in de mate waarin het standaardisatieproces is gevorderd. ML-DSA en SLH-DSA zijn daar al heel ver in en worden inmiddels ondersteund in veelgebruikte software en HSM's. Ook Falcon (dat FN-DSA gaat heten) zou binnen afzienbare tijd moeten worden gestandaardiseerd. Van de andere kandidaten is het nog maar de vraag of ze de procedure van NIST zullen doorstaan. ML-DSA, SLH-DSA en Falcon zijn dus aantrekkelijker, omdat ze eerder in gebruik kunnen worden genomen.

Vertraging

Het tweede belangrijke aspect is de impact op de performance. Binnen de RPKI downloaden alle validators honderdduizenden objecten die allemaal door hen worden gevalideerd. De tijd die dat in beslag neemt, beïnvloedt hoelang het duurt voordat wijzigingen via de RPKI gepropageerd worden in de BGP-routering. Als een nieuw handtekeningenschema ervoor zorgt dat er meer data gedownload moet worden of dat het verifiëren van objecten langer duurt, neemt de vertraging toe. Daarnaast zou het duurder kunnen worden om een validator of repository te draaien.

Er moet een afweging gemaakt worden tussen schema's met kleine handtekeningen maar trage verificatie en schema's met grotere handtekeningen maar snellere verificatie. Ter ondersteuning van de besluitvorming in deze context modelleren we hoe we verwachten dat 2 factoren van de vertraging zullen veranderen afhankelijk van de eigenschappen van de handtekeningen.

• De tijd die het kost om alle objecten uit de RPKI te downloaden. We gaan ervan uit dat alle objecten worden gedownload (zonder caching) en dat de downloadtijd evenredig is aan de grootte van de RPKI. Om een referentiepunt te krijgen, hebben we gemeten hoeveel tijd het downloaden in beslag neemt (constante factoren zoals time-outs en het opzetten van de initiële verbindingen buiten beschouwing latend). In onze opzet duurt het deel van een volledige download dat afhankelijk is van de grootte ongeveer 14,5 seconden. Dit is echter wel gemeten bij een RP met een relatief goede internetverbinding. Veel andere RP's zijn waarschijnlijk trager.

• De tijd die de CPU nodig heeft om handtekeningen te verifiëren. Hiervoor hebben we als referentiepunt gemeten dat het verifiëren van alle RSA-handtekeningen in Routinator ongeveer 13 seconden aan CPU-tijd vergt.

Aan de hand van deze 2 referentiepunten kunnen we voor elk handtekeningenschema – op basis van de grootte van de handtekening/sleutel en de gemeten verificatietijden – voorspellen hoeveel langer het downloaden van de validatie zal duren ten opzichte van RSA-2048. De resulterende cijfers zijn niet representatief voor alle validators in de praktijk, maar vormen wel een solide basis voor het vergelijken van de verschillende schema's.

Welke kandidaten voldoen aan de vereisten?

We hebben gekeken naar de post-kwantumschema's die door NIST zijn geselecteerd voor standaardisatie en naar de inzendingen voor ronde 2 van de oproep van NIST voor aanvullende post-kwantumhandtekeningen. Deze oproep is gericht op het standaardiseren van aanvullende schema's die gebaseerd zijn op andere wiskundige problemen dan die ten grondslag liggen aan ML-DSA en Falcon, of die een performancevoordeel opleveren.

Wanneer we onze methode toepassen om de impact op de performance van veelbelovende kandidaten in te schatten, levert dat de volgende resultaten op (meer opties vind je in het volledige onderzoek):

Falcon-512 laat over het algemeen de beste performance zien, met diverse alternatieven die vergelijkbaar presteren. Een bijkomend voordeel van Falcon is dat het al door NIST is geselecteerd voor standaardisatie (een eerste publieke conceptversie zou eind 2024 worden gepubliceerd onder de naam FN-DSA). De andere kandidaten (met uitzondering van ML-DSA) kunnen nog steeds worden geëlimineerd, en Falcon-512 zal veel sneller dan de rest op grote schaal beschikbaar zijn (in standaarden, software en Hardware Security Modules).

Het is echter wel zo dat dit is gebaseerd op de geschatte duur van volledige downloads en validaties. Er zijn allerlei factoren die een rol spelen bij het bepalen welk algoritme het meest geschikt is:

• In de praktijk slaan validators objecten meestal op in de cache, dus ze voeren eenmalig een volledige download uit en daarna tal van kleinere incrementele updates.

• We zijn verder uitgegaan van de volledige adoptie van 1 nieuw handtekeningenschema en hebben aangenomen dat de structuur van de RPKI (zoals het aantal objecten) ongewijzigd blijft. In de praktijk is het echter mogelijk om het aantal ROA's te verminderen door deze samen te voegen tot grotere, meer efficiënte ROA's, waardoor de grootte van minder belang is.

• Een andere mogelijkheid is dat validators ook de resultaten van de handtekeningenverificatie cachen, zodat de volledige verificatietijd alleen geldt voor de eerste download van een object, en niet voor elke incrementele update.

• Tot slot kan de verificatietijd worden geparallelliseerd over meerdere CPU-cores, en is het opschalen van het aantal cores doorgaans eenvoudiger dan het vergroten van de downloadbandbreedte. Dat maakt de verificatietijd minder belangrijk.

Afhankelijk van een groot aantal van deze factoren kan de beste keuze voor een handtekeningenschema veranderen, maar door de bank genomen lijkt Falcon-512 een goede keuze.

Vervolgens moeten we een klassieke component kiezen die we met een post-kwantum handtekening kunnen combineren tot een hybride constructie. Logische keuzes voor de klassieke component zijn RSA-2048, RSA-3072 en Ed25519. In combinatie met Falcon-512 komen we tot de volgende performance-inschattingen:

Gezien de vele onzekere factoren die de afweging tussen grootte en verificatietijd beïnvloeden, is er hier geen duidelijke winnaar. Als gebruik wordt gemaakt van verificatiecaching, speelt de verificatietijd nauwelijks een rol. Maar omdat incrementele updates vaker voorkomen dan volledige downloads, lijken de grotere sleutels en handtekeningen van RSA ook goed hanteerbaar.

Kunnen we sneller zijn?

Hoewel we hebben vastgesteld dat een hybride constructie met Falcon-512 geschikt is als directe vervanging van RSA, presenteren we ook een idee dat de data- en rekenlast van de RPKI aanzienlijk kan verminderen: het verwijderen van de overbodige handtekeningen en publieke sleutels die in elke ROA zijn opgenomen.

Ondertekende objecten in de RPKI (zoals ROA's) bevatten elk 1 publieke sleutel en 2 handtekeningen. Er is een eenmalig te gebruiken 'end-entity'-certificaat (EE-certificaat), uitgegeven door de resourcehouder, dat een eenmalig te gebruiken sleutelpaar certificeert. Dit sleutelpaar wordt vervolgens gebruikt om het object zelf te ondertekenen en daarna weggegooid. Het EE-certificaat bevat een handtekening van de private langetermijnsleutel van de uitgever, en de publieke sleutel van het eenmalige sleutelpaar. Beide zijn overbodig. In de volgende figuur wordt de structuur van een ROA weergegeven.

De reden dat er een eenmalig EE-certificaat wordt gebruikt in plaats van dat de resourcehouder het object rechtstreeks ondertekent met zijn langetermijnsleutel, is dat intrekking dan kan plaatsvinden via een Certificate Revocation List (CRL) en er geen speciaal intrekkingsmechanisme voor de RPKI hoeft te worden geïmplementeerd. Het is voldoende om het unieke serienummer van het eenmalig te gebruiken EE-certificaat toe te voegen aan een CRL. De eenmalige sleutel wordt dan ingetrokken, en daarmee ook de eenmalige handtekening op het betreffende object.

Null Scheme

We stellen een schema voor dat we het Null Scheme noemen. Dit is een soort handtekeningenschema speciaal voor eenmalige EE-certificaten in de RPKI. In plaats van een eenmalig sleutelpaar te genereren, werkt ons Null Scheme als volgt:

• De handtekening is altijd de lege string.

• De publieke sleutel is een hash van het te ondertekenen bericht.

• Verificatie vindt plaats door de publieke sleutel te vergelijken met de hash van het bericht.

Deze aanpak is mogelijk dankzij de minder strenge eisen die in dit gebruiksscenario aan een handtekeningenschema worden gesteld. Het sleutelpaar wordt maar 1 keer gebruikt, en het bericht dat ondertekend moet worden, is al bekend voordat het sleutelpaar wordt gegenereerd. Wat ondertekend wordt, is niet afhankelijk van de publieke sleutel die voor de ondertekening wordt gebruikt en die is opgenomen in het bijgevoegde EE-certificaat (RFC 5652).

Het door ons voorgestelde schema is net zo veilig als de huidige aanpak: het is afhankelijk van de veiligheid van het voornaamste handtekeningenalgoritme (RSA of de post-kwantumvervanging ervan), en van de collision resistance of second-preimage resistance van de hashfunctie. Beide zijn ook vereist wanneer er 2 reguliere handtekeningen worden gebruikt.

Het Null Scheme heeft een aantal grote voordelen:

• Grootte: We vervangen 1 handtekening en 1 publieke sleutel door slechts 1 hashwaarde. Bij gebruik van RSA-handtekeningen en SHA-256 (de huidige situatie) bespaart dat 496 bytes per object. Voor een ROA van mediane grootte betekent dat een afname van 2.125 bytes naar 1.629 bytes. Op de volledige RPKI-dataset van 838 MB levert dat een besparing op van 172 aan overhead.

• Verificatietijd: We besparen ook 1 handtekeningverificatie per object. In plaats daarvan hoeft alleen een hashfunctie te worden berekend, wat sowieso al nodig is bij het verifiëren van een handtekening. Dat scheelt 35% van de totale verificatietijd in de RPKI.

Beide performancevoordelen komen al van pas in de huidige RPKI, maar helemaal bij het gebruik van grotere en tragere handtekeningenalgoritmen. Vergeleken met Falcon-512 + RSA-2048 bespaart het Null Scheme 1.169+922-32 = 2.059 bytes per ondertekend object. De mediane ROA krimpt van 4.354 naar 2.295 bytes, wat het effect van de algoritmerollover al bijna compenseert. Over de volledige RPKI kan 717 worden bespaard ten opzichte van de totale grootte van 1,7 GB bij gebruik van Falcon-512 + RSA-2048. Dat komt neer op 82% van de toename in totale grootte bij de vervanging van RSA-2048 (838 MB).

Een ander voordeel van het Null Scheme is dat het zich gedraagt als een normaal handtekeningenschema. Dit betekent dat het kan worden ingevoerd met alleen een algoritmerollover (ter vervanging van RFC 7935), zonder enige aanpassing van de RPKI-specificaties. Dit maakt implementatie relatief eenvoudig, vooral in combinatie met de introductie van een post-kwantumhandtekeningenschema.

Hoe kunnen we de overstap maken?

Behalve dat we een geschikt post-kwantumhandtekeningenschema moeten vinden, moeten we ook uitzoeken hoe dit in de bestaande RPKI kan worden ingevoerd. Wij stellen dat een bestaande procedure (die nog nooit gebruikt is) daarvoor niet geschikt is en doen een alternatief voorstel waarvan we denken dat het beter uitvoerbaar is.

RFC 6916

In de beginfase van de RPKI definieerde de SIDR-werkgroep (Secure Inter-Domain Routing) van de IETF een procedure voor algorithm agility (algoritmische wendbaarheid) in RFC 6916. Het kernprincipe van deze aanpak is dat 'gemengde' certificaten niet zijn toegestaan. Dit houdt in dat een RPKI-certificaat met een algoritme-A-subject alleen mag worden ondertekend met een algoritme-A-handtekening, en met een algoritme-B-subject alleen met een algoritme-B- handtekening. Dit impliceert dat het migratieproces top-down verloopt: eerst moet de root-CA certificaten uitgeven op basis van algoritme B, daarna het volgende niveau, en zo verder totdat alle CA's zijn overgestapt op algoritme B.

De procedure in RFC 6916 begint met het vastleggen van 5 wereldwijde mijlpaaldatums en het algoritme (B) waarop wordt overgestapt. In meerdere fasen wordt een volledig aparte kopie van de RPKI gecreëerd, waarin met het nieuwe algoritme wordt gewerkt. Intussen blijft de oude RPKI (met algoritme A) gewoon in gebruik. Op een bepaald moment stappen de RP's van het valideren van de A-boom over op de B-boom, waarna de A-boom uiteindelijk wordt verwijderd.

Wij zijn van mening dat die procedure operationeel onuitvoerbaar is: er is intensieve coördinatie tussen alle CA's voor nodig en er moet een tijdlijn gevolgd worden die maanden of jaren van tevoren is vastgesteld. Het creëren van een aparte kopie van de RPKI vergt een aanzienlijke inspanning en het gesynchroniseerd houden van 2 bomen is zeer complex. Tot slot gaat deze aanpak ervan uit dat we migreren naar een situatie waarin slechts 1 handtekeningenalgoritme wordt gebruikt, terwijl wij juist hebben geconstateerd dat het voordelig kan zijn om meerdere algoritmen tegelijkertijd toe te staan.

Verschillende softwareontwikkelaars en RIR-beheerders hebben soortgelijke zorgen geuit en aangegeven de voorkeur te geven aan een alternatief met gemengde certificaten. Daarnaast woedde er tijdens de ontwikkeling van RFC 6916 al een verhitte discussie over de fundamentele aannames van de procedure. Met name Brian Dickson zette vraagtekens bij de aanname van de auteurs van RFC 6916 dat een wereldwijd gecoördineerde top-down migratie onvermijdelijk is. Hij stelde een eenvoudiger alternatief voor met gemengde certificaten.

Uiteindelijk werd het fundamentele meningsverschil tussen Dickson en de auteurs van de RFC nooit opgelost. Zijn alternatief vond echter weinig weerklank en na 2 jaar stilte werd het conceptdocument alsnog gepubliceerd, ondanks het duidelijke gebrek aan consensus.

Aanpak met gemengde bomen

Wij stellen een alternatief voor RFC 6916 voor met gemengde bomen, dat nauw aansluit bij het voorstel van Dickson. In tegenstelling tot RFC 6916:

• behandelt dit alternatief de invoering van een nieuw algoritme B en de uitfasering van het oude algoritme A als afzonderlijke processen (waardoor het een stabiele status ondersteunt waarin meerdere algoritmen tegelijkertijd zijn toegestaan);

• staat het gemengde certificaten toe, waarbij een bovenliggende CA die algoritme A gebruikt een onderliggende CA die algoritme B gebruikt kan ondertekenen, en omgekeerd;

• maakt het zo een flexibelere aanpak mogelijk, waarbij CA's individueel kunnen beslissen om over te stappen op een ander algoritme.

Het kernprincipe van deze aanpak is dat, voordat CA's op grote schaal migreren naar het nieuwe algoritme B, (nagenoeg) alle RP's in staat moeten zijn om handtekeningen met algoritme B te valideren. Met die aanname kunnen we accepteren dat er tijdens de overgangsfase geen RPKI-boom met alleen algoritme A is. Er is dus geen noodzaak om een afgescheiden, gesynchroniseerde kopie van de RPKI te onderhouden, zoals in RFC 6916.

Het toestaan van gemengde certificaten betekent dat CA's zelfstandig kunnen bepalen wanneer ze overstappen op een nieuw algoritme. Hierdoor is minder coördinatie vereist en krijgen CA-beheerders meer ruimte om de overstap in hun eigen tempo uit te voeren.

Ons voorstel werkt als volgt:

• Fase 0: Dit is de huidige status, voordat de migratie begint. Beheerders van RP-software kunnen bijgewerkte software die handtekeningen gemaakt met algoritme B kan valideren al uitproberen en publiceren, maar er is nog niets gestandaardiseerd.

• Fase 1: Fase 1 begint met de publicatie van het nieuwe algoritmedocument dat RFC 7935 vervangt en het nieuwe algoritme B definieert. Dit document staat het gebruik van zowel algoritme A als B toe en vereist dat RP's beide algoritmen accepteren. In deze fase moeten RP's worden bijgewerkt om algoritme B te ondersteunen, en moeten de root-CA's nieuwe trust anchors (die nog niet in gebruik zijn) publiceren, zodat deze samen met de bijgewerkte RP-software kunnen worden verspreid. Het is mogelijk om praktijkexperimenten uit te voeren met behulp van een 'leaf'-CA. Een reguliere CA ondertekent een certificaat voor een test-CA die een B-sleutel heeft. Dit maakt het mogelijk om de gereedheid van de RP's voor het nieuwe algoritme te testen en te monitoren.

• Fase 2: Wanneer voldoende RP's bekend zijn die algoritme B accepteren, kunnen CA's op brede schaal over gaan stappen op algoritme B. In het volledige afstudeeronderzoek stellen we een reeks experimenten voor die kunnen worden gebruikt om te monitoren of RP's hier klaar voor zijn. Anders dan bij RFC 6916 is het niet nodig om een specifieke datum voor de start van fase 2 af te spreken. Omdat de migratie niet top-down hoeft te verlopen, kan een kleine, experimentele CA als eerste overstappen. Als dat goed gaat (en RP's het nieuwe algoritme accepteren), kunnen grotere CA's veilig volgen wanneer ze er klaar voor zijn.

Bij deze strategie is het wel belangrijk om RP-updates zo snel mogelijk uit te rollen, omdat er veel tijd overheen gaat voordat deze overal zijn geïmplementeerd. Aan de andere kant kunnen CA's wachten met overstappen tot de kwantumdreiging daadwerkelijk aanstaande is.

Een individuele CA kan heel eenvoudig overstappen op een ander algoritme door exact dezelfde procedure te volgen die gewoonlijk wordt gebruikt voor een reguliere sleutelrollover: RFC 6489. De migrerende CA vraagt een nieuw certificaat aan voor de nieuwe sleutel (nu met algoritme B) en maakt alvast kopieën van al zijn objecten, maar dan ondertekend met de nieuwe sleutel. Enige tijd nadat het nieuwe certificaat door de bovenliggende CA is gepubliceerd, worden alle objecten vervangen door de opnieuw ondertekende versies. Dit is een bekende procedure die zich in de praktijk heeft bewezen.

Als er iets fout gaat, is het bovendien mogelijk om een rollover volgens RFC 6489 terug te draaien door simpelweg de oorspronkelijke objecten opnieuw te publiceren, ondertekend met de oude sleutel. Daarmee wordt het risico dat sommige RP's niet klaar zijn voor het nieuwe algoritme nog verder gemitigeerd.

De aanpak met gemengde bomen is aanzienlijk aantrekkelijker voor CA-beheerders en kan eerder bescherming bieden tegen kwantumaanvallen dan RFC 6916, om de volgende redenen:

• Gemakkelijker om te beginnen met migreren: De gemengde aanpak maakt het mogelijk om in een vroeg stadium te experimenteren met leaf-CA's. Een kleine CA kan het nieuwe algoritme in het echt testen zonder te hoeven wachten tot alle bovenliggende CA's in de hiërarchie zijn gemigreerd. Hierdoor kunnen beheerders vertrouwen opbouwen in de nieuwe technologie en eventuele problemen vroegtijdig signaleren, in plaats van daar pas tegenaan te lopen tijdens een gecoördineerde wereldwijde uitrol.

• Aantrekkelijker voor beheerders: De aanpak is veel gemakkelijker te implementeren. CA-beheerders hoeven geen parallelle kopie van de volledige RPKI-boom te onderhouden, wat complex en kostbaar zou zijn om te implementeren. Ook is er geen wereldwijde coördinatie met strikte mijlpaaldatums nodig, zodat CA's hun migratie kunnen plannen op het moment dat ze over voldoende personeel en resources beschikken. Dat kan CA's minder huiverig maken om de overstap te wagen, wat kan helpen om het draagvlak en de consensus te creëren die nodig zijn om de migratie daadwerkelijk door te voeren.

• Eerdere bescherming voor individuele CA's: Met de gemengde aanpak zijn individuele CA's al beschermd tegen kwantumaanvallen zodra ze beschikken over een keten waarin alle certificaten – van de root tot aan henzelf – zijn ondertekend met algoritme B. Dit in tegenstelling tot RFC 6916, dat de oude algoritme A-boom gedurende de hele migratieperiode actief houdt, waardoor zelfs CA's die al producten met algoritme B hebben gepubliceerd kwetsbaar blijven voor kwantumaanvallen totdat de wereldwijde migratie overal is afgerond. Met gemengde certificaten is een CA die is overgestapt op post-kwantum handtekeningen direct beschermd, ongeacht wat andere CA's in het ecosysteem doen. Dat is gunstig, aangezien veel kleine CA's naar verwachting veel meer tijd nodig zullen hebben om te migreren dan het beperkte aantal grote spelers.

Implementatie

Om aan te tonen dat de migratieaanpak met gemengde bomen in de praktijk werkt, implementeerden we een proof-of-concept met Falcon-512-handtekeningen in twee op brede schaal gebruikte RPKI-softwarepakketten: Routinator (een validator) en Krill (CA-software). Hiervoor waren slechts minimale aanpassingen nodig aan de gedeelde Rust-codebase waarop beide tools zijn gebouwd, zonder dat Routinator zelf aangepast hoefde te worden.

Uit onze tests blijkt dat de gemengde aanpak werkt zoals bedoeld. We hebben met succes RPKI-omgevingen opgezet waarin verschillende CA's verschillende algoritmen gebruiken, en aangetoond dat individuele CA's algoritmerollovers kunnen uitvoeren volgens de vertrouwde RFC-6489-procedure voor sleutelrollovers die beheerders al kennen. De migratie is inderdaad voor elke CA een lokale operatie: wanneer een CA van algoritme verandert, heeft dat geen invloed op de andere CA's in de boom.

We hebben de broncode vrijgegeven zodat andere ontwikkelaars de interoperabiliteit kunnen testen en onze inschattingen van de benodigde CPU-tijd voor validatie kunnen verifiëren. Dit zou de RPKI-gemeenschap moeten helpen vertrouwen te krijgen in de aanpak en te beginnen met het plannen van de post-kwantummigratie.

Conclusies

Mijn afstudeeronderzoek vormt het eerste onderzoek naar post-kwantumcryptografie voor de RPKI en legt daarmee de basis voor het kwantumveilig maken van deze kritieke internetinfrastructuur.

We hebben aangetoond dat de RPKI kwetsbaar is voor ernstige kwantumaanvallen, wat het gebruik ervan riskant maakt wanneer dergelijke aanvallen een reële mogelijkheid vormen. Het is daarom essentieel om de RPKI tijdig te upgraden naar post-kwantumcryptografie – voordat deze aanvallen uitvoerbaar worden – om ook in de toekomst veilige routering te kunnen garanderen.

Vervolgens hebben we een methodologie gepresenteerd voor het vergelijken van de te verwachten performance-impact van verschillende post-kwantumhandtekeningenschema's binnen de RPKI. Falcon-512 komt daarbij naar voren als een goede optie.

De performance-impact van post-kwantumhandtekeningen kan worden gemitigeerd door bijvoorbeeld ons Null Scheme toe te passen in ondertekende RPKI-objecten. Dit schema kan een groot deel van de overhead van post-kwantumhandtekeningen compenseren door overbodige gegevens in eenmalig te gebruiken EE-certificaten te elimineren. Het schema kan op zichzelf al een waardevolle bijdrage leveren, maar is vooral effectief in combinatie met de migratie naar post-kwantumhandtekeningen.

Tot slot hebben we laten zien dat de migratiestrategie uit RFC 6916 operationeel onwerkbaar is, en in plaats daarvan een migratieaanpak met gemengde bomen voorgesteld die flexibele, individuele CA-migraties mogelijk maakt via de beproefde procedure voor sleutelrollovers. In de voorgestelde strategie worden RP-updates en TAL's zo vroeg mogelijk verspreid, terwijl CA's hun migratie zonder problemen kunnen uitstellen.

De bevindingen en aanbevelingen in mijn afstudeeronderzoek bieden de RPKI-gemeenschap de noodzakelijke basis om te beginnen met het plannen en uitvoeren van de transitie naar post-kwantumcryptografie. Dat proces kan starten met het opstellen van conceptdocumenten waarin een selectie van mogelijke post-kwantumalgoritmen en de bijbehorende migratiestappen wordt beschreven, die vervolgens door de gemeenschap besproken kunnen worden.