книги / Практическая криптография
..pdf7.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 является вполне приемлемым.