Een post-kwantum certificeringsinstantie met Merkle Tree Certificates opzetten

Wanneer je een adres in een browser intypt, hoe weet je dan dat je verbinding maakt met de juiste website? De Web Public Key Infrastructure (Web PKI) is het complexe en gedistribueerde ecosysteem van beleidsregels, protocollen en infrastructuurbeheerders dat ervoor zorgt dat je erop kunt vertrouwen dat je niet naar een verkeerde of kwaadaardige website wordt omgeleid. In de afgelopen decennia heeft dit ecosysteem aanzienlijke veranderingen ondergaan. Eén daarvan is de toevoeging van transparantie: de inmiddels verplichte eis dat alle certificaten worden geregistreerd in openbare certificaattransparantie-logs. Nu staat het systeem voor een nieuwe uitdaging: de op handen zijnde komst van een kwantumcomputer, die ons ertoe heeft aangezet om tegen 2029 over te stappen op post-kwantum (PQ) cryptografie.

Deze overgang is niet eenvoudig: het simpelweg vervangen van post-kwantumcryptografie in certificaten op internetschaal zou leiden tot een onaanvaardbare verslechtering van de prestaties. Dit moment vraagt om een nieuwe aanpak van de Web PKI: een benadering waarbij we transparantie kunnen beschouwen als een intrinsieke eigenschap in plaats van als een extraatje, en waarmee we een nieuw systeem te ontwerpen dat post-kwantum handtekeningen op efficiënte wijze kan opschalen .

Nadat Merkle Tree Certificates (MTC's) brede steun hebben gekregen binnen de sector, worden ze beschouwd als weg vooruit. Dit jaar, na een succesvol experimenteel proefimplementatie met Chrome, zet Cloudflare zich volop in voor MTC’s.

Naar aanleiding van de aankondiging van vandaag dat Cloudflare een certificeringsinstantie (CA) wordt, delen we graag dat deze CA de uitgifte van MTC-certificaten zal ondersteunen, met als doel begin 2027 opgenomen te worden in de onlangs gelanceerde Quantum-resistant Root Store van Chrome. Als onderdeel van onze missie om bij te dragen aan een beter internet, en in lijn met de traditie van Cloudflare om de sterkste beschikbare cryptografie gratis aan te bieden, zullen we standaard MTC-certificaten kosteloos uitgeven. Door een CA te hebben die zowel klassieke certificaten als MTC-certificaten ondersteunt, kunnen we standaard de veiligste authenticatiemethode gebruiken die er is, waardoor we een moeiteloos en performant PQ-upgradepad bieden voor een groot deel van het internet.

Het huidige vertrouwensecosysteem

Om te begrijpen hoe MTC's voor een doorbraak zorgen, beginnen we met wat achtergrondinformatie over hoe vertrouwen tegenwoordig op het internet werkt.

Aan de clientkant beschikken browsers — in dit geval 'TLS-clients' — over rootprogramma's waarin een reeks beleidsregels is vastgelegd waaraan certificeringsinstanties (CA’s) moeten voldoen om betrouwbaar te worden beschouwd. Aan de serverkant zijn CA's de vertrouwde poortwachters: zij beheren de infrastructuur voor de uitgifte van certificaten, waarbij ze eigendom van domeinen valideren en de koppeling bevestigen tussen een domeinnaam en een openbare sleutel die het eigendom van dat domein aantoont.

Maar hoe controleren we of certificeringsautoriteiten zich aan de regels houden? Hier komt certificaattransparantie (CT) om de hoek kijken, waardoor de uitgifte van certificaten openbaar kan worden gecontroleerd. Wanneer een certificeringsautoriteit een certificaat uitgeeft, moet dat certificaat ook bij ten minste twee openbare logs ingediend worden. Cloudflare beheert sinds 2016 de Nimbus-reeks van CT-logs en lanceert Raio, een nieuwe reeks statische CT-logs.

Hoewel het CT-ecosysteem certificaten openbaar zichtbaar maakt, betekent dit niet dat ze correct zijn uitgegeven of veilig zijn om te gebruiken. Monitoring helpt hierbij door die logrecords te vergelijken met wat domeineigenaren verwachtten en verdachte activiteiten te melden. Cloudflare heeft in 2019 Certificate Transparency Monitoring gelanceerd en heeft deze dienst onlangs  algemeen beschikbaar gemaakt. We publiceren ook grootschalige metingen over certificaten op de Certificate Transparency-pagina in Radar (voorheen bekend als Merkle Town).

Naarmate organisaties hun servers gaan upgraden om gebruik te maken van PQ-authenticatie, zal het monitoren van certificaattransparantie een nog belangrijkere rol gaan spelen bij het opsporen van mogelijke post-kwantum-downgrades. Domeineigenaren die hun domeinen hebben geüpgraded naar post-kwantum-authenticatie moeten CT-logs controleren op onverwacht uitgegeven verouderde certificaten om te voorkomen dat clients terugvallen op een kwaadaardige downgrade-traject.

Een deel van het probleem met dit huidige systeem is dat transparantie als een extra functie is toegevoegd, waardoor het met schaalbaarheidsproblemen te kampen heeft. Certificaten worden vaak meerdere keren, in verschillende vormen, in meerdere logs geregistreerd, waardoor toezichthouders elke log moeten downloaden en verwerken om te voorkomen dat ze een uitgifte missen. Dit kan kostbaar zijn — waardoor het moeilijk is om een diverse groep logbeheerders op internetschaal aan te moedigen. Volgens onze schattingen zullen PQ-handtekeningen de hoeveelheid gegevens die CT-logs moeten opslaan met een factor 40 doen toenemen. Deze schaalbaarheidsuitdaging, en de daaruit voortvloeiende misalignment van prikkels, vormt de kern van het post-kwantum schaalbaarheidsprobleem.

Het post-kwantum schaalbaarheidsprobleem

We hebben uitgebreid geschreven over de uitdagingen bij het opschalen van post-kwantum-cryptografie, maar kort samengevat: om serverauthenticatie op internetschaal te ondersteunen, moet de Web PKI ongeveer een miljard TLS-servers authenticeren zonder de openbare sleutel van elke server vooraf in elke client te laden. Traditioneel hebben CA's dit probleem opgelost door certificaatketens te gebruiken als mechanisme voor vertrouwensdistributie. Maar in de loop der tijd hebben toevoegingen zoals controles op sleutelintrekking en certificaattransparantie meer openbare sleutels en handtekeningen toegevoegd — vijf handtekeningen en twee sleutels in een typische TLS-handshake. PQ-handtekeningen zijn ongeveer 40 keer groter dan klassieke handtekeningen, leidt tot grotere overheadkosten die voor clients, CA’s, logs en monitoren op grote schaal duur zouden zijn om te verwerken.

En toen waren er de Merkle Tree Certificates (MTC's), een conceptspecificatie van de IETF PLANTS-werkgroep die een architectuur beschrijft voor compacte, efficiënte, post-kwantum-certificaten. MTC's bundelen certificaten in een append-only Merkle-boom, waardoor een CA de wortel van die boom kan ondertekenen in plaats van veel afzonderlijke certificaten. Hierdoor kunnen browsers of andere clients een certificaat verifiëren met behulp van een compact opnamebewijs — een reeks cryptografische hashes — ten opzichte van een ondertekende boomtop, in plaats van elk certificaat afzonderlijk te valideren. Een sleutelidee achter MTC's is ‘log niet wat je uitgeeft, maar geef uit door te loggen’. Door uitgifte en loggen aan elkaar te koppelen, wordt transparantie een operationeel vereiste in plaats van een extraatje.

De rol van een certificeringsinstantie in een herontworpen PKI

We breiden onze capaciteit voor het uitgeven van MTC's uit als integraal onderdeel van de opbouw van onze Cloudflare CA. Dat betekent dat we de nieuwe vereisten van het PQ Root-programma moeten bijhouden en een softwarestack voor het uitgeven en spiegelen moeten ontwikkelen, terwijl we ook de faciliteiten, bedrijfsvoering en compliance-functies van de traditionele CA opzetten — geen sinecure!

Het voordeel is dat we vanaf dag één prioriteit kunnen geven aan de vereisten en de architectuur voor deze nieuwe, post-kwantum PKI, en onze opzet zo kunnen vormgeven dat deze aansluit bij de waarden en het wereldwijde netwerk van Cloudflare — met als doel zo transparant mogelijk te zijn nu we aan deze nieuwe reis beginnen.

Laten we eens kijken naar de architectuur die is aangepast voor MTC:

Als je dit vergelijkt met het traditionele CA-ecosysteem, zul je merken dat de verantwoordelijkheden van een CA grotendeels gelijk blijven: het controleren van de eigendom van een domein, het koppelen ervan aan een openbare sleutel en het uitgeven van certificaten. Het grootste verschil is dat in het MTC-ecosysteem de CA, in plaats van certificaten direct te ondertekenen en ze vervolgens te loggen, nu een transparantielog bijhoudt die wordt ondersteund door een Merkle-boom, waarbij een bewijs van opname – dat het certificaat inderdaad in de boom aanwezig is – als vertrouwensanker dient. CA's zullen ook mirroring-cosigners beheren die een kopie van uitgifte-logs opslaan, de consistentie ervan (‘append-only’) verifiëren en de transparantie en beschikbaarheid van deze logs voor het bredere ecosysteem waarborgen.

MTC's uitgeven

MTC's zijn er in twee vormen, die beide kunnen worden gecodeerd in het X.509-certificaatformaat dat clientsoftware tegenwoordig herkent — alleen met een ‘vreemd’ ondertekeningsalgoritme. In de standalone-vorm bevat de ondertekeningswaarde van het certificaat een medeondertekende boomtop van een uitgiftelog en een opnamebewijs (een reeks hashes) waaruit blijkt dat het certificaat in dat logboek is opgenomen. Als clients de medeondertekende boomtoppen buiten het normale kanaal om kunnen verkrijgen (bijv. via een browser-updatemechanisme), kan het certificaat in plaats daarvan in de landmark-relative-vorm worden aangeboden, waarbij de ondertekeningswaarde bestaat uit het lichtgewicht opnamebewijs zonder zware post-kwantum-handtekeningen.

Laten we, om het eenvoudig te houden, eens kijken naar een voorbeeld van de uitgifte van een  standalone certificaat. Wanneer een website een certificaat voor zijn domein wil, kan dat bij een CA via het Automatic Certificate Management Environment (ACME)-protocol worden aangevraagd. Dit protocol  handelt certificaatverzoeken, domeinbeheervalidatie en uitgifteworkflows af. De ACME-infrastructuur van Cloudflare wordt een afsplitsing (fork) van Boulder, de breed ingezette en goed geteste ACME-software waarop Let's Encrypt draait. Let's Encrypt werkt actief aan de ontwikkeling van MTC-ondersteuning in Boulder, en we zijn van plan onze eigen fork te onderhouden waarin deze upstream-wijzigingen worden geïntegreerd, samen met Cloudflare-specifieke aanpassingen, waarbij we zo mogelijk upstream een bijdrage leveren.

Wanneer de MTC CA een aanvraag voor de uitgifte van een certificaat ontvangt, controleert de ACME-server van de CA of de server daadwerkelijk de controle heeft over het domein. Als die controles succesvol zijn, zet de CA die gegevens in een reeks en voegt ze toe aan een ‘append-only’ logboek.

Nadat de CA de MTC-vermelding aan het uitgifte-logboek heeft toegevoegd, berekent de CA de bijgewerkte status van het logboek en ondertekent vervolgens een checkpoint voor die status. Dit checkpoint bevestigt dat de CA alle vermeldingen die tot dat moment in de Merkle-boom van het logboek waren opgenomen, heeft uitgegeven.

De CA stuurt vervolgens deze bijgewerkte logboekstatus en nieuw checkpoint naar een vertrouwde medeondertekenaar, die een kopie van het uitgiftelogboek van de CA duurzaam opslaat en controleert elke nieuwe status op het volgende: ‘append-only’, consistent met de vorige boom en correct gevormd. Deze extra medeondertekening geeft clients en monitors het vertrouwen dat een andere vertrouwde partij dezelfde logstatus heeft waargenomen en geverifieerd heeft dat de CA niet verschillende weergaven van uitgifte aan verschillende delen van het ecosysteem presenteert. Dit zorgt er ook voor dat de uitgegeven certificaten beschikbaar zijn voor monitoring, zelfs als het uitgiftelogboek van de CA niet beschikbaar is.

Het conceptbeleid voor het Quantum-resistant Root Program vereist ten minste twee medeondertekeningen: één van een door Chrome erkende mirroring cosigner die door een afzonderlijke organisatie wordt beheerd, en één van de uitgevende MTC CA zelf. Daarom zullen we mirrors beheren voor andere CA’s die aan het proefproject deelnemen — en eisen we ten minste één onafhankelijke medeondertekening op de certificaten die wij zelf uitgeven.

Cloudflare zal onze mirroring cosigner implementeren in Azul, onze op Rust gebaseerde open-source transparantielogboek, en zal, voor maximale interoperabiliteit, het c2sp tlog mirror-protocol implementeren.

Nadat de CA met succes een medeondertekening van een mirroring-medeondertekenaar heeft ontvangen, stelt de CA tot slot een MTC samen met de medeondertekeningen, de openbare sleutel van de server en een opnamebewijs. Vervolgens stuurt de CA die MTC naar de server, die deze voortaan voor TLS kan gebruiken!

PQ-handtekeningen efficiënt verzenden: de landmark-optimalisatie

Hoewel standalone certificaten goed functioneren, verzenden ze tijdens de TLS-handshake nog steeds grote PQ-handtekeningen, wat hun efficiëntie beperkt. De echte prestatieverbeteringen die het MTC-ontwerp oplevert, zijn landmark-relative certificaten.

In plaats van in elk certificaat medeondertekeningen mee te sturen, kunnen CA's een reeks subbomen aanwijzen die alle actieve certificaten in het logboek omvatten als referentiepunt (landmark), en deze subbomen (samen met de gegevens om ze te authenticeren) via een out-of-band-updateservice naar clients versturen. Tijdens een TLS-handshake vindt de daadwerkelijke authenticatie bij de server plaats doordat de browser controleert of de certificaatgegevens van de server — inclusief de domeinnaam en de openbare sleutel — voorkomen in een vertrouwde subboom van het logboek van de CA. Als het opnamebewijs dat certificaat koppelt aan een medeondertekend landmark, en de openbare sleutel vervolgens tijdens de TLS-handshake het bezit ervan aantoont, weet de client dat hij met de juiste server communiceert.

Door deze handtekeningen en boomstructuur-metadata periodiek buiten het normale kanaal om naar TLS-clients te verzenden, kan een kleine set MTC-batchhandtekeningen op efficiënte wijze miljarden certificaten dekken die door een bepaalde CA zijn uitgegeven. Hoewel landmarks op schaal efficiënter zijn, maken ze standalone MTC’s niet overbodig: clients kunnen namelijk nieuw geïnstalleerd zijn, offline zijn of de relevante landmark-update missen. Daarom is het belangrijk dat servers een fallback voor standalone certificaten behouden.

MTC's in de praktijk: resultaten van ons experiment met Chrome

Dit jaar hebben we een experiment uitgevoerd met Chrome om de haalbaarheid van MTC's tussen een client en server te testen. We hebben een ‘bootstrap CA’ (een nep-CA die de uitgiftepijplijn simuleerde) ingezet die MTC’s uitgaf, ondersteund door een traditionele certificaatketen, voor een selectie van Cloudflare-domeinen op het 'gratis'-abonnement van Cloudflare, en deze aan 50% van de gebruikers van Chrome Beta 146 aangeboden. In de loop van het experiment hebben we met succes miljarden MTC's aangeboden.

Voor TLS hebben we vastgesteld dat het gebruikelijke scenario vrij efficiënt is: met een landmark-relative certificaat hoeft tijdens de handshake slechts één openbare sleutel, één handtekening en één opnamebewijs van minder dan 1 kB te worden verzonden. In het experiment zijn we teruggevallen op de traditionele certificaatketen in plaats van een standalone certificaat aan te bieden in gevallen waar we geen overeenstemming konden bereiken met de client over een landmark-relative certificaat. Aan de CT-kant veranderen MTC's ook de schaalbaarheidskenmerken van transparantie: het logboek hoeft alleen hashes van openbare sleutels bij te houden; er zijn geen handtekeningen per vermelding en de handtekening op de boomtop dekt het hele logboek. Dit voorkomt explosieve toename van het aantal certificaten, omdat het uitgifte-logboek van de CA de bron van waarheid is voor alle certificaten die de CA uitgeeft, en gebruikers van het logboek slechts één exemplaar van elk certificaat hoeven op te halen.

Het resultaat: MTC's werken echt! Gemiddeld is het gebruik van een landmark-MTC 9% sneller dan een klassieke handtekeningketen (toegegeven, het grootste deel van dit prestatievoordeel is te danken aan het weglaten van tussenstappen). En omdat we MTC's hebben getest met klassieke handtekeningen, verwachten we een nog grotere verbetering met post-kwantum handtekeningen. We waren tevreden over deze resultaten en over de sectoroverschrijdende samenwerking op het gebied van MTC's met de PLANTS WG van de IETF, een daarom zijn we vorige maand (augustus 2026) begonnen met het afbouwen van het experiment.

De toekomst van MTC's

We zijn blij dat ons experiment met Chrome heeft aangetoond dat MTC's in de praktijk kunnen werken, en zijn bijzonder enthousiast over het feit dat we nu als een echte CA certificaten te kunnen uitgeven.

Er zijn echter nog bredere vragen die we alleen kunnen beantwoorden door dit grootschalige experiment uit te voeren met het volledige PKI-ecosysteem. Kunnen onafhankelijke monitors MTC-uitgiftelogboeken op productievolume verwerken en verifiëren? Zullen er meerdere CA's en medeondertekenaars opkomen, zodat het systeem de diversiteit heeft die nodig is voor veerkracht? Hoe moeten browsers een evenwicht vinden tussen de prestatievoordelen van compacte landmark-MTC's afwegen tegen de fallback-paden die nodig zijn voor clients zonder recente landmarks? MTC's zijn naar voren gekomen als het toonaangevende ontwerp voor post-kwantum-authenticatie, maar om dit op de schaal van het productie-internet te bewijzen, is de deelname nodig van een diverse groep root-programma’s, browserleveranciers, CA’s, mirrors, waarnemers en de bredere community.

Wij beschouwen het als een eer om deel te mogen nemen aan deze volgende fase van de Web PKI, en nemen de verantwoordelijkheid voor het beheer van de CA-infrastructuur zeer serieus. CA's nemen een bevoorrechte positie in binnen het vertrouwensecosysteem: browsers, domeineigenaren en gewone gebruikers vertrouwen erop dat zij identiteiten correct valideren, ondertekeningssleutels beschermen, het beleid naleven en betrouwbaar functioneren. Voordat de CA van Cloudflare door browsers kan worden vertrouwd om MTC's uit te geven, moeten we een aanvraag indienen bij de Quantum Resistant Root Store van Chrome en een grondig evaluatieproces doorlopen. We verwelkomen die kritische beoordeling en verwachten dat we aan dezelfde hoge eisen zullen voldoen als elke andere CA die wordt vertrouwd om het internet te beveiligen. We hopen dat andere CA's opstaan om de invoering van MTC's te ondersteunen, en we kijken ernaar uit om samen te werken met elke browser die MTC's wil implementeren.