#define INITIATOR 0x0

#define RESPONDER 0x80

#define MAIN 0x0

#define AGGRESSIVE 0x40

#define ABSENT 0x0 /* Метод аутентификации еще не определен*/

#define PRESHARED 0x8

#define DSA_SIGN 0x10

#define RSA_SIGN 0x18

#define RSA_ENC 0x20

#define RSA_REV_ENC 0x28

#define RENCRYPT 0x30

#define GET_ROLE(State) (State&0x80)

#define GET_EXCH(State) (State&0x40)

#define GET_MODE(State) (State&0x38)

#define GET_STEP(State) (State&0x03)

#define SET_ROLE (State, Role) {State &= 0x80; State+=Role;}

#define SET_MODE (State, Meth) {State &= 0xC7; State+=Meth;}

#define SET_EXCH (State, Meth) {State &= 0xBF; State+=Meth;}

#define STATE (role, exch_type, mode, step) (role+exch_type+mode+step)

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

/*Получение о предварительная обработка пакета*/

switch (state. State) /* Выбор набора требуемых функций */

{

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

/* Набор функций для данного состояния */

break;

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

/* Набор функций для данного состояния */

break;

………………………

case STATE (INITIATOR, MAIN, DSA_SIGN, 2):

/* Набор функций для данного состояния */

break;

}

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

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

Нить выполнения второй фазы. Задача данной нити – проведение второй фазы установления соединения. Структура и принцип работы полностью такие же, как и в нити первой фазы. При создании вместе с пакетом нити передаются также значения некоторых переменных (рабочие константы, ключи шифрования и т.п.) необходимые для нормальной работоспособности нити. По завершению второй фазы нить выдает полученные результаты, удаляет себя из таблицы нитей второй фазы и заканчивает работу.

Таблицы поиска нитей

Таблица нитей выполняющих первую фазу представляет собой список CookieTable_t структур

struct CookieTable_t;

typedef struct CookieTable_t {

uchar CookieI[8]; /*Initiator Cookie */

uchar CookieR[8]; /* Responder Cookie */

int pd; /* Pipe Descriptor */

uchar Ready; /* Ready Flag */

struct in_addr AlienAddr; /* Peer IP Address */

struct CookieTable_t *next; /* Next Member (NULL if last) */

};

Необъясненными в данной структуре остались два поля: флаг Ready и структура IP адреса. В структуре IP адреса находится адрес партнера, с которым мы ведем процесс установления соединения. Флаг Ready показывает, закончилось или нет проведение первой фазы. Он используется, если со стороны модуля управления пришло 2 запроса на инициацию попытки установления соединения. В этом случае просматривается таблица нитей первой фазы в поисках записи с указанным IP адресом. Если флаг Ready в данной записи говорит о том, что первая фаза уже завершена, то запрос формируется на проведение сразу второй фазы. IP адрес может также использоваться при поиске нити для пришедшего пакета.

Ниже приведен пример функции поиска записи в таблице по совпадению и CookieI и CookieR.

CookieTable_t *FindCookieRecord (uchar *CI, uchar *CR) {

uchar Test[8] = {0, 0, 0, 0, 0, 0, 0, 0};

struct CookieTable_t *ptr = CookieTable;

while(ptr) {

if (MEMCMP(CI, ptr->CookieI, 8) ||

(MEMCMP (Test, ptr->CookieR, 8)&&MEMCMP (CR, ptr->CookieR, 8)))

ptr = ptr->next;

else

return ptr;

}

return NULL;

}

Таблица нитей второй фазы тоже представляет собой список структур.

struct Phase2Table_t;

typedef struct Phase2Table_t {

uchar MessageID[4]; /* Message ID */

int pd; /* Pipe Descriptor */

struct SPIlist_t SPIlist; /* List of SPIs */

struct Phase2Table_t next; /* Next Member (NULL if last) */

};

Метод работы со списками Phase2Table_t аналогичен вышеприведенному примеру.

Входные и выходные данные

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

typedef struct Proposal_t {

uchar ProposalN; /* Номер Proposal */

uchar ProtocolID; /* Номер протокола */

NewGroup_t *NewGroup;

uchar NTransforms;

Proposal_t *nextPor;

Proposal_t *nextPand;

Transform_t *nextT;

};

Структура Proposal_t описывает Proposal payload, входящий в состав SA payload. Данная структура содержит все поля необходимые для создания и заполнения данного компонента пакета. Полями структуры являются номер компонента (ProposalN), идентификатор протокола, представляемого этим компонентом (ProtocolID), указатель на структуру содержащую параметры для New Group Mode (если он равен NULL, данные режим не нужен), количество Transform payload. Для связи между собой в данных структурах предусмотрено два указателя – указывающий на следующую структуру объединенную по «И» (nextPand), и указывающий на первую структуру следующей группы, объединенной по ИЛИ (nextPor). Также есть указатель на список соответствующих Transform payload структур.

typedef struct Transform_t {

uchar TransformN;

uchar TransformID;

Transform_t *nextT;

Attributes_t *nextA;

};

Структура содержит номер структуры в данном списке, идентификатор представляемого алгоритма, указатель на следующий элемент (напомним, что список одномерный) и указатель на принадлежащий Transform payload список атрибутов.

typedef struct Attributes_t {

uint type;

ushort SmallVal;

BUFFER BigVal;

Attributes_t *nextA;

};

Для атрибутов различают два представления – короткое и длинное. При коротком представлении значение атрибута не превышает 65535 (2 байта), а при длинном задается длина и буфер, содержащий значение атрибута. То, в каком представлении задан (прислан) атрибут определяется первым битом поля type. Если он выставлен, то представление короткое. Остальные биты поля type показывают, какой это именно атрибут (длина ключа, метод аутентификации и т.п.). Поля SmallVal и BigVal предназначены для хранения значения атрибута при соответственно коротком и длинном представлении. Для каждого типа атрибута определено его представление. Если атрибут считается длинным, то допускается его представление в коротком формате (если значение умещается в 2 байта). Но обратное утверждение не верно – короткий атрибут всегда остается коротким.

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

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

Алгоритм обработки входящего пакета

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

При решении первой задачи рассматриваются два признака, по которым пакеты проверяются. Первый – значение поля Initiator Cookie. Это поле ни в одном пакете не может быть нулевым. Второй пункт при проверке это длина пакета. Т.к. ее значение передается в ISAKMP заголовке, а он никогда не шифруется, то для каждого пакета мы можем узнать заявленную длину и сравнить с длиной реальной. Вторая задача решается на основе значений полей CookieI и CookieR путем поиска требуемой нити в таблице нитей первой фазы. Способ решения данных задач была подробнее рассмотрена при описании нити распределения пакета, поэтому в данном разделе будет объяснен алгоритм разбора пакета на его компоненты (payload).

Данный заголовок стоит в начале каждого компонента и служит для связывания компонент в список. Первым полем в нем указан тип следующего компонента (тип первого компонента указывается в соответствующем поле ISAKMP заголовка). У последнего компонента данное поле должно быть равно нулю. Второй байт в заголовке является зарезервированным для будущего использования и должен равняться нулю. Последние два байта содержат длину компонента вместе с общим заголовком.

Далее будет рассмотрена функция CheckPacket, которая осуществляет проверку структуры списка компонент.

int CheckPacket (State_t *state)

{

int next = state->FirstPayload, Length = ISAKMP_HEADER_SIZE;

state->LastPacket = 0;

state->ptr = state->Packet.buf + ISAKMP_HEADER_SIZE;

do

{

if (state->ptr[1]!= 0) return ERROR /*Поле RESERVED не ноль*/

Length += GET_16BIT (state->ptr+2);

if (Length > state->Packet.len) return ERROR

/* Вышли за пределы пакета */

switch(next)

{

case 1: if (CheckSA(state) < 0) return ERROR;

state->LastPacket |= PAYLOAD_SA;

break;

case 4: if (CheckKE(state) < 0) return ERROR;

state->LastPacket |= PAYLOAD_KEY;

break;

………………………………………….

case 13: if (CheckVendor(state) < 0) return ERROR;

state->LastPacket |= PAYLOAD_VENDOR;

break;

default:

return ERROR;

break;

}

next = state->ptr[0]

state->ptr += GET_16BIT (state->ptr+2);

} while(next);

return 0;

}

В функцию в качестве параметра передается структура state, которая содержит всю информацию, относящуюся к данной нити. В данном случае нам потребовалось значение типа первого компонента state->FirstPayload (оно было получено при разборе ISAKMP заголовка), указатель на буфер, содержащий пришедший пакет и длина пакета. Т.к. ISAKMP заголовок уже был разобран, временный указатель смещен на начало первого компонента. Затем начинается цикл по всем компонентам. Сначала проверяется правильность общего заголовка. Для этого проверяем равенство нулю зарезервированного поля. Длину компонента добавляем к сумматору общей длины пакета (Length) и проверяем, что заявленная длина компонент не больше длины самого пакета. Затем стоит оператор выбора (case), который анализирует значение типа заголовка. Этим выполняется проверка правильности типа компонента, и если тип оказывается неизвестным (или неподдерживаемым), то программа заканчивается с ошибкой. Для каждого известного компонента сначала происходит проверка правильности структуры компонента. Это обусловлено наличием в некоторых из них зарезервированных полей, а также тем, что некоторые из них содержат в себе другие компоненты (SA payload). После проверки выставляется флаг наличия данного компонента в пакете. Данные флаги будут необходимы при семантическом анализе пакета. Следующим действием мы присваиваем переменной содержащей тип следующего компонента новое значение и передвигаем указатель на начало следующего компонента. Выход из данного цикла осуществляется по нулевому значению поля общего заголовка Next payload. Гарантией того, что процесс проверки вообще когда-нибудь кончиться служит проверка того, что длина разбираемых компонент меньше длины пакета. Нормальный выход из цикла означает правильную структуру пакета.

Написание программы и проведение тестирования