IKEv1 ir IKEv2 su iš anksto bendru raktu: kuo skiriasi autentifikavimas

Du šliuzai su tuo pačiu iš anksto bendru raktu atlieka rankos paspaudimą, o paketų įrašas nerodo jokios paslapties, kertančios laidą. Tai dalis, kurią žmonės atsimena. Įdomioji dalis yra tai, ką kiekviena versija iš tikrųjų apskaičiuoja, kad įrodytų, jog paslaptis žinoma, nes IKEv1 ir IKEv2 stato tą įrodymą iš skirtingų duomenų ir tai darydamos atskleidžia skirtingą informaciją. Perskaitykite abu pėdsakus greta ir skirtumas nustoja būti kosmetinis.

Ką įrodymas turi pasiekti

Diffie-Hellman suteikia abiem pusėms bendrą reikšmę, kurios viešąsias puses gali apskaičiuoti ir bet kuris stebėtojas. Pati savaime tai nieko neįrodo apie tapatybę: užpuolikas, užbaigęs raktų mainus, turi tą pačią bendrą reikšmę kaip ir jūsų šliuzas. Autentifikavimo žingsnis egzistuoja tam, kad susietų tuos mainus su paslaptimi, kurią turi tik numatytosios pusės, ir su tapatybėmis bei parametrais, dėl kurių jos susitarė.

Būtent šis susiejimas yra priežastis, kodėl maiša apima daugiau nei raktą. Jei ji apimtų tik paslaptį, užpuolikas galėtų ją atkartoti kituose mainuose su kitomis tapatybėmis ar pasiūlymais.

IKEv1 Main Mode: išvesti SKEYID ir tada jį įrodyti

Main Mode atlieka šešis pranešimus. Pirmoji pora derasi dėl saugumo asociacijos, antroji keičiasi viešosiomis Diffie-Hellman reikšmėmis ir nonce reikšmėmis, o trečioji neša tapatybes ir autentifikavimo maišas po ką tik nustatyto šifravimo. RFC 2409 apibrėžia konstrukciją: autentifikuojant iš anksto bendru raktu, SKEYID išvedamas iš paslapties ir abiejų nonce reikšmių, o vėlesnė raktų medžiaga iš SKEYID, Diffie-Hellman bendros reikšmės, slapukų ir konstantų.

Maiša penktame ir šeštame pranešimuose skaičiuojama pagal Diffie-Hellman reikšmę, du slapukus, pasiūlymą ir siuntėjo tapatybę, naudojant SKEYID kaip raktą. Gavėjas perskaičiuoja ją su savo sukonfigūruota paslaptimi. Nesutapimas nutraukia mainus, ir paslaptis niekada nėra naudingoji apkrova.

Aggressive Mode sutalpina tą patį darbą į tris pranešimus, o tai reiškia, kad tapatybės ir autentifikavimo maiša keliauja dar prieš atsirandant šifruotam kanalui. Tai realus pavojus, kai paslaptį galima atspėti, ir tai atskiras klausimas nuo to, ar paslaptis buvo perduota. IKEv1 yra nerekomenduojamas pagal RFC 9395, todėl senas pėdsakas yra diagnostikos pratimas, o ne diegimo tikslas.

IKEv2: kita išvedimo schema ir kita AUTH naudingoji apkrova

IKEv2 nepakartoja IKEv1 raktų tvarkaraščio. Pradiniai IKE raktai gaunami iš sėklos, sudarytos iš nonce reikšmių ir Diffie-Hellman bendros reikšmės, o antrinės saugumo asociacijos išvedamos iš jos. Iš anksto bendras raktas visiškai nepatenka į sėklą.

Tada autentifikavimas pasirodo kaip AUTH naudingoji apkrova. Bendro rakto autentifikavimui RFC 7296 numato papildytą paslapties formą, gaunamą maišuojant paslaptį su fiksuota eilute Key Pad for IKEv2, o tada maišuojant pasirašytus mainų duomenis ir tapatybę su tuo papildytu raktu. Tikrintojas gali atkurti tą pačią reikšmę; stebėtojas negali, be paslapties.

Atkreipkite dėmesį, kas pasikeitė. IKEv1 atveju paslaptis įkepama į raktų tvarkaraštį prieš atsirandant autentifikavimo maišai; IKEv2 atveju raktų tvarkaraštis nepriklauso nuo paslapties, o įrodymas yra atskira naudingoji apkrova, susieta su pasirašytais oktetais. Ta pati konceptuali garantija, kita mechanika, ir todėl parametrų pavadinimai bei įrašai nesutampa vienas su vienu.

Ką stebėtojas iš tikrųjų sužino

Diffie-Hellman viešosios reikšmės, pasiūlymai, nonce reikšmės ir slapukai matomi abiejose versijose. Tapatybės matomos IKEv1 Aggressive Mode atveju ir apsaugotos kitais atvejais. Paslaptis niekada nematoma.

Paskutinis sakinys turi ribą, kurią verta įvardyti. Silpną, žmogaus pasirinktą paslaptį galima atakuoti spėjant: užpuolikas apskaičiuoja, kokia būtų autentifikavimo reikšmė kandidatinei paslapčiai, ir palygina. IKEv1 Aggressive Mode tai daro pigiausia, nes įrodymas yra atvirame tekste, o standartai apskritai įspėja dėl mažos entropijos paslapčių. Niekada neperduoti paslapties nėra tas pats, kas padaryti blogą paslaptį saugią.

Ką daryti su palyginimu

Naudokite vieną unikalią paslaptį kiekvienai pusių porai, generuokite ją iš atsitiktinio šaltinio ir keiskite tuo pačiu parengimo keliu, kuris ją paskirstė. Jei paslaptis saugoma konfigūracijos šablone, kuris siunčiamas į kiekvieną filialą, kompromisas vienoje vietoje yra kompromisas visur.

Pirmenybę teikite autentifikavimui sertifikatais, kur eksploatacinės išlaidos priimtinos, nes jis pašalina bendros paslapties spėjimo problemą ir suteikia kiekvienai pusei atskirą tapatybę. Kur iš anksto bendras raktas lieka, laikykite jį ilgą, siaurai apibrėžkite ir vertinkite IKE versiją kaip saugumo sprendimą, o ne sąveikos detales.