RFC: 3562
Оригинал: Key Management Considerations for the TCP MD5 Signature Option
Категория: Информационный
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 3562, Страница 3 из 4

3. Время жизни ключей

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

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

3. Энтропия ключей

Если мы предположим, что интервал замены ключей составляет 90 дней а разумное значение верхней границы производительности программных атак составляет 1.0*e13 операций MD5 в секунду, минимальная допустимая энтропия ключей составит приблизительно 68 битов. Разумно округлить это значение до 80 битов (10 байтов). Если предполагается возможность аппаратных атак с использованием оборудования типа EFF но с бюджетом небольшой страны, минимальный размер ключа увеличится примерно до 83 битов или 11 байтов. Поскольку число 11 достаточно неудобно, будет разумным округлить размер ключа до 12 байтов.

Для достижения достаточно большой энтропии с ключами на основе английского языка следует помнить, что энтропия этого языка составляет приблизительно 1,3 бита/символ. Другие языки человеческого общения имеют близки значения энтропии. Это означает, что ключи, полученные из языка человеческого общения, должны иметь размер приблизительно 61 байт для созданий энтропии в 80 битов и 73 байта для энтропии в 96 битов.

В документе [RFC1750] описываются более подходящие методы получения высококачественных случайных ключей размером 96 и более битов.

Ранее было отмечено, что атакующий скорей всего будет пытаться использовать для организации атаки короткие пакеты, поскольку в этом случае повышается производительность подбора ключей. Было также отмечено, что операции MD5 в таких случаях будут выполняться для блоков размером 64 байта. Принимая во внимание, что пакет будет включать 40 байтов заголовков IP и TCP, оставшиеся 24 байта блока MD5 могут использоваться в качестве ключа (keying material) без увеличения нагрузки на процессор маршрутизатора, но со значительным ростом нагрузки на атакующего. Хотя такой подход будет увеличивать нагрузку на CPU для случая обычных коротких пакетов BGP (поскольку это будет заставлять расчет MD5 переходить во второй блок MD5) в настоящее время это не представляется существенным увеличением нагрузки на машину маршрутизации BGP.

На практике наиболее разумно выбрать наибольший возможный ключ, размер которого меньше 25 байтов, но не менее 12 байтов.

Некоторые реализации ограничивают набор ключей строками символов ASCII (подобно простым паролям) размером 8 байтов или меньше. Это создает реальный риск подбора ключа в результате описанных выше атак. Наихудшим вариантом будет использование ключа/пароля из символов ASCII, содержащего слово из языка человеческого общения или псевдо-слово. Такие ключи/пароли содержат не более 12 битов энтропии. В таких случаях атаки с использованием словаря могут привести к сокращению времени подбора во много раз. Таким реализациям следует позволять пользователям напрямую вводить двоичные ключи с использованием командного интерфейса. Одним из вариантов может служить соглашение о том, что ключи ASCII, начинающиеся с префикса "0x", интерпретируются как строки байтов, представленных в шестнадцатеричной записи. В идеальном случае такие строки следует создавать на основе случайных данных, как описано в [RFC1750]. Реализациям не следует без необходимости ограничивать размер ключей и следует разрешать ключи размером по крайней мере 16 байтов, чтобы противостоять неизбежным по закону Мура угрозам.

Страница 3 из 4

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