книги / Практическая криптография

генерировать новые параметры алгоритма DH, а пользователя А — от необ­ ходимости каждый раз их проверять. Приложения даже могут использовать фиксированные наборы параметров алгоритма DH, в результате чего их не придется посылать явно — достаточно указать идентификатор нужного на­ бора параметров. Все эти изменения представляют собой простые, непосред­ ственные оптимизации протокола, поэтому мы не будем обсуждать их более подробно. Тем не менее будьте крайне осторожны. Многочисленные оптими­ зации могут привести к тому, что протокол будет взломан. К сожалению, мы не можем сформулировать никаких простых правил относительно того, приведет ли конкретная оптимизация к взлому протокола или нет. Проекти­ рование протокола — это скорее искусство, нежели наука, и жестких правил, которых следует придерживаться всегда и везде, здесь не существует.

15.8Анализ протокола с различных точек зрения

Протокол наподобие нашего весьма полезно проанализировать с различ­ ных точек зрения. Наш протокол должен обладать несколькими свойствами, и в следующих разделах речь идет о том, почему он действительно ими об­ ладает.

15.8.1Точка зрения пользователя А

Давайте рассмотрим протокол с точки зрения пользователя А. Он по­ лучает от пользователя Б одно сообщение. Пользователь А уверен, что это сообщение действительно пришло от пользователя Б, так как оно прошло аутентификацию, и в данные, которые подверглись аутентификации, была включена случайная оказия ЛГа, выбранная самим пользователем А. Такое сообщение невозможно подделать или заменить воспроизведенным старым сообщением.

Пользователь А убеждается в том, что параметры алгоритма DH были вы­ браны правильно, поэтому протокол DH будет обладать всеми необходимыми свойствами. Таким образом, когда пользователь А генерирует секретное зна­ чение у и посылает значение У, он понимает, что вычислить к сможет только тот человек, который знает х , такой, что дх = X . Это основное свойство про­ токола DH. Пользователь Б аутентифицировал Х %а он может сделать это только в том случае, если выполняет все правила протокола. Следовательно, пользователь Б знает соответствующее значение х и сохраняет его в секрете. Таким образом, пользователь А может быть уверен в том, что полученный им ключ к известен только пользователю Б.

Итак, пользователь А убедился в том, что он действительно общается с пользователем Б и что полученный им ключ известен только ему и пользо­ вателю Б.

15.8.2Точка зрения пользователя Б

Теперь давайте взглянем на протокол глазами пользователя Б. Первое со­ общение, полученное им будто бы от пользователя А, практически не предо­ ставляет ему никакой полезной информации. Оно просто утверждает, что кто-то по ту сторону протокола выбрал значение sa и несколько случайных бит Na.

С третьим сообщением все обстоит по-другому. Это сообщение определен­ но пришло от пользователя А, потому что пользователь А аутентифициро­ вал его, а согласно нашим предположениям пользователь Б может проверить аутентификатор пользователя А. Данные, которые подверглись аутентифи­ кации, включают в себя X — случайное значение, выбранное самим пользо­ вателем Б. Это означает, что третье сообщение не могло быть воспроизведен­ ным сообщением, посланным злоумышленником. Оно было аутентифициро­ вано пользователем А специально для этого сеанса работы протокола. Кроме того, аутентификатор пользователя А охватывает и первое сообщение, полу­ ченное пользователем Б, поэтому теперь пользователь Б может быть уверен и в правильности первого сообщения.

Пользователь Б уверен в безопасности параметров алгоритма DH; в конце концов, он сам их выбрал. Поэтому, как и пользователь А, он знает, что вычислить ключ к сможет только тот, кто знает у} такое, что ду = У. Но пользователь А аутентифицировал высланное им значение У, поэтому он является единственным человеком, который знает соответствующее у. Это убеждает пользователя Б в том, что вычислить ключ к кроме него сможет только пользователь А.

15.8.3Точка зрения злоумышленника

И наконец, проанализируем протокол согласования ключей с точки зре­ ния злоумышленника. Если мы будем просто прослушивать канал связи, то зафиксируем все сообщения, которыми обмениваются пользователи А и Б. Но ключ к вычисляется по протоколу DH, поэтому, если параметры алгоритма DH надежны, пассивная атака наподобие этой не позволит получить какойлибо информации о ключе к. Другими словами, пора переходить к активным действиям.

В качестве поучительного упражнения можно рассмотреть каждый эле­ мент данных протокола и попытаться изменить его. В этом случае наша атака

будет моментально остановлена двумя процессами аутентификации. Послед­ няя аутентификация, проводимая пользователем А, охватывает все данные, которыми до этого обменялись пользователи А и Б. Это означает, что мы не можем изменить какие-либо элементы данных, можем лишь попытаться воспроизвести старые сообщения из предыдущего сеанса работы протокола. Но наличие оказии и случайно выбранного X останавливает и атаку воспро­ изведения.

Все это отнюдь не означает, что у нас не осталось путей для нападения. Мы могли бы, например, изменить значение sa на величину большего разме­ ра. Если это значение окажется приемлемым для пользователя Б, ббльшая часть протокола пройдет по обычному сценарию. Существует лишь три про­ блемы. Первая состоит в том, что увеличение sa вообще нельзя назвать ата­ кой, поскольку оно приводит лишь к увеличению простого числа DH, в ре­ зультате чего параметры алгоритма DH становятся еще надежнее. Вторая и третья проблемы — это два процесса аутентификации, которые завершатся неудачей.

В реальной жизни существует множество протоколов с элементами дан­ ных, которые не подвергаются аутентификации. Большинство разработчиков не стали бы утруждать себя аутентификацией значения sa, потому что его изменение не приведет к осуществлению атаки. (Пользователи А и Б неза­ висимо друг от друга проверяют, подходит ли им размер числа р.) Тем не менее, на наш взгляд, злоумышленнику никогда не следует позволять вме­ шиваться в общение участников протокола. Зачем предоставлять ему больше средств, чем нужно? Кроме того, мы можем легко представить себе ситуа­ цию, в которой отказ от аутентификации sa угрожает безопасности системы. Например, предположим, что пользователь Б предпочитает работать с одним из наборов параметров алгоритма DH, встроенных в программу, и генериру­ ет новые параметры только тогда, когда это нужно. Если размеры просто­ го числа, выбранные пользователями А и Б, всегда будут соответствовать параметрам, имеющимся в списке, пользователь Б никогда не сгенерирует новый набор параметров. Но это также означает, что код пользователя Б, который генерирует параметры, и код пользователя А, который проверяет эти параметры, никогда не будут использоваться. Маловероятно, что такой код будет тщательно протестирован. Ошибка в коде генерации и проверки параметров может остаться незамеченной, пока злоумышленник не увеличит sa. Разумеется, вероятность подобного сценария крайне мала, однако суще­ ствуют тысячи маловероятных сценариев, каждый из которых плохо влияет на безопасность системы. А тысячи рисков с малой степенью вероятности в совокупности могут составить риск с высокой степенью вероятности. Вот почему мы так стремимся предотвратить атаку любого типа там, где только возможно. Это дает нам ощущение истинной защищенности.

Как видите, наш протокол обеспечивает наилучшую возможную защиту от взлома ключей.

15.9 Вычислительная сложность протокола

Теперь обсудим вычислительную сложность нашего решения. Будем ис­ ходить из предположения, что процедуры выбора и проверки параметров алгоритма DH кэшированы, поэтому они не будут учитываться в объеме вы­ числений, необходимых для проведения одного сеанса работы протокола. Как следствие этого, у нас остаются такие вычисления:

•три операции возведения в степень в подгруппе DH для каждого из пользователей А и Б;

•одна генерация аутентификатора;

•одна проверка аутентификатора;

•различные относительно эффективные операции, такие, как генерация случайных чисел, сравнение и хэширование2.

Бели мы применяем аутентификацию с симметричным ключом, тогда вре­ мя выполнения протокола будет определяться показателями степеней алго­ ритма DH. Давайте посмотрим, сколько вычислений для этого потребуется. Каждый из пользователей А и Б должен проделать три операции возведе­ ния в степень по модулю с 256-битовым показателем степени. Это потребует около 1150 операций умножения по модулю3. Чтобы получить представление о том, насколько велик этот объем вычислений, давайте сравним его с вычис­ лительной стоимостью создания цифровой подписи RSA, если модуль RSA и простое число DH будут иметь одинаковый размер. Для s-битового модуля алгоритм создания цифровой подписи потребует 3s/2 вычислений, если не использовать китайскую теорему об остатках (Chinese Remainder Theorem — CRT). Использование CRT-представления позволяет сократить объем вычис­ лений в четыре раза, поэтому вычислительная стоимость цифровой подписи RSA для s-битового модуля будет эквивалентна вычислительной стоимости 3s/8 операций умножения. Мы пришли к интересному заключению: алго­ ритм RSA относительно медленнее алгоритма DH при использовании моду­ лей большого размера и относительно быстрее при использовании модулей

2Все сказанное в этом разделе касается объема вычислений для одного из двух участ­ ников протокола. И пользователь А и пользователь В должны выполнить по три операции возведения в степень в подгруппе DH, по одной генерации аутентификатора, по одной проверке аутентификатора и по набору различных эффективных операций.

3Речь идет о простом бинарном алгоритме возведения в степень. При использовании хорошо оптимизированного алгоритма количество операций умножения можно сократить до 1000 или еще меньшего числа.

малого размера. “Переломная” точка находится примерно на уровне 3000 бит. Причина такого эффекта состоит в том, что алгоритм DH всегда использует 256-битовые показатели степеней, в то время как размеры показателей RSA возрастают вместе с размером модуля.

Мы пришли к выводу, что при используемых размерах открытых ключей объем вычислений для алгоритма DH примерно равен объему вычислений для схемы цифровых подписей RSA. Описанная выше нагрузка составляет основной объем вычислений нашего протокола, но она находится в разумных пределах.

Если для аутентификации применяются цифровые подписи RSA, вычис­ лительная нагрузка примерно удваивается. (Проверку подписей RSA можно не учитывать, так как она выполняется очень быстро.) Тем не менее данную нагрузку все еще нельзя назвать чрезмерной. Скорость процессоров стреми­ тельно растет изо дня в день, и, как показывает практика, коммуникацион­ ные задержки и передача служебной информации отнимают гораздо больше времени, чем криптографические вычисления.

15.9.1М етоды оптимизации

Вычисления, выполняемые в рамках протокола DH, поддаются оптими­ зации. С помощью эвристики аддитивной цепочки (addition chain heuristics) каждую операцию возведения в степень можно осуществлять путем меньшего количества умножений. Более того, пользователь А должен вычислить значе­ ния X я и Х у. Используя эвристику аддитивной последовательности (addition sequence heuristics), эти значения можно вычислить параллельно, сэкономив при этом около 250 операций умножения. Более подробно это рассматрива­ ется в работе Боса (Bos) [10, глава 4].

Существуют также разнообразные приемы, которые позволяют быстрее генерировать случайное число у и вычислять ру, но они настолько усложняют систему, что мы предпочитаем обходиться без них.

15.10 Сложность протокола

Описанный протокол согласования ключей является прекрасным приме­ ром того, почему структура большинства протоколов столь сложна. Даже простой протокол наподобие нашего разрастается на целую страницу, а ведь мы еще не включили в его описание все правила генерации параметров алго­ ритма DH и все необходимые проверки, выполняемые в рамках схемы аутен­ тификации (на нашем уровне абстракции они неизвестны). Несмотря на это, уследить за всем, что происходит в рамках такого протокола, уже очень труд­ но. Спецификации более сложных протоколов занимают еще больше места.

Одна система электронных платежей с помощью смарт-карт, над которой ко­ гда-то работал Нильс, включала в себя около десятка протоколов. Их описа­ ние представляло собой 50 страниц всевозможных символов и спецификаций протоколов, и это с использованием запатентованной, чрезвычайно компакт­ ной формы записи! Для описания критических вопросов реализации, каса­ ющихся обеспечения безопасности, потребовалось еще 50 густоисписанных страниц.

Полная документация набора криптографических протоколов может за­ нимать сотни страниц. Протоколы усложняются так быстро, что удержать в голове все их аспекты становится крайне трудно. Это очень опасно — при наличии хотя бы малейшего недопонимания в протокол неизбежно вкрадется какая-нибудь “слабинка”. Упомянутый выше проект, пожалуй, был слишком сложен для того, чтобы его в полной мере могли понять хотя бы сами разра­ ботчики.

Несколько лет спустя Нильс работал с другой системой смарт-карт, пред­ назначенной для коммерческого распространения. Это была хорошо извести ная, устоявшаяся система, которая широко использовалась различными при­ ложениями для работы со смарт-картами. Как-то раз Мариус Шилдер (Ma­ rius Schilder), коллега Нильса, задумался над одним вопросом, а точнее, над огромной “дырой” в безопасности этой системы. Оказалось, что два из ее про­ токолов взаимодействовали друг с другом, что оказывало негативное влияние на каждый из них. Один протокол вычислял ключ сеанса на основе долговре­ менного ключа смарт-карты (этим он немного напоминал протокол согласо­ вания ключей, описанный в данной главе). Второй протокол вычислял значе­ ние функции аутентификации на основе все того же долговременного ключа смарт-карты. Приложив немного усилий, мы могли воспользоваться вторым протоколом, чтобы заставить смарт-карту вычислить ключ сеанса и отослать нам половину его бит. Имея на руках половину бит ключа сеанса, взломать оставшуюся часть системы не представляло никакого труда. Просто кошмар! Данная ошибка была исправлена в следующей версии системы, однако она наглядно иллюстрирует проблемы спецификаций больших протоколов.

Реальные системы всегда обладают поистине гигантскими спецификация­ ми протоколов. Электронные коммуникации сложны сами по себе, а добавле­ ние криптографических функций и отсутствие доверия еще более усложняют ситуацию. Наш совет: будьте крайне осторожны со сложностью протоколов!

Одна из фундаментальных проблем данной области состоит в отсутствии хороших методов записи протокола, которые бы позволяли разбить его на отдельные модули. В результате компоненты протокола перемешиваются са­ мым непостижимым образом. Мы уже наблюдали подобную ситуацию в дан­ ной главе: согласование размера параметров алгоритма DH, обмен ключами DH и аутентификация свалены в одну кучу. Это не просто комбинация несвя­

занных компонентов, а настоящая адская смесь спецификации и реализации. Все это скорее напоминает плохую, очень сложную компьютерную програм­ му без каких-либо признаков модуляризации. Все мы знаем, к чему приводит подобная мешанина, поэтому давно разработали методы разбивки на моду­ ли, которые позволяют справиться со сложностью программы. К сожалению, нам не хватает методов модуляризации для протоколов. Если вы ищете тему длядолгосрочного научно-исследовательского проекта, данный вопрос может стать хорошим предметом для изучения. С другой стороны, однажды Нильс написал исследовательскую работу именно по этой теме. Работа Нильса бы­ ла принята. Он получил финансирование на четыре года исследований, но впоследствии отказался от проекта, поскольку осознал, что не имеет ни ма­ лейшего представления о том, с какой стороны можно хотя бы приблизиться к этому вопросу. Человек, которому в конце концов перепоручили проект Нильса, тоже не продвинулся в нем ни на шаг, зато провел четыре года цен­ ных исследований совсем в другой области. Отсюда вывод: не все так просто, как кажется. Наверное, сложно получить степень доктора наук, если после многолетних исследований вы заявите комиссии: “Понятия не имею, как это делается”.

15.11 Небольшое предупреждение

Мы постарались, чтобы процесс проектирования нашего протокола вы­ глядел как можно проще. Однако это не должно вводить вас в заблуждение. В действительности проектирование протокола — занятие весьма сложное, требующее огромного опыта. Даже опытный разработчик может легко до­ пустить ошибку. Хотя мы и приложили максимум усилий, чтобы сделать все так, как нужно, не исключена вероятность того, что протокол согласова­ ния ключей, разработанный нами в процессе написания этой книги, окажется ненадежным.

15.12Согласование ключей с помощью пароля

До сих пор предполагалось, что согласование ключей основывается на некоторой системе аутентификации. Зачастую, однако, у пользователей нет никаких способов аутентификации кроме пароля. В подобных случаях мы могли бы просто использовать функцию вычисления MAC, применяя пароль в качестве ключа, но это очень опасно: имея расшифровку протокола (добы­ тую путем прослушивания канала общения), злоумышленник может легко проверить правильность любого конкретного пароля. Достаточно лишь вы­ числить значение MAC и посмотреть, будет ли оно правильным.