3. Підходи на основі шифрування з відкритим ключем

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

В [DENN81] пропонується наступний протокол, що використовує мітки дати / часу:

У цьому випадку центральна система виступає в якості сервера аутентифікації (AS), оскільки вона насправді не несе відповідальності за розподіл секретних ключів. Швидше, AS забезпечує сертифікацію відкритих ключів. Сеансовий ключ вибирається і шифрується стороною А, тому немає ризику його розголошення з боку системи AS. Мітки дати / часу захищають від відтворення скомпрометованих ключів.

Цей протокол компактний, але, як попередні, вимагає синхронізації годинників. Інший підхід, який запропонували By (Woo) і Лем (Lam) у [W0092a], передбачає застосування оказій. Відповідний протокол складається з наступних кроків.

На кроці 1 сторона А інформує ЦРК про свій намір встановити безпечне з'єднання зі стороною В. ЦРК повертає учаснику А примірник сертифіката відкритого ключа сторони В (крок 2). Використовуючи відкритий ключ учасника обміну інформацією В, сторона А інформує сторону В про намір встановити з'єднання і посилає оказію N_a (крок 3).На кроці 4 сторона В запитує у ЦРК сертифікат відкритого ключа сторони А і сеансовий ключ. Відповідне повідомлення учасника В включає оказію учасника А, щоб ЦРК міг помітити що видається сеансовий ключ цією оказією. Оказія захищається шифруванням з використанням відкритого ключа ЦРК. На кроці 5 ЦРК повертає стороні В примірник сертифіката відкритого ключа сторони А та інформацію {N_a, K_s, ID_B}. Ця інформація, по суті, доводить, що Ks є секретним ключем, згенерованим ЦРК від імені сторони В і пов'язаним з N_a, причому зв'язування К_s з N_a покликане переконати сторону А в тому, що ключ К_s є новим. Ця трійка значень шифрується за допомогою особистого ключа ЦРК, щоб сторона В могла перевірити, що вказані значення насправді отримані від ЦРК. Потім все це шифрується за допомогою відкритого ключа В, щоб ніхто інший не міг використовувати ці значення в спробі створення незаконного з'єднання з А. На кроці 6 трійка значень {N_a, К_s, IDв}, залишаючись у вигляді, зашифрованому за допомогою особистого ключа ЦРК, передається стороні А разом з оказією N_b, згенерованої стороною В. Все це разом шифрується тепер з використанням відкритого ключа А. Сторона А витягує з повідомлення сеансовий ключ К_s і використовує його для того, щоб зашифрувати Nb і повернути відповідне значення стороні В. Це переконує сторону В в тому, що сторона А дійсно отримала сеансовий ключ.

Описаний протокол здається цілком захищеним щодо атак самого різного виду, проте його автори самі виявили в ньому дефект і представили в [W0092b] наступну виправлену версію алгоритму.

Тут до безлічі елементів, шифрованих особистим ключем ЦРК на кроках 5 та 6, додається ідентифікатор ID_А сторони А. Це пов'язує сеансовий ключ K_s з ідентифікаторами обох сторін, які братимуть участь у сеансі обміну даними. Включення в набір значення ID_А пояснюється тим, що значення оказії N_a має бути унікальним тільки для оказій, що генеруються стороною А, а не для всіх оказій, що генеруються будь-якою зі сторін. Таким чином, саме пара {ID_A, N_a} унікальним чином ідентифікує запит на з'єднання з боку А.

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