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

Служебные функции и модули.

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

Функции работы с памятью.

Наряду с системными функциями работы в моей программе были реализованы функции работы со структурой виртуального буфера BUFFER

typedef struct BUFFER {

uchar *buf;

int len;

int Len;

};

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

int MEMCPY (BUFFER* dst, int offset, uchar *src, int len)

{

uchar *tmp = NULL;

if(! dst) return ERR_BADPARAM;

if (offset + len > dst->Len) /* Проверка достаточности буфера*/

{

dst->Len = ((offset+len)/ALLOC_SIZE+1)*ALLOC_SIZE;

tmp = (uchar*) MALLOC (dst->Len); /* Занятие нового буфера */

if(! tmp) return ERR_NOMEMORY;

memcpy (tmp, dst->buf, dst->len);/*Копирование старого значения*/

FREE (dst->buf); /* Удаление старого буфера */

dst->buf = tmp;

}

dst->len = offset + len; /* Новая длина */

memcpy (dst->buf + offset, src, len); /* Копирование нового значения */

return 0;

}

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

Функции работы с сетью.

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

Функции криптоалгоритмов

В программе используются алгоритмы шифрования DES и Triple DES, алгоритмы хеширования MD5 и SHA1и алгоритмы с открытым ключом RSA и DSA. Реализация всех алгоритмов была взята извне. Исключение составляет только Triple DES, реализация которой основана на основе функций реализации DES.

void des_3cbc_encrypt (DESContext *ks1, DESContext *ks2,

DESContext *ks3, u_char *iv, u_char *dest, const u_char *src, u_long len)

{

word32 iv0, iv1, out[2], out1 [2], out2 [2];

u_long i;

iv0 = GET_32BIT(iv); /* Считывание значения IV */

iv1 = GET_32BIT (iv + 4);

for (i = 0; i < len; i += 8) /*Обработка в цикле по 8 байт */

{

iv0 ^= GET_32BIT (src + i);

iv1 ^= GET_32BIT (src + i + 4);

des_encrypt (iv0, iv1, out1, ks1, 1); /* Шифрование первым ключом */

des_encrypt (out1 [0], out1 [1], out2, ks2, 0); /* Расшифрование вторым*/

des_encrypt (out2 [0], out2 [1], out, ks3, 1); /* Шифрование третим */

iv0 = out[0];

iv1 = out[1];

PUT_32BIT (dest + i, iv0);

PUT_32BIT (dest + i + 4, iv1);

}

PUT_32BIT_DES (iv, iv0);

PUT_32BIT_DES (iv + 4, iv1);

}

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

Создание нитей и организации передачи данных между ними.

Нить создается стандартной функцией pthread_create.

#include

int pthread_create (pthread_t* thread_ID, const pthread_attr_t *attr,

void * (*start_func) (void *), void *arg);

Первый параметр в данной функции это некий дескриптор нити, с помощью которого создающий процесс (нить) может потом ею управлять. Третий параметр – имя функции, выполнением которой и займется новая нить. Как видно из описания функция имеет определенный формат. И последним параметром передается указатель на параметры, передаваемые этой нити при старте. В программе описано 5 функций для запуска нитей – работа с сетью, распределения пакетов, выполнения первой фазы, выполнения второй фазы (одна для New Group Mode и одна для Quick Mode). Первые две нити создаются при старте программы, остальные по мере надобности. Рассмотрим пример создания нити для первой фазы.

#define THREAD_T pthread_t

#define THREAD_SIMPLE_CREATE (start_func, arg, tid) \

pthread_create (tid, NULL, start_func, arg)

THREAD_T tid;

……………………….

Record = AddCookieRecord(); /* Добавление в таблицу нитей первой фазы */

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);