3. Авторитетне джерело відкритих ключів

Найкращий захист розподілу відкритих ключів може бути досягнутий шляхом більш суворого контролю за розподілом відкритих ключів з каталогу. Типовий сценарій представлений схемою на рис. 10.3, в основу якого покладено один з малюнків з [РОРЕ79]. Як і раніше, сценарій припускає наявність деякого центрального об'єкту, уповноваженого підтримувати динамічний каталог відкритих ключів всіх учасників обміну даними. Крім того, кожному з учасників достовірно відомий відкритий ключ центру, але тільки центр знає відповідний особистий ключ. При цьому виконуються наступні дії (їх номери узгоджені з номерами на рис. 10.3)

1. Ініціатор А посилає повідомлення з міткою дати / часу авторитетному джерелу відкритих ключів із запитом про поточний відкритому ключі учасника В.

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

• відкритий ключ учасника В, KU_b, який учасник А може використати для шифрування повідомлень, призначених для одержувача В;

• оригінальний запит, щоб сторона А мала можливість зіставити відповідь з раніше відправленим запитом і переконатися, що запит не був змінений на шляху до авторитетного джерела;

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

3. Ініціатор А зберігає відкритий ключ учасника В і використовує його для шифрування повідомлення, що направляється одержувачу В і містить ідентифікатор відправника А (ID_А) і оказію (N₁), яка виступає в якості унікальної мітки даного повідомлення.

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

6. Респондент В посилає повідомлення ініціатору А, шифрування за допомогою KU, і що містить оказію відправника А (N₁), а також нову оказію, сгенерированную учасником В (N₂). Зважаючи на те що тільки він і міг дешифрувати повідомлення (3), присутність N₁ у повідомленні (6) переконує учасника А в тому, що відправником отриманого повідомлення був В.

7. Ініціатор А повертає N₂, шифрування за допомогою відкритого ключа учасника В, щоб той міг переконатися в тому, що відправником відповіді є А.

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

Рис. 10.3 Сценарій розподілу відкритих ключів