Internet Key Exchange
Протоколи безпеки Інтернет |
---|
Керування ключами |
|
Рівень застосувань |
|
Система доменних імен |
|
Рівень Інтернет |
|
|
IKE (англ. Internet Key Exchange) — стандартний протокол набору протоколів IPsec, який використовується для забезпечення безпеки взаємодії в віртуальних приватних мережах. Призначення IKE — захищене узгодження і доставка ідентифікованого матеріалу для «асоціації безпеки» (SA)
Історія
IKE був спочатку визначений у листопаді 1998 року в серії рекомендацій RFC 2407, RFC 2408, RFC 2409.
У грудні 2005 р вийшла друга версія IKEv2, яка була описана в рекомендації RFC 4306.
У жовтні 2014 року в редакції RFC 7296 вийшла виправлена версія стандарту, що описує IKEv2.
Архітектура
Протокол передає повідомлення через UDP — порти 500 і/ або 4500. Встановлена SA включає в себе роздільний секретний ключ і набір криптографічних алгоритмів. Також IKE може використовувати компресію IP.
Обмін інформацією здійснюється парними повідомленнями «запит — відповідь». Такі пари називаються «обмін» («exchange»).
Обмін даними в IKE відбувається в 2 фази. У першій фазі встановлюється SA IKE. У другій — SA IKE використовується для узгодження протоколу (зазвичай IPSec)[1].
Визначення
SKEYID — рядок, що отримується з секретного ключа, відомого тільки учасникам обміну.
SKEYID_e — матеріал ключів, який використовується SA ISAKMP для захисту конфіденційності своїх повідомлень.
SKEYID_a — матеріал ключів, який використовується SA ISAKMP для ідентифікації своїх повідомлень.
SKEYID_d — матеріал ключів, який використовується при отриманні ключів для SA, що не відносяться до ISAKMP
Nx — дані поточного часу (x може бути i або r в разі ініціатора або отримувача відповідно)
prf (key, msg) — функція псевдовипадкових чисел з ключем (pseudo-random function). Часто використовується хеш-функція.
g^xy — розділяється секретний код Діффі-Геллмана.
CKY_x — cookies ініціатора (якщо x == I) або одержувача (якщо x == R) з заголовка ISAKMP
HDR — заголовок ISAKMP. Його поле типу обміну визначає режим. Якщо пишеться HDR*, то дані зашифровані.
SA — дані узгоджені, які містять одну або кілька пропозицій. Ініціатор може відправити кілька пропозицій, але відповідач зобов'язаний відповісти тільки одним реченням.
IDx — дані ідентифікації для x. У разі, якщо x==ii, то це дані ініціатора в першій фазі, якщо x==ir, то це дані відповідача в першій фазі, якщо x==ui, то це дані ініціатора в другій фазі, якщо x==ur, то це дані відповідача в другій фазі.
CERT — дані сертифікації.
SIG_X — дані підпису ініціатора або відповідача в разі X==I або X==R відповідно.
KE — дані обміну ключами, які містять відкриту інформацію, передану в процесі обміну Діффі-Геллмана.
HASH (X) — дані хеш-коду.
<X>_b — тіло даних X.
<х>y — x зашифрований ключем y.
X|Y — конкатенація X і Y[1].
Фаза 1
Для першої фази можливі 2 режими: основний і агресивний.
В основному режимі відбуваються 3 обміни: в першому вузли домовляються про правила, у другому обмінюються відкритими значеннями Діффі-Геллмана й допоміжними даними, в третьому відбувається підтвердження обміну Діффі-Геллмана.
В агресивному режимі в першому обміні встановлюються правила, передаються відкриті значення Діффі-Геллмана й допоміжна інформація. Причому, в другому повідомленні першого обміну відбувається ідентифікація відповідача (англ. responder). Третє повідомлення ідентифікує ініціатора і підтверджує участь в обміні. Останнє (четверте) повідомлення може бути не послано.
Для обох цих методів можливі чотири типи різних методів ідентифікації: цифровим підписом, два типи шифрування відкритим ключем і роздільним ключем (англ. pre-shared key).
Залежно від типу ідентифікації на початку генерується SKEYID.
SKEYID=prf (Ni_b|Nr_b, g^xy) в разі ідентифікації цифровим підписом.
SKEYID = prf (hash (Ni_b|Nr_b), CKY-I|CKY-R) в разі шифрування відкритим ключем.
SKEYID = prf (pre-shared-key, Ni_b|Nr_b) в разі роздільного ключа.
Після цього сторони обчислюють матеріали ключів SKEYID_d, SKEYID_a, SKEYID_e.
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)
Ідентифікація за допомогою цифрового підпису
В основному режимі на етапах 1 і 2 сторони узгоджують SA IKE і домовляються про налаштування обміну. Необхідно, щоб обидві сторони передали свої cookies. На 3 і 4 етапах сторони обмінюються ключами Діффі-Геллмана й псевдовипадковими значеннями. Після цього сторони можуть захищати повідомлення. На етапах 5 і 6 відбувається обмін зашифрованою інформацією ідентифікації.
![Обмін даними при ідентифікації IKE цифровим підписом в основному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/-1-signature_phase1.png/350px--1-signature_phase1.png)
В агресивному режимі обмежені можливості узгодження, так як ініціатор повинен передати в одному повідомленні значення Діффі-Геллмана і дані поточного часу. А значить ініціатор не може запропонувати різні групи Діффі-Геллмана. Однак, іноді агресивний режим може бути єдиним способом встановлення SA IKE, наприклад, якщо одержувач не знає адресу ініціатора. Якщо ініціатор вже має дані про одержувача, то агресивний режим буде більш ефективним.
![Обмін даними при ідентифікації IKE цифровим підписом в агресивному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/6/66/-2-signature_phase1.png/350px--2-signature_phase1.png)
І в основному, і в агресивному режимах результатом є підписані дані (SIG_I і SIG_R)[1].
Ідентифікація за допомогою шифрування відкритим ключем
Якщо при роботі в основному режимі у відповідача є кілька відкритих ключів, то в 3-му повідомленні пересилається хеш сертифіката (HASH (1)), що використовується ініціатором для шифрування. Таким чином адресат зможе визначити, яким ключем шифруються повідомлення, просто складаючи хеші своїх сертифікатів і порівнюючи їх з отриманим. Варто відзначити, що дані ідентифікації та поточного часу шифруються за допомогою ключа іншої сторони.
![Обмін даними при ідентифікації IKE за допомогою шифрування з відкритим ключем в основному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c8/-1-pubkey_phase1.png/350px--1-pubkey_phase1.png)
![Обмін даними при ідентифікації IKE за допомогою шифрування з відкритим ключем в агресивному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/-2-pubkey_phase1.png/350px--2-pubkey_phase1.png)
Ідентифікація за допомогою виправленого режиму шифрування відкритим ключем
Ідентифікація за допомогою шифрування відкритим ключем вимагає витрат на операції з ключами: 2 операції на шифрування відкритим ключем і 2 операції на розшифровку закритим ключем. Виправлений режим дозволяє скоротити вдвічі кількість операцій. У цьому режимі дані поточного часу також шифруються за допомогою відкритого ключа іншого боку, а ідентифікатори (і, якщо відсилаються, сертифікати) шифруються за допомогою узгодженого симетричного алгоритму шифрування (на підставі даних SA). Ключ для цього шифрування отримано на підставі даних поточного часу[1].
![Обмін даними при ідентифікації IKE за допомогою виправленого шифрування з відкритим ключем в основному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/d/dd/-1-pubkey_rev_phase1.png/350px--1-pubkey_rev_phase1.png)
![Обмін даними при ідентифікації IKE за допомогою виправленого шифрування з відкритим ключем в агресивному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c2/-2-pubkey_rev_phase1.png/350px--2-pubkey_rev_phase1.png)
Причина можливого відсилання HASH (1) така ж, що і в простій ідентифікації за допомогою шифрування відкритим ключем. Ключі Ke_i і Ke_r узгоджуються під час обміну даними SA. Дані шифруються, а заголовки даних передаються відкритим текстом.
Ідентифікація за допомогою роздільного ключа
Ключ в основному режимі може бути визначений за IP-адресою сторін, так як хеш-код ініціатора HASH_I повинен бути пораховано до того, як ініціатор почне обробку IDir. Агресивний режим дозволяє сторонам мати кілька подільних ключів і при узгодженні обміну повідомляти який з них використовується.
![Обмін даними при ідентифікації IKE за допомогою роздільного ключа в основному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/-1-preshared_phase1.png/350px--1-preshared_phase1.png)
![Обмін даними при ідентифікації IKE за допомогою роздільного ключа в агресивному режимі фази 1](http://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/-2-preshared_phase1.png/350px--2-preshared_phase1.png)
Фаза 2
Швидкий режим
Швидкий режим не є повним обміном (так як він нерозривно пов'язаний з обмінами в 1 фазі), хоча і використовується як частина процесу узгодження SA, доставляючи матеріали ключів і погоджуючи правила для SA, які не є ISAKMP SA. Всі повідомлення повинні бути захищені ISAKMP SA. Це означає, що всі частини повідомлень за винятком заголовка ISAKMP шифруються[1].
![Обмін даними під час другої фази IKE в швидкому режимі](http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/-1-quick_mode_phase2.png/350px--1-quick_mode_phase2.png)
HASH (1) = prf (SKEYID_a, M-ID|SA|Ni [|KE] [|IDci|IDcr)
HASH (2) = prf (SKEYID_a, M-ID|Ni_b|SA|Nr [|KE] [|IDci|IDcr)
HASH (3) = prf (SKEYID_a, 0|M-ID|Ni_b|Nr_b)
Новий матеріал ключів визначається як: KEYMAT = prf (SKEYID_d, protocol|SPI|Ni_b| Nr_b) — досконала пряма секретність не потрібна
KEYMAT = prf (SKEYID_d, g (qm)^xy | protocol|SPI|Ni_b|Nr_b) — досконала пряма секретність потрібна. Тут g qm)^xy — розділяється ключ, який був отриманий в процесі обміну Діффі-Хеллмана.
Режим нової групи
Режим нової групи не повинен бути використаний до встановлення SA ISAKMP. Опис нової групи має слідувати тільки після узгодження в фазі 1 (хоча сам режим нової групи не відноситься до фази 2).
![Обмін даними в IKE в режимі нової групи](http://upload.wikimedia.org/wikipedia/commons/thumb/0/04/-1-new_group.png/350px--1-new_group.png)
HASH (1) = prf (SKEYID_a, M-ID | SA)
HASH (2) = prf (SKEYID_a, M-ID | SA)
Групи OAKLEY
У групах OAKLEY відбувається узгодження Діффі-Хеллмана. В RFC 2409 визначено 4 групи. Вперше ці групи були описані в протоколі OAKLEY, тому і отримали таку назву[1].
Примітки
- ↑ а б в г д е RFC 2407 Internet Security Association and Key Management Protocol (ISAKMP). Архів оригіналу за 30 квітня 2016. Процитовано 8 квітня 2018.
Посилання
- RFC 2407 Internet Security Association and Key Management Protocol (ISAKMP) [Архівовано 30 квітня 2016 у Wayback Machine.]
Джерела
- Блек У. «Інтернет: протоколи безпеки. Навчальний курс»
- RFC 2407 — The Internet IP Security Domain of Interpretation for ISAKMP
- RFC 2408 — Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409 — The Internet Key Exchange (IKE)
|