Файл: Сервер аутентификации Kerberos (Цербер) (Понятие «Аутентификация» и его сущность).pdf

1. Центр распространения ключей.

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

KDC поддерживает базу данных, которая включает в себя информацию об учетной записи всех участников безопасности в своей системе. Криптографический ключ, который хранится в секрете между KDC и защитником, является одной из данных учетной записи в базе данных. Ключ обычно известен как долгосрочный ключ, который используется в общении между KDC и руководителем безопасности [10, 11].

Если клиент хочет связаться с сервером, он отправляет запрос в KDC. Затем KDC распределяет сеансовый ключ как для клиента, так и для сервера в зашифрованной форме, где копия клиента зашифровывается с долгосрочным ключом и серверной копией клиента с долгосрочным ключом сервера [8].

1. Передача ключа сеанса в сеансовых билетах.

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

Чтобы избежать этой ситуации, вместо отправки сеансового ключа на сервер KDC отправляет клиенту копию ключа в виде сеансового билета [3, 7, 8].

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

После получения ответа от KDC клиент отправляет сообщение серверу, когда он хочет общаться. В этом процессе взаимной аутентификации клиент отправляет сообщение, которое включает в себя аутентификатор, зашифрованный с помощью ключа сеанса, который был получен от KDC и сеансового билета. Теперь сеансовый билет и аутентификатор вместе становятся удостоверениями личности клиента [3, 4, 8].

Когда сервер получает сообщение, он расшифровывает сеансовый билет, используя секретный ключ (долгосрочный ключ сервера), который совместно используется сервером и KDC. Затем извлекая ключ сеанса для дешифрования аутентификатора. После проверки временной отметки клиента, это ответ с зашифрованной меткой времени, как описано в шаге 1.

1. «Билетные билеты».

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

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

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

1. Служба обмена билетами.

Теперь клиент должен получить билет сеанса из KDC, чтобы запросить услугу с сервера. Здесь клиент отправляет сообщение, которое включает TGT и аутентификатор, который зашифрован с использованием ключа сеанса, совместно используемого клиентом и KDC. Работа KDC делится на две части для работы по перекрестному домену [7, 8].

Как только KDC получает сообщение клиента, служба выдачи билетов проверяет запрос и отправляет билет сеанса и ключ сеанса, как описано в шаге 3.

Использование методов аутентификации, которые не раскрывают удостоверения личности, является обязательным. Протокол Kerberos хорошо подходит для таких операций, поэтому использование Kerberos является серьезным инструментом для обеспечения безопасности связи.

Что касается реализации протокола Kerberos в Windows, то надо отметить следующее:

1. Ключ пользователя генерируется на базе его пароля. Таким образом, при использовании слабых паролей эффект от надежной защиты процесса аутентификации будет сведен к нулю.
2. В роли Kerberos-серверов выступают контроллеры домена, на каждом из которых должна работать служба Kerberos Key Distribution Center (KDC). Роль хранилища информации о пользователях и паролях берет на себя служба каталога Active Directory. Ключ, который разделяют между собой сервер аутентификации и сервер выдачи разрешений формируется на основе пароля служебной учетной записи krbtgt - эта запись автоматически создается при организации домена и всегда заблокирована.
3. Microsoft в своих ОС использует расширение Kerberos для применения криптографии с открытым ключом. Это позволяет осуществлять регистрацию в домене и с помощью смарт-карт, хранящих ключевую информацию и цифровой сертификат пользователя.
4. Использование Kerberos требует синхронизации внутренних часов компьютеров, входящих в домен Windows.

В рамках данной главы были рассмотрены основные концепции и принципы работы сервера аутентификации Kerberos.

ЗАКЛЮЧЕНИЕ

В рамках работы решены следующие задачи:

• изучена литература в области аутентификации и идентификации;
• раскрыто понятие «аутентификация» и «идентификация»;
• проанализированы основные протоколы аутентификации;
• изучена основная концепция Kerberos;
• проанализированы принципы работы Kerberos.

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

Рассмотренные протоколы идентификации дают понять, что существующие протоколы, в полной мере покрывают требования современных систем, однако для каждой задачи и сфере будет наиболее правильным выбрать тот, или иной вариант протокола.