Реализация Kerberos в Windows 2000 поддерживает два алгоритма шифрования:
♦ DES — Data Encription Standard
Это первый официально предложенный правительством США стандарт в области шифрования, предназначенный для коммерческого использования. Длина ключа равна 64 битам, из которых 8 используются для контроля ошибок, и, следовательно, эффективная длина ключа равна 56 битам.
♦ RC4
Более быстрый алгоритм шифрования потока данных с ключом переменной длины. Именно этот алгоритм используется по умолчанию в Windows 2000 Kerberos. Длина ключа в версиях, используемых на территории США, равна 128 бит, а за пределами США — 56 бит.
• Проверка целостности данных
Здесь имеется ввиду, что получатель данных должен быть уверен, что в процессе передачи данные не были изменены. Реализация данного требования основана на вычислении контрольной суммы для каждого передаваемого пакета данных, которая в зашифрованном виде передается вместе с ним. Контрольная сумма есть значение некоторой функции от передаваемых данных, имеющей различные значения на различных данных. В Kerberos для вычисления контрольной суммы используется НМАС — Hash-based Message Authentication Code. Передача зашифрованной контрольной суммы гарантирует, что искажение (случайное или умышленное) передаваемых данных будет обнаружено на принимающей стороне.
• Шифрование трафика
Использование зашифрованных контрольных сумм гарантирует целостность передаваемых данных, но не защищает их от неавторизированного просмотра. Данную проблему решает шифрование всего трафика. Заметим, что попутно при этом решается и проблема проверки целостности данных и аутентификация. Только клиент или сервер, имеющий секретный ключ, может подготовить и/или прочитать передаваемые данные.
Упомянутые выше сервисы требуют определенных накладных расходов. Наиболее накладно шифрование трафика. Проверка целостности данных дороже аутентификации. При изучении собственно модели безопасности в СОМ+ мы увидим, что клиент и сервер совместно выбирают тот уровень безопасности, который удовлетворит их требования.
Основные сценарии использования сервисов Kerberos
В данном разделе рассматриваются основные сценарии, реализуемые в СОМ+, и способы, посредством которых Kerberos обеспечивает необходимый уровень безопасности. Но прежде всего надо остановиться на основной идее этого протокола.
Если каждая пара клиент-сервер имеют известные только им секретные ключи, то проблемы с обеспечением всех упомянутых выше сервисов нет. Проблема в масштабируемости такого подхода, в его надежности и удобстве.
Идея Kerberos состоит в том, что при обращении клиента к серверу первый должен предъявить второму специальный билет, доказывающий его идентичность и содержащий необходимую серверу информацию о правах данного клиента, о секретном ключе, используемом для шифровки пересылаемых данных, и т. п.
Рассмотрим основные поля данных билета:
• Нешифруемые поля
♦ Домен
Домен, где был выдан этот билет. Предполагается, что на контроллере домена запущен сервер Kerberos — KDS (Key Distribution Server), который и выдает все билеты в данном домене,
♦ Имя принципала
Принципалом здесь называется любая сущность, обладающая в данном домене именем и паролем. Это и все зарегистрированные в данном домене пользователи, и приложения, и машины. Все принципалы регистрируются на контролере домена в Active Directory, где в зашифрованном виде для каждого принципала хранится, в частности, его имя и хешированный пароль.
• Шифруемые поля
♦ Флаги билета
♦ Ключ сессии
Билет выдается клиенту для предъявления некоторому серверу. Именно этим ключом будут шифроваться данные, передаваемые между данными клиентом и сервером в текущей сессии (или пока не истекло время действия билета)
♦ Домен
♦ Имя принципала
Клиент не имеет доступа к зашифрованным полям билета. Сопоставляя Домен и Имя приципала в шифруемых и нешифруемых полях билета, сервер может заметить ситуацию, когда предъявляемый билет был выдан другому клиенту,
♦ Время выдачи билета
♦ Время прекращения действия билета
♦ Адреса хоста
Список IP адресов, с которых клиент может вызывать сервер
♦ Авторизационные данные
Эти данные используются сервером для определения прав данного клиента при вызове методов данного сервера.
Для дальнейшего изложения удобно использовать следующие обозначения:
• — секретный ключ принципала, полученный хешированием его пароля. В случае клиента, в случае сервера, в случае KDS
• — ключ сессии между и
• — данные, зашифрованные ключом
Вход пользователя в систему
Процесс входа пользователя в систему состоит из нескольких стадий
1. Ввод имени, домена и пароля
2. Запрос TGT (ticket-granting ticket) у KDS
Специальный билет TGT можно рассматривать как паспорт данного пользователя в данном домене (но принимаемый только KDS). При всех последующих обращениях к KDS в рамках данного сеанса клиентское приложение предъявляет KDS этот билет, доказывая идентичность пользователя. Запрос на получение TGT формируется автоматически и включает в себя
♦ Имя пользователя
♦ Временную метку — момент выдачи запроса, шифрованный ключом
3. Получение и ключа сессии между пользователем и KDS-
Получив запрос, KDC использует известные ему из Active Directory секретный ключ пользователя для расшифровки временной метки. Если расхождение между этой временной меткой и текущим временем по часам KDS не превышает 5 минут, делается вывод о том, что клиент аутентифицирован, т. к. только он мог воспользоваться секретным ключом для кодирования свежей временной метки.
Использование в протоколе Kerberos временной метки для аутентификации пользователя опционно и используется именно в реализации данного протокола в Windows 2000. При отсутствии временной метки аутентификация пользователя реально выполняется при попытке клиента расшифровать полученные от KDS данные, зашифрованные его секретным ключом, и получить ключ сессии между данным пользователем и KDS.
Билет TGT имеет структуру обычного билета. Заметим, что TGT зашифрован секретным ключом самого KDS. Никто кроме KDS, включая самого пользователя, не может прочитать шифрованные поля. В поле Ключ сессии этого билета содержится, что позволяет KDS не хранить ключи сессий со всеми своими клиентами. В поле Авторизационные данные содержатся взятые из Active Directory права данного пользователя и идентификаторы безопасности (SID) этого пользователя и всех групп, в которые он входит.
4. Запрос билета для локальных сервисов
Для обращения к локальным сервисам на машине пользователя последнему также необходим билет для локальных сервисов, который автоматически и запрашивается у KDS с предъявлением TGT.
5. Получение билета для локальных сервисов
С этого момента пользователь может обращаться к локальным сервисам, на чем вход в систему и завершается.
Аутентификация клиента удаленным серверным приложением
Данный процесс выполняется автоматически при вызове клиентским приложением удаленного сервера. Точнее, здесь описывается процесс, выполняемый при первом обращении клиента к серверу в данном сеансе. В зависимости от выбранных клиентом и сервером уровнях аутентификации (этот вопрос будет рассмотрен позже), аутентификация клиента сервером может выполняться с различной периодичностью, от однократной при первом вызове сервера до аутентификации при получении каждого нового пакета. При повторной аутентификации выполняется только часть из рассматриваемых ниже операций.