Rozšíření IKEv2 přidá do podpisu i zprávu, kterou strana dostala od protějšku

IPsec šifruje pakety na úrovni IP a klíče si k tomu domlouvá protokolem IKEv2. Postkvantovou výměnu klíčů už umí: přidalo ji RFC 9370 jako další krok mezi úvodní a ověřovací výměnou, uvnitř mezikroku z RFC 9242. Kvůli starším protějškům je ten krok volitelný. Když ho iniciátor nenabídne nebo ho druhá strana nepřijme, spojení se naváže postaru. A právě tam vede cesta k útoku.

Cloudflare popsal 29. září, jak se ta mezera dá zneužít, a zároveň oznámil opravu. Firma ji vyvinula s pracovní skupinou IPSECME při IETF a u dvou svých služeb ji pustila do beta provozu. Sama přitom píše, že vadu spíš znovu objevila, než objevila: popsaná je nejmíň deset let.

Podpis, který nepokrývá odpověď protějšku

Úvodní výměna IKE_SA_INIT funguje tak, že iniciátor nabídne podporované parametry a pošle svůj podíl klíče, odpovídající strana vybere a pošle svůj. Teprve pak se navazuje ověření a v něm každá strana podepíše svoji identitu a své parametry.

Slovo „své“ je tady celý problém. Podle RFC 7296 podepisuje každá strana jen zprávy, které sama odeslala, ne celý přenos. Žádná z nich tedy protějšku nepotvrdí, že viděla tutéž posloupnost zpráv. Modernější protokoly to dělají obráceně: v TLS 1.3 podepisuje ověřující se strana celý průběh navazování včetně toho, co přijala. Útočník uprostřed tak může vyrobit rozdvojený pohled – iniciátor vidí jednu konverzaci, odpovídající strana druhou.

Dvě podoby útoku

Návrh IETF popisuje dva scénáře. První je útok při kompromitaci klíče. Chce tři věci naráz: útočník musí sedět na cestě a umět měnit zprávy, obě strany musejí ve svých politikách připouštět silnou i slabou výměnu klíčů a útočník musí tu slabou zlomit v reálném čase, a k tomu musí mít dlouhodobý ověřovací klíč jedné ze stran.

Pak už to jde rychle. Útočník z úvodní zprávy vyškrtá silné metody, odpovídající strana proto sáhne po slabé, útočník z obou podílů dopočítá relační klíče a ověřovací zprávu iniciátora dešifruje a přepíše tak, aby seděla na tu podvrženou. Obě strany skončí na spojení, které jejich pravidla dovolují, ale které by samy nikdy nevybraly.

Druhý scénář je zajímavější, protože nepotřebuje kompromitovat ani jednu ze stran. Popsala ho v roce 2016 práce Downgrade Resilience in Key-Exchange Protocols z konference IEEE Symposium on Security and Privacy; podepsáni jsou pod ní Karthikeyan Bhargavan, Chris Brzuska, Cédric Fournet, Matthew Green, Markulf Kohlweiss a Santiago Zanella-Béguelin. Stačí, aby útočník znal dlouhodobý klíč někoho jiného, komu odpovídající strana důvěřuje. V ověřovací zprávě pak jen vymění identitu iniciátora za svou a podepíše ji vlastním klíčem. Iniciátor je přesvědčený, že mluví s protějškem, kterého si vybral; protějšek si myslí, že mluví s útočníkem – a klíč zná útočník.

Kvantová varianta má jednu nepříjemnost pro útočníka: výpočet musí proběhnout online, přímo během navazování spojení. Tím se liší od sklízení šifrovaného provozu na později, kde se počítá bez časového tlaku. Cloudflare z toho vyvozuje, že tyhle útoky nebudou první na řadě, zároveň ale posunul vlastní termín přechodu na postkvantovou kryptografii na rok 2029.

Co rozšíření mění

Oprava se jmenuje IKE_SA_INIT_FULL_TRANSCRIPT_AUTH a je popsaná v návrhu draft-ietf-ipsecme-ikev2-downgrade-prevention, na kterém pracují Valery Smyslov a Christopher Patton. Osmá revize má čtrnáct stran a vyšla 1. července 2026. Návrh doplňuje RFC 7296 a v evidenci IETF je ve frontě u redakce RFC; rejstřík IANA už pro něj drží číslo oznámení 16447 s odkazem na dokument, který teprve dostane vlastní číslo.

Podstata je prostá. Když obě strany oznámení pošlou, přejdou na jiné složení podepisovaných dat: do podpisu jde vedle vlastní zprávy i ta přijatá. Před obojí se přidá osm nulových bajtů jako oddělovač, protože prvních osm bajtů každé skutečné zprávy tvoří identifikátor iniciátora, a ten nulový být nemůže – nový podpis se tak nedá zaměnit se starým.

Samotné oznámení by šlo z paketu vyškrtnout, a tím rozšíření obejít. Proti tomu stojí trik, za který Cloudflare děkuje Smyslovovi: odpovídající strana ho posílá bezpodmínečně, i když ho v dotazu nedostala. To je opak toho, jak se chová server v TLS 1.3. Vyhodí-li útočník oznámení jen z jednoho směru, jedna strana počítá podpis postaru a druhá po novu, podpisy nesednou a ověření spadne. Vyhodit ho z obou směrů znamená padělat podpis obou stran naráz.

Kde to zatím běží

Cloudflare zapnul rozšíření v beta provozu ve službách Cloudflare WAN a Magic Transit. Zákazník o ně musí požádat svůj účetní tým, který mu na účtu zapne příznak ipsec_downgrade_protection; plošně se to má zapnout po dost dlouhém testování. Firma v IKE vystupuje jako odpovídající strana.

Druhá strana je tím pádem na zbytku ekosystému a ten zatím nikam nespěchá. Seznam typů oznámení v hlavní větvi strongSwanu, tedy nejrozšířenějšího otevřeného démona IKEv2, končí v tomhle bloku hodnotou SA_RESOURCE_INFO = 16444 ze souboru notify_payload.h – číslo 16447 v něm není. Bez obou stran ochrana neplatí.

Návrh sám vymezuje, co neumí. Hlídá jen to, že se s úvodní výměnou nikdo nehrabal; pravidla, podle kterých odpovídající strana vybírá algoritmy, nemění, takže sám o sobě nedokládá, že se vybralo to nejsilnější, co obě strany umějí. A když útok opravdu zachytí, projeví se to obyčejnou chybou ověření – k nerozeznání od špatného certifikátu nebo od překlepu v konfiguraci. Provozovatel, který se na rozšíření chce spolehnout, si proto podle autorů musí nastavit pravidlo, že se spojení bez něj vůbec nenaváže.

Týmž přechodem na postkvantovou výměnu klíčů prochází i SSH, kde ho IETF letos popsal v RFC 10042.

Zdroje

• Preventing quantum downgrade attacks against IPsec, Cloudflare, 29. září 2026
• Downgrade Prevention for the Internet Key Exchange Protocol Version 2 (IKEv2), návrh IETF, revize 08 z 1. července 2026
• Downgrade Resilience in Key-Exchange Protocols, IEEE Symposium on Security and Privacy 2016
• IKEv2 Notify Message Status Types, rejstřík IANA