Файл: Сервер аутентификации Kerberos ( Цербер).pdf

1. Алёна направляет в адрес Стива сообщение, в котором содержится

её имя в открытом виде и аутентификатор, зашифрованный с помощью секретного ключа известного только им. Причем само по себе в реализации рассматриваемого протокола, такое сообщение представляет из себя структуру данных с двумя полями: информация об Алёне, то есть имя и текущее время на её компьютере.

1. Стив получает сообщение и видит, что оно пришло от некого чело

века называющего себя Алёной, далее он расшифровывает вторую половину сообщения тем ключом, которым они условились с Алёной шифровать аутентификатор, и узнает время отправки сообщения.

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

3. Стив шифрует поле времени из сообщения Алёны при помощи их общего ключа и прикрепляет его в собственное сообщение в направлении Алёны. Следует отметить, что Стив возвращает Алёне не всё содержимое её аутентификатора, а только шифрованную метку времени. При отправке всего сразу у Алёны бы возникли подозрения, что кто-то вероятно притворившись Стивом попросту скопировал его аутентификатор из её исходного сообщения и без модификации оного отправил назад. В полученном письме содержится лишь часть информации, что свидетельствует о том, что получатель исходного аутентификатора смог расшифровать его содержимое, обработать его и правильным образом (общим ключом) зашифровать обратно. Использование метки времени обусловлено тем, что это поля является уникальным идентификатором сообщения Алёны. Алёна получив ответ от Стива расшифровывает его, и сравнивает метку времени с данными времени указанными в исходном аутентификаторе. При совпадении этих данных, Алёна может быть уверена, что её аутентификатор дошел до кого-то кто знает их со Стивом общий секретный ключ, смог расшифровать его и извлечь данные о времени, учитывая тот факт, что ни Стив, ни Алёна свой ключ никому не передавали, то справедлив вывод, что именно Стив получил аутентификатор Алёны и ответил на него. Механизм взаимной аутентификации представлен на рисунке 1.

Рисунок 1.

Теперь, когда ясен механизм простой взаимной аутентификации вроде того, что описан выше, мы сталкиваемся со следующей проблемой. В примере со Стивом и Алёной мы не упомянули место, в котором они договариваются о секретном ключе для своей переписки. Нет, конечно люди могут встретиться где-нибудь в парке и обсудить все детали, но в сетевой картине договариваются машины. В дальнейшем мы будем под Алёной подразумевать клиентскую программу, а под Стивом сетевую службу на сервере. При подобном раскладе очевидно, что клиентская программа и серверная служба сами по себе встретится не могут, тем более если у Алёны-клиента есть задача посылать сообщения на несколько серверов появляется еще одна проблема – для каждого из них придется обзавестись отдельным секретным ключом. Да и Стиву - серверу потребуется столько ключей, сколько у него клиентов. То есть если каждой клиентской программе для поддержания связи с каждой сетевой службой требуются уникальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то задача обмена ключами становится достаточно острой проблемой. Эту проблему как раз-таки и решает рассматриваемый нами протокол Kerberos.

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

KDC являет собой специальную службу, запущенную на физически защищенном сервере, где она ведет базу данных с информацией по учётным записям всех главных абонентов безопасности (security principal) своей области ответственности. Под областью ответственности в сетях Windows 2000 и выше подразумевается домен, в дальнейшем, для удобства мы будем использовать этот термин. В базе данных KDC по мимо данных о каждом абоненте безопасности хранится и криптографический ключ, известный только абоненту и службе KDC. Этот ключ называется долговременным и используется для установления связи между пользователем системы безопасности и центра распределения ключей. Чаще всего при реализации протокола Kerberos долговременные ключи генерируются на основе пароля пользователя. Когда клиенту требуется обратиться к серверу, он сначала направляет запрос в KDC, который в свою очередь направляет каждому участнику предстоящего сеанса связи копии уникального сеансового ключа (session key), с коротким периодом действия. Назначение такого ключа в проведении аутентификации клиента и сервера. Копия ключа, направляемая на сервер шифруется при помощи долговременного ключа этого сервера, а направляемая клиенту соответственно с помощью долговременного ключа клиента.

Рисунок 2. Теоретическое управление ключами

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

РАЗДЕЛ 2. Система мандатов.

2.1 Сеансовые мандаты

При формировании ответа на запрос клиента, который намерен подключиться к удаленному серверу, служба KDC фактически направляет обе копии сеансового ключа (клиента и сервера) клиенту, причем сеансовый ключ клиента шифруется при помощи долговременного ключа клиента, а сеансовый ключ сервера вместе с информацией о клиенте формируется в блок данных, называющийся сеансовый мандат. Далее сеансовый мандат целиком шифруется с помощью долговременного ключа сервера, который как мы помним знаю лишь сервер и служба KDC.Таким образом обязанность обработки сеансового мандата, возлагается на клиента, который должен доставить его на сервер.

Рисунок 3. Схема аутентификации с использованием сеансового мандата.

Следует отметить, что в данном случае функции центра распределения ключей ограничиваются генерацией сеансового мандата и службе KDC более нет нужды отслеживать статусы доставки сообщений соответствующим адресатам. В случае же если какое-либо из сообщений попадет не по адресату, - ничего страшного не случится, так как расшифровать клиентскую копию сеансового ключа может только тот, кто владеет долговременным ключом клиента, а расшифровать сеансовый мандат способен тот только тот, кто владеет долговременным ключом сервера. Итак, получив ответ от KDС, клиентская машина извлекает из полученного блока сеансовый мандат и свою копию сеансового ключа, который помещает в безопасное хранилище в области оперативной памяти. В момент возникновения необходимости связаться с сервером, клиент посылает ему блок информации состоящий из сеансового мандата, который зашифрован долговременным ключом этого сервера и клиентского аутентификатора, зашифрованного с помощью сеансового ключа, полученного от KDC при первоначальном обращении к нему. Собственно, сам сеансовый мандат в комплексе с аутентификатором и является удостоверением, по которому сервер доподлинно определяет «личность» обратившегося к нему клиента.

Рисунок 4. Взаимная аутентификация клиент-сервер.

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

Используя такую схему связи с использованием сеансовых мандатов, сервере не нужно хранить сеансовые ключи для связи с клиентами, они хранятся в специальной кэш-памяти удостоверений (credetntials cache) клиентской машины, что является несомненным приемуществом. Сервре же, получив от клиента мандат, получает, расшифровав его, свою копию сеансового ключа. При миновании надобности в этом ключе, сервер попросту может стереть его из своей памяти.

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

2.2 Мандат на выдачу мандатов

Ранее отмечалось, что обычно долговременный ключ пользователя создается на основе его пароля. Когда Алёна проходит регистрацию, клиент клиент Kerberos, установленные у неё на машине, обрабатывает её пароль с помощью функции хэширования, при помощи одного из алгоритмов DES-CBC-MD5 или других. В результате на выходе получаем криптографический ключ. В KDC получившейся долговременный ключ Алёны хранится в базе данных с учетными данными пользователей. Получая запрос от клиента, KDC заглядывает в свою базу данных и находит в ней учетную запись нужного пользователя, в нашем примере Алёны, далее извлекая соответствующий пользователю долговременный ключ.

Процесс вычисления одной копии ключа по пользовательскому паролю и извлечения другой его копии из базы данных выполняется единожды за сеанс, при первом входе пользователя в сеть. После получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos на машине пользователя запрашивает сеансовый мандат и сеансовый ключ, котырые впоследствии и используются во все последующих транзакциях с KDC в течении текущего сеанса работы в сети. Для установления первичного сеанса связи с KDC, при первом обращении KDC отвечает специальным сеансовым мандатом, так называемый мандат на выдачу мандатов (ticket-granting ticket), или TGT мандат. Как и обычный сеансовый мандат, TGT имеет копию сеансового ключа для связи службы с клиентом (KDC-клиент). Манндат TGT шифруется при помощи долговременного ключа центра KDC, а клиентская копия сеансового ключа посредством долговременного ключа пользователя.

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