if (NULL == Record) return ERROR_MEMORY;

MEMCPY (Record->CookieI, buff, 8);

Record->Ready = 0;

BUFptr = (BUFFER*) MALLOC (sizeof(BUFFER)); /* Создание параметра */

if (NULL == BUFptr) return ERROR_MEMORY;

MEMINIT(BUFptr);

MEMADD (BUFptr, null, 1);

PUT_32BIT (addr_tmp, clientaddr.sin_addr.s_addr)/* Запись адреса партнера */

MEMADD (BUFptr, addr_tmp, 4);

PUT_16BIT (null, length);

MEMADD (BUFptr, null, 2);

MEMADD (BUFptr, buff, length); /* Запись длины пакета */

if (THREAD_SIMPLE_CREATE (WorkThread, (void*) BUFptr, &tid)) {

printf («Thread creation failed\n»);

return 1;

}

……………………….

После принятия решения о том, что для принятого пакета нужно создавать отдельную нить я сначала добавляю новую запись в таблицу нитей первой фазы. В эту запись заноситься Cookie Initiator и флаг Ready обнуляется как знак того, что первая фаза еще не закончена. После этого формируется массив, содержащий информацию необходимую для начала работы нити. В него входит IP адрес отославшего сообщение, длина пакета и собственно пакет. Указатель на виртуальный буфер, содержащий эту информацию, передается в качестве параметра в функцию нити. В самом начале работы каждая нить создает pipe, для того чтобы ей можно было передавать пакеты. Читающий дескриптор она оставляет у себя, а дескриптор для записи она записывает в таблицу нитей первой фазы (запись она находит, зная значение Cookie Initiator). Туда же записывается и значение Cookie Responder, после того как оно будет определено. Для нитей второй фазы процесс создания во многом похож, за исключением того, что в качестве параметра передается указатель на структуру state, которая содержит всю требуемую информацию (ключи шифрования, рабочие константы, адреса и т.п.). Процесс распределения дескрипторов pipe для связи остается таким же. Дескриптор записи в нить работы с сетью является глобальной переменной и доступен каждой нити.

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

Модули реализации протокола ISAKMP

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

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

Состояние, в свою очередь, состоит из следующих частей: анализ и проверка данных из пакета, проведение расчетов, составление данных для отсылаемого пакета и определение следующего состояния.

Анализ и проверка пришедших данных (часто называемый «семантическим разбором пакета») включает в себя в первую очередь анализ качественного состава пакета, т.е. проверяется все ли из необходимых в данном состоянии компонент присутствуют и нет ли лишних. Все эти проверки осуществляются при анализе переменной, содержащей флаги имеющихся компонент (то, как она определяется, описано в разделе, описывающем работу нити первой фазы). Затем проходит проверка пришедших данных. Для каждого компонента происходит своя проверка, которая может и отсутствовать, например, Nonce payload значение которого просто запоминается. Для SA payload проверка заключается в сравнении пришедшей политики с описанной в конфигурации для ответчика и в проверке правильности присланного ответа для инициатора. Для KE payload происходит проверка длины присланной ключевой информации согласно параметрам, присланным в политике. В Certificate и Certificate Request payloads проверяется тип используемых сертификатов (у меня в программе допустимы только x509 сертификаты). В Identification payload проверяется тип присылаемой информации (допускается только IP адреса) и собственно содержимое компонента. Компонент со значением хеш-функции (Hash payload) проверяется путем подсчета своего варианта и сравнения его с пришедшим значением. В примере приведена функция, вычисляющая значение хеш-функции противоположной стороны.

int CalculateAlienHash (State_t *state, BUFFER *Hash)

{

uchar save;

BUFFER DATA;

MEMINIT(&DATA); /* Инициализация буфера */

if(! ((state->SKEYID).len))

CalculateSKEYID(state); /* Подсчет SKEYID */

MEMADD (&DATA, &(state->AlienKE)); /* g^x (i/r) */

MEMADD (&DATA, &(state->MyKE)); /* g^x (i/r) */

if (GET_ROLE (state->State) == INITIATOR) {

MEMADD (&DATA, state->CookieR, 8);

MEMADD (&DATA, state->CookieI, 8);

} else {

MEMADD (&DATA, state->CookieI, 8);

MEMADD (&DATA, state->CookieR, 8);

}

MEMADD (&DATA, &(state->SAi_b));

MEMADD (&DATA, &((state->AlienIdent).Type), 1);

MEMADD (&DATA, (state->AlienIdent).DOI, 3);

MEMADD (&DATA, &((state->AlienIdent).Data));

if (GET_MODE (state->State) == DSA_SIGN) {

save = state->HashAlg;

state->HashAlg = HASH_ALG_SHA;

M (PRF(state, &(state->SKEYID), &DATA, Hash));

state->HashAlg = save;

} else

M (PRF(state, &(state->SKEYID), &DATA, Hash));

return 0;

}

Формулы, реализованные этой функцией, были представлены при описании фазы 1 (Main Mode). Следует заметить, что эта функция считает не значение инициатора или ответчика, а значение хеш-функции противоположной стороны. Внутри функции это достигается анализом переменной показывающей текущее состояние. Для проверки подписи (располагается в Signature payload) считается данное значение хеш-функции и подписывается требуемым алгоритмом. В приведенном примере есть еще один пример использования переменной состояния. DSA алгоритм может подписывать хеш только от алгоритма SHA. Специально для этого случая значение текущего алгоритма хеширования принудительно приравнивается значению алгоритму SHA. Следует заметить, что в процессе проверки может поменяться текущее значение состояния. Это может произойти при сравнении политик, когда партнеры договариваются о методе аутентификации

После проверки проводятся необходимые расчеты. Большинство формул для расчетов были приведены в разделе о первой фазе.

int CalculateSKEYID_d (State_t *state)

{

uchar z0 = 0;

BUFFER DATA;

MEMINIT(&DATA);

if(! ((state->SKEYID).len))

M (CalculateSKEYID(state));

MEMADD (&DATA, &(state->SharedKey));

MEMADD (&DATA, state->CookieI, 8);

MEMADD (&DATA, state->CookieR, 8);

MEMADD (&DATA, &z0, 1));

PRF (state, &(state->SKEYID), &DATA, &(state->SKEYID_d));

MEMZERO(&DATA);

return 0;

}

Выше приведен пример расчета одной из рабочих констант.

Рассмотрим пример одной из реализации функций состояния. Состояние возьмем для инициатора, режим - Aggressive Mode, пакет - приход ответа от ответчика.

………………………….

case STATE (INITIATOR, AGGRESSIVE, ABSENT, 1):

if (state. LastPacket & PAYLOAD_SA)

{

Log (PAYLOAD_MALFORMED, &state, NULL);

goto THREAD_END;

}

answer = ProvePolicy (&MyISAKMPPolicy, &(state. AlienPolicy), &state);

if (answer==ERR_NOPROPOSAL)

{

Log (PAYLOAD_MALFORMED, &state, NULL);

goto THREAD_END;

}

switch (state. AuthMeth)

{

case 1: SET_MODE (state. State, PRESHARED); break;

case 2: SET_MODE (state. State, DSA_SIGN); break;

case 3: SET_MODE (state. State, RSA_SIGN); break;

case 4: case 5:

default:

Log (NOT_SUPPORTED, &state, NULL);

goto THREAD_END;

}

ONE_MORE = 1;

break;

……………………….

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

case STATE (INITIATOR, AGGRESSIVE, PRESHARED, 1):

ERR (CheckHash(&state));

ERR (CalculateEncKeysPhase1 (&state));

ERR (MakeISAKMP(&state));

ERR (MakeHash(&state));

ERR (SendPacket(&state, 0));

NOT_END = 0;

break;

Приведенный набор действий будет выполнен, если в предыдущем примере партнеры договорились о методе аутентификации с помощью заранее известного секретного ключа. На данном примере видны все три составляющих состояния. Сначала проходит аутентификация ответчика путем проверки значения Hash payload. Затем производится расчет ключевой информации для первой фазы. Завершают все функции создания компонент пакета и отсылка самого пакета. Так как это последний пакет со стороны инициатора, то значение состояния не изменяется и выставляется флаг, говорящий об окончании фазы.

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

/* Инициализация нити */

while (NOT_END) {/* Проверка признака окончания работы */

if (GET_STEP (state. State)) /* Если это не первый пакет */

{

ERR (RecivePacket(&state)); /* Ожидание пакета */

ERR (DecryptPacket(&state)); /* Расшифрование пакета */

}

ONE_MORE = 1;

while (ONE_MORE) {/* Новый выбор без посылки пакета */

ONE_MORE = 0;

switch (state. State) {

case STATE (RESPONDER, AGGRESSIVE, ABSENT, 0):

Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9