CC BY
97
№5(23)2009
А. С. Михайлов, С. С. Селезнёв
Итерационный процесс разработки протоколов информационного обмена1
В современных условиях всесторонней информатизации общества и стремительного развития распределенных информационных систем, систем электронного документооборота, электронного бизнеса особую актуальность имеет задача разработки надежных и безопасных протоколов информационного обмена.
В самом общем случае протокол информационного обмена представляет собой последовательность передачи сообщений с применением вычислительных, в том числе криптографических, алгоритмов в процессе обработки данных. Спецификой протоколов является наличие в них возможных несостоятельно-стей — ситуаций, когда злоумышленник может причинить ущерб участникам протокола или когда цели протокола не достигаются [12, 14]. Наличие несостоятельностей в протоколах в некоторой степени схоже с наличием ошибок в программном обеспечении. Тестирование и верификация программного обеспечения являются общепризнанными необходимыми этапами процесса разработки программных продуктов. Подобным образом ставится вопрос об анализе моделей протоколов с целью выявления возможных несостоятельностей с последующим внесением исправлений.
На кафедре «Кибернетика» Национального исследовательского ядерного университета «МИФИ»2 был предложен и исследован итерационный процесс для разработки протоколов, состоящий из трех основных этапов: визуальное моделирование протокола, анализ формальной математической модели протокола и практический анализ протокола в исследовательской среде информационного обмена (рис. 1).
Визуальные модели способствуют целостному восприятию моделируемых протоколов,
используются для обмена знаниями между разработчиками. Визуальное моделирование позволяет представить протокол в форме диаграмм, показывающих участников протокола и их возможности (статическое представление), а также процессы взаимодействия между участниками (динамическое представление). На основе визуальных моделей возможна генерация формализованных моделей протоколов, например с использованием языка XML, что позволяет автоматически экспортировать модели между различными инструментальными средствами моделирования и анализа.
Формальный анализ Анализатор «ЯНУС»
Визуальное моделирование
Язык визуального моделирования .
'Практический анализ СПК«ИКАМ»
Рис. 1. Итерационный процесс разработки протоколов
1 Статья подготовлена по результатам Всероссийской научно-практической конференции Московской финансово-промышленной академии «Развитие конкуренции на рынке информационных технологий» (25-26 марта 2009 г.). — Прим. ред.
2 http:Zcyber.mephi.ru.
59
№ 5(23) 2009 ^
Предлагается проводить анализ моделей протокола с применением двух взаимодополняющих подходов формального и практического анализа. Формальный анализ подразумевает обработку математической модели протокола, созданную с использованием выразительных возможностей того или иного метода моделирования. Как правило, основное преимущество формальных методов заключается в возможности автоматизации анализа. Основными ограничениями являются сложность подготовки формальных моделей и абстрагирование от внутреннего существа используемых вычислительных и криптографических алгоритмов, т. е. рассмотрение таких алгоритмов, как «черные ящики», что может быть причиной появления несостоятельно-стей в протоколах.
Практический анализ дополняет формальный, происходит с привлечением экспертов, осуществляющих ролевое выполнение протокола, для чего требуется создание исследовательской среды информационного обмена. По существу, практический анализ — тестирование выбранного протокола до его реализации. в Итерация начинается с разработки визу-| альной модели протокола и заканчивается получением результатов формального и практи-§ ческого анализа. В соответствии с принципом | обратной связи результаты анализа оказывает ют влияние на моделирование. Если в процессе анализа в протоколе были обнаружены не-
4 состоятельности, то следующая итерация на-
=» чинается с коррекции модели протокола, по-00
§ сле чего происходит анализ исправленной § модели. Процесс может продолжаться до тех 1 пор, пока не будет получена работоспособная ® и безопасная версия протокола [6].
5 Для визуального моделирования протоколов информационного обмена возможно использовать предметно-ориентированный язык
^ визуального моделирования [2, 3, 8]. Преимуществами подобного языка являются нагляд-
6 ность, представление статического и динами-3 ческого аспектов протокола. В визуальном § языке определяются такие основные синтак-» сические конструкции как объект, состояние, & переход, цикл и ветвление. В целом формали-5: зация синтаксиса может быть выполнена с по-
мощью расширенной формы Бэкуса-Наура. Синтаксические конструкции могут быть спроецированы в понятия предметной области, такие как контрагенты, коммуникации, операции электронной цифровой подписи и др. Статический аспект можно выразить с помощью объектно-реляционных диаграмм. Для этого язык включает графические примитивы описания объектов, их атрибутов, методов и отношений между ними. Представление динамики протоколов как асинхронных систем с предысторией возможно осуществить с использованием автоматных моделей. Для поддержки процесса визуального моделирования возможна разработка специализированного графического редактора, например с использованием технологии Microsoft DSL Tools. Визуальная модель протокола может быть сохранена в формате XML и использована для последующего экспорта в системы формального и практического анализа.
Для формального анализа моделей протоколов был выбран логико-алгебраический метод, основанный на расширении SPI-исчисле-ния. В начале 1990-х гг. Р. Милнер предложил получившее известность PI-исчисление, представляющее собой удобный метод формализации и исследования параллельных процессов, которые могут синхронизировать свое поведение. В 1999 г. А. Гордон и М. Абади предложили расширение PI-исчисления, добавив возможность моделировать протоколы, использующие симметричные и асимметричные криптографические алгоритмы [9]. Предложенное расширение получило наименование SPI-исчисления. Оно позволяет удобно моделировать протоколы, но верификация протоколов является нетривиальной задачей [1]. Впоследствии SPI-исчисление было обогащено рядом новых механизмов, в частности введением типизации [4, 10,11]. Процесс анализа моделей протоколов может быть полностью автоматизирован. Был разработан автоматизированный анализатор протоколов «ЯНУС», использующий метод проверки типов (type checking), основанный на расширенных возможностях SPI-исчисления. Анализатор позволяет делать вывод о наличии или отсутствии несостоятельностей в протоколе. На вход ана-
60
№5(23)2009
лизатор получает формальную модель протокола в терминах расширенного SPI-исчисле-ния. Процесс анализа полностью автоматизирован. По результатам выдается заключение об отсутствии или возможном наличии несостоятельностей в протоколе [7, 13].
Далее продемонстрируем пример моделирования и анализа простого протокола с использованием SPI-исчисления. Рассмотрим основные элементы SPI-исчисления. Ограничимся только наиболее часто используемыми операциями и симметричными алгоритмами.
Модель протокола в SPI-исчислении состоит из сообщений и процессов.
• Сообщение x — имя, представляющее собой канал, метку времени, симметричный ключ или ключевую пару.
• Сообщение (M, N) — примитив, описывающий любую конечную запись.
• Сообщение {M}N — криптограмма, полученная при зашифровывании сообщения M на симметричном ключе шифрования N.
Далее приведем сводную таблицу синтаксиса операций в SPI-исчислении и его расширении, в основном в методе проверки типов (табл. 1).
Каждый процесс — это последовательность операций. В произвольном процессе P обычно часть переменных являются свободными. Для свободных переменных их значения должны быть переданы процессу извне в момент его запуска. Например, в процессе
inp C (x);stop
такой переменной является канал C. Кроме свободных, в процессе также используются связанные переменные, область действия которых находится внутри процесса. В вышеприведенном примере связанной является переменная x. Для свободных переменных вводится операция замещения значения P{x ^ N}, что означает замещение на сообщение N для каждого свободного вхождения переменной x в процессе P, в том числе и в его сообщениях.
Вышеперечисленные операции, будучи составной частью процессов, определяются следующим образом.
• Процессы out M N и inp M(x); P — процессы отправки и приема, соответственно, работающие с асинхронным неупорядоченным каналом M. Если отправка out xN происходит
«
О >§
S
3=
Таблица 1
Синтаксис операций в SPI-исчислении и его расширении
Синтаксис SPI-исчисления Расширенный синтаксис Описание
С '{M } out CM Выдача в канал связи С сообщения М
С {x } inpC (x) Прием из канала С значения х
— splitXis (Y,Z) Разделение данного X на данные У и I
caseL of {x } k in decrypt Xis {Y } Z Расшифровывание криптограммы X на ключе I
— check XisY Проверка, что X есть У
(vK ) new (X) Генерирование нового (уникального) значения X
P1Q P | Q Параллельное выполнение процессов Р и 0
— repeat P Повторение процесса Р бесконечное количество раз
— stop Остановка работы процесса
{X } к {X } k Зашифровывание сообщения Xна симметричном ключе К
61
№ 5(23) 2009 ^
параллельно с приемом inp x (y);P, они взаимодействуют, меняя дальнейший процесс: P{y ^ N}.
• Процесс repeat inp M(x);P — повторяющийся прием данных, который ведет себя как обычный прием данных, за исключением того, что каждый раз, когда из канала поступают данные, исходный процесс распадается на два процесса: один ожидает очередной порции данных, а второй ведет себя как P x^ N.
• Процесс split Mis(x, y);P разделяет пару M на два ее компонента. Если M есть, процесс ведет себя как P{x^ N}{y^L}, иначе он самоблокируется, т. е. бездействует.
• Процесс decrypt Mis{X} N;P расшифровывает M, используя симметричный ключ N. Если Mесть{L} N, процесс ведет себя как, иначе он самоблокируется.
• Процесс check M is N;P проверяет, что сообщения M и N — одно и то же перед выполнением P. Если сообщения не эквивалентны, процесс самоблокируется.
• Процесс new(x:T);P генерирует новое имя x, область действия которого — P, и затем запускает P. Это абстрактное представление генератора случайных чисел и ключей
в • Процесс P | Q запускает процессы P и Q | параллельно
• Процесс stop самоблокируется.
§ Рассмотрим, как записывается в SPI-исчисле-! нии простой протокол, в котором действуют два абонента: A — получатель и B — отправитель.
1. Абонент A генерирует новое одноразо-
4 вое случайное число (ОСЧ).
=» 2. Абонент A отправляет абоненту B по от-§ крытому каналу связи незашифрованное со-§ общение, содержащее это ОСЧ. 1 3. Абонент B отправляет абоненту A по от® крытому каналу связи зашифрованные в од-g ном пакете сообщение Msg и полученное ранее ОСЧ.
4. Абонент A расшифровывает полученное У сообщение. Если присланное и ранее отправленное ОСЧ совпадают, то протокол считается & успешно завершенным.
'! Запишем протокол в терминах SPI-исчисле-§ ния.
3 ST
а
& Отправитель (net; key) =
5 repeat inp net (Nb');
new Msg;
out net {Msg, Nb'} key;
Получатель (net; key) =
new Nb;
out net Nb;
inp net (ctext);
decrypt ctext is {Msg,Nb2} key
check Nb2 is Nb;
Система(net) =
new (key);
Отправитель (net; key) | Получатель (net; key)
В целом SPI-исчисление позволяет достаточно точно описывать значительное число протоколов, в которых используются криптографические алгоритмы. Как уже отмечалось, в основе анализатора лежит метод проверки типов. Для верификации свойств моделей протоколов метод использует дополнительную информацию о протоколе, которая должна быть добавлена к SPI-модели.
Дополнительная информация, добавляемая к протоколу, включает описание задач участников протокола и тех средств, на которые они опираются для гарантии правильного решения этих задач, а также типы данных, используемых участниками для информационного обмена. Например, в рассмотренном ранее простом протоколе задача участников — передача сообщения M. Отправитель начинает решать эту задачу перед отправкой криптограммы получателю. Получатель заканчивает решение задачи после того, как убеждается, что числа, гарантирующие «свежесть» сообщения, содержащиеся в криптограмме, тождественны ранее пересланным в ходе протокола числам. Таким образом, описание задач участников протокола — сравнительно неформальный способ комментирования событий, происходящих в ходе его исполнения.
Для описания решаемых в протоколе задач используется следующая нотация.
События:
begin L — начало решения задачи L;
end L — окончание решения задачи L
Соответственно, к нотации SPI добавляются две операции — begin L и end L. Как уже
62
№5(23)2009
было сказано, в рассмотренном ранее протоколе решается единственная задача — передача сообщения от отправителя к получателю. Запишем протокол в расширенной нотации:
Отправитель(net,• key) = repeat inp net (Nb'); begin «отправка Msg» new Msg;
out net {Msg, Nb'} key;
Получатель(net,• key) =
new Nb;
out net Nb;
inp net (ctext);
decrypt ctext is {msg,Nb2} key
check Nb2 is Nb;
end «отправка Msg»
Система (net; done) =
new (key);
(Отправитель(net; key) | Получатель(net; key))
Таким образом, для любой из частей протокола можно вычислить множество задач, решаемых протоколом, куда попадают те задачи, решение которых уже началось, но еще не закончилось. Вводится простое правило — протокол безопасен, если каждому окончанию решения любой из задач соответствует хотя бы одно начало решения этой задачи. Однако для проверки протокола такого комментирования недостаточно, поскольку для обнаружения несостоятельности необходимо явно описывать модель злоумышленника.
Как известно, чтобы задать тип данных, надо определить возможные значения данных этого типа и указать набор базовых операций, которые можно производить над данными задаваемого типа. В методе проверки типов типы данных определяют те действия, которые можно совершить с помощью данных в протоколе. Например, с помощью ключа шифрования K можно зашифровать сообщение, но ключ нельзя отправить по открытому каналу. А одноразовое случайное число N обычно можно использовать для доказательства того, что переданные данные «свежие» (предотвращения атаки повтора сообщений), что тоже от-
ражается в его типе. Типы данных представляют формальный способ комментирования протокола и дают возможность верификации протокола. В табл. 2 представлены возможные типы данных.
Таблица 2
Типизация
Обозначение Тип
(x: T, U) Тип — зависимая пара (х — связанный в и)
T + U Тип суммы
Nonce[ end L] Одноразовое случайное число, используемое для подтверждения факта I
Top «Верхний»тип данных: все остальные сообщения — его подтипы
Key(T) Общий ключ, на котором возможно шифрование данных типа Т
«О
о
S
3=
В рассматриваемом примере протокола для решения задачи отправки сообщения необходимо защититься от атаки повтора сообщений. Защита осуществляется с помощью ОСЧ Nb. Таким образом у Nb будет тип Nonce [end «отправка Msg»]. Для симметричных алгоритмов этого типа данных достаточно. Для асимметричных — необходимо вводить более сложную систему типов [11].
Таким образом, в протокол добавляются тип для ключа шифрования и синонимы для типа сообщения и типа сети. Общая модель типизированного протокола выглядит следующим образом.
Msg = Top Network = Un
MyNonce(msg) = Nonce[endmsg] MyKey = Key(msg: Msg,-nonce: MyNonce(msg))
TypedSender(net: Network; key: MyKey) : =
repeat inp net (nonce: Un); new (msg: Msg); begin msg;
cast nonce is (nonce': MyNonce(msg)) ; out net {msg,nonce'j key; TypedReceiver(net: Network,key:
63
№5(23)2009
MyKey):=
new (nonce: Un) ;
out net nonce;
inp net (ctext: Un);
decrypt ctext is {msg: Msg;nonce':
MyNonce (msg)}key;
check nonce is nonce';
end msg;
TypedSystem (net: Network) : = new (key: MyKey);
К нотации SPI добавляются операции над типами. Рассмотрим одну из них, необходимую для дальнейшей записи протокола. Операция castXis(Y: T) преобразует значение X в значение Y типа U. Процесс castXis(Y:T) приводит сообщение M к типу T, связывая переменную x с M, и затем запуская P.
После добавления к модели протокола вышеперечисленной информации возможен ее автоматизированный анализ. В ходе анализа «ЯНУС» проверяет, можно ли, используя предлагаемые типы данных, гарантировать решение заданных задач. Для этого на основе правил вычисляются те условия, которые не-
обходимы для отсутствия несостоятельностей в модели. Например, если для противодействия атакам повтора сообщений используется одноразовое случайное число N, то условием будет «N должно генерироваться каждый раз при исполнении протокола». Для вычисления вышеописанного множества условий удобно осуществлять проверку модели протокола от последних по хронологии операций (именно эта особенность метода обусловила выбор названия анализатора). Если множество условий пусто, то протокол считается безопасным. На рис. 2 представлен результат работы анализатора «ЯНУС».
Одним из преимуществ выбранного метода анализа является то, что увеличение размеров анализируемых моделей не сильно влияет на время анализа и общую производительность, так как в процессе анализа не требуется проверять множество всех возможных состояний протокола. К достоинствам анализатора «ЯНУС» относятся наличие графического интерфейса пользователя и возможность работы анализатора под управлением операционной системы Windows, тогда как в основном
Рис. 2. Анализатор протоколов «ЯНУС»
64
аналогичные средства анализа не имеют графического интерфейса и функционируют под управлением операционных систем семейства итх. Предоставляется возможность визуального графического отображения процесса анализа протокола. Встроенный редактор облегчает задачу создания и исправления моделей протоколов. Для заданной модели анализатор строит дерево операций протокола, которое позволяет дополнительно проверить отсутствие логических ошибок в модели. Пользовательский интерфейс и встроенная справочная система выполнены на русском языке. Анализатор также поддерживает анализ протоколов, в которых используются асимметричные алгоритмы.
Между тем, в некоторых случаях невозможно составить модель протокола, которую можно было бы типизировать, например, в случае протоколов с многоуровневыми операциями зашифровывания и электронной цифровой подписи. Как и большинство формальных методов анализа, выбранный метод и анализатор «ЯНУС» рассматривают вычислительные и криптографические алгоритмы как «черные ящики», не обеспечивая в должной мере возможность анализа «математических» несостоятельностей протоколов. Частично этот недостаток компенсируется практическим анализом протоколов в рамках общего технологического итерационного процесса разработки.
Основная идея практического анализа протоколов состоит в привлечении экспертов для ролевого выполнения протокола, включая возможные роли злоумышленников. Для организации работы требуется наличие специальной исследовательской среды информационного обмена, создаваемой на базе существующей сетевой инфраструктуры. Участники протокола объединяются в сессии, в рамках которых каждый из них выполняет свою роль. Протокол декомпозируется на последовательность сообщений, передаваемых между участниками, и выполняемые ими вычислительные и криптографические алгоритмы. Соответственно, участники протокола имеют возможность обмениваться сообщениями и осуществлять необходимые вычисления, для чего
^ № 5(23) 2009
им предоставляется универсальный пользовательский интерфейс. Выполнение протоко- е; ла контролируется средствами среды, с воз- ^ можностью эмуляции атак, в соответствии и с выбранной ролью злоумышленника. §
Возможность выполнения вычислительных операций в распределенных условиях является важным преимуществом практическо- о го анализа протоколов. Участники протокола могут декомпозировать используемые в нем вычислительные алгоритмы на тривиальные алгебраические операции и простые вспомогательные алгоритмы. Декомпозиция алгоритмов позволяет учитывать их внутреннюю структуру и анализировать возможные «математические» несостоятельности протоколов, т. е. ситуации, связанные с некорректным применением математических операций в распределенных условиях. Следует отметить, что наличие или отсутствие «математических» несостоятельностей никаким образом не связано с размерами используемых криптографических ключей. Важна корректность последовательности выполнения составляющих алгоритм операций и правил генерации параметров. Следовательно, в реализации интерфейса для выполнения вычислительных операций можно ограничиться стандартными типами данных, экономя ресурсы на поддержке работы с большими числами, обеспечивающими действительную криптографическую стойкость алгоритмов.
Таким образом, при практическом анализе в какой-то степени можно преодолеть распространенное ограничение формальных методов, зачастую рассматривающих вычислительные и криптографические алгоритмы как «черные ящики».
Другой отличительной особенностью является возможность одновременного анализа нескольких различных протоколов, для каждого из которых может быть создано несколько сессий. В свою очередь это позволяет анализировать несостоятельности, связанные с параллельным выполнением протоколов, например с нелегитимным использованием злоумышленником сообщений, полученных в различных сессиях протоколов (рис. 3).
65
№5(23)2009
Сессия №1
/
/
/
■V
Сессия протокола
/
\ и-и \
\ Отправитель \ I I \ \
^ \--J 1 \
\ Злоумышленник / \ , ___
\ ' У 4 Сессия № 2
\ / _ \
г
о
0
1
0 а гт а
€ &
§
«о
1
1 &
§
€ а
I
гт
0 &
>а
■о
1
а
гт
а &
\ Получатель
\
Аминиаратор
Сервер
Рис. 3. Практический анализ протоколов
Сессия протокола
В целом методика практического анализа дает возможность исследовать выполнение протокола и обнаружить в нем потенциальные недостатки до реальной реализации и внедрения протокола в промышленные информационные системы.
Для практического анализа и исследования протоколов был разработан сетевой программный комплекс (СПК) «ИКАМ» [5]. СПК «ИКАМ» предоставляет участникам протокола универсальный пользовательский web-ин-терфейс для исследования различных протоколов. Программное обеспечение включает в себя подсистемы управления сессиями и сообщениями, а также специализированный вычислитель, поддерживающий традиционные математические преобразования и вычисления в группах точек эллиптических кривых.
Рассмотренный итерационный процесс разработки протоколов основан на принципе кибернетической обратной связи, когда по результатам анализа вносятся исправления в модель протокола. Первоначально визуальные модели позволяют воплотить протокол в отделенном от сознания разработчика виде, в целом обеспечивают целостное восприятие протокола и дают эффективную возможность его обсуждения различными людьми.
На основе визуальной модели возможна автоматизированная генерация моделей протокола для их последующего формального и практического анализа. Одним из эффективных методов формального анализа протоколов является логико-алгебраический метод проверки типов, использующий расширенное БР!-исчисление, реализованный в разработанном средстве автоматизированного анализа
66
протоколов «ЯНУС». В целом достоинством формального анализа является возможность автоматической проверки модели протокола. Основное преимущество при использовании метода проверки типов заключается в том, что не требуется проверять все возможные состояния протокола. Это дает потенциальную возможность эффективно применять данный метод для проверки моделей реальных промышленных протоколов. Отличительной чертой разработанного анализатора «ЯНУС» является наличие графического пользовательского интерфейса для задания модели протокола и отображения процесса и результатов анализа, поддержка операционных система семейства Windows и Linux.
Взаимодополняющим является метод практического анализа протоколов в исследовательской среде информационного обмена с привлечением экспертов, для поддержки которого был разработан сетевой программный комплекс «ИКАМ». Цель практического анализа состоит в обеспечении работы по протоколу до его реализации и реального внедрения в промышленные информационные и вычислительные системы. Основные преимущества практического анализа — возможности проверки модели протокола с нечетко специфицированной схемой обмена сообщениями, проверки протокола в условиях его параллельного выполнения различными группами участников, большей степени свободы в поведении потенциального злоумышленника. Возможно определение несо-стоятельностей, связанных с внутренней структурой вычислительных и криптографических алгоритмов в условиях их распределенного выполнения. В целом предложенный итерационный процесс разработки служит цели создания эффективных протоколов информационного обмена в открытых компьютерных сетях, удовлетворяющих современным требованиям надежности и безопасности.
СПИСОК ЛИТЕРАТУРЫ
1. ЗахаровВ. А., Корчевский А. А. О формальной верификации криптографических протоколов с использованием БР!-исчисления. М.: ВМиК МГУ, 2005.
^ № 5(23) 2009
2. Ильичева Н. В. Язык визуального моделиро- 'ж вания протоколов информационного обмена / на- g учн. рук. А. С. Михайлов / Научная сессия МИФИ-2009. ^ Конференция «Молодежь и наука». В 2 ч. Ч. 2. М.: vj МИФИ, 2009. £
3. Кознов Д. В. Основы визуального моделирования. М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, vj 2008.
4. КосачевА.С., Пономаренко В. Н. Анализ подходов к верификации функций безопасности и мобильности // ИСП РАН. 2004.
5. Михайлов А. С. Архитектура сетевого программного комплекса ИКАМ / Безопасность информационных технологий. 2003. № 3.
6. Михайлов А. С. Итерационный процесс разработки протоколов электронной коммерции / Сборник тезисов докладов Всероссийской научно-практической конференции «Развитие конкуренции на рынке информационных технологий». М.: МФПА, 2009.
7. Селезнёв С. С. «ЯНУС» — анализатор протоколов информационного обмена / научн. рук. А. С. Михайлов / Научная сессия МИФИ-2009. Конференция «Молодежь и наука». В 2 ч. Ч. 2. М.: МИФИ, 2009.
8. Чернышев М. Е. Визуальное моделирование протоколов информационного обмена / Научная сессия МИФИ-2007: сб. науч. тр. Т. 16. М.: МИФИ, 2007.
9. Abadi M., Gordon A. A calculus for cryptographic protocols: the SPI-calculus // Information and Computation. 1999. Vol. 148. №1.
10. Gordon A., Jeffrey A. Authenticity by typing for security protocols/Journal of Computer Security. 2003. Vol. 11. №4.
11. Gordon A., Jeffrey A. Types and effects for asymmetric cryptographic protocols // Journal of Computer Security. 2004. Vol. 12. № 3-4.
12. Meadows C. Formal methods for cryptographic protocol analysis: emerging issues and trends / IEEE Journal on Selected Areas in Communication. 2003. Vol. 21. № 1.
13. Mikhailov A. S., SeleznevS. S. The security protocols analyzer using extensions of SPI-calculus // Proc. 2-nd SYRCoSE. St. Peterburg, Russia. 2008. Vol. 1.
14. Moore J. H. Protocol failures in cryptosystems / IEEE Transactions on Information Theory. 1988. Vol. 5. № 76.
67
