Каждый IT’шник слышал про сертификаты, и практически каждый их использовал. Многие читали распространенные пошаговые руководства, как установить центр сертификации. Кто-то находил немногочисленные материалы о том, как планировать развертывание инфраструктуры открытых ключей.

В этой статье будет рассказано о возможностях и функциях компонентов PKI и параметрах сертификатов, чтобы стало понятно, почему и зачем надо предпринимать те или иные шаги при установке и настройке центров сертификации. В качестве примера будет приведена установка и настройка двухуровневой иерархии удостоверяющих центров на базе Windows Server 2008.

 

Определения

При общении с администраторами, и уж тем более — с пользователями, часто выясняется, что использовать сертификаты они уже научились, но на вопрос, что это такое, можно часто услышать неуверенный ответ «ну, это… ну, для аутентификации». Поэтому позволю себе начать статью с определений; те, кто с ними знаком, могут сразу переходить к следующему разделу.

Сертификат — это файл или объект, хранящийся в базе данных, который содержит следующие поля: номер, открытый ключ, информацию о владельце ключа и вариантах его использования, информацию об УЦ, выдавшем сертификат, и срок действия. Кроме перечисленных полей сертификат может содержать и другие данные. Формат сертификата определяется стандартом X.509, на данный момент действует третья версия стандарта. Вся информация, содержащаяся в сертификате, заверена подписью УЦ.

Инфраструктура открытых ключей (Public Key Infrastructure (PKI)) — это набор взаимосвязанных программных и аппаратных компонентов, а также административных и организационных мер для работы с криптографическими системами, использующими ассиметричные алгоритмы.

Приложения, относящиеся к PKI, можно разделить на две категории:

  • приложения для работы только с сертификатами — центры регистрации, центры сертификации, каталоги сертификатов;
  • пользовательские приложения — почтовые клиенты, браузеры, системы защищенного документооборота и др.

Кроме технической составляющей важную роль играют и «бюрократические» компоненты PKI, особенно когда существует потребность реализовать юридически значимый электронный документооборот. Политики сертификации (Certificate Policy) и регламент УЦ (Certificate Practice Statements) позволяют определить уровень доверия к издаваемым сертификатам.

Если политики и регламенты, состав и производители пользовательских приложений могут меняться от организации к организации, то наличие центра сертификации, пусть и от разных вендоров, остается неизменным. Удостоверяющий центр — это основа инфраструктуры открытых ключей, которая объединяет программные модули и аппаратные компоненты (например, HSM — Hardware Security Module). Прежде чем описывать функции УЦ, посмотрим на жизненный цикл ключей и сертификатов, показанный на схеме (см ниже). Не все приведенные на схеме пункты обязательно встречаются для каждого ключа или сертификата.

Сначала генерируется ключ — в зависимости от его предназначения генерация может происходить как на стороне клиента, так и на стороне сервера, особенно при использовании аппаратных генераторов случайных чисел или архивации ключей. Прежде чем выпустить сертификат для созданного открытого ключа, необходимо выполнить проверку данных, предоставленных в запросе на сертификат. Проверка информации о владельце ключа, в зависимости от типа сертификата, варьируется от отправки ссылок на указанный в запросе e-mail, до предъявления паспорта и данных о зарегистрированном домене. Задачи по проверке выполняет центр регистрации, который зачастую является компонентом центра сертификации.

После этого сертификат должен быть помещен в хранилище, доступное тем, кто будет использовать этот сертификат — это может быть служба каталогов или веб-сервер. Далее сертификат используется в рабочем порядке до тех пор, пока не истечет срок действия ключа или сертификат не будут отозван. Причины отзыва могут быть связаны с изменением данных о владельце (смена фамилии или должности, изменение название сайта) или компрометацией закрытого ключа. Важная задача УЦ — поддержание актуальной информации о статусе сертификата.

Необходимо избежать ситуаций, когда злоумышленник с помощью украденного закрытого ключа подписывает договор, который впоследствии признается действительным, так как на момент подписания сертификат не был отозван. УЦ должен регулярно и максимально часто обновлять информацию о статусе сертификата, а владелец сертификата должен как можно раньше сообщать о необходимости отзыва или перевыпуска сертификата. Для предоставления информации о статусе сертификата используются списки отзыва, которые содержат информацию обо всех отозванных сертификатах, или изменениях по сравнению с предыдущим списком отзыва, или протокол OCPS (Online Certificate Status Protocol).

Списки отзыва генерируются с заданным на УЦ интервалом, в то время как с использованием компонента OCSP responder можно получить информацию о статусе сертификата в реальном времени. В том случае, если закончился срок действия закрытого ключа, то центр сертификации занимается выпуском нового сертификата для нового ключа или для этого же ключа, но с другим сроком действия (использование того же ключа оправдано, например, для сертификатов агентов восстановления ключей, чтобы избежать процедуры экспорта-перешифрования-импорта заархивированных ключей).

 

Доверие

Ключевой аспект PKI — это доверие. То есть оба участника аутентификации или обмена сообщениями должны доверять центрам сертификации, которыми выданы сертификаты. Рассмотрим обращение, например, к банковскому сайту по HTTPS. Прежде чем создается защищенное соединение, пользователь должен убедиться, что подключается именно к тому сайту, к которому планировал. Аутентификация сайта происходит с использованием SSL-сертификата. Среди прочего проверяется, что сертификат выдан именно для того сайта, к которому происходит обращение, что сертификат может быть использован для аутентификации сервера, что сертификат не был отозван, что данные в сертификате не были изменены третьей стороной. Последняя проверка требует проверки подписи УЦ, который выдавал сертификат для сервера. То есть необходимо получить сертификат ключа УЦ и выполнить аналогичные проверки для этого сертификата. Опять же, сертификат УЦ должен быть заверен какой-то подписью… До какого момента длятся такие проверки? До тех пор, пока не встретится сертификат УЦ, который находится в списке доверенных сертификатов удостоверяющих центров на стороне клиента. Откуда берутся такие списки? Есть несколько вариантов: списки поставляются вместе с ОС и обновлениями, или доверенные УЦ добавляются администратором или самим пользователем.

Стоит упомянуть еще и самоподписанные сертификаты. Корневые удостоверяющие центры выдают сертификаты сами себе, то есть УЦ1 выдает сертификат для ключа УЦ1, заверенный подписью УЦ1. Такие самоподписанные сертификаты являются основой доверия, и с одной стороны они должны быть доступны всем участникам PKI, а с другой — в случае компрометации или подмены такого сертификата вся система должна перестраиваться заново, с перевыпуском всех сертификатов и защищенным распространением всем пользователям нового корневого сертификата. Существуют коммерческие удостоверяющие центры, которым автоматически доверяют все пользователи ОС, а также пользователи различных браузеров, от Konqueror до Google Chrome.

За выдачу сертификатов большинство из них хотят получать деньги, так что многие компании развертывают свои собственные ЦС, которым изначально никто не доверяет. Корпоративный ЦС удобен возможностью создания собственных политик и шаблонов сертификатов, но создает сложности с доверием со стороны клиентов и партнеров. С клиентами проблемы доверия обычно решаются покупкой SSL-сертификатов для веб-серверов в коммерческих УЦ. С партнерами, или в случае слияний, строятся различные отношения доверия между несколькими УЦ. Для этого используются кросс-сертификаты (сертификат с ключом УЦ1 заверяется подписью УЦ2 и наоборот), которые показывают взаимное доверие между УЦ нескольких организаций. Наиболее распространены три модели доверия (см схему в конце статьи):

  • Мостовая (Bridge CA Model). В данной модели существует центральный (мостовой) УЦ, которому доверяют все остальные УЦ. Такая модель позволяет осуществлять централизованное управление при небольшом количестве кросс-сертификатов. В качестве примера можно привести реализацию US government’s Federal Bridge Certification Authority.
  • В сетевой модели все УЦ считаются равноправными, и создается до n2 кросс-сертификатов. Кросс-сертификация на уровне корневых УЦ может быть не всегда желательной, в этом случае используются схемы кросссертификации на уровне подчиненных УЦ с ограничением доверия.
  • Иерархическая модель обычно используется в компаниях с разветвленной структурой, когда есть корневой УЦ и подчиненные, например, в филиалах. Кроме того, иерархическая модель позволяет минимизировать затраты при перестроении инфраструктуры в случае компрометации ключа УЦ. Действительно, если происходит компрометация ключа одного из издающих (подчиненных) УЦ, то необходимо переиздать только те сертификаты, которые были выданы этим УЦ. Более того, такая модель позволяет создавать УЦ с различными регламентами в рамках одной инфраструктуры.

Еще встречаются гибридные модели и списки доверенных сертификатов, распространяемых между заинтересованными сторонами.

 

Варианты установки УЦ

Чтобы реализовать иерархическую модель доверия, существуют различные варианты установки ЦС. В Windows Server 2008 установка центра сертификации происходит через добавление роли Active Directory Certificate Services. При прохождении мастера необходимо выбрать тип установки и тип центра сертификации.

Вариант установки (Enterprise или Standalone) влияет на возможности центра сертификации. Например, Enterprise CA может использовать шаблоны и автоматическую подачу заявок на сертификат. Standalone УЦ, несмотря на название, может быть членом домена. В случае же использования Standalone УЦ, в качестве Offline Root CA, он должен быть членом рабочей группы.

Можно установить два типа УЦ — Root CA и Subordinate CA. Для Root CA создается самоподписанный сертификат, для Subordinate CA необходимо запрашивать сертификат у вышестоящего УЦ. После установки УЦ нельзя менять имя сервера, на котором он установлен, так как сертификат УЦ окажется недействительным.

Удостоверяющие центры можно классифицировать по их предназначению: для хранения политик, выпуска сертификатов для подчиненных УЦ или для выпуска сертификатов для конечных пользователей. Можно создавать несколько центров для выпуска сертификатов, разделяя их по географическому признаку или по типу выдаваемых сертификатов. Начиная с Windows Server 2008 R2 отпала необходимость ставить отдельный УЦ в каждом лесу организации, так как появилась возможность выдавать сертификаты пользователям не только того леса, в котором установлен УЦ, но и пользователям тех лесов, с которым настроены доверительные отношения.

Для повышения надежности системы и снижения последствий компрометации корневые УЦ, и УЦ, хранящие политики, используются в режиме Offline, чтобы исключить возможность атак по сети. В качестве типа для таких УЦ выбирают Standalone CA.

 

Поля сертификатов

Прежде чем устанавливать УЦ, необходимо обдумать, для чего будут использоваться сертификаты. В большинстве случаев добавить новые шаблоны сертификатов на уже работающий УЦ не составит труда, но изменить параметры сертификата самого УЦ будет невозможно. Поэтому ниже перечислены поля сертификатов, значения для которых важно продумать до начала установки УЦ.

 

AIA и CDP

При проверке сертификата необходимо построить цепочку сертификатов до доверенного УЦ и проверить, что ни один сертификат в этой цепочке не был отозван. Местоположение списков отзывов (Certificate Revocation List (CRL)) и сертификатов УЦ задается параметрами CRL Distribution Points (CDP) и Authority Information Access (AIA) соответственно. Для каждого параметра может быть указано несколько путей, и протоколов, по которым можно получить данные (например, HTTP, LDAP или FTP).

 

Варианты использования ключа

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

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

Данные шифруются с помощью секретного ключа симметричным алгоритмом, этот секретный ключ шифруется открытым ключом пользователя и помещается в заголовок зашифрованного файла. Секретный ключ может шифроваться не только открытым ключом пользователя, но и открытым ключом агента восстановления (data recovery agent).

В этом случае агент получает возможность расшифровать данные даже при утере пользовательского закрытого ключа. Второй путь — это архивирование и шифрование закрытого ключа пользователей с помощью открытых ключей агентов восстановления ключей (key recovery agent), и последующее восстановление пользовательского ключа в случае его утраты.

 

Срок действия

Срок действия сертификата зависит от его предназначения. Обычно для пользовательских сертификатов выбирают срок 1-2 года, для сертификатов Subordinate Issuing CA — около 5 лет, для сертификатов здоровья NAP — несколько часов, самый длительный срок задается для сертификатов корневых УЦ — до нескольких десятков лет.

 

Алгоритмы и длина ключа

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

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

Кроме того, необходимо правильно выбрать алгоритм хеширования, который используется для создания хешей сертификатов, которые потом подписываются УЦ. С одной стороны, довольно популярный алгоритм SHA1 рекомендуется прекратить использовать до конца текущего года, из-за атак на него, и перейти на SHA2. С другой стороны, WinXP SP2 и Server 2003 SP2 не поддерживают SHA2 без обновлений, причем для Server 2003 SP2 требуется установка KB938397, который недоступен через стандартный Windows Update, а требует отдельного скачивания.

 

Этапы развертывания

После описания возможных вариантов и параметров установки, рассмотрим шаги, которые надо предпринять при развертывании двухуровневой инфраструктуры центров сертификации на базе Windows Server 2008.

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

Если в итоге было принято решение о создании иерархии корпоративных ЦС, то переходим к следующим шагам.

  • Проверить, что выполнены предварительные требования.
  • В случае использования одного Issuing CA на весь лес, соответствующий сервер должен быть включен в группу Certpublishers в каждом домене.
  • Если используются HSM-модули, они должны быть подключены до начала установки УЦ.
  • Для установки требуется учетная запись Enterprise Admin или длительная настройка разрешений на объекты и контейнеры AD.
  • Установить Stand-Alone Root CA, который планируется использовать в варианте Offline, с использованием файла CAPolicy.Inf, в котором отсутствуют AIA и CDP и указан увеличенный срок действия сертификата УЦ. Пример такого файла с минимальным набором параметров — в листинге. Срок действия сертификата УЦ, заданный через мастера добавления ролей будет иметь более высокий приоритет, чем срок, заданный в файле. Файл CAPolicy.Inf должен находиться в %SystemRoot%, в противном случае он не будет использован.
  • Задать необходимые параметры для корневого УЦ.
  • Задать расширения CDP и AIA для выдаваемых сертификатов, указав пути, которые будут доступны для пользователей при отключении корневого УЦ. Параметры задаются на вкладке Extensions в свойствах сервера в оснастке Certification Authority. И для местоположения CRL, и для местоположения корневого сертификата необходимо включить расширения в издаваемые сертификаты, отметив «Include in the CDP (AIA) extension of issued certificates» соответственно. Можно настроить CDP и AIA через командную строку с помощью certutil. После конфигурирования параметров необходимо разместить соответствующие файлы по указанным путям.
  • Задать интервал публикации CRL от нескольких месяцев до года, и каждый раз по истечению заданного интервала переводить УЦ в состояние online, генерировать CRL и копировать его по путям, указанным в CDP. Настройка интервала публикации CRL производится в свойствах контейнера Revoked Certificates оснастки Certification Authority командой certutil (листинг 2) или указывается перед установкой УЦ в файле CAPolicy.Inf в разделе [certsrv_server] (листинг 3).
  • Необходимо увеличить период действия выдаваемых сертификатов, так как выдаваемые сертификаты будут предназначены для УЦ.
  • На сервере, который будет подчинен УЦ, настроить доверие к корневому сертификату. Впоследствии необходимо будет настроить доверие к корневому сертификату для всех пользователей.
  • Установить Issuing Enterprise CA, который будет являться подчиненным для Stand-Alone Root CA. В процессе установки надо сохранить запрос на сертификат для подчиненного УЦ в файл. Файл с запросом необходимо скопировать на сервер, на котором установлен корневой УЦ, в оснастке Certification Authority выбрать Submit new request в разделе Action и открыть скопированный файл. После этого сертификат необходимо издать, так как по умолчанию он окажется в контейнере Pending Requests. Затем полученный сертификат перенести и установить на подчиненном УЦ.

Есть еще некоторые подводные камни при удалении центра сертификации из домена — недостаточно только удалить соответствующую роль, так как после этого остается еще база изданных сертификатов, сертификаты и ключи УЦ, списки отзывов и сертификаты промежуточных УЦ.

 

Заключение

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

 

Листинг 1. Файл CAPolicy.Inf для корневого УЦ

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
[CRLDistributionPoint]
[AuthorityInformationAccess]

 

Листинг 2. Настройка частоты публикации CRL с помощью certutil

certutil -setreg CA\CRLPeriodUnits 60
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 1
certutil -setreg CA\CRLOverlapPeriod "Weeks"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg CA\CRLDeltaPeriod "Hours"

 

Листинг 3. Настройка частоты публикации CRL с помощью фала

CAPolicy.Inf
CRLPeriodUnits = 60
CRLPeriod = Days
CRLOverlapUnits = 1
CRLOverlapPeriod = Weeks
CRLDeltaPeriodUnits = 0
CRLDeltaPeriod = Hours

 

Симметричные и ассиметричные криптосистемы

Сертификаты используются при работе с ассиметричными криптографическими алгоритмами. Для таких алгоритмов требуется закрытый ключ (обычно — случайное число) и связанный с ним открытый ключ (который является основной частью сертификата). Главное свойство таких систем — невозможность получения закрытого ключа по известному открытому. Ассиметричные алгоритмы используются для обмена ключами, аутентификации, шифрования сессионных ключей, создания электронных цифровых подписей (ЭЦП). При создании подписи используется закрытый ключ, для проверки подписи — открытый ключ.

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

В симметричной криптографии используется один и тот же ключ для шифрования и расшифровки данных. То есть, чтобы передать кому-то секретную информацию, зашифрованную с помощью симметричного алгоритма, необходимо сначала передать ключ так, чтобы он не стал известен третьей стороне. Симметричные алгоритмы могут быть использованы и для аутентификации (например, CBC-MAC и HMAC), но так как для проверки используется тот же ключ, что и для аутентификации, такой метод нельзя назвать надежным, поскольку ключ известен как минимум двум сторонам. Симметричные алгоритмы работают на несколько порядков быстрее ассиметричных, используют более короткие ключи, проще реализуются на обычных процессорах, но требуют серьезных затрат по управлению ключами. Кроме того, секретность зашифрованных данных будет зависеть не только от того, как надежно вы храните свой секретный ключ, но и от методов хранения ключа получателем.

 

Ссылки по теме

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • 1 комментарий
    Подписаться
    Уведомить о
    1 Комментарий
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии