Ця стаття для тих, хто з тих чи інших причин вирішив
написати власний крипто-провайдер для 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. Тоді в реєстрі необхідно прописати наступні ідентифікатори:
Нижче наведено приклад коду реєстрації 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, у згаданих вище двох сценаріях, не вийти. Біда ще й у тому, що
функції ці недокументовані і знайти інформацію по них вкрай складно. Їх
опису присвячений наступний розділ.
Опції конвертування ключів
Архітектура кругообігу відкритих ключів для
"Нестандартних" алгоритмів в Windows представлена на картинці:
Малюнок 4 - Імпорт та експорт відкритих ключів до/з CSP
Функція A_ConvertPublicKeyInfo - на вході приймає
ключ у форматі ASN.1 DER і повинна перетворити його у формат, який
"Розуміє" функція CSP CPImportKey
Функція A_EncodePublicKeyInfoAndParameters на вході
бере ключ в тому форматі, в якому ключ експортує CPExportKey. На
вихід A_EncodePublicKeyInfoAndParameters повинна сформувати ASN.1 DER
структуру з ключем - ту ж саму яка в разі імпорту передається в
A_ConvertPublicKeyInfo - на вхід. Сподіваюся, ви не заплуталися у всіх цих входах
Jі виходах
Ось сигнатури і нам інформацію про те параметрів цих
функцій:
BOOL WINAPI
A_ConvertPublicKeyInfo (
DWORD dwCertEncodingType,// IN -
VOID * EncodedKeyInfo,// IN - буфер з ключем - покажчик
// на структуру CERT_PUBLIC_KEY_INFO
DWORD dwAlg,
//IN - AlgId ключа
DWORD dwFlags,// IN - зазвичай 0
BYTE ** ppStructInfo,// OUT - подвійний покажчик на структуру
// в заголовку структури йде спочатку PUBLICKEYSTRUC,
потім DSSPUBKEY,
// а потім сам
ключ з параметрами
DWORD
* StructLen// OUT - довжина структури
);
BOOL WINAPI
A_EncodePublicKeyAndParameters (
DWORD dwCertEncodingType,// IN
LPCSTR lpszStructType,// IN - OID алгоритму
const void * pvStructInfo,// IN - така ж структура як
// на виході ConvertPublicKeyInfo
DWORD nStructLen,// IN - довжина вхідної структури
DWORD dwFlags,// IN - зазвичай 0
DWORD Unk,
/ /? - Невідомо
BYTE
** pbPubKey,// OUT - відкритий ключ в
ASN.1 DER
DWORD *
pcPubKeyLen,// OUT - довжина відкритого
ключа
BYTE ** pbParams,// OUT - параметри відкритого ключа
DWORD *
pcParamsLen// OUT - довжина параметрів
);
Формати ключів залежать від крипто-провайдера та
використовуваних алгоритмів.
Функція I_CryptGetDefaultCryptProvider з crypt32.dll
З незрозумілої для мене причини Windows часто не
намагається шукати потрібний крипто-провайдер за ідентифікатором алгоритму з яким
потрібно працювати. У таких випадках вона просто викликає недокументовані
функцію I_CryptGetDefaultCryptProvider, і якщо той провайдер, який повернула
ця функція, не вміє працювати з даним алгоритмом, то процес завершується з
помилкою. Так відбувається, наприклад, при розборі в Internet Explorer PKCS # 7
відповіді в сценарії із запитом сертифікату на тестовому УЦ.
Необхідно замінити цю функцію таким чином, щоб
при нульовому параметрі algid на вході вона повертала наш провайдер, який вже
на відміну від штатного провайдера легко впоратися з "нестандартними
алгоритмами ".
Обговорення способів заміни функцій в системній dll
виходить далеко за рамки цієї статті. Можу лише, як один із способів вирішення,
запропонувати бібліотеку Microsoft Detours:
http://research.microsoft.com/sn/detours
Прив'язка закритого ключа до сертифіката
На відміну від відкритого ключа закриті ключі ніколи не
залишають крипто-провайдер і тому коли ви бачите що для даного сертифікату
є закритий ключ (як на малюнку) це означає що в контексті цього
сертифіката існує явна посилання на закритий ключ.
Малюнок 5 - Закритий ключ сертифіката
Контекст сертифіката це набір додаткових
атрибутів сертифіката, які знаходяться не в тілі сертифіката, а зберігаються
окремо від нього. Одним з таких атрибутів і є посилання на закритий ключ,
яка складається з імені провайдера та імені ключового контейнера.
Приклад коду для прив'язки закритого ключа до
сертифікату:
PCCERT_CONTEXT
pCert;
CRYPT_KEY_PROV_INFO prov_info;
...
prov_info.cProvParam = 0;
prov_info.rgProvParam = 0;
prov_info.dwFlags = 0;
prov_info.dwKeySpec = AT_SIGNATURE;
prov_info.dwProvType = 0;
prov_info.pwszContainerName = L "key-kont-name";
prov_info.pwszProvName = L "A-CSP";
CertSetCertificateContextProperty (
pCert,
CERT_KEY_PROV_INFO_PROP_ID,
0,
& prov_info
);
Успіхів у розробці крипто-провайдера!
http://www.realcoding.net/
Форми в HTML документах
Деякі WWW browser дозволяють користувачеві, заповнивши
спеціальну форму, повертати отримані значення, виконувати деякі
дії на вашому WWW - сервер. Коли форма інтерпретується WEB - оглядачем,
створюється спеціальні екранні елементи GUI, такі, як перемикачі, checkboxes,
radiobuttons, що випадають меню, скролліруемие списки, кнопки і т.д. Коли
користувач заповнює форму і натискає кнопку "Підтвердження"
(SUBMIT - спеціальний тип кнопки, який задається при описі документа);
інформація, введена користувачем у форму, надсилається HTTP-сервером для
обробки та передачі іншим програмам, що працюють під сервером, відповідно
з CGI (Common Gateway Interface) інтерфейсом.
Коли ви описуєте форму, кожен елемент введення даних
має тег . Коли користувач поміщає дані в елемент форми,
інфоромація розміщується в розділі VALUE даного елементу.
