В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 16. Проблемы реализации. Часть II каждой операции с участием открытого ключа, но и время, которое прохо- дит между принятием запроса и отправкой ответа. Если запрос поступает в момент времени t , мы должны отправить ответ в момент времени t + C , где C — некоторая константа. Впрочем, чтобы окончательно исключить вся- кую возможность утечки информации о времени выполнения вычислений, нам следовало бы гарантировать, что ответ на запрос действительно будет готов к моменту времени t + C . Для достижения этой цели частоту принятия входных запросов, вероятно, понадобится ограничить до некоторого фикси- рованного верхнего уровня. 16.4 Протоколы В контексте реализации криптографические протоколы не очень отлича- ются от коммуникационных. Самый простой метод реализации протокола — отслеживание его состояния с помощью программного счетчика и поочеред- ное выполнение всех необходимых шагов протокола. Если в подобной системе не используется многопоточность, на время ожидания ответа ее жизнедея- тельность замирает. Поскольку ответ не всегда приходит вовремя (а иногда не приходит вообще), данную идею нельзя назвать удачной. Более правильно сохранять явное состояние протокола и обновлять его каждый раз при получении нового сообщения. Реализовать данный подход несколько сложнее, но в то же время он обеспечивает гораздо больше гибко- сти, нежели предыдущий. 16.4.1 Выполнение протоколов поверх безопасного канала общения Многие криптографические протоколы выполняются поверх небезопас- ных каналов общения. Иногда, впрочем, имеет смысл запускать протокол поверх безопасного канала общения. В качестве примера можно привести ситуацию, когда каждый пользователь взаимодействует с центром распро- странения ключей (ЦРК) по безопасному каналу общения. ЦРК применяет простой протокол для распространения ключей между пользователями си- стемы, чтобы те могли общаться друг с другом. (Что-то подобное выполняет протокол Kerberos.) Если вы применяете криптографический протокол для взаимодействия с участником, с которым вы уже обменялись ключом, сле- дует использовать полную функциональность безопасного канала общения. В частности, требуется реализовать защиту от атак воспроизведения. Это не составит труда, зато позволит предотвратить большое количество атак на криптографические протоколы. 16.4. Протоколы 315 Иногда наличие безопасного канала общения позволяет сократить функ- циональность протокола. Например, если безопасный канал общения обес- печивает защиту от атак воспроизведения, самому протоколу этого делать не нужно. Тем не менее старое доброе правило модуляризации гласит, что протокол должен минимизировать свою зависимость от безопасного канала общения. В дальнейшем при обсуждении реализации нашего протокола будем пред- полагать, что протокол выполняется поверх небезопасного канала общения. Некоторые моменты нашего обсуждения будут не вполне применимы к вы- полнению протокола поверх безопасного канала общения, но предложенные решения не повредят и в этом случае. 16.4.2 Получение сообщения Когда состояние протокола получает новое сообщение, нам нужно про- вести несколько проверок. Вначале следует убедиться, принадлежит ли по- лученное сообщение заданному протоколу. Каждое сообщение должно начи- наться описанными ниже полями. • Идентификатор протокола. В точности идентифицирует протокол и его версию. Особо важную роль здесь играют идентификаторы версий. • Идентификатор экземпляра протокола. Идентифицирует, к како- му экземпляру протокола принадлежит данное сообщение. Пользовате- ли А и Б могут одновременно запустить два сеанса протокола согласо- вания ключей, и мы не хотим их перепутать. • Идентификатор сообщения. Идентифицирует сообщение в рамках заданного протокола. Самый легкий способ идентификации — просто пронумеровать сообщения. В зависимости от ситуации, некоторые из перечисленных идентифика- торов могут быть неявными. Например, для протоколов, которые выполня- ются поверх собственного соединения TCP, номер порта и связанный с ним сокет однозначно идентифицируют экземпляр протокола. Отметим также, что идентификатором протокола и информацией о его версии достаточно обменяться лишь однажды. С другой стороны, пользователи должны как минимум один раз обменяться этими сведениями, чтобы впоследствии они охватывались всеми процедурами аутентификации или проверки цифровых подписей, присутствующими в протоколе. Проверив идентификаторы протокола и его экземпляра, мы узнаем, како- му состоянию протокола следует переслать данное сообщение. Предположим, состояние протокола только что отослало сообщение номер n − 1 и ожидает прихода сообщения номер n . |