Geum.ru


Разработка и программная реализация электронной цифровой подписи асимметричным методом шифрования данных

Дипломная работа - Компьютеры, программирование

Другие дипломы по предмету Компьютеры, программирование



?о центр знает соответствующий личный ключ. При этом выполняются следующие действия (их номера согласованы с номерами на рис. 1.3).

  1. Инициатор А посылает сообщение с меткой даты/времени авторитетному источнику открытых ключей с запросом о текущем открытом ключе участника В.
  2. Авторитетный источник отвечает сообщением, которое шифруется с использованием личного ключа авторитетного источника, KRаuth. Это сообщение инициатор А может дешифровать, используя открытый ключ авторитетного источника. Поэтому отправитель А может быть уверенным в том, что сообщение исходит от авторитетного источника. Это сообщение должно включать следующее:

-открытый ключ участника В, KUb, который участник А может использовать для шифрования сообщений, предназначенных для получателя В;

-оригинальный запрос, чтобы сторона А имела возможность сопоставить ответ с ранее отправленным запросом и убедиться, что запрос не был изменен на пути к авторитетному источнику;

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

  1. Инициатор А сохраняет открытый ключ участника В и использует его для шифрования сообщения, направляемого получателю В и содержащего идентификатор отправителя А (IDA) и оказию (N1), которая выступает вкачестве уникальной метки данного сообщения.
  2. Респондент В получает открытый ключ участника А от авторитетного источника точно таким же способом, каким отправитель А получил открытый ключ получателя В.

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

  1. Респондент В посылает сообщение инициатору А, шифрованное с помощью KU. и содержащее оказию отправителя А (N1), а также новую оказию, сгенерированную участником В (N2). Ввиду того что только он и мог де шифровать сообщение (3), присутствие N1 в сообщении (6) убеждает участника А в том, что отправителем полученного сообщения был В.

Рисунок 1.4 - iенарий распределения открытых ключей

  1. Инициатор А возвращает N2, шифрованное с помощью открытого ключа участника В, чтобы тот мог убедиться в том, что отправителем ответа является А.

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

Сертификаты открытых ключей

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

Альтернативный подход, который предложил Конфельдер (Kohnfelder) [KOHN78], основан на сертификатах, которые могут использоваться участниками для обмена ключами без контакта с авторитетным источником открытых ключей и должны обеспечивать способ обмена, такой же надежный, как способ получения ключей непосредственно от авторитетного источника открытых ключей. Каждый сертификат содержит открытый ключ и другую информацию, создается авторитетным источником сертификатов и выдается участнику вместе с соответствующим личным ключом. Один участник передает информацию о своем ключе другом; с помощью передачи своего сертификата. Другие участники мо гут проверить, что сертификат был создан авторитетным источником. Можно сформулировать следующие требования к этой схеме:

  1. Любой участник должен иметь возможность прочитать сертификат, чтобы определить имя и открытый ключ владельца сертификата.
  2. Любой участник должен иметь возможность проверить, что сертификат исходит из авторитетного источника сертификатов и не является подделкой.
  3. Только авторитетный источник сертификатов должен иметь возможность создавать и изменять сертификаты.

Все эти требования удовлетворялись первоначальной схемой из [KOHN78]. Деннинг (Denning) добавил к ним следующее дополнительное требование [DENN83].

4.Любой участник должен иметь возможность проверить срок действия сертификата.

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

CA=EKRauth[T, IDA, KUa],

где KR.auth обозначает личный ключ, используемый авторитетным источником. Теперь участник А может переслать этот сертификат любому другому участнику, который прочитывает и проверяет сертификат:

D KUauth [CA] = DKUauth[EKRauth[T, IDA, KUa] = (Т, IDA, KUa ).

Получатель исп