Инфраструктура Открытого Ключа (часть 5)

Обсуждение проблем безопасности

Главным в данном стандарте является формат и содержимое сертификатов и CRLs. Так как сертификаты и CRLs подписаны, необходимости в дополнительных сервисах целостности нет. Ни сертификаты, ни CRLs не содержат никаких секретов, поэтому к сертификатам и CRLs возможен неограниченный и анонимный доступ.

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

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

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

К сожалению, некоторые наследуемые приложения (например, TLS/SSL) используют единственную пару ключей для подписывания и для управления ключом.

Критическим фактором безопасности является защита закрытых ключей. Недостаточная защита пользователями своих закрытых ключей позволяет атакующему подделывать их подписи, либо дешифровать их конфиденциальную информацию. Компрометация закрытого ключа подписывания СА может иметь катастрофические последствия. Если атакующему удалось незаметно получить закрытый ключ СА, он может выпускать поддельные сертификаты и CRLs, подрывая доверие к системе. Если такая компрометация обнаружена, все сертификаты, выпущенные компрометированным СА, необходимо отменить, чтобы предотвратить использование сервисов своими пользователями и пользователями других САs. Повторное построение после такой компрометации будет проблематичным, так что САs рекомендуется реализовывать комбинацию строгих технических мер (например, криптографические модули с ограниченными возможностями вмешательства) и соответствующие процедуры управления (например, разделение обязанностей), чтобы избежать подобных инцидентов.

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

Доступность и своевременное обновление информации отмены позволяют гарантировать корректность информации, хранящейся в сертификате. Хотя срок действия сертификата и истекает естественным образом, в течение его жизненного цикла могут произойти события, негативно влияющие на связывание субъекта и открытого ключа. Если информация отмены несвоевременна или недоступна, гарантия связывания существенно понижается. Доверяющие группы могут не иметь возможности обрабатывать каждое критичное расширение, которое может появиться в CRL. САs должны проявлять особое внимание, когда делают доступной информацию отмены только с помощью CRLs, которые содержат критичные расширения, особенно если поддержка этих расширений не является обязательной согласно данному стандарту. Например, если информация отмены публикуется, с использованием комбинации дельта CRLs и полного CRLs, и дельта CRLs выпускаются более часто, чем полные CRLs, то доверяющие группы, которые не могут обрабатывать критичные расширения, относящиеся к дельта CRL, не имеют возможности получать самую последнюю информацию об отмене. В другом случае, если полный CRL выпускается всякий раз, когда выпускается дельта CRL, своевременность информации отмены будет обеспечена всем доверяющим группам. Аналогично, реализации механизма проверки действительности сертификационного пути, которые опускают проверку отмены, обеспечивают меньше гарантий, чем те, которые поддерживают это.

Алгоритм проверки действительности сертификационного пути зависит от знаний об открытых ключах (и некоторой другой информации) для одного или более доверенных САs. Решение о доверии СА является важным решением, так как оно, в конечном счете, определяет доверие к сертификату. Аутентифицированное распределение доверенных открытых ключей СА (особенно в форме "самоподписанных" сертификатов) является критичным внешним процессом, который находится вне предметной области данного стандарта.

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

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

Связывание между ключом и субъектом сертификата не может быть более сильным, чем реализация криптографического модуля и алгоритмов, используемых при создании подписи. Короткие длины ключей или слабые хэш-алгоритмы ограничивают использование сертификата. САs должны следить за развитием криптографии и внедрять наиболее сильные криптографические технологии. Кроме того, САs должны отклонять выпуск сертификатов для САs или конечных участников, которые создают слабые подписи.

Несогласованность приложений в правилах сравнения имен может привести к тому, что будет принят недействительный сертификационный путь или отвергнут действительный путь. Серия спецификаций Х.500 определяет правила для сравнения уникальных имен, которые требуют сравнения безотносительно регистра, набора символов и нескольких последовательных пробелов, а также первых и последних пробелов. Стандарт Х.509 ослабляет строгость этих правил, требуя поддержки как минимум бинарного сравнения.

САs должны представить уникальное имя в поле субъекта сертификата СА идентично уникальному имени в поле выпускающего в сертификатах, выпущенных этим СА. Если САs используют различное представление, реализации не должны распознавать цепочки имен для путей, которые включают данный сертификат. Как следствие, действительность путей может не быть признана.

Кроме того, ограничения имени для уникальных имен должны быть установлены идентично представлениям, используемым в поле субъекта или расширении subjectAltName. Если это не так, то ограничения имени, установленные как excludedSubTrees, не будут соответствовать, и недействительные пути будут приниматься, и ограничения имени, выраженные как permittedSubtrees, не будут соответствовать, и действительные пути будут отвергаться. Для того, чтобы избежать приема недействительных путей, САs должны установить ограничения имени для уникальных имен как permittedSubtrees везде, где это возможно.