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

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

131

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

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

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

В завершение необходимо отметить следующее: тщательно обдумайте, ка­ киеданные включать в процесс аутентификации. Все эти данные вместе с са­ мим сообщением должны быть представлены в виде строки байтов так, чтобы последнюю можно было уникальным образом разбить на исходные поля. Не забывайте применять это к результату конкатенации дополнительных дан­ ных и сообщения, которая упоминалась в начале этого раздела. Если вы со­ бираетесь аутентифицировать строку d |т , постарайтесь сформулировать фиксированное правило того, как разбивать полученную строку на поля d6

6Для тех, чье счастливое детство прошло ие в США, поясняем: Хортон — один из пер­ сонажей д-ра Сьюсса (Dr. Seuss), автора популярных детских книг [89].

Глава 8

Безопасный канал общения

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

8.1Формулировка проблемы

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

8.1.1Роли

Большинство соединений являются двунаправленными. Пользователь А отсылает сообщения пользователю Б, а пользователь Б отсылает сообщения пользователю А. Чтобы не перепутать эти потоки данных, протокол обмена данными должен обладать некоторой “асимметричностью”. В реальных систе­ мах одним из участников общения может быть клиент, а другим — сервер. Иногда для удобства говорят об инициаторе (участнике общения, иниции­ ровавшем безопасное соединение) и ответчике. В любом случае участникам общения нужно назначить роли пользователя А и пользователя Б, чтобы каждый четко знал, в какой роли он выступает.

Разумеется, у нас всегда есть злоумышленник Е, который пытается ата­ ковать безопасный канал общения всеми возможными способами. Злоумыш­ ленник Е может читать все сообщения, которыми обмениваются пользовате­ ли А и Б, и как угодно манипулировать этими сообщениями. В частности, злоумышленник Е может удалять, вставлять или изменять данные, переда­ ваемые по каналу общения.

8.1 Формулировка проблемы

133

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

8.1.2 Ключ

Чтобы реализовать безопасный канал общения, нам нужен какой-нибудь общий секрет. В данном случае предположим, что пользователи А и Б приме­ няют общий секретный ключ К , не известный никому, кроме них самих. Это очень важное свойство. Криптографические функции никогда не могут иден­ тифицировать пользователя А как физическое лицо. В большинстве случаев они идентифицируют ключ. Алгоритм верификации, применяемый пользо­ вателем Б, сообщает ему примерно следующее: “Это сообщение было посла­ но кем-то, кто знает ключ К и выступает в роли пользователя А”. Данное утверждение может пригодиться пользователю Б только в том случае, если он знает, что ключ К известен ограниченному числу лиц, например только ему самому и пользователю А.

На данном этапе нас не волнует конкретный способ выбора и распростра­ нения ключа. Мы просто предполагаем, что ключ уже есть. Об управлении ключами речь идет в главе 15, “Протокол согласования ключей”. К ключу К предъявляются следующие требования:

• он должен быть известен только пользователям А и Б;

•каждый раз при инициализации безопасного канала общения следует генерировать новое значение ключа К.

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

134 Глава 8. Безопасный канал общения

установки некоторого уникального ключа К и перезапускать этот протокол при каждой новой инициализации безопасного канала общения. Ключ К, ис­ пользуемый на протяжении только одного сеанса общения, называется клю­ чом сеанса (session key). Как генерировать ключи сеанса, описано в главе 15, “Протокол согласования ключей”.

Безопасный канал общения проектируется таким образом, чтобы достичь 128-битового уровня безопасности. Следуя правилу проектирования 3 (см. раздел 4.5.8), мы будем использовать 256-битовый ключ. Таким образом, дли­ на значения К составляет 256 бит.

8.1.3Сообщения или поток

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

Мы также предполагаем, что транспортная система, которая занимает­ ся доставкой сообщений от пользователя А к пользователю Б и наоборот, не является надежной. С криптографической точки зрения, даже надежный коммуникационный протокол наподобие TC P/IP не в состоянии сформиро­ вать надежный канал общения. В конце концов, злоумышленник может легко менять, удалять или вставлять данные в TCP-поток, не прерывая процесс пе­ редачи данных. Протокол TCP устойчив по отношению только к случайным событиям наподобие потери пакета. Он не защищен от активных атак. С на­ шей, “злодейской”, точки зрения, надежного коммуникационного протокола нет и быть не может. (Это хороший пример того, насколько разнятся взгляды криптографов на окружающий мир.)

8.1.4Свойства безопасности

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

8,1 Формулировка проблемы

135

Безопасный канал общения должен обладать следующими свойствами:

•злоумышленник Е ничего не знает о сообщениях пц кроме времени их отправки и размера;

•даже если злоумышленник Е атакует канал общения, манипулируя дан­ ными, отправленными пользователем А пользователю Б, последова­

тельность сообщений ..., полученная пользователем Б, являет­ ся подпоследовательностью последовательности сообщений mi, m2, •••,

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

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

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

136 Глава 8. Безопасный канал общения

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

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

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

8.2Порядок аутентификации и шифрования

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

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

8.2 Порядок аутентификации и шифрования

137

шифрования, исправляет недостатки последней и делает ее безопасной. Как видите, для реальных систем подобные теоретические результаты не име­ ют большого значения. В действительности существуют аналогичные дока­ зательства того, что такая проблема вообще не возникает для всех поточных шифров (таких, как режим CTR) и для режима СВС.

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

ирасшифровать сообщение, и проверить его значение MAC независимо от того, в каком порядке применялись шифрование и аутентификация. Если же сообщение является подцельным (т.е. имеет неправильное значение MAC), пользователь Б его отбросит. Если к сообщению вначале применялось шиф­ рование, а затем аутентификация, на стороне получателя операция дешиф­ рования будет проводиться после операции аутентификации. В этом случае пользователю Б не придется расшифровывать подцельные сообщения, по­ скольку он обнаружит и отбросит их еще до расшифровки. Если же к со­ общению сначала применялась аутентификация, а затем шифрование, поль­ зователю Б придется расшифровывать абсолютно все сообщения — только так он сможет проверить их значения MAC. Таким образом, во втором слу­ чае пользователю Б придется проделывать лишнюю работу по расшифровке поддельных сообщений. Данная проблема становится актуальной тогда, ко­ гдазлоумышленник Е отсылает пользователю Б большое количество фальси­ фицированных сообщений. Отбрасывая эти сообщения еще до расшифровки, пользователь Б снижает нагрузку на процессор. Кроме того, в некоторых (на­ до сказать, весьма редких) случаях применение данного подхода несколько затрудняет проведение атак типа “отказ в обслуживании” (denial-of-service — DOS). На практике большинство DOS-атак направлены на переполнение ка­ нала общения, а вовсе не на загрузку фальсифицированными сообщениями процессора пользователя Б. Лично нам этот аргумент не кажется убедитель­ ным, так как мы всегда готовы пожертвовать производительностью ради без­ опасности.

Существует два основных аргумента и в пользу второго подхода, при котором вначале применяется аутентификация, а затем шифрование. Если шифрование выполняется перед аутентификацией, злоумышленник Е видит

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

138	Глава 8. Безопасный канал общения

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

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

Второй аргумент в пользу подхода “сначала аутентификация, затем шиф­ рование” касается принципа Хортона. Аутентифицировать нужно не то, что сказано, а то, что имеется в виду. Аутентификация шифрованного текста нарушает это правило и создает еще одно потенциальное слабое место. Поль­ зователь Б может успешно аутентифицировать шифрованный текст, но затем расшифровать его с помощью неправильного ключа, отличного от того, ко­ торый применялся пользователем А для шифрования. В этом случае, даже несмотря на корректное прохождение аутентификации, пользователь Б по­ лучит не тот открытый текст, который был послан ему пользователем А. Данная проблема, в частности, присуща одной из конкретных (нестандарт­ ных) конфигураций протокола IPSec [32]. Для исправления этой ошибки ключ шифрования можно было бы включить в дополнительные данные, ко­ торые подвергаются аутентификации вместе с самим сообщением. Нам, од­ нако, не хотелось бы применять этот ключ в каких-либо других целях по­ мимо его стандартного назначения. Это связано с дополнительным риском; использование не очень надежной функции вычисления MAC может приве­ сти к утечке информации о ключе шифрования. Более удачным решением является генерация ключа шифрования и ключа аутентификации на основе одного и того же ключа безопасного канала общения (см. раздел 8.4.1). Дан­ ное решение позволяет устранить слабое место, но порождает перекрестную зависимость: система аутентификации приобретает зависимость от системы генерации ключей.

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

8,3 Структура решения

139

аутентификацию, а затем шифрование, поскольку простота и безопасность кажутся нам важнее экономии процессорного времени.

8.3Структура решения

Наше решение состоит из трех компонентов: нумерации сообщений, шиф­ рования и аутентификации.

8.3.1 Номера сообщений

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

Назначать сообщениям номера очень просто. Пользователь А нумерует первое сообщение как 1, второе как 2 и т.п. Пользователь Б запоминает но­ мер сообщения, которое было получено последним. Номер каждого нового сообщения должен быть больше номера предыдущего принятого сообщения. Принимая только сообщения с возрастающими номерами, пользователь Б га­ рантирует, что злоумышленник Е не сможет воспроизвести и отослать ему какое-нибудь старое сообщение.

Для разработки безопасного канала общения мы будем использовать 32битовые номера сообщений. Первому сообщению присваивается номер 1. Об­ щее количество сообщений ограничено числом 232- 1. Если количество сооб­ щений превысит это число, пользователю А придется прекратить примене­ ние текущего ключа и перезапустить протокол согласования ключей, чтобы сгенерировать новый ключ. Номер сообщения должен быть уникальным, по­ этому мы не можем позволить, чтобы он вернулся к нулю.

Разумеется, мы бы могли использовать и 64-битовые номера сообщений, но это потребовало бы слишком больших расходов. (К каждому сообщению пришлось бы добавлять не четыре лишних байта, а восемь.) Для большин­ ства систем вполне достаточно и 32-битовых номеров сообщений. Кроме того,

140 Глава 8. Безопасный канал общения

ключ все равно следует периодически изменять1. При необходимости вы, ко­ нечно, можете использовать 40или 48-битовые номера сообщений; особого значения это не имеет.

Почему мы начинаем нумеровать сообщения с единицы, если в языке С нумерацию принято начинать с нуля? Это небольшая хитрость реализации. Бели сообщениям могут быть присвоены N номеров, пользователям А и Б придется отслеживать N + 1 состояний. Действительно, ведь тогда количе­ ство отосланных сообщений может принимать любое значение из множества { 0 ,..., N }. Если ограничить количество возможных сообщений до 232— 1, это состояние может быть представлено с помощью одного 32-битового числа. Если бы нумерация сообщений начиналась с нуля, нам бы пришлось ввести дополнительный флаг, указывающий, что пользователь А еще не отослал ни одного сообщения или же что пространство номеров сообщений было исчерпа­ но. Наличие таких флагов требует реализации дополнительного и достаточно сложного кода, который практически никогда не будет использоваться. Если же этот код практически не используется, то и практически не тестируется, а значит, может отказать в нужный момент. По сути, введение дополнитель­ ного флага — лишь еще одно потенциальное слабое место, которого так легко избежать, начиная нумерацию сообщений с единицы.

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

8.3.2 Аутентификация

Для аутентификации сообщений мы будем использовать функцию вычис­ ления MAC. Как вы уже, наверное, догадались, это будет функция HMAC-SHA-256 с полным 256-битовым результатом. Входное значение функ­ ции вычисления MAC будет состоять из сообщения т , и дополнительных данных аутентификации х*. Как отмечалось в главе 7, “Коды аутентичности сообщений”, вместе с сообщением зачастую необходимо аутентифицировать и данные о контексте, в котором оно было отослано. Эти данные применяют­ ся пользователем Б для правильной интерпретации сообщения. Обычно они включают в себя номер версии протокола, размеры полей и подтверждение того, что это третье сообщение из последовательности сообщений, отправ­ ленных по каналу. Здесь мы просто определяем безопасный канал общения, поэтому реальное значение х* должно предоставляться оставшейся частью приложения. С нашей точки зрения, каждый элемент х, — это строка, зна­ чение которой одинаково для пользователей А и Б.*

гВсе ключи следует обновлять через разумные промежутки времени. Интенсивно ис­ пользуемые ключи необходимо обновлять почаще. Ограничение количества сообщений, которые могут быть зашифрованы или аутентифицированы с помощью одного и того же ключа, до 232 - 1 является вполне приемлемым.