Бездольный Алексей НГУ

Категория: Черновик
Ревизия 1 от 18-00 3 июля
Бездольный Алексей
НГУ
Июль 2004 года
Протокол безопасного соединения
1.Введение ..................................................................................................................................... 1
2.Обзор схемы работы протокола ............................................................................................... 1
3.Формат пакета ............................................................................................................................ 1
4.Установка соединения. .............................................................................................................. 2
5.Передача данных ........................................................................................................................ 2
6.Смена сессионного ключа. ........................................................................................................ 3
7. Разрыв соединения.................................................................................................................... 3
8. Алгоритмы шифрования и подписи. ....................................................................................... 3
1.Введение
Данный документ определяет спецификацию протокола безопасного обмена данными через
двунаправленное потоковое соединение. Протокол предназначен для использования в
системах, в которых для передачи данных используются посредники (proxy, port forwarding,
etc.) Обеспечивает идентификацию сторон, шифрование данных, целостность данных и их
порядок.
2.Обзор схемы работы протокола
Для обеспечения всех функций протокола заявленных ранее в протоколе используются
различные криптографические механизмы.
Аутентификация проходит посредством шифрованного обмена Диффи-Хелмана. Для работы
этого механизма обе стороны должны иметь некое общее секретное значение. Это значение
может быть не очень большим (>6 символов). Этим значением вполне может выступать
пароль, который в состояние запомнить пользователь.
Для обеспечения целостности и сохранности данных используются механизмы электронноцифровой подписи и шифрования.
Т.к. в момент аутентификации создаются сессионные ключи, раскрытие в последствие
пароля не приведет к раскрытию данных. И наоборот полное раскрытие данных
аутентификации и сессии не приводит к раскрытию пароля. Следовательно, протокол
обладает одним очень хорошим свойством «Perfect forward secrecy».
3.Формат пакета
Каждый пакет, передаваемый в течение сессий или процесса аутентификации, имеет
одинаковую структуру. Эта структура делится на три части:
 Заголовок: Тип пакета, номера пакета, длина пакета.
 Данные: Содержимое поле определяется типом пакета, в большинстве случаев
содержатся данные, передаваемые через протокол.
 Хвост: подпись всего пакета.
Все поля заголовка и хвоста передаются в Network byte order. Это же относится к полям,
передаваемым в части данных управляющих пакетов.
------------------------------------------------------------------------¬
¦01234567|01234567|01234567|01234567|01234567|01234567|01234567|01234567¦
+--------T-----------------T-----------------T-----------------T--------+
¦ PType ¦
OutCounter
¦
InCounter
¦
Length
¦Reserved¦
¦
¦
¦
¦
¦
¦
+--------+-----------------+-----------------+-----------------+--------+
¦
¦
¦
DATA
¦
¦
¦
¦~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~¦
¦
¦
¦
¦
¦--------------------------- keyed HASH SUM ----------------------------¦
¦
¦
¦
¦
L------------------------------------------------------------------------
PType - 8 бит.
OutCounter - 16 бит. Порядковый номер исходящего пакета.
InCounter - 16 бит. Порядковый номер последнего полученного пакета.
Length - 16 бит. Общая длина DATA.
Keyed Hash - 128 бит. Поле подписи пакета.
Data - Данные. Длинна, структура и назначение зависит от типа пакета.
Reserved - 8 бит. Должно содержать нулевое значение.
4.Установка соединения.
Для установки соединения инициатор отсылает пакет типа 0x0, в данных которого
содержится:
Login - Строка с завершающим нулем.
RND – случайное 32 битное число.
DhPubKey - 1024 битный публичный ключ Диффи-Хелмана.
Этот пакет не подписывается. Поле данных шифруется, начиная с поля RND. Для ключа
шифрования берется общее секретное значение (пароль), вектор инициализации нулевой
блок шифрования. Поля счетчиков из заголовка пакета обязаны содержать нулевые
значения.
Если другая сторона принимает соединение, то она отвечает пакетом типа 0x1 в данных,
которого содержится:
RND - 32 битное число равно RND из пакета 0x0 плюс 1.
DhPubKey - 1024 битный публичный ключ Диффи-Хелмана.
Перед отправкой эта сторона может подсчитать общее значение по алгоритму ДиффиХелмана. Из этого значения составляются ключ подписи, вектор инициализации
шифрования, ключ шифрования. Эти ключи берутся из полученного общего числа в
перечисленном порядке. Если числа по длине не достаточно, то оно повторяется нужное
количество раз. Подсчитав сессионные ключи, пакет 0x1 подписывается и шифруется как
обычный пакета данных.
Инициатор соединения по получение пакета 0x1 так же подсчитывает сессионные ключи и
проверяет подпись. Если подпись не верна, то инициатор обязан разорвать соединение. Если
пакет корректен, то инициатор обязан незамедлительно отправить пакет данных (может
быть с данными нулевой длины). Сервер не может первым начинать передачу данных.
5.Передача данных
Данные передаются в пакетах типа 0x4. При этом от пакета сначала считается подпись, а
потом данные пакета шифруются.
6.Смена сессионного ключа.
Для улучшения стойкости шифрования лучше как можно чаще менять ключ сессии. Смену
ключа необходимо произвести тогда, когда происходит переполнение счетчика пакетов. То
есть пакет смены ключа пойдет с номером 65535. Но также смену ключа можно произвести
когда угодно. Инициатор смены ключа отсылает пакет типа 0x2, в данных которого
содержится публичный ключ Диффи-Хелмана, длинной 1024 бита. Другая сторона должна
сразу отослать пакет подтверждения смены ключа типа 0x3, в котором тоже содержится
публичный ключ Диффи-Хелмана. После отправки этих пакетов стороны сбрасывают
счетчики, следующие пакеты будут иметь номер один. Пакеты 0x2 и 0x3 подписываются и
шифруются как обычные пакеты данных.
7. Разрыв соединения.
Для разрыва соединения достаточно передать пакет типа 0x5. Сторона соединения,
получившая такой пакет, обязана разорвать соединение.
8. Алгоритмы шифрования и подписи.
Для подписи пакетов используется алгоритм HMAC-MD5 [rfc 2104]. Для шифрования
используется DES-EDE2. [http://www.weidai.com/scan-mirror/cs.html#DESede]. Из
стандартной реализации убирается первые 8 байт, которые использовались как вектор
инициализации. И были хешем от времени и ключа.