RFC: 4251
Оригинал: SSH Protocol Architecture
Категория: Предложенный стандарт
Дата публикации:
Авторы: ,
Перевод: Николай Малых

RFC 4251, Страница 17 из 29

9.3.3. Использование перехваченных данных (Replay)

Использование для MAC опций, отличных от "none", обеспечивает целостность данных и аутентификацию. В дополнение к этому транспортный протокол обеспечивает уникальный идентификатор сессии (связанный с псевдослучайными данными, которые являются частью алгоритма и процесса обмена ключами), который может использоваться протоколами вышележащего уровня для привязки данных к текущей сессии и предотвращения случаев воспроизведения данных, перехваченных из других сессий. Например, протокол аутентификации [SSH-USERAUTH] использует идентификатор сессии для предотвращения повторного использования сигнатур предыдущих сеансов. Поскольку обмен открытыми ключами криптографически связан с текущей сессией (т. е, начальным обменом ключами), перехваченные сигнатуры невозможно повторно использовать в других сессиях. Отметим, что идентификатор сессии можно делать открытым без снижения уровня безопасности протокола.

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

Детектирование попыток использования перехваченных данных с использованием монотонного роста порядковых номеров на входе MAC (или HMAC в некоторых случаях_ рассматривается в документах [RFC2085], [RFC2246], [RFC2743], [RFC1964], [RFC2025], [RFC4120]. Основа этих методов описана в документе [RFC2104]. Существенно, что различие порядковых номеров в каждом пакете гарантирует, что по крайней мере один аргумент (input) MAC-функции будет уникальным и обеспечит неповторяющийся результат MAC, который не может быть предсказан атакующим. Если сессия длится достаточно долго, порядковые номера могут начать повторяться. Такой повтор может дать атакующему возможность повторного использования ранее записанных пакетов с идентичными порядковыми номерами, но такая ситуация возможна только в тех случаях, когда партнеры не используют повторной генерации ключей до того, как начнется повтор порядковых номеров. Если партнеры выполнили регенерацию ключей, повторное использование пакетов будет обнаружено, поскольку проверка MAC даст отрицательный результат. По этой причине необходимо сделать упор на то, что партнеры должны выполнить регенерацию ключей до того, как начнется повтор порядковых номеров. Естественно, если атакующий будет пытаться повторно использовать собранные пакеты до того, как партнеры проведут регенерацию ключей, получатель дубликата не получит корректное значение MAC и пакет будет отброшен. Причина некорректности результата MAC в таких случаях обусловлена тем, что получатель будет создавать MAC на основе принятого пакета, разделяемого ключа (shared secret) и ожидаемого порядкового номера. Поскольку используемый повторно пакет не имеет ожидаемого порядкового номера (пакет с таким номером уже был принят получателем), рассчитанное значение MAC не будет соответствовать значению из принятого пакета.

Страница 17 из 29

2007 - 2022 © Русские переводы RFC, IETF, ISOC.