12

Лекція 7. Автентифікація

Протоколи автентифікації

Розглянемо основні протоколи, що забезпечують як взаємну автентифікацію учасників, так і автентифікацію тільки одного з учасників.

Взаємна автентифікація

Дані протоколи застосовуються для взаємної автентифікації учасників і для обміну ключем сесії.

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

Такі повтори називаються replay-атаками. Розглянемо можливі приклади подібних replay-атак:

1. Просте повторення: супротивник просто копіює повідомлення й повторює його пізніше.

2. Повторення, що не може бути визначено: супротивник знищує вихідне повідомлення й посилає скопійоване раніше повідомлення.

Один з можливих підходів для запобігання replay-атак міг би складатися в приєднанні послідовного номера (sequence number) до кожного повідомлення, використовуваному в автентифікационном обміні. Нове повідомлення приймається тільки тоді, коли його послідовний номер правильний. Труднощі даного підходу полягають у тому, що кожному учасникові потрібно підтримувати значення sequence number для кожного учасника, з яким він взаємодіє в цей момент. Тому звичайно sequence number не використовуються для автентифікації й обміну ключами. Замість цього застосовується один з наступних способів:

1. Оцінки часу: учасник А приймає повідомлення як не застаріле тільки в тому випадку, якщо воно містить оцінку часу, що, на думку А, відповідає поточному часу. Цей підхід вимагає, щоб годинники всіх учасників були синхронізовані.

2. Запит/відповідь: учасник А посилає в запиті до В випадкове число (nonce - number only once) і перевіряє, щоб відповідь від В містив коректне значення цього випадкового числа .

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

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

Використання симетричного шифрування

Для забезпечення автентифікації й розподілу ключа сесії часто використовується дворівнева ієрархія ключів симетричного шифрування. Загалом ця стратегія включає використання довіреного центра розподілу ключів (KDC). Кожний учасник розділяє секретний ключ, що має назву також майстер-ключем, з KDC. KDC відповідає за створення ключів, що мають назву ключів сесії, і за розподіл цих ключів з використанням майстрів-ключів. Ключі сесії застосовуються протягом короткого часу для шифрування тільки даної сесії між двома учасниками.

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

Протокол Нидхема й Шредера

Передбачається, що секретні майстер-ключі K_A і K_B розділяють відповідно А и KDC і В и KDC. Метою протоколу є безпечний розподіл ключа сесії KS між А и В. Протокол являє собою наступну послідовність кроків:

1. A KDC: ID_A || ID_B || N₁

2. KDC A: E_Ka [K_S || ID_B || N₁ || E_Kb [K_S || ID_A] ]

3. A B: E_Kb [K_S || ID_A]

4. B A: E_KS [N₂]

5. A B: E_KS [f (N₂)]

1. А запитує в KDC ключ сесії для встановлення захищеного з'єднання з В. Повідомлення включає ідентифікацію А и В і унікальний ідентифікатор даної транзакції, що позначений як N₁ і називається nonce. Nonce може бути часовою міткою, лічильником або випадковим числом; мінімальна вимога полягає в тому, щоб він відрізнявся для кожного запиту. Крім того, для запобігання підробки бажано, щоб супротивникові було важко вгадати nonce. Таким чином, випадкове число є кращим варіантом для nonce.

2. KDC відповідає повідомленням, зашифрованим ключем K_А. Таким чином, тільки А може розшифрувати повідомлення, і А впевнений, що воно отримано від KDC, так як передбачається, що крім А и KDC цей ключ не знає ніхто. Це повідомлення включає наступні елементи, призначені для А:

• Одноразовий ключ сесії.

• Ідентифікатор В.

• nonce, що ідентифікує дану сесію .

А повинен переконатися, що отриманий nonce дорівнює значенню nonce з першого запиту. Це доводить, що відповідь від KDC не був модифікований при пересиланні й не є повтором деякого попереднього запиту. Крім того, повідомлення включає два елементи, призначені для В:

• Одноразовий ключ сесії K_S.

• Ідентифікатор А ID_A.

Ці два останніх елементи шифруються майстер-ключем, що KDC розділяє з В. Вони посилають В при встановленні з'єднання й доводять ідентифікацію А.

3. А зберігає в себе ключ сесії й передає В інформацію від KDC, призначену В: Е_Kb [K_S || ID_A]. Так як ця інформація зашифрована K_В, вона захищена від перегляду. Тепер В знає ключ сесії (K_S), знає, що іншим учасником є А, (ID_A) і що початкова інформація передана від KDC, так як вона зашифрована з використанням K_B.

В цій точці ключ сесії безпечно переданий від А к В, і вони можуть почати безпечний обмін. Проте, існує ще два додаткових кроки:

4. Використовуючи створений ключ сесії, В пересилає A nonce N₂.

5. Також використовуючи K_S, А відповідає f (N₂), де f - функція, що виконує деяку модифікацію N₂.

Ці кроки гарантують B, що повідомлення, що він одержав, не змінений і не є повтором попереднього повідомлення.

Помітимо, що реальний розподіл ключа включає тільки кроки 1 - 3, а кроки 4 і 5, як і 3, виконують функцію автентифікації.

А безпечно одержує ключ сесії на кроці 2. Повідомлення на кроці 3 може бути дешифровано тільки B. Крок 4 відбиває знання В ключа K_S, і крок 5 гарантує В знання учасником А ключа K_S і підтверджує, що це не застаріле повідомлення, так як використовується nonce N₂. Кроки 4 і 5 покликані запобігти загальному типу replay-атак. Зокрема, якщо супротивник має можливість захопити повідомлення на кроці 3 і повторити його, то це повинне привести до розриву з'єднання.

Розриваючи рукостискання на кроках 4 і 5, протокол усе ще уразливий для деяких форм атак повторення. Припустимо, що супротивник Х має можливість скомпрометувати старий ключ сесії. Малоймовірно, щоб супротивник міг зробити більше, ніж просто копіювати повідомлення кроку 3. Потенційний ризик полягає в тому, що Х може змусити взаємодіяти А и B, використовуючи старий ключ сесії. Для цього Х просто повторює повідомлення кроку 3, що було перехоплено раніше й містить скомпрометований ключ сесії. Якщо В не запам'ятовує ідентифікацію всіх попередніх ключів сесій з А, він не зможе визначити, що це повтор. Далі Х повинен перехопити повідомлення рукостискання на кроці 4 і представитися А в відповіді на кроці 5.