Вопросы проверки подлинности имеют первостепенное значение в процессе аутентификации пользователей, систем и защищенных сетевых соединений с помощью цифровых сертификатов. Для того чтобы убедиться в подлинности сертификата, приложение Windows, использующее механизмы инфраструктуры открытых ключей (PKI), должно определить, может ли оно доверять данному сертификату и соответствующему открытому ключу.
Для осуществления проверки подлинности сертификата в приложении PKI должна быть реализована соответствующая логика, посредством которой выполняется серия процедур сличения для различных частей сертификата. В данной статье мы рассмотрим эти процедуры, а также другие аспекты процесса проверки подлинности сертификата. Тщательное изучение этого процесса поможет в дальнейшем распознавать и решать проблемы, связанные с проверкой подлинности сертификатов в случае их возникновения.
Процедуры сличения
В процессе проверки подлинности сертификата для него выполняются процедуры сличения по следующим критериям: цифровая подпись (digital signature), параметры отношений доверия (trust), временные параметры (time), информация об аннулировании сертификата (revocation) и параметры формата (formatting). Если выясняется, что сертификат не соответствует требованиям хотя бы одного из этих критериев, то он считается недействительным. При сличении цифровой подписи программа проверки подлинности с помощью заслуживающего доверия открытого ключа проверяет подлинность цифровой подписи, добавленной в сертификат выдавшим его центром Certificate Authority (CA). В качестве ключа используется открытый ключ выдавшего сертификат центра CA либо другого центра, входящего в цепочку сертификатов в соответствии с иерархической моделью доверительных отношений.
Для проверки подлинности подписи недостаточно просто наличия открытого ключа, он должен быть заслуживающим доверия. В инфраструктурах PKI систем Windows Server 2003 и Windows 2000 Server сертификат и открытый ключ заслуживающего абсолютного доверия центра CA называются трастовыми якорями (trust anchor), а доступ к ним осуществляется через контейнер Trusted Root Certification Authorities хранилища сертификатов клиента Windows PKI. В процессе сличения параметров доверительных отношений производится аутентификация сертификата доверенных CA — эту процедуру также называют проверкой подлинности цепочки сертификатов. При выполнении данной процедуры для каждого сертификата цепочки могут запускаться различные циклы проверки подлинности. Подробнее процедура проверки подлинности цепочки сертификатов будет рассмотрена ниже.
При обработке временных параметров сертификата производится сличение текущей даты с датами начала и окончания срока действия сертификата. Одна из причин ограничения срока действия сертификата заключается в обеспечении соответствия современным требованиям компьютерной безопасности, в частности криптографии, поскольку вряд ли кто-то станет доверять сертификатам, выпущенным по устаревшей технологии.
Во время выполнения процедуры сличения срока действия (revocation check) проверяется, не аннулирован ли данный сертификат выдавшим его центром CA. В средах PKI систем Windows 2003 и Windows 2000 Server реализована поддержка работы с абсолютными списками аннулированных сертификатов (complete CRL) и узлами распространения списков CRL (CRL Distribution Point, CDP). Помимо этого, служба Windows 2003 Certificate Services может работать и со списками изменений (delta CRL). Используя списки CRL, списки изменений CRL и узлы CDP, можно обеспечить проверку срока действия сертификатов в автоматическом режиме. Более подробно вопросы, связанные с аннулированием сертификатов, рассмотрены в статье «Процедуры аннулирования сертификатов в инфраструктуре Windows PKI», опубликованной в журнале Windows IT Pro/RE № 4 за 2006 г.
При выполнении процедуры сличения параметров форматирования проверяется, соответствует ли формат сертификата стандартным требованиям, определенным в рекомендации X.509, выпущенной комитетом International Telecommunications Union Telecom- munication Standardization Sector (ITU-T). При этом также проверяется корректность расширений сертификата, описывающих параметры доверительных отношений с регулируемой степенью доверия, таких как базовые ограничения, ограничения имен, ограничения политик приложений и ограничения политик выдачи. Более подробно эти расширения описаны в статье «Принципы доверия PKI», опубликованной в Windows IT Pro № 7 за 2006 г. Например, большая часть приложений, работающих с Secure MIME (S/MIME), проверяет подлинность параметра сертификата subject’s name, описанного в Internet Engineering Task Force (IETF) Request for Comments (RFC) 822 (по сути дела, это стандартное имя в формате адресов почты Internet, скажем, jan.declercq@hp.com). Для этого значение данного параметра сравнивается с полем адреса отправителя в заголовке сообщения SMTP. В случае S/MIME такая проверка обеспечивает защиту от возможного заимствования прав (impersonation) и от атак типа man-in-the-middle. При проведении подобных атак злоумышленник обычно пытается отождествить себя с реальным пользователем, чтобы получить доступ к системе или сети. Сходные типы проверок выполняются и в большинстве реализаций Secure Sockets Layer (SSL). Протокол SSL проверяет соответствие параметра subject’s RFC 822 name имени, находящемуся в поле URL того защищенного Web-сайта, к которому обращается клиент.
Стандартная процедура обработки цепочки сертификатов
Что такое цепочка сертификатов и почему ее следует обрабатывать в процессе проверки подлинности сертификата? С помощью построения цепочки можно организовать проверку подлинности всех сертификатов, с которыми связан данный сертификат. Для того чтобы разобраться в том, что представляет собой цепочка сертификатов, обратимся к иерархической модели доверительных отношений в инфраструктуре PKI. В данной модели (которая также обсуждалась в упомянутой выше статье «Принципы доверия PKI») цепочка сертификатов каждого пользователя состоит из сертификатов всех центров CA, которые образуют в пределах данной иерархии путь от пользователя до корневого (root) центра CA. При использовании иерархической модели доверительных отношений каждый сертификат содержит указатель на родительский (или выдавший сертификат) центр CA, который хранится в поле issuer сертификата X.509. На рис. 1 показан пример цепочки для пользовательского сертификата, выданного центром CA при наличии двухуровневой иерархии в инфраструктуре PKI. Рис. 1 иллюстрирует простейший пример использования параметров certificate subject (субъект) и certificate issuer (издатель сертификата). В данном примере субъектом пользовательского сертификата является пользователь, а издателем сертификата — промежуточный центр CA. В сертификате промежуточного центра субъектом является сам этот центр, издателем же в данном случае будет корневой CA. В иерархической модели доверительных отношений корневой центр CA всегда сам подписывает свой сертификат, поэтому для своего сертификата он является как субъектом, так и издателем сертификата.
Построение цепочки сертификатов. На данном этапе программа проверки просматривает всю цепочку сертификатов, начиная с сертификата пользователя. При этом производится поиск сертификата, заслуживающего абсолютного доверия центра CA (т. е. трастового якоря). В примере, показанном на рис. 2, программа проверки подлинности обнаружила трастовый якорь на уровне корневого центра CA, хотя в общем случае он может находиться и на уровне промежуточного CA. После того как был обнаружен трастовый якорь, процедура построения цепочки завершается, после чего логика программы проверки переключается на процедуру проверки подлинности цепочки сертификатов. Если программе проверки не удается обнаружить трастовый якорь, тогда весь процесс обработки цепочки завершается и становится невозможно принять решение о доверии данному сертификату со стороны программы проверки подлинности.
Для идентификации сертификата центра CA во время процедуры проверки подлинности цепочки используется расширение Authority Key Identifier (AKI) проверяемого сертификата. В поле AKI содержится информация следующих типов.
- Имя центра, выдавшего сертификат и серийный номер сертификата данного центра. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя поля Serial number и Subject. Данный метод идентификации сертификата называется строгим совпадением.
- Идентификатор открытого ключа (KeyID) сертификата центра, выдавшего проверяемый сертификат. Если эта информация имеется в поле AKI, тогда программа проверки подлинности выполняет поиск совпадающего сертификата, используя расширение сертификата Subject Key Identifier (SKI), в котором хранится уникальный идентификатор открытого ключа сертификата субъекта. Данный метод идентификации сертификата называется совпадением ключей.
Если в проверяемом сертификате поле AKI отсутствует, программа проверки подлинности пытается идентифицировать сертификат выдавшего центра CA с помощью проверки совпадения имени, взятого из поля Issuer проверяемого сертификата, с содержимым поля Subject сертификата. Данный метод идентификации сертификата называется совпадением имен.
В тех случаях когда проверяемый сертификат недоступен локально, имеющиеся в Windows программные средства проверки подлинности используют расширение Authority Information Access (AIA), с тем чтобы получить копию сертификата путем его загрузки по сети с соответствующего узла. Для этого используется поле AIA, которое содержит указатель на узел хранения сертификатов центров CA для протоколов FTP, HTTP, Lightweight Directory Access Protocol (LDAP) или указатель на соответствующий файловый ресурс. Если поле AIA содержит несколько ссылок, программные средства проверки подлинности пытаются задействовать все эти ссылки в порядке их перечисления в данном поле. Все сертификаты, которые загружаются с использованием поля AIA, кэшируются программой проверки в профиле пользователя PKI на локальном диске (а именно в папке Documents and SettingsusernameLocal SettingsTemporary Internet Files), а также в локальном хранилище сертификатов пользователя.
Просмотреть цепочку, относящуюся к конкретному сертификату, можно с помощью закладки Certification Path диалогового окна свойств сертификата, которое показано на экране. Чтобы получить доступ ко всем своим сертификатам, необходимо запустить оснастку Certificates консоли MMC, а для доступа к свойствам отдельного сертификата дважды щелкнуть на соответствующем сертификате в списке, выводимом данной оснасткой.
Если при загрузке сертификата используется Web-интерфейс центра CA систем Windows 2003 или Windows 2000 Server, то в этом случае можно выбрать загрузку только самого сертификата либо загрузку данного сертификата совместно со всеми сертификатами, образующими цепочку. Возможность загрузки цепочки сертификатов иногда бывает весьма полезной, например если для работы используется переносной компьютер. В этом случае все сертификаты цепочки будут доступны для программы проверки подлинности даже тогда, когда пользователь находится в дороге.
Обработка цепочки списков CTL
Данная процедура представляет собой особый случай обработки цепочек сертификатов. Список CTL содержит заверенный перечень сертификатов, заслуживающих абсолютного доверия корневых центров CA, следовательно, здесь содержатся сертификаты центров CA, подписанные ими самими. Формирование списка CTL выполняется через выпадающее меню контейнера объекта групповой политики Enterprise Trust Group Policy Object. Доступ к данному контейнеру осуществляется последовательным выбором Windows SettingsSecurity SettingsPublic Key Policies. Объекты GPO также выполняют автоматическую загрузку списков CTL в контейнер Enterprise Trust хранилища содержимого сертификатов. Отметим, что контейнер Enterprise Trust не является контейнером трастовых якорей — его содержимое не считается заслуживающим абсолютного доверия по умолчанию.
Для того чтобы список CTL и его содержимое считались заслуживающими доверия, сертификат, с помощью которого подписывался этот список, должен быть действительным. Следовательно, данный сертификат должен полностью удовлетворять требованиям проверки процедурами сличения по всем рассмотренным выше параметрам (цифровая подпись, параметры отношений доверия, временные параметры, информация об аннулировании сертификата и параметры формата). Гарантией успешной проверки цифровой подписи служит наличие сертификата из контейнера Trusted Root Certification Authorities в цепочке того сертификата, который использовался для подписи сертификата списка CTL. Как уже говорилось выше, определить, является ли цепочка сертификатов составной частью действительного списка CTL, можно путем просмотра каждого из сертификатов цепочки с помощью закладки Certification Path окна свойств сертификата.
Обработка цепочки кросс-сертификатов
Кросс-сертификация — это новая возможность установления отношений доверия, появившаяся в инфраструктуре PKI среды Windows 2003 (подробнее она рассмотрена в статье «Принципы доверия PKI»). В отличие от списков CTL, кросс-сертификация позволяет устанавливать детальные отношения доверия в PKI между различными инфраструктурами центров CA. При установлении доверительных отношений через кросс-сертификацию между двумя центрами CA, входящими в инфраструктуры различных организаций, каждый из этих центров становится одновременно как родительским, так и подчиненным, при этом в процессе построения цепочек сертификатов наблюдаются весьма интересные эффекты.
Проверка подлинности сертификатов — тема достаточно сложная, поэтому в случае возникновения проблем с сертификатами знания основных принципов проверки их подлинности в среде Windows могут помочь вам при локализации возможных причин и в некоторой степени облегчить решение проблем.
Жан де Клерк (jan.declercq@hp.com) — член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press)