IKEv1 față de IKEv2 cu cheie prepartajată: ce diferă la autentificare

Două gateway-uri configurate cu aceeași cheie prepartajată încheie un handshake, iar o captură de pachete nu arată niciun secret care traversează legătura. Aceasta este partea de care oamenii își amintesc. Partea interesantă este ce calculează de fapt fiecare versiune pentru a dovedi că secretul este cunoscut, pentru că IKEv1 și IKEv2 construiesc acea dovadă din intrări diferite și expun informații diferite în timp ce o fac. Citiți cele două urme alături și diferența încetează să mai fie cosmetică.

Ce trebuie să realizeze dovada

Diffie-Hellman le dă ambelor părți o valoare comună ale cărei jumătăți publice pot fi calculate și de oricine urmărește. Prin sine, asta nu dovedește nimic despre identitate: un atacator care încheie un schimb de chei are aceeași valoare comună ca gateway-ul dumneavoastră. Pasul de autentificare există pentru a lega acel schimb de un secret pe care îl au doar părțile vizate, și de identitățile și parametrii asupra cărora s-au înțeles.

Această legare este motivul pentru care hash-ul acoperă mai mult decât cheia. Dacă ar acoperi doar secretul, un atacator l-ar putea reda într-un alt schimb, cu alte identități sau propuneri.

IKEv1 în Main Mode: se derivă SKEYID, apoi se dovedește

Main Mode rulează șase mesaje. Prima pereche negociază asocierea de securitate, a doua schimbă valorile publice Diffie-Hellman și nonce-urile, iar a treia duce identități plus hash-uri de autentificare sub criptarea abia stabilită. RFC 2409 definește construcția: la autentificarea cu cheie prepartajată, SKEYID se derivă din secret și din ambele nonce-uri, iar materialul de cheie ulterior din SKEYID, valoarea comună Diffie-Hellman, cookie-uri și constante.

Hash-ul din mesajele cinci și șase se calculează peste valoarea Diffie-Hellman, cele două cookie-uri, propunere și identitatea expeditorului, cu SKEYID ca cheie. Receptorul îl recalculează cu propriul secret configurat. O nepotrivire încheie schimbul, iar secretul nu este niciodată un payload.

Aggressive Mode comprimă aceeași muncă în trei mesaje, ceea ce înseamnă că identitățile și hash-ul de autentificare călătoresc înainte să existe un canal criptat. Aceasta este o expunere reală pentru un secret ușor de ghicit și este o chestiune separată de aceea dacă secretul a fost transmis. IKEv1 este depreciat de RFC 9395, așa că o urmă veche este un exercițiu de diagnostic, nu o țintă de implementare.

IKEv2: altă derivare și alt payload AUTH

IKEv2 nu refolosește schema de chei din IKEv1. Cheile IKE inițiale provin dintr-o sămânță construită din nonce-uri și valoarea comună Diffie-Hellman, iar asocierile de securitate copil derivă din ea. Cheia prepartajată nu alimentează deloc sămânța.

Autentificarea apare apoi ca payload AUTH. Pentru autentificarea cu cheie comună, RFC 7296 specifică o formă umplută a secretului, obținută prin hash-ul secretului cu șirul fix Key Pad for IKEv2, apoi prin hash-ul datelor de schimb semnate și al identității cu acea cheie umplută. Verificatorul poate reconstrui aceeași valoare; un observator nu poate, fără secret.

Observați ce s-a schimbat. În IKEv1 secretul este turnat în schema de chei înainte ca hash-ul de autentificare să existe; în IKEv2 schema de chei este independentă de secret, iar dovada este un payload distinct legat de octeții semnați. Aceeași garanție conceptuală, altă mașinărie, și de aceea numele parametrilor și capturile nu se potrivesc unu la unu.

Ce află de fapt un observator

Valorile publice Diffie-Hellman, propunerile, nonce-urile și cookie-urile sunt vizibile în ambele versiuni. Identitățile sunt vizibile în IKEv1 Aggressive Mode și protejate în celelalte cazuri. Secretul nu este niciodată vizibil.

Ultima propoziție are o limită care merită spusă. Un secret slab, ales de om, poate fi atacat prin ghicire: atacatorul calculează care ar fi valoarea de autentificare pentru un secret candidat și compară. IKEv1 Aggressive Mode face asta cel mai ieftin pentru că dovada este în clar, iar standardele avertizează în general asupra secretelor cu entropie mică. A nu transmite niciodată secretul nu este același lucru cu a face un secret prost sigur.

Ce faceți cu comparația

Folosiți un secret unic pentru fiecare pereche de părți, generați-l dintr-o sursă aleatoare și rotiți-l pe aceeași cale de provisionare care l-a distribuit. Dacă secretul stă într-un șablon de configurare care pleacă la fiecare sucursală, un compromis într-un singur loc este un compromis peste tot.

Preferați autentificarea bazată pe certificate acolo unde costul operațional este acceptabil, pentru că elimină problema ghicirii secretului comun și dă fiecărei părți o identitate distinctă. Acolo unde o cheie prepartajată rămâne, țineți-o lungă, limitați-i domeniul și tratați versiunea IKE ca decizie de securitate, nu ca detaliu de interoperabilitate.