Развернуть все
Свернуть все

Рекомендации по использованию модулей КриптоПро

IKE, ESP, AH

Инициализация библиотеки и модуля ядра

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

На этапе инициализации библиотеки необходимо выработать ключи в соответствии с Рекомендации по использованию API SADB.

Инициализация модуля ядра ОС криптографической поддержки протоколов и преобразований ESP/AH осуществляется вызовом cpesp_init_gost, завершение - cpesp_shutdown_gost.

На этапе инициализации модуля необходимо выработать ключи в соответствии с Рекомендации по использованию API SADB.

  • создать ключи

  • передать на уровень ядра данные для инициализации ПДСЧ модуля и открытый ключ администратора узла сети

  • инициализировать ПДСЧ на уровне ядра ОС

  • передать на уровень приложения открытый ключ модуля ESP/AH

Режимы и методы фазы 1 IKE/ГОСТ

Базовыми методами в фазе 1 IKE/ГОСТ являются "Main Mode" и "Aggressive Mode". Они используются с ISAKMP-службой безопасности и предназначены для выработки аутентифицированного ключевого материала с использованием обмена по Диффи-Хеллману на асимметричных ключевых парах. Фаза 1 идентифицируется значением Messege_ID равным 0.

Фаза 1 IKE/ГОСТ состоит из процесса аутентификации, завершающегося вызовами функций p1_VerifyIRFn на каждой из сторон. Если хотя бы одна из функций возвратила ошибку, процессы на обеих сторонах должны завершиться по неуспеху.

После успешного завершения процесса стороны сериализуют данные сессии фазы 1. Для сериализации, десериализации и ресериализации используются вызовы p1_SerializeFn, p1_deSerializeFn и p1_reSerializeFn.

После согласования сторонами ассоциаций безопасности (SA), ISAKMP создаёт IKE сессии фазы 1 вызовом p1_CreateFn, на вход которого передаются параметры:

  • идентификатор метода аутентификации

  • параметр шифрования и имитовставки обмена ISAKMP

  • параметр группы алгоритма Диффи-Хеллмана

  • HASH_OID - идентификатор функции хеширования, использующейся в вызовах PRF и при выработке и проверке значений аутентифицирующих элементов фазы 1 и фазы 2

Далее с использованием функции p1_SetParamFn могут быть установлены иные параметры согласованной SA:

  • максимальное время жизни SA

  • максимальное число сессий фазы 2, создаваемых из сессии фазы 1

  • возможность неиспользования режима PFS

Функция p1_GetParamFn считывает установленные значения параметров.

Метод IKE-GOST-PSK

PSK-аутентификация. Main Mode

Аутентификация в режиме IKE-GOST-PSK требует, чтобы процессу ISAKMP был установлен предварительно распределённый ключ PSK. ISAKMP передаёт этот ключ в IKE с помощью p1_SetPSKFn. В данном режиме аутентификация в фазе IKE/ГОСТ ph1 проводится по схеме:

Таблица 1
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder



HDR,SA

p1_Create

p1_SetParam




==>

<==




p1_Create

p1_SetParam






HDR,SA

HDR,KE_i,Ni

p1_Setup

==>

.

.

.

.

<==

p1_Setup

HDR,KE_r,Nr







HDR*,IDii,HASH_I

p1_SetPSK

p1_Agree

p1_AuthIR(I)

p1_Encap







==>







p1_SetPSK

p1_Agree

p1_Decap

p1_VerifyIR(I)







.




.




p1_Decap

p1_VerifyIR(R)




<==

p1_AuthIR(R)

p1_Encap




HDR*,IDir,HASH_R

Метод IKE-GOST-PSK

PSK-аутентификация. Aggressive Mode

Таблица 2
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder




HDR,SA,KE_i,Ni,IDii

p1_Create

p1_SetParam

p1_Setup





==>





p1_Create

p1_SetParam





.







.







p1_SetPSK

p1_SetParam

p1_Agree

p1_VerifyIR(R)







<==

p1_Setup

p1_SetPSK

p1_Agree

p1_AuthIR(R)







HDR,SA,KE_r,Nr,IDir,HASH_R




HDR*,HASH_I

p1_AuthIR(I)

p1_Encap




==>




p1_Decap

p1_VerifyIR(I)




.

Метод IKE-GOST-SIGNATURE

Аутентификация на ключах подписи. Main Mode

Аутентификация в режиме IKE-GOST-SIGNATURE требует установленного ключа подписи пользователя. Также ISAKMP должен либо найти сертификат оппонента в хранилищах сертификатов компьютера, либо запросить сертификат у удаленной стороны запросом CERTREQ. Сертификат удаленной стороны должен быть проверен, разобран и передан функции p1_SetOtherCertFn.

Таблица 3
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder



HDR,SA

p1_Create

p1_SetParam




==>

<==




p1_Create

p1_SetParam






HDR,SA

HDR,KE_i,Ni,[CERTREQ]

p1_Setup

==>

.

.

.

.

<==

p1_Setup

HDR,KE_r,Nr,[CERTREQ]







HDR*,IDii,[CERT],SIG_I

p1_Agree

p1_SetMyCertProv*

p1_AuthIR(I)

p1_Encap







==>







p1_Agree

p1_Decap

p1_SetOtherCert

p1_VerifyIR(I)







.






.






p1_Decap

p1_SetOtherCert

p1_p1_VerifyIR(R)






<==

p1_SetMyCertProv

p1_AuthIR(R)

p1_Encap






HDR*,IDir,[CERT],SIG_R

Примечание: Функция p1_SetMyCertProvFn может быть вызвана на более ранних этапах обмена. После выполнения функции p1_AuthIRFn контекст, переданный в p1_SetMyCertProvFn, может быть уничтожен приложением.

Метод IKE-GOST-SIGNATURE

Аутентификация на ключах подписи. Aggressive Mode

Таблица 4
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder





HDR,SA,KE_i,Ni,IDii,[CERTREQ]

p1_Create

p1_SetParam

p1_Setup






==>






p1_Create

p1_SetParam






.

.









p1_SetParam

p1_Agree

p1_SetOtherCert

p1_VerifyIR(R)









<==

p1_Setup

p1_Agree

p1_SetMyCertProv*

p1_AuthIR(R)









HDR,SA,KE_r,Nr,[CERTREQ],IDir,[CERT],SIG_R






HDR*,[CERT],SIG_I

p1_SetMyCertProv*

p1_AuthIR(I)

p1_Encap






==>






p1_Decap

p1_SetOtherCert

p1_VerifyIR(I)






.

Примечание: Функция p1_SetMyCertProvFn может быть вызвана на более ранних этапах обмена. После выполнения функции p1_AuthIRFn контекст, переданный в p1_SetMyCertProvFn, может быть уничтожен приложением.

Метод IKE-GOST-GSS-API

GSS-API-аутентификация. Main Mode

Аутентификация в режиме IKE-GSS-API требует, чтобы процесс ISAKMP использования SSPI-провайдера. ISAKMP передаёт идентификаторы сторон и токены в IKE с помощью p1_SetSSPIFn. GSS-API-аутентификация в Main Mode фазы 1 проводится по схеме:

Таблица 5
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder



HDR,SA

p1_Create

p1_SetParam




==>

<==




p1_Create

p1_SetParam






HDR,SA





HDR,KE_i,Ni,GSSi

p1_Setup

SSPI->

InitializeSecurityContext(Gi,0,GSSi)





==>





.





.









.









SSPI->

InitializeSecurityContext(0,GSSr,GSSI(n))

p1_SetSSPI(Gi,Gr,GSSi,GSSr)

p1_Agree









<==

p1_Setup

SSPI->

AcceptSecurityContext(Gr,GSSi,GSSr)

p1_SetSSPI(Gi,Gr,GSSi,GSSr)

p1_Agree









HDR,KE_r,Nr,GSSr















HDR*,IDii,[GSSI(n)|HASH_I]

[

SSPI->

InitializeSecurityContext(0,GSSR(n-1),GSSI(n))

|

p1_AuthIR(I)

SSPI->EncryptMessage(hs)

]

p1_Encap















==>















p1_Decap

[

SSPI->

AcceptSecurityContext(0,GSSI(n-1),GSSR(n))

|

SSPI->

DecryptMessage(hash)

p1_VerifyIR(I)

p1_AuthIR(R)

SSPI->

EncryptMessage(hs)

]















.

.

p1_Decap

SSPI->

DecryptMessage(hash)

p1_VerifyIR(R)

<==

p1_Encap

HDR*,IDir,[GSSR(n)|HASH_R]

Метод IKE-GOST-GSS-API

GSS-API-аутентификация. Agressive Mode

Этот режим допустим только в случае, если второй вызов SSPI->InitializeSecurityContext() на инициаторе и первый вызов SSPI->AcceptSecurityContext() на ответчике возвратил SEC_E_OK. В случае возврата SEC_I_CONTINUE_NEEDED, аутентификация должна быть прервана. Для этого режима макрос CPIKE_AV_GSS(n) всегда должен иметь значения аргумента n равное 0. GSS-API-аутентификация в Agressive Mode фазы 1 проводится по схеме:

Таблица 6
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder








HDR,SA,KE_i,Ni,IDii,GSSi

p1_Create

p1_SetParam

p1_Setup

SSPI->

InitializeSecurityContext(Gi,0,GSSi)









==>









p1_Create

p1_SetParam









.















.















SSPI->

InitializeSecurityContext(0,GSSr,0)

p1_SetSSPI(Gi,Gr,GSSi,GSSr)

p1_SetParam

p1_Agree

SSPI->

DecryptMessage(hash)

p1_VerifyIR(R)















<==

p1_Setup

SSPI->

AcceptSecurityContext(Gr,GSSi,GSSr)

p1_SetSSPI(Gi,Gr,GSSi,GSSr)

p1_Agree

p1_AuthIR(R)

SSPI->

EncryptMessage(hs)















HDR,SA,KE_r,Nr,IDir,GSSr,HASH_R








HDR*,HASH_I

p1_AuthIR(I)

SSPI->

EncryptMessage(hs)

p1_Encap








==>








p1_Decap

SSPI->

DecryptMessage(hash)

p1_VerifyIR(I)








.

Метод IKE-GOST-HYBRID-INITIATOR / IKE-GOST-HYBRID-RESPONDER

Аутентификация на ключах подписи. Main Mode

Аутентификация в режиме IKE-GOST-HYBRID-INITIATOR / IKE-GOST-HYBRID-RESPONDER требует установленного ключа подписи у сервера (IKE-GOST-HYBRID-RESPONDER). Также ISAKMP должен либо найти сертификат сервера в хранилищах сертификатов компьютера, либо запросить сертификат запросом CERTREQ. Сертификат сервера должен быть проверен, разобран и передан функции p1_SetOtherCertFn. Данный метод аутентификации сервера завершается переходом к обмену конфигурационной информацией (раздел 3.1 [draft-dukes-ike-mode-cfg]) для аутентификации клиента (IKE-GOST-HYBRID-INITIATOR).

Таблица 7
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder



HDR,SA

p1_Create(IKE-GOST-HYBRID-INITIATOR)

p1_SetParam




==>

<==




p1_Create(IKE-GOST-HYBRID-RESPONDER)

p1_SetParam






HDR,SA

HDR,KE,Ni,[CERTREQ]

p1_Setup

==>

.

.

.

.

<==

p1_Setup

HDR,KE,Nr






HDR*,IDii,HASH_I

p1_Agree

p1_AuthIR(I)

p1_Encap






==>






p1_Agree

p1_Decap

p1_VerifyIR(I)






.






.






p1_Decap

p1_SetOtherCert

p1_VerifyIR(R)






<==

p1_SetMyCertProv

p1_AuthIR(R)

p1_Encap






HDR*,IDir,[CERT],SIG_R

Примечание: Функция p1_SetMyCertProvFn может быть вызвана на более ранних этапах обмена. После выполнения функции p1_AuthIRFn контекст, переданный в p1_SetMyCertProvFn, может быть уничтожен приложением.

Метод IKE-GOST-HYBRID-INITIATOR / IKE-GOST-HYBRID-RESPONDER

Аутентификация на ключах подписи. Aggressive Mode

Таблица 8
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder





HDR,SA,KE_i,Ni,IDii

p1_Create(IKE-GOST-HYBRID-RESPONDER)

p1_SetParam

p1_Setup






==>






p1_Create(IKE-GOST-HYBRID-INITIATOR)

p1_SetParam






.






.






p1_Agree

p1_VerifyIR(R)






<==

p1_Setup

p1_Agree

p1_AuthIR(R)






HDR,SA,KE_r,Nr,IDir,HASH_R






HDR*,[CERT],SIG_I

p1_SetMyCertProv*

p1_AuthIR(I)

p1_Encap






==>






p1_Decap

p1_SetOtherCert

p1_VerifyIR(I)






.

Примечание: Функция p1_SetMyCertProvFn может быть вызвана на более ранних этапах обмена. После выполнения функции p1_AuthIRFn контекст, переданный в p1_SetMyCertProvFn, может быть уничтожен приложением.

Формат передачи сигнатуры

Signature передаётся в виде строки битов длиной 512.

Режимы и методы фазы 2 IKE /ГОСТ

Фаза 2 IKE/ГОСТ обмена ISAKMP включает режим Quick Mode, New Group Mode и Informational Mode.
Замечание

Строго говоря, New Group Mode не принадлежит фазе 2, но, для упрощения, в дальнейшем на этом не будет акцентироваться внимание.

Сессия фазы 2 IKE/ГОСТ идентифицируется уникальным параметром M_ID, отличным от 0 и создаётся вызовом p2_CreateFn.

Сессия фазы 2 порождается на основе сессии фазы 1. Сессия фазы 1 может быть как исходной, так и десериализованной (полученной вызовами p1_SerializeFn и p1_deSerializeFn).

Сессии фазы 2 вызовом p2_SetParamFn могут быть установлены параметры согласованной SA:

  • CPIPSEC_AT_Group_Description - параметр группы алгоритма Диффи-Хеллмана режима PFS

  • CPIPSEC_AT_GOST_28147_SBOX - параметр, используемый для выбора SBox

  • CPIPSEC_AT_Life_Duration - ограничение на время жизни сессии в секундах/байтах

  • CPIPSEC_AT_Ext_Serial_Number - использование Extended SN

  • CPIPSEC_AT_Max_Auth_Error - максимальное значение счётчика ошибок аутентификации

  • CPIPSEC_AT_Max_Packet_Len - максимальный размер пакета

  • CPIPSEC_AT_Authentication_Algorithm - алгоритм аутентификации

  • CPIPSEC_ATP_Check_SN - использование оконного алгоритма

Значения установленных параметров могут быть получены вызовом p2_GetParamFn.

На основе одной сессии фазы 1 допускается создание не более CPIKE_PFSONLY_MAX_MSGS (2^12) сессий фазы 2 при условии использования PFS и не более CPIKE_NONPFS_MAX_MSGS (2^7) без использования PFS.

Режим Quick Mode фазы 2

В режиме IKE/ГОСТ Quick Mode вырабатываются ключи для протоколов ESP и AH/ГОСТ, согласовываются параметры и режимы работы протоколов для каждого значения индекса SPI, ключи и параметры подготавливаются для передачи модулю ядра ОС.

На уровне протокола ISAKMP обмен IKE/ГОСТ Quick Mode производится по схеме:

Таблица 9
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder









HDR*,HASH(1),SA0,[SA1,...]Ni,[KE_i,][IDci,IDcr]

p2_Create

p2_SetParam

p2_Setup

p2_HashAFn(HASH(1))

p2_Encap










==>










p2_Create

p2_Decap

p2_VerifyA(HASH(1))

p2_SetParam










.








.








p2_Decap

p2_VerifyA(HASH(2))

p2_Agree








<==

p2_Setup

p2_Agree

p2_HashA;(HASH(2))

p2_Encap








HDR*,HASH(2),SA0,[SA1,...]Nr,[KE_r,][IDci,IDcr]




HDR*,HASH(3)

p2_Hash3

p2_Encap




==>




p2_Decap

p2_Verify3




.

.

spiSerialize(SA*,...)

.

spiSerialize(SA*,...)

.

SA0,[SA1,...]- одна или несколько SA, определяющих алгоритмы, режимы, параметры протоколов ESP/AH. Для каждой из SA Инициатор в составе первого пакета передаёт SPI для направления Инициатор - Респондер. В ответном пакете Респондер передаёт для каждой ассоциации своё значение SPI для направления Респондер-Инициатор.

Режим PFS

Инициатор и Респондер вырабатывают эфемерные ключевые пары вызовом функции p2_SetupFn. Эти вызовы возвращают открытые ключи, после обмена которыми, вызовами p2_AgreeFn вырабатываются ключи согласования, используемые при получении результирующих ключей. Параметры ключевых пар PFS согласуются в составе SA0. Режим PFS по умолчанию обязателен. Необязательное использование режима PFS может быть согласовано в составе SA на первой фазе протокола и установлено вызовом p1_SetParamFn с параметром CPIKE_AC_PFS_Control со значением CPIKE_PFSC_Non_Mandatory_PFS.

Замечание

Значения HASH(1) и HASH(2) вычисляются приложением вызовами функции p2_HashAFn и проверяются p2_VerifyAFn. Значения HASH(3) вырабатываются вызовами p2_Hash3Fn и проверяются p2_Verify3Fn.

ISAKMP информационный обмен

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

Таблица 10
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder





HDR*,HASH(1),N/D

p2_Create

p2_HashA

p2_Encap






==>






p2_Create

p2_Decap

p2_VerifyA






.

где

  • N/D - данные протокола ISAKMP

  • Шифрование производится в согласованных в ISAKMP SA режимах

Transaction Exchanges при использовании IKE-GOST-HYBRID-INITIATOR / IKE-GOST-HYBRID-RESPONDER

Предназначен для обмена конфигурационной информацией при использовании гибридной аутентификации, инициатором Transaction Exchange может быть только сервер (IKE-GOST-HYBRID-RESPONDER), а общее количество пакетов при Transaction Exchange не должно превышать 2. Поддерживаются только Protected Exchanges (раздел 3.1.1 [draft-dukes-ike-mode-cfg]):

Таблица 11
Initiator Вызываемые функции Направление передачи Вызываемые функции Responder






HDR*,HASH,ATTR

p2_Create

p2_HashA

p2_Encap







==>







p2_Create

p2_Decap

p2_VerifyA

p1_SetParam(CPIKE_AC_Own_CFGMODE_Status,CPIKE_CFGMODE_OK)*







.





.





p2_Decap

p2_VerifyA

p2_Encap

p1_SetParam(CPIKE_AC_Peer_CFGMODE_Status,CPIKE_CFGMODE_OK)*





<==

p2_HashA

p2_Encap





HDR*,HASH,ATTR

Закрытые ключи, сертификаты, проверка сертификатов

Закрытые ключи

Приложение ISAKMP должно представить библиотеке libike_gost ключ компьютера (ключ администратора безопасности компьютера) и ключ аутентификации пользователя. Эти ключи могут быть представлены либо в форме PSK либо в форме ключевого контейнера КриптоПро CSP-3.6.1. Ключи в форме PSK устанавливаются вызовами CreatePSKFn, p1_SetPSKFn для ключа компьютера и ключа пользователя соответственно. Ключи в форме ключевого контейнера КриптоПро CSP-3.6.1 устанавливаются вызовами CreateProvFn и p1_SetMyCertProvFn. Функции CreateProvFn и p1_SetMyCertProvFn для ключа компьютера и ключа пользователя создают хэндлы ключей для использования в библиотеке без обращения к интерфейсу пользователя (SILENT режим). Ключевые контейнеры должны содержать закрытые ключи обмена AT_KEYEXCHANGE и сертификаты этих ключей. Ключ аутентификации пользователя устанавливается в библиотеку вызовом p1_SetMyCertProvFn, передающем хендл провайдера с подготовленным для режима SILENT ключевым контейнером.

Требование к сертификатам сторон

  • сертификат должен быть выпущен "КриптоПро УЦ 1.3 или выше" (соответствовать RFC 4490)

  • срок действия закрытого ключа сертификата должен удовлетворять установленному регламенту и требованиям используемой версии "КриптоПро CSP" (обычно не более 1 года и трёх месяцев)

  • в случае, если сертификат используется не только для IKE и срок действия сертификата превышает срок действия закрытого ключа, то сертификат должен содержать расширение Private Key Usage Period [RFC3280]. При этом данное расширение должно контролироваться обеими сторонами для обоих сертификатов

  • проверяемый сертификат должен содержать в расширении EKU (Extended Key Usage) [RFC3280] назначение "1.3.6.1.5.5.8.2.2" (сертификат IKE посредник IP безопасности)

  • проверяемый сертификат должен содержать в расширении Key Usage [RFC3280] флаги: digitalSignature (цифровая подпись) и/или nonRepudiation (неотрекаемость), keyEncipherment (шифрование ключей) и/или keyAgreement (согласование ключей).

Поиск и проверка сертификатов

Поиск и проверка сертификата пользователя:

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

  • сертификат должен контролироваться приложением до вызова модуля IKE вызовом ikeCheckCert

Поиск и проверка сертификата оппонента:
  • поиск и проверка осуществляется приложением ISAKMP на этапе создания SA

  • если сертификат оппонента не найден, приложение устанавливает вложение ISAKMP CERTREQ в соответствующей фазе обмена и должна получить сертификат в ответном сообщении

  • полученный сертификат должен быть проверен вызовом ikeCheckCert

  • проверка сертификата должна включать проверку всей цепочки сертификата

  • сертификат корневого центра сертификации (ЦС), на котором заканчивается цепочка проверяемого сертификата, должен храниться в хранилище "Root" (доверенные корневые центры сертификации)

Закрытый ключ используется функцией p1_AuthIRFn. Рекомендуется до вызова:

  • задать PIN для доступа к ключевому носителю функцией SetProvParam(PP_KEYEXCHANGE_PIN)

  • открыть контейнер в режиме CRYPT_SILENT для запрета интерактивного взаимодействия СКЗИ "КриптоПро CSP" с пользователем

Время жизни SA

Результатом проверки срока действия ключа и сертификат функцией ikeCheckCert или проверки PSK функцией getPSKnotAfterFn является срок окончания действия ключа или запланированый срок следующего обновления статуса сертифката по СОС (CRL) или OCSP. Согласно п. 4.4.2.1 RFC 4301 [ARCH] рекомендуется согласовывать время жизни SA, которая завершится ранее полученного срока. Согласованные времена жизни SA должны быть установлены вызовами p1_SetParamFn (...CPIKE_AC_Life_Duration...CPIKE_LIFET_SECONDS...) и p2_SetParamFn (...CPIPSEC_AT_Life_Duration...CPIPSEC_LIFET_SECONDS...).

Замечание

На ОС семейства Windows для проверки сертификата на отзыв по протоколу OCSP требуется установить Revocation Provider и клиент службы OCSP (являются дополнительными компонентами CSP 3.6.1).

На ОС семейства Linux проверка по протоколу OCSP должна быть реализована приложением самостоятельно