Инфраструктуры открытых ключей - [13]

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

Формат ответа ЦРК зависит от типа ключа пользователя А. Если пользователь А использует открытый ключ Диффи-Хэллмана, то ЦРК возвращает его подписанным при помощи открытого ключа Диффи-Хэллмана. Пользователь проверяет цифровую подпись, чтобы убедиться, что ответ принадлежит ЦРК. И пользователь А, и ЦРК вычисляют один и тот же симметричный ключ при помощи алгоритма Диффи-Хеллмана и используют его как сеансовый ключ 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. Пользователь А подписывает ответ и отправляет свой сертификат ключа подписи, для того чтобы сервер В при помощи открытого ключа мог выполнить валидацию подписи.

Пользователь А подписывает последовательность из трех элементов: свой запрос ran A, запрос сервера ran B и имя сервера name B. Ran A - это запрос А к серверу В, гарантирующий, что пользователь А подписывает не произвольное сообщение сервера В или другого субъекта, выдающего себя за сервер В. Получив ответ Token АВ от пользователя А, сервер В проверяет, совпадает ли значение ran B с соответствующим значением в сообщении Token ВА1