Опубликован: 26.01.2005 | Уровень: специалист | Доступ: платный | ВУЗ: Московский государственный университет имени М.В.Ломоносова
Лекция 10:

Безопасное сетевое взаимодействие (часть 3)

Обмен ключа

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

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

Переговоры об алгоритме

Обмен ключа начинается каждой стороной с посылки следующего пакета:

SSH_MSG_KEXINIT
cookie (random bytes)
kex_algorithms
server_host_key_algoritms
encryption_algorithms_client_to_server
encryption_algorithms_server_to_client
mac_algorithms_client_to_server
mac_algorithms_ server _to_client
compression_algorithms_client_to_server
compression_algorithms_ server _to_client
languages_client_to_server
languages_ server _to_client
first_kex_packet_follows
Таблица 22.2. Параметры переговоров
Cookie Должно быть случайным числом, созданным отправителем. Цель создания этого cookie следующая: сделать так, чтобы ни одна из сторон не могла полностью определить ключи и идентификатор сессии
Kex_algorithms

Алгоритмы обмена ключей, которые были определены выше. Первым алгоритмом должен быть самый предпочтительный. Если обе стороны сделают один и тот же выбор, то этот алгоритм и должен использоваться. В противном случае следующий алгоритм должен применяться для выбора метода обмена ключа: повторять по каждому kex алгоритму клиента. Выбрать первый алгоритм, который удовлетворяет следующим условиям:

  • сервер также поддерживает данный алгоритм;
  • если алгоритм требует шифрования ключом сервера, существует алгоритм шифрования у серверной части server_host_key_algorithms, который также поддерживается клиентом;
  • если алгоритм требует подписи ключом сервера, существует алгоритм подписи у серверной части server_host_key_algoritms, который также поддерживается клиентом;
  • если нет алгоритма, который удовлетворяет всем этим условиям, соединение прерывается.
Server_host_key_algoritms

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

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

Encryption_algorithms

Список возможных алгоритмов симметричного шифрования в порядке предпочтения. Выбранный алгоритм шифрования для каждого направления должен быть первым алгоритмом в списке клиента, и также находиться в списке алгоритмов сервера. Если такого алгоритма нет, то стороны должны разорвать соединение.

"none" должно быть явно указано в списке, если это принимается

Mac_algorithms

Список возможных МАС-алгоритмов в порядке предпочтения. Выбранный алгоритм МАС должен быть первым в списке клиента, а также существовать в списке сервера. Если такого алгоритма нет, стороны должны разорвать соединение.

"none" должно быть явно указано в списке, если это принимаемо.

Compression_algorithms

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

"none" должно быть явно указано в списке, если это принимается

Languages Список тегов языков в порядке предпочтения в соответствии с RFC-1766. Оба участника могут игнорировать этот список. Если нет предпочтений по языку, список должен быть пустым
First_kex_packet_follows Признак того, что следующим пакетом будет обмен ключа. Если пакет с обменом ключа будет послан, значение должно быть true. Если нет, то значение должно быть false.

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

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

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

Выход из обмена ключа

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

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

Ключи шифрования должны вычисляться как HASH некоторого известного значения и общего секрета K следующим образом:

  1. Инициализационный вектор при шифровании в направлении от клиента к серверу:

    HASH (K || "A" || session_id) ( "A" означает единственный символ ASCII A).

  2. Инициализационный вектор при шифровании в направлении от сервера к клиенту:

    HASH (K || "B" || session_id)

  3. Ключ шифрования в направлении от клиента к серверу:

    HASH (K || "C" "" || session_id)

  4. Ключ шифрования в направлении от сервера к клиенту:

    HASH (K || "D" || session_id)

  5. Ключ целостности в направлении от клиента к серверу:

    HASH (K || "E" || session_id)

  6. Ключ целостности в направлении от сервера к клиенту:

    HASH (K || "F" || session_id)

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

K1 = HASH (K || X || session_id)
    (например, в первом случае Х есть "A")
K2 = HASH (K || K1) K3 = HASH (K || K1 || K2) и т.д.
Принятие ключей в использование

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

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

SSH_MSG_NEWKEYS
Евгений Виноградов
Евгений Виноградов

Прошел экстерном экзамен по курсу перепордготовки "Информационная безопасность". Хочу получить диплом, но не вижу где оплатить? Ну и соответственно , как с получением бумажного документа?

Илья Сидоркин
Илья Сидоркин

Добрый день! Подскажите пожалуйста как и когда получить диплом, после сдичи и оплаты?????