Операционная система

Инфраструктура с открытым ключом Microsoft Windows 2000

Информационный документ

Аннотация

Microsoft® Windows® 2000 привносит на платформу Windows полную инфраструктуру с открытым ключом (public-key infrastructure, PKI). Эта инфраструктура расширяет созданные за последние несколько лет криптографические службы с открытым ключом (public-key, PK) на основе Windows, предоставляя интегрированный набор служб и инструментов для создания, развертывания и управления приложениями на базе PK. Новая инфраструктура дает разработчикам программного обеспечения возможность использовать преимущества механизмов безопасности разделенного секрета (shared-secret security) или безопасности на основе PK в Windows. Предприятия также получают возможность управления средой и приложениями с помощью совместимых инструментов и политик.

 


© 1999 Microsoft Corporation. Все права защищены.

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

Этот документ имеет исключительно информационный характер. MICROSOFT НЕ ДАЕТ НИ ПРЯМЫХ, НИ КОСВЕННЫХ ГАРАНТИЙ НА ЭТОТ ДОКУМЕНТ.

Microsoft, Active Desktop, BackOffice, логотип BackOffice, MSN, Windows и Windows NT являются зарегистрированными торговыми знаками или торговыми марками корпорации Microsoft в Соединенных Штатах и/или других странах.

Другие продукты и имена компаний, упомянутые здесь, могут быть торговыми марками их законных владельцев.

Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA

0499 


Содержание


Введение. 1

Концепции.. 2

Криптография с открытым ключом  2

Возможности открытых ключей  2

Цифровые подписи  3

Аутентификация  3

Соглашения о секретных ключах посредством открытого ключа  3

Шифрование значительных объемов данных без предварительного разделения секретных данных  4

Защита криптографических ключей и доверие  4

Сертификаты  5

Полномочные сертификаторы  5

Доверие и проверка  5

Компоненты Windows 2000 PKI 7

Полномочные сертификаторы... 9

Иерархия сертификатов  9

Развертывание CA в предприятии  11

Доверие в нескольких иерархиях CA  12

Работа с доменными клиентами.. 14

Создание ключей  14

Восстановление ключей  14

Регистрация сертификатов  15

Обновление  16

Использование ключей и сертификатов  16

Восстановление  17

Роуминг 17

Отзыв  18

Доверие  18

Политика безопасности PK в Windows 2000. 20

Доверенные корневые CA  20

Выдача и обновление сертификатов  20

Вход в систему с помощью смарт-карт  21

Обзор приложений.. 22

Безопасность Интернета  22

Защищенная электронная почта  23

Содержание с цифровой подписью   24

Шифрующая файловая система  25

Вход в систему с помощью смарт-карт  25

Безопасность IP (IPSec) 26

Взаимодействие. 27

Критерии  27

Стандарты Интернета  27

Подготовка Windows 2000 PKI 30

E-mail на основе S/MIME, использующая Exchange Server 30

Дополнительная информация.. 32

 


Введение


Microsoft® Windows® 2000 привносит на платформу Windows полную инфраструктуру с открытым ключом (public-key infrastructure, PKI). Эта инфраструктура расширяет созданные за последние несколько лет криптографические службы с открытым ключом (public-key, PK) на основе Windows, предоставляя интегрированный набор служб и инструментов для создания, развертывания и управления приложениями на базе PK. Новая инфраструктура дает разработчикам программного обеспечения возможность использовать преимущества механизмов безопасности разделенного секрета (shared-secret security) или безопасности на основе PK в Windows. Предприятия также получают возможность управления средой и приложениями с помощью совместимых инструментов и политик.

В документе приведен обзор инфраструктуры с открытым ключом (PKI) Windows 2000.

Концепции


Криптография с открытым ключом

Криптография – наука о защите данных. Криптографические алгоритмы математически совмещают исходный открытый текст (plaintext) и ключ шифрования для получения зашифрованных данных (ciphertext).При использовании хорошего криптографического алгоритма, невозможно вычислительными методами обратить процесс и получить открытый текст, имея в наличии только шифрованные данные; для такого преобразования необходимы дополнительные данные – ключ дешифрования.

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

В противоположность этому, основным качеством криптографии с открытым ключом (public-key, PK) является то, что ключ шифрования отличается от ключа дешифрования. Шифрование открытым ключом шифрования - однонаправленный процесс; открытый текст превращается в шифрованный, но ключ шифрования не важен для дешифрования данных. Для обратного превращения шифрованного текста в открытый необходим другой ключ – ключ дешифрования (связанный, но не совпадающий с ключом шифрования). Таким образом, в криптографии PK у каждого пользователя есть пара ключей, состоящая из открытого и личного ключа. Делая общедоступным открытый ключ, вы даете другим возможность посылать вам шифрованные данные, которые могут быть дешифрованы только вашим личным ключом. Аналогично, используя свой личный ключ, вы можете таким образом преобразовать данные, что остальные пользователи могут проверить, именно ли вы их посылали. Последняя возможность является основой цифровых подписей.

Возможности открытых ключей

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

Существует ряд хорошо известных криптографических алгоритмов PK. Некоторые из них, такие как алгоритм Rivest-Shamir-Adleman (RSA) и алгоритм криптографии эллиптической кривой (Elliptic Curve Cryptography, ECC), являются универсальными; они поддерживают все вышеперечисленные операции. Другие поддерживают только часть этих возможностей. Примерами могут служить алгоритм цифровой подписи (Digital Signature Algorithm, DSA, являющийся частью государственного стандарта цифровой подписи США Федеральный стандарт по обработке информации 186), используемый только для создания цифровых подписей, и Diffie-Hellman (D-H), используемый только при соглашении о секретных ключах.

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

Цифровые подписи

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

·         Только владелец личного ключа может создать цифровую подпись.

·         Любой, кто имеет доступ к соответствующему открытому ключу, может проверить подлинность цифровой подписи.

·         Любое изменение подписанных данных (даже изменение всего лишь одного бита в большом файле) нарушает цифровую подпись.

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

Аутентификация

Криптография PK предоставляет сильные службы распределенной аутентификации. Аутентификация сущности гарантирует, что автор сообщения – тот, за кого он себя выдает. Если Алиса получает данные от Боба, а затем посылает ему запрос, зашифрованный его открытым ключом, то Боб дешифрует запрос и отсылает его обратно Алисе, подтверждая тем самым, что у него есть доступ к личному ключу, на который ссылалась Алиса при отправке запроса. Алиса также может послать Бобу запрос открытым текстом. В таком случае Боб совмещает запрос с другой информацией, которая имеет цифровую подпись. После этого Алиса использует открытый ключ для проверки его подписи и доказательства того, что он имеет доступ к соответствующему личному ключу. Запрос делает данное сообщение уникальным и предотвращает атаку методом повторного воспроизведения. В любом случае, данный прием называют протоколом подтверждения владения, поскольку отправитель доказывает, что у него есть доступ к определенному личному ключу.

Соглашения о секретных ключах посредством открытого ключа

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

Шифрование значительных объемов данных без предварительного разделения секретных данных

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

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

Защита криптографических ключей и доверие

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

Алиса может доверять открытому ключу Боба, поскольку он вручил его ей лично, но это подразумевает, что у них ранее была возможность защищенного обмена данными. Более вероятен вариант, при котором Алиса получила открытый ключ Боба незащищенным образом, (например, из общедоступного каталога), так что для обеспечения уверенности Алисы в том, что ключ, которым она пользуется, действительно принадлежит Бобу, требуется некий механизм. Один из таких механизмов основан на сертификатах, выдаваемых полномочным сертификатором (certificate authority, CA).

Сертификаты

Сертификаты предоставляют механизм удостоверения связи открытого ключа с сущностью, владеющей соответствующим частным ключом. Сертификат – снабженное электронное подписью заявление, описывающее subject public key, сертификат подписывается издателем (у которого есть другая пара открытого/частного ключей). Обычно, сертификаты также содержат прочую информацию, связанную с открытым ключом субъекта, вроде информации об идентичности сущности, имеющей доступ к соответствующему открытому ключу. Таким образом, при выдаче сертификата, издатель удостоверяет правильность связи между открытым ключом субъекта и информацией об идентичности субъекта.

Наиболее распространенная сейчас форма сертификата основывается на стандарте ITU-T X.509. Это фундаментальная технология, используемая в Windows 2000 PKI. Она, впрочем, не является единственной возможной формой сертификата; так, например, безопасные e-mail сообщения Pretty Good Privacy (PGP) основываются на собственной, присущей только PGP, форме сертификата.

Полномочные сертификаторы

Полномочный сертификатор (certificate authority, CA) – сущность или служба, выдающая сертификаты. CA служит гарантом связи между открытым ключом субъекта и информацией об идентичности субъекта, содержащейся в выдаваемом сертификате. Различные CA могут выбирать различные методы подтверждения этой связи, так что очень важно ознакомиться с политиками и процедурами, используемыми сертификатором, перед тем как доверить сертификатору поручительства за ваш ключ.

Доверие и проверка

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

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

·         Содержит криптографически корректную подпись издателя.

·         Подтверждает связь Боба и его открытого ключа.

·         Был издан тем сертификатором, которому Алиса доверяет.

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

В конце концов, Алиса достраивает цепочку сертификатов от Боба и его открытого ключа через ряд полномочных сертификаторов и до сертификата, выданного кем-то, кому Алиса полностью доверяет. Такой сертификат называется доверенным корневым сертификатом (trusted root certificate), поскольку он образует корень (верхний узел) иерархии связей открытых ключей/сущностей, которые Алиса считает подлинными (смотри раздел 4.1, Иерархия сертификатов). Когда Алиса начинает явно доверять определенному доверенному корневому сертификату, она неявным образом доверяет всем сертификатам, выданным эти доверенным корнем, как и сертификатам, выданным его подчиненными CA, сертифицированными доверенным корнем.

Набор доверенных корневых сертификатов, которым Алиса явно доверяет – единственная информация, которую Алиса должна получить безопасным образом. Этот набор сертификатов гарантирует систему доверия Алисы и ее уверенность в инфраструктуре с открытым ключом.

Компоненты Windows 2000 PKI


На рисунке 1 отображена обзорная схема компонентов Windows 2000 PKI. Это – логическое представление, и оно не предполагает физической необходимости использования различных серверов; по сути, многие функции могут выполняться одной серверной системой. Ключевым элементом PKI являются Microsoft Certificate Services. Это дает вам возможность развертывать один или более CA уровня предприятия. Эти CA поддерживают выдачу и отзыв сертификатов. Они интегрированы с Active Directory, которая предоставляет информацию о расположении и политике CA, и делает возможной публикацию информации о сертифицировании и отзыве.

Инфраструктура PKI не заменяет существующих в Windows механизмов доверия доменам (domain trust) и механизмов авторизации, основанных на контроллерах доменов (domain controller, DC) и центрах распределения ключей Kerberos (Kerberos Key Distribution Center, KDC). Напротив, PKI работает совместно с этими службами и предоставляет расширения, дающие приложениям возможность легко подстраиваться под требования масштабов extranet и Internet. В частности, PKI направлена на нужды масштабируемых и распределенных идентификации, аутентификации, целостности и конфиденциальности.

Рисунок 1. Компоненты инфраструктуры с открытым ключом Windows 2000

Поддержка создания, развертывания, и управления приложениями на базе PK одинаково предоставляется как на рабочих станциях и серверах под управлением Windows 2000 или Windows NT, так и рабочих станциях под управлением Windows 95 и Windows 98. На рисунке 2 предоставлен обзор этих служб. Microsoft CryptoAPI – является основой этих служб и предоставляет стандартный интерфейс к криптографическим возможностям, предоставляемым подключаемыми провайдерами криптографических служб (cryptographic service providers, CSP). Эти CSP могут быть основаны как на программном обеспечении, так и использовать возможности аппаратных шифрующих устройств, и могут поддерживать широкий спектр алгоритмов и длин ключей. Как видно из рисунка, один из возможных аппаратных CSP поддерживает смарт-карты. Некоторые CSP, поставляемые с Windows 2000 используют преимущества инфраструктуры Microsoft PC/SC-совместимых смарт-карт (см. http://www.microsoft.com/smartcard/ и http://www.smartcardsys.com/).

На криптографических службах основывается ряд служб управления сертификатами. Сюда входит поддержка сертификатов стандарта X.509 версии 3, предоставление постоянного хранилища, служб перечисления, и поддержки дешифрования. Наконец, существуют службы, работающие с повсеместно используемыми стандартами сообщений. В первую очередь, сюда входит поддержка стандартов PKCS и развивающихся стандартов инфраструктуры с открытым ключом проблемной группы проектирования Интернет (Internet Engineering Task Force, IETF) и X.509 (PKIX).

Другие функции, на возможности которых опирается CryptoAPI, предоставляют дополнительные возможности для разработчиков приложений. Secure Channel (schannel) поддерживает сетевую аутентификацию и шифрование с использованием широко распространенных протоколов TLS и SSL. Доступ к ним может быть получен через интерфейс Microsoft WinInet для использования с протоколом HTTP (HTTPS) и другими протоколами через интерфейс SSPI. Authenticode поддерживает подпись проверку объектов. Она в основном используется для определения источника целостности компонентов, загруженных из Internet, хотя может использоваться и в других средах. Наконец, поддерживаются смарт-карты общего пользования. Они используются для интеграции криптографических смарт-карт независимым от приложений образом и являются основой службы входа в систему на основе смарт-карт, встроенной в Windows 2000.

Рисунок 2. Службы приложений с открытым  ключом

Полномочные сертификаторы


Microsoft Certificate Services, поставляемые с Windows 2000, предоставляют организации все средства для простой организации CA для удовлетворения задач бизнеса. В Certificate Services входит модуль политики "по умолчанию", подходящий для издания сертификатов сущностям внутри предприятия (пользователям, компьютерам или службам). Сюда входит идентификация запрашивающей стороны и проверка доступности запрашиваемого сертификата в рамках доменной политик безопасности PK. Все это может быть легко изменено или расширено для того, чтобы соответствовать каким-либо другим соображениям политики или расширить поддержку CA для различных сценариев extranet или Internet. Поскольку Certificate Services основаны на стандартах, создается широкая поддержка приложений с возможностями PK в гетерогенных средах.

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

Иерархия сертификатов

Windows 2000 PKI подразумевает иерархическую модель CA. Она была выбрана из соображений масштабируемости, простоты администрирования и взаимодействия с растущим числом коммерческих CA и продуктов третьих фирм. В своей простейшей форме, иерархия CA состоит из одного CA, хотя, в общем, иерархия состоит из нескольких CA с четко определенными отношениями родитель-ребенок, как видно из рисунка 3. Как указано там же, в сферу интересов может попадать несколько несвязанных иерархий. Абсолютно необязательно, чтобы все CA имели общего CA верхнего уровня (корень).

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

Рисунок 3: Иерархия CA

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

·         Использование – Сертификаты могут выдаваться в различных целях (например, безопасная электронная почта, сетевая аутентификация, и так далее). Политика выдачи для этих целей может отличаться, а разделение дает возможность администрировать эти политики.

·         Организационное деление – В зависимости от роли сущности в организации могут быть различные политики выдачи сертификатов. И вновь, создание нескольких выдающих CA облегчает разделение и управление этими политиками.

·         Географическое деление – Организации могут иметь сущности на различных физических площадках. Сетевое объединение этих площадок может диктовать необходимость создание нескольких CA для соответствия требованиям использования.

Подобная иерархия CA также дает ряд административных преимуществ, включая:

·         Гибкую конфигурацию среды безопасности CA (длина ключа, физическая защита, защита от сетевых атак, и так далее) для достижения компромисса между защитой и простотой использования. Например, вы можете решить использовать специальное криптографическое аппаратное обеспечение на корневом CA, работать на нем в физически защищенной области или работать на нем в отключенном от сети состоянии. Эти решения, в то же время, могут быть неприемлемыми для выдающих CA из соображений простоты использования.

·         Использование достаточно частых обновлений ключей и/или сертификатов выдающих CA, которые наиболее подвержены риску, без нарушения их доверительных отношений.

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

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

Развертывание CA в предприятии

Развертывание Microsoft Certificate Services – достаточно простая операция. Рекомендуется сначала задать домен перед созданием CA. Затем установите корневой CA или несколько CA уровня предприятия. Процесс установки Certificate Services проводит администратора через этот процесс[A.A.R1] . В ключевые элементы процесса установки входят:

·         Выбор головного сервера – Корневой CA может работать на любой платформе Windows 2000 Server, включая доменный контроллер. При принятии данного решения следует учитывать такие факторы, как требования физической безопасности, ожидаемая загрузка, требования связи, и так далее.

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

·         Создание ключа – Пара открытых ключей CA создается в ходе процесса и уникальна для данного CA.

·         Сертификат CA – Для корневого CA, процесс установки автоматически создает самоподписанный сертификат CA, используя пару открытого/личного ключей CA. Для "дочернего" CA может быть создан запрос сертификата, который можно отослать корневому CA или CA-посреднику.

·         Интеграция в Active Directory – Информация, затрагивающая CA, записывается при установке в объект CA в Active Directory. Это дает доменным клиентам информацию о доступных CA и типах выдаваемых ими сертификатов.

·         Политика выдачи – Программа установки CA масштаба предприятия автоматически устанавливает и конфигурирует поставляемый Microsoft модуль политики предприятия для CA. Авторизованный администратор может изменить политику, хотя в большинстве случаев это не нужно.

Послу установки корневого CA возможна установка промежуточного или выдающего CA, подчиненного корневому. Единственным важным отличием в политике установки является то, что создается запрос на сертификат, который отправляется корневому или промежуточному CA. Этот запрос может быть автоматически направлен работающему CA, обнаруженному с помощью Active Directory, или вручную направлен в случае автономного сценария. В любом случае, полученный сертификат должен быть установлен на CA прежде, чем он начнет работу.

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

CA – ценные ресурсы, и, как уже говорилось выше, желательно защищать их должным образом. Вот некоторые конкретные вещи, которые следует принять во внимание:

·         Физическая защита – Поскольку CA представляют собой сущности с высоким уровням доверия в предприятии, их следует защищать от преступного использования. Это требование зависит от внутреннего значения сертификации, производимой CA. Физическая изоляция сервера CA в условия, доступные только администраторам безопасности, может сильно уменьшить возможность подобных атак.

·         Управление ключами – Ключи CA – наиболее ценное имущество, поскольку личный ключ создает фундамент доверия в сертификационном процессе. Криптографические аппаратные модули (доступные Certificate Services через CryptoAPI CSP) могут предоставить защищенное от вторжения хранилище ключей и изолировать криптографические операции от прочего программного обеспечения, работающего на сервере. Это значительно уменьшает возможность того, что ключ CA будет подвергнут риску.

·         Восстановление – Утеря CA из-за аппаратного сбоя, например, может создать ряд административных и рабочих проблем и не допустить отзыва существующих сертификатов. Certificate Services поддерживают резервирование экземпляров CA таким образом, что они могут быть впоследствии легко восстановлены. Это весьма важная часть общего процесса управления CA.

Доверие в нескольких иерархиях CA

Из предыдущих разделов видно, что Windows 2000 PKI должна работать с отношениями доверия в нескольких иерархиях CA. Это может влиять как на иерархии CA внутри одного предприятия, так и на иерархии в нескольких предприятиях, в том числе и коммерческие CA (такие как VeriSign, Thawte и другие).

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

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

Альтернативой явному включению всех доверенных корневых CA в объект политики является использование перекрестных сертификатов. Они использовались, как минимум в одном продукте производителя PKI и дают возможность создать цепочку доверия от одного, доверенного, корневого CA к нескольким прочим CA. Инфраструктура PKI в Windows 2000 способна обрабатывать подобные перекрестные сертификаты и использовать их при принятии решений о доверии, но они не являются необходимыми в данной модели. Microsoft выбрала это подход из-за поднимаемых перекрестными сертификатами вопросов, а именно:

·         Неопределенная интерпретация перекрестных сертификатов поверх границ организации при реализации CA неравноправных политик.

·         Интерпретация перекрестных сертификатов в условиях отсутствия существующих деловых соглашений об их использовании.

·         Дополнительные административные затраты при создании и поддержке перекрестных сертификатов.

Работа с доменными клиентами


Операционная система Windows 2000 предоставляет обширный набор основных служб, поддерживающих разработку и развертывание взаимодействующих приложений на основе PK. Они также доступны в Windows NT 4.0, Windows 98 и Windows 95. Наиболее значительной новой возможностью реализации Windows 2000 является интеграция с моделями доменного администрирования и политики, что значительно упрощает управление приложениями на предприятии.

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

Создание ключей

Использование технологии PK зависит от возможности создавать и управлять ключами одного или нескольких алгоритмов PK. Интерфейс программирования Microsoft CryptoAPI поддерживает устанавливаемые CSP, которые поддерживают создание ключей и управление различными криптографическими алгоритмами. Интерфейс CryptoAPI определяет стандартные, единые для всех CSP, интерфейсы создания ключей и управления ими.

Механизмы хранения ключевого материала зависят от выбранного CSP. Поставляемые Microsoft программные CSP (или базовые CSP) хранят ключевой материал в зашифрованном виде либо для каждого пользователя (per-user) либо для компьютера (per-computer). Они так же поддерживают контроль за экспортом пар открытых ключей (флаг CRYPT_EXPORTABLE) и контроль использования (флаг CRYPT_USER_PROTECT). Первый управляет экспортом личный ключей из CSP; второй определяет то, как предупреждается пользователь при попытке приложения использовать личный ключ. Прочие CSP могут реализовывать различные механизмы. Например, CSP на смарт-картах хранят пары открытых ключей в устойчивой к взломе аппаратуре смарт-карт и обычно требуют ввода PIN-кода для получения доступа к операциям, требующим личного ключа. Эти защитные механизмы прозрачны для приложений, обращающихся ко всем ключевым парам по имени набора ключей, уникальному в контексте CSP.

Восстановление ключей

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

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

Microsoft Exchange Server на данный момент предоставляет поддержку восстановления ключей обмена ключами таким образом, что шифрованные e-mail сообщения могут быть прочитаны. Более того, существуют CSP третьих фирм, предоставляющие общую поддержку восстановления ключей. Корпорация Microsoft может в будущем включить дополнительную поддержку восстановления ключей в зависимости от желаний пользователей.

Регистрация сертификатов

Как уже упоминалось, практическое использование технологии на базе PK в основном полагается на сертификаты, связывающие открытые ключи с известными сущностями. Windows 2000 PKI поддерживает регистрацию сертификатов в CA масштаба предприятия корпорации Microsoft или CA третьих фирм. Регистрация сертификатов реализована независимо от транспорта и основывается на использовании широко распространенных сообщений о запросе сертификата PKCS-10 и ответов PKCS-7, содержащих получившийся сертификат или цепочку сертификатов. На данный момент, поддерживаются сертификаты, поддерживающие ключи и подписи RSA, ключи и подписи DSA и ключи Diffie-Hellman.

Поддержка сообщений PKCS-10 и PKCS-7 предоставляется поставляемым Microsoft управляющим элементом регистрации (Xenroll.dll), который может управляться как из языка сценариев (для регистрации из Web), так и программно для поддержки прочих транспортных механизмов, таких как RPC, DCOM, и e-mail. Этот элемент управления дает вызывающему приложению возможность задать атрибуты, входящие в сообщение PKCS-10 и позволяет использование существующей пары ключей или создание новой пары. Процесс регистрации подразумевается асинхронным, а элемент управления регистрацией предоставляет управление состояниями для сопоставления выданных сертификатов и ожидающих запросов. Таким образом предоставляются средства для создания внутренней связи между сертификатом, CSP, создающим пару ключей и именем контейнера пары ключей.

PKI поддерживает несколько методов регистрации, включая регистрацию через Интернет, мастер регистрации и управляемую политикой авто-регистрацию, происходящую при обработке входя пользователя в систему. В будущем, процесс регистрации сертификата будет развиваться согласно проекту синтаксиса запроса сертификата (Certificate Request Syntax, CRS) находящемуся в разработке IETF PKIX.

Обновление

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

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

Пока еще не определены широко используемые протоколы сообщений для обновления сертификатов, но включены в черновик IETF PKIX CRS. Как только эти стандарты будут одобрены, Microsoft планирует реализовать соответствующие форматы сообщений.

Использование ключей и сертификатов

В Microsoft PKI, криптографические ключи и связанные с ними сертификаты хранятся и управляются подсистемами CryptoAPI. Как уже упоминалось, ключи управляются CSP, а сертификаты – хранилищами сертификатов CryptoAPI.

Хранилища сертификатов – это хранилища для сертификатов и связанных с ними свойств. По соглашению, PKI определяет пять стандартных хранилищ сертификатов:

·         MY – Это хранилище используется для хранения пользовательских или компьютерных сертификатов, для которых доступен связанный личный ключ.

·         CA – Это хранилище используется для хранение сертификатов выдающих или промежуточных CA для построения цепочек проверки сертификатов.

·         TRUST – Это хранилище используется для хранения списков доверия сертификатов (Certificate Trust Lists, CTL). Это – дополнительный механизм, благодаря которому администратор может задать набор доверяемых CA. Их преимуществом является то, что они могут передаваться по незащищенным каналам, поскольку они имеют цифровую подпись.

·         ROOT – Это хранилище содержит только самоподписанные сертификаты CA для доверенных корневых CA.

·         UserDS – Это хранилище предоставляет логическое представление хранилища сертификатов Active Directory (например, из свойства userCertificate объекта User). Его целью является упрощение доступа к внешним хранилищам.

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

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

Восстановление

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

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

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

Роуминг

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

Windows 2000 PKI поддерживает роуминг двумя путями. Во-первых, в том случае, если используются основные CSP Microsoft, роуминг ключей и сертификатов поддерживается механизмом путешествующих профилей. Этот механизм прозрачен для пользователя с того момента, как разрешаются путешествующие профили. Маловероятно, что эти возможности будут поддерживаться CSP третьих фирм, поскольку они обычно используют другой метод хранений данных о ключах, зачастую на аппаратном обеспечении. Во-вторых, аппаратные опознавательные устройства, такие как смарт-карты, поддерживают роуминг, из расчета на наличие внутреннего физического хранилища сертификата. CSP смарт-карт, поставляемый с Windows 2000, поддерживает эту возможность. Пользователь просто переносит аппаратное опознавательное устройство на новое место.

Отзыв

Хотя сертификаты и должны быть долгоживущими грамотами, существует ряд случаев, в которых действие этих грамот должно быть прекращено до истечения срока их действия. Примерами может служить:

·         Компрометация, или подозрения компрометации личного ключа сущности.

·         Мошенничество при получении сертификата.

·         Изменение статуса.

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

Необходимость в информации об отзыве, и ее своевременность, зависит от приложения. Для поддержки всего разнообразия операционных факторов, Windows 2000 PKI осуществляет поддержку широко распространенных списков отзыва сертификатов (Certificate Revocation Lists, CRL). CA предприятия поддерживают отзыв сертификатов и распространение CRL в Active Directory под административным контролем. Клиенты домена могут получить эту информацию и кэшировать ее локально для использования при проверке сертификатов. Тот же механизм поддерживает CRL, изданные коммерческими CA или сертификатными продуктами третьих фирм, из расчета на то, что опубликованные CRL доступны клиентам сети.

Доверие

Основная проблема доверия клиенту при использовании технология на базе PK является доверие, связанное с проверкой сертификатов. Это обычно основывается на доверии, связанном с CA, выдавшим сертификат. Как уже обсуждалось, PKI подразумевает наличие иерархии CA, в которой управление доверием основывается на решениях, затрагивающих корневые CA. Если данный сертификат конечной сущности может предъявить цепочку к известному доверенному корневому CA, а предполагаемое использование сертификата совпадает с контекстом приложения, он считается корректным. В случае отсутствия любого из этих условий, он считается некорректным.

В PKI, пользователи могут принимать решения по доверию, которые затрагивают только их самих. Они делают это посредством установки ли удаления корневых доверенных CA и управления связанными ограничениями использования инструментами управления и администрирования. Это должно быть, однако, исключением, а не общепринятой практикой. Эти отношения доверия должны задаваться политикой предприятия (Смотри следующий раздел, Политика безопасности PK в Windows 2000.) Отношения доверия, заданные политикой, автоматически продвигаются на клиентские компьютеры под управлением Windows 2000.

Политика безопасности PK в Windows 2000


Политики безопасности могут налагаться на узлы (site), домены или организационные единицы (organizational units, OU), и влиять на соответствующие группы безопасности и пользователей и компьютеров. Политика безопасности PK – это только одна сторона общей политики безопасности Windows и интегрирована в эту структуру. Она предоставляет механизм централизованным образом задавать и управлять политику, проталкивая ее повсеместно. Наиболее важные стороны политики безопасности PK обсуждаются ниже.

Доверенные корневые CA

Доверенные корневые CA могут задаваться политикой для установки основных доверительных отношений, используемых доменными клиентами для подтверждения сертификатов PK. Набор доверенных CA конфигурируется с помощью редактора групповой политики. Он может задаваться по-машинно и накладываться на всех пользователей этого компьютера.

Кроме указания корневого CA как доверенного, администратор также может устанавливать свойства применения, связанные с CA. При указании, они ограничивают круг целей, для которых действительны сертификаты, выданные CA. Ограничения основаны на идентификаторах объектов (OID) согласно определению расширений ExtendedKeyUsage в черновике IETF PKIX, часть 1. На данный момент это предоставляет возможности для ограничения любой комбинации следующего:

·         Аутентификации сервера

·         Аутентификации клиента

·         Подписи кода

·         E-mail

·         Конечной системы безопасности (IP Security, IPSec)

·         Туннелирования IPSec

·         Пользователей IPSec

·         Указания времени (time-stamping)

·         Шифрующей файловой системы Microsoft

Выдача и обновление сертификатов

Частью интеграции PKI с Windows 2000, стало определение в политике механизма поддержки автоматической выдачи сертификатов. Это контролируется двумя ключевыми элементами: типами сертификатов и объектами автоматической выдачи. Они интегрированы в объект групповой политики и могут определяться на основе узле, домена, организационной единицы, компьютера, или пользователя.

Типы сертификатов предоставляют шаблон для сертификата и ассоциируют его для простоты администрирования с общим именем. Шаблон определяет элементы – требования к именованию, срок годности, допустимые CSP для создания личного ключа, алгоритмы и расширения, которые следует включить в сертификат. Типы сертификатов логически разделяются на компьютерные и пользовательские типы и налагаются на объекты политики соответственным образом. Сразу после определения эти типы сертификатов становятся доступны для использования в объектах автоматической выдачи и мастере выдачи сертификата.

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

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

Вход в систему с помощью смарт-карт

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

Обзор приложений


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

Безопасность Интернета

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

·         Серверная аутентификация – Позволяет клиентам проверять тот сервер, с которым они работают.

·         Клиентская аутентификация – Позволяет серверам проверять идентичность пользователя и использовать ее для принятия решений по управлению доступом.

·         Конфиденциальность – Позволяет шифровать данные между клиентами и серверами, что предотвращает ее раскрытие при передаче по открытым каналам Интернета.

Протоколы Secure Sockets Layer (SSL) и Transport Layer Security (TLS), развивающийся стандарт IETF играют значительную роль в решении этих вопросов. Протоколы SSL и TLS – это гибкие протоколы безопасности, которые могут быть наложены поверх других транспортных протоколов. Они основываются на технологии аутентификации на базе PK и используют согласование ключей на базе PK для создания уникального ключа шифрования для каждой сессии клиент/сервер. Они обычно ассоциируются с приложениями на базе Web и протоколом HTTP (называемым HTTPS).

Протоколы SSL и TLS поддерживаются на платформе Windows провайдером SSPI защищенного канала (secure channel, Schannel). Microsoft Internet Explorer и Internet Information Services используют Schannel для предоставления этих возможностей. Поскольку Schannel интегрирован в архитектуру Microsoft SSPI, он доступен для использования с многими протоколами для поддержки аутентифицируемых и/или шифруемых линий связи.

Для полной реализации возможностей протоколов SSL и TLS необходимо, чтобы как клиент, так и сервер имели идентификационные сертификаты, выданные взаимно доверяемыми CA, что позволит партнерам аутентифицировать друг друга. В данном режиме обмен сертификатами происходит вместе с данными, что удостоверяет наличие соответствующего личного ключа. Каждая из сторон может затем проверить сертификат и удостовериться во владении личным ключом, используя открытый ключ сертификата. Идентификационная информация, включенная в сертификат, может использоваться для принятия дополнительных решений по контролю за доступом. Например, клиент может решить, является ли сервер тем, с кем он собирается вести дела, а сервер – какие данные доступны клиенту.

Windows 2000 PKI включает поддержку последних решения в качестве стандартного компонента Windows 2000 Server. Сертификаты пользователя могут быть привязаны по принципу "один-к-одному" или "несколько-к-одному" к принципалам безопасности (объектам пользователя) в Active Directory. Schannel может использовать эту информацию для автоматического создания идентификатора безопасности для клиента, так, чтобы механизмы Windows ACL могли использоваться для контроля доступа к ресурсам. Это полезно для служб, поскольку они могут использовать одни и те же механизмы контроля доступа вне зависимости от используемого механизма клиентской аутентификации (PK или Kerberos).

Как только клиент и сервер аутентифицировал друг друга, они могут согласовать сессионный ключ и начать защищенное общение. SSL и TLS также часто используются таким образом, что клиентская аутентификация не является необходимой. Использование взаимной аутентификации рекомендуется, однако, в средах предприятия, поскольку она позволяет вам использовать механизмы контроля за доступом на основе Windows. Более того, использование PKI значительно упрощает выдачу и управление сертификатами, что уменьшает нагрузку на клиента.

Защищенная электронная почта

Продукты с системами безопасности электронной почты на основе PK, включая Microsoft Exchange, доступны уже несколько лет и получили широкое распространение. Эти системы базируются на технологии PK в части:

·         Цифровые подписи, подтверждающие источник и подлинность сообщения e-mail.

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

Распределенная природа электронной почты, и доверие к транспорту "сохрани-и-пошли дальше" (store-and-forward) для многих пользователей, были определяющими факторами использования технологии PK. Альтернативные варианты, основанные на криптографии с предварительным разделением секретных данных, навязывали дополнительные требования административной и физической безопасности, что затрудняло их использование.

Ограничением некоторых ранних реализаций было отсутствие совместимости продуктов различных поставщиков. В условиях отсутствия подходящих стандартов поставщики реализовывали системы, которые основывались на собственных протоколах, кодировках сообщений, и допущениях доверия, которые и определили невзаимодействующие PKI. (PGP, хотя и широко используется, тоже принадлежит к этой категории, поскольку ее форматы сообщений так и не стали основой взаимодействующих защищенных приложений e-mail в индустрии.) Только недавно начала появляться основа взаимодействующих защищенных систем e-mail, с предписываемым IETF стандартом S/MIME версии 3, который основывается на предложении S/MIME версии 2, исходившем от RSA Data Security. Не смотря на статус разработки, S/MIME уже реализован в ряде продуктов, включая клиент сообщений и совместной работы Microsoft Outlook® 98 и Microsoft Outlook Express, с доказанной возможностью взаимодействия с разными производителями цифровых подписей и шифрования PK на основе алгоритмов RSA.

В действии эти системы используют личный ключ пользователя для цифровой подписи исходящего сообщения e-mail. Пользовательский сертификат высылается вместе с сообщением e-mail, так что пользователь может проверить корректность подписи. S/MIME определяет профиль этих сертификатов, что удостоверяет возможность взаимодействия и подразумевает иерархическую модель CA для предоставления масштабируемого управления доверием. Для шифрования почтовых сообщений, пользователь получает шифровальный сертификат получателя, либо из более раннего сообщения, либо из службы каталогов. Как только подлинность этого сертификата установлена, пользователь может использовать содержащийся в нем открытый ключ для шифрования секретного ключа, используемого для шифрования сообщений электронной почты.

Содержание с цифровой подписью

Расширяющееся использования Интернета вызвало доверие к загружаемому активному содержанию (контенту), как, например, приложения на базе Windows, управляющие элементы ActiveX®, и Java-апплеты. Это привело к сомнениям по поводу безопасности такого содержания, поскольку его загрузка часто является побочным эффектом действия какого-либо веб-сценария и не выдает никакого предупреждения пользователю. Для удовлетворения этой озабоченности, Microsoft в 1996 году представила технологию цифровой подписи AuthenticodeTM и значительно обновила ее в 1997.

Технология Authenticode позволяет распространителям программного обеспечения снабжать цифровой подписью любую форму активного содержания, включая архивы из нескольких файлов. Эти подписи могут быть использованы для проверки как распространителя содержания, так и целостности содержания в момент загрузки. Эта инфраструктура проверки масштабируется до размеров пользователей Windows по всему миру, основываясь на иерархической структуре CA, в которой малое количество CA выдает сертификаты на распространение программного обеспечения. Для нужд предприятия, Windows 2000 PKI позволяет вам выдавать сертификаты Authenticode внутренним разработчикам или подрядчикам и позволяет любому служащему проверить источник и целостность загруженного приложения.

Шифрующая файловая система

Шифрующая файловая система (Encrypting File System, EFS) Windows 2000 поддерживает прозрачное шифрование и дешифрование файлов, хранимых на диске под управлением файловой системы Windows NT (NTFS). Пользователь может назначить отдельные файлы для шифрования, или же целые папки, чье содержимое должно храниться в зашифрованном виде. Приложения получают доступ к шифрованным файлам пользователя так же, как и к нешифрованным. Однако они не могут дешифровать шифрованные файлы других пользователей.

EFS широко использует технологии, основанные на PK, для предоставления механизмов шифрования файлов для нескольких пользователей и поддержки восстановления файлов. Для этого она использует возможность PK поддерживать массовое шифрование без предварительного разделения секретных данных. Каждый пользователь EFS создает пару открытых ключей и получает сертификат EFS. Сертификат выдается полномочным сертификатором предприятия в домене Windows 2000, хотя EFS может создавать и самоподписанные сертификаты для автономного функционирования в том случае, когда нет необходимости в совместном доступе к данным. Более того, Windows 2000 поддерживает политику восстановления EFS, при которой могут быть назначены доверенные агенты восстановления. Эти агенты создают пару открытых ключей восстановления EFS и получают сертификат восстановления EFS от CA предприятия. Сертификаты агентов восстановления EFS размещаются на клиентах домена посредством объекта групповой политики.

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

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

Вход в систему с помощью смарт-карт

Windows 2000 обеспечивает основанный на PK вход в систему с помощью смарт-карт в качестве альтернативы паролям. Этот метод основан на совместимой с PC/SC инфраструктуре смарт-карт, впервые представленной в Windows NT и Windows 95 в декабре 1997 г., и смарт-картах с возможностями RSA и с поддержкой CryptoAPI CSP. Процесс аутентификации использует протокол PKINIT, предложенный рабочей группой Kerberos IETF, для интеграции аутентификации на основе PK с системой контроля доступа на основе Kerberos Windows 2000.

Система распознает считывание смарт-карты в качестве альтернативы стандартной защищенной последовательности CTRL + ALT + DEL для инициации процедуры входа в систему. После этого пользователю предлагается ввести PIN-код смарт-карты, контролирующий операции с личным ключом, хранящимся в смарт-карте. В данной системе, смарт-карта также хранит копию сертификата пользователя (выданного CA предприятия). Это позволяет пользователю путешествовать по домену.

Безопасность IP (IPSec)

IPSec определяет протоколы сетевого шифрования на уровне протокола IP. IPSec не требует технологий на основе PK и может использовать предварительно разделенные ключи, сообщаемые по защищенной внешней линии в конечные точки сети. Рабочая группа IPSec IETF признала, однако, что технологии на основе PK предлагают практическое решение для создания распределенной архитектуры доверия, в частности, той, при которой устройства IPSec могут взаимно аутентифицировать друг друга и соглашаться о ключах шифрования без опоры на предварительно заключенное соглашение о разделенных секретных данных.

Сообщество IPSec, включая Microsoft, активно работает над стандартами взаимодействующих сертификатов и протоколов выдачи и управления сертификатами. Хотя некоторый уровень взаимодействия уже был продемонстрирован, для удостоверения широкой совместимости между устройствами IPSec и реализациями PKI все еще необходима работа. Microsoft старается разрабатывать свою Windows 2000 PKI в соответствии с этими развивающимися стандартами.

Взаимодействие


Критерии

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

Индустрия еще не достигла такого уровня взаимодействия. С увеличением числа приложений, работающих с технологиями на основе PK, достижима полная интеграция. На сегодняшний день, SSL/TLS и S/MIME прекрасно работают на продуктах различных поставщиков. Более новые приложения, вроде подписи кода и форм с цифровой подписью пока еще ненадежны. Более неприятным является тот факт, что пока еще не существует технического механизма сравнения имен в разных кодировках. Код Unicode, например, позволяет различным образом кодировать символы с диакритическими знаками.

В будущем, как минимум две силы будут являться движущим фактором совместимости:

·         Изначальные попытки, за которыми последует увеличивающаяся зависимость от систем на основе PK.

·         Больший упор на стандарты.

Корпорация Microsoft участвует в развитие стандартов, связанных с PK, и старается создавать продукты, основанные на принятых на данный момент стандартах, что должно улучшить взаимодействие.

Стандарты Интернета

Стандарты Интернета не гарантируют взаимодействия, хотя и помогают в этом. Исторически сложилось так, что развертывание коммерческого продукта опережает процессы сотрудничества. Это особенно верно в технологиях PK, где IETF уже создало несколько активно работающих групп, разрабатывающих предлагаемые стандарты для технологий на основе PK. Многие из приложений, которые могут выиграть от этих стандартов, уже в продаже. Более того, ни один стандарт не может удовлетворить все запросы какого-либо приложения. Даже самые всеобъемлющие стандарты должны быть адаптированы в процессе реализации. Взаимодействие, таким образом, это результат стандартизации под воздействием рыночной реальности.

Рабочая группа IETF, которой дано задание по определению основ взаимодействующей PKI, это PKIX (X.509). После почти трех лет работы, создание основы архитектуры завершено. Спецификация, RFC 2459, Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1 доступна на ftp://ftp.isi.edu/in-notes/rfc2459.txt. Корпорация Microsoft вовлечена в работу по этому стандарту вместе с IETF и заинтересована в том, чтобы ее продукты PKI были совместимы с этим стандартом. После утверждения стандарта, он станет важным фактором в определении устойчивой PKI, которая будет гарантировать, что сертификаты могут быть запрошены, интерпретированы и отозваны некоторым стандартным способом.

В IETF существует также ряд других инициатив, которые могут оказать значительное влияние на взаимодействие PKI. Они вызваны нуждами приложений на основе PK, особенно TLS, S/MIME, and IPSec. В каждом случае, эти приложения создали необходимость по определению подмножества PKIX, удовлетворяющего их нуждам; зачастую они превосходят заданный PKIX набор функций. Хотя это, как может показаться, и разбивает процесс на части, в то же время, этим обеспечивается быстрая обратная связь дизайнеров PKI.

Уже не является сюрпризом то, что наиболее агрессивным набором зависящих от приложений стандартов являются плоды творчества рабочей группы IETF S/MIME (http://www.ietf.org/ids.by.wg/smime.html). Из них наиболее важны (S/MIME) Cryptographic Message Syntax, S/MIME Version 3 Message Specification, S/MIME Version 3 Certificate Handling, and Certificate Request Syntax. Сообщество S/MIME, как и TLS до того, имело преимущество: оно начинало с существующего de facto стандарта . PKIX также начинала со стандарта (X.509), но он оказался неподходящим для основы систем на базе PK. Это означает, что PKIX Part 1, основной стандарт IETF, набирается опыта у тех приложений, которые пытаются его использовать. Свежим примером процесса обратной связи является проверка цепочки сертификатов.

PKIX Part 1 предлагает, но не задает, алгоритм проверки цепочки сертификатов. Одной из возможных реализаций текущего проекта Internet является то, что цепочка имен (name-chaining, когда сравнивается имя издателя сертификата с именем CA в поле субъекта родительского сертификата) всегда должны проводиться, даже если информация вроде AuthorityKeyIdentifier (издатель открытого ключа) имеется в наличии. Неотъемлемой проблемой такого подхода является, однако, то, что он не подходит двум значительным средам открытого ключа: той, в которой нет службы каталогов для обнаружения сертификата CA по имени, и тех сложных вариантов, в которых наличествует сложная сеть CA с перекрестным сертифицированием. Рабочая группа PKIX не сталкивалась с этими проблемами до тех пор, пока приложения не попытались обобщить свои алгоритмы проверки цепочки и не обнаружили невозможность этого. Положительным эффектом этого явилась работа обратной связи, а новый механизм сейчас реализуется в стандарте.

Существует также весьма важная усиливающая функция в поле зрения взаимодействия PKI. Национальный институт стандартов (National Institute of Standards, NIST) установил рабочую группу по взаимодействию, состоящую из AT&T, CertCo, Certicom, Cylink, Digital Signature Trust, Dynacorp, Entrust, Frontier Technologies, GTE, ID Certify, MasterCard, Microsoft, Motorola, Spyrus, VeriSign, и Visa. Целью этого проекта является гарантирование минимального взаимодействия между реализациями PKIX Part 1 членов рабочей группы. NIST оптимистично считает, что этот форум решит любые двусмысленности и/или ошибки в новом стандарте PKIX.

Еще один фактор, влияющий на определение стандартов PKI, лежит вне IETF. Существует ряд криптографических стандартов сообщений (PKCS) de facto, созданный и поддерживаемый RSA Laboratories (http://www.rsa.com/rsalabs/html/standards.html), который уже широко распространен в продуктах. Стандарты PKCS, впервые опубликованные в 1990 г., включают в себя синтаксис криптографических сообщений. Стандарты, наиболее близкие к PKI – это PKCS-7, Cryptographic Message Syntax Standard, и PKCS-10, Certification Request Syntax Standard. Значение стандартов RSA в том, что они предоставляют основной, но хорошо понятный каркас взаимодействия. Фактически, в то время как рабочая группа PKIX предложила новый стандарт управления сертификатами, рабочая группа S/MIME создала собственное предложение, основанное на PKCS. Такой ответ типичен для практики IETF и отражает осведомленность в делах рынка. Стандарты de facto зачастую являются лучшим выбором; Microsoft воспользовалась этими стандартами в текущей реализации PKI для увеличения взаимодействия

Термин инфраструктура подразумевает, что PKI сами могут быть объединены вместе. Если, к примеру, отдел компании решает использовать модель PKI поставщика A для своих приложений, а компания позже решает использовать модель поставщика B для системы почты, имеет смысл ожидать некоторого перекрытия. Задача становится сложнее, когда компания A и компания B хотят избирательно объединить их PKI в конкретной коммерческой extranet. Техническая сложность проистекает их необходимости привязки отношения доверия (кто кому что доверяет) между сущностями и их отслеживания со временем. На данный момент существует три конкурирующих модели того, как должны работать отношения доверия:

·         Иерархии (например, VeriSign, Microsoft, и Netscape)

·         Сети (например, Entrust)

·         Паутины (например, PGP)

Каждая из этих трех моделей подразумевает, нечто свое о том, как устанавливаются и поддерживаются доверительные отношения, создаются ли они напрямую или же через посредника. Different trust models probably will not interoperate seamlessly. В лучшем случае, в PKI может быть встроена некоторая гибкость, вместе с поддерживающими административными инструментами, что позволило бы пользователям интегрировать отдельные модели доверия таким образом, что это имело бы смысл в конкретных коммерческих ситуациях.

Подготовка Windows 2000 PKI


E-mail на основе S/MIME, использующая Exchange Server

Защита на основе PKI относительно нова, и существует весьма малое число примеров развертывания PKI. Для развертывания PKI в широких масштабах корпорация должна обучить своих пользователей, осознать вопросы, связанные с управлением ключами/сертификатами и осознать риск и ответственность, связанные с PKI. Существует ряд компаний, которые могут предоставить помощь по этим вопросам. Список доступен на www.microsoft.com/security/partners/.

Одной из наиболее распространенных областей, которые могут выиграть от использования безопасности PKI, является электронная почта. Используя S/MIME, основанный на PKI, пользователи могут отсылать сообщения с цифровой подписью и зашифрованные сообщения e-mail. Благодаря использованию e-mail на основе S/MIME, корпорации могут начать развертывание PKI и набирать опыт и определенные знания.

Корпорация Microsoft рекомендует пользователям, желающим развертывать PKI, начать с Microsoft Exchange Server 5.5 (SP1) и клиента сообщений и сотрудничества Microsoft Outlook 98, предоставляющих возможности e-mail на основе S/MIME. Ключевыми элементами PKI, включенными в Microsoft Exchange и Microsoft Outlook, являются:

·         Сервер управления ключами с встроенными возможностями восстановления ключей.

·         Сервер сертификатов X.509 версии 3 Server.

·         Служба каталогов Exchange на основе LDAP.

·         Клиенты S/MIME (Outlook), использующие CryptoAPI.

 

Microsoft Exchange Server 5.5 вместе с Microsoft Outlook обеспечивают возможности защищенной электронной почты вместе с функциями восстановления ключей и возможностью иметь несколько серверов управления ключами и иерархией доверия сертификатам.

Корпорация Microsoft предоставит возможность миграции для пользователей Exchange к более общим инфраструктурам PKI, предоставляемым Windows 2000, куда входят служба каталогов Active Directory и CA предприятия. В будущих версиях Microsoft сделает сервер управления ключами более универсальной системой для использования другими приложениями.

Дополнительная информация


С самой свежей информацией о Windows 2000 Server и Windows NT можно познакомиться на веб-узле, посвященном Windows NT, по адресу http://www.microsoft.com/ntserver, на веб-узле, посвященном безопасности, по адресу http://www.microsoft.com/security, или на форуме по Windows NT Server в сети Microsoft Network (GO WORD: MSNTS).


 [A.A.R1]В оригинале: The Certificate Services installation process walks the administrator through this process