IKEv1 verzus IKEv2 s vopred zdieľaným kľúčom: čím sa autentifikácia líši

Dve brány nastavené s rovnakým vopred zdieľaným kľúčom dokončia handshake a záznam paketov neukazuje žiadne tajomstvo prechádzajúce po linke. To je časť, ktorú si ľudia pamätajú. Zaujímavá časť je to, čo každá verzia skutočne vypočíta, aby dokázala, že tajomstvo pozná, pretože IKEv1 a IKEv2 stavajú tento dôkaz z rôznych vstupov a pri tom odhaľujú rôzne informácie. Prečítajte si obe stopy vedľa seba a rozdiel prestane byť kozmetický.

Čo musí dôkaz dosiahnuť

Diffie-Hellman dáva obom stranám spoločnú hodnotu, ktorej verejné polovice dokáže vypočítať aj ktokoľvek, kto sa pozerá. Samo o sebe to o identite nič nedokazuje: útočník, ktorý dokončí výmenu kľúčov, má rovnakú spoločnú hodnotu ako vaša brána. Krok autentifikácie existuje preto, aby výmenu zviazal s tajomstvom, ktoré majú len zamýšľané strany, a s identitami a parametrami, na ktorých sa dohodli.

Práve toto zviazanie je dôvod, prečo hash pokrýva viac než kľúč. Keby pokrýval iba tajomstvo, útočník by ho mohol prehrať do inej výmeny s inými identitami alebo návrhmi.

IKEv1 Main Mode: odvodiť SKEYID a potom ho dokázať

Main Mode vykoná šesť správ. Prvý pár vyjedná bezpečnostnú asociáciu, druhý si vymení verejné hodnoty Diffie-Hellman a nonce, a tretí nesie identity a autentifikačné hashe pod šifrovaním, ktoré sa práve vytvorilo. RFC 2409 definuje konštrukciu: pri autentifikácii vopred zdieľaným kľúčom sa SKEYID odvodí z tajomstva a oboch nonce a neskorší kľúčový materiál z SKEYID, spoločnej hodnoty Diffie-Hellman, cookies a konštánt.

Hash v piatej a šiestej správe sa počíta cez hodnotu Diffie-Hellman, obe cookies, návrh a identitu odosielateľa, s SKEYID ako kľúčom. Príjemca ho prepočíta so svojím nastaveným tajomstvom. Nezhoda ukončí výmenu a tajomstvo samo nikdy nie je payload.

Aggressive Mode stláča tú istú prácu do troch správ, čo znamená, že identity a autentifikačný hash cestujú skôr, než existuje šifrovaný kanál. To je skutočné vystavenie pri uhádnuteľnom tajomstve a je to oddelené od otázky, či bolo tajomstvo prenesené. IKEv1 je podľa RFC 9395 zastaraný, takže stará stopa je diagnostické cvičenie, nie cieľ nasadenia.

IKEv2: iné odvodenie a iný AUTH payload

IKEv2 nepoužíva kľúčový plán IKEv1. Počiatočné kľúče IKE pochádzajú zo seedu zloženého z nonce a spoločnej hodnoty Diffie-Hellman a podriadené bezpečnostné asociácie sa odvodzujú z neho. Vopred zdieľaný kľúč do seedu nevstupuje vôbec.

Autentifikácia sa potom objaví ako AUTH payload. Pre autentifikáciu zdieľaným kľúčom RFC 7296 predpisuje doplnenú formu tajomstva, vytvorenú hashovaním tajomstva s pevným reťazcom Key Pad for IKEv2, a potom hashovaním podpísaných výmenných dát a identity týmto doplneným kľúčom. Overovateľ dokáže tú istú hodnotu znovu zostaviť; pozorovateľ nie, bez tajomstva.

Všimnite si, čo sa zmenilo. V IKEv1 je tajomstvo zapečené do kľúčového plánu skôr, než autentifikačný hash existuje; v IKEv2 je kľúčový plán nezávislý od tajomstva a dôkaz je samostatný payload naviazaný na podpísané oktety. Rovnaká koncepčná záruka, iný stroj, a preto sa názvy parametrov a záznamy nemapujú jedna k jednej.

Čo sa pozorovateľ skutočne dozvie

Verejné hodnoty Diffie-Hellman, návrhy, nonce a cookies sú viditeľné v oboch verziách. Identity sú viditeľné v IKEv1 Aggressive Mode a v ostatných prípadoch chránené. Tajomstvo nie je nikdy viditeľné.

Posledná veta má hranicu, ktorú stojí za to uviesť. Slabé, človekom zvolené tajomstvo sa dá napadnúť hádaním: útočník vypočíta, aká by bola autentifikačná hodnota pre kandidátske tajomstvo, a porovná. IKEv1 Aggressive Mode to robí najlacnejším, pretože dôkaz je v otvorenom texte, a štandardy vo všeobecnosti varujú pred tajomstvami s nízkou entropiou. Nikdy neposlať tajomstvo nie je to isté ako urobiť zlé tajomstvo bezpečným.

Čo robiť s porovnaním

Používajte jedno jedinečné tajomstvo na každú dvojicu strán, generujte ho z náhodného zdroja a rotujte ho tou istou provisioningovou cestou, ktorá ho distribuovala. Ak je tajomstvo v konfiguračnej šablóne, ktorá sa posiela do každej pobočky, kompromis na jednom mieste je kompromis všade.

Uprednostnite autentifikáciu založenú na certifikátoch tam, kde sú prevádzkové náklady prijateľné, pretože odstraňuje problém hádania zdieľaného tajomstva a dáva každej strane jedinečnú identitu. Kde vopred zdieľaný kľúč zostáva, držte ho dlhý, obmedzte jeho rozsah a berte verziu IKE ako bezpečnostné rozhodnutie, nie ako detail interoperability.