Google a Cloudflare chtějí postkvantově zajistit certifikáty a nerozbít přitom web

Dnes
Doba čtení: 8 minut

Sdílet

Adresní řádek se symbolem atomu
Autor: Shutterstock
Kvantové počítače potenciálně ohrožují nejen komunikaci, ale také bezpečnost certifikátů potvrzujících identitu komunikujících stran. Prosté nasazení nových algoritmů by ale znamenalo výrazně delší klíče a podpisy.

Kvantové počítače jsou teoretickou hrozbou budoucnosti, na kterou bychom se podle odborníků měli začít připravovat už dnes. Mohou nám totiž pomoci s řešením řady různých problémů, ale zároveň mohou ohrožovat současné algoritmy používané v asymetrické kryptografii s veřejným klíčem. Podle některých předpovědí tu dostatečně výkonné kvantové počítače budeme mít do deseti let, jiné zase tvrdí, že tu nebudou nikdy.

Co se dozvíte v článku
  1. Certifikáty v ohrožení
  2. Na velikosti záleží
  3. Merkle Tree Certificates (MTC)
  4. Certifikáty bez podpisu
  5. Velmi efektivní důkaz
  6. Google a Cloudflare už testují
  7. Raději být připraven dřív

Budoucí přítomnost kvantových počítačů ovšem může ohrozit data, která posíláme už dnes. Už nyní totiž někdo může ukládat zašifrovaná data a předpokládat, že si je přečte, až bude mít k dispozici dostatečně výkonný kvantový počítač. Tomuto principu se říká „posbírej dnes, dešifruj později“ (harvest now, decrypt later). Snahou je tedy vše připravit s dostatečným předstihem a pokud možno brzy začít přenášet data za použití algoritmů, které budou odolné proti tomuto typu útoku.

Už dnes je možné nasadit postkvantové algoritmy (PQC) do komunikačních protokolů a zajistit tak třeba web. Například Portál NÚKIB je zabezpečen pomocí algoritmu X25519MLKEM768, který kombinuje klasický algoritmus eliptických křivek X25519 s kvantově odolným ML-KEM-768. Organizace uvádí, že více než polovina spojení je už realizována novým algoritmem.

Certifikáty v ohrožení

Celé praktické řešení tohoto problému je ale mnohem širší a zahrnuje také například ochranu certifikátů. To jsou veřejné strojově čitelné dokumenty, které jsou vystavovány certifikačními autoritami. V nich autorita potvrzuje vazbu veřejného klíče žadatele a jeho identity, která byla standardizovanou cestou ověřena. Pravost certifikátu je pak podložena elektronickým podpisem, k jehož vytvoření byl použit soukromý klíč autority.

Také tento proces je napadnutelný dostatečně výkonným kvantovým počítačem, protože ve své podstatě používá stejné základní principy asymetrické kryptografie. Kvantový počítač lze tedy také použít k prolomení TLS certifikátu serveru, což útočníkovi umožní vydávat se za server vůči nic netušícím klientům.

Dobrou zprávou je, že už máme k dispozici postkvantové algoritmy, které můžeme použít také pro kvantově bezpečné ověřování. Špatnou zprávou je, že zavedení těchto algoritmů do TLS bude vyžadovat významné změny v jednom z nejkomplexnějších a z hlediska bezpečnosti nejdůležitějších systémů na internetu: Web Public-Key Infrastructure (WebPKI).

Na velikosti záleží

Základním problémem je tu už samotná velikost dat přenášených pro potřeby těchto nových algoritmů. Například podpisy pro ML-DSA-44, jeden z postkvantových algoritmů standardizovaných organizací NIST, mají délku 2420 bajtů, zatímco ECDSA-P256, nejoblíbenější současný podpis, používá podpisy o délce pouze 64 bajtů.

Podobně veřejné klíče ML-DSA-44 mají délku 1312 bajtů, zatímco klíč pro ECDSA má pouze 64 bajtů. To je zhruba dvacetinásobné zvětšení velikosti. Ještě horší je, že během úvodní komunikace TLS se přenese celá řada veřejných klíčů a podpisů. Klient totiž neověřuje jen koncový certifikát serveru, ale také podpisy všech mezilehlých certifikátů a podpis kořenové autority.

To v součtu u postkvantových klíčů a podpisů přidává desítky kilobajtů režijních nákladů na každé nové spojení. To stačí k tomu, aby změna měla znatelný dopad na výkon TLS. Prosté nahrazení starých certifikátů novými by tak uživatelé poznali, protože by to zpomalilo připojování k serverům se službami. Stejně tak by to ale byla zvýšená zátěž pro servery, kterým by výrazně narostla velikost přenášených dat pro každého uživatele.

Merkle Tree Certificates (MTC)

Vývojáři prohlížeče Chrome tvrdí, že tohle není správná cesta a nemají v plánu zařadit do svého kořenového úložiště nové důvěryhodné certifikáty používající postkvantovou kryptografii. Místo toho ve spolupráci s dalšími partnery pracují na evoluci certifikátů HTTPS založených na Merkle Tree Certificates (MTC), které jsou v současné době vyvíjeny v pracovní skupině PLANTS (PKI, Logs, And Tree Signatures) při IETF.

MTC nahrazují komplexní a rozsáhlý serializovaný řetězec podpisů, který se využívá v tradičním PKI, pomocí kompaktních důkazů vycházejících z Merkleova hašového stromu. Představa je taková, že v budoucnu certifikační autorita podepíše jediný kořen stromu, který bude zastupovat miliony certifikátů. Do prohlížeče pak bude k ověření odeslán pouze lehký důkaz o zařazení bodu důvěry do tohoto stromu.

Všechny informace, které klient potřebuje k ověření MTC, mohou být předány mimo komunikační kanál mezi ověřovaným serverem a klientem. Pokud má klient dostatečně aktuální data, pak TLS handshake (navázání bezpečného spojení) potřebuje pouze jeden podpis, jeden veřejný klíč a jeden důkaz o zařazení do Merkleova stromu.

Oddělí se tak síla odpovídajícího kryptografického algoritmu od velikosti dat přenášených k uživateli. Zmenšením autentizačních dat na absolutní minimum se MTC snaží udržet postkvantový web stejně rychlý a plynulý jako dnes a zachovat vysoký výkon i při zavedení silnějšího zabezpečení.

Navíc s MTC přichází do vydávání certifikátů automaticky také transparentnost. Není možné vydat certifikát, aniž by byl zahrnut do veřejného stromu. Vlastnosti současného komplexního systému Certificate Transparency tak budou rovnou součástí certifikačních autorit. Nebude tak nutné dále rozšiřovat TLS handshake o kontrolu SCT (Signed Certificate Timestamps), jak je tomu dnes.

Certifikáty bez podpisu

Hodně aktivní v oblasti postkvantového šifrování je společnost Cloudflare, která se aktivně zapojuje do vývoje nových protokolů a algoritmů a je velmi rychlá v jejich nasazování. Zástupci firmy nyní popsali aktuální stav MTC na svém blogu a předvedli, jak by komunikace s klientem mohla vypadat v praxi.

Při úvodním TLS handshaku dostane klient něco, co vypadá jako klasický certifikát ve formátu PEM. Technicky vzato to skutečně je certifikát podle standardu X.509. Najdeme v něm podle očekávání například doménové jméno, veřejný klíč a dobu platnosti. Chybí ovšem podpis autority, protože tento certifikát nic podobného neobsahuje. Také identifikátor podpisového algoritmu OID je pro současnou utilitu OpenSSL neznámý, protože jde o novou variantu.

Jak tedy ověříme platnost takového dokumentu bez podpisu autority? Trik spočívá v tom, že certifikační autorita nazvaná Merkle Tree Certification Authority (MTCA) vydává certifikáty bez podpisu v dávkách, nikoliv jednotlivě. Namísto podpisu obsahuje certifikát důkaz o zařazení certifikátu do dávky certifikátů podepsaných MTCA.

Pro podepsání dávky certifikátů uspořádá MTCA zatím nepodepsané certifikáty do Merkleova stromu. Každý list stromu odpovídá jednomu certifikátu a každý vnitřní uzel se rovná haši svých potomků. K podepsání celé dávky použije autorita svůj soukromý klíč a podepíše kořen stromu. Struktura pak zaručuje, že každý certifikát v dávce byl podepsán MTCA. Pokud bychom se pokusili upravit dodatečně jediný bit kteréhokoli z certifikátů, kořen by po přepočítání všech hašů měl jinou hodnotu, což by způsobilo selhání ověření.

Důkaz o zařazení certifikátu do stromu se skládá z haše každého sourozeneckého uzlu podél cesty od certifikátu ke kořeni stromu. Tato sekvence hašů postačí k prokázání zařazení certifikátu do stromu. To znamená, že k ověření MTC musí klient také získat podepsaný kořen stromu od MTCA.

Velmi efektivní důkaz

Podepsané kořeny stromů mohou být distribuovány klientům samostatným komunikačním kanálem a mohou být ověřeny offline. Každý ověřený kořen může být poté použit k ověření kteréhokoliv certifikátu v odpovídající dávce, což eliminuje potřebu získávat podpis pro každý serverový certifikát.

V průběhu TLS handshaku klient sdělí serveru, které kořeny už zná. Pokud má server certifikát MTC bez podpisu pokrytý jedním z těchto známých kořenů, může tento certifikát rovnou použít k prokázání své identity. To ve výsledku znamená potřebu přenosu jediného podpisu, jednoho veřejného klíče a jednoho důkazu o zařazení do stromu.

V praxi nebudou autority vytvářet nový strom pro každou dávku certifikátů, ale budou vytvářet jeden velký strom. Jak tento strom poroste, budou pravidelně vybírány podkořeny, které se budou odesílat do prohlížečů a které se nazývají orientační body (landmarks). Ty budou sloužit ke zkrácení cesty při procházení rozsáhlým stromem a umožní zmenšit objem dat posílaný klientovi.

V běžném případě budou prohlížeče schopny načíst nejnovější orientační body a servery mohou počkat na zařazení nových certifikátů do příští dávky. Někdy ale potřebujeme vydat certifikát rychle bez čekání. MTCA proto budou podporovat okamžité vystavení bez využití orientačních bodů. Takto vystavené certifikáty ale už nebudou tak efektivní a budou větší, než ty klasické, protože budou přenášet kompletní cestu až ke kořeni celého stromu.

Google a Cloudflare už testují

Google a Cloudflare už celou věc testují na skutečném internetovém provozu, zatím velmi opatrně, aby se na současném systému nic nerozbilo. Pracují na studii proveditelnosti, která vyhodnotí výkon a bezpečnost spojení založených na certifikátech MTC.

Cloudflare může podporu zapnout u části vybraných serverů, Chrome zase může pomalu zapínat podporu u klientů a vrátit se zpět, pokud se něco pokazí. Vše by mělo být zajištěno tak, aby se klient v případě problémů dokázal vždy vrátit k tradičnímu řešení s běžnými certifikáty. Toto je první fáze testů, která má zajistit data ze skutečného provozu.

Začátkem roku 2027 by měla nastat druhá fáze, během které budou osloveni provozovatelé logů pro Certificate Transparency, aby pomohli s nasazením MTC. Základní principy jsou u obou systémů stejné, jde o hašové stromy obsahující všechny vystavené certifikáty. Protože s tímto nasazením jsou už velké praktické zkušenosti, mělo by jít vše hladce.

Během roku 2027 budou také dokončeny požadavky na začlenění dalších certifikačních autorit do nového úložiště Chrome Quantum-resistant Root Store (CQRS), který bude podporovat pouze MTC. Tím vznikne nové úložiště důvěryhodných certifikátů, které bude speciálně navrženo pro požadavky postkvantového webu.

Chrome Quantum-resistant Root Program bude fungovat souběžně se stávajícím Chrome Root Programem, aby byl zajištěn postupný přechod mezi oběma systémy, který zachová kontinuitu pro všechny uživatele. V této třetí fázi bude také pro weby zavedena možnost používat pouze kvantově odolné certifikáty, bez zálohy v podobě paralelního použití klasických certifikátů.

Školení Kubernetes

Raději být připraven dřív

Obě společnosti si uvědomují, že podobné složité změny obvykle vyžadují více času, než se na začátku předpokládá. Zároveň bychom ale měli být připraveni raději dřív, než pozdě. Na nástupu velkých jazykových modelů (LLM) jsme viděli, jak rychle a neočekávaně může změna přijít. Také v případě kvantových počítačů se můžeme jednoho dne probudit a zjistit, že dnes je den-Q a staré pořádky neplatí.

Proto je potřeba spěchat, ale zároveň při tom nepoškodit to, co v současné době dobře funguje a plní důležitou roli v zabezpečení komunikace na internetu. Zatímco prostá náhrada algoritmů by znamenala citelný nárůst datových přenosů a způsobila by další potíže, návrh využívající MTC by měl umožnit hladký přechod. Podle dosavadních plánů to vypadá, že se nových certifikátů dočkáme velmi brzy.

Autor článku

Petr Krčmář pracuje jako šéfredaktor serveru Root.cz. Studoval počítače a média, takže je rozpolcen mezi dva obory. Snaží se dělat obojí, jak nejlépe umí.



Nejnovější články