Криптография 2е издание Протоколы, алгоритмы и исходные тексты на языке С
 Скачать 3.25 Mb.
|
|
свою подлинность. Получение серверных мандатов Клиенту требуется получить отдельный мандат для каждой нужной ему услуги . 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-клиент: {K c,tgs {T c,tgs }K tgs }K c , 3. Клиент-TGS: {A c,s }K c,tgs {T c,tgs } K tgs,s 4. TGS-клиент: {K c,s {T c,s }K s }K c,tgs 5. Клиент-сервер: {A c,s }K c,s {T c,s }K s T c,s = {s, c, a, v, l, K c,s }K s A c,s = {c, a, t} K c,s Сообщения 1,3 и 5 не изменились. Двойное шифрование мандата на этапах 2 и 4 в версии 5 было устранено. Мандаты версии 5 дополнительно включают возможность использовать несколько адресов, а поле "время жи з- ни", l, заменено временем начала и окончания . В удостоверение версии пять добавлена возможность включения дополнительного ключа. Безопасность 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 и других специальных целей. Ключи могут быть DOU- BLE-ONLY (только двойные), правые и левые половины которых должны быть различны , DOUBLE (двойные) половины которых могут случайно совпасть , SINGLE-REPLICATED (одинарные-повторенные), в которых пр а- вые и левые половины равны, или SINGLE (одинарные), содержащие только 56 битов. CGA определяет аппа- ратную реализацию определенных типов ключей, используемых для некоторых операций . CV проверяется в безопасном аппаратном модуле : для каждой функции CGA вектор должен соответствовать определенным правилам. Если CV успешно проходит проверку, то при помощи XOR KEK или MK с CV полу- чается вариант KEK или MK, и извлеченный ключ для дешифрирования открытого текста сообщения использ у- ется только при выполнении функции CGA. При генерации новых ключей CV задает способ использования соз- данного ключа. Комбинации типов ключей, которые могут быть использованы для вскрытия системы, не со з- даются в CGA-совместимых системах и не импортируются в них. Для распределения ключей CGA применяет комбинацию криптографии с открытыми ключами и криптогр а- фии с секретными ключами. KDC шифрует сеансовый ключ для пользователя секретным главным ключом, ра з- деляемым с этим пользователем. Распределение главных ключей происходит с помощью криптографии с о т- крытыми ключами. Разработчики системы выбрали такой гибридный подход по двум причинам . Первой из них является эффек- тивность. Криптография с открытыми ключами требует больших вычислительных ресурсов, если сеансовые ключи распределяются с помощью криптографии с открытыми ключами, система может повиснуть. Второй причиной является обратная совместимость, система может быть с минимальными последствиями установлена поверх существующих схем с секретными ключами . CGA-системы проектировались так, чтобы они могли взаимодействовать с различными другими системами . При контакте с несовместимыми системами функция трансляции вектора управления (Control Vector Translate, CVXLT) позволяет системам обмениваться ключами . Инициализация функции CVXLT требует контроля с обе- их сторон. Каждая из них должна независимо установить нужные таблицы трансляции . Такой двойной контроль обеспечивает высокую степень надежности, касающейся целостности и происхождения ключей, импортируемых в систему. Тип ключа DATA поддерживается для совместимости с другими системами . Ключ типа DATA хранится вместе с соответствующим CV, указывающим, что это ключ типа DATA. Ключи типа DATA могут использо- ваться достаточно широко, и поэтому к ним нужно относиться с подозрением и использовать их с осторожн о- стью. Ключи типа DATA нельзя использовать ни для каких функций управления ключ ами. Аппаратура закрытия коммерческих данных (Commercial Data Masking Facility, CDMF) представляет собой экспортируемую версию CGA. Ее особенностью является уменьшение эффективной длины ключей DES до раз- решенных к экспорту 40 битов (см. раздел 15.5) [785]. 24.9 Схема проверки подлинности ISO Для использования в схеме проверки подлинности ISO, также известной как протоколы X.509, рекомендует- ся криптография с открытыми ключами [304]. Эта схема обеспечивает проверку подлинности по сети . Хотя конкретный алгоритм не определен ни для обеспечения безопасности, ни для проверки подлинности, специф и- кация рекомендует использовать RSA. Однако возможно использование нескольких алгоритмов и хэш-функций . Первоначальный вариант X.509 был выпущен в 1988 г. После открытого изучения и комментирования он был пересмотрен в 1993 году, чтобы исправить некоторые изъяны в безопасности [1100, 750]. Версия Последовательный номер Идентификатор алгоритма - Алгоритм - Параметры Выдавшая организация Время действия - начало действия - гонец действия Субъект Открытый ключ субъекта - Алгоритм - Параметры - Открытый ключ Подпись Рис. 24-2. Сертификат X.509. Сертификаты Наиболее важной частью X.509 используемая им структура сертификатов открытых ключей . Имена всех пользователей различны. Доверенный Орган сертификации (Certification Authority, CA) присваивает каждому пользователю уникальное имя и выдает подписанный сертификат, содержащий имя и открытый ключ пользов а- теля. Структура сертификата X.509 показана на 22-й [304]. Поле версии определяет формат сертификата . Последовательный номер уникален для конкретного CA. Сле- дующее поле определяет алгоритм, использованный для подписи сертификата , вместе со всеми необходимыми параметрами. Выдавшей организацией является CA. Срок действия представляет собой пару дат, сертификат действителен в промежутке между этими двумя датами . Субъект - это имя пользователя. Информация об от- крытом ключе включает название алгоритма, все необходимые параметры и открытый ключ . Последним полем является подпись CA. Если Алиса хочет связаться с Бобом, она сначала извлекает из базы данных его сертификат и проверяет его достоверность. Если у них общий CA, то все просто. Алиса проверяет подпись CA на сертификате Боба. Если они пользуются различными CA, то все гораздо сложнее. Представьте себе древовидную структуру, в которой одни CA сертифицируют другие CA и пользователей. На самом верху находится главный CA. У каждо- го CA есть сертификаты, подписанные вышестоящим CA и нижестоящим CA. При проверке сертификата Боба Алиса использует эти сертификаты. Такая схема продемонстрирована на 21-й. Сертификат Алисы заверен CA А, сертификат Боба заверен CA В Алиса знает открытый ключ CA А . У CA C есть сертификат, подписанный CA А , поэтому Алиса может проверить это. У CA С есть сертификат, подписанный CA D . И сертификат Боба подписан CA D . Подымаясь по дереву серти- фикации до общей точки, в данном случае CA D , Алиса может проверить сертификат Боба. +) + +) ) +) , +) * +) - Боб Алиса Рис. 24-3. Пример иерархии сертификации. Сертификаты могут храниться в базах данных на различных узлах сети . Пользователи могут посылать их друг другу. Истечении срока действия сертификата он должен быть удален из всех общедоступных каталогов . Однако CA, выдавший сертификат, должен продолжать хранить его копию, которая может потребоваться при разрешении возможных споров. Сертификаты также могут быть отозваны, либо из-за компрометации ключа пользователя, либо из-за того, что CA больше не хочет подтверждать сертификат данного пользователя . Каждый CA должен поддерживать список всех отозванных сертификатов, срок действия которых еще не закончился . Когда Алиса получает новый сертификат, она должна проверить, не был ли он отозван . Она может проверить базу данных отозванных кл ю- чей по сети, но скорей всего она проверит локально кэшируемый перечень отозванных сертификатов . В такой системе определенно вероятны злоупотребления, отзыв сертификатов возможно является самой слабой частью |