2. Підходи на основі традиційного шифрування

Як було показано в розділі 5.3 (див. главу 5), для того, щоб забезпечити конфіденційність зв'язку в розподіленому середовищі, можна використовувати дворівневу ієрархію ключів традиційного шифрування. У загальному випадку ця стратегія передбачає наявність і використання надійного центру розподілу ключів (ЦРК). Кожна сторона в мережі, що бере участь в обміні даними, має свій таємний ключ, званий головним ключем і використовуваний спільно з ЦРК. ЦРК несе відповідальність за створення ключів, які діють протягом недовгого часу для з'єднань між двома сторонами і які називаються сеансовими ключами, а також за розподіл таких ключів деяким захищеним за допомогою головних ключів способом. Такий підхід є загальноприйнятим. Як приклад його використання ми розглянемо в розділі 11 систему Kerberos. Матеріал цього розділу буде корисний для кращого розуміння механізму роботи системи Kerberos.

На рис. 5.9 (див. главу 5) показана схема, спочатку запропонована Нідхем (Needham) і Шредером (Schroeder) [NEED78] для розподілу секретних ключів за допомогою ЦРК, що, як уже згадувалося в розділі 5, включає елементи аутентифікації. Відповідний протокол можна представити таким чином:

Секретні ключі Е_Ka і E_Kb використовують спільно А і ЦРК і В та ЦРК відповідно. Метою застосування протоколу є захищена передача сеансового ключа К, сторонам А і В. Сторона А отримує новий сеансовий ключ на кроці 2 схеми. Повідомлення, передане на кроці 3 схеми, може бути дешифровано і прочитано тільки стороною В. Крок 4 відображає знання ключа К, стороною В, а крок 5 переконує сторону В в тому, що ключ К, відомий стороні А, і в тому, що відповідне повідомлення є новим, тому що в ньому використовується оказія N₂. Згадайте, що при описі відповідної схеми в розділі 5 було показано, що метою кроків 4 та 5 є запобігання можливості відтворення повідомлень певного типу противником. Зокрема, якщо супротивник зможе перехопити повідомлення на кроці 3 і потім відтворити його, це може певним чином порушити дії В.

Незважаючи на підтвердження, що виконуються в ході кроків 4 та 5, цей протокол все ще виявляється вразливим щодо атак з відтворенням повідомлень деякого спеціального виду. Припустимо що противник X якимось чином зміг скомпрометувати старий сеансовий ключ. Швидше за все, така можливість набагато менш імовірна, порівняно з тим, що супротивник зможе просто перехопити і записати повідомлення, передане на кроці 3. Однак така загроза потенційно все ж існує. Противник X може виступити від імені А і обдурити В, змусивши використовувати старий ключ, для чого просто відтворить у відповідному вигляді крок 3. Якщо В не пам'ятає точно всі попередні сеансові ключі, що використовувалися з А, то В не зможе визначити, що отримане повідомлення є відтворенням. Якщо певний С може перехопити повідомлення квитування на кроці 4, то він зможе відправити відповідь (крок 5) від особи А. Після цього С отримує можливість посилати підроблені повідомлення В, які будуть здаватися В прийшли від А зважаючи використання достовірного сеансового ключа.

Деннінг (Denning) в [DENN81, DENN82] пропонує усунути цей недолік шляхом модифікації протоколу Нідхема-Шредера, яка полягає в тому, що на кроках 2 і 3 додаються мітки дати / часу. При цьому передбачається, що головні ключі К_а і К_b є захищеними, а вся процедура складається з наступних кроків.

Тут Т є міткою дати / часу, використання якої переконує сторони В і А в тому, що сеансовий ключ був створений щойно. Таким чином, як учасник А, так і учасник В знатимуть, що дана сесія розподілу ключів відповідає поточному часу. Сторони А і В можуть переконатися у відповідності часу, перевіривши нерівність

|Час -Т| < ∆t₁+∆t₂

де ∆t₁ позначає оцінку для середнього відхилення показань локальних годин (А або В) від показань годин ЦРК, а ∆t₂ - очікуваний час затримки в мережі.

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

На закінчення відзначимо, що кроки 4 і 5 не входили в оригінальну схему [DENN81], а були додані пізніше [DENN82]. Ці дії підтверджують отримання сеансового ключа стороною В.

Протокол Деннінга, очевидно, забезпечує більш високий рівень безпеки в порівнянні з протоколом Нідхема-Шредера. Однак тут виникає нова проблема: ця вдосконалена схема вимагає залежності від годинників, показники яких повинні бути синхронізовані в мережі. В [GONG92] вказується на виникаючий при цьому ризик. Цей ризик випливає з того факту, що розподілені години можуть стати несинхронізовані або в результаті навмисних дій противника, або в результаті відмови годин або механізму синхронізації. Проблема виникає тоді, коли годинник відправника випереджає годинник передбачуваного адресата. У цьому випадку противник може перехопити повідомлення, що йде від відправника, і відтворити це повідомлення пізніше, коли мітка дати / часу в повідомленні стане відповідати поточним показникам годин вузла адресата. Таке відтворення може привести до непередбачуваних результатів. Гонг (Gong) називає такі атаки атаками затримки-відтворення.

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

В [KEHN92] була зроблена спроба врахувати моменти, пов'язані з атаками затримки-відтворення, і виправити у зв'язку з цим недоліки протоколу Нідхема-Шредера. Згодом в описаній там схемі були виявлені неузгодженості та в [NEUM93a] була запропонована вдосконалена стратегія. Тепер протокол виглядає наступним чином.

Давайте простежимо крок за кроком за тими діями, які необхідно виконати при такому обміні.

1. Сторона А ініціює ідентифікаційний процес, генеруючи оказію N_a і посилаючи її разом зі своїм ідентифікатором стороні В у вигляді відкритого тексту. Ця оказія буде повернута стороні А в зашифрованому повідомленні, що включає сеансовий ключ, щоб сторона А могла переконатися у відповідності цього ключа поточному часу.

2. Сторона В повідомляє в ЦРК про те, що потрібний сеансовий ключ. Відповідними повідомлення в ЦРК включає ідентифікатор В і оказію N_b. Ця оказія буде повернута В в зашифрованому повідомленні, що включає сеансовий ключ, щоб у В була можливість переконатися у відповідності цього ключа поточному часу. Повідомлення В, яке направляється ЦРК, також включає блок, зашифрований за допомогою секретного ключа, що використовується спільно В і ЦРК. Цей блок служить для того, щоб дати вказівку ЦРК видати посвідчення стороні А, тому в блоці вказується передбачуваний одержувач посвідчення, пропонований термін дії посвідчення, а також оказія, отримана від А.

3. ЦРК пересилає стороні А оказію В і блок, шифрований з використанням секретного ключа, який В застосовує спільно з ЦРК, Цей блок виконує роль "мандата", який А може використовувати для продовження процесу ідентифікації, як буде видно нижче. ЦРК також посилає стороні А блок, шифрований за допомогою секретного ключа, що використовується спільно А і ЦРК. Цей блок переконує сторону А в тому, що сторона В отримала початкове повідомлення А (зважаючи на присутність в блоці ID_B) і що це повідомлення відповідає часу і не є відтворенням (N_a), а також повідомляє А сеансовий ключ (К_s) і межі часу його використання (T_b).

4. Сторона А пересилає мандат стороні В разом з оказією сторони В, шифрованого отриманим сеансовим ключем. Мандат надає учаснику В секретний ключ, який служить для того, щоб дешифрувати E_Ks[N_b] і перевірити значення оказії. Той факт, що оказія учасника В приходить в зашифрованому за допомогою сеансового ключа вигляді, переконує його в тому, що повідомлення прийшло від учасника А і не є відтворенням.

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

Коли учасник В отримує повідомлення на кроці 1, він перевіряє, що мандат не прострочений. Нові оказії N'_a і N'_b переконують обидві сторони в тому, що даний процес не є атакою відтворення.

У наведеному вище обговоренні час, представлене значенням Т_b, є часом годин учасника В. Таким чином, дана мітка дати / часу не вимагає синхронізації годин, так як стороні В доводиться перевіряти тільки мітки дати / часу, згенеровані у своїй системі.