В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 12. Алгоритм Диффи–Хеллмана Пользователь А Известны Проверить параметры Пользователь Б Известны Проверить параметры Рис. 12.3. Протокол Диффи–Хеллмана в рамках подгруппы полученное ими число принадлежит к нужной подгруппе, чтобы избежать атак, связанных с использованием подгруппы малого размера. На рис. 12.3 проверка обозначена операторами сравнения (например, = или < ), над которыми стоят знаки вопроса. Это означает, что пользователь А (или Б) должен проверить, действительно ли между значениями сохраняет- ся указанное отношение. Если оно сохраняется, тогда все в порядке. Если же отношение неверно, тогда пользователь А должен предположить, что на него осуществляется нападение. В этом случае необходимо остановить выполне- ние протокола, прекратить отправку сообщений и уничтожить все данные, касающиеся протокола. Например, если проверка последней группы условий покажет, что они неверны, пользователь А должен уничтожить значения x и Y . Более подробно о том, как бороться с такими нарушениями, речь идет в разделе 14.5.5. Наш протокол представляет собой безопасный вариант схемы Диффи– Хеллмана, но он не должен применяться в точности так, как здесь описано. Результат k должен пройти хэширование, прежде чем будет использоваться оставшейся частью системы. Более подробно это рассматривается в разде- ле 15.6. 12.9 Что может пойти не так Лишь некоторые книги и статьи обращают внимание читателей на важ- ность проверки того, действительно ли значения, полученные от собеседника, принадлежат необходимой подгруппе. Нильс впервые обнаружил это пробле- му в IKE (Internet Key Exchange — обмен ключами в Internet), одном из про- токолов IPSec. Некоторые протоколы IKE используют обмен ключами по схе- 12.9. Что может пойти не так 243 ме Диффи–Хеллмана. Поскольку IKE функционирует в реальном мире, ему приходится иметь дело с потерянными сообщениями. Поэтому IKE требует от пользователя Б, чтобы тот в случае отсутствия ответа повторно отослал свое последнее сообщение. При этом IKE не указывает, как именно пользователь А должен обрабатывать сообщение, повторно отосланное ему пользователем Б. Между тем пользователю А легко совершить серьезную ошибку. Для простоты предположим, что пользователи А и Б применяют протокол DH в рамках подгруппы (см. рис. 12.3), но не проверяют правильность зна- чений X и Y . Более того, после обмена данными пользователь А применяет ключ k , чтобы отослать пользователю Б зашифрованное и аутентифициро- ванное сообщение, содержащее еще некоторые параметры протокола. (Это стандартная ситуация, аналогичные которой могут случаться и в IKE.) Пользователь А может совершить следующую ошибку. Получив копию повторно отправленного сообщения, содержащего значение Y , он просто пе- ресчитывает значение ключа k и отсылает соответствующий ответ пользо- вателю Б. Звучит довольно безобидно, не так ли? Но тут в дело вступает злоумышленник Е. Пусть d — это малый делитель числа ( p − 1) . Злоумышлен- ник Е может заменить Y элементом порядка d . Теперь ключ k пользователя А может иметь лишь d возможных значений и полностью определяется значе- ниями Y и ( x mod d ) . Злоумышленник Е перебирает все возможные значения ( x mod d ) , вычисляет ключ k , который должен был получить пользователь А, и пытается расшифровать следующее сообщение, отправленное пользовате- лем А. Если значение ( x mod d ) было угадано верно, сообщение будет успешно расшифровано, а злоумышленник узнает точное значение ( x mod d ) . Но что, если у числа p − 1 есть целый ряд малых делителей ( d 1 , d 2 , . . . , d k ) ? Тогда злоумышленник Е сможет повторить атаку для каждого из этих дели- телей и узнать значения ( x mod d 1 ) , . . . , ( x mod d k ) . Используя общую форму китайской теоремы об остатках (см. раздел 13.2), злоумышленник сможет определить значение ( x mod d 1 d 2 d 3 . . . d k ) . Таким образом, если произведе- ние всех малых делителей числа p − 1 достаточно велико, злоумышленник получит значительный объем информации об x . Поскольку x предполагается сохранять в секрете, дальнейшее развитие событий будет далеко не самым приятным. В нашем случае злоумышленник Е может завершить атаку, пере- слав пользователю А исходное значение Y и подождав, пока пользователи А и Б выполнят все действия, требуемые протоколом. Но теперь у злоумышлен- ника накопилось достаточно информации об x , чтобы найти ключ k , который применяют пользователи А и Б. Немного уточним: описанная атака — это вовсе не атака на IKE. Это ата- ка на реализацию IKE, которая допускается стандартом. Несмотря на это, на наш взгляд, протокол должен содержать достаточно информации для то- го, чтобы компетентный разработчик мог создать безопасную реализацию. |