Однако в большинстве случаев выбор ключа выполняется автоматически и прозрачно для пользователя. Если устанавливается сеанс связи по протоколу 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, где владельцами сертификатов являются служащие организации, вмешательство УЦ в нормальный жизненный цикл сертификата требуется в случаях: