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 считывает установленные значения параметров.

Метод GOST-IKE-PSK

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

Аутентификация в режиме GOST-IKE-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_SetPSK p1_Agree	<==	p1_Setup p1_SetPSK p1_Agree	HDR,KE_r,Nr
HDR*,IDii,HASH_I	p1_AuthIR(I) p1_Encap	==>	p1_Decap p1_AuthIR(R) p1_VerifyIR(I)
	p1_Decap p1_VerifyIR(R)	<==	p1_Encap	HDR*,IDir,HASH_R

Метод GOST-IKE-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)

Метод GOST-IKE-SIGNATURE

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

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

Обмен данными при аутентификации в фазе 1 IKE/ГОСТ режима GOST-IKE-SIGNATURE Main Mode производится по варианту, обеспечивающему защиту идентификационных параметров Инициатора и Респондера с учётом моделей нарушителя "Пассивный наблюдатель" и "Ложный Инициатор".

Таблица 3

Initiator	Вызываемые функции	Направление передачи	Вызываемые функции	Responder
HDR,SA	p1_Create p1_SetParam	==> <==	p1_Create p1_SetParam	HDR,SA
HDR,KE,Ni,[CERTREQ]	p1_Setup	==>
	p1_Agree	<==	p1_Setup p1_Agree	HDR,KE,Nr,[CERTREQ]
HDR*,IDii,[CERT],SIG_I	p1_SetMyCertProv* p1_AuthIR(I) p1_Encap	==>	p1_Decap p1_SetMyCertProv p1_AuthIR(R) p1_SetOtherCert p1_VerifyIR(I)
	p1_Decap p1_SetOtherCert p1_p1_VerifyIR(R)	<==	p1_Encap	HDR*,IDir,[CERT],SIG_R

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

Метод GOST-IKE-SIGNATURE

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

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

Таблица 4

Initiator	Вызываемые функции	Направление передачи	Вызываемые функции	Responder
HDR,SA,KE_i,Ni,[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*,IDii,[CERT],SIG_I	p1_SetMyCertProv* p1_AuthIR(I) p1_Encap	==>	p1_Decap p1_SetOtherCert p1_VerifyIR(I)

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

Метод GOST-IKE-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]

Метод GOST-IKE-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)

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

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

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

Фаза 2 IKE/ГОСТ обмена ISAKMP включает режим Quick Mode, New Group Mode и Informational Mode. Сессия фазы 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 производится по схеме:

Таблица 7

Initiator	Вызываемые функции	Направление передачи	Вызываемые функции	Responder
HDR*,HASH(1),SA0,[SA1,...]Ni,[KE_i,][IDci,IDcr]	p2_Create(M_ID,CERT_R) p2_SetParam p2_Setup p2_HashAFn(HASH(1)) p2_Encap	==>	p2_Create(M_ID,CERT_I) 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.

Режим "Новая группа параметров"

Режим "Новая группа параметров" не должен использоваться до установления ISAKMP SA. Определение новой группы параметров должно следовать за обменом фазы1, но не является обменом фазы 2, (M-ID отличен от 0).

Таблица 8

Initiator	Вызываемые функции	Направление передачи	Вызываемые функции	Responder
HDR*,HASH(1),SA	p2_Create(M_ID,CERT_R) HashA p2_Encap	==>	p2_Create(M_ID,CERT_I) p2_Decap VerifyA
	p2_Decap VerifyA	<==	HashA p2_Encap	HDR*,HASH(2),SA

Аутентичность сообщения обеспечивается передачей HASH(1) и HASH(2).

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

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

Таблица 9

Initiator	Вызываемые функции	Направление передачи	Вызываемые функции	Responder
HDR*,HASH(1),N/D	p2_Create(M_ID,CERT_R) HashA p2_Encap	==>	p2_Create(M_ID,CERT_I) p2_Decap VerifyA

где

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

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

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

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

Приложение ISAKMP должно представить библиотеке libike_gost ключ компьютера (ключ администратора безопасности компьютера) и ключ аутентификации пользователя. Эти ключи могут быть представлены либо в форме PSK либо в форме ключевого контейнера КриптоПро CSP-3.6. Ключи в форме PSK устанавливаются вызовами CreatePSKFn, p1_SetPSKFn для ключа компьютера и ключа пользователя соответственно. Ключи в форме ключевого контейнера КриптоПро CSP-3.6 устанавливаются вызовами 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...).

---

(C) "КРИПТО-ПРО" 2005-2011. Все права сохранены