Windows cryptoapi что это

Обновлено: 06.07.2024

Внедрение электронной подписи (без разделения на используемые криптоалгоритмы и критерий «квалифицированности», см. закон 63-ФЗ, ст. 5) в информационную систему обычно вызвано необходимостью контроля целостности и авторства порождаемых в системе информационных потоков и документов.

Под катом описаны интерфейсы для работы с электронной подписью, а также распространенные форматы электронной подписи.

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

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

Отдельное внимание в вопросе работы с электронной подписью следует уделить установлению соответствия между открытым ключом подписи и непосредственно лицом, которому он принадлежит. Для решения данной задачи существует такое понятие, как «Сертификат открытого ключа электронной подписи» (или просто «цифровой сертификат»). Для выдачи, проверки действительности, отзыва и управления сертификатами необходима инфраструктура открытых ключей (Public Key Infrastructure). Вопрос сопоставления открытого ключа и его владельца – один из самых важных и сложных при работе с асимметричной криптографией, так как открытый ключ – это никак не идентифицируемый набор публичной информации, которая служит для проверки электронной подписи. А при отсутствии связки этой информации непосредственно с ее владельцем она всегда может быть изменена злоумышленником, что позволит ему формировать электронную подпись и выдавать ее за электронную подпись другого лица.

Встраивание электронной подписи в прикладные системы

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

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

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

В «западном» мире широко используется сертификация решений на соответствие Common Criteria, в России процесс сертификации средств криптографической защиты проводит ФСБ России.

Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).

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

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

Интерфейсы для доступа к СКЗИ

На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.

Microsoft Crypto API 2.0

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

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.

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

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации. В силу того, что распространенность Windows XP все еще довольно велика, CNG в прикладных системах используется крайне мало.

Проприетарные интерфейсы

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

Форматы электронной подписи

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

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

XML-DSig

Область применения XML-DSig – веб-приложения и веб-сервисы.

Сырая подпись

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

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

Заключение

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

Создание и верификация цифровой подписи в CryptoAPI через сертификат открытого ключа

Сегодня все технологии передачи защищенных данных в Internet – обмен ключами, работа с сертификатами, алгоритмы шифрования - должны соответствовать стандарту PEM (Privacy-Enhanced Mail). Протокол X.509, который описывает структуру сертификата, является составной частью PEM.

Version

Serial Number

Algorithm Identifier:Algorithm Parameters

Issuer

Period of Validity:Not Before Date Not After Date

Subject

Subject’s Public KeyAlgorithmParametersPublic Key

Signature

Структура X.509-сертификата

Установим этот сертификат. Двойным щелчком по файлу evgeny.cer запускаем certificate import wizard. Выбираем для установки персональное хранилище (personal) и заканчиваем установку, нажав кнопку Finish.

Данная цифровая подпись преобразована в hex-вид, поэтому при верификации ее нужно преобразовать обратно в текстовый формат.

Алгоритм верификации состоит из вызова следующих функций:

CertOpenStore - открываем хранилище сертификатов.
CertFindCertificateInStore – находим нужный сертификат.
CRYPT_VERIFY_MESSAGE_PARA – заполняем структуру для верификации
CryptVerifyDetachedMessageSignature – проверяем подпись.

Результат должен быть следующим:

Верификация цифровой подписи без дополнительной информации

А теперь, предположим, вы получили цифровую подпись без дополнительной информации в hex представлении. Ее длина 256 байт или 128 байт в текстовом виде.

Вы также получили и сертификат с открытым ключом. Используя только функции для работы с сертификатами, вы не сможете верифицировать такую подпись. Для верификации этой подписи нужно перейти к функциям CryptoAPI нижнего уровня, которые работают с CSP (cryptographic service provider). Все криптографические операции в операционной системе выполняются независимыми друг от друга модулями, известными как криптографические сервис провайдеры (CSP). В поставку Windows 2000 входят несколько CSP:

Gemplus GemSAFE Card CSP v1.0
Microsoft Base Cryptographic Provider v1.0
Microsoft Base DSS and Diffie-Hellman Cryptographic Provider
Microsoft Base DSS Cryptographic Provider
Microsoft DH SChannel Cryptographic Provider
Microsoft Enhanced Cryptographic Provider v1.0
Microsoft Enhanced DSS and Diffie-Hellman Cryptographic Provider
Microsoft RSA SChannel Cryptographic Provider
Microsoft Strong Cryptographic Provider
Schlumberger Cryptographic Service Provider

Процесс верификации заключается в вызове следующих функций:

Результат должен быть следующим:

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

Мы должны получить цифровую подпись, приведённую в начале статьи.

CertOpenStore - открывает хранилище сертификатов.
CertFindCertificateInStore – находит нужный сертификат.
CRYPT_SIGN_MESSAGE_PARA – заполнение структуры для создания подписи
CryptSignMessage – создаем подпись.

Результат должен быть следующим:

Cоздание обычной цифровой подписи

Теперь создадим обычную подпись, используя наш сертификат (файл evgeny.pfx), размером 256 байт в hex-представлении. Как и в случае верификации такой подписи, воспользуемся функцией CryptAcquireCertificatePrivateKey. Она обеспечит переход от сертификата к соответствующему дескриптору CSP. Используя дескриптор, нам осталось получить подпись.

Ниже представлена последовательность действий.

CertOpenStore - открывает хранилище сертификатов.

CertFindCertificateInStore – находит нужный сертификат.

CryptAcquireCertificatePrivateKey –получает дескриптор CSP провайдера соответствующего нашему сертификату.

CryptCreateHash – создает хэш

CryptSignHash – шифрует созданный хэш

Результат должен быть следующим:

Архитектура системы CryptoAPI состоит из пяти основных функциональных областей:

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

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

Функции шифрования и расшифровки сертификатов

Функции, используемые для шифрования или расшифровки данных. Также включена поддержка хэширования данных. Дополнительные сведения см. в разделе функции шифрования и расшифровки данных , а затем — Шифрование и расшифровка данных.

Функции хранилища сертификатов

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

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

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

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

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

ViPNet CSP

VipNet CSP – это программный комплекс, который реализует интерфейс Microsoft CryptoApi.

Генерация закрытых и открытых ключей ЭЦП и шифрования в соответствии с алгоритмом ГОСТ Р 34.10 – 2001.
Вычисление хеш-функции в соответствии с алгоритмом ГОСТ Р 34.11-94.
Вычисление и проверка ЭЦП в соответствии с алгоритмом ГОСТ Р 34.10-2001.
Выработка случайных и псевдослучайных чисел, сессионных ключей шифрования.
Шифрование и имитозащита данных в соответствии с алгоритмом ГОСТ 28147-89.
Аутентификация и шифрование при передаче данных по протоколам SSL/TLS.
Операции с сертификатами открытых ключей, соответствующих стандарту X.509 v3.

Совместимость

ViPNet CSP функционирует под управлением ОС Windows 2000 (32 бит)/XP (32 бит)/Server 2003 (32 бит)/Vista (32 бит) /Windows 7 (32/64 бит).

К сожалению VipNet CSP – это платный продукт, но на сайте есть бета-версии, которые отлично функционируют.

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

Итак, мы инсталлировали криптопровайдер, можем написать программу, шифрующую данные с использованием ГОСТ 28147-89. В скачиваемом пакете (архиве) есть папка «ViPNet CSP SDK (для разработчиков)», найдем там заголовочный файл importitccsp.h, в нем объявлены необходимые нам константы. Смотрим пример:

HCRYPTPROV hProv;
HCRYPTKEY hSessionKey;

// Получение контекста криптопровайдера
// VPN_DEF_PROV и VPN_PROV_TYPE - указывают на то, что мы используем ViPNet CSP
if (!CryptAcquireContext(&hProv, NULL, VPN_DEF_PROV, VPN_PROV_TYPE, CRYPT_VERIFYCONTEXT))
printf("Error CryptAcquireContext");
return;
>

// Генерация сессионного ключа
// CPCSP_ENCRYPT_ID - используется ГОСТ 28147-89
if (!CryptGenKey(hProv, CPCSP_ENCRYPT_ID, CRYPT_ENCRYPT | CRYPT_DECRYPT, &hSessionKey))
printf("Error CryptGenKey");
return;
>

// Данные для шифрования
char data[]="habrahabr";
DWORD count=strlen(data);

// Шифрование данных
if (!CryptEncrypt(hSessionKey, 0, true, 0, (BYTE*)data,
&count, strlen(data)))
printf("Error CryptEncrypt");
return;
>

// Тестовый вывод на экран
printf("Encrypted string: %s", data);

// Расшифровывание данных
if(!CryptDecrypt(hSessionKey, 0, true, 0, (BYTE*)data, &count))
printf("Error CryptDecrypt");
return;
>

// Тестовый вывод на экран
printf("Decrypted string: %s", data);

// Освобождение контекста локальных переменных
CryptDestroyKey(hSessionKey);
CryptReleaseContext(hProv, 0);

Шифрование данных и расшифрование их на другом компьютере — тема отдельной статьи.
Спасибо за внимание.

Читайте также: