возможности  клиентов домена

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

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

Генерация ключей

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

Механизм хранения ключей зависит от выбранного CSP. Поставляемые корпорацией МайкрософтMicrosoft CSP (или базовые CSP) хранят ключи в зашифрованном виде, сгруппированные по отдельным пользователям или по компьютерам. Они также поддерживают управление возможностями экспорта пары ключей (флаг CRYPT_EXPORTABLE) и их использования (флаг CRYPT_USER_PROTECT). Первый флаг управляет экспортом личного секретного ключа из CSP, а второй флаг определяет, как будет производиться уведомление пользователя в случае, если приложение попытается использовать его личный ключ. В криптографическом интерфейсе КриптоПро CSP (смотрите подробнее в разделе «Использование российских криптоалгоритмов в Windows»), личные секретные ключи могут формироваться на различные типы носителей и храниться на них в защищенном виде. К числу таких носителей относятся: реестр Windows, дискета 3,5", процессорные карты MPCOS-EMV и российские интеллектуальные карты (РИК) таблетки Touch-Memory DS1993 - DS1996. В других CSP могут применяться иные механизмы. Например,  CSP, поддерживающие смарт-карты, хранят пару ключей в защищенном хранилище смарт-карты.

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

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

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

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

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

Как уже говорилось выше, практическое использование криптографии с открытыми ключами основано на сертификатах, которые устанавливают связь между известными объектами и их открытыми ключами. Инфраструктура открытых ключей Windows 2000 поддерживает подачу запросов на сертификаты в центр сертификации предприятия (созданный на основе поставляемых корпорацией Microsoft служб сертификации) или в независимые ЦС. Поддержка подачи запросов осуществлена таким образом, что не зависит от способа передачи данных. Она основана на отраслевых стандартах PKCS-10 для сообщения с запросом на сертификат и PKCS-7 для сообщения с ответом, который содержит выданный сертификат или цепочку сертификатов. В настоящее время поддерживаются сертификаты, которые используют ключи и подписи с алгоритмами RSA и DSA, ключи с алгоритмом DH (Diffie-Hellman) и ключи  с российским алгоритмом ГОСТ Р 34.10-94, при использовании КриптоПро CSP.

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

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

Обновление сертификатов

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

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

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

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

Сертификаты хранятся в специальных хранилищах (store). В инфраструктуре PKIоткрытых ключей Windows 2000 определены пять стандартных хранилищ сертификатов.

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

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

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

·         ROOT. В этом хранилище содержатся только сертификаты доверенных корневых ЦС, сертификаты которых заверены собственной подписью этих ЦС.

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

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

Экспорт и импорт сертификатов

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

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

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

Перемещаемость

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

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

Отзыв сертификатов

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

·         Потеря ключевых носителей.

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

·         Увольнение сотрудников, имевших доступ к ключевой информации.

·         Нарушение правил хранения и уничтожения (после окончания срока действия) секретного ключа.

·         Возникновение подозрений на утечку информации или ее искажение в системе конфиденциальной связи.

·         Нарушение правил хранения ключевых носителей.

·         Получение сертификата незаконным путем.

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

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

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

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

Доверие

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

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

Политика использования открытых ключей в среде Windows 2000

Политики безопасности применимы к сайтам, доменам и организационным подразделениям (OU – Organizational Unit), они определяют безопасность связанных с ними пользователей и компьютеров. Политика безопасного использования открытых ключей является лишь одним аспектом общей политики безопасности в среде Windows 2000, поэтому она интегрирована в эту структуру. Тем самым обеспечивается механизм централизованного определения политики и управления ею в глобальном масштабе. Далее обсуждаются важнейшие аспекты политики безопасного использования открытых ключей.

Доверенные корневые ЦС

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

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

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

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

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

·         Электронная почта.

·         Система IPSec.

·         Туннель IPSec.

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

·         Проставление штампов времени.

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

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

Для обеспечения автоматического получения сертификатов в инфраструктуре открытых ключей Windows 2000 определены соответствующие механизмы. Этот процесс определяется двумя главными элементами: типом сертификата и объектом автоматического получения. Данные элементы интегрированы с объектом GPO (Group Policy Object – объект групповой политики) и могут быть определены отдельно для каждого сайта, домена, подразделения, компьютера и пользователя.

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

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

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

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

Обзор применений

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

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

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

·         Проверка подлинности клиента. Возможность для серверов идентифицировать клиента и на этом основании принять решение о предоставлении доступа.

·         Конфиденциальность. Шифрование данных, передаваемых между клиентом и сервером, по общедоступным сетям.

Для решения этих задач используется протоколы SSL (Secure Sockets Layer) TLS (Transport Layer Security). Эти протоколы основаны на технологии проверки подлинности с помощью электронной цифровой подписи и сертификатов, и шифрования с открытыми ключами.

Протоколы SSL и TLS поддерживаются через интерфейс SSP защищенного канала (Schannel SSP) Windows 2000. Поскольку модуль Schannel встроен в операционную систему, его можно использовать с несколькими протоколами для поддержки проверки подлинности и обмена зашифрованными данными.

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

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

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

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

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

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

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

Недостаточное взаимодействие между поставщиками ограничило некоторые ранние реализации безопасного обмена данными. При отсутствии подходящих стандартов поставщики внедряли системы, основанные на их собственных протоколах, кодировках сообщений и допущениях доверия, которые фактически определяли невзаимодействующие инфраструктуры открытых ключей. (Хотя система защиты электронной почты PGP используется довольно широко, она относятся к упомянутой категории, поскольку ее форматы обмена сообщениями так и не стали основой для взаимодействующих и безопасных почтовых приложений в отраслевом масштабе.) Основа для взаимодействующих безопасных почтовых систем появилась благодаря усилиям ведущих производителей. Этой основой является предложенный организацией IETF стандарт S/MIME версии 3, разработанный на базе стандарта S/MIME версии 2 (RSA Data Security). Стандарт S/MIME поддерживается рядом продуктов, в том числе Microsoft Outlook  и Microsoft Outlook Express.

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

Компоненты с электронной цифровой подписью

Быстрое развитие Интернета приводит к росту зависимости от загружаемых из него активных материалов, например, приложений Windows, элементов управления ActiveX^® и приложений Java. В результате повышается внимание к безопасности применения таких загружаемых программ, поскольку они часто проявляют побочные эффекты в веб-сценариях, не уведомляя об этом пользователя. Для решения этой проблемы корпорация Microsoft представила технологию электронных цифровых подписей программных компонент - Authenticode^TM.

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

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

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

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

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

Вход с помощью смарт-карт

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

Система распознает ввод смарт-карты как альтернативу нажатия комбинации клавиш CTRL + ALT + DEL, активизирующего средства безопасности при входе в систему. Далее пользователю предлагается ввести PIN-код смарт-карты, с помощью которого контролируется доступ к операциям с личным ключом, хранящимся на смарт-карте. На смарт-карте хранится также сертификат пользователя, выданный ЦС предприятия. Это дает пользователю возможность перемещаться в пределах домена.

Протокол IP Security (IPSec)

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

Использование российских криптоалгоритмов в Windows

Пользователям Windows теперь стала доступна возможность использовать сертифицированные средства криптографической защиты информации в составе операционной системы Windows.

Средство криптографической защиты информации КриптоПро CSP, разработанное совместно компанией "Крипто-Про" (www.CryptoPro.ru) и Государственным унитарным предприятием научно-техническим центром "Атлас" реализовано в соответствии с криптографическим интерфейсом корпорации Microsoft — CSP (Cryptographic Service Provider) и российскими криптографическими алгоритмами:

·         электронной цифровой подписи ("ГОСТ Р 34.10-94. Информационная технология. Криптографическая защита информации. Система электронной цифровой подписи на базе асимметричного криптографического алгоритма.");

·         хэширования ("ГОСТ Р 34.11-94. Информационная технология. Криптографическая защита информации. Функция хэширования.");

·         шифрования и имитозащиты данных ("ГОСТ 28147-89. Системы обработки информации. Защита криптографическая").

Использование СКЗИ КриптоПро CSP позволяет решить сразу несколько задач:

·         корпоративные пользователи получают возможность использовать стандартные и повсеместно используемые приложения корпорации Microsoft с надежной российской криптографией (256 бит).

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

К стандартным приложениям, которые теперь могут использовать российские алгоритмы электронной цифровой подписи и шифрования, относятся:

·         Центр Сертификации сертификатов открытых ключей X.509 — Microsoft Certification Authority.

·         Электронная почта — Microsoft Outlook, входящая в состав Microsoft Office 2000.

·         Электронная почта — Microsoft Outlook Express, входящая в состав Internet Explorer версии 5.0 и выше.

·         Средства формирования и проверки электронной цифровой подписи  программных компонент, распространяемого по сети — Microsoft Authenticode.

·         Защита соединений в Интернете с использованием протокола TLS/SSL.

Средство криптографической защиты КриптоПро CSP имеет сертификат ФАПСИ СФ/114-0411 от 11 марта 2001 года.