Ольга Полянская - Инфраструктуры открытых ключей

Формат ответа ЦРК зависит от типа ключа пользователя А . Если пользователь А использует открытый ключ Диффи-Хэллмана, то ЦРК возвращает его подписанным при помощи открытого ключа Диффи-Хэллмана. Пользователь проверяет цифровую подпись, чтобы убедиться, что ответ принадлежит ЦРК . И пользователь А , и ЦРК вычисляют один и тот же симметричный ключ при помощи алгоритма Диффи-Хеллмана и используют его как сеансовый ключ S A . Пользователь А может использовать и открытый ключ RSA . В этом случае ЦРК генерирует временный симметричный ключ и шифрует его при помощи открытого ключа ( RSA ) пользователя А . Кроме того, ЦРК генерирует и заверяет цифровой подписью второй симметричный ключ, который будет использоваться как сеансовый ключ S A . Затем подписанный ключ S A шифруется при помощи временного ключа и отправляется пользователю А вместе с временным ключом, зашифрованным открытым ключом ( RSA ) пользователя А . Пользователь А может извлечь ключ S A , расшифровав сначала временный ключ при помощи своего секретного ключа ( RSA ), а потом использовав этот временный ключ для окончательного расшифрования подписанного ключа S A . Проверка подписи гарантирует, что сеансовый ключ S A получен от ЦРК .

Без сертификата ЦРК был бы необходим другой механизм аутентификации открытого ключа пользователя А . Связывание имени пользователя А с его открытым ключом подписи позволяет ЦРК аутентифицировать запрос. ЦРК полагается на удостоверяющий центр (УЦ) для подтверждения того, что пользователь А владеет секретным ключом, соответствующим открытому ключу , указанному в сертификате .

Использование в системе Kerberos технологии открытых ключей позволяет ЦРК не хранить секретные ключи пользователей, что значительно снижает риск компрометации. В случае успешной атаки на ЦРК последствия оказываются менее серьезными, так как новые секретные ключи требуются только серверам.

В том случае, когда пользователи имеют сертификаты открытых ключей , необходимость в ЦРК отпадает. Это не означает, что отпадает необходимость в доверии и третьих сторонах; просто доверенной третьей стороной становится УЦ. Однако УЦ не участвует в обмене протоколами, и в отличие от ситуации с ЦРК , если УЦ недоступен, аутентификация по-прежнему может быть выполнена.

Аутентификацию при помощи сертификатов обеспечивают несколько распространенных протоколов, в частности, наиболее известный и широко распространенный протокол Secure Socket Layer (SSL), который применяется практически в каждом web-браузере. Помимо него применяются протоколы Transport Layer Security (TLS) [142], Internet Key Exchange (IKE) [147], S/MIME [169], PGP и Open PGP [149]. Каждый из них немного по-своему использует сертификаты , но основные принципы - одни и те же.

Рис. 2.5. Взаимная аутентификация на базе сертификатов

Рис. 2.5иллюстрирует типичный обмен сообщениями при аутентификации на базе сертификатов , использующий цифровые подписи [70]. Обмен соответствует стандарту аутентификации субъектов на основе криптографии с открытыми ключами [117]. Во многих протоколах предусматривается, что клиент направляет запрос серверу для того, чтобы инициировать аутентификацию. Такой подход, характерный, например, для дополнений аутентификации и шифрования к протоколу Internet File Transfer Protocol, гарантирует, что и пользователь, и сервер поддерживают один и тот же механизм аутентификации. Некоторые протоколы не требуют этого подготовительного шага.

Если сервер В поддерживает метод аутентификации, запрашиваемый пользователем А , то начинается обмен сообщениями. Сообщение Token ID уведомляет о том, что будет выполняться взаимная аутентификация , а также содержит номер версии протокола и идентификатор протокола. Хотя этот идентификатор не обязателен, он намного упрощает процедуру и поэтому обычно используется. Пользователь А ожидает сообщение Token ВА1 от сервера В. Идентификатор протокола в Token ID позволяет пользователю А удостовериться, что сервер В отправляет ожидаемое сообщение. Token ВА1 состоит только из случайного числа ran B , это - своего рода запрос, корректным ответом должна быть цифровая подпись числа ran B . Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.