В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 8. Безопасный канал общения MsgCntRec ← i return m В этом алгоритме использован канонический порядок операций. Вообще- то номер сообщения можно было бы проверять и перед расшифровкой, одна- ко, если бы он был искажен злоумышленником, наша функция сгенерировала бы не ту ошибку, которую нужно. Вместо уведомления о том, что сообщение было искажено, пользователь был бы оповещен о неправильном порядке сооб- щений. Поскольку подобные ситуации зачастую требуется обрабатывать по- разному, данная функция не должна предоставлять неверную информацию. Проверку номера сообщения ставят перед расшифровкой для того, чтобы быстрее отбрасывать ложные сообщения. Нам этот аспект не кажется очень важным; если вы получаете так много ложных сообщений, что скорость их отклонения начинает иметь значение, следовательно, вы столкнулись с го- раздо более серьезными проблемами. Нельзя не отметить еще один важный момент, касающийся получателя сообщений. Функция ReceiveMessage не должна раскрывать никакой ин- формации о ключе или открытом тексте сообщения до тех пор, пока сообще- ние не прошло аутентификацию. Если аутентификация окончится неудачей, функция должна уведомить получателя об ошибке, но не возвращать ника- кой информации о ключевом потоке или открытом тексте. Вместо этого она должна очистить области памяти, в которых те хранились. Почему это так важно? Наличие открытого текста сообщения позволяет вычислить ключевой поток, поскольку мы исходим из предположения, что злоумышленник знает шифрованный текст. Опасность состоит в том, что злоумышленник отошлет ложное сообщение (с некорректным значением MAC). Сообщение будет от- брошено, но злоумышленник все равно узнает ключевой поток по данным, выданным функцией получателя. Как видите, в дело вновь вступает пара- ноидальная модель, согласно которой любая информация, преждевременно раскрытая или упущенная функцией ReceiveMessage , автоматически по- падает в руки злоумышленника. Уничтожая данные, хранящиеся в перемен- ных k и m , еще до того как функция ReceiveMessage возвратит ошибку, мы предотвращаем какую-либо утечку этих данных. 8.4.4 Порядок сообщений Как и отправитель, получатель обновляет состояние S , изменяя значение переменной MsgCntRec . Получатель гарантирует, что номера принятых им сообщений строго возрастают. Это исключает возможность повторного при- нятия одного и того же сообщения, однако, если в процессе передачи по сети поток сообщений будет переупорядочен, получателю придется отбросить це- лый ряд совершенно корректных (во всем остальном) сообщений. 8.5. Альтернативы 147 Это упущение довольно легко исправить (хотя и за счет некоторых рас- ходов). Если разрешить получателю принимать сообщения вне зависимости от их порядка, тогда приложение, использующее безопасный канал общения, должно обладать возможностью обработки сообщений, номера которых “вы- биваются” из общей последовательности. Многие приложения не способны справиться с подобной ситуацией. Некоторые системы могут обрабатывать неупорядоченные сообщения, однако обладают небольшими изъянами (зача- стую в области безопасности). В большинстве ситуаций мы предпочитаем исправлять ошибки транспортного уровня и гарантировать, что случайное перемешивание сообщений невозможно, а значит, безопасному каналу обще- ния не придется сталкиваться с подобной проблемой. Порой возникает ситуация, когда получатель допускает прием сообщений, прибывших не по порядку; и тому есть очень важная причина. Речь идет об IPSec — протоколе безопасности IP (IP Security) [50], который выполняет шифрование и аутентификацию IP-пакетов. Поскольку IP-пакеты могут быть переупорядочены в процессе передачи по сети и все приложения, использую- щие протокол IP, знают об этом свойстве, IPSec не просто запоминает номер последнего полученного сообщения, а отслеживает целый диапазон номеров сообщений. Если c — это номер последнего полученного сообщения, IPSec ор- ганизует битовую карту для номеров сообщений c − 31 , c − 30 , c − 29 , . . . , c − 1 , c . Каждый бит этой карты указывает на то, было ли получено сообщение с соот- ветствующим номером. Сообщения с номерами, меньшими чем c − 31 , всегда отклоняются. Сообщения с номерами в диапазоне от c − 31 до c − 1 принимают- ся только тогда, когда значение соответствующего бита равно 0 (разумеется, после этого оно изменяется на 1). Если же номер нового сообщения больше c , значение c обновляется, а битовая карта соответствующим образом сдвигает- ся. Подобная схема допускает ограниченный прием переупорядоченных сооб- щений и при этом не требует хранить слишком много сведений о состоянии. 8.5 Альтернативы Данное нами определение безопасного канала общения не всегда практич- но. В частности, реализация безопасного канала общения во встроенном аппа- ратном обеспечении с использованием функции SHA-256 обходится слишком дорого. А нет ли каких-нибудь альтернативных решений? Когда мы писали эту книгу, Нильс работал с клиентом, который столк- нулся с аналогичной проблемой. Вначале в качестве режима работы блочно- го шифра предполагалось использовать OCB [82, 83]. Преимущество данного режима состоит в том, что и аутентификация и шифрование выполняются с помощью блочного шифра, а потому не требуют реализации дополнитель- |