В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 8. Безопасный канал общения какую функцию применять последней. Если последним применяется шифро- вание, злоумышленник сможет беспрепятственно нападать на функцию шиф- рования. Если же последней применяется аутентификация, злоумышленник будет нападать на функцию аутентификации. В общем случае аутентифика- ция важнее шифрования. Поэтому мы предпочитаем подвергнуть опасности функцию шифрования, но защитить значение MAC насколько это возможно. Вы не ослышались: вопреки мнению большинства, аутентификация дей- ствительно важнее шифрования. Для большей наглядности попробуйте пред- ставить себе использование безопасного канала общения. Подумайте, какой ущерб нанесет злоумышленник Е, если он сможет читать все сообщения. За- тем представьте, каков будет ущерб, если злоумышленник Е сможет изменять все эти сообщения. В большинстве случаев изменение данных оказывает воис- тину разрушающее воздействие на систему, а потому наносит намного больше ущерба, чем просто чтение этих данных кем-нибудь посторонним. Второй аргумент в пользу подхода “сначала аутентификация, затем шиф- рование” касается принципа Хортона. Аутентифицировать нужно не то, что сказано, а то, что имеется в виду. Аутентификация шифрованного текста нарушает это правило и создает еще одно потенциальное слабое место. Поль- зователь Б может успешно аутентифицировать шифрованный текст, но затем расшифровать его с помощью неправильного ключа, отличного от того, ко- торый применялся пользователем А для шифрования. В этом случае, даже несмотря на корректное прохождение аутентификации, пользователь Б по- лучит не тот открытый текст, который был послан ему пользователем А. Данная проблема, в частности, присуща одной из конкретных (нестандарт- ных) конфигураций протокола IPSec [32]. Для исправления этой ошибки ключ шифрования можно было бы включить в дополнительные данные, ко- торые подвергаются аутентификации вместе с самим сообщением. Нам, од- нако, не хотелось бы применять этот ключ в каких-либо других целях по- мимо его стандартного назначения. Это связано с дополнительным риском; использование не очень надежной функции вычисления MAC может приве- сти к утечке информации о ключе шифрования. Более удачным решением является генерация ключа шифрования и ключа аутентификации на основе одного и того же ключа безопасного канала общения (см. раздел 8.4.1). Дан- ное решение позволяет устранить слабое место, но порождает перекрестную зависимость: система аутентификации приобретает зависимость от системы генерации ключей. Можно до хрипоты спорить о том, в каком порядке лучше выполнять шифрование и аутентификацию. Оба решения могут служить основой как для хороших, так и для плохих систем. Каждый подход имеет свои преиму- щества и недостатки, поэтому окончательный выбор зависит от того, какую из операций вы считаете более важной. Мы предпочитаем сначала проводить 8.3. Структура решения 139 аутентификацию, а затем шифрование, поскольку простота и безопасность кажутся нам важнее экономии процессорного времени. 8.3 Структура решения Наше решение состоит из трех компонентов: нумерации сообщений, шиф- рования и аутентификации. 8.3.1 Номера сообщений Номера сообщений очень важны по ряду причин. Они могут применяться для генерации векторов инициализации, используемых в некоторых алгорит- мах шифрования. Они позволяют получателю отбрасывать сообщения, вос- произведенные злоумышленником, не требуя наличия большой базы данных сообщений. С их помощью можно определить, какие сообщения были поте- ряны в процессе передачи по каналу общения. И наконец, они гарантируют, что пользователь Б будет получать сообщения в правильном порядке. По этим причинам номера сообщений должны монотонно возрастать (т.е. более поздние сообщения должны иметь б´ольшие номера, чем более ранние) и быть уникальными (не должно быть двух разных сообщений, имеющих одинако- вые номера). Назначать сообщениям номера очень просто. Пользователь А нумерует первое сообщение как 1, второе как 2 и т.п. Пользователь Б запоминает но- мер сообщения, которое было получено последним. Номер каждого нового сообщения должен быть больше номера предыдущего принятого сообщения. Принимая только сообщения с возрастающими номерами, пользователь Б га- рантирует, что злоумышленник Е не сможет воспроизвести и отослать ему какое-нибудь старое сообщение. Для разработки безопасного канала общения мы будем использовать 32- битовые номера сообщений. Первому сообщению присваивается номер 1. Об- щее количество сообщений ограничено числом 2 32 − 1 . Если количество сооб- щений превысит это число, пользователю А придется прекратить примене- ние текущего ключа и перезапустить протокол согласования ключей, чтобы сгенерировать новый ключ. Номер сообщения должен быть уникальным, по- этому мы не можем позволить, чтобы он вернулся к нулю. Разумеется, мы бы могли использовать и 64-битовые номера сообщений, но это потребовало бы слишком больших расходов. (К каждому сообщению пришлось бы добавлять не четыре лишних байта, а восемь.) Для большин- ства систем вполне достаточно и 32-битовых номеров сообщений. Кроме того, |