В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 16. Проблемы реализации. Часть II Если полученное сообщение действительно имеет номер n , значит, все в порядке. Просто обработайте его в соответствии с правилами протокола. Но что, если номер сообщения будет другим? Если номер полученного сообщения больше n или меньше n − 1 , это сви- детельствует о том, что в системе не все в порядке. Подобное сообщение не могло быть сгенерировано системой, а значит, является подделкой. Содержи- мое такого сообщения следует проигнорировать. Если полученное сообщение имеет номер n − 1 , значит, отправленное со- общение n могло быть утеряно. По крайней мере это могло случиться, если протокол выполняется поверх ненадежного транспортного уровня. Посколь- ку мы хотим минимизировать зависимость протокола от других частей си- стемы, то предполагаем именно наличие ненадежного канала общения. Вначале проверьте, совпадает ли только что полученное сообщение n − 1 с сообщением n − 1 , полученным ранее. Если они отличаются, новое сообщение следует проигнорировать. Отправка второго ответа приведет к нарушению безопасности многих криптографических протоколов. Если же сообщения аб- солютно идентичны, просто еще раз отправьте сообщение n . Разумеется, оно должно быть полностью идентичным предыдущему сообщению n , которое было отослано ранее. Если в соответствии с одним из перечисленных выше правил сообщение было проигнорировано, необходимо принять еще одно решение. Нужно ли инициировать аварийное завершение протокола? Ответ на этот вопрос в неко- торой степени зависит от используемого приложения и самой ситуации. Если протокол выполнялся поверх безопасного канала общения, наличие подоб- ных сообщений свидетельствует о взломе безопасного канала общения либо о злонамеренных действиях второго участника. И в том и в другом случае выполнение протокола и канала общения должно быть аварийно заверше- но. Просто удалите состояние протокола и состояние канала общения вместе с ключом последнего. Если протокол выполняется поверх небезопасного канала общения, тогда отправка каждого из отброшенных сообщений могла быть делом рук зло- умышленника, пытающегося вмешаться в выполнение протокола. В идеале нам нужно было бы проигнорировать сообщения злоумышленника и просто завершить протокол. Это, конечно же, не всегда возможно. Например, если поддельное сообщение n − 1 дойдет до нас первым, мы отправим ответ. Ес- ли позднее мы получим “настоящее” сообщение n − 1 , то будем вынуждены его проигнорировать. Разрешить данную проблему невозможно, поскольку мы не можем отправить второй ответ, не подвергая риску безопасность си- стемы. Но мы не знаем, какое из двух полученных сообщений с номером n − 1 было настоящим. Поэтому следует просто занести в журнал сведения об ошибке, вызванной получением второго сообщения с номером n − 1 , и про- 16.4. Протоколы 317 должать выполнение протокола как обычно. Если сообщение, на которое мы ответили, было создано злоумышленником, выполнение протокола рано или поздно даст сбой, поскольку криптографические протоколы специально раз- рабатываются таким образом, чтобы помешать злоумышленнику успешно за- вершить протокол с одним из его участников. 16.4.3 Время ожидания Выполнение каждого протокола включает в себя ожидание ответа. Если вы не получаете ответ на сообщение в течение определенного периода вре- мени, вы можете повторно отослать последнее сообщение. После нескольких безуспешных попыток отослать сообщение с этой идеей придется расстаться. Зачем продолжать выполнение протокола, если вы не можете взаимодейство- вать со вторым участником? Самый простой способ реализовать время ожидания — это отсылать со- стоянию протокола сообщения об истекшем времени. Для контроля за вре- менем ожидания можно применять таймеры, значения которых явно уста- навливаются протоколом, или же сообщения, которые отсылаются каждые несколько секунд или около того. Одним из распространенных типов атак является отправка на конкрет- ный компьютер огромного количества сообщений типа “начало протокола”. Каждый раз, когда система получает подобное сообщение, она инициирует новое состояние выполнения протокола. Через несколько миллионов подоб- ных сообщений у компьютера заканчивается память и система “зависает”. В качестве хорошего примера подобной атаки можно привести синхронную атаку (SYN flood attack) . Защититься от таких атак очень сложно, но они показывают, как важно удалять устаревшие состояния протокола. Если вы- полнение протокола замерло и не возобновляется в течение слишком долгого времени, его состояние необходимо удалить. Величина времени ожидания постоянно является предметом ожесточен- ных споров. По своему опыту мы знаем, что пакет, отправленный по Internet, доходит до адресата примерно через секунду или же не доходит вообще. Если в течение пяти секунд на сообщение не было получено ответа, имеет смысл отправить его еще раз. Трех попыток должно быть вполне достаточно; если уровень потери сообщений настолько высок, что мы потеряли четыре по- следовательных сообщения за 15 с, данное соединение вряд ли годится для выполнения протокола. Мы предпочитаем проинформировать пользователя о проблеме уже через 20 с, а не заставлять его пребывать в напрасном ожи- дании ответа несколько минут или более. |