В. Р. Гинзбург Перевод с английского
жүктеу/скачать 2,74 Mb. Pdf көрінісі
|
практическая криптография
Глава 14. Введение в криптографические протоколы Поле фиксированной длины, одинаковое для всех версий протокола, легко поддается анализу. Мы знаем, какой в точности должна быть длина этого поля. Проблемы начинаются тогда, когда размер или значение поля зависят от некоторой контекстной информации, такой, как более ранние сообщения, отправленные в рамках соответствующего протокола. Это открывает массу возможностей для злоумышленников. Многие сообщения в криптографических протоколах аутентифицируют- ся с помощью цифровой подписи или каким-либо другим способом. Функция аутентификации работает со строкой байтов, поэтому аутентифицировать со- общение проще всего на транспортном уровне. Если интерпретация сообще- ния зависит от некоторой контекстной информации, проверка подписи или кода аутентичности сообщения может давать неоднозначные результаты. Мы уже взламывали несколько протоколов, пользуясь подобной ошибкой. Для кодирования полей хорошо использовать кодировку TLV (Tag–Length– Value — дескриптор–длина–значение). Согласно ей каждое поле кодируется тремя элементами данных. Первый элемент (дескриптор) идентифицирует текущее поле, второй (длина) задает длину значения в закодированном ви- де, а третий (значение) — это и есть фактические данные, которые должны быть закодированы. Самой известной кодировкой TLV является ASN.1 [42], но она настолько сложна и плохо определена, что мы предпочитаем держать- ся от нее подальше. Впрочем, некоторые элементы ASN.1 могли бы оказаться весьма полезными. Более новой альтернативой ASN.1 является XML. Забудьте всю шуми- ху, раздутую вокруг XML; мы собираемся использовать его лишь в каче- стве системы кодирования данных. Если для кодирования сообщений будет применяться фиксированный шаблон DTD (Document Template Definition — описание шаблона документа), синтаксический анализ будет контекстно-неза- висимым и проблем с восстановлением исходного вида сообщений у нас не возникнет. 14.5.4 Состояние выполнения протокола Во многих реализациях криптографических протоколов один и тот же компьютер может одновременно принимать участие в выполнении сразу не- скольких протоколов. Чтобы следить за каждым из этих процессов, понадо- бится ввести состояние выполнения протокола. Последнее будет содержать всю информацию, необходимую для успешного завершения протокола. Реализация протоколов требует применения событийно-управляемого программирования (event-driven programming) , поскольку продолжение рабо- ты каждого протокола зависит от получения внешних сообщений. Это можно реализовать разными способами, например выделяя один поток или процесс 14.5. Сообщения и действия 277 под выполнение каждого протокола или же используя какую-нибудь систему управления событиями. При наличии событийно-управляемой инфраструктуры реализовать крип- тографический протокол будет сравнительно несложно. Состояние протокола содержит конечный автомат, который указывает, какого типа должно быть следующее сообщение. В общем случае сообщения других типов не принима- ются. Если в систему поступает сообщение ожидаемого типа, оно анализиру- ется и обрабатывается согласно установленным правилам. 14.5.5 Ошибки Криптографические протоколы всегда включают в себя массу проверок. К их числу относятся контроль типа протокола и типа сообщения, провер- ка того, принадлежит ли полученное сообщение к типу, заданному состоя- нием выполнения протокола, анализ сообщения и выполнение необходимых криптографических проверок. Если хотя бы одна из этих проверок окончится неудачей, в системе будет сгенерирована ошибка. Поскольку ошибки представляют собой потенциальный путь нападения на систему, они нуждаются в самой тщательной обработке. Наиболее без- опасное решение — при обнаружении ошибки не посылать никаких ответных сообщений и моментально удалить состояние протокола. Это минимизирует количество информации, которое злоумышленник может получить о прото- коле. К сожалению, подобную систему, которая никак не сигнализирует об обнаружении ошибки, едва ли можно назвать дружественной. Чтобы система действительно была удобна в использовании, нам могут потребоваться сообщения об ошибках. Если это возможно, не посылайте со- общения об ошибках другим участникам протокола. Запишите сообщение об ошибке в журнал, хранящийся в безопасном месте, чтобы системный адми- нистратор смог определить причину проблемы. Если же вы должны послать сообщение об ошибке, постарайтесь сделать его как можно менее информа- тивным. Зачастую вполне достаточно простого сообщения, например: “Это ошибка”. Отправка сообщений об ошибках особенно опасна при осуществлении тай- минг-атак. Злоумышленник Е может отправить пользователю А фальсифи- цированное сообщение и подождать ответа. Время, которое потребуется поль- зователю А для того, чтобы обнаружить ошибку и отослать ответ, часто поз- воляет определить, что именно в сообщении было неправильным и до какого момента все шло так, как нужно. Вот хороший пример того, какую опасность могут представлять подобные взаимодействия. Много лет назад Нильс работал с коммерческой системой смарт-карт. Для активизации такой смарт-карты пользователю требовалось |