Если субъект 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].
Жизненный цикл сертификатов и ключей
Политикой применения сертификатов должно быть четко определено, в какой момент времени сертификаты и ключи становятся валидными и как долго сохраняют свой статус, а также когда необходимо их заменять или восстанавливать.
