Управление ключами.

При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае со Стасом и Ольгой мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Ольгой понимать клиентскую программу, установленную на рабочей станции, а под Стасом — службу на сетевом сервере, то встретиться они никак не могут. Проблема ещё более осложняется в тех случаях, когда Ольге-клиенту нужно посылать сообщения на несколько серверов, в этом случае для каждого сервера её придётся обзавестись отдельным ключом. Да и службе по имени Стас потребуется столько секретных ключей, сколько у него клиентов. Если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создаёт невероятный риск для всей системы безопасности.

Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) — персонаж классической греческой мифологии. Этот свирепый пёс о трёх головах, по поверьям греков, охраняет врата подземного царства мёртвых. Трём головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center, KDC.

KDC представляет собой службу, работающую на физически защищённом сервере. Она ведёт базу данных с информацией об учётных записях всех главных абонентов безопасности своей области. Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Этот ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи генерируются на основе пароля пользователя, указываемого при входе в систему.

Когда клиенту нужно обратиться к серверу, он прежде всего направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей – проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту – долговременного ключа данного клиента.

Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.