В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 15. Протокол согласования ключей Пользователь А Известно: (p, q, g) Пользователь Б Известно: (p, q, g) x R {1, ..., q- 1} X := g x Y := g y y R {1, ..., q- 1} k Y x k X y AUTH A (k) AUTH B (k) Проверить AUTH A (k) Проверить AUTH B (k) Рис. 15.1. Первая попытка согласования ключа • Работа протокола основана на предположении, что пользователям А и Б известен набор параметров ( p, q, g ) . Выбор констант в качестве этих значений — не очень удачная идея. • Данный протокол использует четыре сообщения, в то время как для достижения желаемой цели достаточно только трех. • Ключ сеанса применяется в качестве входного значения функции аутен- тификации. Это не составит проблемы, если функция сильная. Предпо- ложим, однако, что функция аутентификации может допустить утечку информации о нескольких битах ключа сеанса. Это было бы очень пло- хо и, безусловно, потребовало бы повторного анализа всего протокола. “Золотое правило” гласит: секретные данные лучше использовать толь- ко для одной цели. В нашем случае k будет применяться в качестве ключа сеанса, поэтому использовать его еще и как аргумент функции аутентификации определенно не стоит. • Сообщения об аутентификации слишком похожи друг на друга. Пусть, например, функция аутентификации — это простая функция вычисле- ния MAC, которая использует значение секретного ключа, известного обоим пользователям. Тогда пользователь Б может просто отправить пользователю А полученное от него же значение MAC, а значит, поль- зователю Б не нужно знать секретный ключ, чтобы завершить выпол- нение протокола. Следовательно, пользователь А не может быть уверен в том, что последнее сообщение об аутентификации истинно. 15.3. Пусть всегда будут протоколы! 285 • Ключ k не должен использоваться программой до тех пор, пока пользо- ватели А и Б не обменяются сообщениями об аутентификации, и за этим необходимо внимательно следить. На первый взгляд данное требование выглядит очевидным, но вы бы не поверили, узнав, до чего додумыва- ются некоторые программисты, пытаясь оптимизировать систему. В следующих разделах главы рассматривается, как исправить все эти недостатки. 15.3 Пусть всегда будут протоколы! Мы уже подчеркивали важность проектирования систем с запасом на бу- дущее. Это еще более важно для протоколов. Если ограничить размер полей базы данных до 2000 байт, это может составить проблему для некоторых пользователей, но от ограничения легко избавиться в следующей же версии базы данных. С протоколами все не так просто. Протоколы запускаются для обмена данными между различными участниками, и каждая новая версия протокола должна обладать обратной совместимостью с предыдущей. Изме- нить протокол и в то же время сохранить его совместимость со старыми вер- сиями чрезвычайно сложно. Чтобы осознать это, вам придется реализовать несколько версий протокола, а также систему выбора, какую версию следует использовать. Переход к другой версии протокола — это, безусловно, прекрасный мо- мент для осуществления атаки. Если старый протокол был менее безопа- сен, злоумышленник будет заинтересован в том, чтобы заставить вас приме- нить именно этот старый протокол. Вы бы удивились, узнав, как много си- стем страдают от так называемой атаки с откатом версий (version-rollback attack) . Разумеется, предусмотреть все будущие требования невозможно, поэтому в какой-то момент вам понадобится определить вторую версию протокола. Тем не менее цена одновременного существования нескольких версий прото- кола достаточно высока, особенно в контексте общей сложности. Удачные протоколы живут практически вечно (а неудачные нас не ин- тересуют). Полностью убрать протокол из всех систем в мире невозможно. Таким образом, протоколы еще более важно проектировать с запасом на бу- дущее. Вот почему мы не можем указать в протоколе согласования ключей фиксированный набор параметров DH. Даже если они будут очень большими, существует опасность, что будущие успехи в области криптоанализа заставят нас изменить их. |