};

Метод работы со списками 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. Гарантией того, что процесс проверки вообще когда-нибудь кончиться служит проверка того, что длина разбираемых компонент меньше длины пакета. Нормальный выход из цикла означает правильную структуру пакета.

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

В данном разделе будет описан процесс написания и тестирования отдельных функций и модулей. При написании программы, реализующей протокол 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 <pthread.h>

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

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

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

FreePolicy (state. AlienPolicy);

ERR (CheckPacket(&state));

ONE_MORE = 1;

break;

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

…….

state. State++; /* Следующий номер пакета */

break;

……………….

} /* switch */

} /* while (ONE_MORE) */

} /* while (NOT_END)

/* Действия выполняемые в конце нити */

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

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

Тестирование с другими реализациями протокола ISAKMP

Во время написания и отладки моей программы, внешней реализацией для тестирования был выбран сайт www.ssh.fi, содержащий свою реализацию данного протокола. Данный сервер имеет хорошо разветвленную систему настроек политики чужой стороны, что позволяет определять посылаемый мне SA payload с точностью до атрибутов (что очень помогло при тестировании выбора приемлемых атрибутов). Также на сервере хорошо реализована система показа процесса работы программы. Расчет каждой величины предваряется перечислением входных данных и используемых алгоритмов. Это очень помогает при поиске ошибок, связанных с неправильным вычислением констант или неправильном использовании алгоритмов, когда видно, что входные данные те же, а результат другой.

Отладка с данной реализацией проводилась методом описанном в предыдущем разделе. Т.е. после каждого созданного состояния проводилось тестирование при разных входных данных.

Заключение

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

Технология реализации протокола ISAKMP

Исходя из технического задания, данная реализация протокола ISAKMP должна содержать 4 обмена (Main Mode, Aggressive Mode, New Group Mode и Quick Mode) и должна поддерживать 4 метода аутентификации (методом заранее известного секретного ключа, цифровой подписью с помощью алгоритмов DSS и RSA, шифрования открытым ключом с помощью алгоритма RSA). Весь процесс написания программы можно разбить на 6 частей:

Подготовительная часть

Реализация Main mode с методом аутентификации заранее известного секретного ключа

Реализация Quick Mode

Реализация остальных методов аутентификации для Main Mode

Реализация Aggressive Mode со всеми методами аутентификации

Реализация New Group Mode

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

Подготовительная часть

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

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

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

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

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

Лог. Включает в себя функции инициализации и записи в лог-файл. Функция записи пишется с расчетом на много нитевую программу.

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

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

Проверка структуры пакета. Протокол ISAKMP четко определяет структуру пакетов. Тестирование осуществляется путем ручного задания правильно и неправильно сформированных пакетов.

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

Реализация Main mode c методом аутентификации заранее известного секретного ключа

Main mode состоит из 6-и посылок пакетов - 3 от каждой из сторон (инициатора и ответчика). Также здесь реализуется прием задания для стороны инициатора.

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

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

Порядок реализации данного этапа следующий:

Получение задания на установление соединения со стороны инициатора, проверка необходимости проведения первой фазы (возможно для данного партнера ISAKMP SA уже создана и тогда сразу переходим ко второй фазе);

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

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

Прием и разбор второго пакета инициатором. Проверка корректности выбранной политики. Получение секретного и отрытого ключей для алгоритма Diffie-Hellman с параметрами, оговоренными в политике. Составление и отсылка третьего пакета, содержащего свой открытый ключ и Nonce - случайную последовательность для данного соединения;

Прием и разбор третьего пакета ответчиком. Сохранение Nonce и открытого ключа инициатора, вычисление своей пары Diffie-Hellman ключей. Составление и отсылка четвертого пакета, содержащего открытый ключ и Nonce ответчика;

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

Прием пятого пакета ответчиком. Вычисление общего ключа для алгоритма Diffie-Hellman. Вычисление ключей шифрования. Расшифровка пакета и его разбор. Проверка идентифицирующей информации инициатора. Вычисление аутентифицирующей инициатора информации и сравнение со значением находящимся в пакете. Вычисление информации идентифицирующей и аутентифицирующей ответчика. Составление, шифрование и отсылка шестого пакета;

Прием шестого пакета инициатором. Расшифровка пакета и проверка информации идентифицирующей и аутентифицирующей ответчика.

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

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

После написания всех трех обменов происходит тестирования Main mode в целом. Сначала тестируется работа двух реализаций программы в роли и инициатора и ответчика. Затем тестируется совместимость с другими реализациями протокола (в процессе разработки для тестирования совместимости использовался сервер www.ssh.fi). Тестирование включает в себе проведение одиночного соединения и сразу нескольких (причем каждая из сторон в разных соединениях играет разную роль), проведение удачных и неудачных соединений. Также в процессе тестирования проверяется одинаковая работа программы на разных процессорах (Sun Sparc и Intel x86).

Реализация Quick mode

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

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

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

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

Прием инициатором второго пакета. Расшифрование пакета и проверка целостности. Проверка корректности выбранного варианта политики. Вычисление значения хеш-функции от Nonce-ов. Составление третьего пакета, его шифрование и отсылка ответчику. Вычисление выходных результатов.

Прием ответчиком третьего пакета. Расшифровка пакета, вычисление значения хеш-функции от Nonce-ов и сравнение с присланным значением. Вычисление выходных результатов.

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

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

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

Реализация остальных методов аутентификации для Main mode

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

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

Порядок реализации данного этапа следующий:

Реализация ветвления по разным методам аутентификации в зависимости от договоренной политики;

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

Реализация метода аутентификации шифрованием открытым ключом алгоритмом RSA. Сертификаты для расшифрования также задаются явно.

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

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

Реализация Aggressive mode со всеми методами аутентификации

На этом этапе реализуется другой режим для проведения первой фазы. От Main mode его отличает меньшее количество посылаемых пакетов, но вместе с этим большее количество информации передаваемых в пакетах и большая трудоемкость при их обработке. Реально данный режим реализуется на основе кода написанного для Main mode путем перестановки основных функций, но при этом надо помнить, что простая перестановка не поможет и требуется некий дополнительный анализ. Например, в политике, передаваемой инициатором, не может быть предложен выбор между различными Oakley группами, т. к. в этом же пакете посылается публичный ключ однозначно определяющий группу. Все подобные проверки должны проводиться для Aggressive Mode.

Порядок реализации этапа следующий:

Реализация ветвления между Main и Aggressive режимами. Для инициатора вид режима определяется конфигурацией. Ответчик проверяет приемлемость предложенного режима, также основываясь на конфигурации и, в случае не приемлемого значения, может отказаться продолжать обмены. Инициатор должен в этом случае уметь предложить другой режим, конечно, если это позволяет реализация.

Реализация метода аутентификации заранее известного секретного ключа. После реализации проводят тесты, проводимые на втором этапе, но с использованием Aggressive mode.

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

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

Реализация New Group Mode

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

Порядок реализации этапа следующий:

Реализация со стороны инициатора ответвления на New Group mode в зависимости от конфигурации. Должна быть предусмотрена проверка существования уже созданной нестандартной Oakley группы.

Создания инициатором пакета содержащего информацию о предлагаемой группе, подсчет значения хеш-функции от этого пакета, шифрования пакета (с помощью алгоритмов и ключей из ISAKMP SA) и отсылка пакета;

Получение пакета, его расшифровка и проверка целостности. Проверка приемлемости предлагаемой группы. Составление ответного пакета, подсчет значения хеш-функции, шифрование и отсылка этого пакета. Сохранение информации о группе для второй фазы;

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

Реализация использования во время второй фазы групп, о которых договаривались во время New Group mode.

При тестировании проверяется правильная работа в New Group mode и инициатора, и ответчика. Особое внимание стоит уделить правильной работе программы при попытке договориться о нескольких Oakley группах.

В данном разделе был рассмотрен порядок реализации протокола ISAKMP, предложен вариант разбиения общей задачи на подзадачи, даны рекомендации по организации работ над этими задачами и предложен порядок проведения тестов.

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

Сегментация рынка пользователей программы, реализующей протокол ISAKMP

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

При разумном делении рынка на сегменты все инструменты маркетинга внутри него могут быть оптимально скоординированы. Именно поэтому сегментация рынка считается очень важным аспектом деятельности предприятия.

Методика расчёта сегментации рынка

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

Для дальнейшего деления рынка на сегменты можно воспользоваться различными критериями в зависимости от следующих факторов:

географического положения потребителей (регион, страна);

типа потребителя (величина предприятия, интенсивность потребления, отрасль, место в производственном процессе);

типа процесса, для которого приобретается продукция (административная деятельность, движение товара, производственный процесс);

покупательского спроса (клиент / потенциальный клиент, связь с поставщиком, частота и величина закупок);

На рынках сбыта товаров широкого потребления используют другие критерии. Классическими являются следующие показатели:

социально-экономические (образования, доходы);

демографические (возраст, пол, состав семьи);

географические

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

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

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

Таблица 1. Неупорядоченная диаграмма Чекановского

Номера единиц	1	2	…
1	X			X
2			X
…	…	…	…	…
w				X

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

Поиск сегментов рынка для программы установки защищенных сетевых соединений с помощью протокола ISAKMP