Инфраструктуры открытых ключей - читать бесплатно онлайн полную версию книги автора Ольга Юрьевна Полянская (Лекция 7. Классификация сертификатов и управление ими) #8

Лекция 7. Классификация сертификатов и управление ими

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

Классы сертификатов

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

Можно выделить три класса сертификатов открытых ключей:

* сертификаты конечных субъектов;

* сертификаты удостоверяющих центров;

* самоподписанные сертификаты.

Внутри каждого класса существует несколько типов сертификатов, все они представлены на рис. 7.1. Рассмотрим их последовательно.

Рис. 7.1. Классификация сертификатов открытых ключей

Сертификаты конечных субъектов

Эти сертификаты выпускаются для субъектов, не являющихся удостоверяющими центрами, и содержат открытые ключи, при помощи которых пользователи сертификатов могут верифицировать цифровые подписи и управлять ключами. Сертификаты должны предоставлять пользователям информацию о назначении открытых ключей, достаточную для принятия решения о пригодности данного ключа для конкретного приложения. Субъектом сертификатов этого класса может быть человек или система (например, web-сервер или маршрутизатор). Рекомендуемые профили сертификатов варьируются в зависимости от типа субъекта [70].

Сертификаты пользователей

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

1 использовать в качестве имени субъекта отличительное имя (отличительное имя стандарта X.500 или DNS-имя);

2 устанавливать срок действия сертификата не более 3 лет, начиная с момента его выпуска (в противном случае чрезмерно разрастаются списки САС);

3 задавать дополнение Key Usage (назначение ключа) как критичное. В нем должно указываться: для открытых ключей подписи - их назначение: цифровая подпись или поддержка неотказуемости; для открытых ключей, связанных с алгоритмами Диффи-Хэллмана, эллиптических кривых Диффи-Хэллмана и обмена ключами, - согласование ключей; для RSA-ключей транспортировки ключей - шифрование ключей;

4 задавать дополнение Certificate Policies (политики применения сертификатов) как некритичное; дополнение должно определять одну политику и не содержать никаких спецификаторов политики;

5 задавать дополнение Subject Alternative Name (альтернативное имя субъекта) как некритичное; для приложений защищенной электронной почты S/MIME v3 в качестве альтернативного имени в дополнении должен указываться адрес электронной почты.

В соответствии с требованиями конкретной локальной среды в сертификате могут содержаться и другие дополнения, которые должны быть помечены как некритичные.

Сертификаты систем

К сертификатам систем можно отнести, например, VPN-сертификаты, сертификаты устройств (в том числе и беспроводной связи) и SSL-сертификаты [105].

VPN-сертификаты (IPsec). Эти сертификаты генерируются на основе информации об устройстве (например, IP-адреса) и подписываются человеком от имени устройства (путем ручной или автоматизированной процедуры).

Сертификаты устройств. Эти сертификаты связаны с определенным устройством (например, кабельным модемом), генерируются и физически размещаются в некоторой постоянной памяти устройства. Как правило, имеют длительный срок действия, сопоставимый со сроком жизни устройства. Такие сертификаты обычно не обновляются, потому что их физически трудно заменить.

Сертификаты устройств беспроводной связи. Эти сертификаты предназначены для поддержки функциональности SSL-типа применительно к небольшим устройствам и процессорам. В качестве примера можно привести краткосрочные сертификаты WTLS (Wireless Transport Layer Security). На базе основного SSL-сертификата программной системой промежуточного слоя выпускаются временные сертификаты для конечных устройств. Когда основной сертификат аннулируется или заканчивается его срок действия, ПО промежуточного слоя приостанавливает выпуск следующих сертификатов.

SSL-сертификаты. Эти сертификаты генерируются Web-сервером и используются для связывания адреса и программного обеспечения определенного Web-сервера. Сертификаты не только обеспечивают SSL-туннель к обращающемуся с запросом браузеру клиента, но и позволяют определять, принадлежит ли данный унифицированный указатель ресурсов (URL) той организации, которая предъявляет этот URL хосту. Недавно появилась возможность реализовать концепцию "распределенных сертификатов", согласно которой один SSL-сертификат может распределяться между несколькими машинами Web-сервера.

Для поддержки онлайновых приложений в профиль сертификата компьютерной системы включается информация об именах. К содержанию сертификата системы предъявляются те же требования, что и к содержанию сертификата пользователя, за исключением того, что дополнение Subject Alternative Name в качестве альтернативного имени должно задавать DNS-имя компьютера ( dNSname ) или IP-адрес ( iPAddress ), если система является маршрутизатором. Кроме этого, дополнение Extended Key Usage (расширенное назначение ключа) должно задаваться как некритичное, если система является web-сервером, поддерживающим протоколы SSL или TLS, или маршрутизатором, поддерживающим протокол IPsec.

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

Сертификаты удостоверяющих центров

Эти сертификаты выпускаются для субъектов, являющихся удостоверяющими центрами, и образуют узлы пути сертификации [123]. Открытые ключи в этих сертификатах используются для верификации цифровых подписей на сертификатах других субъектов или списках САС. Сертификаты должны предоставлять пользователям информацию, достаточную для построения путей сертификации и локальных списков САС. Субъектом сертификата может быть УЦ внутри данной корпоративной PKI, УЦ внешней корпоративной PKI и мостовой УЦ. Рекомендуемые профили сертификатов варьируются в зависимости от типа субъекта.

Сертификаты удостоверяющих центров корпоративной PKI

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

1 использовать в качестве имени субъекта отличительное имя (отличительное имя стандарта X.500 или DNS-имя); имя субъекта должно быть образовано только из рекомендуемых атрибутов имен каталогов, а любая часть имени субъекта, совпадающая с именем издателя, должна быть задана тем же типом строки;

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

3 не использовать открытые ключи, связанные с алгоритмами Диффи-Хэллмана, эллиптических кривых Диффи-Хэллмана и обмена ключами; если используется RSA-ключ, то в качестве его назначения не должна указываться транспортировка ключей;

4 задавать дополнение Basic Constraints (основные ограничения) как критичное; устанавливать параметр cA в значение TRUE ; если корпоративная PKI является иерархической, то указывать значение длины пути;

5 задавать дополнение Key Usage (назначение ключа) как критичное, указывать значения: подписание сертификата открытого ключа и подписание САС;

6 задавать дополнение Certificate Policies (политики применения сертификатов) как некритичное; в нем должны быть перечислены все политики, которые УЦ субъекта может включать в подчиненные сертификаты; перечисленные политики не должны содержать никаких спецификаторов;

7 задавать дополнение Subject Key Identifier (идентификатор ключа субъекта) как некритичное; его значение должно сравниваться со значением дополнения Authority Key Identifier (идентификатор ключа УЦ) в сертификатах, изданных УЦ субъекта;

8 задавать дополнение Subject Information Access (доступ к информации о субъекте) как некритичное и указывать репозиторий, который содержит сертификаты, изданные субъектом.

В соответствии с требованиями конкретной локальной среды сертификат может содержать и другие дополнения, они должны быть помечены как некритичные.

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

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

К содержанию сертификата УЦ, используемого в среде нескольких корпоративных PKI, предъявляются практически те же требования, что и к содержанию сертификата УЦ корпоративной PKI, за исключением двух пунктов, касающихся соответствия политик и ограничений на имена [70]. В сертификате УЦ, который участвует во взаимодействии между разными корпоративными PKI, необходимо:

1 задавать дополнение Policy Mappings (соответствие политик) как некритичное и устанавливать в нем только соответствие политик издателя, которые указаны в дополнении Certificate Policies ;

2 задавать дополнение Name constraints (ограничения на имена) как критичное. Исключать поддеревья в иерархии отличительных имен, соответствующие локальному пространству имен каждой PKI. Это позволяет субъекту одной PKI не принимать сертификаты другой PKI, которые содержат локальные имена.

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

Сертификаты мостовых удостоверяющих центров

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

Самоподписанные сертификаты

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

Сертификаты установления пункта доверия

Самоподписанные сертификаты являются сертификатами только в том смысле, что имеют формат сертификата стандарта X.509. Подпись на самоподписанном сертификате подтверждает только то, что у издателя есть открытый и секретный ключи, и ничего более - ничего имеющего отношение к содержанию сертификата. Пользователь может доверять самоподписанному сертификату только тогда, когда получил его защищенным способом, гарантирующим подлинность источника - данного УЦ.

Самоподписанные сертификаты должны иметь формат X.509 v1 и не содержать дополнений, поскольку в этом нет необходимости. В такие сертификаты пока не включается информация о политиках применения сертификатов, особенно в сертификаты головного УЦ иерархической PKI. Так как изменения в наборе политик отражаются на валидности пути сертификации, можно ожидать, что в будущем самоподписанные сертификаты будут иметь формат X.509 v3 и устанавливать пункты доверия с учетом политик применения сертификатов.

Сертификаты обновления ключа

Чтобы ввести в действие новый сертификат или ключ подписи САС, УЦ выпускает пару сертификатов обновления ключа. Первый сертификат содержит старый открытый ключ и подписывается новым секретным ключом. Второй сертификат содержит новый открытый ключ и подписывается старым секретным ключом. Таким образом, пользователи сертификатов, подписанных старым секретным ключом, и пользователи сертификатов, подписанных новым секретным ключом, могут проверять валидность сертификатов друг друга. В обоих сертификатах обновления имена издателя и субъекта совпадают, оба сертификата принадлежат УЦ одной и той же корпоративной PKI. Таблица 7.1 иллюстрирует некоторые отличия профилей этих сертификатов от нормального профиля сертификата УЦ [128].

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

Новый сертификат УЦ, подписанный старым ключом, дает возможность пользователям сертификатов, подписанных старым секретным ключом, строить валидный путь сертификации к сертификатам, подписанным новым секретным ключом.

Сертификаты обновления политики

УЦ выпускает сертификаты обновления политики, чтобы изменить домен политики. Предположим, что УЦ выпускает сертификаты в соответствии с политиками I и II. В связи с изменениями внутри организации планируется выпускать новые сертификаты в соответствии с политиками III, IV и V. При переходе к новым политикам УЦ желает гарантировать непрерывность работы своих пользователей. Даже если бы УЦ мог моментально выпустить новые сертификаты для всех пользователей, в том числе и внешних, то пользователям пришлось бы заняться переконфигурированием своих приложений, что помешало бы их работе. Поэтому при изменении политик выпускается пара сертификатов обновления политики. В данном примере первый сертификат задает политики I и II, устанавливая их соответствие политикам III, IV и V, а второй сертификат задает политики III, IV и V, устанавливая их соответствие политикам I и II.

|Содержание сертификата | Старый сертификат, подписанный новым ключом | Новый сертификат, подписанный старым ключом |

|Срок действия ключа | Начинается с выпуска сертификата и заканчивается после того, как истечет срок действия сертификатов, подписанных ранее старым секретным ключом | Начинается с выпуска сертификата и заканчивается после того, как истечет срок действия сертификатов, подписанных ранее старым секретным ключом |

|Открытый ключ субъекта | Старый ключ подписи | Новый ключ подписи |

|Дополнение Basi Constraints | Задается как некритичное; параметр cA принимает значение TRUE, но значение длины пути не указывается | Задается как некритичное; параметр cA принимает значение TRUE, но значение длины пути не указывается |

|Дополнение Authority Key Identifier | Задается как некритичное и относится к новому открытому ключу | Задается как некритичное и относится к старому открытому ключу |

|Дополнение Subject Key Identifier | Задается как некритичное и соответствует дополнению Authority Key Identifier в сертификатах, подписанных старым секретным ключом | Задается как некритичное и соответствует дополнению Authority Key Identifier в сертификатах, подписанных новым секретным ключом |

|Цифровая подпись | Генерируется при помощи нового секретного ключа | Генерируется при помощи старого секретного ключа |

Таблица 7.1.Особенности профилей старого и нового сертификатов обновления ключа

Обновление политик часто происходит вместе с обновлением ключа. Профиль сертификата обновления политики в целом совпадает с профилем сертификата, но имеет некоторые особенности [70].

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

* дополнение Certificate Policies (политики применения сертификатов) задается как некритичное; в нем указываются все новые политики, которые УЦ устанавливает в сертификатах, подписываемых новым секретным ключом; эти политики не имеют спецификаторов;

* дополнение Policy Mappings (соответствие политик) задается как некритичное; оно определяет новые политики как политики домена издателя и устанавливает их соответствие старым политикам, заданным как политики домена субъекта.

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

* дополнение Certificate Policies (политики применения сертификатов) задается как некритичное; в нем указываются все старые политики, которые были установлены в сертификатах, подписанных старым секретным ключом; эти политики не имеют спецификаторов;

* дополнение Policy Mappings (соответствие политик) задается как некритичное; оно определяет старые политики как политики домена издателя и устанавливает их соответствие новым политикам, заданным как политики домена субъекта.

Использование субъектом нескольких сертификатов

Пары ключей одного субъекта

Более широкое распространение инфраструктур открытых ключей, скорее всего, приведет к тому, что субъектам PKI придется иметь целый набор пар ключей одного назначения (например, для цифровой подписи). Уже сейчас появляется необходимость устанавливать строгое соответствие между парами ключей и "ролями", которые приходится играть субъекту в течение дня, включая рабочее и нерабочее время. Субъект может использовать один ключ для подписания электронных документов по служебной необходимости, другой - для подписания сообщения, отправляемого по электронной почте другу, и третий - для подписания заявки на товар, приобретаемый в магазине электронной торговли и т.д. (рис. 7.2).

Рис. 7.2. Применение пользователем нескольких пар ключей

В современной жизни существует привычная всем аналогия набору пар ключей - кредитные карты: личные и корпоративные. Многие деловые люди используют корпоративную кредитную карту для служебных целей и личную кредитную карту для всех других целей. Корпоративная кредитная карта выпускается для служащего компанией, в которой он работает, и может предоставлять некоторые преимущества по сравнению с личной кредитной картой (например, высокий лимит расходов или страхование несчастных случаев). Та же самая модель поддерживается для ключей: ключ может генерироваться и выпускаться централизованно самой компанией, а не локально субъектом PKI на его рабочей станции. Более того, этот ключ может наделяться определенными привилегиями или его применение может ограничиваться. Концепция использования субъектом нескольких пар ключей актуальна для многих сред, наоборот, было бы удивительно, если бы субъект PKI имел всего одну пару ключей для различных целей.

Итак, пара ключей должна быть связана с разными ролями или действиями субъекта. Однако бывают случаи, когда пара ключей имеет вполне определенное назначение. Например, пара ключей из алгоритма цифровой подписи Digital Signature Algorithm (DSA) не может использоваться для шифрования и расшифрования, пара ключей Диффи-Хэллмана не может использоваться для подписания данных и верификации подписи. Более того, даже пара ключей RSA, которая, в принципе, может применяться для аутентификации, целостности, конфиденциальности или обмена ключами, на практике должна иметь только одно назначение, разрешенное политикой или вариантом реализации PKI.

Сфера применения пары ключей может быть разной даже в рамках одного назначения [44]. Так, например, во многих средах важно различать, с какой целью субъект PKI подписывает данные: для своей аутентификации или с намерением заверить содержание документа. Иногда бывает необходимо не просто задать назначение пары ключей, но и конкретизировать тип и категорию назначения. Например, пара ключей может быть создана только для авторизации платежей, более того, сумма платежей может быть также ограничена, в этом случае все заверенные данным ключом транзакции на сумму, превышающую заданный лимит, будут отвергнуты.

Таким образом, пара ключей может быть связана с определенной политикой, которая ограничивает ее:

* определенным качественным или количественным признаком назначения (например, транзакции на сумму не выше заданного значения);

* определенным типом назначения (например, авторизация платежей) внутри определенной категории назначения (например, цифровая подпись) внутри определенного сервиса назначения (например, аутентификации).

Кроме того, назначение пары ключей может зависеть от типа приложения или протокола обмена. Например, пара ключей может использоваться для аутентификации субъекта по протоколу Internet Protocol Security (IPsec), а не по протоколу Secure Sockets Layer (SSL).

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

Взаимосвязи сертификатов и пар ключей

Если субъект PKI имеет много пар ключей, то должен иметь и много сертификатов, поскольку формат сертификата стандарта X.509 не позволяет ему указывать в поле Subject Public Key Info (информация об открытом ключе субъекта) несколько ключей. Это, однако, не исключает возможности появления определенного открытого ключа в нескольких сертификатах, которые одновременно являются валидными. Проанализируем взаимосвязи между парами ключей и сертификатами [43].

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

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

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

Важно учитывать, что если один и тот же открытый ключ содержится в нескольких валидных сертификатах, субъекту сертификата легко совершить ошибку или даже подмену. Например, в одном сертификате дополнение Key Usage (назначение ключа) может задавать только цифровую подпись, а в другом сертификате, содержащем тот же самый ключ - неотказуемость. Тогда любой нарушитель или даже сам субъект может подменить один сертификат другим таким образом, что заверенные цифровой подписью данные приобретут совершенно другой смысл. Требование, чтобы разные сертификаты всегда содержали разные открытые ключи, - это простой способ полностью исключить риск подмены.

Управление несколькими парами ключей

Возможность использовать несколько действующих сертификатов, связанных с разными политиками и назначениями ключей, сопряжена с тем, что для каждого вида активности должен выбираться корректный (соответствующий назначению) секретный ключ. Например, для заверения цифровой подписью некоторого платежного поручения может потребоваться ключ, предназначенный для подписания платежей на сумму "более чем 100 тыс. долл.", а не ключ для подписания платежей на сумму "не более чем 100 тыс. долл.". Неизбежно возникают ситуации, когда при выборе ключа для подписания документа пользователь должен консультироваться с другой стороной о ее согласии закрепить договором условия подписываемого документа. При положительном ответе используется ключ, обеспечивающий неотказуемость.

Однако в большинстве случаев выбор ключа выполняется автоматически и прозрачно для пользователя. Если устанавливается сеанс связи по протоколу SSL, то клиентское ПО осуществляет поиск сертификата пользователя, в котором дополнение Key Usage (назначение ключа) содержит значение SSL, а затем использует соответствующий секретный ключ для аутентификации пользователя. Со временем ПО PKI станет более совершенным, и выбор ключей в основном будет прозрачным.

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

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

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

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

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

С другой стороны, требования к созданию резервных копий ключей подписи (особенно тех, которые должны использоваться для поддержки неотказуемости) не предъявляются; они должны принадлежать только тому субъекту, который указан в соответствующем сертификате открытого ключа. Если секретный ключ подписи утрачен, должна быть сгенерирована новая пара ключей. По истечении срока действия секретные ключи подписи не помещаются в архив, а безопасным образом уничтожаются.

Такие взаимоисключающие друг друга требования диктуют необходимость субъекту корпоративной PKI иметь, по крайней мере, две разные пары ключей (и связанных с ними сертификатов). Это установлено рядом требований и профилей в стандартах PKI (например, RFC 3280). В некоторых средах, например, в инфраструктуре ИТ-безопасности шведской некоммерческой организации Secure Electronic Information in Society, уже управляют тремя парами ключей: шифрования/расшифрования, подписи/верификации общего назначения и подписи/верификации для поддержки неотказуемости [68].

Жизненный цикл сертификатов и ключей

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

Важнейшим вопросом в смысле возможных правовых последствий применения электронной цифровой подписи является вопрос: когда сертификат становится валидным. Выпуск сертификата открытого ключа и подписание его УЦ после аутентификации лица, обращающегося с запросом о выдаче сертификата, не являются достаточным условием для придания сертификату статуса валидного. Сертификат становится валидным только после его открытой публикации в репозитории PKI, и наоборот, сертификат теряет статус валидного после его включения в список аннулированных сертификатов и публикации последнего [10].

Рис. 7.3. Жизненный цикл сертификата

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

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

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

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

Рис. 7.3 иллюстрирует жизненный цикл сертификата. Стрелки, которые отображают нормальный жизненный цикл, выделены более ярко, в отличие от тех стрелок, которыми отмечены моменты вмешательства УЦ или РЦ. Так, например, в корпоративной PKI, где владельцами сертификатов являются служащие организации, вмешательство УЦ в нормальный жизненный цикл сертификата требуется в случаях:

1 аннулирования сертификата при увольнении служащего, владеющего этим сертификатом;

2 аннулирования сертификата при утере служащим своего секретного ключа или пароля доступа к секретному ключу;

3 приостановления действия сертификата, выпущенного для служащего, который в данный момент времени увольняется или находится под следствием;

4 возобновления сертификата служащего при отказе от увольнения или после прояснения обстоятельств судебного дела и т.п.

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

Примерные сценарии управления жизненным циклом сертификатов и ключей

Рассмотрим возможные сценарии управления жизненным циклом сертификатов и ключей PKI, предполагая, что политикой применения сертификатов установлен срок действия сертификата открытого ключа - 1 год, секретного ключа - 10 лет, цифровой подписи - 25 лет с момента подписания электронного документа [80].

Пример 7.1. Пусть секретный ключ используется для подписания деловых контрактов. Так как срок действия секретного ключа - 10 лет и ключ был создан в начале 2000 года, то он должен храниться до начала 2010 года. На рис. 7.4 символом Х в середине 2001 года помечен момент подписания контракта, который будет действовать до середины 2026 года. Цифровая подпись этого документа остается действительной по истечении срока действия секретного ключа, который использовался для создания этой подписи, поэтому открытый ключ должен храниться дольше секретного, так как он будет использоваться для верификации цифровой подписи и после окончания действия секретного ключа. Действительно, вполне вероятно, что другой электронный документ будет подписан в конце 2009 года непосредственно перед тем, как истечет срок действия секретного ключа, следовательно, открытый ключ должен храниться, по крайней мере, до 2035 года, потому что он может потребоваться для верификации цифровой подписи спустя 25 лет после подписания документа.

Рис. 7.4. Сценарий использования секретного ключа для подписания деловых контрактов

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

Пример 7.2. Рассмотрим более сложный случай: компрометацию секретного ключа подписи. На рис. 7.5 момент компрометации помечен символом Х в начале 2002 года. После обнаружения компрометации секретного ключа УЦ вносит сертификат соответствующего открытого ключа в список аннулированных сертификатов.

Если последний документ был подписан при помощи секретного ключа (до его компрометации) в начале 2002 года, то открытый ключ должен оставаться доступным до начала 2027 года, следовательно, сертификат открытого ключа должен быть доступен, несмотря на то, что он внесен в список аннулированных сертификатов.

Рис. 7.5. Сценарий компрометации секретного ключа подписи

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