Подпись

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

Алиса

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

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

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

этой схемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(13) Алиса для точности проверяет /А в M.

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

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

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

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

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

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

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

24.10 Почта с повышенной секретностью PRIVACY-ENHANCED MAIL (PEM)

Почта с повышенной секретностью ( Privacy-Enhanced Mail, PEM) представляет собой стандарт Internet для почты с повышенной секретностью, одобренный Советом по архитектуре Internet (Internet Architecture Board, IAB) для обеспечения безопасности электронной почты в Internet. Первоначальный вариант был разработан Группой секретности и безопасности (Privacy and Security Research Group, PSRG) Internet Resources Task Force (IRTF), а затем их разработка была передана в Рабочую группу PEM Internet Engineering Task Force (IETF) PEM Working Group. Протоколы PEM предназначены для шифрования, проверки подлинности, проверки цел о-стности сообщения и управления ключами .

Полностью протоколы PEM сначала были детально описаны в ряде RFC (Requests for Comment, Запросы комментариев) в [977] и затем пересмотрены в [978]. Третья итерация протоколов [979, 827, 980] сведена в [177, 178]. Протоколы были изменены и улучшены, и окончательные протоколы детально описываются в др у-гом наборе RFC [981, 825, 76, 802]. В другой статье Мэтью Бишопа (Matthew Bishop) [179] подробно описаны все изменения. Попытки реализации PEM рассматриваются в [602, 1505, 1522, 74, 351, 1366, 1367]. См. также

[1394].

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

PEM поддерживает только определенные алгоритмы, но позволяет добавлять и более поздние алгоритмы . Сообщения шифруются алгоритмом DES в режиме CBC. Проверка подлинности, обеспечиваемая средством Проверки целостности сообщения (Message Integrity Check, MIC), использует MD2 или MD5. Симметричное управление ключами может применять либо DES в режиме , либо тройной DES с двумя ключами (так называемый режим EDE). Для управления ключами PEM также поддерживает сертификаты открытых ключей, используя RSA (длина ключа до 1024 битов) и стандарт X.509 для структуры сертификатов.

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

Документы PEM

PEM определяется в следующих четырех документах:

- RFC 1421: Часть I, Процедуры шифрования и проверки подлинности сообщений . В этом документе определяются процедуры шифрования и проверки подлинности сообщений, которые должны обеспечить функции почты с повышенной секретностью для передачи электронной почты в Internet.

- RFC 1422: Часть II, Управление ключами с помощью сертификатов . В этом документе определяется архитектура и инфраструктура управления ключами, которые основаны на методе сертификатов открытых ключей, предоставляющих информацию о ключах отправителям и получателям сообщений .

- RFC 1423: Часть III, Алгоритмы, режимы и идентификаторы. Этот документ содержит определения, форматы, ссылки и цитаты для криптографических алгоритмов, режимов использования и связанных идентификаторов и параметров.

- RFC 1424: Часть IV, Сертификация ключей и родственные функции . В этом документе описываются три типа функций, поддерживаемых PEM: сертификация ключей, хранение и извлечение списка отозванных сертификатов (certificate revocation list, CRL).

Сертификаты

PEM совместим со схемой проверки подлинности, описанной в [304], см. также [826]. PEM представляет собой надмножество X.509, определяя процедуры и соглашения для инфраструктуры управления ключами, и с-пользуемой с PEM и в будущем другими протоколами (включая стеки TCP/IP и OSI).

Инфраструктура управления ключами использует общий корень для всей сертификации Internet. Центр регистрационной политики (Internet Policy Registration Authority, IPRA) определяет глобальную стратегию, применимую ко всей иерархии. Ниже корня - IPRA - находятся Центры сертификационной политики (Policy Certification Authorities, PCA), каждый из которых определяет и опубликовывает свою стратегию регистрации пользов а-телей и организаций. Каждый PCA сертифицирован IPRA. Следом за PCA идут CA, сертифицирующие пользо-