Клиент посылает сообщение, содержащее его имя и имя его сервера TGS на сервер проверки подлинности Kerberos. (может быть несколько серверов TGS.) На практике пользователь, скорее всего, просто вводит свое имя и программа входа в систему посылает запрос .

Сервер проверки подлинности Kerberos ищет данные о клиенте в своей базе данных. Если информация о клиенте есть в базе данных, Kerberos генерирует сеансовый ключ, который будет использоваться для обмена данными между клиентом и TGS. Он называется Мандатом на выделение мандата (Ticket Granting Ticket, TGT). Kerberos шифрует этот сеансовый ключ секретным ключом клиента . Затем он создает для клиента TGT, доказывающий подлинность клиента TGS, и шифрует его секретным ключом TGS. Сервер проверки подлинности посылает эти два зашифрованных сообщения клиенту .

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

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

Получение серверных мандатов

Клиенту требуется получить отдельный мандат для каждой нужной ему услуги . TGS выделяет мандаты для отдельных серверов.

Когда клиенту нужен мандат, которого у него пока нет, он посылает запрос к TGS. (На практике программа, скорее всего, делает это автоматически и незаметно для пользователя .)

TGS, получив запрос, расшифровывает TGT своим секретным ключом. Затем TGS использует включенный в TGT сеансовый ключ, чтобы расшифровать удостоверение . Наконец TGS сравнивает информацию удостоверения с информацией мандата, сетевой адрес клиента с адресом отправителя запроса и метку времени с текущим временем. Если все совпадает, TGS разрешает выполнение запроса.

Проверка меток времени предполагает, что часы всех компьютеров синхронизированы, по крайней мере с точностью до нескольких минут. Если время, указанное в запросе, отстоит от текущего момента слишком дал е-ко в прошлое или в будущее, TGS считает запрос попыткой повторения предыдущего запроса . TGS должна также отслеживать правильность сроков действия удостоверений , так как услуги сервера могут запрашиваться н е-сколько раз последовательно с одним мандатом, но разными удостоверениями . Другой запрос с тем же мандатом и уже использованной меткой времени удостовер ения будет отвергнут.

В ответ на правильный запрос TGS возвращает правильный мандат, который клиент может предъявить се р-веру. TGS также создает новый сеансовый ключ для клиента и сервера , зашифрованный сеансовым ключом, общим для клиента и TGS. Оба этих сообщения отправляются клиенту. Клиент расшифровывает сообщение и извлекает сеансовый ключ.

Запрос услуги

Теперь клиент может доказать свою подлинность серверу . Он создает сообщение, очень похожее на то, кот о-рое посылалось TGS (и это понятно, так как TGS - тоже услуга).

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

Сервер расшифровывает и проверяет мандат и удостоверение, как уже обсуждалось, а также проверяет адрес клиента и метку времени. Если все в порядке, то сервер уверен, что, согласно Kerberos, клиент - именно тот, за кого он себя выдает.

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

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

Kerberos версии 4

В предыдущих разделах рассматривался Kerberos версии 5. Версия 4 немного отличается сообщениями и конструкцией мандатов и удостоверений . В Kerberos версии 4 используются следующие пять сообщений :

1.Клиент-Kerberos: c,tgs

2.Kerberos-клиент: {Kc,tgs{Tc,tgs}Ktgs}K„

3.Клиент-TGS: {Ac,s}Kc,tgs{Tc,tgs} Kgs,s

4.TGS-клиент: {Kc,s{Tc,s}Ks}Kc,tgs

5.Клиент-сервер: {Ac,s}Kc,s {Tc,s}K

Tc,s = {s, c, a, v, /, Kc,s}Ks

Ac,s = {c a, t} Kc,s

Сообщения 1,3 и 5 не изменились. Двойное шифрование мандата на этапах 2 и 4 в версии 5 было устранено. Мандаты версии 5 дополнительно включают возможность использовать несколько адресов, а поле "время жи з-ни", /, заменено временем начала и окончания. В удостоверение версии пять добавлена возможность включения дополнительного ключа.

Безопасность Kerberos

Стив Белловин (Steve Bellovin) и Майкл Мерритт (Michael Merritt) проанализировали некоторые потенциальные уязвимые места Kerberos [108]. Хотя эта работа была написана про протоколы версии 4, многие ее замечания применимы и к версии 5 .

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

Использование удостоверений основаны на том, что все часы сети более или менее синхронизированы . Если время компьютера будет установлено неправильно , то старое удостоверение может быть использовано без пр о-блем. Большинство сетевых протоколов поддержки единого времени небезопасны, поэтому такая возможность представляет собой серьезную проблему.

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

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

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

Лицензии

Kerberos не является общедоступным, но код МТИ доступен свободно . Действительная реализация в раб о-тающих системах UNIX - это совсем другая история. Ряд компаний продает версии Kerberos, но можно получить хорошую версию бесплатно от Cygnus Support, 814 University Ave., Pale Alto, CA, 94301; (415) 32,2.-3811; fax: (415) 32.2.-3270.

24.6 KRYPTOKNIGHT

KryptoKnight (КриптоРыцарь) является системой проверки подлинности и распределения ключей, разраб о-танной в IBM. Это протокол с секретным ключом, использующий либо DES в режиме CBC (см. раздел 9.3) или модифицированную версию MD5 (см. раздел 18.5). KryptoKnight поддерживает четыре сервиса безопасности:

-Проверка подлинности пользователя (называемая единственной подписью - single sign-on)

-Двусторонняя проверка подлинности

-Распределение ключей

-Проверка подлинности содержания и происхождения данных

С точки зрения пользователя, KryptoKnight похож на Kerberos. Вот некоторые отличия:

-Для проверки подлинности и шифрования мандатов KryptoKnight использует хэш-функцию.

-KryptoKnight не использует синхронизированных часов, используются только текущие запросы (см. раздел 3.3).

-Если Алисе нужно связаться с Бобом , одна из опций KryptoKnight позволяет Алисе послать сообщение Бобу, а затем позволяет Бобу начать протокол обмена ключами .

KryptoKnight, как и Kerberos, использует мандаты и удостоверения. Он содержит и TGS, но в KryptoKnight называются серверами проверки подлинности. Разработчики KryptoKnight потратили немало усилий, миним и-зируя количество сообщений, их размер и объем шифрования. О KryptoKnight читайте в [1110, 173, 174, 175].

24.7 SESAME

SESAME означает Secure European System for Applications in a Multivendor Environment - Безопасная европейская система для приложений в неоднородных средах . Это проект Европейского сообщества, на 50 процентов финансируемый RACE (см. раздел 25.7), главной целью которой является разработка технологии для проверки подлинности пользователя при распределенном контроле доступа . Эту систему можно рассматривать как европейский вариант Kerberos. Проект состоит из двух частей: на первой стадии разрабатывается базовая архитектура, а вторая стадия представляет собой ряд коммерческих проектов . Следующие три компании принимают наибольшее участие в разработке системы - ICL в Великобритании, Siemens в Германии и Bull во Франции.

SESAME представляет собой систему проверки подлинности и обмена ключами [361, 1248, 797, 1043]. Она использует протокол Needham-Schroeder, применяя криптографию с открытыми ключами для свзи между ра з-личными безопасными доменами . В системе есть ряд серьезных изъянов . Вместо использования настоящего алгоритма шифрования в этой системе применяется XOR с 64-битовым ключом. Что еще хуже, в SESAME используется XOR в режиме CBC, который оставляет незашифрованным половину открытого текста. В защиту разработчиков надо сказать, что они собирались использовать DES, но французское правительство выразило неудовольствие по этому поводу. Они утвердили код с DES, но затем убрали его. Эта система меня не впечатлила.

Отождествление в SESAME является функцией первого блока, а не всего сообщения. В результате этого тождественность сообщений будет проверена по словам "Dear Sir, а не по всему содержанию сообщений. Генерация ключей состоит из двух вызовов функции rand операционной системы UNIX, которая совсем не случайна. В качестве однонаправленных хэш-функций SESAME использует crc32 и MD5. И конечно, SESAME подобно Kerberos чувствительна к угадыванию паролей.

24.8 Общая криптографическая архитектура IBM

Общая криптографическая архитектура ( Common Cryptographic Architecture , CCA) была разработана компанией IBM, чтобы обеспечить криптографические прим итивы для конфиденциальности, целостности, управления ключами и обработки персонального идентификационного кода (PIN) [751, 784, 1025, 1026, 940, 752]. Управление ключами происходит с помощью векторов управления (control vector, CV) (см. раздел 8.5). Каждому ключу соответствует CV, с которым ключ объединен операцией XOR. Ключ и CV разделяются только в безопасном аппаратном модуле . CV представляет собой структуру данных, обеспечивающую интуитивное п о-нимание привилегий, связанных с конкретным ключом .

Отдельные биты CV обладают конкретным смыслом при использовании каждого ключа, применяемого в CGA. CV передаются вместе с зашифрованным ключом в структурах данных, называемых ключевыми марк ерами (key token). Внутренние ключевые маркеры используются локально и содержат ключи, шифрованные л о-кальным главным ключом ( master key, MK). Внешние ключевые маркеры используются для шифрованными ключами между системами. Ключи во внешних ключевых маркерах зашифрованы ключами шифрования кл ю-чей (key-encrypting key, KEK). Управление KEK осуществляется с помощью внутренних ключевых маркеров . Ключи разделяются на группы в соответствии с их использованием .

Длина ключа также задается при помощи битов CV. Ключи одинарной длины - 56-битовые - используются для таких функций, как обеспечение конфиденциальности и сообщений. Ключи двойной длины - 112-битовые -применяются для управления ключами, функций PIN и других специальных целей. Ключи могут быть DOUBLE-ONLY (только двойные), правые и левые половины которых должны быть различны , DOUBLE (двойные) половины которых могут случайно совпасть, SINGLE-REPLICATED (одинарные-повторенные), в которых пр а-вые и левые половины равны, или SINGLE (одинарные), содержащие только 56 битов. CGA определяет аппаратную реализацию определенных типов ключей, используемых для некоторых операций .