В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 15. Протокол согласования ключей Одна система электронных платежей с помощью смарт-карт, над которой ко- гда-то работал Нильс, включала в себя около десятка протоколов. Их описа- ние представляло собой 50 страниц всевозможных символов и спецификаций протоколов, и это с использованием запатентованной, чрезвычайно компакт- ной формы записи! Для описания критических вопросов реализации, каса- ющихся обеспечения безопасности, потребовалось еще 50 густоисписанных страниц. Полная документация набора криптографических протоколов может за- нимать сотни страниц. Протоколы усложняются так быстро, что удержать в голове все их аспекты становится крайне трудно. Это очень опасно — при наличии хотя бы малейшего недопонимания в протокол неизбежно вкрадется какая-нибудь “слабинка”. Упомянутый выше проект, пожалуй, был слишком сложен для того, чтобы его в полной мере могли понять хотя бы сами разра- ботчики. Несколько лет спустя Нильс работал с другой системой смарт-карт, пред- назначенной для коммерческого распространения. Это была хорошо извест- ная, устоявшаяся система, которая широко использовалась различными при- ложениями для работы со смарт-картами. Как-то раз Мариус Шилдер (Mar- ius Schilder), коллега Нильса, задумался над одним вопросом, а точнее, над огромной “дырой” в безопасности этой системы. Оказалось, что два из ее про- токолов взаимодействовали друг с другом, что оказывало негативное влияние на каждый из них. Один протокол вычислял ключ сеанса на основе долговре- менного ключа смарт-карты (этим он немного напоминал протокол согласо- вания ключей, описанный в данной главе). Второй протокол вычислял значе- ние функции аутентификации на основе все того же долговременного ключа смарт-карты. Приложив немного усилий, мы могли воспользоваться вторым протоколом, чтобы заставить смарт-карту вычислить ключ сеанса и отослать нам половину его бит. Имея на руках половину бит ключа сеанса, взломать оставшуюся часть системы не представляло никакого труда. Просто кошмар! Данная ошибка была исправлена в следующей версии системы, однако она наглядно иллюстрирует проблемы спецификаций больших протоколов. Реальные системы всегда обладают поистине гигантскими спецификация- ми протоколов. Электронные коммуникации сложны сами по себе, а добавле- ние криптографических функций и отсутствие доверия еще более усложняют ситуацию. Наш совет: будьте крайне осторожны со сложностью протоколов! Одна из фундаментальных проблем данной области состоит в отсутствии хороших методов записи протокола, которые бы позволяли разбить его на отдельные модули. В результате компоненты протокола перемешиваются са- мым непостижимым образом. Мы уже наблюдали подобную ситуацию в дан- ной главе: согласование размера параметров алгоритма DH, обмен ключами DH и аутентификация свалены в одну кучу. Это не просто комбинация несвя- 15.11. Небольшое предупреждение 299 занных компонентов, а настоящая адская смесь спецификации и реализации. Все это скорее напоминает плохую, очень сложную компьютерную програм- му без каких-либо признаков модуляризации. Все мы знаем, к чему приводит подобная мешанина, поэтому давно разработали методы разбивки на моду- ли, которые позволяют справиться со сложностью программы. К сожалению, нам не хватает методов модуляризации для протоколов. Если вы ищете тему для долгосрочного научно-исследовательского проекта, данный вопрос может стать хорошим предметом для изучения. С другой стороны, однажды Нильс написал исследовательскую работу именно по этой теме. Работа Нильса бы- ла принята. Он получил финансирование на четыре года исследований, но впоследствии отказался от проекта, поскольку осознал, что не имеет ни ма- лейшего представления о том, с какой стороны можно хотя бы приблизиться к этому вопросу. Человек, которому в конце концов перепоручили проект Нильса, тоже не продвинулся в нем ни на шаг, зато провел четыре года цен- ных исследований совсем в другой области. Отсюда вывод: не все так просто, как кажется. Наверное, сложно получить степень доктора наук, если после многолетних исследований вы заявите комиссии: “Понятия не имею, как это делается”. 15.11 Небольшое предупреждение Мы постарались, чтобы процесс проектирования нашего протокола вы- глядел как можно проще. Однако это не должно вводить вас в заблуждение. В действительности проектирование протокола — занятие весьма сложное, требующее огромного опыта. Даже опытный разработчик может легко до- пустить ошибку. Хотя мы и приложили максимум усилий, чтобы сделать все так, как нужно, не исключена вероятность того, что протокол согласова- ния ключей, разработанный нами в процессе написания этой книги, окажется ненадежным. 15.12 Согласование ключей с помощью пароля До сих пор предполагалось, что согласование ключей основывается на некоторой системе аутентификации. Зачастую, однако, у пользователей нет никаких способов аутентификации кроме пароля. В подобных случаях мы могли бы просто использовать функцию вычисления MAC, применяя пароль в качестве ключа, но это очень опасно: имея расшифровку протокола (добы- тую путем прослушивания канала общения), злоумышленник может легко проверить правильность любого конкретного пароля. Достаточно лишь вы- числить значение MAC и посмотреть, будет ли оно правильным. |