Протокол автентифікації з використанням kdc

Інший підхід використовує nonces. Цей протокол складається з наступних кроків:

1. A -> KDC: ID_A || ID_B

2. KDC -> A: E_KRkdc [ID_B || KU_b]

3. A -> B: E_KUb [N_a || ID_A]

4. B -> KDC: ID_B || ID_A || E_KUkdc [N_a]

5. KDC -> B: E_KRkdc [ID_A || KU_a] || E_KUb [E_KRkdc [N_a || K_S || ID_B]]

6. B -> A: E_KUa [E_KRkdc [N_a || K_S || ID_B] || N_b]

7. A -> B: E_KS [N_b]

На першому кроці А інформує KDC, що хоче встановити безпечне з'єднання з B. KDC повертає А сертифікат відкритого ключа В (крок 2). Використовуючи відкритий ключ B, А інформує В о створенні захищеного з'єднання й посилає nonce N_a (крок 3). На 4-му кроці В запитує KDC про сертифікат відкритого ключа А и запитує ключ сесії. В включає nonce A, щоб KDC міг позначити ключ сесії цим nonce. Nonce захищений використанням відкритого ключа KDC. На 5-м кроці KDC повертає В сертифікат відкритого ключа А плюс інформацію {N_a, K_S, ID_B}. Ця інформація означає, що K_S є секретним ключем, створеним KDC в інтересах В и пов'язаний з N_a. Зв'язування K_S і N_a гарантує А, що K_S не застарів. Ця трійка шифрується з використанням закритого ключа KDC, це гарантує B, що трійка дійсно отримана від KDC. Вона також шифрується з використанням відкритого ключа B, щоб ніхто іншої не міг підглянути ключ сесії й використовувати цю трійку для встановлення з'єднання з А. На кроці 6 трійка {N_a, K_S, ID_B}, зашифрована закритим ключем KDC, передається А разом з nonce N_b, створеним B. Все повідомлення шифрується відкритим ключем А. А відновлює ключ сесії K_S, використовує його для шифрування N_b, що повертає B. Це останнє повідомлення гарантує B, що А знає ключ сесії.

Це досить безпечний протокол при різного роду атаках. Однак автори запропонували переглянуту версію даного алгоритму:

1. A -> KDC: ID_A || ID_B

2. KDC -> A: E_KRauth [ID_B || KU_b]

3. A -> B: E_KUb [N_a || ID_A]

4. B -> KDC: ID_B || ID_A || E_KUauth [N_a]

5. KDC -> B: E_KRauth [ID_A || KU_a] || E_KUb [E_KRauth [N_a || K_S || ID_A || ID_B]]

6. B -> A: E_KUa [E_KRauth [N_a || K_S || ID_A || ID_B] || N_b]

7. A -> B: E_KS [N_b]

Додається ідентифікатор А ID_A до даних, зашифрованих з використанням закритого ключа KDC на кроках 5 і 6 для ідентифікації обох учасників сесії. Це включення ID_A приводить до того, що значення nonce N_a повинне бути унікальним тільки серед всіх nonces, створених А, але не серед nonces, створених всіма учасниками. Таким чином, пари {ID_A, N_a} унікально ідентифікує з'єднання, створене А.

Однобічна автентифікація

Існує специфічний додаток - електронна пошта, для якого шифрування також має велике значення. Особливість e-mail полягає в тому, що відправникові й одержувачеві немає необхідності бути на зв'язку в той же самий час. Замість цього повідомлення направляються в поштову скриньку одержувача, де вони зберігаються доти, поки в того не з'явиться можливість одержати їх. Заголовок повідомлення повинен бути незашифрованим, щоб повідомлення могло пересилатися протоколами e-mail, такими як Х.400 або SMTP. Однак бажано, щоб протоколи керування поштою не мали б доступу до самого повідомлення. Відповідно, e-mail повідомлення повинне бути зашифроване так, щоб система керування поштою могла б не знати ключ шифрування. Другою вимогою є автентифікація повідомлення. Звичайно одержувачеві потрібна певна гарантія того, що повідомлення прийшло від законного відправника.