В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 14. Введение в криптографические протоколы отправка сообщений все-таки реализована, поскольку общие методы обра- ботки полученных повторных сообщений работают даже в том случае, если повторные сообщения не отправляются. Получив сообщение, следует решить, что с ним делать. Мы исходим из предположения, что все сообщения являются идентифицируемыми. Другими словами, мы точно знаем, каким именно сообщением протокола должно быть текущее полученное сообщение. Если мы получили то сообщение, которого ожидали, тогда все в порядке и мы продолжаем следовать правилам прото- кола. Теперь предположим, что мы получили сообщение “из будущего”, т.е. то сообщение протокола, которое ожидали получить в более поздний момент времени. Справиться с таким сообщением легко — просто проигнорируйте его. Не изменяйте состояние выполнения протокола и не отправляйте ответ; просто отбросьте сообщение — и все. Вероятно, оно являлось частью атаки. Даже в самых странных протоколах, где получение сообщения “из будущего” может быть всего-навсего частью цепочки ошибок, инициированных утерян- ными сообщениями, игнорирование сообщения будет иметь точно такой же эффект, что и потеря сообщения в процессе его передачи. Поскольку каждый протокол должен уметь справляться с потерей сообщения, игнорирование со- общений в любом случае не нанесет вреда. А как же быть со “старыми” сообщениями, которые уже были обрабо- таны протоколом когда-то в прошлом? Подобное событие может произойти в трех случаях. В первом полученное сообщение совпадает с предыдущим, на которое вы только что ответили. Возможно, оно было повторно отправ- лено вашим собеседником, поэтому на него следует ответить так же, как вы ответили перед этим. Обратите внимание, что ответ должен быть в точности таким же. Не пересчитывайте ответ с помощью другого случайного значения. Не стоит также просто предполагать, что полученное сообщение идентично предыдущему, на которое вы ответили. Это нужно проверить. Во втором случае идентификатор полученного сообщения равен иденти- фикатору сообщения, на которое вы ответили последним, но содержимое со- общения отличается. Например, предположим, что в протоколе DH пользо- ватель Б получает первое сообщение от пользователя А и затем получает еще одно сообщение, которое также помечено как первое сообщение протокола, но содержит другие данные. Это свидетельствует об атаке. Оно никогда бы не спровоцировало подобную ситуацию, поскольку повторное сообщение ни- когда не отличается от исходного. Либо второе сообщение, либо сообщение, на которое вы уже ответили, является поддельным. В целях безопасности по- добную ситуацию рекомендуется рассмотреть как ошибку протокола со всеми вытекающими отсюда последствиями, которые уже упоминались. (Игнори- рование полученного сообщения тоже вполне безопасно, но оно не позволит 14.5. Сообщения и действия 281 распознать многие виды активных атак. Это окажет нежелательное влияние на компоненты обнаружения и отклика системы безопасности.) В третьем случае мы получаем совсем старое сообщение, которое было впервые отправлено еще задолго до предыдущего. Сделать в данной ситу- ации можно не так уж много. Если вы все еще храните изначальное сооб- щение, которое было получено на той стадии протокола, то можете прове- рить, идентичны ли старое и новое сообщения. Если это действительно так, просто проигнорируйте сообщение. Если же сообщения неодинаковы, вы об- наружили атаку и должны обработать ее как ошибку протокола. Многие программы сохраняют не все сообщения, которые были получены во время выполнения протокола. В этом случае мы не сможем определить, совпадает ли новое сообщение с тем, что уже когда-то было получено. Такие сообще- ния рекомендуется просто проигнорировать — в любом случае это не нанесет вреда безопасности системы. Вы бы удивились, узнав, как часто подобное происходит с реальными протоколами. Иногда сообщения задерживаются на длительное время. Предположим, пользователь А отправил сообщение, кото- рое было задержано. Через несколько секунд пользователь А посылает по- вторное сообщение, которое на сей раз достигает своей цели, после чего оба пользователя продолжают выполнение протокола. Через полминуты поль- зователь Б получает исходное сообщение. С нашей точки зрения, подобная ситуация выглядит так, как если бы пользователь Б получил копию — в тер- минах протокола — очень старого сообщения. Ситуация становится намного сложнее, если у протокола есть более двух участников. Такие протоколы существуют, но их рассмотрение выходит за рамки данной книги. Если вам когда-нибудь придется разрабатывать про- токол с несколькими участниками, обратите особое внимание на повторения и воспроизведения. Еще одно замечание: узнать, было ли доставлено последнее сообщение протокола, невозможно. Если пользователь А отсылает последнее сообщение пользователю Б, он никогда не получит подтверждения того, что это сообще- ние действительно прибыло. Если же канал связи будет нарушен и пользо- ватель Б не получит последнего сообщения, он попытается повторить преды- дущее сообщение, но оно все равно не дойдет до пользователя А. Пользова- тель А, находящийся на “нормальном” конце протокола, не сможет опреде- лить, дошло сообщение или нет. Для решения этой проблемы в конец про- токола можно добавить специальное уведомление, отправленное пользовате- лем Б пользователю А, но тогда это уведомление станет новым последним сообщением, и проблема повторится. Криптографические протоколы следу- ет разрабатывать таким образом, чтобы описанная ситуация не повлияла на безопасность системы. |