IKEv1 срещу IKEv2: удостоверяване с предварително споделен ключ и какво се различава

Два шлюза, конфигурирани с един и същ предварително споделен ключ, завършват ръкостискане и прихващането на пакети не показва тайна, която да пресича мрежата. Това е частта, която хората запомнят. Интересната част е какво всъщност изчислява всяка версия, за да докаже, че тайната е известна, защото IKEv1 и IKEv2 изграждат това доказателство от различни входни данни и разкриват различна информация, докато го правят. Прочетете двете следи една до друга и разликата престава да бъде козметична.

Какво трябва да постигне доказателството

Дифи-Хелман дава на двамата партньори обща стойност, чиито публични половини може да изчисли и всеки наблюдател. Само по себе си това не доказва нищо за самоличността: нападател, който завърши обмен на ключове, има същата обща стойност като вашия шлюз. Стъпката на удостоверяване съществува, за да обвърже този обмен с тайна, която само предвидените партньори притежават, и със самоличностите и параметрите, за които са се споразумели.

Точно това обвързване е причината хешът да покрива повече от ключа. Ако покриваше само тайната, нападател би могъл да я възпроизведе в различен обмен с различни самоличности или предложения.

IKEv1, основен режим: извеждане на SKEYID и след това доказване

Основен режим изпълнява шест съобщения. Първата двойка договаря асоциацията за сигурност, втората разменя публични стойности на Дифи-Хелман и случайни числа, а третата носи самоличности плюс хешове за удостоверяване под току-що установеното криптиране. RFC 2409 дефинира конструкцията: при удостоверяване с предварително споделен ключ SKEYID се извежда от тайната и от двете случайни числа, а по-късният ключов материал се извежда от SKEYID, общата стойност на Дифи-Хелман, бисквитките и константите.

Хешът в петото и шестото съобщение се изчислява върху стойността на Дифи-Хелман, двете бисквитки, предложението и самоличността на подателя, с ключ SKEYID. Получателят го преизчислява със своята конфигурирана тайна. Несъответствието прекратява обмена и в нито един момент тайната не е полезен товар.

Агресивен режим компресира същата работа в три съобщения, което означава, че самоличностите и хешът за удостоверяване пътуват, преди да съществува криптиран канал. Това е реално излагане за тайна, която може да бъде отгатната, и е отделно от въпроса дали тайната е била предадена. IKEv1 е обявен за остарял с RFC 9395, така че наследена следа е диагностично упражнение, а не цел за внедряване.

IKEv2: различно извеждане и различен полезен товар AUTH

IKEv2 не използва повторно ключовия график на IKEv1. Първоначалните IKE ключове идват от семе, изградено от случайните числа и общата стойност на Дифи-Хелман, а дъщерните асоциации за сигурност се извеждат от него. Предварително споделеният ключ изобщо не захранва семето.

След това удостоверяването се появява като полезен товар AUTH. За удостоверяване със споделен ключ RFC 7296 определя подплатена форма на тайната, получена чрез хеширане на тайната с фиксирания низ Key Pad for IKEv2, и след това хеширане на подписаните данни за обмена и самоличността с този подплатен ключ. Проверяващият може да възстанови същата стойност; наблюдател не може, без тайната.

Забележете какво се промени. При IKEv1 тайната е вградена в ключовия график, преди хешът за удостоверяване да съществува; при IKEv2 ключовият график е независим от тайната и доказателството е отделен полезен товар, обвързан с подписаните октети. Същата концептуална гаранция, различна машина и затова имената на параметрите и прихващанията не се съпоставят едно към едно.

Какво всъщност научава наблюдателят

Публичните стойности на Дифи-Хелман, предложенията, случайните числа и бисквитките са видими и в двете версии. Самоличностите са видими в агресивен режим IKEv1 и защитени в останалите случаи. Тайната никога не е видима.

Последното изречение има граница, която си струва да се посочи. Слаба тайна, избрана от човек, може да бъде атакувана чрез отгатване: нападателят изчислява каква би била стойността за удостоверяване за кандидат-тайна и сравнява. агресивен режим IKEv1 прави това най-евтино, защото доказателството е на открито, а стандартите предупреждават за тайни с ниска ентропия като цяло. Никога да не се предава тайната не е същото като да се направи лоша тайна безопасна.

Какво да правим със сравнението

Използвайте една уникална тайна за всяка двойка партньори, генерирайте я от случаен източник и я сменяйте през същия път за предоставяне, който я е разпространил. Ако тайната се съхранява в шаблон за конфигурация, който се изпраща до всеки клон, компрометиране на едно място е компрометиране навсякъде.

Предпочитайте удостоверяване, базирано на сертификати, където оперативните разходи са приемливи, тъй като то премахва проблема с отгатването на споделената тайна и дава на всеки партньор отделна самоличност. Където предварително споделен ключ остава, дръжте го дълъг, ограничете обхвата му и третирайте версията на IKE като решение за сигурност, а не като подробност за съвместимост.