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-й. Сертификат Алисы заверен CAAj сертификат Боба заверен CA Алиса знает открытый ключ CAA. У CAC есть сертификат, подписанный CAA, поэтому Алиса может проверить это. У CAc; есть сертификат, подписанный CAD. И сертификат Боба подписан CAD. Подымаясь по дереву сертификации до общей точки, в данном случае CAD, Алиса может проверить сертификат Боба.

Рис. 24-3. Пример иерархии сертификации.

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

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

этой схемы.

Протоколы проверки подлинности

Алисе нужно связаться с Бобом. Сначала она извлекает из базы данных последовательность сертификации от Алисы до Боба и открытый ключ Боба. В этот момент Алиса может инициировать однопроходный, двухпроходный или трехпроходный протокол проверки подлинности .

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

В двухпроходном протоколе добавлен ответ Боба. Протокол устанавливает, что именно Боб, а не какой-то самозванец, посылает ответ. Он также обеспечивает безопасность обеих передач и защищает от вскрытия повтором.

И в однопроходных, и в двухпроходных алгоритмах используются метки времени . В трехпроходном протоколе добавляется еще одно сообщение Алисы Бобу и позволяет избежать меток времени (и, следовательно, пр а-вильного единого времени).

Однопроходный протокол:

(1)Алиса генерирует случайное число RA.

(2)Алиса создает сообщение, M = (TA, RA, 1B, d), где TA - метка времени Алисы, 1B - идентификатор Боба, d -произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Боба EB.

(3)Алиса посылает Бобу (CA, DA(M)). (CA - это сертификат Алисы, DA - это общий узел дерева сертификации.)

(4)Боб проверяет CA и получает EA. Он проверяет, что срок действия этих ключей еще не истек. (EA - это открытый ключ Алисы.)

(5)Боб использует EA для дешифрирования DA(M). Этим действием он проверяет и подпись Алисы, и целостность подписанной информации.

(6)Боб для точности проверяет 1B в M.

(7)Боб проверяет TA в M и убеждается, что сообщение является текущим.

(8)Дополнительно Боб может проверить RA в M по базе данных старых номеров, чтобы убедиться, что соо б-щение не является повторяемым старым сообщением .

Двухпроходный протокол состоит из однопроходного протокола и последующего аналогичного однопрохо д-ного протокола от Боба к Алисе. После выполнения этапов (1)-(8) однопроходного протокола двухпроходный протокол продолжается следующим образом :

(9)Боб генерирует случайное число RB.

(10)Боб создает сообщение M = (TB, RB, 1A, RA, d), где TB - метка времени Боба, 1A- идентификатор Алисы, а d - произвольные данные. Для безопасности данные могут быть зашифрованы открытым ключом Алисы EA. RA - случайное число Алисы, созданное на этапе (1).

(11)Боб посылает Алисе sends Да(М).

(12)Алиса использует EB, чтобы расшифровать Да(М). Таким образом одновременно проверяются подпись Боба и целостность подписанной информации .

(13)Алиса для точности проверяет 1A в

(14)Алиса проверяет в M и убеждается, что сообщение является текущим.

(15)Дополнительно Алиса может проверить в чтобы убедиться, что сообщение не является повторяемым старым сообщением.

Трехпроходный протокол решает ту же самую задачу, но без меток времени . Этапы (1) - (15) такие же, как в двухпроходном алгоритме, но TA = = 0.

(16)Алиса сверяет полученную версию RA с RA, которое было отправлено Бобу на этапе (3).

(17)Алиса посылает Бобу DA(R).

(18)Боб использует ЕА, чтобы расшифровать DA(R). Таким образом одновременно проверяются подпись Алисы и целостность подписанной информации .

(19)Алиса сверяет полученную версию RB с R, которое было отправлено Алисе на этапе (10).