Регистрация крипто-провайдера и алгоритмов в системе
Секреты разработки CSP Юрий Зырянов Введение Эта статья для тех, кто по тем или иным причинам решил написать собственный крипто-провайдер для OC семейства Windows. Если Вы хотите реализовать в вашем провайдере нестандартные алгоритмы, то вам предстоит столкнуться с определенными трудностями. Трудности могут возникнуть, например, при попытках использования вашего крипто-провайдера для проверки сертификатов в MS Internet Explorer. Под нестандартными алгоритмами здесь понимаются не всемирные DES, RSA, DSA и т.д, а, например, алгоритмы семейства ГОСТ. Дело в том, что для RSA и подобных алгоритмов все необходимые идентификаторы уже зашиты в систему, а для ГОСТ-ов (или многих других алгоритмов) надо отдельно позаботиться о том, чтобы система их “увидела”. Для примеров кода используется Си. Все примеры кода служат только для иллюстрации принципов изложенных в статье и не являются полноценными рабочими программами. Также подразумевается, что у читателя есть базовые знания в области прикладной криптографии и термины “открытый ключ”, “ASN.1” и подобные для него не являются загадкой. Интеграция провайдера в Windows Помимо наличия библиотеки самого провайдера дополнительно требуется: зарегистрировать провайдер и крипто-алгоритмы в системе, прописав определенные параметры в реестре; создать библиотеку с функциями конвертирования ключей из форматов криптопровайдера во внешние форматы и зарегистрировать эти функции в реестре; заменить функцию I_CryptGetDefaultCryptProvider в библиотеке crypt32.dll Только после выполнения этих действий провайдер нормально интегрируется в систему и вы сможете, например, генерировать сертификаты при помощи вашего провайдера на основе стандартного компонента ОС Windows Server - Сertification services или на тестовом УЦ КриптоПро http://www.cryptopro.ru/certsrv Корректно будет отображаться статус проверки подписи у сертификатов, подписанных вашим “нестандартным” алгоритмом и т.п. Далее подробно рассмотрим каждый из упомянутых выше шагов, предполагая при этом что библиотека с Вашим CSP уже имеется и корректно работают все функции провайдера. Регистрация крипто-провайдера и алгоритмов в системе Когда у вас уже есть готовая библиотека с реализацией функций CSP, необходимо зарегистрировать ее в системе, для того чтобы новый крипто-провайдер стал доступен различным приложениям. Процесс регистрации самого CSP подробно описан в MDSN, и повторять эту информацию здесь смысла нет. Все это подробно описано в [1]. Также здесь мы не будем останавливаться на проблеме подписи нового CSP в Microsoft и путях ее обхода. Эта проблема уже многократно обсуждалась на различных форумах, например смотрите [3]. Гораздо интереснее рассмотреть регистрацию криптографических алгоритмов. Каждый алгоритм имеет свой уникальный ASN.1 идентификтор Оbject Identifier - OID. Например, алгоритм подписи ГОСТ-34.10-2001 имеет такой OID (представленный в виде строки) – “1.2.643.2.2.3”. Идентификатор каждого поддерживаемого вашим CSP алгоритма следует занести в реестр. Помимо OID у каждого крипто-алгоритма в Windows существует еще идентификатор в виде четырех-байтового числа – AlgID, по которому алгоритмы идентифицируются в провайдере. Этот идентификатор заноситься в CSP и его можно узнать перечислив алгоритмы посредством вызова CPGetProvParam. В КриптоПро, например, для алгоритма хеширования ГОСТ-34.11-94 AlgID используется значение 0x801e Пусть нам необходимо зарегистрировать алгоритм подписи ГОСТ-34.10-2001. Тогда в реестре необходимо прописать следующие идентификаторы: “1.2.643.2.2. 9!1” – Хэш ГОСТ-34.11-94 “1.2.643.2.2.19!3” – Ключ подписи ГОСТ-34.10-2001 “1.2.643.2.2.3!4” – Подпись ГОСТ-34.10-2001 – Алгоритм Хэша + Алгоритм Ключа Рисунок 1 - Идентификаторы алгоритмов Далее приведен пример кода регистрации OID алгоритма ГОСТ-34.11-94 // Регистрация GOST-3411-94 HASH OID // CRYPT_OID_INFO oidInfo; int rc = 0;
memset(&oidInfo, 0, sizeof(CRYPT_OID_INFO)); oidInfo.cbSize = sizeof(CRYPT_OID_INFO); oidInfo.pszOID="1.2.643.2.2.9"; oidInfo.pwszName= L"GOST-3411-94 HASH"; oidInfo.dwGroupId = CRYPT_HASH_ALG_OID_GROUP_ID; oidInfo.Algid = 0x801e; oidInfo.ExtraInfo.cbData=0; oidInfo.ExtraInfo.pbData=0; rc = CryptRegisterOIDInfo( &oidInfo, 0 ); if(rc) printf("nHash algorithm registered”); else printf("nError registering hash algorithm”); Аналогично регистрируются и остальные алгоритмы. Подробную информацию о структуре CRYPT_OID_INFO можно найти в MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/crypt_oid_info.asp Для того чтобы провайдер вызывался для проверки сертификата, подписанного нашим “нестандартным” алгоритмом необходимо еще одно дополнительное действие. Дело в том, что Windows определяет какой провайдер использовать для проверки по полю ExtraInfo (см. ссылку в предыдущем абзаце для описания этого поля) в ключе реестра соответвующему алгоритму подписи – такой ключ мы создаем, вызывая функцию CryptRegisterOIDInfo. Поэтому надо указать системе наш провайдер в качестве провайдера по умолчанию для типа, который занесен в ExtraInfo алгоритма подписи. Следующий код устанавливает провайдер по умолчанию для определенного типа. #define YOUR_PROV_NAME "MY_PROV" #define YOUR_PROV_TYPE 75 rc = CryptSetProvider( YOUR_PROV_NAME, YOUR_PROV_TYPE ); Сценарии применения нашего CSP Рассмотрим здесь два сценария применения CSP. Первый сценарий – проверка подписи сертификата. Для проверки подписи система загружает открытый ключ из сертификата, которым подписан проверяемый. Затем по OID алгоритма подписи проверяемого сертификата, так как описано в предыдущем разделе статьи, определяется требуемый провайдер. Чтобы проверить подпись, нужно импортировать открытый ключ в CSP и можно было бы подумать что Windows сразу вызывает функцию нашего провайдера CPImportKey. Но не тут-то было! Второй сценарий – генерация ключевой пары и отправка запроса на сертификат на Удостоверяющий Центр. Windows загружает наш CSP, генерирует ключевую пару и экспортирует к себе наверх открытый ключ вызывая функцию CPExportKey. Все хорошо. Вроде бы надо взять и поместить полученный буфер с ключом в PKCS#10 запрос, который затем будет отправлен на УЦ. И тут все опять не совсем так. Рисунок 2 - Запрос на сертификат в УЦ Рисунок 3 - Процесс создания сертификата Оказывается, существуют промежуточные функции для экспорта/импорта открытых ключей, и без их реализации ничего хорошего с нашим CSP, в упомянутых выше двух сценариях, не получиться. Беда еще и в том, что функции эти недокументированные и найти информацию по ним крайне сложно. Их описанию посвящен следующий раздел.
Популярное: Как выбрать специалиста по управлению гостиницей: Понятно, что управление гостиницей невозможно без специальных знаний. Соответственно, важна квалификация... Модели организации как закрытой, открытой, частично открытой системы: Закрытая система имеет жесткие фиксированные границы, ее действия относительно независимы... Как распознать напряжение: Говоря о мышечном напряжении, мы в первую очередь имеем в виду мускулы, прикрепленные к костям ... ©2015-2024 megaobuchalka.ru Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. (337)
|
Почему 1285321 студент выбрали МегаОбучалку... Система поиска информации Мобильная версия сайта Удобная навигация Нет шокирующей рекламы |