15. Протоколи аутентифікації. Взаємна та одностороння аутентифікація. (прочитати уважно номери малюнків і т.Д.)

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

1. Взаємна аутентифікація

Важливою сферою додатків є протоколи взаємної аутентифікації. Такі протоколи дають можливість обом сторонам, що приймають участь в обміні даними переконатися у справжності один одного і обмінятися сеансовими ключами. Ця тема вже обговорювалася в розділах 5.3 (традиційні методи; див. розділ 5) та 6.3 (схеми з відкритим ключем; див. розділ 6). Там в центрі уваги був розподіл ключів. Ми повертаємося до цієї теми, щоб розглянути тут можливості аутентифікації в більш широкому контексті.

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

В [GONG93] наводиться список наступних прикладів атак з використанням відтворення повідомлень.

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

• Відтворення, яке можна зареєструвати. Противник може відтворити повідомлення з міткою дати / часу усередині реального вікна часу.

• Відтворення, яке не можна виявити. Ця ситуація може мати місце з огляду на те, що оригінальне повідомлення можна примусово затримати, щоб воно не досягло адресата, тоді адресат отримає лише відтворене повідомлення.

• Зворотнє відтворення без модифікації. Це відтворення повідомлення, що повертається назад відправнику. Такий вид атаки виявляється можливим, коли використовується традиційне шифрування і для відправника не занадто просто відрізнити по вмісту повідомлення, яке надсилається від отримуваних.

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

• Мітки дати / часу. Сторона А приймає повідомлення як нове, тільки якщо повідомлення містить мітку дати / часу, значення якої, на думку А, досить близько до значення поточного часу в системі А. При цьому підході необхідно, щоб годинники сторін, які беруть участь в обміні даними, були синхронізовані.

• Запит / відповідь. Сторона А, яка очікує нового повідомлення від В, спочатку посилає B оказію (запит) і вимагає, що наступне повідомлення, отримане від В (відповідь), містило відповідне коректне значення оказії.

Тут можна заперечити (див., наприклад, [LAM92a]), що мітки дати / часу не можна використовувати для додатків, заснованих на застосуванні протоколу з встановленням логічних з'єднань, через внутрішні властивості цієї технології. По-перше, потрібно який-небудь протокол, що забезпечує синхронізацію годин процесорів різних систем. Цей протокол має бути, з одного боку, толерантним до відмов, щоб розпізнавати мережні помилки, а з іншого - захищеним, щоб протистояти атакам ворожої сторони. По-друге, шанси успішного завершення атак зростають, коли виникають тимчасові порушення синхронізації через відмови годинного пристрою однієї зі сторін. Нарешті, через спонтанні і непередбачувані затримки в мережах, що для мереж цілком природно, не можна очікувати, що розподілені години можуть підтримувати точну синхронізацію. Тому будь-яка процедура, яка використовує мітки дати / часу, повинна допускати для вікна часу достатньо широкі рамки, щоб враховувати можливість затримок в мережі, але в той же час ці рамки повинні бути досить вузькими, щоб мінімізувати можливості для атак.

Водночас підхід з використанням запитів / відповідей не годиться для додатків, що працюють з протоколами без встановлення з'єднань, оскільки в таких додатках буде потрібно дуже велике число додаткових підтверджень перед передачею будь-якої порції даних, що зводить нанівець головні переваги моделі обміну даними без встановлення з'єднань. Для таких додатків кращим підходом є застосування деякого надійного сервера часу і узгоджені спроби кожної зі сторін утримувати свої годинники в синхронізації з годинником такого сервера (див., наприклад, [LAM92b]).