IKEv1 і IKEv2 зі спільним попереднім ключем: чим відрізняється автентифікація

Два шлюзи, налаштовані з тим самим попереднім ключем, завершують рукостискання, і запис пакетів не показує секрету, що перетинає дріт. Це та частина, яку запам'ятовують. Цікава та частина, яку кожна версія справді обчислює, щоб довести знання секрету, бо IKEv1 і IKEv2 будують цей доказ із різних вхідних даних і при цьому розкривають різну інформацію. Прочитайте дві траси поруч — і відмінність перестане бути косметичною.

Чого має досягти доказ

Diffie-Hellman дає обом сторонам спільне значення, публічні половини якого може обчислити й будь-який спостерігач. Саме по собі це нічого не доводить про ідентичність: атакувальник, який завершив обмін ключами, має те саме спільне значення, що й ваш шлюз. Крок автентифікації існує, щоб прив'язати цей обмін до секрету, який є лише в передбачених сторін, а також до ідентичностей і параметрів, про які вони домовилися.

Саме ця прив'язка є причиною, чому хеш охоплює більше, ніж ключ. Якби він охоплював лише секрет, атакувальник міг би відтворити його в іншому обміні з іншими ідентичностями чи пропозиціями.

IKEv1 Main Mode: вивести SKEYID, а потім довести

Main Mode виконує шість повідомлень. Перша пара узгоджує асоціацію безпеки, друга обмінюється відкритими значеннями Diffie-Hellman і nonce, третя несе ідентичності та хеші автентифікації під щойно встановленим шифруванням. RFC 2409 визначає конструкцію: за автентифікації спільним попереднім ключем SKEYID виводиться із секрету й обох nonce, а подальший ключовий матеріал — із SKEYID, спільного значення Diffie-Hellman, cookie та констант.

Хеш у п'ятому й шостому повідомленнях обчислюється за значенням Diffie-Hellman, двома cookie, пропозицією та ідентичністю відправника, з SKEYID як ключем. Одержувач перераховує його зі своїм налаштованим секретом. Розбіжність завершує обмін, і сам секрет ніколи не є корисним навантаженням.

Aggressive Mode стискає ту саму роботу в три повідомлення, а отже, ідентичності та хеш автентифікації вирушають до того, як з'явиться зашифрований канал. Це реальна експозиція для вгадуваного секрету, і це окреме питання від того, чи передавався секрет. IKEv1 застарів за RFC 9395, тож стара траса — діагностична вправа, а не мета розгортання.

IKEv2: інше виведення та інше корисне навантаження AUTH

IKEv2 не використовує повторно розклад ключів IKEv1. Початкові ключі IKE походять із зерна, побудованого з nonce і спільного значення Diffie-Hellman, а дочірні асоціації безпеки виводяться з нього. Попередній ключ зовсім не живить зерно.

Далі автентифікація з'являється як корисне навантаження AUTH. Для автентифікації спільним ключем RFC 7296 визначає доповнену форму секрету, отриману хешуванням секрету з фіксованим рядком Key Pad for IKEv2, а потім хешуванням підписаних даних обміну та ідентичності цим доповненим ключем. Перевіряльник може відтворити те саме значення; спостерігач — ні, без секрету.

Зверніть увагу, що змінилося. У IKEv1 секрет замішаний у розклад ключів ще до появи хешу автентифікації; у IKEv2 розклад ключів не залежить від секрету, а доказ — окреме корисне навантаження, прив'язане до підписаних октетів. Та сама концептуальна гарантія, інша механіка, і тому назви параметрів та записи не зіставляються один до одного.

Що насправді дізнається спостерігач

Відкриті значення Diffie-Hellman, пропозиції, nonce і cookie видно в обох версіях. Ідентичності видно в IKEv1 Aggressive Mode, а в інших випадках вони захищені. Секрет не видно ніколи.

Останнє речення має межу, яку варто назвати. Слабкий, вибраний людиною секрет можна атакувати вгадуванням: атакувальник обчислює, яким було б значення автентифікації для кандидата в секрети, і порівнює. IKEv1 Aggressive Mode робить це найдешевшим, бо доказ лежить відкрито, і стандарти загалом попереджають про секрети з низькою ентропією. Ніколи не передавати секрет — це не те саме, що зробити поганий секрет безпечним.

Що робити з порівнянням

Використовуйте один унікальний секрет на кожну пару сторін, генеруйте його з випадкового джерела й змінюйте тим самим шляхом підготовки, який його розповсюджував. Якщо секрет лежить у шаблоні конфігурації, що йде в кожну філію, компрометація в одному місці — компрометація всюди.

Віддавайте перевагу автентифікації за сертифікатами там, де експлуатаційні витрати прийнятні, оскільки вона усуває проблему вгадування спільного секрету й дає кожному учаснику окрему ідентичність. Там, де попередній ключ залишається, тримайте його довгим, обмежте сферу застосування й розглядайте версію IKE як рішення про безпеку, а не як деталь сумісності.