IKEv1 kontra IKEv2 megosztott kulccsal: miben más az azonosítás

Két átjáró, amely ugyanazzal a megosztott kulccsal van beállítva, végrehajt egy kézfogást, és a csomagrögzítés nem mutat titkot, amely átkel a vonalon. Ez az a rész, amire az emberek emlékeznek. Az érdekes rész az, hogy mit számol ki valójában az egyes verziók annak bizonyítására, hogy a titok ismert, mert az IKEv1 és az IKEv2 más bemenetekből építi ezt a bizonyítékot, és közben más információkat tár fel. Olvassa el a két nyomot egymás mellett, és a különbség megszűnik kozmetikus lenni.

Mit kell elérnie a bizonyítéknak

A Diffie-Hellman mindkét félnek ad egy közös értéket, amelynek nyilvános felét bárki kiszámíthatja, aki figyel. Önmagában ez semmit nem bizonyít az identitásról: a támadó, aki befejez egy kulcscserét, ugyanazzal a közös értékkel rendelkezik, mint az átjárója. Az azonosítási lépés azért van, hogy ezt a cserét egy olyan titokhoz kösse, amely csak a szándékolt feleknél van, valamint azokhoz az identitásokhoz és paraméterekhez, amelyekben megállapodtak.

Ez a kötés az oka annak, hogy a hash többet fed le, mint a kulcs. Ha csak a titkot fedné le, a támadó egy másik cserébe játszhatná vissza, más identitásokkal vagy javaslatokkal.

IKEv1 Main Mode: SKEYID levezetése, majd bizonyítása

A Main Mode hat üzenetet futtat. Az első pár megtárgyalja a biztonsági társítást, a második kicseréli a nyilvános Diffie-Hellman értékeket és a nonce-okat, a harmadik pedig identitásokat és azonosítási hash-eket visz a frissen létrehozott titkosítás alatt. Az RFC 2409 határozza meg a konstrukciót: megosztott kulcsos azonosításnál az SKEYID a titokból és mindkét nonce-ból származik, a későbbi kulcsanyag pedig az SKEYID-ből, a Diffie-Hellman közös értékből, a cookie-kból és konstansokból.

Az ötödik és hatodik üzenet hash-e a Diffie-Hellman érték, a két cookie, a javaslat és a küldő identitása fölött számolódik, SKEYID kulccsal. A fogadó a saját beállított titkával számolja újra. Az eltérés lezárja a cserét, és a titok soha nem maga a hasznos teher.

Az Aggressive Mode ugyanezt a munkát három üzenetbe sűríti, ami azt jelenti, hogy az identitások és az azonosítási hash még a titkosított csatorna létrejötte előtt utaznak. Ez valódi kitettség kitalálható titok esetén, és külön kérdés attól, hogy a titok átadásra került-e. Az IKEv1-et az RFC 9395 elavulttá tette, ezért egy régi nyom diagnosztikai gyakorlat, nem bevezetési cél.

IKEv2: más levezetés és más AUTH hasznos teher

Az IKEv2 nem használja újra az IKEv1 kulcsütemezését. A kezdeti IKE-kulcsok a nonce-okból és a Diffie-Hellman közös értékből épített seedből jönnek, és a gyermek biztonsági társítások ebből származnak. A megosztott kulcs egyáltalán nem táplálja a seedet.

Az azonosítás ezután AUTH hasznos teherként jelenik meg. Megosztott kulcsos azonosításhoz az RFC 7296 a titok feltöltött formáját írja elő, amelyet úgy kapunk, hogy a titkot a rögzített karakterlánccal hasheljük Key Pad for IKEv2, majd az aláírt csereadatokat és az identitást ezzel a feltöltött kulccsal hasheljük. Az ellenőrző újra tudja építeni ugyanazt az értéket; egy megfigyelő nem, a titok nélkül.

Figyelje meg, mi változott. Az IKEv1-ben a titok bele van sütve a kulcsütemezésbe, mielőtt az azonosítási hash létezne; az IKEv2-ben a kulcsütemezés független a titoktól, és a bizonyíték külön hasznos teher, amely az aláírt oktettekhez kötődik. Ugyanaz a fogalmi garancia, más gépezet, és ezért a paraméternevek és a rögzítések nem feleltethetők meg egymásnak egy az egyben.

Mit tud meg valójában egy megfigyelő

A Diffie-Hellman nyilvános értékek, a javaslatok, a nonce-ok és a cookie-k mindkét verzióban láthatók. Az identitások az IKEv1 Aggressive Mode-ban láthatók, a többi esetben védettek. A titok soha nem látható.

Ennek az utolsó mondatnak van egy határa, amit érdemes kimondani. Egy gyenge, ember által választott titok kitalálással támadható: a támadó kiszámolja, mi lenne az azonosítási érték egy jelölt titokra, és összehasonlítja. Az IKEv1 Aggressive Mode ezt teszi a legolcsóbbá, mert a bizonyíték nyílt szövegben van, és a szabványok általában óvnak az alacsony entrópiájú titkoktól. A titok soha nem elküldése nem ugyanaz, mint egy rossz titkot biztonságossá tenni.

Mit kezdjen az összehasonlítással

Használjon egy egyedi titkot minden félpárhoz, állítsa elő véletlen forrásból, és forgassa ugyanazon a telepítési úton, amely elosztotta. Ha a titok egy olyan konfigurációs sablonban van, amelyet minden fióktelepre kiküldenek, akkor az egy helyen bekövetkezett kompromittálódás mindenhol kompromittálódás.

Ahol az üzemeltetési költség elfogadható, részesítse előnyben a tanúsítványalapú azonosítást, mivel az megszünteti a megosztott titok kitalálásának problémáját, és minden félnek külön identitást ad. Ahol megosztott kulcs marad, tartsa hosszúnak, szűkítse a hatókörét, és tekintse az IKE-verziót biztonsági döntésnek, nem interoperabilitási részletnek.