Ольга Полянская - Инфраструктуры открытых ключей

• Название: Инфраструктуры открытых ключей
• Автор: Ольга Полянская
• Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру
• Жанр: Прочая околокомпьтерная литература
• Год: 2007
• ISBN: 978-5-9556-0081-9

В курс включены сведения, необходимые специалистам в области информационной безопасности. Рассматривается технология инфраструктур открытых ключей (Public Key Infrastructure – PKI), которая позволяет использовать сервисы шифрования и цифровой подписи согласованно с широким кругом приложений, функционирующих в среде открытых ключей. Технология PKI считается единственной, позволяющей применять методы подтверждения цифровой идентичности при работе в открытых сетях.

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

---

* способ доступа к информации УЦ ( Authority Access Info ).

Документ RFC 3280 Certificate & CRL Profile пока не рекомендует использовать дополнение Subject Directory Attributes, которое предназначено для доставки любых значений атрибутов каталога X.500, характеризующих субъект данного сертификата. Вместе с этим стандарт X.509 позволяет вводить любые другие дополнения, необходимость которых определяется их использованием в конкретной системе (например, в системе SET ).

Субъектом сертификата может быть конечный пользователь, система или УЦ. Основные поля сертификата одинаковы для всех субъектов. Различать субъекты сертификатов и оценивать возможность построения пути сертификации позволяет дополнение Basic Constraints (основные ограничения), используемое только для удостоверяющих центров.

Дополнение Key Usage (назначение ключа) отражает области применения секретного ключа, соответствующего указанному в сертификате открытому ключу. В одноименной графе (таблицы 6.1) перечислены возможные области применения ключа.

Дополнение Subject Alternative Name (альтернативное имя субъекта) позволяет расширить границы идентификации владельца сертификата при помощи альтернативных имен, таких как DNS-имена, IP-адреса, URI-адреса или адреса электронной почты Интернета. Альтернативное имя должно проверяться в соответствии с регламентом УЦ. Помимо зарегистрированных типов имен УЦ может использовать свои собственные имена, задавая их в поле Other Name. Аналогичная информация содержится и в дополнении Issuer Alternative Name, характеризующем издателя сертификата. Удостоверяющие центры могут иметь много пар ключей, и дополнение Authority Key Identifier (идентификатор ключа УЦ) помогает пользователям выбрать правильный ключ для верификации подписи на сертификате.

Пользователи также могут владеть несколькими парами ключей или несколькими сертификатами для одного и того же ключа. Дополнение Subject Key Identifier (идентификатор ключа субъекта) используется для того, чтобы различать ключи подписи в сертификатах одного и того же владельца.

Дополнение CRL Distribution Point (пункт распространения САС) задает унифицированный идентификатор ресурса (Uniform Resource Identifier - URI) для указания местонахождения списка аннулированных сертификатов, то есть определяет пункт распространения САС.

Организации могут поддерживать широкий круг приложений, использующих PKI. Некоторые сертификаты бывают надежнее других в зависимости от процедур их выпуска или типов криптографических модулей пользователей. Различные организации (компании или правительственные агентства) используют разные политики применения сертификатов, пользователи при этом не всегда способны их различить, но при принятии решения могут ориентироваться на дополнение Certificate Policies (политики применения сертификата). Это дополнение содержит абсолютно уникальный идентификатор объекта (Object Identifier - OID), характеризующий политику применения сертификатов, в соответствии с которой был выпущен данный сертификат, и назначение сертификата. Признак критичности в поле Certificate Policies ограничивает использование сертификата одной из идентифицируемых политик - тем самым УЦ декларирует, что выпущенный им сертификат должен применяться в соответствии с положениями одной из указанных в списке политик. Это может защитить УЦ от материальных претензий доверяющей стороны, которая использовала сертификат не по тому назначению или не тем способом, которые установлены политикой применения сертификатов, указанной в сертификате.

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

Дополнение Policy Mappings (соответствие политик) используется, если субъектом сертификата является УЦ. С помощью этого дополнения можно устанавливать соответствие между политиками применения сертификатов разных удостоверяющих центров.

Пример 6.1. Пусть корпорация ACE заключает соглашение с корпорацией ABC о кросс-сертификации с целью защиты электронного обмена данными [167]. Каждая компания имеет свою политику безопасности финансовых транзакций. Очевидно, что просто генерация кросс-сертификатов не обеспечит необходимой функциональной совместимости, так как в каждой компании конфигурирование финансовых приложений и выпуск сертификатов для служащих осуществляются согласно собственной политике. Одно из возможных решений - переконфигурирование всех финансовых приложений и повторный выпуск всех сертификатов в соответствии с требованиями обеих политик. Другим, более простым решением может быть использование дополнения Policy Mappings. Если поле этого дополнения включает кросс-сертификат, выпущенный УЦ компании ACE для УЦ компании ABC, то политика безопасности финансовых транзакций компании ABC считается эквивалентной одноименной политике компании ACE.

Выпуск сертификата одним УЦ для другого является подтверждением надежности сертификатов последнего. Существует три основных способа подтвердить надежность некоторого множества сертификатов. Во-первых, это можно сделать при помощи дополнения Basic Constraints (описанного выше). Второй способ состоит в описании множества сертификатов на основании имен, указанных в поле имени субъекта или альтернативного имени субъекта, в дополнении Name Constraints (ограничения на имена). Это дополнение может использоваться для задания множества допустимых имен или множества неразрешенных имен.

В-третьих, для описания множества сертификатов на основании ограничений политик можно использовать дополнение Policy Constraints (ограничения политик). Это дополнение используется только в сертификатах УЦ и задает проверку пути к политике, запрашивая идентификаторы политик и (или) запрещая задание соответствия политик [2]. Если УЦ выдает универсально надежные сертификаты, то нет необходимости явно указывать в них политики применения сертификатов. Если же сертификаты УЦ, признанного надежным в определенном домене, используются вне этого домена, то требуется явное указание политики применения во всех сертификатах пути сертификации. При помощи дополнения Policy Constraints можно объявить неправомерным дополнение Policy Mappings в том случае, когда сертификация выходит за пределы определенного домена. Это актуально для контроля рисков, возникающих из-за "транзитивного" доверия, когда домен A доверяет домену В, домен В доверяет домену С, но домен A не желает доверять домену С. Если ограничения политики применения сертификатов установлены, то пользователи не станут иметь дело с сертификатами, в которых не указаны определенные политики или дополнение Policy Constraints вообще отсутствует.

Дополнение Certificate Policies может сопровождаться спецификатором для указания в каждом сертификате дополнительной информации, независимой от политики применения сертификатов. Стандарт X.509 жестко не регламентирует назначение и синтаксис этого поля. Типы спецификаторов политики могут быть зарегистрированы любой организацией.

Стандартно используются следующие спецификаторы политики:

* а) CPS содержит ссылку в виде уникального идентификатора ресурса на опубликованный регламент УЦ (Certification Practice Statement - CPS), в соответствии с которым выпускался данный сертификат;

* б) User Notice содержит указатель на уведомление и/или текст уведомления, которое должно появляться на экране дисплея пользователя сертификата (включая подписчиков и доверяющие стороны) до использования сертификата и информировать о политике применения данного сертификата.

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

Альтернативные форматы сертификатов

Помимо сертификатов открытых ключей формата X.509 v3 существуют сертификаты и других форматов. Остановимся на сертификатах SPKI, PGP, SET и атрибутных сертификатах.