В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 15. Протокол согласования ключей будет моментально остановлена двумя процессами аутентификации. Послед- няя аутентификация, проводимая пользователем А, охватывает все данные, которыми до этого обменялись пользователи А и Б. Это означает, что мы не можем изменить какие-либо элементы данных, можем лишь попытаться воспроизвести старые сообщения из предыдущего сеанса работы протокола. Но наличие оказии и случайно выбранного X останавливает и атаку воспро- изведения. Все это отнюдь не означает, что у нас не осталось путей для нападения. Мы могли бы, например, изменить значение s a на величину большего разме- ра. Если это значение окажется приемлемым для пользователя Б, б´ольшая часть протокола пройдет по обычному сценарию. Существует лишь три про- блемы. Первая состоит в том, что увеличение s a вообще нельзя назвать ата- кой, поскольку оно приводит лишь к увеличению простого числа DH, в ре- зультате чего параметры алгоритма DH становятся еще надежнее. Вторая и третья проблемы — это два процесса аутентификации, которые завершатся неудачей. В реальной жизни существует множество протоколов с элементами дан- ных, которые не подвергаются аутентификации. Большинство разработчиков не стали бы утруждать себя аутентификацией значения s a , потому что его изменение не приведет к осуществлению атаки. (Пользователи А и Б неза- висимо друг от друга проверяют, подходит ли им размер числа p .) Тем не менее, на наш взгляд, злоумышленнику никогда не следует позволять вме- шиваться в общение участников протокола. Зачем предоставлять ему больше средств, чем нужно? Кроме того, мы можем легко представить себе ситуа- цию, в которой отказ от аутентификации s a угрожает безопасности системы. Например, предположим, что пользователь Б предпочитает работать с одним из наборов параметров алгоритма DH, встроенных в программу, и генериру- ет новые параметры только тогда, когда это нужно. Если размеры просто- го числа, выбранные пользователями А и Б, всегда будут соответствовать параметрам, имеющимся в списке, пользователь Б никогда не сгенерирует новый набор параметров. Но это также означает, что код пользователя Б, который генерирует параметры, и код пользователя А, который проверяет эти параметры, никогда не будут использоваться. Маловероятно, что такой код будет тщательно протестирован. Ошибка в коде генерации и проверки параметров может остаться незамеченной, пока злоумышленник не увеличит s a . Разумеется, вероятность подобного сценария крайне мала, однако суще- ствуют тысячи маловероятных сценариев, каждый из которых плохо влияет на безопасность системы. А тысячи рисков с малой степенью вероятности в совокупности могут составить риск с высокой степенью вероятности. Вот почему мы так стремимся предотвратить атаку любого типа там, где только возможно. Это дает нам ощущение истинной защищенности. 15.8. Анализ протокола с различных точек зрения 295 15.8.4 Взлом ключа Теперь посмотрим, что произойдет, если одна из оставшихся частей си- стемы будет каким-либо образом дискредитирована. Если пользователь А потеряет свой ключ аутентификации, который не будет известен злоумышленнику, он просто не сможет запустить протокол. При этом пользователь А все еще сможет применять уже установленные клю- чи сеанса. Именно такого поведения обычно ожидают от протоколов. Это же справедливо и для пользователя Б, если он потеряет свой ключ аутентифи- кации. Если пользователь А потеряет ключ сеанса, который не будет известен злоумышленнику, ему придется еще раз запустить протокол согласования ключей с пользователем Б, чтобы установить новый ключ сеанса. Ситуация ухудшается, если злоумышленнику удается узнать ключ. Ес- ли злоумышленник узнает ключ аутентификации пользователя А, он сможет выдавать себя за него до тех пор, пока пользователь Б не будет уведомлен о потере ключа и не перестанет принимать сообщения, аутентифицированные пользователем А. Это неизбежное следствие потери ключа. Если вы потеряе- те ключи от машины, всякий, кто найдет их, сможет воспользоваться вашей машиной. Главная функция ключей и состоит в том, чтобы открывать доступ к определенным функциям. К счастью, наш протокол обладает одним свой- ством, наличие которого всегда крайне желательно: он гарантирует, что все предыдущие сеансы общения между пользователями А и Б останутся в секре- те. Даже если злоумышленник знает ключ аутентификации пользователя А, он не сможет вычислить ключ сеанса k для протокола, выполнение которого уже было завершено. Это не удастся даже в том случае, если злоумышленник записывал все предыдущие сообщения. Данное свойство протокола называ- ется прямой безопасностью (forward secrecy) 1 . Сказанное справедливо и для ключа аутентификации пользователя Б. И наконец, рассмотрим ситуацию, когда злоумышленнику удается взло- мать ключ сеанса. Ключ k — это хэш-код значения g xy , где x и y — случайные числа. Они не предоставляют никакой информации о других ключах, напри- мер о ключах аутентификации пользователей А и Б. Значение k , применяе- мое в одном сеансе работы протокола, полностью независимо от значений k , применяемых в других сеансах работы этого же протокола (по крайней мере, если предположить, что пользователи А и Б применяют хороший генератор псевдослучайных чисел). 1 Иногда это называют идеальной прямой безопасностью (perfect forward secrecy — PFS), но мы предпочитаем не использовать слов наподобие “идеальный”, поскольку идеальной безопасности не существует. |