Прошел экстерном экзамен по курсу перепордготовки "Информационная безопасность". Хочу получить диплом, но не вижу где оплатить? Ну и соответственно , как с получением бумажного документа? |
Безопасное сетевое взаимодействие (часть 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
Каждый поддерживаемый алгоритм должен быть в списке в соответствии с предпочтениями. Каждая строка должна содержать название, по крайней мере, одного алгоритма.
После получения SSH_MSG_KEXINIT пакета от другой стороны, каждый участник будет знать, правильно ли были сделаны предположения. Если каким-либо из участников были сделаны неправильные предположения, а последнее поле было true, то следующий пакет должен молча игнорироваться, и обе стороны должны затем выполнить повторный KEXINIT. Если предположения правильные, обмен ключа должен быть продолжен с использованием выбранного метода.
После обмена пакетом KEXINIT выполняется алгоритм обмена ключа. Он может включать обмен несколькими пакетами, как определено в конкретном методе обмена ключа.
Выход из обмена ключа
Обмен ключа создает два значения: разделяемый секрет K и хэш обмена Н. Ключи для шифрования и вычисления МАС получаются из этих значений. Хэш обмена Н из первого сообщения обмена ключа также используется как идентификатор сессии. Эти данные используются при аутентификации: они подписаны закрытым ключом сервера. После вычисления идентификатор сессии остается прежним, даже если ключи впоследствии изменяются.
Каждый метод обмена ключа должен определить хэш-функцию, которая используется для этого обмена ключа. Будем обозначать этот алгоритм HASH.
Ключи шифрования должны вычисляться как HASH некоторого известного значения и общего секрета K следующим образом:
- Инициализационный вектор при шифровании в направлении от клиента
к серверу:
HASH (K || "A" || session_id) ( "A" означает единственный символ ASCII A).
- Инициализационный вектор при шифровании в направлении от сервера
к клиенту:
HASH (K || "B" || session_id)
- Ключ шифрования в направлении от клиента к серверу:
HASH (K || "C" "" || session_id)
- Ключ шифрования в направлении от сервера к клиенту:
HASH (K || "D" || session_id)
- Ключ целостности в направлении от клиента к серверу:
HASH (K || "E" || session_id)
- Ключ целостности в направлении от сервера к клиенту:
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