В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 15 Протокол согласования ключей Наконец-то пришло время взяться за протокол согласования ключей. На- значением данного протокола является создание общего ключа для безопас- ного канала общения, описанного в главе 8, “Безопасный канал общения”. В законченном виде криптографические протоколы довольно сложны, и знакомство сразу с окончательной версией протокола может оказаться весь- ма непростой задачей для неподготовленного читателя. Поэтому мы предста- вим вам последовательность протоколов, к каждому из которых будет добав- ляться все больше и больше функций. Не забывайте, что промежуточные версии протокола не обладают полной функциональностью и будут иметь множество слабых мест. 15.1 Окружение У протокола согласования ключей есть два участника: пользователь А и пользователь Б. Оба пользователя хотят обеспечить безопасность свое- го общения. Вначале они запускают протокол согласования ключей, чтобы установить секретный ключ сеанса k , а затем используют ключ k для обмена фактическими данными по безопасному каналу общения. Для обеспечения безопасности согласования ключа пользователи А и Б должны иметь возможность идентифицировать друг друга. Вопросам базо- вой аутентификации посвящена часть 3, “Введение в криптографию”, а пока мы просто предположим, что пользователи А и Б в состоянии аутентифици- ровать сообщения, которыми обмениваются. Базовая аутентификация может осуществляться с помощью цифровых подписей RSA (если пользователи А и Б знают ключи друг друга или используют инфраструктуру открытого ключа) либо посредством общего секретного ключа и функции вычисления MAC. 282 15.2. Первая попытка 283 Но зачем же проводить согласование ключа, если у нас уже есть общий секретный ключ? На то есть свои причины. Прежде всего согласование ключа позволяет отделить ключ сеанса от существующего (долговременного) обще- го ключа. Если ключ сеанса будет дискредитирован (например, из-за ошибок в реализации безопасного канала общения), общий секретный ключ все еще останется в безопасности. А если общий секретный ключ будет дискредити- рован после выполнения протокола согласования ключей, злоумышленник, которому известен общий секретный ключ, все еще не сможет узнать ключ сеанса, согласованный в результате выполнения протокола. Таким образом, потеря ключа не приведет к раскрытию прежних данных. Эти свойства очень важны: они повышают надежность всей системы. Существуют также ситуации, в которых общий секретный ключ довольно слаб (например, если это пароль). Как правило, пользователи, не желая запо- минать 30-буквенные пароли, пытаются выбрать что-нибудь попроще. Стан- дартным типом атаки на пароли подобного рода является атака с использова- нием словаря (dictionary attack) , в ходе которой компьютер злоумышленника перебирает большое количество простых паролей. Хороший протокол согла- сования ключей может превратить слабый пароль в сильный ключ. Впрочем, в этой главе такие протоколы рассматриваться не будут. 15.2 Первая попытка Начнем с самой простой структуры протокола (рис. 15.1). Это не более чем протокол Диффи–Хеллмана в рамках подгруппы с добавлением аутен- тификации. Пользователи А и Б выполняют протокол DH, используя первые два сообщения. (Для простоты мы опустили несколько необходимых прове- рок.) Затем пользователь А подсчитывает значение функции аутентифика- ции для ключа сеанса k и посылает это значение пользователю Б, который сверяет его со значением функции аутентификации для своего ключа k . Точ- но так же пользователь Б посылает значение функции аутентификации для k пользователю А. Пока неизвестно, в какой именно форме будет происходить аутентифика- ция. Напомним: предполагается, что пользователи А и Б могут аутентифи- цировать сообщения, которыми они обмениваются. Таким образом, пользова- тель Б может проверить значение функции AUTH A ( k ) , а пользователь А — значение функции AUTH B ( k ) . То, как именно это делается — посредством цифровых подписей или функции вычисления MAC, нас не волнует. Дан- ный протокол лишь обеспечивает возможность аутентификации по отноше- нию к ключу сеанса. Первая версия протокола имеет ряд недостатков. |