введение

Смарт-карты являются ключевым компонентом инфраструктуры открытых ключей (public-key infrastructure ‑ PKI), которую Microsoft интегрировала в операционную систему Windows® 2000. Они расширяют возможности программных решений, таких как интерактивный вход в систему, идентификация клиента и удаленный вход в систему. Смарт-карты обеспечивают:

Защищенную от несанкционированного доступа и/или фальсификации данных память для хранения личных ключей и иной персональной информации.

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

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

Что такое смарт-карта?

Термин смарт-карта используется для обозначения класса устройств размером с кредитную карточку, обладающих различными возможностями: карты для хранения данных, бесконтактные карты и карты на основе интегрированных микросхем (integrated circuit cards ‑ ICC). Все они отличаются друг от друга, а также от традиционных карт с магнитной полоской, используемых для обслуживания банковского счета, и ATM-карт. Для применения на персональном компьютере и в среде Windows 2000 наибольший интерес представляют ICC, т.к. они пригодны для выполнения нетривиальных операций, таких как цифровая подпись и передача ключей.

Смарт-карта — это, по существу, миниатюрный компьютер с ограниченной памятью и возможностям обработки данных, заключенный в форму пластиковой кредитной карточки. Электронная схема, расположенная на смарт-карте, эксплуатирует всю мощь процессора той аппаратуры, с которой взаимодействует смарт-карта. Обмен данными между смарт-картой и приложением, работающим на компьютере, осуществляется на основе полудуплексного последовательного интерфейса, управляемого приемным устройством с помощью соответствующего драйвера. Устройства для чтения смарт-карт отличаются разнообразием. Они могут быть подсоединены к компьютеру с помощью интерфейса RS-232, PCMCIA или USB.

Что такое криптография?

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

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

Криптография на основе открытых ключей

Основной особенностью криптографии на основе открытых ключей, напротив, является то, что ключи для шифрования и для расшифровки неодинаковы. Кодирование на основе открытых ключей является односторонней функцией, что означает возможность преобразования открытого текста в закрытый, однако ключ, применявшийся для шифрования, не имеет отношения к процессу расшифровки. Операция расшифровки требует применения открытого ключа (связанного с ключом, применявшимся при шифровании, но не идентичного ему) для обратного преобразования закрытого текста в открытый. Таким образом, каждый пользователь систем кодирования на основе открытых ключей имеет пару ключей, которая состоит из открытого ключа и закрытого (личного) ключа. Благодаря тому, что открытый ключ доступен всем, послать зашифрованные данные может любой. Однако, такое сообщение может быть расшифровано получателем только с помощью личного ключа. Разделение ключей шифрования на открытые и личные открыло новые возможности криптографии, такие как цифровая подпись, соглашение о ключах (key agreement) и распределенную идентификацию (distributed authentication).

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

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

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

концепции системы открытых ключей

Следующие концептуальные положения важны для понимания того, как доступ с помощью смарт-карт реализован в Windows 2000. Дополнительную информацию о технологии открытых ключей, интегрированной в Windows 2000, можно получить в официальном документе Microsoft Windows 2000 Public Key Infrastructure (Инфраструктура открытых ключей Windows 2000).

Что такое инфраструктура открытых ключей?

Инфраструктура открытых ключей (public key infrastructure ‑ PKI) — это набор компонентов, предназначенных для управления подтверждением прав доступа и ключами, используемыми службами шифрования и электронных подписей. Качественная PKI должна обеспечивать операции шифрования, регистрации и возобновления сертификатов, их распространения, подтверждения и аннулирования, а также инструментарий администрирования и обслуживания для управления перечисленными возможностями. Основные компоненты Windows 2000 PKI включают уполномоченную службу выдачи сертификатов (certification authority ‑ CA), Microsoft CryptoAPI для управления сертификатами и ключами, и политики инфраструктуры, используемые для настройки параметров, определяющих доверительные отношения и поведение приложений. Каталог можно рассматривать и как компонент PKI, поскольку он может хранить такую информацию, как местонахождение CA, сертификаты и списки аннулированных сертификатов (certificate revocation list ‑ CRL).

Сертификат

Сертификаты предоставляют механизм, обеспечивающий уверенность в том, что открытый ключ связан с объектом, обладающим соответствующим личным ключом. Самая распространенная на сегодня форма сертификатов базируется на стандарте ITU-T X.509. Windows 2000 поддерживает как сертификаты IETF RFC 2459 X.509 версии 3, так и списки аннулированных сертификатов (certificate revocation list ‑ CRL) X.509 версии 2.

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

Уполномоченный сертификации

Уполномоченный сертификации (certification authority — CA) выдает тем, кто обращается с запросами, сертификаты, руководствуясь набором установленных критериев. CA действует как гарант соответствия между открытым ключом и идентификационной информацией, содержащейся в выданном сертификате. Критерии, используемые СА при обработке запроса, должны быть опубликованы в форме утвержденного порядка выдачи сертификатов, что позволит владельцам сертификатов обоснованно доверять ему.

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

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

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

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

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

Список аннулированных сертификатов

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

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

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

Windows 2000 PKI поддерживает регистрацию сертификатов для службы CA или для CA сторонних разработчиков, например, VeriSign. Поддержка регистрации реализована независимо от способа транспортировки данных и основана на использовании промышленного стандарта PKCS-10 для сообщений о запросе на сертификацию и PKCS-7 — для откликов, содержащих результирующий сертификат или цепочку сертификатов. В сертификатах Windows 2000, которые поддерживают ключи и подписи RSA и алгоритм цифровой подписи DSA (Digital Signature Algorithm), поддерживаются также ключи Диффи-Хеллмана (Diffie-Hellman). Однако регистрация для сертификатов Диффи-Хеллмана в Windows 2000 не поддерживается из-за отсутствия общепринятого стандарта, который послужил бы основой реализации.

Хранилища сертификатов

Криптографические ключи и связанные с ними сертификаты хранятся и управляются подсистемой CryptoAPI. Ключи управляются провайдерами службы криптографии (Cryptographic Service Provider ‑ CSP), а сертификаты — хранилищами сертификатов CryptoAPI.

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

Персональные (Personal) — содержит сертификаты пользователей или компьютеров, для которых соответствующий личный ключ доступен через CryptoAPI.

CA — содержит сертификаты источника или промежуточных CA, используемые при построении цепочек сертификатов.

Корпоративное хранилище действующих сертификатов (Enterprise Trust) — содержит списки действующих сертификатов. Они являются альтернативным механизмом, позволяющим администратору определять совокупность действующих CA. Последние должны сверяться с самостоятельно подтвержденными сертификатами, хранящимися в корневом хранилище действующих сертификатов.

Корневое хранилище действующих сертификатов (Trusted Root) — содержит только самостоятельно подтвержденные сертификаты, которые в PKI являются отправными точками для определения действенности сертификатов.

UserDS — обеспечивает логическое представление хранилища сертификатов, находящихся в активном каталоге. Например, Windows 2000 CA может публиковать сертификаты пользователя и машины в качестве значения свойства userCertificate объекта «пользователь» (user) или «компьютер» (computer) для доступа со стороны других пользователей или служб.

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

Код проверки сертификата в CryptoAPI пытается строить путь сертификатов (т.е. цепочку сертификатов) вверх от сертификата конечного объекта (например, сертификата пользователя или компьютера) до корневого CA следующим образом:

1. Если цепочка сертификатов не представлена как часть протокола, CryptoAPI использует информацию, содержащуюся в поле идентификатора ключа уполномоченного (Authority Key Identifier ‑ AKI), (если оно представлено), для поиска родителя (источника) сертификата (сертификатов) в системе их хранения. Если AKI содержит информацию об источнике и серийном номере, CryptoAPI будет искать соответствующий родительский сертификат. В противном случае будет использовано значение идентификатора ключа для поиска соответствия родительскому сертификату (сертификатам).

2. Если CryptoAPI не находит родительский сертификат ни в цепочке сертификатов, предоставленной протоколом, ни в системном хранилище, базирующемся на AKI, тогда CryptoAPI будет просматривать в сертификате поле доступа к информации об уполномоченном (Authority Info Access ‑ AIA). Если информация в AIA представлена, CryptoAPI использует ее для поиска родительского сертификата (сертификатов) в указанных ресурсах (например, HTTP или LDAP).

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

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

концепции каталога Active directory и Kerberos

Эти концепции важны для понимания того, как доступ с помощью смарт-карты реализован в Windows 2000.

Дополнительная информация о реализации Microsoft протокола Kerberos версии 5 представлена в официальном документе Windows 2000 Kerberos Authentication, который доступен по адресу http://www.microsoft.com/windows/server/Technical/. Дополнительную информацию о Active Directory можно получить в официальном документе Windows 2000 Active Directory, опубликованном по адресу http://www.microsoft.com/windows/server/Technical/.

Kerberos

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

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

PKINIT

Существует расширение протокола Kerberos версии 5, предложенное IETF. Это расширение под названием PKINIT обеспечивает использование сертификата открытого ключа вместо пароля в процессе начальной аутентификации. Расширение PKINIT в Windows 2000 является основой для доступа с помощью смарт-карты и не отменяет требования по использованию долговременного симметричного ключа. Точнее, открытый ключ в сертификате используется для шифрования симметричного ключа, возвращаемого как результат успешной аутентификации, что означает расшифровку с использованием связанного личного ключа, хранящегося на смарт-карте.

Служба аутентификации KDC

В Windows 2000 реализована доменная служба сетевой аутентификации, известная под названием KDC (Key Distribution Center), которая в качестве базы данных учетных записей использует доменный каталог Active Directory. KDC является единым процессом, в рамках которого функционируют две службы: службы аутентификации (Authentication Service ‑ AS) и службы выдачи билетов (Ticket-Granting Service ‑ TGS). AS выдает специальные билеты начального доступа TGT (Ticket Granting Ticket) принципалам безопасности, аутентичность которых установлена (т.е. пользователям, машинам, службам) для доступа к TGS. Последняя выдает билеты для доступа к другим службам в домене или к TGS в другом домене, связанном с данным доверительными отношениями. На каждом контроллере домена функционирует KDC, которая работает в пространстве процессов локальной системы безопасности LSA (Local Security Authority). Любой контроллер домена может принимать адресованные домену запросы на аутентификацию и выдачу билетов.

Active Directory

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

Объект есть определенный, поименованный набор атрибутов, который представляет нечто конкретное, например, пользователя, принтер или приложение. Атрибуты содержат данные, описывающие предмет, который идентифицируется объектом каталога. Атрибуты пользователя могут включать обычное имя пользователя, сертификат или адрес электронной почты. Все объекты активного каталога защищены списком контроля доступа (Access Control List ‑ ACL). ACL определяют видимость объекта и какие действия с объектом может осуществлять каждый пользователь. Объект не может быть обнаружен пользователем, который не имеет права просматривать его.

Домены, леса и доверительные отношения

Домен является единой областью безопасности в Windows 2000. Active Directory включает один или более доменов. На автономном компьютере доменом является собственно компьютер. Домен может охватывать более чем одно физическое местоположение. Каждый домен обладает собственной политикой безопасности и отношениями с другими доменами по поводу обеспечения безопасности (доверительные отношения). Когда многие домены соединены доверительными отношениями и совместно используют общие схему, конфигурацию и глобальный каталог, они образуют дерево доменов. Множество деревьев доменов могут быть объединены в лес.

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

Kerberos использует Active Directory как базу данных учетных записей, из которой он получает информацию о принципалах безопасности. Когда домен присоединяется к дереву доменов Windows 2000, между ним и его родительским доменом в дереве автоматически устанавливаются доверительные отношения Kerberos. Доверительные отношения Kerberos транзитивны, так что для членов дерева не требуется никаких дополнительных отношений доверия. Иерархия доверия сохранена в перекрестных ссылках между объектами каталога.

Каждый контроллер домена хранит доступную для записи копию каталога так, чтобы можно было создать учетные записи, отменить пароли и модифицировать членство в группе на любом контроллере домена. Изменения, произведенные в одной копии каталога, автоматически дублируются в остальных копиях. Однако Windows 2000 не реализует протокол тиражирования (replication protocol) Kerberos. Взамен этого используется протокол репликации хранилищ Active Directory с использованием нескольких мастер-копий (multi-master protocol) по безопасному каналу, установленному между ними.

как осуществляется аутентификация с помощью смарт-карты

Смарт-карта может использоваться для аутентификации в домене Windows 2000 тремя способами. Первый — интерактивный вход в систему с применением Active Directory, протокола Kerberos версии 5 и сертификата открытого ключа. Второй — идентификация клиента, что означает аутентификацию пользователя с применением сертификата открытого ключа, который соответствует учетной записи, хранящейся в Active Directory. Третий — удаленный вход в систему, когда для подтверждения соответствия между удаленным пользователем и учетной записью, хранящейся в Active Directory, используется сертификат открытого ключа совместно с протоколом EAP (Extensible Authentication Protocol) и защищенной передачей данных (Transport Layer Security ‑ TLS).

Интерактивный вход в систему

Интерактивный вход в систему с использованием смарт-карты начинается тогда, когда пользователь вставляет смарт-карту в устройство чтения смарт-карт, которое сигнализирует операционной системе Windows 2000 о необходимости запросить персональный идентификационный номер (Personal Identification Number ‑ PIN) вместо имени пользователя, имени домена и пароля. Это событие эквивалентно нажатию знакомого сочетания клавиш Ctrl-Alt-Del, инициирующему процедуру входа в систему с использованием пароля. Однако PIN, который указывается пользователем в диалоговом окне при входе в систему, обеспечивает аутентификацию только по отношению к смарт-карте, но не к собственно домену. Сертификат открытого ключа, хранящийся на смарт-карте, используется для аутентификации в домене с применением протокола Kerberos версии 5 и его расширения PKINIT.

Запрос на вход в систему

После того, как пользователь вводит PIN в диалоговом окне регистрации в системе, операционная система начинает выполнение последовательности действий, чтобы определить, может ли пользователь быть идентифицирован и аутентифицирован на основе предъявленной им удостоверяющей информации (PIN и смарт-карта). При запросе на вход в систему сначала происходит обращение к локальной системе безопасности LSA, которая передает обработку пакету аутентификации Kerberos, запущенному на клиентском компьютере. Пакет Kerberos посылает запрос службы аутентификации (authentication service ‑ AS) службе KDC, функционирующей на контроллере домена, на аутентификацию и получение начального билета TGT. В состав запроса AS, в те его поля, которые предшествуют идентификационным (предопознавательные поля данных), клиентская часть пакета Kerberos включает пользовательский сертификат X.509 версии 3, обнаруженный на смарт-карте. Удостоверение, включенное в предопознавательные поля данных, удостоверяется цифровой подписью с использованием личного ключа пользователя так, чтобы KDC могла проверить запрос AS, порожденный владельцем сертификата.

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

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

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

Проверка цифровой подписи

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

Поиск учетной записи и TGT

После подтверждения того, что пользователь является тем, за кого себя выдает, и сертификат может быть использован для аутентификации в домене, служба KDC запрашивает в каталоге домена учетную запись. KDC ищет учетную запись пользователя в Active Directory по имени принципала пользователя (User Principal Name ‑ UPN), которое указано в поле альтернативного имени (Subject Alternative Name) в пользовательском сертификате открытого ключа. Учетная запись, которую KDC получает из каталога, используется для формирования TGT. TGT будет включать идентификатор безопасности пользователя (Security ID ‑ SID), SID для всех доменов, к которым относится пользователь, а также, возможно, SID для всех глобальных групп, членом которых пользователь является (в среде со многими доменами). Список SID внесен в список полей данных авторизации TGT.

KDC шифрует TGT, используя случайный ключ, специально сгенерированный для этого. Случайный ключ зашифровывается с помощью открытого ключа из сертификата пользователя и включается в предопознавательное поле данных ответа KDC. KDC подписывает ответ, используя свой личный ключ так, чтобы клиент мог удостовериться в том, что ответ получен от KDC, которому можно доверять. Клиент сначала проверяет подпись KDC, формируя путь сертификации от сертификата KDC к доверенному корневому CA, и затем использует открытый ключ KDC, чтобы проверить подпись ответа. KDC также подписывает данные авторизации TGT, используя ключ сервера, подписанный с применением секретного ключа KDC. Таким образом, ложная служба не может изменить данные авторизации после того, как TGT был выпущен. После получения ответа KDC клиент извлечет зашифрованный случайный ключ, расшифрует его и применит полученный ключ для расшифровки TGT. Полученный TGT используется стандартным протоколом Kerberos версии 5, чтобы запросить сеансовые билеты для доступа к ресурсам домена от TGS.

Следует отметить, что дополнительные удостоверения прав доступа создаются в процессе регистрации в системе по протоколу Kerberos так, чтобы сохранить возможность доступа к серверам, работающим под управлением операционной системы Windows NT® 4.0 и более ранних версий. Это справедливо, даже если пользователь никогда не использовал пароль на компьютере. При создании учетной записи создается однонаправленная функция, которая добавляется как атрибут учетной записи для использования в качестве дополнительного удостоверения, обеспечивающего обратную совместимость аутентификации.

Автономная регистрация в системе (Offline Logon)

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

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

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

Поскольку поддержка смарт-карт интегрирована в CryptoAPI, протоколам SSL (Secure Sockets Layer) и TLS (Transport Layer Security) не нужно "знать" что-либо о смарт-карте для того, чтобы работать с ней. Роль смарт-карты в процессе аутентификации клиента состоит в том, чтобы подписать часть данных протокола на начальной стадии сеанса обмена данными по протоколу SSL. Поскольку личный ключ, соответствующий сертификату открытого ключа, хранится на смарт-карте, подобный метод аутентификации является более строгим, т.к. применение личного ключа требует от владельца карты подтверждения прав доступа и к карте, и к домену. Кроме того, операции с личным ключом, выполняемые на начальной стадии сеанса обмена данными, реализуются картой таким образом, что личный ключ никогда не передается главному компьютеру или в локальную сеть.

Взаимная аутентификация

Оба протокола SSL 3.0 и TLS 1.0 поддерживают взаимную аутентификацию, что для клиента означает возможность проверить подлинность сервера, а для сервера — подлинность клиента. Аутентификация сервера происходит, когда клиент подтверждает подлинность сервера, проверяя криптографическую подпись на сертификате сервера, а также всех промежуточных сертификатов CA на соответствие корневому сертификату CA, находящемуся в корневом хранилище действующих сертификатов клиента. Аутентификация клиента сервером реализована так же, как и аутентификация сервера, но проверка сертификатов осуществляется в противоположном направлении. Сервер проверяет криптографическую подпись на сертификате клиента, а также все промежуточные сертификаты CA на соответствие корневому сертификату CA, находящемуся в корневом хранилище действующих сертификатов сервера. Как только аутентификация клиента произведена, сервер должен установить контекст безопасности с соответствующей авторизацией, которая определяет, какие ресурсы сервера разрешено использовать клиенту.

Авторизация

Аутентификация клиента в Windows 2000 с применением открытых ключей использует информацию сертификата клиента для получения информации о его правах доступа в домене. Windows 2000 реализует службу безопасности, которая использует информацию сертификата для поиска учетных записей в каталоге Active Directory и определения прав доступа аутентифицированного клиента. Поиск в каталоге может осуществляться на основе UPN , содержащегося в сертификате, или по свойствам, источнику (или источнику и субъекту) в сертификате клиента.

Когда установлен сеанс SSL или TLS, провайдер безопасного канала (secure channel provider), прежде всего, пытается исходя из UPN сертификата, найти учетную запись пользователя в каталоге домена. UPN включен в сертификат в поле альтернативного имени субъекта (Alternative Subject Name) и определяет точное имя учетной записи пользователя (префикс) и имя домена, в котором расположена учетная запись (суффикс). Также как при входе в систему с помощью смарт-карты на основе Kerberos, CA-источник должен иметь полномочия на выпуск сертификатов для домена, чтобы им можно было доверять при идентификации и проверке полномочий.

Если нет соответствия UPN или источник CA не уполномочен издавать сертификаты для аутентификации в домене, провайдер пытается запросить в каталоге поиск учетной записи, у которой атрибут Alternate Security Identities содержит явное указание на соответствие сертификату клиента. Явное указание сертификата в учетной записи пользователя требует дополнительных действий администратора. Соответствие сертификату клиента может быть основано либо на имени источника, либо на источнике и субъекте в сертификате. Учетная запись может иметь один или более связанных с ней сертификатов, что упрощает применение одной учетной записи для нескольких внешних пользователей. Сертификат не может соответствовать нескольким учетным записям, хранящимся в каталоге домена. Аутентификация потерпит неудачу, если сертификат соответствует более чем одной учетной записи.

Удаленный доступ

Поддержка расширяемой аутентификации для удаленных пользователей в Windows 2000 обеспечивается службой удаленного доступа RAS (remote access service). Сервер удаленного доступа поддерживает EAP и обеспечивает модулям различных производителей возможность поддержки разнообразных методов аутентификации — от использования смарт-карт до биометрических. Windows 2000 включает встроенный модуль для смарт-карт, что позволяет обеспечить строгую аутентификацию удаленных пользователей.

Удаленный вход в систему фактически означает две различные аутентификации: одну для сервера RAS и другую для сети. Первая аутентификация завершается подтверждением аутентификации сервера RAS клиентом и установлением соединения между клиентом и сервером. В результате клиенту сопоставляются некоторые политики RAS и атрибуты учетной записи. Атрибуты учетной записи применяются индивидуально и включают такие свойства, как права доступа, режимы обратного вызова (callback options), статические маршруты (static routes) и т.д. Политики RAS определяют основные принципы взаимодействия сервера с клиентом. Это позволяет управлять пользователями, обеспечивая соответствие свойств подключения, группового членства, профиля и т.д.

Вторая аутентификация относится к домену и использует EAP поверх TLS в качестве протокола аутентификации вместо Kerberos или стандарта SSL. Аутентификация в домене с использованием EAP/TLS очень похожа на описанную выше аутентификацию клиента с использованием SSL, за исключением того, что сертификат открытого ключа должен содержать UPN, соответствующий учетной записи, хранящейся в доменном каталоге Active Directory.

Различия между локальной регистрацией и регистрацией в домене

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

Внедрение смарт-карт

Для организаций польза от внедрения смарт-карт заключается в повышении безопасности сети за счет улучшения методов аутентификации. Windows 2000 позволяет организовать строгую аутентификацию с использованием смарт-карт, благодаря таким средствам операционной системы, как Kerberos и Active Directory, а также разнообразным инструментам администрирования для управления инфраструктурой открытых ключей. В Windows 2000 Professional, Windows 2000 Server и Windows 2000 Advanced Server интегрированы технологии смарт-карт и открытых ключей. Компании могут немедленно воспользоваться их преимуществами для извлечения прибыли без необходимости привлечения внешнего управления сертификатами и закупки дорогостоящих и нестандартных программных компонентов.

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

Каким категориям пользователей необходимы смарт-карты?

Какие политики и процедуры должны быть установлены для управления картами и сертификатами?

Каков должен быть порядок выдачи смарт-карт пользователям?

Какое оборудование для работы со смарт-картами доступно и совместимо с Windows 2000?

Кто должен использовать смарт-карты?

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

Windows 2000 поддерживает разбиение пользователей по группам на основе их роли в домене и определяет три различные категории: администратор, пользователь с расширенными полномочиями (Power User) и пользователь.

Администраторы обладает всей полнотой власти. Устанавливаемые по умолчанию параметры настройки Windows 2000 не ограничивают доступ администраторов к любым объектам реестра или системным файлам. Администраторы могут исполнять все функции, поддерживаемые операционной системой. Те права, которых администратор не имеет по умолчанию, он может предоставить сам себе.

Пользователи с расширенными полномочиями не наделены столь широкими правами как администраторы, но могут устанавливать приложения, выполнять настройку системы и т.д. Устанавливаемые для таких пользователей по умолчанию параметры настройки защиты Windows 2000 соответствуют (и обратно совместимы) с настройками защиты по умолчанию для обычных пользователей операционной системы Windows NT 4.0.

Пользователи являются противоположностью администраторов. Устанавливаемые по умолчанию настройки безопасности разработаны так, чтобы не дать им возможности подвергнуть риску целостность операционной системы и установленных приложений (если Windows 2000 вновь установлена в разделе NTFS). Пользователи не могут модифицировать настройки реестра, файлы операционной системы или программные файлы. Пользователи не могут устанавливать приложения, которые могут быть запущены другими пользователями (для предотвращения опасности проникновения «троянских коней»). Пользователи не имеют доступа к личным данным других пользователей.

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

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

Пользователь запрашивает присоединение своего компьютера к домену.

Пользователь должен выполнить операцию по администрированию, такую как повышение статуса сервера до контроллера домена.

Пользователю нужно настроить соединение для удаленного доступа к сети.

Какие политики необходимы?

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

Обязательное использование смарт-карт

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

Политика обязательного использования смарт-карты для интерактивной регистрации в системе не рекомендована в следующих ситуациях:

Пользователь запрашивает присоединение своего компьютера к домену.

Пользователю нужно настроить соединение для удаленного доступа к сети.

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

Удаление смарт-карты

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

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

Если карта осталась дома

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

Личные идентификационные номера

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

Многое было сделано для управления и периодической смены PIN-кодов смарт-карт, подобно тому, как это реализовано в политиках использования паролей. Частые изменения PIN-кода действительно не являются необходимыми благодаря способности смарт-карт противостоять вышеописанным типам вторжения. Однако остается некоторое неудобство, связанное с тем, как и когда пользователь может сменить PIN-код, если такая потребность все же возникла — эта возможность предоставляется ему только при выполнении операции с личным ключом. Недостаток стандартов для управления PIN-кодами средствами операционной системы вынуждает реализовывать управление PIN-кодом на уровне CSP, а не на уровне операционной системы. Следовательно, отсутствуют функциональные возможности изменения PIN-кода посредством стандартного интерфейса подобного тому, который применяется для регистрации в системе с применением паролей.

Каков должен быть порядок выдачи смарт-карт?

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

По этому сценарию служба безопасности действует как уполномоченный регистрации и устанавливает сертификат на удостоверении сотрудника. При этом удостоверение представляет собой одновременно и смарт-карту. Служба-уполномоченная сертификации в Windows 2000 Server и Windows 2000 Advanced Server поддерживает такую возможность как часть Web-интерфейса регистрации. Независимо от того, как именно корпорация внедряет смарт-карты, решение об их интеграции с удостоверениями сотрудников или отсутствие таковой базируется на потребностях организации в усилении безопасности и повышению удобства доступа применительно к той или иной категории сотрудников.

Станция регистрации смарт-карт

Станция регистрации смарт-карт включена как часть корпоративной службы CA, доступной в Windows 2000 Server и Windows 2000 Advanced Server. Она поддерживает централизованную выдачу карт. Подобно корпоративному CA, станция регистрации смарт-карт использует шаблоны сертификата для определения того, какую информацию включать в предназначенный для того или иного применения сертификат. Настройка, установленная по умолчанию для корпоративного CA, не разрешает выдачу шаблонов сертификата смарт-карт; вместо этого администратор CA должен разрешить выдачу шаблонов корпоративным CA.

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

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

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

Какое оборудование доступно?

Смарт-карты

Компании, внедряющие смарт-карты, не должны считать, что карта может хранить множество сертификатов, поскольку не обеспечивается поддержка различения нескольких сертификатов на карте. Криптографические смарт-карты имеют ограниченный объем памяти; обычно от 2 до 8 КБ, с возможностью увеличения в будущем до 16 КБ. Поскольку память пользуется большим спросом и довольно дорога, производители карт ограничивают объем памяти, доступный одному приложению, чтобы обеспечить поддержку на карте нескольких приложений и служб.

В Windows 2000 смарт-карты и связанный с ними провайдер криптографической службы (CSP) предполагают поддержку лишь одного сертификата для карты. Windows 2000 будет работать с любой криптографической смарт-картой, для которой существует провайдер CryptoAPI. Провайдеры криптографической службы CryptoAPI для смарт-карт Gemplus и Schlumberger включены в Windows 2000, в то время как такие компании, как Bull и Siemens Nixdorf предлагают CSP для поддержки своих смарт-карты отдельно.

Устройства чтения смарт-карт

Типы устройств чтения смарт-карт различаются в зависимости от области их применения. Большинство устройств чтения смарт-карт подключаются к ПК через последовательный порт RS-232, разъем PCMCIA Type II или шину USB. Windows 2000 обеспечивает встроенную поддержку для нескольких устройств чтения смарт-карт ведущих производителей, включая Bull, Gemplus, Litronic, Rainbow Technologies, Schlumberger и SCM Microsystems.

Чтобы помочь потребителям определить, какое устройство чтения смарт-карт совместимо с платформой Windows, Microsoft разработала программу выдачи устройствам чтения смарт-карт специальных логотипов, которая реализуется под руководством лаборатории качества Windows Hardware Quality Lab. Такой логотип гарантирует совместимость и способность к взаимодействию карты и устройств чтения. Программа выдачи логотипов для устройств чтения смарт-карт аналогична тому, что Microsoft сделала для многих других типов устройств, таких как звуковые платы, сетевые и графические адаптеры. Наибольший выигрыш для потребителя состоит в том, что, купив устройство чтения, на котором присутствует логотип совместимости с Windows, он может быть уверен в том, что оно отвечает всем требованиям совместимости и взаимодействия, включая качество драйвера, полноценное управление энергопотреблением и поддержку стандарта Plug-and-Play. Список Windows-совместимых устройств, в том числе, устройств чтения смарт-карт, доступен по адресу http://www.microsoft.com/hwtest/hcl.

Способность к взаимодействию и стандарты

Способность к взаимодействию всегда подразумевает двунаправленность. Инфраструктура Microsoft Windows 2000 PKI разработана так, чтобы обеспечить совместимость с основными стандартами открытых ключей. Microsoft продолжает поддерживать способность к взаимодействию путем тестирования своей продукции совместно с продуктами сторонних производителей, таких как Netscape, VeriSign и других.

PKIX

Со спецификацией инфраструктуры открытых ключей и списков аннулированных сертификатов — IETF Internet X.509, RFC 2459, можно ознакомиться по адресу http://www.ietf.org/rfc/rfc2459.txt.

PKCS

Спецификации Public Key Cryptography Standards (PKCS) опубликованы по адресу http://www.rsa.com/rsalabs/pubs/PKCS .

TLS

Предварителные проекты рабочей группы IETF, посвященные защите транспортного уровня (Transport Layer Security — TLS), находятся по адресу http://www.ietf.org/html.charters/tls-charter.html.

Kerberos

Спецификации IETF Kerberos Network Authentication Service (V5), RFC 1510 находятся по адресу http://www.ietf.org/rfc/rfc1510.txt.

Предварительные спецификации IETF, которые посвящены использованию шифрования с открытыми ключами для первоначальной аутентификации в Kerberos, уточняющие RFC 1510, находятся по адресу http://search.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-07.txt.

PC/SC

Спецификации Personal Computer/Smart Card находятся по адресу http://www.smartcardsys.com/.

дополнительные ссылки

Ресурсы

Самую последнюю информацию Microsoft, посвященную вопросам безопасности, можно найти по адресу http://www.microsoft.com/security/.

Информация для разработчиков программного обеспечения может быть получена через сеть Microsoft Developer Network (MSDN) по адресу http://msdn.microsoft.com/.

Документы

Правительство США

Национальный институт стандартов и технологий (NIST) вместе с Министерством обороны (Department of Defense ‑ DOD) и Национальным агентством безопасности (NSA), опубликовали информацию об усилиях правительства США по созданию федеральной инфраструктуры PKI. Опубликованные документы находятся по адресу http://csrc.nist.gov/pki/.

Правительство Канады

Правительство Канады прилагает аналогичные усилия относительно PKI под эгидой Treasury Board of Canada Secretariat. Опубликованная информация об этом может быть получена по адресу http://www.cio-dpi.gc.ca/pki/splash_e.html.

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

За информацией о Windows 2000 или Windows NT Server, опубликованной позднее настоящего документа, обращайтесь на Web-страницу по адресу http://www.microsoft.com/ntserver или в Форум Windows NT Server Forum в сети MSN™ (GO WORD: MSNTS).