Алгоритмы обмена ключей и протоколы аутентификации

Использование шифрования с открытым ключом

Протокол аутентификации с использованием аутентификационного сервера.

Рассмотрим протокол, использующий отметки времени и аутентификационный сервер:

1. A -> AS:  IDA || IDB
2. AS -> A:  EKRas [IDA || KUa || T] || 
             EKRas [IDB || KUb || T]
3. A -> B:   EKRas [IDA || KUa || T] || 
             EKRas [IDB || KUb || T] || 
             EKUb [EKRa [KS || T]]

В данном случае третья доверенная сторона является просто аутентификационным сервером AS, потому что третья сторона не создает и не распределяет секретный ключ. AS просто обеспечивает сертификацию открытых ключей участников. Ключ сессии выбирается и шифруется А, следовательно, не существует риска, что AS взломают и заставят распределять скомпрометированные ключи сессии. Отметки времени защищают от повтора скомпрометированных ключей сессии.

Данный протокол компактный, но, как и прежде, требует синхронизации часов.

Протокол аутентификации с использованием KDC

Другой подход использует nonces. Этот протокол состоит из следующих шагов:

1. A -> KDC: IDA || IDB
2. KDC -> A: EKRkdc [IDB || KUb]
3. A -> B:   EKUb [Na || IDA]
4. B -> KDC: IDB || IDA || EKUkdc [Na]
5. KDC -> B: EKRkdc [IDA || KUa] || 
             EKUb [EKRkdc [Na || KS || IDB]]
6. B -> A:   EKUa [EKRkdc [Na || KS || IDB] || Nb]
7. A -> B:   EKS [Nb]

На первом шаге А информирует 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: IDA || IDB
2. KDC -> A: EKRauth [IDB || KUb]
3. A -> B:   EKUb [Na || IDA]
4. B -> KDC: IDB || IDA || EKUauth [Na]
5. KDC -> B: EKRauth [IDA || KUa] || EKUb [
             EKRauth [Na || KS || IDA || IDB]]
6. B -> A:   EKUa [EKRauth [Na || KS || 
             IDA || IDB] || Nb]
7. A -> B:   EKS [Nb]

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