Схема проверки подлинности ISO

Для использования в схеме проверки подлинности ISO, также известной как протоколы X.509, рекомендуется криптография с открытыми ключами [304]. Эта схема обеспечивает проверку подлинности по сети. Хотя конкретный алгоритм не определен ни для обеспечения безопасности, ни для проверки подлинности, спецификация рекомендует использовать RSA. Однако возможно использование нескольких алгоритмов и хэш-функций. Первоначальный вариант X.509 был выпущен в 1988 г. После открытого изучения и комментирования он был пересмотрен в 1993 году, чтобы исправить некоторые изъяны в безопасности [1100, 750].

Рис. 22-2. Сертификат X.509.

Сертификаты

Наиболее важной частью X.509 используемая им структура сертификатов открытых ключей. Имена всех пользователей различны. Доверенный Орган сертификации (Certification Authority, CA) присваивает каждому пользователю уникальное имя и выдает подписанный сертификат, содержащий имя и открытый ключ пользователя. Структура сертификата X.509 показана на Рис. 22-2 [304].

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

Если Алиса хочет связаться с Бобом, она сначала извлекает из базы данных его сертификат и проверяет его достоверность. Если у них общий CA, то все просто. Алиса проверяет подпись CA на сертификате Боба.

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

Такая схема продемонстрирована на Рис. 22-3. Сертификат Алисы заверен CA_А, сертификат Боба заверен CA_В. Алиса знает открытый ключ CA_А. У CA_C есть сертификат, подписанный CA_А, поэтому Алиса может проверить это. У CA_С есть сертификат, подписанный CA_D. И сертификат Боба подписан CA_D. Подымаясь по дереву сертификации до общей точки, в данном случае CA_D, Алиса может проверить сертификат Боба.

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

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

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