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

Иногда результатом функции СВС-МАС считают половину последнего блока, но это уже зависит от конкретной ситуации.

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

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

Алгоритм СВС-МАС не слишком прост в применении. Тем не менее в об­ щем случае он считается безопасным, если соответствующий блочный шифр также безопасен. Существует ряд атак на основе коллизий, которые сокра­ щают уровень безопасности СВС-МАС до половины размера блока [12]. Вот простой пример одной из таких атак. Пусть М — это функция СВС-МАС. Если известно, что М (о) = М(Ь), значит, М(а |с) = М(Ь |с). Это объясня­ ется спецификой алгоритма СВС-МАС. Проиллюстрируем данное свойство на простом примере, когда с состоит из одного блока текста. Мы знаем, что

М (а |с) = Е к(с® М(а)), М{Ь |с) = Е к(с® М(Ь)).

Поскольку М (а) = М(Ь), правые части этих выражений равны.

Такая атака выполняется в два этапа. На первом этапе злоумышленник собирает значения MAC для большого количества сообщений, пока не на­ ткнется на коллизию. В этом случае у него появятся сообщения а и Ь, для которых М (а) = М(Ь). Если теперь злоумышленнику удастся аутентифици­ ровать у получателя сообщение а | с, он может заменить его сообщением ЬI с, причем значение MAC останется прежним. Получатель проверит зна­ чение MAC и примет поддельное сообщение. (Напомним, что мы работаем с параноидальной моделью. Вполне возможно, что злоумышленник может создать сообщение и аутентифицировать его у получателя. В реальной жизни такие ситуации встречаются довольно часто.) Существует много усовершен­ ствованных вариантов такой атаки, которые работают даже при добавлении поля с длиной сообщения и применении правил дополнения [12].

Эта атака не является тривиальной, поскольку она не срабатывает для идеальной функции вычисления MAC. Найти коллизию несложно и для иде­ альной функции. Тем не менее, даже когда у вас появятся сообщения а и 6,

лать значение MAC для нового сообщения, как при использовании алгоритма СВС-МАС.

Существует несколько теоретических результатов, которые показывают, что при использовании конкретной модели доказательств алгоритм СВСМАС обеспечивает 64-битовый уровень безопасности, если размер блока ра­ вен 128 бит [4]. К сожалению, этого недостаточно для обеспечения уровня безопасности, установленного для наших систем. Мы бы смогли использо­ вать СВС-МАС, если бы имели блочный шифр с 256-битовым блоком.

Использовать алгоритм СВС-МАС следует крайне осторожно. Функцию СВС-МАС нельзя применять к самому сообщению — это позволяет злоумыш­ леннику осуществлять довольно простые атаки. Необходимо поступить не­ сколько иначе.

1.Создайте строку s путем конкатенации значений I и т, где I — это длина сообщения т , представленного в формате фиксированной длины.

2. Дополните строку s, чтобы ее длина стала кратной длине блока. (Более подробно это рассматривается в разделе 5.1.)

3.Примените функцию СВС-МАС к дополненной строке а.

4.Результатом применения функции СВС-МАС считайте последний блок шифрованного текста или часть этого блока. Не используйте в качестве MAC промежуточные значения.

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

Несмотря на это, мы не рекомендуем использовать СВС-МАС, поскольку сделать это правильно крайне сложно.

7.5НМАС

Если идеальная функция вычисления MAC — это случайное отображение, а у нас уже есть функции хэширования, которые ведут себя как случайное отображение, то почему бы не вычислять значение MAC с помощью функ­ ции хэширования? Именно эта идея легла в основу алгоритма НМАС [3, 58]. Разработчики данного алгоритма, конечно же, знали о проблемах функций хэширования, которые обсуждаются в главе 6, “Функции хэширования”. В то

время как функции хэширования обеспечивают только n /2-битовый уровень безопасности по отношению к некоторым типам атак, функция вычисле­ ния MAC должна обеспечивать n-битовый уровень безопасности. Определять функцию МАС(АТ, 7п ) как h (K |тп), h(m |К) или даже как h(K II Ш II К) при использовании одной из стандартных итеративных функций хэширова­ ниянебезопасно [76]. Если присоединить ключ к началу сообщения, он станет уязвимым по отношению к атакам с удлинением сообщения. Если же присо­ единить ключ к концу сообщения, сообразительный злоумышленник сможет восстановить ключ примерно за 2”/2 шагов.

Разработчики алгоритма НМАС не только учли все эти моменты, но и от­ неслись к этому весьма серьезно. Структура функции НМАС позволяет из­ бежать атак с восстановлением ключа и атак, которые могут быть проведе­ ны злоумышленником в автономном режиме, без взаимодействия с системой. Несмотря на это, НМАС все еще ограничен n/2-битовым уровнем безопас­ ности. Это объясняется наличием атак, построенных на парадоксе задачи о днях рождения, которые используют внутренние коллизии итеративных функций хэширования. Алгоритм НМАС гарантирует, что выполнение та­ ких атак потребует 2П/2 взаимодействий с атакуемой системой. Это гораздо сложнее, нежели выполнить 2"/2 вычислений на собственном компьютере.

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

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

Значение НМАС подсчитывается по формуле h(K Ф а |h(K 0 b |т )), где а и 6 — некоторые константы. Как видите, сам текст сообщения хэширу­ ется только единожды, а полученный результат еще раз хэшируется вместе с ключом аутентификации. Более подробно об алгоритме НМАС можно про­ читать в его спецификациях [3, 58]. Алгоритм НМАС работает с любыми ите­ ративными функциями хэширования, которые описаны в главе 6, “Функции хэширования”. Это единственное исключение, когда можно непосредственно применять функции SHA, а не SHA<* — в НМАС уже учтены проблемы, на решение которых направлены функции SHAj.

Нам нравится НМАС. Он красив, эффективен и прост в реализации. В ка­ честве функций хэширования НМАС обычно применяют MD5 или SHA-1. Сегодня подобные реализации данного алгоритма содержатся во многих про­

граммных библиотеках. Несмотря на это, для достижения заявленного 128-битового уровня безопасности мы бы рекомендовали использовать НМАС только с 256-битовой функцией хэширования, например SHA-256. Поскольку

вНМАС уже учтены слабые места функции SHA-256, использовать SHAj-256

вданном случае необязательно.

7.5.1НМАС или SHAd?

Как уже отмечалось, функция вычисления MAC, определенная как h(K | m), хороша настолько, насколько хороша соответствующая функ­ ция хэширования h. В качестве хорошей функции хэширования предлагалась SHArf-256. Тогда функцию вычисления MAC можно переписать следующим образом:

(К,т ) н-* SHA - 256(SHA - 2Щ К |т ) ) .

Между тем в предыдущем разделе мы рекомендовали воспользоваться ал­ горитмом НМАС с функцией хэширования SHA-256. Это можно записать так:

(К ,т ) SHA - 256{{К 0 а) |SHA - 2Щ {К 0 Ь) |т ) ) .

Почему же мы рекомендуем использовать НМАС, если первая конструк­ ция проще?

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

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

работы UMAC может различаться в 3-5 раз, в зависимости от точного набора значений параметров, а разные платформы предпочитают различные наборы параметров.

Ужасающее изобилие функций UMAC — результат непомерного стремле­ ния к оптимизации. В погоне за высокими скоростями разработчики UMAC создали версии функций на все случаи жизни, поскольку в каждой ситуации требуется выполнение конкретных оптимизаций.

Мы не согласны с этим подходом. Он имеет преимущества в краткосроч­ ной перспективе, однако обладает существенным недостатком в аспекте дол­ говременного пользования. В отличие от НМАС или SHA-1, у алгоритма UMAC нет единого стандарта. Разные разработчики используют разные вер­ сии UMAC. Чтобы осуществлять взаимодействие между такими системами, понадобится реализовать сразу несколько версий UMAC. Многие библиотеки позволяют выбирать набор параметров UMAC только во время компиляции, что создает целый ряд проблем, если приложению нужны две или более вер­ сии UMAC. Кроме того, на протяжении времени жизни криптографической системы — а это 20-30 лет — архитектура процессоров претерпит немало изменений. При таких условиях микрооптимизация, основанная на текущей архитектуре, просто не имеет будущего.

7.6.3 Платформенная гибкость

Как уже отмечалось, разные версии UMAC оптимизированы для конкрет­ ных платформ. Более того, каждая версия выдвигает достаточно строгие требования к своей платформе. Если у вас есть процессор с быстрой ко­ мандой умножения и достаточный объем памяти, UMAC способен достичь очень высоких скоростей. Тем не менее, на наш взгляд, он не сможет развить нужной производительности при работе со смарт-картами или другими 8-раз- рядными устройствами с ограниченным объемом памяти. Требования UMAC квременному хранилищу данных очень высоки, а смарт-карты всегда имеют ограниченный объем памяти.

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

4Некоторые уже давно твердят о том, что процессоры с малой разрядностью безнадежно устарели и в течение нескольких лет будут вытеснены новыми, более мощными процессора­ ми. Мы с этим не согласны. Процессоры с малой разрядностью применяются уже несколько десятилетий. Они не вымирают, а просто переходят в еще более "мелкие” системы. Появив­ шиеся па свет в начале 1970-х годов 8-разрядные процессоры до сих пор счастливо живут и здравствуют, хотя по прогнозам должны были бы исчезнуть, как минимум, 10 лет назад.

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

Т.6.4 Нехватка анализа

Еще одной проблемой алгоритма UMAC является недостаточный объем криптоанализа, которому была подвергнута его структура. Как уже отмеча­ лось, существует доказательство безопасности UMAC, но оно не заменяет со­ бой проведения анализа, исходя из позиций злоумышленника. Довольно мно­ го систем, имевших доказанную безопасность, впоследствии были взломаны. К сожалению, подобный недостаток присущ всем новым алгоритмам, таким, как AES, SHA-256, или некоторым конструкциям, предлагаемым в данной книге. Среди них наибольшего внимания со стороны криптоаналитиков, по­ жалуй, удостоился AES. (Мы это знаем, потому что сами принимали участие

вего анализе.) Функция SHA-256 была разработана Управлением националь­ ной безопасности США (NSA), предыдущие наработки которого были весьма неплохи. В NSA также работает большое количество экспертов. Некоторые из них, несомненно, анализировали функцию SHA-256 перед тем, как предоста­ вить ее на суд широкой общественности. Новые конструкции, предложенные

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

ипредположим, что вероятность полноты и правильности доказательства безопасности алгоритма UMAC составляет 95%. Однако в 5% случаев можно предположить, что UMAC не имеет доказательства безопасности, и такого рода вероятность нас совершенно не привлекает.

7.6.5Зачем тогда нужен UMAC?

“Если нам не нравится UMAC, то зачем же так много о нем говорить?” — спросите вы. Вообще-то мы думаем, что разработчики UMAC двигались в правильном направлении. Идея использовать неопределенность относитель­ но значения К для того, чтобы ускорить вычисление MAC, крайне ценна. Нам бы хотелось проделать еще ряд исследований в этой области. Где-то обязательно должна отыскаться функция вычисления MAC, которая будет более быстрой, чем функция хэширования, и вместе с тем такой же надежной и гибкой, как современные блочные шифры.

7.7 Какую функцию вычисления MAC выбрать

Как вы, наверное, уже догадались, мы отдаем предпочтение комбинации HMAC-SHA-256, т.е. алгоритму НМАС, в котором в качестве функции хэ­ ширования используется SHA-256. Мы бы действительно хотели, чтобы код аутентичности сообщения был 256-битовым. В большинстве систем, однако, используются лишь 64или 96-битовые значения MAC, и даже тогда мно­ гие жалуются на большие расходы. Добавление к каждому сообщению по 32 байт (256 бит) ни в коей мере не принесет популярности вашему проекту. Насколько мы знаем, для функции вычисления MAC не существует атак на основе коллизий, если использовать ее в классическом понимании, поэтому надеемся, что усечение результата алгоритма HMAC-SHA-256 до 128 бит не должно навредить безопасности системы.

Еще раз подчеркнем, что применять в качестве функции хэширования НМАС функцию SHAd-256 нет смысла, так как в алгоритме НМАС уже учте­ напроблема удлинения сообщения. Тем не менее для достижения 128-битово­ го уровня безопасности в НМАС следует использовать 256-битовую функцию хэширования, поэтому SHA-1 нам не подходит.

Нельзя сказать, что алгоритм НМАС полностью нас устраивает. Мы ве­ рим в существование более быстрых функций вычисления MAC, но подходя­ щих вариантов пока что не появилось.

7.8 Использование MAC

Правильно использовать MAC намного сложнее, чем кажется. Давайте посмотрим, в чем же состоят основные проблемы.

Когда пользователь Б получает значение МАС(АТ,т), он знает, что ктото, кому известен ключ К , подтвердил правильность сообщения т. Меж­ ду тем это отнюдь не обеспечивает действительной корректности сообщения. Злоумышленник Е мог записать сообщение, отправленное пользователем А пользователю Б, и затем послать копию этого сообщения пользователю Б ко­ гда-нибудь позднее. Если система последнего не имеет специальной защиты от такого типа атак, пользователь Б примет эту копию как корректное сооб­ щение от пользователя А. Аналогичные проблемы возникают, если пользова­ тели А и Б применяют один и тот же ключ К для аутентификации трафика сообщений в обоих направлениях. Злоумышленник Е может послать запи­ санное им сообщение обратно пользователю А, и тот поверит, что сообщение было отправлено пользователем Б.

Довольно часто пользователям А и Б нужно аутентифицировать не толь­ ко сообщение т , но и некоторые дополнительные данные d. Это может быть

130 Глава 7. Коды аутентичности сообщений

номер сообщения, используемый для защиты от атак воспроизведения (re­ play attacks), адрес источника и назначения сообщения и т.п. Большинство подобных полей являются частью заголовка аутентифицируемого (и часто зашифрованного) сообщения. Значение MAC должно обеспечивать аутенти­ фикацию не только т , но и d. Как правило, для решения этой проблемы функцию вычисления MAC применяют не к т, а к d |т.

Следующую проблему лучше всего определить с помощью правила про­ ектирования.

Правило проектирования 4. Принцип Хортона: аутентифицируйте не то, что сказано, а то, что имеется в виду.

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

Предположим, пользователь А применяет значение MAC для аутентифи­ кации сообщения т := а | 6 | с, где а, b и с — некоторые поля данных. Пользователь Б получает сообщение т и разбивает его на поля а, 6 и с. Но правильно ли он это делает? Разбивка на поля должна проводиться в соот­ ветствии с некоторыми правилами. Если эти правила не совпадают с теми, которые применяются пользователем А для построения сообщения, пользо­ ватель Б получит неправильные значения полей. Подобные ситуации крайне нежелательны, поскольку они означают возможность аутентификации фаль­ сифицированных данных. Поэтому очень важно, чтобы пользователь Б раз­ бивал сообщение т именно на те поля, из которых оно было составлено поль­ зователем А.

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