Я робив IPsec VPN на ASA 8.0, і я трохи розумію про це. Ініціатор починається з надсилання своєї політики ISAKMP респонденту, а відповідь відправляє назад відповідну політику. Після цього ключ Diffie-Hellman отримує обмін, а потім обидва відправляють попередньо спільний ключ іншому для аутентифікації.
Зараз у нас є два ключі:
Який ключ використовується для шифрування загальнодоступного ключа?
Відповіді:
Ви задали чудове запитання. Питання здається дуже простим, але насправді відповідь дещо складніша. Я зроблю все можливе, щоб відповісти на це лаконічно. Крім того, оскільки ви згадали про ISAKMP, я припускаю, що вас цікавить IKEv1. Речі дещо змінюються для IKEv2 (ну, багато), але я хотів би згадати відповідь нижче лише стосується IKEv1.
Фаза 1 може бути виконана у двох різних режимах: Основному та Агресивному режимі. В будь-якому режимі перше повідомлення надсилається Ініціатором, а друге повідомлення - Відповідачем. Обидва ці повідомлення включають те, що в світі криптографії відомо як Нонсе . Nonce - це просто випадковим чином згенероване число, яке використовується для генерації ключів. (термін Nonce походить від _N_umber, що використовується _Once_) . Отже, після повідомлення 1 і повідомлення 2, обидві сторони знають нестосунків один одного.
Nonce's поєднуються з Pre-Shared-Key, щоб створити значення Seed для генерації секретних ключів. Відносна частина IKE RFC тут:
For pre-shared keys: SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
SKEYID - це значення Seed, яке згодом буде використано для створення додаткових секретних ключів. Попередній загальний ключ і обидва значення Nonce (Ni_b - це неприйняття ініціатора, а Nr_B - неприйняття відповіді) поєднуються за допомогою функції PRF або випадкової функції Psuedo. PRF - це як алгоритм хешування, за винятком того, що результат може бути стільки бітів, скільки вам потрібно.
Тепер, якщо ви спочатку виконували головний режим, повідомлення 3 та 4 діляться відкритими ключами ініціатора та відповідача (відповідно) Diffie-Hellman. Вони обидва використовують ці значення для створення загальної таємниці Діффі-Гелмана . Якщо ви працювали в агресивному режимі, ці загальнодоступні значення DH також включаються до Повідомлення 1 та Повідомлення 2 (разом з "Нонс").
Значення Seed потім комбінується з DH Shared Secret (та кількома іншими значеннями) для створення трьох ключів сеансу : ключ відновлювальний, ключ автентифікації та ключ шифрування. RFC констатує це як таке:
Результатом головного або агресивного режиму є три групи автентифікованих матеріалів клавіатури:
SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)
SKEYID_d, _a та _e - це три ключі сесії, згадані вище. SKEYID- значення насіння. g^xyє загальним секретом DH. CKY-Iі CKI-Rє файлами cookie ініціатора та відповідача, це лише додаткові генеровані випадковим чином значення, які пізніше використовуються для ідентифікації цієї конкретної асоціації обміну та безпеки ISAKMP. 0 1 2є буквальними числами 0, 1 і 2. Символ Труби |являє собою конкатенацію.
У будь-якому випадку всі ці значення об'єднані разом за допомогою PRF, який створює три клавіші сесії:
Ключ аутентифікації та ключ шифрування використовуються для захисту / шифрування наступних узгоджених фаз2. У головному режимі повідомлення 5 та 6 Phase1 також захищені цими клавішами. Крім того, ці майбутні інформаційні обміни ISAKMP (DPD, події Rekey, Видалити повідомлення тощо) також захищені цими двома ключами.
Похідний ключ передається IPsec, а IPsec генерує власний зберігаючий матеріал із цього ключа. Якщо ви пам’ятаєте, IPsec не містить внутрішньо механізм обміну ключами, тому єдиний спосіб придбати секретні ключі - це встановити їх вручну (що є архаїчним і ніколи справді більше не робиться), АБО залежати від зовнішньої служби для надавати ключовий матеріал, як ISAKMP.
RFC каже, що так:
SKEYID_e - це ключовий матеріал, який ISAKMP SA використовує для захисту конфіденційності своїх повідомлень.
SKEYID_a - це ключовий матеріал, який ISAKMP SA використовує для автентифікації своїх повідомлень.
SKEYID_d - це ключ-матеріал, який використовується для отримання ключів для асоціацій безпеки, які не є ISAKMP.
З урахуванням сказаного, ми можемо повернутися до вашого питання: Який ключ використовується для захисту попереднього спільного ключа?
У головному режимі попередньо розділений ключ (PSK) перевіряється у Повідомленнях 5 та 6. Повідомлення 5 та 6 захищені ключами сеансу, згенерованими ISAKMP, описаними вище.
В агресивному режимі жодне повідомлення в процесі переговорів не шифрується. І PSK перевіряється в Повідомленнях 2 та 3. Помітьте, я сказав, що в обох випадках PSK перевірено , і я ніколи не сказав, що PSK обмінюється . Очевидно, що якщо в Агресивному режимі нічого не зашифровано, і ви просто надіслали попередньо спільний ключ через провід незашифрованим, виникне величезна вразливість вразливості безпеки.
Пощастило нам, письменники ІСАКМП вже про це думали. І як результат, вони створили спеціальний метод для перевірки наявності у кожної сторони правильного PSK, фактично не ділившись ним по всьому проводу. Існує два пункти, які використовуються для перевірки для кожного партнера щодо того, що вони обидва мають однаковий PSK: метод ідентичності та хеш ідентичності .
VPN Peers можуть вибрати ідентифікацію себе різними методами; найчастіше однолітки просто використовуватимуть свою вихідну IP-адресу. Але у них є можливість використовувати FQDN або Hostname. Кожен із них, поряд із співвідношенням для обраного методу, є тим, що складає метод ідентичності. Так, наприклад, якби у мене був IP 5.5.5.5 і я хотів використовувати свою IP-адресу для ідентифікації себе, метод мого ідентифікатора фактично був би [IP Address, 5.5.5.5] . (Примітка: значення BOTH складають весь метод ідентифікації)
Потім метод ID поєднується (використовуючи PRF) зі значенням Seed, про яке ми говорили раніше (SKEYID), та кількома іншими значеннями, щоб створити Hash Identity . Нагадаємо, що в першу чергу входило в створення SKEYID - Pre-Shared-Key.
Потім метод ID та Hash ID надсилаються по всій лінії зв'язку, а інша сторона намагається знову створити Hash ID, використовуючи ту ж формулу. Якщо одержувач може знову створити той самий Hash ID, він доводить одержувачеві, що відправник повинен мати правильний ключ загального доступу.
Це описано в RFC тут:
Для аутентифікації або обміну ініціатор протоколу генерує HASH_I, і респондент генерує HASH_R де:
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b ) HASH_R = prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b )
IDii та IDir - метод ідентифікації. І HASH_I і HASH_R є хешами ініціатора та відповідача. І те й інше ділиться у Фазі1. Від RFC:
Під час аутентифікації за допомогою загального доступу до основного режиму визначається наступний спосіб:
Initiator Responder ---------- ----------- HDR, SA --> <-- HDR, SA HDR, KE, Ni --> <-- HDR, KE, Nr HDR*, IDii, HASH_I --> <-- HDR*, IDir, HASH_RАгресивний режим із загальнодоступною клавішею описується так:
Initiator Responder ----------- ----------- HDR, SA, KE, Ni, IDii --> <-- HDR, SA, KE, Nr, IDir, HASH_R HDR, HASH_I -->
І тепер ми можемо нарешті повністю відповісти на ваше запитання:
Попередньо розділений ключ поєднується за допомогою PRF з Nonces та низкою інших цінностей, відомих будь-кому іншому в ході переговорів. Результат - це значення, яке можуть досягти взаємно дві сторони, лише якщо обидві сторони почали з однакових значень - ака, однакового попереднього спільного ключа. Отримане значення - це те, що ділиться на дроті, і дозволяє двом сторонам перевірити, чи відповідають вони попередньо спільні ключі, фактично не піддаючи ніякої інформації про сам попередньо розділений ключ.
Основний режим стає на крок більш безпечним, також шифруючи обмін описаного вище "результуючого значення", що робить ще складніше витягнути будь-яку корисну інформацію про те, що було попередньо поділеним ключем.
(здається, я не зуміла відповісти на це лаконічно)
Ваша відповідь полягає у вашому запитанні: біржа Diffie-Hellman використовується для створення загального ключа для надійного обміну загальним ключем (тобто попереднього доступу).
Дивіться це: /security/67953/understanding-diffie-hellman-key-exchange