Изучи Windows Server 2003 за 15 минут в неделю:
 

Введение в Инфраструктуру открытого ключа (PKI, Public Key Infrastructure) и Службы сертификации (Certificate Services) Windows Server 2003

Кори Хайнс (Corey Hynes)

 

Эта статья является первой из серии, охватывающей разработку, реализацию и управление инфраструктурой открытого ключа (далее – PKI). Системы PKI становятся все более и более распространенными в современных ИТ-средах, поскольку многие технологии строятся с использованием преимуществ стойкой аутентификации, обеспечиваемой сертификатами.

Что представляет собой PKI?

PKI определяется как «набор политик, практики и компонентов, образующих иерархию сертификатов». Существует несколько ключевых понятий, которые необходимо понимать для того, чтобы реализовать PKI.

Термин

Определение

Сертификат

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

ЦС

Центр Сертификации (ЦС) является пакетом программного обеспечения, принимающим и обрабатывающим запросы на выдачу сертификатов, издающим сертификаты и управляющим выданными сертификатами.

Технологии, управляющие PKI

Проще говоря, ролью PKI является выпуск и управление сертификатами. Это утверждение лежит в основе понимания работы PKI и дает хорошее понимание действия существующих сертификатов.

Сертификаты обеспечивают основу для аутентификации объекта. Эта аутентификация основана на некоторых ключевых принципах, некоторые из которых управляются технологически, другие – с помощью закона и политики организации. В своей основе, сертификат реализует две ключевые технологии: асимметричное шифрование (часто называемое шифрованием с открытым/закрытым ключом) и хэширование.

Закрытый ключ является средством, с помощью которого объект идентифицируется, что означает, что обладание закрытым ключом эквивалентно подлинности. Следовательно, если у вас есть мой закрытый ключ, то вы - это я. Закрытые ключи являются наиболее охраняемым секретом в компьютерном мире. Для защиты закрытых ключей организации реализуют такие средства, как сейфы, физическая охрана и хранение, основанное на аппаратном обеспечении. Каждый закрытый ключ имеет соответствующий ему открытый ключ. Этот ключ по своей природе является доступным для каждого, кто хочет воспользоваться им. Вместе они предоставляют главную службу PKI – идентификацию (открытый ключ) и аутентификацию (закрытый ключ). Применительно к шифрованию нужно усвоить одно важное правило. Любые данные, которые были зашифрованы с помощью закрытого ключа, могут быть расшифрованы только с помощью соответствующего ему открытого ключа и наоборот: любые данные, которые были зашифрованы с помощью открытого ключа, могут быть расшифрованы только с использованием соответствующего закрытого ключа.

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

В этих примерах сделано два допущения. Во-первых, все мы принимаем, что Алиса – единственный человек, у которого есть копия ее закрытого ключа. Во-вторых, мы принимаем, что ее открытый ключ, является на самом деле ее открытым ключом; он не был подделан кем-то еще. Единственным способом удостовериться, что единственная копия закрытого ключа Алисы находится в ее распоряжении, является организация управления ее ключом, предпринимающая достаточные шаги для его защиты. В Windows закрытый ключ хранится как часть профиля пользователя, защищаемого паролем пользователя или смарт-картой. В некоторых реализациях закрытый ключ может храниться в особом аппаратном модуле или на смарт-карте. Открытый ключ защищается от изменений путем информирования пользователя открытого ключа о том, что произошло несанкционированное изменение. Это является функцией одностороннего хэширования (one-way hash).

Часто задается вопрос: «А как открытые ключи становятся открытыми?». Ответ прост – сертификаты. Исключительная цель сертификата – это доказать подлинность. Подлинность проверяется с помощью математической связи между открытым и закрытым ключом. Открытый ключ Алисы информирует Боба о ее подлинности. Ее закрытый ключ доказывает ее подлинность. Когда Алиса посылает Бобу копию своего сертификата, этот сертификат содержит копию ее открытого ключа. Поскольку этот открытый ключ является единственной вещью, которая может расшифровать данные, зашифрованные с помощью закрытого ключа Алисы, успешная расшифровка данных означает, что они фактически были зашифрованы с помощью закрытого ключа Алисы. Так как обладание закрытым ключом равносильно подлинности, то это означает, что именно Алиса должна была зашифровать эти данные.

Открытый ключ, хотя он и является общим, никогда не должен меняться. Поскольку каждый открытый ключ математически связан с закрытым ключом, то изменение открытого ключа меняет эту связь и лишает его надежности. И хотя технически невозможно предотвратить изменение данных, само это изменение может быть зафиксировано. Если изменение данных было зафиксировано, то пользователь может быть проинформирован о том, что эти данные, возможно, являются неправильными или измененными. Алгоритм хэширования уменьшает огромные документы до прогнозируемого набора битов. Этот набор битов потом может быть снова воссоздан и сравнен с исходным. Эта операция подобна той, что выполняется при контроле с помощью циклического избыточного кода (CRC, cyclic redundancy check) или контрольном разряде четности (parity bit) в других системах обмена информацией. Поскольку хэширование удаляет биты, восстановление исходного документа по хэшу является невозможным. Также, в силу его природы, изменение всего одного бита в документе приводит к 50% изменению значения хэша. Это делает хэширование очень эффективным методом обнаружения изменения данных.

Пример использования PKI

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

  1. Пользователь проходит аутентификацию на своей собственной локальной системе, чтобы получить доступ к его закрытому ключу.
  2. Алиса выполняет однонаправленное хэширование своего сообщения.
  3. Алиса шифрует сообщение с помощью своего закрытого ключа и переправляет это сообщение и зашифрованный хэш Бобу вместе с копией своего сертификата. Обратите внимание на то, что зашифрованный с помощью закрытого ключа хэш известен как цифровая подпись.
  4. Боб получает данные и использует этот сертификат для получения открытого ключа Алисы. Затем он использует этот открытый ключ для расшифровки хэша, пришедшего вместе с сообщением.
  5. Боб берет полученное сообщение и генерирует новый хэш. Он сопоставляет новый хэш с тем, что только что расшифровал. Если они совпадают, то это означает, что Боб смог расшифровать данные (и удостовериться в подлинности Алисы), а также то, что данные не были изменены каким бы то ни было способом.

Возможно, вы обратили внимание, что в этом примере существует несколько серьезных проблем с безопасностью.

  1. Мы не подтвердили подлинность самого Боба.
  2. Мы не обеспечили конфиденциальности сообщения.
  3. Мы не убедились, что сертификат Алисы не был подменен каким-либо способом.
  4. Мы не убедились, что сертификат Алисы не был аннулирован или отозван.

Эти темы будут раскрыты позднее в этой и в следующей статье, посвященной PKI.

Роль Центров Сертификации

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

Пример данных сертификата

Необходимо понимать, как происходит процесс проверки подлинности запрашивающей стороны центром сертификации. В зависимости от реализации это может быть выполнено автоматически через реквизиты пользователя (Active Directory) или вручную, что вовлекает бумажную работу, подтверждение через электронную почту и, в экстренных случаях, подтверждение личности (личные документы, фото-идентицикация и т.д.). Доверие к сертификату, напрямую связано с уровнем доверия, которое вы испытываете к центру сертификации, выпустившему данный сертификат. Если центр сертификации имеет очень слабую политику выпуска или очень бедный механизм подтверждения, то вероятность того, что могут появиться поддельные сертификаты, возрастает. Это произошло в прошлом году с Verisign – крупнейшим коммерческим центром сертификации, выпустившим сертификаты для объекта, имитирующего саму компанию Microsoft.

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

ЦС очень редко работают поодиночке. Чаще они реализуются в виде иерархической структуры, состоящей из корневого ЦС (root CA) и подчиненных ЦС (subordinate CA). Как правило, корневой ЦС – это компьютер, который находится в отключенном от сети состоянии (offline) и помещен в физически безопасное место. Подчиненные ЦС создаются, чтобы обслуживать определенные функции и их безопасность обеспечивается в соответствии с уязвимостью той функции, которую они выполняют. Процесс подтверждения подлинности всех сертификатов вплоть до корневого сертификата называется путем верификации или цепочкой верификации сертификатов.

Проверка подлинности сертификатов

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

Информация о цепочке сертификатов, хранящаяся в сертификате

Вот пример моего личного сертификата для электронной почты. В этом сертификате содержится имя ЦС, выпустившего его. В данном случае сертификат был выпущен ЦС Personal Freemail RSA 2000.8.30. ЦС Thwarte Personal Freemail выпустил сертификат для данного ЦС. Для того чтобы объект мог убедиться, что мой сертификат имеет силу и, следовательно, я именно тот, кем себя представляю (открытый ключ будет использоваться для подтверждения подлинности цифровой подписи), вся цепочка должна быть пройдена и подтверждена. Ниже приведен пример процедуры, которая предпринимается для подтверждения сертификата Алисы.

  1. Боб получает сертификат Алисы и убеждается, что срок его действия не истек.
  2. Затем этот сертификат рассматривается с целью определения, каким ЦС он был выпущен.
  3. Если ЦС является доверенным ЦС, тогда извлекается сертификат этого ЦС и открытый ключ этого сертификата используется для расшифровки хэша сертификата Алисы.
  4. Расшифрованный хэш сравнивается с новым хэшем, полученным Бобом и, если они совпадают, тогда сертификат является подлинным и не был подделан.
  5. Боб теперь может доверять открытому ключу Алисы и расшифровывает с его помощью данные, посланные Алисой.

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

Доверяющие ЦС

Для того чтобы два объекта успешно обменивались данными, защищенными с использованием сертификатов, оба эти объекта должны доверять одному и тому же ЦС. Другими словами, доверяя ЦС, вы, по сути, верите, что кто-то за вас проверяет подлинность и вы верите, что эта проверка подлинности проводится правильно. В Windows вы доверяете ЦС, когда копируете сертификат этого ЦС в хранилище Trusted Root Certification Authorities (Доверенные корневые Центры Сертификации) на вашем компьютере. Другие операционные системы имеют сходные механизмы.

Доверенные корневые ЦС на моем локальном компьютере

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

PKI в действии – SSL

Наиболее распространенный пример работы PKI в действии является протокол SSL. Когда вы получаете доступ к Web-сайту, адрес которого имеет префикс https, вы соединяетесь с сайтом по протоколу SSL. Для того чтобы соединение было успешным должны произойти две вещи. Во-первых, вы должны обменяться секретным ключом сеанса (session key) с Web-сервером и, во-вторых, вы должны подтвердить подлинность Web-сервера. Первый шаг выходит за рамки обсуждения этой статьи, но будет рассмотрен в следующей. Второй шаг приводит к тому, что Web-браузер клиента запрашивает копию сертификата данного сервера.

Этот сертификат используется для подтверждения подлинности защищенного сайта MCP

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

Заключение

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

Кори Хайнс в настоящее время является преподавателем и консультантом ассоциации Genesis-ii. Он работал в данном качестве для правительства и частных компаний в течение 8 лет и обладает множеством сертификационных статусов, включая такие, как Microsoft Certified System Engineer + Internet (MCSE+I), Microsoft Certified Database Administrator (MCDBA), Microsoft Certified Solution Developer (MCSD), Novell Master CNE, Certified Information Systems Security Professional (CISSP), Security Certified Network Professional (SCNP) и Linux+.

Статью Кори Хайнса «Основы криптографии» вы можете прочесть в серии «Сетевая безопасность в Windows 2000 за 15 минут в неделю» - прим. переводчика.