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