Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Posibnik_1_0.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
7.93 Mб
Скачать

4. Сертифікати відкритих ключів

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

Альтернативний підхід, який запропонував Конфельдер (Kohnfelder) [KOHN78], заснований на сертифікатах, які можуть використовуватися учасниками для обміну ключами без контакту з авторитетним джерелом відкритих ключів і повинні забезпечувати спосіб обміну, такий же надійний, як спосіб отримання ключів безпосередньо від авторитетного джерела відкритих ключів. Кожен сертифікат містить відкритий ключ та іншу інформацію, створюється авторитетним джерелом сертифікатів і видається учаснику разом з відповідним особистим ключем. Один учасник передає інформацію про своєму ключі іншого за допомогою передачі свого сертифіката. Інші учасники можуть перевірити, що сертифікат був створений авторитетним джерелом. Можна сформулювати такі вимоги до цієї схеми.

  1. Будь-який учасник повинен мати можливість прочитати сертифікат, щоб визначити ім'я і відкритий ключ власника сертифіката.

  2. Будь-який учасник повинен мати можливість перевірити, що сертифікат виходить з авторитетного джерела сертифікатів і не є підробкою.

  3. Тільки авторитетне джерело сертифікатів повинен мати можливість створювати і змінювати сертифікати.

Всі ці вимоги задовольнялися первісною схемою з [KOHN78]. Деннінг (Denning) додав до них наступне додаткова вимога [DENN83].

  1. Будь-який учасник повинен мати можливість перевірити термін дії сертифіката.

Схема використання сертифікатів показана на рис. 10.4. Кожен учасник звертається до авторитетного джерела сертифікатів, надаючи відкритий ключ і запитуючи для нього сертифікат. Запит повинен припускати або особисте звернення, або деяку захищену форму зв'язку. Для учасника А авторитетне джерело забезпечує сертифікат виду

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

Рис. 10.4. Обмін сертифікатами відкритих ключів

Одержувач використовує відкритий ключ авторитетного джерела сертифікатів KUauth, щоб дешифрувати сертифікат. Зважаючи на те що сертифікат можна прочитати тільки за допомогою відкритого ключа авторитетного джерела сертифікатів, це дає гарантію того, що сертифікат прийшов саме від авторитетного джерела сертифікатів. Елементи IDA і KUa повідомляють одержувачу ім'я і відкритий ключ власника сертифіката. Нарешті, мітка дати / часу Т визначає термін дії сертифікату. Мітка дати / часу повинна бути захищена від наступної послідовності дій. Противник дізнається особистий ключ А. З цієї причини А генерує нову пару ключів (особистий і відкритий) і звертається до авторитетного джерела сертифікатів за новим сертифікатом. Тим часом противник відтворює повідомлення зі старим сертифікатом і відсилає його В. Якщо В буде шифрувати повідомлення, використовуючи старий скомпрометований відкритий ключ, супротивник зможе прочитати ці повідомлення.

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

Розподіл секретних ключів за допомогою системи з відкритим ключем

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]