Протокол Нидхема Шредера

Вызывающий (исходный) объект обозначается через А, вызываемый (объект назначения) - через В. Участники сеанса А и В имеют уникальные идентификаторы ID_A и ID_В соответственно. Стороны А и В, каждая по отдельности, разделяют свой секретный ключ с сервером KDС.

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

1. А → KDС: ID_A ,ID_В;

Сторона А инициирует фазу распределения ключей, посылая по сети серверу KDС идентификаторы ID_A и ID_В:

2. KDС → A: Е_A(T, P, K, ID_В), Е_B(T, P, K, ID_A);

Сервер KDC генерирует сообщение с временной отметкой Т, сроком действия P, случайным сеансовым ключом К и идентификатором ID_A. Он шифрует это сообщение секретным ключом, который разделяет со стороной В. Затем сервер KDC берет временную отметку Т, срок действия P сеансовый ключ K, идентификатор ID_В стороны В и шифрует все это секретным ключом, который разделяет со стороной А. Оба эти зашифрованные сообщения он отправляет стороне А.

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

3. А → В: Е_K(ID_A,T), Е_B(T, P, K, ID_A);

Затем сторона А генерирует сообщение со своим идентификатором ID_A и отметкой времени Т, шифрует его сеансовым ключом К и отправляет стороне В. Кроме того, А отправляет для В сообщение от KDC, зашифрованное ключом стороны В.

Только сторона В может расшифровать эти сообщения. Сторона В получает отметку времени Т, срок действия Р, сеансовый ключ К и идентификатор ID_A.

Затем сторона В расшифровывает сеансовым ключом К вторую часть полученного сообщения. Совпадение значений Т и ID_A в двух частях сообщения подтверждает подлинность А по отношению к В.

4. B→A: Е_K(T+1)

Для взаимного подтверждения подлинности сторона В создает сообщение, состоящее из отметки времени Т плюс 1, шифрует его ключом К и отправляет стороне А.

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

Этот протокол успешно работает при условии, что часы каждого участника синхронизированы с часами сервера KDC. Следует отметить, что в этом протоколе необходим обмен с KDC для получения сеансового ключа каждый раз, когда А желает установить связь с В. Протокол обеспечивает надежное соединение объектов А и В при условии, что ни один из ключей не скомпрометирован и сервер KDC защищен.

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

Протокол Kerberos обеспечивает распределение ключей симметричного шифрования и проверку подлинности пользователей, работающих в незащищенной сети. Реализация Kerberos - это программная система, построенная по архитектуре "клиент-сервер". Клиентская часть устанавливается на все компьютеры защищаемой сети, кроме тех, на которые устанавливаются компоненты сервера Kerberos. В роли клиентов Kerberos могут, в частности, выступать и сетевые серверы (файловые серверы, серверы печати и т.д.).

Серверная часть Kerberos называется центром распределения ключей (англ. Key Distribution Center, сокр. KDC) и состоит из двух компонент:

1) сервер аутентификации (англ. Authentication Server, сокр. AS);

2) сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

Физически данные серверы могут быть совмещены. Информационными ресурсами, необходимыми клиентам С, управляет сервер информационных ресурсов SS. Предполагается, что серверы службы Kerberos надежно защищены от физического доступа злоумышленников.

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

Kerberos также создает сеансовые ключи, которые выдаются клиенту и серверу (или двум клиентам) и никому больше. Сеансовый ключ используется для шифрования сообщений, которыми обмениваются две стороны, и уничтожается после окончания сеанса.

Область действия системы Kerberos распространяется на тот участок сети, все пользователи которого зарегистрированы под своими именами и паролями в базе данных сервера Kerberos.

В общих чертах процесс идентификации и аутентификации пользователя в системе Kerberos версии 5 можно описать следующим образом (см. рис. 1).

Клиент С, желая получить доступ к ресурсу сети, направляет запрос серверу аутентификации AS. Сервер AS идентифицирует пользователя с помощью его имени и пароля и высылает клиенту мандат (ticket) на доступ к серверу службы выделения мандатов TGS (Ticket-Granting Service).

Для использования конкретного целевого сервера информационных ресурсов SS клиент С запрашивает у TGS мандат на обращение к целевому серверу SS. Если все в порядке, TGS разрешает использование необходимых ресурсов сети и посылает соответствующий мандат клиенту С.

Каждому субъекту сети сервер Kerberos назначает разделяемый с ним ключ симметричного шифрования и поддерживает базу данных субъектов и их секретных ключей. Схема функционирования протокола Kerberos представлена на рис. 1.

Рис.1.

Пусть клиент C собирается начать взаимодействие с сервером SS (англ. Service Server - сервер, предоставляющий сетевые сервисы). В несколько упрощенном виде, протокол предполагает следующие шаги:

1. C->AS: {c}.

На первом шаге клиент C посылает серверу аутентификации AS свой идентификатор C (идентификатор передается открытым текстом).

2. AS->C: {TGT}K_AS__TGS, K_C__TGS }K_C,

где:

K_C - основной ключ C;

K_C__TGS - ключ, выдаваемый C для доступа к серверу выдачи разрешений TGS;

{TGT} - Ticket Granting Ticket - мандат для доступа к серверу выдачи разрешений

{TGT}={c, tgs, t₁, p₁, K_C__TGS }, где tgs - идентификатор сервера выдачи разрешений, t₁ - отметка времени, p₁ - период действия мандата.

Запись {•}K_X здесь и далее означает, что содержимое фигурных скобок зашифровано на ключе K_X.

На втором шаге сервер аутентификации AS, проверив, что клиент C имеется в его базе, возвращает ему мандат для доступа к серверу выдачи разрешений и ключ для взаимодействия с сервером выдачи разрешений. Вся посылка зашифрована на ключе клиента C. Таким образом, даже если на первом шаге взаимодействия идентификатор "С" послал не клиент С, а нарушитель X, то полученную от AS посылку X расшифровать не сможет.

Получить доступ к содержимому мандата TGT не может не только нарушитель, но и клиент C, т.к. мандат зашифрован на ключе, который распределили между собой сервер аутентификации и сервер выдачи разрешений.

3. C->TGS: {TGT}K_AS__TGS, {Aut₁} K_C__TGS, {ID}

где {Aut₁} - аутентификационный блок - Aut₁ = {с, t₂}, t₂ - метка времени; ID - идентификатор запрашиваемого сервиса (в частности, это может быть идентификатор сервера SS).

На третьем шаге клиент C обращается к серверу выдачи разрешений ТGS. Он пересылает полученный от AS мандат, зашифрованный на ключе K_AS__TGS, аутентификационный блок, содержащий идентификатор C и метку времени, показывающую, когда была сформирована посылка и идентификатор запрашиваемого сервиса ID. Сервер выдачи разрешений расшифровывает мандат TGT и получает из него информацию о том, кому был выдан мандат, когда и на какой срок, ключ шифрования, сгенерированный сервером AS для взаимодействия между клиентом C и сервером TGS. С помощью этого ключа расшифровывается аутентификационный блок (аутентификатор). Если метка в блоке совпадает с меткой в мандате, это доказывает, что посылку сгенерировал на самом деле С (ведь только он знал ключ K_C__TGS и мог правильно зашифровать свой идентификатор). Далее делается проверка времени действия мандата и времени оправления посылки 3). Если проверка проходит и действующая в системе политика позволяет клиенту С обращаться к клиенту SS, тогда выполняется шаг 4).

4. TGS->C: {{TGS}K_TGS__SS, K_C__SS}K_C__TGS,

где K_C__SS - ключ для взаимодействия C и SS, {TGS} - Ticket Granting Service - мандат для доступа к SS (обратите внимание, что такой же аббревиатурой в описании протокола обозначается и сервер выдачи разрешений). {TGS} ={с, ss, t₃, p₂, K_C__SS }.

На четвертом шаге сервер выдачи разрешений TGS посылает клиенту C ключ шифрования и мандат, необходимые для доступа к серверу SS. Структура мандата такая же, как на шаге 2): идентификатор того, кому выдали мандат; идентификатор того, для кого выдали мандат; отметка времени; период действия; ключ шифрования.

5. C->SS: {TGS} K_TGS__SS, {Aut₂} K_C__SS

где Aut₂={c, t₄}.

На пятом шаге клиент C посылает мандат, полученный от сервера выдачи разрешений, и свой аутентификационный блок серверу SS, с которым хочет установить сеанс защищенного взаимодействия. Предполагается, что SS уже зарегистрировался в системе и распределил с сервером TGS ключ шифрования K_TGS__SS. Имея этот ключ, он может расшифровать мандат, из него получить ключ шифрования K_C__SS и проверить подлинность отправителя сообщения.

6. SS->C: {t₄+1} K_C__SS

Смысл последнего шага заключается в том, что теперь уже SS должен доказать C свою подлинность. Он может сделать это, показав, что правильно расшифровал предыдущее сообщение. Вот поэтому, SS берет отметку времени из аутентификационного блока C, изменяет ее заранее определенным образом (увеличивает на 1), шифрует на ключе K_C__SS и возвращает C.

Если все шаги выполнены правильно и все проверки прошли успешно, то стороны взаимодействия C и SS, во-первых, удостоверились в подлинности друг друга, а во-вторых, получили ключ шифрования для защиты сеанса связи - ключ K_C__SS.

Нужно отметить, что в процессе сеанса работы клиент проходит шаги 1) и 2) только один раз. Когда нужно получить мандат на доступ к другому серверу (назовем его SS1), клиент С обращается к серверу выдачи разрешений TGS с уже имеющимся у него мандатом, т.е. протокол выполняется начиная с шага 3).

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

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

Kerberos может использовать различные симметричные алгоритмы шифрования и хэш-функции, однако обязательными для поддержки установлены алгоритм шифрования 3-DES или AES и хэш-функция MD5.

В системе Kerberos используется два типа верительных документов: мандат и аутентификатор.

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

Аутентификатор (authenticator) - это дополнительный атрибут, предъявляемый вместе с мандатом.

Мандат предоставляется одному клиенту для доступа к строго определенному серверу и на строго определенное время. Он содержит идентификатор клиента (с), идентификатор сервера (ss), метку времени (t), время действия мандата (p) и сеансовый ключ (K_C__SS ). Мандат зашифрован на секретном ключе сервера.

Если клиент получил мандат, он может использовать его для доступа к данному серверу в течение промежутка времени, отведенного для данного мандата.

Клиент не может расшифровать мандат (он не знает секретного ключа сервера), но он может предъявить его серверу в зашифрованной форме. Никто из подслушивающих в сети не сможет прочитать или изменить мандат при передаче его по сети.

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

В отличие от мандата, аутентификатор используется только один раз. Однако клиент может генерировать аутентификаторы по мере надобности.

Использование аутентификатора преследует две цели.

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

На практике вся эта сложная процедура аутентификации производится автоматически.

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