IKEv1 versus IKEv2: autentizace předem sdíleným klíčem a co se liší

Dvě brány nakonfigurované se stejným předem sdíleným klíčem dokončí handshake a zachycení paketů neukazuje, že by po drátě přecházelo tajemství. To je část, kterou si lidé pamatují. Zajímavá část je, co každá verze skutečně počítá, aby prokázala znalost tajemství, protože IKEv1 a IKEv2 staví tento důkaz z různých vstupů a přitom odhalují různé informace. Přečtěte si obě stopy vedle sebe a rozdíl přestane být kosmetický.

Co má důkaz dokázat

Diffie-Hellman dává oběma protějškům sdílenou hodnotu, jejíž veřejné poloviny může spočítat i kdokoli, kdo se dívá. Samo o sobě to nic neprokazuje o identitě: útočník, který dokončí výměnu klíčů, má stejnou sdílenou hodnotu jako vaše brána. Krok autentizace existuje proto, aby tuto výměnu svázal s tajemstvím, které mají jen zamýšlené protějšky, a s identitami a parametry, na nichž se dohodly.

Právě toto svázání je důvod, proč hash pokrývá víc než klíč. Kdyby pokrýval jen tajemství, mohl by ho útočník přehrát do jiné výměny s jinými identitami nebo návrhy.

IKEv1 Main Mode: odvodit SKEYID a pak ho prokázat

Main Mode probíhá v šesti zprávách. První dvojice vyjednává bezpečnostní asociaci, druhá si vyměňuje veřejné hodnoty Diffie-Hellman a nonce a třetí nese identity a autentizační hashe pod šifrováním, které právě vzniklo. RFC 2409 definuje konstrukci: při autentizaci předem sdíleným klíčem se SKEYID odvozuje z tajemství a obou nonců a pozdější klíčový materiál se odvozuje ze SKEYID, sdílené hodnoty Diffie-Hellman, cookies a konstant.

Hash v páté a šesté zprávě se počítá přes hodnotu Diffie-Hellman, obě cookies, návrh a identitu odesílatele, s klíčem SKEYID. Příjemce ho přepočítá se svým nakonfigurovaným tajemstvím. Neshoda ukončí výměnu a tajemství samo nikdy není užitečným zatížením.

Aggressive Mode stlačuje stejnou práci do tří zpráv, což znamená, že identity a autentizační hash cestují dřív, než existuje šifrovaný kanál. To je skutečné vystavení pro uhodnutelné tajemství a je to oddělené od otázky, zda bylo tajemství přeneseno. IKEv1 je označen za zastaralý v RFC 9395, takže starší stopa je diagnostické cvičení, nikoli cíl nasazení.

IKEv2: jiné odvození a jiné zatížení AUTH

IKEv2 znovu nepoužívá plán klíčů IKEv1. Počáteční klíče IKE pocházejí ze semene postaveného z nonců a sdílené hodnoty Diffie-Hellman a podřízené bezpečnostní asociace se z něj odvozují. Předem sdílený klíč semeno vůbec nekrmí.

Autentizace se pak objeví jako zatížení AUTH. Pro autentizaci sdíleným klíčem RFC 7296 předepisuje doplněnou podobu tajemství, vzniklou hashováním tajemství s pevným řetězcem Key Pad for IKEv2, a poté hashováním podepsaných dat výměny a identity tímto doplněným klíčem. Ověřovatel může stejnou hodnotu znovu sestavit; pozorovatel to bez tajemství nedokáže.

Všimněte si, co se změnilo. V IKEv1 je tajemství zapečeno do plánu klíčů dřív, než autentizační hash existuje; v IKEv2 je plán klíčů na tajemství nezávislý a důkaz je samostatné zatížení svázané s podepsanými oktety. Stejná koncepční záruka, jiný stroj, a proto se názvy parametrů a zachycení neshodují jedna k jedné.

Co se pozorovatel skutečně dozví

Veřejné hodnoty Diffie-Hellman, návrhy, nonce a cookies jsou viditelné v obou verzích. Identity jsou viditelné v IKEv1 Aggressive Mode a v ostatních případech chráněné. Tajemství není nikdy viditelné.

Poslední věta má hranici, kterou stojí za to uvést. Slabé tajemství zvolené člověkem lze napadnout hádáním: útočník spočítá, jaká by byla autentizační hodnota pro kandidáta na tajemství, a porovná. IKEv1 Aggressive Mode to dělá nejlevnějším, protože důkazy jsou na očích, a standardy obecně varují před tajemstvími s nízkou entropií. Nikdy nepřenášet tajemství není totéž jako udělat špatné tajemství bezpečným.

Co s tím srovnáním dělat

Používejte jedno jedinečné tajemství pro každou dvojici protějšků, generujte ho z náhodného zdroje a obměňujte ho stejnou cestou zřizování, která ho distribuovala. Pokud je tajemství uloženo v konfigurační šabloně, která se posílá do každé pobočky, kompromitace na jednom místě je kompromitace všude.

Upřednostněte autentizaci založenou na certifikátech tam, kde jsou provozní náklady přijatelné, protože odstraňuje problém hádání sdíleného tajemství a dává každému protějšku jedinečnou identitu. Tam, kde předem sdílený klíč zůstává, držte ho dlouhý, zužte jeho rozsah a berte verzi IKE jako bezpečnostní rozhodnutí, nikoli jako detail interoperability.