4.3. Протоколы на основе асимметричных криптосистем
Криптографические протоколы разрабатываются на основе не только симметричных, или одноключевых (с одним и тем же ключом для шифрования и дешифрования), но и асимметричных, или двухключевых криптосистем [44]. Особенность асимметричной схемы заключается в том, что в прямом криптографическом преобразовании применяется открытый (шифрование) или секретный (вычисление цифровой подписи) ключ, а в обратном преобразовании — секретный (дешифрование) или открытый (проверка цифровой подписи) ключ, то есть ключи в прямом и обратном преобразовании всегда различны. Кроме того, прямое и обратное преобразования взаимно обращаемы. Так, если К открытый, К-1 секретный ключ, а С, М — шифротекст и открытый текст соответственно, то при заданном С = {М}K от- крытый текст может быть получен в результате преобразования М = {С}К-1. Аналогично при С = {М}К-1 М = {C}K.
Таким
образом, если Алиса и Боб опубликовали свои открытые ключи КА и Кв при
условии сохранения в секрете парных ключей К
передача сообщения М
осуществляется следующим образом [161]. Для шифрования сообщения М Алиса
последовательно применяет прямое криптографическое преобразование на ключах К
(секретный ключ
Алисы) и КB (открытый ключ Боба):
Для
дешифрования полученного сообщения Боб последовательно применяет обратное
криптографическое преобразование на ключах К
(секретный ключ Боба) и КA (открытый ключ Алисы).
Очевидная
атака заключается в том, что злоумышленник может сгенерировать пару ключей КX, К
и поместить КX в общедоступный справочник с утверждением, что данный
ключ принадлежит Алисе. Тогда все секретные сообщения, адресованные Алисе,
будут зашифрованы на ключе КX и, следовательно, раскрыты злоумышленником
(дешифрованием на ключе К). Таким образом, проблема
обеспечения конфиденциальности при передаче сообщений сводится к проблеме
доказательства подлинности источника сообщений (аутентификации).
Известным способом решения сформулированной проблемы является создание доверенного центра сертификации — некоторого аналога сервера аутентификации. Для этого Сэм (центр сертификации) обеспечивает каждого абонента криптосети специальным сертификатом. В упрощенном виде сертификат можно рассматривать как структурированную запись в базе данных, состоящую из имени абонента, открытого ключа, прав доступа, срока действия сертификата и других атрибутов, скрепленных цифровой подписью центра сертификации. Тогда валидности цифровой подписи сертификата (проверка осуществляется с помощью открытого ключа центра) позволяет установить подлинность открытого ключа конкретнога-абонента криптосети. Например, сертификат Алисы будет выглядеть следующим образом:
Однако сертификаты не позволяют полностью решить проблему. Например, один из первых криптографических протоколов, разработанный Демпинг (Denning) и Сакко (Sacco) в 1982 г, предназначался для распределения секретных сеансовых ключей:
Только в 1994 г. Абади (Abadi) раскрыл существенный недостаток данного протокола. Суть его заключается в том, что Боб, получив сообщение Алисы (сообщение на шаге 3), меж выдавать себя за Алису в течение срока действия временной метки ТА.
Предположим,
Боб желает выдать себя за Алису при взаимодействии с Чарли. Для этого он
обращается к Сэму, получает сертификат Чарли СС, выполняет
дешифрование сообщения, полученного от Алисы на 3 шаге протокола, далее шифрует
сообщение {ТА,КAB)
на, открытом
ключе Чарли (из сертификата СC) и затем
посылает Чарли сообщение:
Уязвимость данного протокола объясняется отсутствием уникального имени абонента респондента в сообщениях протокола.
Рассмотрим еще один протокол, предложенный Ву (Woo) и Сэмом (Lam) [50]:
Очевидный недостаток здесь заключается в том, что Боб не проверяет уникальность сообщений протокола с помощью временных меток или одноразовых случайных чисел (nonce). Отсутствие цифровой подписи сообщений со стороны Алисы приводит к более серьезным проблемам. В результате Боб может доказать факт существования Алисы только самому, себе и не может доказать этого третьей стороне. Некоторые протоколы на базе двухключевых криптоалгоритмов гарантируют возможность доказательства принадлежности в случае отказа от ранее переданного сообщения, однако в общем случае нарушение механизма аутентификации представляет собой реальную угрозу.
4.4. Протокол с «двуликим Янусом»
Конвей (Л. Conway) в свое время заметил, что очень просто победить гроссмейстера при игре в шахматы по почте. Стратегия заключается в том, чтобы разыграть одну партию одновременно с двумя гроссмейстерами, передавая ходы белых тому, кто играет черными, и наоборот. Таким образом, человека, играющего в шахматы указанным способом, можно сравнить с «двуликим Янусом», повернутым одним своим лицом к игроку белыми, а другим-К игроку черными фигурами.
Аналогичная идея может быть использована для атаки криптографических протоколов. Например, Нидхейм и Шредер в 1978 г., сразу же вслед за первой фундаментальной работой по двухключевой криптографии [44], предложили следующий протокол аутентичного ключевого обмена [45]. Рассмотрим шаги протокола исходя из предположения, что Алиса и Боб заранее обменялись своими сертификатами:
Описанный протокол впервые был исследован в работе [41] в 1989 г. Тем не менее в 1995 г. Лов (Lowe) провел дополнительное исследование [46] и продемонстрировал уязвимость протокола при атаке со стороны «двуликого Януса». Рассмотрим ситуацию, когда Чарли находится между Алисой и Бобом. При этом Чарли взаимодействует с Алисой от своего лица, но выдает себя за Алису, взаимодействуя с Бобом:
Способ противодействия атаке заключается в указании уникального имени абонента внутри сообщения.
Рассмотрим
протокол, введенный стандартом CCITT Х.509 для управления сертификацией в
иерархической структуре [47]. В 1989 году Барроуз (Burrows), Абади (Abadi) и
Нидхэйм (Needham) предложили атаку на протокол Х.509 [41]. Кратко изложим идею
атаки. В соответствии с протоколом Алиса подписывает сообщение вида {TA, NA,
В, Х, {Y}
},
где TA— временная метка, NA — серийный номер, а Х и Y — некоторые
данные, и посылает его Бобу. Поскольку подпись всего сообщения выполняется
после шифрования Y, существует возможность замены подписи Алисы на подпись
злоумышленника. Механизм атаки существенно зависит от математических свойств
применяемого криптоалгоритма.
Таким образом, вычисление подписи после шифрования приводит к разрушению механизма аутентификации. Последнее может означать, например, невозможность доказательства принадлежности в случае отказа от ранее переданного сообщения.
4.6. Протокол для сетей подвижной радиосвязи
В последние годы возникла задача разработки криптографических протоколов для сетей подвижной 1задиосвязи. Работа в сети осуществляется с помощью портативных приемопередатчиков, причем ограниченный объем памяти и невысокая производительность процессора не позволяют хранить большое количество ключей и выполнять сложные криптографические вычисления. Решение, применяемое на практике, заключается в создании центрального сервера, в задачу которого входят установление и поддержка защищенного режима взаимодействия абонентов сети.
Интересный вариант протокола для сетей подобного типа был предложен в 1989 г. Татебаяши (М. Tatebayashi), Матцузаки (N. Matsuzaki) и Ньюманом (D.В. Newman) [48]. TMN- протокол разработан исходя из предположения, что персональное устройство абонента сети (например, Smart Card) позволяет выполнять некоторые криптографические вычисления — возводить в куб по модулю двусоставного числа, суммировать по модулю 2, а также выполнять шифрование/дешифрование с помощью стандартного криптоалгоритма (например, DES). Известно [40], что арифметическая операция возведения в куб по модулю двусоставного числа (произведение двух простых чисел) обладает свойствами однонаправленной функции, то есть функции, которую легко вычислить, но трудно обратить. Таким образом, вычисление кубического корня по модулю двусоставного числа представляет собой трудоемкую задачу. Однако при известных сомножителях данная задача решается существенно более просто. Следовательно, сложность вычисления кубического корня эквивалентна сложности факторизации двусоставного числа [39].
Рассмотрим взаимодействие Алисы и Боба при условии, что Сэм (сервер) знает сомножители модуля N, причем все остальные абоненты знают N, но не знают сомножителей:
Алиса и Боб генерируют случайные числа RA и RB соответственно, возводят их в куб по модулю N и посылают Сэму. Сэм, зная разложение числа N, берет кубический корень и получает числа RA и RB. Далее Сэм суммирует (по модулю 2) полученные числа и возвращает; результат Алисе. Теперь Алиса может вычислить RB, так как RB = RAΘ (RA ΘRB). Боб: знает число RB по построению, следовательно, Алиса и Боб имеют общий сеансовый секретный ключ для шифрования/дешифрования конфиденциальной информации. В результате пассивного перехвата криптоаналитик противника получает три шифротекста: зашифрованные на открытом ключе сервера одноразовый ключ RA, сеансовый ключ RB и их сумму по модулю 2. Соответственно имеется две возможности: раскрыть сеансовый ключ методом силовой атаки или выполнить факторизацию модуля N, атаковать безусловно секретный шифр Вернама RA Θ RB. В работе [48] доказано, что секретность сеансового ключа эквивалентна сложности факторизации числа N
Тем не менее в 1994 г. Симмонс (G. J. Simmons) показал, что протокол может быть успешно атакован [49]. Любой легальный абонент сети, например Чарли (С), при содействии другого легального абонента, например Дэйва (D), может легко раскрыть сеансовый ключ RB. Для этого Чарли договаривается с Дэйвом о сеансовом ключе, который будет сгенерирован Дэйвом по запросу сервера, то есть сеансовый ключ RD известен Чарли заранее. Тогда протокол будет состоять из следующей последовательности шагов:
На первом
шаге Чарли, воспользовавшись шифротекстом, перехваченным при взаимодействии
Боба и Сэма, формирует сообщение R
mod N) mod N
и посылает его Сэму с запросом на установление соединения между ним и
Дэйвом. Отметим, что Сэм в силу криптографических свойств преобразования не
может контролировать структуру принятого сообщения, даже если сохраняет все
предыдущие сообщения других абонентов сети. Далее, следуя дисциплине протокола,
Сэм запрашивает сеансовый ключ от Дэйва. Взяв кубический корень и расшифровав
тем самым сеансовый и одноразовый ключи, Сэм вычисляет их сумму (по модулю 2) RD Θ RC RB
и посылает Чарли. Поскольку Чарли знает RD
(в силу предварительной договоренности с Дэйвом), он может легко вычислить RC RB = RD Θ (RD Θ RC RB). Теперь для раскрытия сеансового ключа Боба
Чарли сначала должен вычислить R
(всегда может сделать, так как
знает RC) и затем RB= R(RC RB) = (R(RD Θ
(RD Θ
RC RB))).
4.7. Анализ протоколов SSH и АКА
Протоколы SSH [35,36] и АКА [37] предназначены для аутентификации и конфиденциальной передачи сообщений в открытых сетях. Основу обоих протоколов составляют методы асимметричной криптографии. Анализ криптостойкости протоколов выполнен в [38].
Рассмотрим протоколы SHS и АКА. Введем некоторые, общие для обоих протоколов, обозначения:
• через А обозначим клиента, В — сервер, С — злоумышленника. Введенные обозначения используются в качестве уникальных идентификаторов абонентов;
• КA — открытый, а K — парный секретный ключ А;
• через
КBh и КBs,
обозначим два открытых, а через К
и К
— два парных
секретных ключа В. В SSH КBh выполняет
функции долговременного, а KBs —
кратковременного ключа. В протоколе АКА KBs
— одноразовый ключ;
• зашифрованный на ключе К открытый текст Х обозначим через {Х}к. Каждый, кто знает {X}k и ключ, обратный к K, может получить Х. Для симметричных крипто- систем эти ключи совпадают. Для асимметричных криптосистем открытый и парный секретные ключи взаимно обратимы в указанном смысле. Если K — секретный ключ, то асимметричное шифрование с целью получения {X}K есть, по сути, вычисление цифровой подписи на ключе К. Иногда в шифротекст {X}K вводится дополнительная избыточность, которая позволяет контролировать целостность принятого сообщения. Однако с точки зрения анализа криптостойкости протоколов это не существенно;
• через Н обозначена хэш-функция, Θ — суммирование по модулю 2 (XOR);
• NA и NB — уникальные случайные одноразовые значения, генерируемые A и В
соответственно. Для протокола АНА (но не для SSH) важно, чтобы эти значения хранились в секрете.
Предполагается, что при заданных А и КA сервер В может достоверно убедиться в том, что КA является открытым ключом А и что А является легальным абонентом криптосети. Аналогично А может убедится в подлинности ключа КBh. Однако А не имеет какой-либо исходной информации о КBh, кроме той, которую он получает в ходе реализации протокола. Аутентификация открытых ключей выполняется при помощи сертификатов. Все транзакции и действия, связанные с передачей и обработкой сертификатов, исключены из рассмотрения с цепью упрощения описания протоколов.
Протокол SSH позволяет реализовать несколько различных вариантов аутентификации. Рассмотрим случай аутентификации клиента при помощи методов асимметричной криптографии. Имеем следующий протокол:
Основное назначение описанного протокола — обеспечить сеансовым ключом К абонентов А и В. При помощи сообщений 1 и 2 абоненты А и В обмениваются одноразовыми случайными значениями. В сообщении 3 В передает А свои открытые ключи. В сообщении 4 А передает В ключ Х. Конфиденциальность этого сообщения обеспечивается шифрованием на открытых ключах КBs, и КBh,. Значение хэш-функции предыдущего сообщения позволяет установить непрерывную ассоциацию между сообщениями текущего сеанса и гарантирует невозможность несанкционированного воспроизведения сообщений. А передает свой идентификатор и открытый ключ в сообщении 5. Уникальность сообщения подтверждается цифре вой подписью значения хэш-функции идентификатора абонента А и одноразовых случайных значений NA и NB. Конфиденциальность сообщения обеспечивается шифрованием на ключе К', полученном из К,NA и NB.
Протокол уязвим, так как в сообщении 5 не содержится явной информации о К и В. Возможна атака, в ходе которой некоторый сервер С, обладающий открытыми ключами КCh и КCs, может выдать себя за абонента А при установлении сеансового соединения между А и В. Для этого А должен предварительно установить сеансовое соединение с C. Когда это происходит, С немедленно устанавливает сеансовое соединение с В. Если при этом допускается, что одноразовые значения могут быть одинаковыми в двух различных сеансах, то С может использовать аутентичные, подтвержденные цифровой подписью, сообщения А для установления сеансового соединения с В.
В результате В уверен, что уникальный ключ К используется в сеансовом соединении с А, однако это не так — тот же самый ключ известен С.
Метод противодействия описанной атаке заключается в использовании дополнительной информации, включающей идентификатор, сертификат и открытые ключи В, а также некоторый уникальный идентификатор сеансового ключа (например, значение хэш-функции этого ключа). Необходимо отметить, что в последнюю версию протокола SSH внесены соответствующие изменения.
Так же как SSH, протокол АКА допускает несколько различных режимов аутентификации. Рассмотрим вариант, изложенный на с. 181 документа [37].
Цель протокола — обеспечить абонентов А и В сеансовым ключом NA Θ NB. В сообщениях 1 и 2 абоненты A и В обмениваются открытыми ключами. В сообщениях 3 и 4 абоненты обмениваются одноразовыми значениями NA и NB, которые впоследствии будут использованы для вычисления сеансового ключа. В сообщении 5 передается подписанное В одноразовое значение NA. Сообщение 6 — результат хеширования одноразового значения NB, зашифрованный на открытом ключе абонента В. В результате только А и В знают результирующий сеансовый ключ — асимметричное шифрование гарантирует полную конфиденциальность передаваемых сообщений.
В рассмотренном протоколе подлинность сообщений подтверждается цифровой подписью абонента В. Однако протокол АКА столь же уязвим, что и рассмотренный выше протокол SSH. Основной недостаток заключается в том, что протокол позволяет убедиться в подлинности NA, но не NB. В результате С может выдать себя за В при установлении сеансового соединения между А и В.
Атака возможна, если А и В инициируют сеансовое соединение, а С перехватывает и выполняет замену некоторых сообщений. При этом С может не быть легальным абонентом криптосети.
С перехватывает сообщение 2 и выполняет замену открытого ключа КBs на свой собственный открытый ключ КCs. Данная манипуляция позволяет С, перехватив сообщение 3, раскрыть NA. После чего С может конфиденциально, передать NA абоненту В (сообщение 3'). С может также изъять сообщение 4 и вместо него передать А другое сообщение 4' с известным С одноразовым значением NC. В конечном итоге С не может продолжить взаимодействие с В, но А уверен, что уникальный сеансовый ключ NA Θ NC известен только А и В. Однако этот ключ известен также и С. Превентивная мера заключается в том, что подписанные В сообщения должны содержать дополнительную информацию. Последняя версия протокола содержит все необходимые дополнения и исправления.
5. ВАN-логика
Проблема аутентификации в компьютерных сетях настолько фундаментальна, что инициировала различные исследования. Интерес к данной проблеме привел к развитию методов формального анализа протоколов аутентификации и обмена ключами.
Существует четыре основных подхода к анализу криптографических протоколов [233]:
1) моделирование и проверка работы протокола с использованием языков описания и средств проверки, не разработанных специально для анализа криптографических протоколов;
2) создание экспертных систем, позволяющих разработчику протокола исследовать различные сценарии;
3) выработка требований к семейству протоколов, используя некую логику для анализа понятий «знание» и «доверие»;
4) разработка формальных методов, основанных на записи свойств криптографических систем в алгебраическом виде.
Полное описание этих четырех подходов и связанных с ними исследований выходит за рамки данной книги. Хорошее введение в эту тему дано в [201,202].
Первый из подходов пытается доказать правильность протокола, рассматривая его как обычную компьютерную программу. Ряд исследователей представляют протокол как конечный автомат [203,204], другие используют расширения методов исчисления предиката первого порядка [205], а третьи для анализа протоколов используют языки описания [206]. Однако доказательство правильности отнюдь не является доказательством безопасности, и этот подход потерпел неудачу при анализе многих уязвимых протоколов. И хотя его применение поначалу широко изучалось, с ростом популярности третьего из подходов работы в этой области были переориентированы. Во втором подходе для определения того, может ли протокол перейти в нежелательное состояние (например, потеря ключа), используются экспертные системы. Хотя этот подход дает лучшие результаты, он не гарантирует безопасности и не предоставляет методик разработки атак. Он хорош для проверки криптостойкости протокола по отношению к конкретной атаке, но не более. Примеры такого подхода можно найти в [48,207], а в [208] обсуждается экспертная система Interrogator. Третий подход гораздо популярнее. Он был впервые введен Бэрроузом (М. Burrows), Абади (М. Abadi) и Нидхэмом (В.М. Needham). Они разработали формальную логическую модель для анализа знания и доверия, названную BAN-логикой [209,210]. BAN-логика широко используется при анализе протоколов аутентификации. Она рассматривает подлинность как функцию от целостности и новизны, используя логические правила для отслеживания состояния этих атрибутов на протяжении всего протокола. Хотя были предложены различные варианты, большинство разработчиков протоколов до сих пор обращаются к оригинальной работе. BAN-логика не предоставляет доказательство безопасности, она может только рассуждать о проверке подлинности. Она является простой, прямолинейной логикой, легкой в применении и полезной при поиске уязвимых мест в протоколе. Вот некоторые положения BAN-логики:
• Алиса верит Х (Алиса действует, как если бы Х являлось истиной.);
• Алиса знает Х (Кто-то послал сообщение, содержащее Х, Алисе, которая может прочитать и снова передать Х — возможно, после дешифрования.);
• Алиса выдает Х (В некоторый момент времени Алиса послала сообщение, которое содержит предложение Х. Не известно, как давно было послано сообщение и было ли оно послано в течение текущего исполнения протокола. Известно, что Алиса доверяла Х, когда выдавала Х.);
• Х ново (Х никогда не было послано в сообщении до текущего выполнения протокола.).
BAN-логика также предоставляет правила для рассуждения о доверии протоколу. Для доказательства чего-либо в протоколе или для ответа на какие-то вопросы к логическим предложениям о протоколе можно применить эти правила. Например, одним из правил является правило о значении сообщения (конструкция вида ЕСЛИ..., ТО ... ):
• ЕСЛИ Алиса верит, что у Алисы и Боба общий секретный ключ К и Алиса знает Х, зашифрованное на К, но при этом Алиса не шифровала Х с помощью К, ТО Алиса верит, что Боб выдал Х.
Другое правило — правило подтверждения метки времени:
• ЕСЛИ Алиса верит, что Х могло быть выдано только недавно и что Боб когда-то выдал Х, ТО Алиса верит, что Боб верит Х.
BAN-анализ делится на четыре этапа:
1) использование положений и правил BAN-логики для приведения описания протокола к стандартной форме;
2) добавление всех положений о начальном состоянии протокола;
3) присоединение логических формул к положениям с целью получения утверждений о состоянии системы;
4) применение логических постулатов к утверждениям и положениям для раскрытия состояние доверия участников протокола.
Авторы утверждают, что BAN-логика позволяет получить ясное и полное описание практического протокола. Другие исследователи не так оптимистичны и пытаются показать, что BAN-логика может привести к получению неправильных характеристик протоколов [211,212]. Несмотря на критику, при помощи BAN-логики удалось доказать уязвимость некоторых протоколов, включая первичную версию протоколов стандарта Х.509 [213], а также избыточность ряда практических протоколов аутентификации, например Kerberos. Во многих опубликованных работах BAN-логика используется для заявления претензии на безопасность предлагаемых протоколов [214-216]. Были опубликованы и другие логические системы, некоторые из них разрабатывались как расширения BAN-логики [217 — 220].
Четвертый подход к анализу криптографических протоколов предлагает моделировать протокол как алгебраическую систему, выразить знания участников о протоколе и затем проанализировать достижимость определенных состояний. Этот подход пока не привлек столько внимания, как формальная логика, но положение дел постепенно меняется. Теоретическое обоснование возможности применения алгебраических моделей для анализа криптографических протоколов было сделано в работе [221]. Другие подходы рассмотрены в [212,222 — 227]. Анализатор протоколов Исследовательской лаборатории ВМС (Navy Research Laboratory, NRL), возможно, является наиболее успешным применением этих методов [228-231]. Он был использован для проверки множества протоколов [201,232,233]. Анализатор протоколов определяет следующие действия:
— принять (Боб, Алиса, М, N) (Боб принимает сообщение М как пришедшее от Алисы в течение локального раунда N);
— узнать (Ева, М) (Ева узнает М.);
— послать (Алиса, Боб, Q М) (Алиса посылает М Бобу в ответ на запрос Q );
— запросить (Боб, Алиса, Q, N) (Боб посылает Q Алисе в течение локального раунда N).
Используя эти действия, можно задать требования. Например:
— если Боб принял сообщение М от Алисы в какой-то прошедший момент времени, то Ева не знает М в какой-то прошедший момент времени;
— если Боб принял сообщение М от Алисы в течение локального раунда N, то Алиса послала М Бобу в ответ на запрос Боба в течение локального раунда N.
Для анализа при помощи NRL исследуемый протокол должен быть описан в терминах приведенных конструкций. Затем выполняется четыре фазы анализа: определение правил перехода для честных участников, описание операций, возможных и для полностью честных, и для нечестных участников, описание базовых блоков протокола и описание правил преобразования. Смысл всего этого заключается в том, чтобы показать, что данный протокол удовлетворяет необходимым требованиям. Использование инструментов, подобных NRL, в итоге могло бы привести к созданию протокола, который был бы обоснованно признан безопасным. Хотя формальные методы в основном применяются к уже существующим протоколам, наметилась тенденция их использования и при проектировании протоколов. Ряд предварительных шагов в этом направлении уже сделан в [200].
Kerberos представляет собой разработанный для сетей ТСР/IP-протокол проверки подлинности с доверенной третьей стороной. Служба Kerberos, работающая в сети, действует как доверенный посредник, обеспечивая проверку подлинности сетевых объектов. В протоколе Kerberos реализован криптостандарт DES, но вместо него можно использовать и другие алгоритмы. При общении с каждым объектом сети Kerberos использует уникальный секретный ключ-идентификатор. Протокол Kerberos был первоначально разработан в Массачусетском технологическом университете для проекта Афина. Модель Kerberos основана на идеях, описанных в параграфе IX3. Оригинальная версия Kerberos, версия 4, определена в [28,234]. (Версии с 1 по 3 были внутренними рабочими версиями.) Версия 5, модификация версии 4, определена в [235-237]. Лучшим обзором по Kerberos является статья [238]. Другие обзорные статьи — [239,240]; использование Kerberos на практике описано в [241,242].
6.1. Модель Kerberos
Объектами сетевого взаимодействия в модели Kerberos являются клиенты и серверы. Клиентами могут быть пользователи, но могут — и независимые программы, выполняющие различные действия: загрузку файлов, передачу сообщений, доступ к базам данных и принтерам, получение административных привилегий и т.п. Kerberos хранит базу данных клиентов и их секретных ключей. Для пользователей секретный ключ является зашифрованным паролем. Сетевые службы, требующие проверки подлинности, и клиенты, которые хотят использовать эти службы, регистрируют в Kerberos свои секретные ключи. Так как Kerberos знает все секретные ключи, он может создавать сообщения, убеждающие один объект в подлинности другого. Kerberos также создает уникальные сеансовые ключи, которые выдаются клиенту и серверу (или двум клиентам). Сеансовый ключ используется для шифрования/дешифрования сообщений, которыми обмениваются две стороны, и уничтожается после окончания сеанса. В Kerberos версии 4 используется нестандартный режим шифрования (см. параграф 4.4). В Kerberos версии 5 применяется режим СВС.
В этом параграфе рассматривается Кеrberos версии 5. Различия версий 4 и 5 будут рассмотрены ниже. Этапы протокола Kerberos представлены на рис. IX.9. Клиент запрашивает у сервера аутентификации Kerberos разрешение на обращение к Службе выделения мандатов с (Ticket-Granting Service, TGS). Это разрешение, зашифрованное на секретном ключе клиента, посылается
клиенту. Для использования конкретного прикладного сервера клиент запрашивает у TGS мандат на обращение к этому серверу. Если все в порядке, TGS посылает мандат клиенту. Затем клиент предъявляет мандат прикладному серверу. Если атрибуты
проверки подлинноклиента правильны, прикладной сервер предоставляет клиенту доступ к услуге.
Kerberos использует два типа атрибутов: мандаты и удостоверения. (В дальнейшем в этом параграфе будет использоваться нотация, применяемая в документах КегЬегов — см. табл. IX.4.)
Мандат используется для безопасной передачи серверу идентификатора клиента, которому данный мандат выдан. В нем также содержится информация, которую сервер может задействовать для проверки того, что клиент, использующий мандат, — это именно тот клиент, которому данный мандат был выдан. Удостоверение — это дополнительный атрибут, предъявляемый вместе с мандатом. Мандат Kerberos имеет следующую форму:
Мандат содержит имя клиента, его сетевой адрес, имя сервера, метку времени и сеансовый ключ. Эта информация шифруется секретным ключом сервера. Если клиент получил мандат, он может использовать его для доступа к серверу много раз — пока не истечет срок действия мандата. Клиент не может расшифровать мандат (он не знает секретного ключа сервера), но может предъявить его серверу в зашифрованном виде. Прочитать или изменить мандат при передаче по сети невозможно. Удостоверение Kerberos имеет следующую форму:
Клиент создает его каждый раз, когда ему нужно воспользоваться услугами сервера. Удостоверение содержит имя клиента, метку времени и необязательный дополнительный сеансовый ключ, все эти данные шифруются на общем для клиента и сервера сеансовом ключе. В отличие от мандата удостоверение используется только один раз. Клиент может генерировать удостоверения по мере надобности (ему известен общий секретный ключ). Удостоверение содержит некоторый открытый текст, зашифрованный сеансовым ключом, который может быть дешифрован только при условии, что ключ известен. Что не менее важно, зашифрованный открытый текст включает метку времени. Злоумышленник, которому удалось перехватить в открытом канале и мандат, и удостоверение, не сможет использовать их спустя какое-то время.
6.4. Сообщения Kerberos версии 5
6.5. Получение первоначального мандата
Клиент идентифицируется при помощи пароля. Открытая передача пароля по сети небезопасна. Протокол Kerberos минимизирует вероятность компрометации пароля, но при этом не позволяет пользователю правильно идентифицировать себя, если он не знает пароля. Клиент посылает сообщение, содержащее собственное имя и имя сервера TGS (у клиента может быть несколько серверов TGS), на сервер аутентификации Kerberos. На практике пользователь, скорее всего, просто вводит свое имя. Сервер аутентификации Kerberos ищет данные о клиенте в своей базе данных. Если информация о клиенте есть в базе данных, Kerberos генерирует сеансовый ключ, который будет использоваться для обмена данными между клиентом и TGS. Kerberos шифрует этот сеансовый ключ секретным ключом клиента. Затем он создает для клиента Разрешение на выделение мандата (Ticket Granting Ticket, TGT), доказывающее подлинность клиента серверу TGS, и шифрует его на секретном ключе TGS. Сервер аутентификации посылает эти два зашифрованных сообщения клиенту. Теперь клиент расшифровывает первое сообщение и получает сеансовый ключ. Секретный ключ является хэш-функцией от пароля клиента, поэтому у законного пользователя не возникает проблем с дешифрованием. Злоумышленник не знает правильного пароля и, следовательно, не может расшифровать ответ сервера аутентификации и получить TGT или сеансовый ключ. Клиент сохраняет TGT и сеансовый ключ и для снижения вероятности компрометации уничтожает пароль и значение хэш-функции. Если злоумышленник получит доступ к памяти компьютера клиента, он раскроет только TGT и сеансовый ключ. Эти данные важны, но только нв время жизни TGT. Когда срок действия TGT истечет, эти сведения станут бессмысленными. Теперь в течение срока действия TGT клиент может доказывать TGS свою подлинность.
6.6. Получение мандатов прикладных серверов
Клиенту требуется получить отдельный мандат для каждой необходимой ему услуги. Сервер TGS выделяет мандаты для отдельных прикладных серверов. Когда клиенту нужен мандат, которого у него нет, он посылает запрос TGS. Сервер TGS, получив запрос, расшифровывает TGT на своем секретном ключе. Затем TGS использует включенный в TGT сеансовый ключ, чтобы расшифровать удостоверение. Наконец, TGS сравнивает информацию удостоверения с информацией мандата, сетевой адрес клиента с адресом отправителя запроса и метку времени с текущим временем. Если все совпадает, TGS разрешает выполнение запроса. Проверка меток времени предполагает, что часы всех компьютеров синхронизированы, по крайней мере, с точностью до нескольких минут. Если расхождение времени слишком велико, TGS считает запрос попыткой повторения предыдущего запроса. TGS должен также отслеживать правильность сроков действия удостоверений, так как услуги сервера могут последовательно запрашиваться несколько раз с одним мандатом, но с разными удостоверениями. Другой запрос с тем же мандатом и уже использованной меткой времени удостоверения будет отвергнут. В ответ на легальный запрос TGS возвращает мандат, который клиент может предъявить серверу. TGS также создает новый сеансовый ключ для клиента и сервера, зашифрованный общим для клиента и TGS сеансовым ключом. Оба этих сообщения отправляются клиенту. Клиент расшифровывает сообщение и извлекает сеансовый ключ.
Теперь клиент может доказать свою подлинность прикладному серверу. Он создает сообщение, очень похожее на то, которое посылалось TGS. Клиент создает удостоверение, состоящее из его имени, сетевого адреса и метки времени, зашифрованное на сеансовом ключе, который был сгенерирован TGS. Запрос состоит из мандата, полученного от Kerberos (уже зашифрованного секретным ключом сервера), и зашифрованного идентификатора. Сервер расшифровывает и проверяет мандат и удостоверение, а также проверяет адрес клиента и метку времени. Если все в порядке, то сервер уверен, что клиент — именно тот, за кого он себя выдает. Если приложение требует взаимной проверки подлинности, сервер посылает клиенту сообщение, состоящее из метки времени, зашифрованной сеансовым ключом. Это доказывает, что серверу известен правильный секретный ключ и он может расшифровать мандат и удостоверение. При необходимости клиент и сервер могут шифровать и дешифровать все последующие сообщения общим ключом. Так как этот ключ известен только им, они оба могут быть уверены, что сообщение, зашифрованное этим ключом, отправлено другой стороной.
В предыдущих параграфах рассматривался Kerberos версии 5. Версия 4 отличается сообщениями и конструкцией мандатов и удостоверений. В Kerberos версии 4 используется следующие пять сообщений:
Сообщения 1, 3 и 5 не изменились. Двойное шифрование мандата на этапах 2 и 4 в версии 5 было устранено. Мандаты версии 5 допускают использование нескольких адресов, а срок действия 1 не указывается. В удостоверение версии 5 добавлена возможность включения дополнительного ключа.
Беллоуин (S. Bellovin) и Мерритт (М. Merritt) проанализировали некоторые потенциально уязвимые места протокола Kerberos [243]. Хотя их исследование касалось Kerberos версии 4, многие замечания применимы и к версии 5. Показано, что возможно повторное использование старых удостоверений. Хотя метки должны предотвратить такую возможность, удостоверения могут использоваться повторно в течение срока действия мандата. Предполагается, что серверы хранят все легальные мандаты, чтобы обнаружить повторы, но это не всегда возможно. Кроме того, срок действия бывает достаточно большим. Проверка легальности удостоверений основана на том факте, что все часы компьютеров сети более или менее синхронизированы. Если время компьютера будет установлено неправильно, то появляется возможность использования старого удостоверения. Большинство сетевых протоколов поддержки единого времени небезопасны, поэтому такая возможность способна привести к серьезным проблемам. Возможно также угадывание пароля. Злоумышленник может перехватывать и сохранять мандаты в базе данных и затем пытаться расшифровать их. Возможно, самой опасной является атака, использующая специальное программное обеспечение. Изначально предполагается, что программному обеспечению можно доверять. Однако клиентское программное обеспечение может быть заменено такой версией, которая помимо выполнения легальных действий записывает пароли. Эта проблема характерна для любого криптографического программного обеспечения, работающего на небезопасном компьютере, но широкое распространение Kerberos делает его особенно привлекательной мишенью. В настоящее время ведутся работы над улучшением Kerberos, включая модернизацию управления ключами с помощью асимметричной криптографии и интерфейса Smart Card. Одна из реализаций протокола Kerberos свободно распространяется компанией Cygnus Support.
Доказательство принадлежности
Механизмы доказательства принадлежности обеспечивают разрешение конфликтов, возникающих в случае отказа вовлеченных в процесс информационного обмена сторон от ранее переданных/принятых сообщений. Так, в сфере банковских технологий отказ от ранее принятых/переданных сообщений может означать отказ от взятых финансовых обязательств. Криптографические методы, лежащие в основе механизмов доказательства принадлежности, позволяют независимому арбитру принимать однозначное решение по факту отказа от обязательств.
При сетевом взаимодействии различают два типа отказа:
отказ отправителя: разногласия по поводу факта отправки конкретным отправителе конкретного сообщения или времени его (сообщения) отправки;
отказ получателя: разногласия по поводу факта получения конкретным получателем конкретного сообщения или времени его (сообщения) получения.
Для каждого из указанных типов отказа существуют свои механизмы доказательства принадлежности.
1. Фазы процедуры и роли сторон
В общем виде процедура доказательства принадлежности состоит из пяти фаз: запроса услуги, генерации доказательства, передачи/хранения доказательства, проверки доказательства, разрешения конфликта [64,136]. Роли сторон (отправителя и получателя), участвующих в процедуре, меняются при переходе от одной фазы к другой.
Сформулируем цели процедуры доказательства принадлежности:
• доказательство факта отправки конкретным отправителем конкретного сообщения или времени его (сообщения) отправки;
• доказательство факта получения конкретным получателем конкретного сообщения или времени его (сообщения) получения.
Основное назначение сети — предоставление определенных услуг абонентам. Таким образом, трактовка доказательства принадлежности как услуги позволяет точнее формулировать и решать целевые задачи.
Предположим, что стороны А и В намереваются принять участие в информационном обмене в целях решения некоторой практической задачи. Сторона В прежде всего требует гарантий того, что сторона А не сможет впоследствии отказаться 6i' ранее переданных сообщений. Для обеспечения подобной услуги необходимо согласие стороны А. Для этого В (или другая заинтересованная сторона) формирует и передает стороне А специальное извещение о включении механизма доказательства принадлежности для всех последующих сообщений. Извещение не требуется, если услуга входит в список общесистемных требований. Так, если сторона А берет на себя обязательство по выплате определенной суммы и передает чек стороне В, то доказательство принадлежности гарантируется подписью на чеке. Специальный запрос при этом не нужен — подпись на чеке является узаконенной и распространенной формой финансовых отношений. Однако в отдельных случаях сторона В может запросить специальный сертифицированный чек.
Таким образом, одна из сторон играет роль инициатора и выполняет запрос услуги. Следуя приведенной выше аналогии с чеком, роль инициатора выполняет сторона В.
Фаза генерации доказательства предполагает участие одной или нескольких сторон, согласных предоставить гарантии доказательства принадлежности при возникновении конфликтной ситуации. Генерация доказательства выполняется в ответ на запрос инициатора. Возвращаясь к аналогии с чеком, генерация доказательства — Подписывание чека стороной А и предъявление сертификата банка при специальном запросе.
После генерации доказательство должно быть:
• передано на хранение стороне (сторонам), затребовавшей гарантии доказательства принадлежности
и/или
• передано на хранение доверенному агенту для использования при разрешении конфликтов в будущем.
В случае платежа по чеку — передача чека с подписью и сертификатом банка. При сертификации банк выполняет регистрацию и хранит копии всех сертифицированных чеков.
Инициатор (или доверенный агент) осуществляет проверку сгенерированного доказательства. Проверка доказательства выполняется всегда, независимо от того, возник конфликт или нет, и позволяет установить состоятельность доказательства при разрешении конфликта в будущем.
При платеже по чеку — проверка подписи на чеке, текущей даты и (при необходимости) проверка сертификата банка.
Разрешение конфликта — финальная фаза процедуры доказательства принадлежности. Отметим, что конфликт может возникнуть как в текущий момент (во время текущего сеанса), так и в любой момент времени в будущем. Для разрешения конфликта необходимо найти соответствующее доказательство, перепроверить его и вынести вердикт по результату проверки, для чего привлекается независимый арбитр.
Стандарты сетевой безопасности не предусматривают конкретной процедуры разрешения конфликта. Однако все механизмы доказательства принадлежности разрабатывались с учетом этой фазы.
2. Доказательство при отказе отправителя
Отказ отправителя, как отмечалось выше, — следствие разногласия сторон по поводу принадлежности конкретного сообщения конкретному отправителю или времени его (сообщения) отправки.
Предполагается, что генерация доказательства выполняется отправителем, в некоторых случаях — доверенным агентом. Получатель запрашивает услугу и проверяет доказательство, представленное отправителем.
По сути, доказательство — некоторая однозначная (в смысле коллизий) функция, связывающая следующие информационные объекты:
• уникальный идентификатор отправителя;
• данные;
• дату и время отправки сообщения (опционально);
• уникальный идентификатор получателя (опционально);
• уникальный идентификатор доверенного агента (опционально).
Отметим, что рассматриваемые ниже схемы, рассчитанные в первую очередь на применение в области телекоммуникаций, позволяют решать аналогичные задачи при управлении базами данных.
2.1. Цифровая подпись отправителя
Основу этой схемы доказательства принадлежности составляет цифровая подпись отправителя, передаваемая получателю вместе с блоком данных (рис. Х.1).
Таким образом, первичное доказательство— цифровая подпись отправителя. Проверка доказательства есть проверка цифровой подписи получателем сообщения. После проверки цифровая подпись сохраняется в базе данных получателя. Впоследствии, если отправитель откажется от переданного сообщения, получатель может предоставить цифровую подпись (или результат проверки цифровой подписи) в качестве неопровержимого доказательства факта отказа со стороны отправителя.
Рассмотрим роль центров сертификации (ЦС). Проверка и хранение сертификатов — важнейший элемент схемы доказательства принадлежности на базе цифровой подписи. Так, если получатель предоставляет результат проверки цифровой подписи на некотором открытом ключе, то это само по себе не является полноценным доказательством для независимого арбитра. Для установления факта отказа необходимо предоставить доказательство аутентичности открытого ключа отправителя. Подлинность открытого ключа подтверждается с помощью проверки цифровой подписи долгов
ременного сертификата (сертификат в общем виде — это открытый ключ отправителя+идентификатор отправителя+цифровая подпись ЦС), выданного доверенным ЦС на раннем этапе формирования сети. Отправитель передает сертификат вместе с подписанным блоком данных. Применение долговременных сертификатов объясняется тем, что факт отказа может устанавливаться в отдаленном будущем. Долговременные сертификаты накладывают дополнительную ответственность на ЦС. При отмене сертификата (по причине компрометации секретного ключа или по инициативе ЦС) точное время отмены незамедлительно сообщается держателям данного сертификата. Доказательство в виде результата проверки цифровой подписи, предоставленное до отмены сертификата, принимается к рассмотрению. Доказательство, предоставленное после отмены сертификата, считается несостоятельным. Итак, общая проверка состоит из трех этапов: проверки списка отмененных сертификатов, проверки цифровой подписи сертификата на известном открытом ключе ЦС и проверки цифровой подписи блока данных на открытом ключе отправителя (извлекается из сертификата).
Проблема усложняется при отмене сертификата в момент его использования. Одно из решений — отправитель сохраняет копии списков отмененных сертификатов, заверенных цифровой подписью ЦС, для предъявления при возникновении спорной ситуации.
2.2. Цифровая подпись третьей стороны
Альтернативный вариант — использование вместо цифровой подписи отправителя цифровой агента, например ЦС (рис. Х.2).
В такой схеме доверенный агент выступает в качестве поручителя. Отправитель передает агенту блок данных, агент вычисляет цифровую подпись (на своем секретном ключе) от конкатенации блока данных, идентификатора отправителя и другой необходимой информации (например временной метки) и затем передает ее отправителю. Отправитель передает получателю блок данных и цифровую подпись агента. Получатель принимает сообщение, проверяет (на открытом ключе агента) и сохраняет цифровую подпись в качестве доказательства.
Для контроля целостности и аутентичности сообщений, передаваемых от отправителя к агенту, применяют код аутентификации сообщения (КАС). Для вычисления КАС агент и отправитель должны иметь один и тот же секретный ключ. Контроль целостности и аутентичности сообщений, передаваемых от агента к отправителю, обеспечивается за счет цифровой подписи агента — открытый ключ агента известен как отправителю, так и получателю сообщений.
Описанная схема имеет ряд преимуществ перед схемой доказательства принадлежности на базе цифровой подписи отправителя. Одно из них — меньшее количество необходимых для проверки цифровой подписи открытых ключей и, как следствие, меньший объем памяти для их хранения. При этом предоставление услуги обеспечивается относительно небольшим числом доверенных агентов. Другое важное преимущество — контроль системного времени со стороны доверенных агентов при помощи временных меток, что позволяет достоверно устанавливать время отправки сообщения.
2.3. Цифровая подпись третьей стороны с хешированием
Рассмотрим одну из разновидностей описанной выше схемы — использование хэш-функции для вычисления дайджеста, или «цифрового отпечатка пальца», блока данных. Отправитель вычисляет дайджест от блока данных и передает его доверенному агенту. Агент вычисляет цифровую подпись от конкатенации дайджеста, идентификатора отправителя и временной метки и затем передает подпись отправителю. Отправитель передает получателю блок данных и цифровую подпись доверенного агента. Получатель проверяет и сохраняет цифровую подпись в качестве доказательства.
Преимущество данной схемы:
• меньший объем данных, передаваемых от отправителя к агенту;
• конфиденциальный режим взаимодействия с доверенным агентом.
Отметим особую важность последнего — абоненты сети доверяют цифровой подписи агента, но не доверяют во всех остальных случаях (раскрытие агенту секретной информации, предназначенной другому абоненту, может быть нежелательно). Конфиденциальность обеспечивается тем, что агенту передается не сам блок данных, а его хэш-функция (для получения данных необходимо обратить хэш-функцию).
При использовании различных хэш-функций (MD2, MD4, MD5, SHA и т.д.) в число
скрепляемых цифровой подписью объектов включается уникальный идентификатор хэш-функции. При отсутствии идентификатора хэш-функции цифровая подпись не является однозначным доказательством факта отказа, так как с отличной от нуля вероятностью применение двух различных хэш-функций к двум различным блокам данных позволяет получить один и тот же дайджест.
2.4. Применение третьей стороной симметричной криптосистемы
Этот вариант схемы, концептуально аналогичный двум предыдущим, отличается применением симметричной (одноключевой) криптосистемы.
Вместо цифровой подписи доверенный агент вычисляет КАС на своем секретном ключе, используя непосредственно блок данных либо дайджест блока данных, полученный с помощью хэш-функции (рис. Х.3). Вычисленный агентом КАС передается отправителю для пересылки .получателю. В отличие от схем на базе цифровой подписи получатель в данном случае не может сам проверить КАС, так как не знает секретного ключа агента. Для проверки получатель передает блок данных (или дайджест) и КАС агенту. Агент вычисляет текущий КАС и сравнивает с принятым. При совпадении агент уведомляет получателя о валидности КАС. Получатель сохраняет проверенный КАС в своей базе данных.
Отметим, что при передаче от отправителя к агенту, а также от агента к получателю необходимо обеспечить целостность и аутентичность передаваемой информации.
2.5. Обмен сообщениями при участии третьей стороны
Другой вариант схемы предполагает участие третьей стороны в обмене сообщениями между отправителем и получателем. Рассмотрим два способа реализации такой схемы. Простейший представлен на рис. Х.4.
Доверенный агент берет на себя обязательство по генерации и сохранению доказательства включая копию дайджеста или блока данных, идентификатор отправителя и временную метку.
Безусловное достоинство такого способа реализации схемы — в «прозрачности»: введение дополнительной услуги по доказательству принадлежности не приводит к каким-либо изменениям на уровне прикладных протоколов между отправителем и получателем. При этом, однако, необходимо обеспечить целостность и аутентичность информации при передаче от отправителя к агенту и от агента к получателю.
Второй способ представлен на рис. Х.5.
Доверенный агент генерирует доказательство, в. виде цифровой подписи и передает получателю для проверки и сохранения. Концептуально данный способ аналогичен схеме с цифровой подписью третьей стороны.
3. Доказательство при отказе получателя
Отказ получателя — это, как отмечалось выше, следствие разногласия сторон по поводу факта получения конкретного сообщения конкретным получателем или времени его (cooбьщения) получения. Отметим, что рассматривается только факт получения, независимо от назначения полученных данных и способов их обработки. В некотором смысле ситуация эквивалентна расписке за доставленную телеграмму, где подпись получателя подтверждает факт доставки, но не заверяет текст телеграммы.
Генерация доказательства выполняется получателем, в некоторых случаях при участии одного или более доверенных агентов. Отправитель играет роль инициатора, запрашивает услугу и выполняет проверку полученного доказательства.
Доказательство принадлежности при отказе получателя должно связывать следующие информационные объекты:
• уникальный идентификатор получателя;
• данные;
• дату и время получения сообщения (опционально);
• уникальный идентификатор отправителя (опционально);
• уникальный идентификатор доверенного агента (опционально).
Рассмотрим некоторые криптографические схемы доказательства принадлежности при отказе получателя.
3.1. Уведомление о получении с цифровой подписью получателя
Эта схема предусматривает генерацию получателем уведомления о доставке и передачи его отправителю. Уведомление содержит цифровую подпись получателя (или доверенного агента-поручителя), вычисленную на основе:
• дайджеста или данных;
• другой вспомогательной информации, например даты и времени получения.
Схема доказательства принадлежности с цифровой подписью получателя представлена на рис. Х.6.
Описанная схема, по сути, сводится к схеме доказательства принадлежности при отказе отправителя по отношению к уведомлению о доставке (за тем исключением, что в этом случае данные или дайджест не нужно передавать обратно отправителю). Управление сертификатами и списком отмененных ключей аналогично схеме доказательства принадлежности при отказе отправителя (см. предыдущий параграф).
3.2. Применение третьей стороной симметричной криптосистемы
Это возможный вариант рассмотренной выше схемы — применение доверенным агентом симметричной криптографической техники для вычисления КАС (см. рис. Х.З). Аналогично схеме доказательства принадлежности при отказе отправителя проверка КАС выполняется доверенным агентом. Отличие данной схемы в том, что отправитель и получатель меняются ролями.
Проблема, возникающая в контексте вышеизложенных схем доказательства принадлежности, связана с потенциальной возможностью отказа получателя от передачи уведомления о доставке.
Один из возможных способов решения проблемы — вовлечение доверенного агента в процедуры генерации и передачи уведомления о доставке. Отправитель посылает данные агенту, последний подтверждает получение уведомлением о доставке согласно описанной выше схеме на базе цифровой подписи. Как правило, агент не посылает отправителю уведомления до тех пор, пока получатель не получит в полном объеме данные текущего сеанса. В некоторых ситуациях возможно поблочное уведомление, однако для этого необходим дополнительный механизм, позволяющий достоверно убедиться в том, что текущий блок данных доставлен получателю. Действия агента аналогичны, например, действиям судебного исполнителя, вручающего повестку.
Двухфазный протокол разработан для решения проблемы отказа получателя от передачи уведомления о доставке. Протокол используется при передаче данных как от отправителя к получателю, так и от агента к получателю. Рассмотрим вариант протокола при передаче от отправителя к получателю.
Вначале отправитель посылает получателю специальное служебное сообщение, содержащее дайджест передаваемых данных. Получатель посылает отправителю ответное служебное сообщение, содержащее подписанную копию принятого дайджеста. После проверки цифровой подписи и дайджеста, принятого от получателя, отправитель начинает передачу данных. Получение данных подтверждается уведомлением о доставке по схеме, представленной на рис. Х.6.
Основное преимущество двухфазного протокола — получение отправителем гарантий в безотказном приеме данных до их непосредственной передачи. Отметим, что без предварительного обмена служебными сообщениями получатель в целях отказа от передачи уведомления может симулировать сбои в работе сети сразу же после передачи данных отправителем.
Получатель также обязан включить время получения дайджеста в ответное служебное сообщение. Таким образом, отправитель имеет возможность проверить время получения (и сохранить его в качестве доказательства) до непосредственной передачи данных.
Все описанные выше схемы предполагают участие третьей стороны. Доказательства, представленные доверенным агентом, используются для вынесения вердикта в конфликтных ситуациях.
В рамках рассмотренных схем доказательства принадлежности агент выполняет следующие функции:
сертификация открытых ключей. Агент выпускает сертификаты, заверяющие подлинность открытых ключей, их соответствие парным секретным ключам, принадлежащим конкретным абонентам сети. Осуществляет управление сертификатами, формирует и рассылает список отмененных сертификатов (при компрометации ключей и т.д.);
сертификация идентичности. Агент подтверждает подлинность отправителя, вычисляя цифровую подпись от лица отправителя;
удивление временными метками. Агент подтверждает подлинность момента времени при вычислении цифровой подписи;
хранение доказательств. Агент гарантирует надежное хранение доказательств в течение заданного периода и незамедлительное их предоставление по первому требованию;
гарантии доставки. Агент гарантирует отправителю безотказный прием сообщений со стороны получателя;
арбитраж. Агент выполняет функции независимого арбитра в ходе разрешения конфликтных ситуаций. Отметим, что с точки зрения сетевого взаимодействия данная функция (в отличие от всех остальных) не является типичной.