KRYPTOKNIGHT

KryptoKnight (КриптоРыцарь) является системой проверки подлинности и распределения ключей, разраб о-танной в IBM. Это протокол с секретным ключом, использующий либо DES в режиме СВС (см. раздел 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 в режиме СВС, который оставляет незашифрованным половину открытого текста. В защиту разработчиков надо сказать, что они собирались использовать DES, но французское правительство выразило неудовольствие по этому поводу. Они утвердили код с DES, но затем убрали его. Эта система меня не впечатли­ла.

Отождествление в SESAME является функцией первого блока, а не всего сообщения. В результате этого то­ждественность сообщений будет проверена по словам "Dear Sir", а не по всему содержанию сообщений. Генера­ция ключей состоит из двух вызовов функции rand операционной системы UNIX, которая совсем не случайна. В качестве однонаправленных хэш-функций SESAME использует сгс32 и 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, КЕК). Управление КЕК осуществляется с помощью внутренних ключевых маркеров. Ключи разделяются на группы в соответствии с их использованием .

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

CV проверяется в безопасном аппаратном модуле: для каждой функции CGA вектор должен соответствовать определенным правилам. Если CV успешно проходит проверку, то при помощи XOR КЕК или МК с CV полу­чается вариант КЕК или МК, и извлеченный ключ для дешифрирования открытого текста сообщения использ у-ется только при выполнении функции 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, также известной как протоколы Х.509, рекомендует­ся криптография с открытыми ключами [304]. Эта схема обеспечивает проверку подлинности по сети. Хотя конкретный алгоритм не определен ни для обеспечения безопасности, ни для проверки подлинности, специф и-кация рекомендует использовать RSA. Однако возможно использование нескольких алгоритмов и хэш-функций . Первоначальный вариант Х.509 был выпущен в 1988 г. После открытого изучения и комментирования он был пересмотрен в 1993 году, чтобы исправить некоторые изъяны в безопасности [1100, 750].

Версия

Последовательный номер Идентификатор алгоритма

- Алгоритм

- Параметры Выдавшая организация

Время действия

- начало действия

- гонец действия

Субъект Открытый ключ субъекта

- Алгоритм

- Параметры

- Открытый ключ

Подпись