Стратегии обновления должны строиться таким образом, чтобы обеспечить непрерывную работу пользователей. Обычно сертификаты выпускаются с периодом перекрытия сроков их действия от 4 до 6 недель, чтобы обеспечить плавный переход от старого сертификата к новому. Своевременность обновления сертификатов часто зависит от подготовки и квалификации пользователей. Хотя в большинстве PKI-систем существует режим настройки на автоматическое обновление сертификатов по истечении срока их действия, но часто сертификаты обновляются по запросам пользователей. Поэтому для обновления сертификата пользователю необходимо в определенный момент времени подтвердить УЦ свои идентификационные данные и отправить соответствующий запрос.
Некоторую проблему представляет обновление двойной пары ключей, когда пользователь для работы с одним приложением применяет два сертификата: сертификат ключа шифрования и сертификат ключа подписи. В этом случае в момент обновления пользователь должен получить два новых сертификата. При переходе от старых сертификатов к новым количество сертификатов, которыми оперирует пользователь, может увеличиваться до четырех (для одного приложения), в этот период одновременно действуют пара сертификатов с истекающим сроком действия и пара новых сертификатов. Если учитывать, что пользователь может работать с несколькими приложениями, становится ясно, что количество сертификатов, которые необходимо обновлять, постоянно растет. К сожалению, нет простого способа решения этой проблемы, кроме обучения пользователей, технической поддержки и документирования процессов обновления ключей.
Ряд поставщиков PKI предлагают клиентское программное обеспечение с функциями управления процессом обновления сертификатов. В этом случае клиентское программное обеспечение формирует и отправляет УЦ подписанный запрос (соответствующий тому сертификату, который должен быть обновлен). Цифровая подпись на запросе верифицируется при помощи открытого ключа, содержащегося в копии сертификата отправителя запроса. Если подпись подтверждается, то считается, что пользователь, отправивший запрос, является законным владельцем исходного сертификата. В этом случае УЦ выпускает новый сертификат с теми же самыми данными пользователя и открытым ключом, но новым сроком действия.
Поиск информации о статусе сертификатов
Во время работы в системе PKI пользователям приходится идентифицировать других пользователей и использовать их сертификаты. Большинство организаций хранят сертификаты в общедоступном каталоге, в репозитории. Пользователи обращаются с запросами к репозиторию, чтобы найти сертификаты, принадлежащие определенному человеку или устройству. Проблема, связанная с поиском, заключается в том, что если доступ к каталогу может получить каждый желающий, то содержащаяся в каталоге информация о пользователях также доступна каждому. Очевидно, что многие организации не стремятся раскрывать информацию о своих служащих.
Приложение Microsoft Outlook автоматически прикрепляет сертификат пользователя к отправляемому заверенному цифровой подписью сообщению. Это позволяет получателю проверять электронную почту, имея необходимые сертификаты и не выполняя никаких лишних действий. Присланные по почте сертификаты других пользователей затем хранятся получателем локально и используются для будущих проверок. Пока не все приложения предоставляют подобный сервис, поэтому доверяющие стороны вынуждены выполнять поиск информации о статусе сертификатов самостоятельно (более подробно способы получения информации о статусе сертификатов изложены в лекции 12).
Выбор способа генерации пары ключей
Генерация ключей может осуществляться централизованно (УЦ или по его поручению РЦ) либо индивидуально (конечным субъектом). В большинстве случаев пары ключей создаются конечными субъектами, которые должны иметь программные или аппаратные средства для создания надежных ключей. Этот способ позволяет субъекту обеспечить большую конфиденциальность в отношениях с доверяющими сторонами, поскольку секретный ключ владелец хранит сам и никогда не предъявляет. К сожалению, большинство пользователей не принимает достаточных мер для защиты своих секретных ключей, увеличивая риск их компрометации.
К преимуществам централизованной генерации можно отнести быстроту создания ключей, использование специализированных средств генерации высококачественных ключей, контроль соответствия алгоритмов генерации установленным стандартам, а также хранение резервных копий секретных ключей на случай их утери пользователями. Если ключи генерируются централизованно, то политикой безопасности PKI должны быть предусмотрены средства их защищенной транспортировки другим компонентам PKI, а также гарантии того, что параллельно не будет осуществляться несанкционированное копирование секретных ключей.
Порядок обновления ключей
Политикой PKI должен быть определен порядок действий в случае обновления пар ключей. Пары ключей могут обновляться вручную и автоматически. При ручном обновлении ответственность за своевременное формирование запроса об обновлении возлагается на конечного субъекта, который должен помнить дату истечения срока действия сертификата. Если запрос об обновлении не будет вовремя направлен в УЦ, субъект лишится сервисов PKI. При автоматическом обновлении система PKI сама отслеживает дату истечения срока действия сертификата и инициирует запрос об обновлении ключа соответствующему УЦ.
Политика безопасности организации может предусматривать, например, чтобы все документы, зашифрованные старыми ключами, расшифровывались и вновь зашифровывались при помощи новых ключей или чтобы любые документы, подписанные ранее старым ключом, переподписывались при помощи нового ключа. Рациональная политика управления ключами допускает пятилетний (и даже более) срок действия пары ключей, но может ограничивать период действия ключей шифрования строго конфиденциальных данных несколькими месяцами. Иногда конкретный срок действия ключей не устанавливается, а ключи заменяются в случае необходимости, например, при утере секретного ключа. В этом случае следует повторно оценивать уровень защищенности используемой пары ключей по истечении пяти лет либо при появлении новых криптографических алгоритмов или других технологических достижений.
Выбор способа хранения секретных ключей
При проектировании PKI должен быть выбран способ хранения криптографических ключей - он, как правило, зависит от специфики деятельности конкретной организации. Для ограничения доступа к секретным ключам применяются следующие механизмы [2].
Защита с помощью пароля. Пароль или PIN-код используются для шифрования секретного ключа, который хранится на локальном жестком диске. Этот метод считается наименее безопасным, так как проблема доступа к ключу решается подбором пароля.
Карты PCMCIA. Ключ защищенно хранится на карте с микрочипом, но при вводе в систему "покидает" карту, следовательно, становится уязвимым для хищения.
Устройства хранения секрета. Секретный ключ хранится в зашифрованном виде в специальном устройстве и извлекается только с помощью одноразового кода доступа, предоставляемого устройством. Этот метод более безопасен, чем упомянутые выше, но требует доступности устройства хранения конечному субъекту и не исключает утери устройства.
Биометрические средства. Ключ защищается биометрическими средствами аутентификации владельца ключа, при этом обеспечивается тот же самый уровень защиты, что и в предыдущем случае, но субъект избавляется от необходимости иметь при себе устройство хранения секрета.
Смарт-карты. Ключ хранится на смарт-карте с чипом, который обеспечивает возможность выполнять операции шифрования и цифровой подписи. Ключ никогда не покидает карту, поэтому риск его компрометации низок. Однако владелец ключа должен носить смарт-карту с собой и заботиться о ее сохранности. При утере смарт-карты зашифрованные при помощи секретного ключа данные могут оказаться невосстановимыми.