Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Windows CryptoAPI

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

Содержание

Основные понятия и термины

Криптография – наука о защите данных. Алгоритмы криптографии с помощью математических методов комбинируют входной открытый текст и ключ шифрования, в результате чего получаются зашифрованные данные. Применение криптографии обеспечивает относительно надёжную передачу данных и предотвращение их получения несанкционированной стороной. Применяя хороший алгоритм шифрования, можно максимально усложнить взлом защиты и получения открытого текста подбором ключа.
Шифрование – защита информации от несанкционированного просмотра или использования, особенно при передаче по линиям связи.
Дешифрование – процесс, обратный процессу шифрованию.
Аутентификация (authentication) – проверка подлинности, этот процесс надежного определения подлинности поддерживающих связь компьютеров. Аутентификация основана на методах криптографии, и это гарантирует, что нападающий или прослушивающий сеть не сможет получить информацию, необходимую для рассекречивания пользователя или другого объекта. Аутентификация позволяет поддерживающему связь объекту доказать свое тождество другому объекту без пересылки незащищенных данных по сети. Без «сильной» (strong) аутентификации и поддержания целостности, данных любые данные и компьютер, который их послал, являются подозрительными.
Шифр – обеспечивает возможность передачи сообщения по незащищенным каналам (не обязательно сетевым) с защитой этого сообщения от прочтения посторонними лицами.
Цифровая подпись – это двоичные данные небольшого объема, обычно не более 256 байт. Цифровая подпись есть не что иное, как результат работы хеш-алгоритма над исходными данными, зашифрованный закрытым ключом отправителя. Проще говоря, берем исходные данные, получаем из них хеш и шифруем хеш своим закрытым ключом (с помощью асимметричного алгоритма).
Сертификат – средство, позволяющее гарантированно установить связь между переданным открытым ключом и передавшей его стороной, владеющей соответствующим личным ключом. Сертификат представляет собой набор данных, зашифрованных с помощью цифровой, или электронной, подписи. Информация сертификата подтверждает истинность открытого ключа и владельца соответствующего личного ключа.

Общие положения

Интерфейс

В сфере защиты компьютерной информации криптография применяется в основном для: шифрования и дешифрования данных; а также создания и проверки цифровых подписей. Шифрование данных позволяет ограничить доступ к конфиденциальной информации, сделать ее нечитаемой и непонятной для посторонних. Применение цифровых подписей оставляет данные открытыми, но дает возможность верифицировать отправителя и проверять целостность полученных данных. Для защиты информации специалистами Microsoft был разработан интерфейс CryptoAPI, который является основой средств защиты Microsoft Internet Security Framework. Он позволяет создавать приложения, использующие криптографические методы и обеспечивает базовые функции защиты для безопасных каналов и подписи кода. Реализация CryptoAPI в Internet Explorer позволяет нам легко интегрировать со своими приложениями усиленные средства шифрования. Интерфейс CryptoAPI обеспечивает API высокого уровня для аутентификации, подписи, шифрования/дешифрации, а также полную инфраструктуру защиты с общим ключом. Благодаря данной инфраструктуре, можно воспользоваться функциями управления сертификатами, такими как запрос на создание сертификата, его сохранение или верификация.
Программный интерфейс CryptoAPI фирмы Microsoft предоставляет возможности для добавления в приложение, основанное на базе Win32, функций аутентификации, шифрования, дешифрования и электронной подписи. Задачами CryptoAPI являются:

• Аутентификация сетевых пользователей
• Шифрование и дешифрование сетевых сообщений
• Шифрование и дешифрование данных
• Создание цифровой подписи и ее подтверждение.

CryptoAPI состоит из пяти функциональных различных областей, как показано на иллюстрации, взаимодействующих с приложением. Напрямую к провайдеру (CSP) приложение обратиться не может (см. Рис.1).

Открытость интерфейса: открытая архитектура CryptoAPI позволяет выбирать Cryptographic Service Provider (CSP) по своему усмотрению. CryptoAPI доступен в операционных системах Windows, Macintosh и UNIX. Кроме того, в CryptoAPI поддерживаются стандартные форматы сертификатов X.509 версии 3, ASN.1 и DER.

Симметричные и асимметричные шифры

Блочные шифры

Блочные шифры считаются более надежными, нежели поточные, поскольку каждый блок текста подвергается сложным преобразованиям. Тем не менее, одних только этих преобразований оказывается недостаточно для обеспечения должного уровня безопасности — важно, каким образом они применяются к исходному тексту в процессе шифрования. Наиболее простой и интуитивно понятный способ состоит в том, чтобы разбить исходный текст на блоки соответствующего размера, а затем отдельно каждый блок подвергнуть шифрующему преобразованию. Такой режим использования блочных шифров называют электронной кодовой книгой (ECB — electronic codebook). Его главный недостаток состоит в том, что одинаковые блоки исходного текста при шифровании дадут одинаковые же блоки шифр-текста — а это может существенно облегчить противнику задачу взлома. Поэтому режим ECB не рекомендуется использовать при шифровании текстов, по длине превышающих один блок — в таких случаях лучше воспользоваться одним из режимов, связывающих различные блоки между собой. По умолчанию в CryptoAPI блочные шифры используются в режиме сцепления блоков шифр-текста (CBC — cipher block chaining). В этом режиме при шифровании очередной блок исходного текста вначале комбинируется с предыдущим блоком шифр-текста (при помощи побитового исключающего ИЛИ), а затем полученная последовательность битов поступает на вход блочного шифра (рис. 2). Образующийся на выходе блок шифр-текста используется для шифрования следующего блока. Самый первый блок исходного текста также должен быть скомбинирован с некоторой последовательностью битов, но «предыдущего блока шифр-текста» еще нет; поэтому режимы шифрования с обратной связью требуют использования еще одного параметра — он называется инициализирующим вектором (IV — initialization vector).

Инициализирующий вектор должен генерироваться отдельно с помощью уже известной нам функции CryptGenRandom и, как и солт-значение, передаваться вместе с ключом в открытом виде. Размер IV равен длине блока шифра. Например, для алгоритма RC2, поддерживаемого базовым криптопровайдером Microsoft, размер блока составляет 64 бита (8 байтов).

Алгоритм RSA

Работа с CryptoAPI

Криптопровайдеры, инициализация и деинициализация

Любой сеанс работы с CryptoAPI начинается с инициализации (получения контекста). Инициализация выполняется при помощи функции CryptAcquireContext. В качестве параметров эта функция принимает имя контейнера ключей, имя криптопровайдера, тип провайдера и флаги, определяющие тип и действия с контейнером ключей и режим работы криптопровайдера:

BOOL WINAPI CryptAcquireContext(HCRYPTPROV* phProv,LPCTSTR pszContainer, LPCTSTR pszProvider,DWORD dwProvType,DWORD dwFlags);

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

Прежде чем использовать какие-либо функции Crypto API, необходимо запустить криптопровайдер. Делается это с помощью функции CryptAcquireContext:

BOOL CRYPTFUNC CryptAcquireContext( HCRYPTPROV* hCryptProvider,//дескриптор провайдера, out-параметр LPCTSTR pszContainer, // имя контейнера ключей LPCTSTR pszProvider, // имя провайдера DWORD dwProvType, // тип провайдера DWORD dwFlags // флаги )

Кроме инициализации криптопровайдера данную функцию можно использовать для создания и удаления контейнеров ключей. Для этого параметру dwFlags присваивается значение, соответственно, CRYPT_NEW-KEYSET и CRYPT_DELETEKEYSET. Функция CryptAcquireContext работает в два этапа: сначала она ищет криптопровайдер по имени и типу, указанному в аргументах, а затем контейнер ключей с заданным именем. По окончании работы с криптопровайдером необходимо вызвать функцию CryptReleaseContext. Криптопровайдеры отличаются друг от друга:

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

По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования — MD5 и SHA. В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к уже известному нам типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы. Приложение обращается к криптопровайдеру не напрямую, а через CryptoAPI. При этом вначале необходимо запросить у системы контекст криптопровайдера. Первым делом, хотя бы из любопытства, выясним, какие же криптопровайдеры установлены в системе. Для этого нам понадобятся четыре функции CryptoAPI:

• CryptEnumProviders (i, резерв, флаги, тип, имя, длина_имени) — возвращает имя и тип i-го по порядку криптопровайдера в системе (нумерация начинается с нуля);
• CryptAcquireContext (провайдер, контейнер, имя, тип, флаги) — выполняет подключение к криптопровайдеру с заданным типом и именем и возвращает его дескриптор (контекст). При подключении мы будем передавать функции флаг CRYPT_VERIFYCONTEXT, служащий для получения контекста без подключения к контейнеру ключей;
• CryptGetProvParam (провайдер, параметр, данные, размер_данных, флаги) — возвращает значение указанного параметра провайдера, например, версии (второй параметр при вызове функции — PP_VERSION), типа реализации (программный, аппаратный, смешанный — PP_IMPTYPE), поддерживаемых алгоритмов (PP_ENUMALGS). Список поддерживаемых алгоритмов при помощи этой функции может быть получен следующим образом: при одном вызове функции возвращается информация об одном алгоритме; при первом вызове функции следует передать значение флага CRYPT_FIRST, а при последующих флаг должен быть равен 0;
• CryptReleaseContext (провайдер, флаги) — освобождает дескриптор криптопровайдера.

Работа с ключами

Криптографические ключи и выполняемые функции

В CryptoAPI существуют ключи двух типов:

• сессионные ключи (session keys)
• пары открытый/закрытый ключ (public/private key pairs).

Сессионные ключи — это симметричные ключи, так как один и тот же ключ применяется и для шифрования, и для расшифровки. Сессионные ключи меняются. Алгоритмы, использующие сессионные ключи (так называемые симметричные алгоритмы), – RC2, RC4, DES. Microsoft RSA Base Provider работает с 40-разрядными сессионными ключами.
Пары открытый/закрытый ключ используются в так называемых асимметричных алгоритмах шифрования. Если шифрование выполнялось одним ключом из пары, то дешифрование производится другим. Открытые (public) ключи могут передаваться другим лицам для проверки цифровых подписей и шифрования пересылаемых данных. Длина открытого ключа в Microsoft RSA Base Provider составляет 512 разрядов. Закрытые (private) ключи не могут быть экспортированы; они используются для создания цифровых подписей и дешифровки данных. Закрытый ключ должен быть известен только его владельцу. При шифровании с открытым ключом жизненно важна абсолютно достоверная ассоциация открытого ключа и передавшей его стороны, поскольку в обратном случае возможна подмена открытого ключа и осуществление несанкционированного доступа к передаваемым зашифрованным данным. Необходим механизм, гарантирующий достоверность корреспондента, например, применение сертификата, созданного авторизованным генератором сертификатов. Обычно сертификаты содержат дополнительную информацию, позволяющую идентифицировать владельца личного ключа, соответствующего данному открытому ключу. Сертификат должен быть подписан авторизованным генератором сертификатов. Выполняемые функции:

• Функции кодирования сертификатов:

Эти функции управляют сертификатами и сопутствующими данными через сеть OSI (соединение открытых систем, семиуровневая модель) как описано в CCIT X.200. Методы OSI, описывающие абстрактные объекты, используют абстрактную синтаксическую нотацию один (ASN.1), как описано в CCITT X.209.

• Функции базы сертификатов:

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

• Базовые криптографические функции:

Используются для наиболее полного использования криптографических возможностей в приложении. Это функции взаимодействующие с провайдером. Все криптографические операции выполняются независимыми модулями называемыми Cryptographic Service Providers (CSP). Каждый CSP предлагает различные реализации криптографической поддержки используемой через CryptoAPI. Некоторые провайдеры несут более сильные алгоритмы, некоторые содержат физические компоненты (смарткарты, криптоускорители). В дополнение, некоторые CSP могут напрямую работать с пользователем при использовании личного ключа или подписи.

• Функции сообщений низкого уровня:

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

• Упрощенные функции сообщений:

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

Криптопровайдер отвечает за хранение и разрушение ключей. Программист не имеет доступа непосредственно к двоичным данным ключа, за исключением операций экспорта открытых ключей. Вся работа с ключами производится через дескрипторы (handle). В CryptoAPI ключи для шифрования / дешифрования и создания / проверки подписей разделены. Называются они соответственно «пара для обмена ключами» и «пара для подписи». База данных ключей состоит из контейнеров, в каждом из которых хранятся ключи, принадлежащие определенному пользователю. Контейнер ключей имеет уникальное имя и содержит пару для обмена и пару для подписи. Все ключи хранятся в защищенном виде. По умолчанию для каждого пользователя создается контейнер с именем этого пользователя. Можно создавать дополнительные контейнеры и назначать им произвольные имена, которые обязательно должны быть уникальными (см. Рис. 4).

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

Для генерации ключей в CryptoAPI предусмотрены две функции – CryptGenKey и CryptDeriveKey. Первая из них генерирует ключи случайным образом, а вторая – на основе пользовательских данных. При этом гарантируется, что для одних и тех же входных данных CryptDeriveKey всегда выдает один и тот же результат. Это способ генерации ключей может быть полезен для создания симметричного ключа шифрования на базе пароля. Более подробно следует остановиться на функции CryptGenKey, которая используется чаще всего. Эта функция имеет прототип:

Первый и четвертый параметры говорят сами за себя. Вторым параметром передается идентификатор алгоритма шифрования, для которого генерируется ключ (например, CALG_3DES). При генерации ключевых пар RSA для шифрования и подписи используются специальные значения AT_KEYEXCHANGE и AT_SIGNATURE. Третий параметр задает различные опции ключа, которые зависят от алгоритма и провайдера. Например, старшие 16 битов этого параметра могут задавать размер ключа для алгоритма RSA. Подробное описание всех флагов можно найти в MSDN. Здесь я упомяну только один флаг — CRYPT_EXPORTABLE, который позволяет экспортировать закрытые ключи RSA из контейнера (по умолчанию это запрещено). Для других ключей этот параметр смысла не имеет – открытые ключи являются свободно экспортируемыми, а сессионные ключи вообще не хранятся внутри контейнера, т.ч. их обязательно нужно экспортировать.

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

Обмен ключами в CryptoAPI реализуется с помощью функций CryptExportKey и CryptImportKey, имеющих следующие прототипы:

В качестве ключей экспорта/импорта могут использоваться либо ключевая пара RSA (с типом AT_KEYEXCHANGE), либо симметричный сеансовый ключ. Параметр dwBlobType зависит от того, какой ключ экспортируется (импортируется), и задает тип структуры, в которую помещается экспортируемый ключ. Для открытого ключа это PUBLICKEYBLOB, и ключ экспорта/импорта при этом лишен смысла и должен быть нулем. Для закрытого ключа это PRIVATEKEYBLOB, и в качестве ключа экспорта может использоваться сеансовый ключ. Для сеансового ключа это обычно SIMPLEBLOB, а экспортируется он, как правило, на открытом ключе получателя.

Описание флагов можно найти в MSDN. Можно выделить среди них флаг CRYPT_OAEP, который заставляет криптопровайдера использовать формат PKCS #1 версии 2 при сохранении сессионного ключа с шифрованием RSA. Ключ, сохраненный в этом формате, затем может быть расшифрован другими системами шифрования. Если же этот флаг не указан, то ключ сохраняется в каком-то известном только CryptoAPI формате, и использовать его где-либо еще вряд ли удастся.

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

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

В качестве примера ниже будет рассмотрено создание и экспорт пары ключей для шифрования RSA и симметричного ключа 3DES:

Обмен симметричными ключами
За обмен сессионными ключами в .NET отвечают классы RSAOAEPKeyExchangeFormatter/Deformatter и RSAPKCS1KeyExchangeFormatter/Deformatter. Они унаследованы от базовых классов AsymmetricKeyExchangeFormatter/Deformatter, предоставляющих методы CreateKeyExchange и DecryptKeyExchange для шифрования и дешифрации сессионных ключей, соответственно. Рассмотрим передачу сессионного ключа на небольшом примере:

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

Получение дескриптора ключа

Дескриптор открытого ключа можно получить, вызвав функцию CryptGetUserKey.

Экспорт ключей

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

Первый аргумент – дескриптор экспортируемого ключа. Второй аргумент – дескриптор ключа, которым шифруется экспортируемый ключ. Открытые ключи экспортируются в незашифрованном виде. В этом случае hCryptKey = 0. При экспорте сессионных и закрытых ключей необходимо их предварительно зашифровать. Аргумент hCryptKey должен содержать дескриптор открытого ключа получателя. При вызове с аргументом pbData = NULL функция вернет необходимую длину буфера по адресу, на который указывает аргумент pdwDataLen. После успешного завершения переменная dwSessionKeyLen будет содержать действительную длину BLOB-структуры ключа. Это значение необходимо сохранить для обратной операции – импорта ключа в криптопровайдер.

Импорт ключей

Ключи импортируются функцией CryptImportKey :

hCryptKey = 0 в том случае, если импортируемый ключ был, зашифрован асимметричным ключом или не был зашифрован вообще. Если импортируемый ключ шифровали сессионным ключом, то hCryptKey должен содержать дескриптор этого ключа. По окончании работы с ключом необходимо для его дескриптора вызвать функцию CryptDestroyKey(HCRYPTKEY hKey).

Цифровая подпись

Цифровая подпись – это двоичные данные небольшого объема, обычно не более 256 байт. Цифровая подпись есть не что иное, как результат работы хеш-алгоритма над исходными данными, зашифрованный закрытым ключом отправителя. Полученные в результате шифрования хеша двоичные данные и есть цифровая подпись (см. Рис. 5).

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

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

Если они эквивалентны, значит, данные были подписаны именно нами (см. Рис. 6).

Подобный алгоритм позволяет любому лицу проверить подлинность подписи отправителя. Напомню, что открытый ключ отправителя, с помощью которого собственно и производится проверка, распространяется (как правило) свободно. Для работы с цифровыми подписями используются функции CryptCreateHash, CryptHashData, CryptSignHash, CryptVerifySignature, CryptDestroyHash.

Создание цифровой подписи

Процесс создания подписи состоит из следующих этапов:

• создание хеш-объекта функцией CryptCreateHash;
• наполнение хеш-объекта данными (CryptHashData);
• подписание хеша (CryptSignHash);
• разрушение хеш-объекта (Crypt-DestroyHash).

Аналогично функциям CryptEncrypt, проверка длины буфера для подписи производится вызовом функции CryptSignHash с нулем вместо указателя на данные. Как и у функции CryptEncrypt, указатели на данные и их длину являются параметрами типа [in, out].

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

Проверка подписи выполняется так:

• создается хеш-объект функцией CryptCreateHash;
• хеш-объект наполняется данными (CryptHashData);
• подпись расшифровывается и результат сравнивается со «своим» хешем (CryptVerifySignature);
• хеш-объект разрушается (CryptDes-troyHash).

Шифрование и дешифрование данных

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

Таким образом, расшифровать данные можно только, имея закрытый ключ из той же ключевой пары, что и открытый ключ, которым данные были зашифрованы.

Хеши MD5 и SHA

Хеш создается вызовом функции CryptCreateHash, принимающей на входе контекст криптопровайдера, идентификатор алгоритма (CALG_MD5 или CALG_SHA) и хендл ключа (для хешей с ключем типа MAC и HMAC). После этого хеш можно вычислять как явно, используя функцию CryptHashData, так и неявно, передавая хендл хеша в функцию CryptEncrypt. Использование CryptEncrypt обсуждалось в разделе про DES, поэтому остановимся на функции CryptHashData. Ее вызов может выглядеть следующим образом: CryptHashData(hHash,(BYTE *)&data,dwLen,0); Вычисление хеша (также как и шифрование) можно производить по частям (например, читая данные в буфер и хешируя содержимое буфера в цикле). После окончания хеширования можно либо подписать хеш (см. ниже), либо получить его значение вызовом: CryptGetHashParam(hHash,HP_HASHVAL,(BYTE *)&buf,&dwLen,0); Размер хеша MD5 равен 128 бит или 16 байтов. Для SHA это 160 бит или 20 байтов. После получения значения хеш использовать уже нельзя. Его нужно разрушить вызовом CryptDestroyHash. Проверка хеша производится точно также, как и его создание – нужно вычислить хеш и сверить полученное значение с сохраненным: HCRYPTHASH hHash;

BYTE newHash[16]; dwLen=16;

Заключение

И CryptoAPI, и .NET предоставляют богатый набор средств шифрования, позволяющих организовать собственную систему защиты данных без использования сторонних средств. В .NET, правда, эти средства пока плохо отлажены и документированы, но использовать их все равно можно. Основными препятствиями на пути использования средств CryptoAPI и .NET могут стать отсутствие на платформах ниже Windows 2000 поддержки “сильной” криптографии и требования, налагаемые Российским законодательством на средства шифрования, используемые в коммерческой деятельности. По Российскому законодательству эти средства обязательно должны быть сертифицированы ФАПСИ. Но ни один из алгоритмов, реализованных в CryptoAPI и .NET, не является сертифицированным. Правда, это не мешает разработчикам shareware-программ использовать алгоритмы типа RSA для защиты своих продуктов.