CC BY
35
УДК 004.056.5 DOI 10.23683/2311-3103-2019-5-58-68
Е.А. Перевышина, Л.К. Бабенко
АНАЛИЗ СТОЙКОСТИ К АТАКАМ КРИПТОГРАФИЧЕСКИХ ПРОТОКОЛОВ С ИСПОЛЬЗОВАНИЕМ ФОРМАЛЬНОГО ВЕРИФИКАТОРА SPIN*
В основе безопасности любой защищенной системы, в которой используется передача данных между двумя и более сторонами, лежат криптографические протоколы. Для оценки качества и безопасности разрабатываемых протоколов применяют различные инструменты формальной верификации. Инструменты, ориентированные на верификацию протоколов безопасности такие как Scyther tool, AVISPA, ProVerif, используются для верификации стандартных свойств (конфиденциальности, аутентификации), в то время как универсальные средства применяются для верификации более сложных свойств. Универсальное средство формальной верификации SPIN использует проверку на моделях с применением темпоральной логики. Он не был специально разработан для проведения верификации безопасности протоколов. Этот инструмент более сложный, но гибкий и позволяет разработчику криптографического протокола создать модель своего протокола на требуемом ему уровне абстракций, и проверить его на соблюдение поставленных целей проверки. Цель данной работы - описать верификацию протокола Нидхема-Шредера с помощью средства проверки модели SPIN. Задачи исследования: описать язык Promela, который используется для составления модели в рассматриваемом инструменте; показать модель протокола для определения атак на аутентификацию сторон; описать взаимодействующие стороны, передаваемые данные, порядок передаваемых сообщений между сторонами. В работе описано проведение верификации безопасности протокола Нидхема-Шредера с помощью формального верификатора SPIN на предмет наличия атак на аутентификацию. В результате выполнения работы были обнаружены атаки на аутентификацию сторон, показаны схемы взаимодействия сторон при данных атаках.
Верификация; SPIN; протокол Нидхема-Шредера.
Е.А. Perevyshina, L.K. Babenko
VERIFICATION OF CRYPTOGRAPHIC PROTOCOLS WITH THE SPIN TOOL
The security of any protected system that uses data transfer between two or more parties is based on cryptographic protocols. To assess the quality and safety of the developed protocols, various formal verification tools are used. Formal verification tools, such as Scyther tool, Avispa, ProVerif, used to verify standard properties (confidentiality, authentication), while universal tools are used to verify more complex properties. The universal formal verification tool SPIN uses model checking using temporal logic. SPIN was not specifically designed for protocol security verification. This tool is more complex, but versatile and allows the cryptographic protocol developer to create a model of his protocol at the level of abstractions he needs and check it for compliance with the set verification goals. The purpose of this paper is to describe the verification of the Needham-Schroeder protocol using the SPIN tool. Research objectives: describe the Promela language, which is used to compile the model in the tool in question; show a protocol model to identify attacks on authentication of the parties; describe the interacting parties, the transmitted data, the order of transmitted messages between the parties. The paper describes the security verification of the Needham-Schroder protocol using the formal SPIN verifier for authentication attacks. As a result of the work, attacks on authentication of the parties were detected, the interaction patterns of the parties during these attacks are shown.
Verification; SPIN tool; Needham-Schroeder protocol.
*
Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 18-07-01347.
Введение. В настоящее время актуальным является проведение верификации протоколов. Формальная верификация [1] протоколов необходима как для протоколов только разрабатываемых, чтобы проверить, что данная реализация концептуально правильна, так и для давно существующих, ведь ошибка в протоколе означает, что все реализации, которые реализуют этот протокол ошибочны [2]. В работе [3] рассматриваются способы и методы формального описания моделей.
Для оценки качества и безопасности криптографических протоколов применяют различные инструменты формальной верификации, к наиболее известным относят Scyther tool [4], Avispa [5], ProVerif [6]. Существующие формальные верификаторы могут проверять протокол на уязвимость к атакам на секретность и аутентификацию, так как это самые распространенные атаки на протоколы. Однако, этого недостаточно для полноценного анализа безопасности протокола [7].
Данная статья посвящена верификации протоколов с использованием SPIN [8] - свободно распространяемому пакету программ для формальной верификации проверки модели (model checking) [9, 10]. В качестве криптографического протокола выбран классический протокол Нидхема-Шредера [11].
Инструмент SPIN. SPIN (Simple Promela Interpreter) - свободно распространяемый пакет программ для формальной верификации систем, разработанный в Исследовательском Центре Bell Labs Джерардом Холзманном (Jerard Holzmann), он широко применяется как в обучении студентов методам верификации, так и в промышленности для формального анализа свойств разрабатываемых протоколов и бортовых систем [12].
S in может использоваться в двух режимах - как симулятор и как верификатор. Для доказательства свойств модели используется верификация - другой режим работы S in. Верификатор пытается найти контрпример - неправильную, ошибочную траекторию поведения, опровергающую заданное пользователем свойство, анализируя все возможные поведения модели. Для этого он строит сложную конструкцию - синхронное произведение модели переходов анализируемой системы и автомата Бюхи [13], задающего все возможные некорректные поведения. В случае нахождения контрпримера симулятор S in демонстрирует его пользователю в управляемом режиме симуляции [14].
Для верификации необходимо описать свою собственную модель и проверить ее с помощью собственных целей проверки, причем с применением LTL логики [15] возможны проверки с течением времени, например, проверка того, что некоторое событие произойдет когда-либо в будущем после другого события. Инструмент SPIN изначально был разработан для верификации многопоточных программ. Процессы взаимодействуют между собой с помощью каналов, в которые один процесс может поместить некоторые данные, а другой процесс - извлечь. С помощью данного инструмента можно описать криптографический протокол в виде модели, в которой будут использоваться не программные потоки, а стороны, взаимодействующие в протоколе. Модель описывается на языке Promela [16, 17] (PROcess MEta LAnguage- абстрактный язык спецификации алгоритмов.). Все сообщения между легальными сторонами предварительно будут проходить через сторону злоумышленника. Согласно модели Долева-Яо [18] злоумышленник может выполнять различные действия с каналом передачи данных и самими сообщениями. В частности, для каждого свойства безопасности можно описать поведение злоумышленника и осуществить проверку на устойчивость модели протокола к различным его атакам.
Через каналы осуществляется взаимодействие процессов. Один процесс может поместить в канал некоторые данные, а другой процесс взять их. Ниже приведен пример канала, через который можно передавать 2 переменные типа mty e.
chan chanl = [0] of {mtype, mtype};
В теле процесса описывается порядок передачи сообщений. В каждом процессе указываются каналы, через которые процесс может обмениваться данными с другим процессом. Ниже приведен пример отправки сообщения с двумя случайными числами от процесса A процессу B с использованием ранее описанного канала.
proctype A (chan myChan) {
vas ! Na, Nb;
}
proctype A (chan myChan) {
mtype Na_, Nb_; vas ? Na_, Nb_;
}
Данные могут быть в виде типа bit, byte, short, int. Кроме того возможно использование абстрактного типа данных mty e, который можно использовать в случаях, когда необходимо сравнить совпадение каких-либо данных в канале и смысловое название для них. Ниже приведен пример определения mty e, который можно в дальнейшем использовать.
mtype = {Na, Nb};
После составление модели для возможности её верификации необходимо составить LTL-формулу. LTL представляет собой расширенное условие, в котором помимо классических операторов и, или, не добавляются операторы времени. Таким образом, можно составить более обширное условие для проверки модели, которое будет учитывать различные моменты времени. Полный список операторов приведен в [19]:
С помощью таких операторов составляется LTL-формула. Например, следующая формула означает то, что всегда в будущем q будет истинно до тех пор, пока значение не станет истинным.
[](q Up)
В языке Promela используется так называемый never claim. С помощью LTL-формулы составляется условие, которое никогда не должно выполниться в ходе моделирования. Наполнение never claim создается с помощью соответствующей команды SPIN, на вход которой подается LTL-формула, а на выходе получается never claim, который можно использовать в конце описания модели. Ниже приведен пример never claim для ранее приведенной LTL-формулы. never { /* [](q Up) */ T0_init: do
:: ((p)) -> goto accept_S9 :: ((q)) -> goto T0_init od; accept_S9: do
:: ((((p)) 11 ((q)))) -> goto T0_init od;
}
Описание криптографического протокола Нидхема-Шредера на языке
Promela. Алгоритм Нидхема-Шредера предполагает, что при построении отношений публичные ключи партнеров не хранятся на каждой стороне, за ними надо обращаться к серверу. Без потери общности будем считать, что каждый участник знает публичные ключи всех возможных партнеров. Рассмотрим сокращенный алгоритм Нидхема-Шредера.
1.
2.
3.
В модели так же присутствует возможность проверки протокола в случае активных атак злоумышленника, в частности атаки Лоу [20] и подмены случайного числа.
Атака Лоу:
1.
2.
3.
4.
5.
6.
Атака на подмен случайного числа для проверки корректной обработки данной ситуации в модели протокола:
1. A-I: Ei(Na,A)
2. I-B : Eb( Wr о ng N , A )
3. B-I: E a IW r о ng N ,Nb)
4. I — A: Ea(WrongN, Nb) в случае не совпадения случайного числа стороны должны прервать текущий сеанс.
Смоделируем протокол Нидхама-Шредера на языке Promela.
Сначала определим абстрактные типы mtype, которые в дальнейшем будут использованы как элементы в сообщениях:
mtype = {Na, A, B, C, Nb, AKey, BKey, CKey, WrongN};
Функция CheckKeys вызывается для проверки успешности аутентификации сторон:
#define CheckKeys(KCheck) if \
:: Key1 == KCheck -> AuthGood = 1 \ :: else skip \ fi;
В этой функции параметром в нее подается текущий ключ, который сравнивается с ранее запомненным на предыдущей итерации протокола, и в случае их совпадения флаг AuthGood устанавливается в единицу.
В следующих строках указаны каналы передачи, в которых может поместиться 3 элемента сообщения:
chan dy1 = [0] of {mtype, mtype, mtype}
chan dy2 = [0] of {mtype, mtype, mtype}
Через данные каналы будет осуществляться передача сообщений между сторонами. При проверке модели со злоумышленником, будет использоваться два канала для моделирования нескольких сессий.
Объявим следующие флаги: AuthGood = 0; Fini = 0; Fin2 = 0. После исполнения протокола значения всех флагов должно быть равно единице, в таком случае модель пройдет верификацию по LTL формуле успешно. Флаг AuthGood указывает на успешность аутентификации сторон, флаги Fin1 и Fin2 указывают на успешность завершения хода протокола на обеих сторонах. Это нужно, в случае атак на подмену значения, в таком случае протокол не дойдет до конца из-за его остановки после проверки на возвращаемое значение, и эти флаги будут равны нулю.
Далее опишем процесс стороны A
15 proctype AP (chan ch; mtype SideKey)
16 {
17 mtype Na_, A_, B_, C_, Nb_, Na_ret, MyKey;
18 Na_ = Na;
19 A_ = A;
20 B_ = B;
21
22 Keyl = SideKey;
23
24 ch ! SideKey, Na_, A_;
25 ch ? MyKey, Na_ret, Nb_;
26 if
27 :: Na_ret == Na_ ->
28 ch ! SideKey, Nb_, 0;
29 Fini = 1;
30 :: else
31 fi
В данном протоколе используется асимметричное шифрование в каждом сообщении. Таким образом при моделировании шифрования при передаче данных используется следующий порядок: [ключ] [элемент] [элемент]. В переменную Key 1 запишется ключ, который будет использоваться при отсылки сообщения 1. Это нужно для того, чтобы узнать на каком ключе будет зашифровано отправляемое сообщение. В строках (15) - (32) описан процесс стороны A. Входными параметрами являются канал передачи и ключ для общения с выбранной стороной. Внутри тела процесса указаны переменные, которые будут использоваться при передачи сообщений. В строке (24) отправляется сообщение 1, в (25) сообщение 2. Далее идет блок проверки возвращаемого случайного числа в строках (26) - (31) и в случае успеха, отправляется последнее сообщение 3. Так же в строке (29) устанавливается флаг успешности завершения протокола на стороне A. В случае если случайное число не совпадет с первоначальным флаг не установится, а 3 сообщение не будет отправлено, то есть произойдет обрыв сессии.
Аналогичным образом описывается процесс стороны B в строках (34)-(55):
34 proctype BP (chan ch)
35 {
36 mtype Na_, ID_, B_, Nb_, Nb_ret, SideKey, MyKey;
37 Nb_ = Nb;
38 B_ = B;
39 ch ? MyKey, Na_, ID_;
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55 }
Но, имеются некоторые отличия, в частности в строке 41 присутствует проверка наличия атаки на подмену стороны как в атаке Лоу. Вызывается функция, которая сравнивает ключи, и при их несовпадении не изменяет значение контрольного флага. В случае, если отправленное первой стороной сообщение было зашифровано на одном ключе, а пришло в текущую сторону зашифрованным на другом ключе, то имеет место атака. В строках (43)-(46) после получения сообщения 1 в зависимости от присланного идентификатора выбирается ключ для шифрования сообщения 2. В области (50)-(54) так же осуществляется проверка возвращаемого случайного числа и установка флага успешного завершения протокола.
В строках (57)-(70) описан злоумышленник, использующий атаку Лоу. Он перехватывает все сообщения и изменяет содержимое сообщений для успешной атаки:
57 ргоСуре Айаск1 (сИап сЫ, сИ2)
58 {
59 mtype Na , ГО , В , № , № гй, SideKey, Na get, ГО get, МуКеу;
60 МуКеу = СКеу;
61 сИ1 ? МуКеу, Na_get, ID_get;
62 сИ2 ! ВКеу, Na_get, ID_get;
63
64 mtype ге1, ге2, ге3;
65 сИ2 ? ге1, ге2, ге3;
66 сИ1 ! ге1, ге2, ге3;
67
68 сИ1 ? МуКеу, Nb ге^ 0;
69 сИ2 ! ВКеу, Nb_ret, 0;
70 }
В строках (72)-(83) описан злоумышленник, использующий атаку на подмен случайного числа:
72 ргоСуре Айаск2 (сИап сИ1, сИ2)
73 {
74 т1уре ге1, ге2, ге3;
75 сИ1 ? ге1, ге2, ге3;
76 сИ2 ! ге1, WrongN, ге3;
77
78 сИ2 ? ге1, ге2, ге3;
79 сИ1 ! ге1, ге2, ге3;
80
СпескК^(МуКеу); Я \
:: ГО_ == А -> SideKey = АКеу \ :: ГО_ == С -> SideKey = СКеу \ А;
сИ ! SideKey, №_, №_; сИ ? МуКеу, Nb_ret, 0; if
:: №_гй == Nb_ -> Fin2 = 1; :: else
А;
81 82 83 }
ch1 ? rel, re2, 0; ch2 ! rel, re2, 0;
В области строк (85)-(94) описана основная функция, которая вызывает созданные ранее процессы:
85 шк
86 {
87
88
89
90
91
92
93
94 }
/*run AP(dy2, BKey); run BP(dy2);*/
run AP(dy1, CKey); /*run Attack1(dy1, dy2);*/ run Attack2(dy1, dy2); run BP(dy2);
В случае если оставить только строки (87) и (88), можно построить схему взаимодействия сторон при обычном ходе протокола без каких-либо атак (рис. 1).
Рис. 1. Схема протокола Нидхема-Шредера
Для проверки нашей модели было определено два злоумышленника. Каждую атаку необходимо проверять отдельно.
Для верификации модели протокола против атаки Лоу необходимо оставить строки (90), (91), (93).
Для проведения атаки на подмену случайного числа - строки (90), (92), (93).
В строках (99) - (105) описана проверочная LTL формула "[](! || !x || !y)". В виде "never claim" это значит, что все контрольные флаги по завершения модели никогда не должны принимать значение 0, то есть, контрольные флаги успешности завершения протокола на обеих сторонах и совпадение ключей шифрования при отсылке сообщения должны быть равны единице на момент окончания исполнения протокола:
!y) */
!x || !y)) -> goto T0_init
99 never { /* [](!p II !x ||
100 accept_init:
101 T0 init:
102 do
103 :: ((!p
104 od;
105 }
Проведем верификацию модели при наличии злоумышленника первого типа. В инструменте SPIN переходим во вкладку "Verification", включаем использование "never claim" в соответствующем поле и производим верификацию кнопкой "Run". Обнаружилась ошибка (рис. 2).
040 Paper.pml
Spin Version 6.4.7 - 19 August 2017 :: ¡Spin Version 1.1.4 - 27 November 2014 Edit/View Simulate I Replay | Verification Swarm Run <Help> Save Session Restore Session <Qult>
safety > exhaustive
p^^nvali^endstates (deadlock) " + minimized automata (slow)
^^Ul^^^^B violations n + collapse compression
r + xr/xs assertions ' hash-compact bitstate/supi
Liven ess_|
O non-progress cycles " do not u<
<•' acceptance cycles ® use clainr
r enforce weak fairness constraint claim name
> depth-first search I? + partial order reduction n + bounded context switching with bound :[o
mtype = {Na, А, В, C, Nb, AKey, ВКеу, CKey,
WrongN):
2 »define CheckKeys(KCheck) if\
3 :: Key1 ==
ck-> AuthGood = 1 \
5 fi;
6
7 chan dy1 = [0] of {mtype, mtype, mtype}
8 chan dy2 = [0] of {mtype, mtype, mtype}
10 bit AuthGood = 0;
11 bit Fini = 0;
12 bit Fin2 = 0;
13
14 mtype Key1 ;
15 proctype AP (chan ch; mtype SideKey)
16 {
17 mtype Na_, A_, B_, C^ Nb_,
, МуКеу; Na = Na:
19 A = A;
20 B_= B;
21
22 Key1 = SideKey;
23
Claims_| P + iterative search for short tr
:laim or HI property breadth-first search
+ partial order reduction * report unreachable code
Show Show
Error Advanced
Trapping Parameter Options Settings
Full statespace search for:
never claim + (never_0) assertion violations + (if within scope of claim) acceptance cycles + (fairness disabled) invalid end states - (disabled by never claim)
State-vector 100 byte, depth reached 57, errors: 1 26 states, stored 0 states, matched 26 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved)
Stats on memory usage (in Megabytes): 0.003 equivalent memory usage for states (stored*(State-vi 0.287 actual memory usage for states 128.000 memory used for hash table (-w24) 0.534 memory used for DFS stack (-m10000) 128.730 total actual memory usage
pan: elapsed time 0 seconds
To replay the error-trail, goto Simulate/Replay and select "Run"
Рис. 2. Ошибка при верификации
Для более подробного рассмотрения причины ошибки во вкладке " Simulate / Replay" строим схему взаимодействия сторон (рис. 3).
" Random, with seed: ("' interactive (for resolution of all non determinism) • Guided, with trail: |Paper.pml.trail browse
initial steps skipped: [Ô
maximum number of steps: 110000
№ Track Data Values (this can be slow)
chan dy1 = [0] of (mtype, mtype, mty chani dy2 = [0] of (mtype, mtype, mty
mtype Keyt;
proctype AP (chan ch; mtype SideK
II <•" blocks new messages r loses new messages r MSC+stmnt MSC max text width [20 MSC update delay [25
AuthGood = 9 BPC3);B_ = В BP(3):ID = ft BP(3):HyKey = BK
ey
BP(3):Ma = Ma BP(3):Nb = Mb BP(3):Mb_ret = N
b
BP(3):SideKey = AKey
Fini = 1 Fin2 » 1 Keyl = CKey
55: proc ■ (never_0:1) Paper.pml:103(state 1) [(((!<AuthGood)||!(Fin1))||!<Fin2)))] 56: proc 0 terminates <<<<<START OF CYCLE»»>
57: proc - (never_0:1) Paper.pml:103 (state 1) [(((!(AuthQood)||!(Fin1))||!(Fin2)))I 58: proc - (never_0:1) Paper.pml:103(state 1) [(((!(AuthQood)||!(Fin1))||!(Fin2)))] spin: trail ends after 5& steps »processes: 0 MSC: ~G line 102
58: proc - (never_0:1) Paper.pml:102 (state 3)
Рис. 3. Схема атаки на протокол при наличии злоумышленника первого типа
Как видно из схемы, в данном случае производится атака Лоу. Так же в левом нижнем окне выводятся значения переменных в последнем состоянии. Из этих значений можно выяснить, какие флаги не были установлены в единицу, и где произошла ошибка. В данном случае, флаг "AuthGood" оказался равным нулю. Это свидетельствует о том, что было подменено сообщение при передаче из стороны А к В, в частности, содержимое сообщения осталось таким же, но ключ шифрования был использован разный. В случае второго типа злоумышленника, верификация так же показывает ошибку. В данном случае, производится атака на подмену случайного числа, и схема взаимодействия выглядит как на рис. 4.
Рис. 4. Схема атаки на протокол при наличии злоумышленника второго типа
По схеме можно увидеть, что протокол перестал выполняться после 2 сообщения. Злоумышленник, перехватив первое сообщение, поменял значение случайного числа "Na" на "WrongN". Так же в данном случае значение контрольных флагов "Fini" и "Fin2" принимают значение нуля. Это свидетельствует о том, что протокол на обеих сторонах не был выполнен до конца, в частности из-за некорректной проверки на возвращенное случайное число, которое было подменено злоумышленником.
Заключение. Данная работа посвящена методу определения атак на аутентификацию сторон с помощью формального верификатора SPIN.
В отличие от других верификаторов в SPIN можно описать свою собственную модель и проверить ее с помощью собственных целей проверки, с применением линейной темпоральной логики LTL.
В качестве примера рассмотрен протокол Нидхема-Шредера.
В работе приведено описание языка Promela, который используется для составления модели в рассматриваемом инструменте. Приведена модель протокола для определения атак на аутентификацию сторон. Описаны взаимодействующие стороны, передаваемые данные, порядок передаваемых сообщений между сторонами. Проведена верификация безопасности криптографического протокола с помощью инструмента SPIN.
В результате проделанной работы были обнаружены атаки на аутентификацию сторон, показаны схемы взаимодействия сторон при данных атаках.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Meadows C. Formal Verification of Cryptographic Protocols // Proceedings of the 4th International Conference on the Theory and Applications of Cryptology: Advances in Cryptology.
- Springer-Verlag, 1995. - P. 135-150.
2. Черемушкин А.В. Криптографические протоколы. Основные свойства и уязвимости.
- М.: Академия, 2009. - 272 с.
3. Косачев А.С., Пономаренко В.Н. Анализ подходов к верификации функций безопасности и мобильности. - М.: Институт системного программирования РАН, 2004. - 101 с.
4. Scyther tool: automated analysis of security protocols. - https://people.cispa.io/cas.cremers/ scyther/.
5. The AVISPA Project. - http://www.avispa-project.org/.
6. ProVerif: Cryptographic protocol verifier in the formal model. - https://prosecco.gforge.inria.fr/ personal/bblanche/proverif.
7. Котенко И.В., Резник С.А., Шоров А.В. Верификация протоколов безопасности на основе комбинированного использования существующих методов и средств // Тр. СПИИРАН.
- Т. 8. - С. 292-310.
8. SPIN home page. - http://SPINroot.com.
9. Кларк Э., Грамберг О., Пелед Д. Верификация моделей программ: Model Chec ing. - M.: МЦНМО, 2002.
10. Лепендин А.А., Уберт А.В. Метод верификации моделей в приложении к анализу протоколов аутентификации // Известия Алтайского государственного университета. - 2012.
- Т. 2. - Вып. 1 (73). - С. 84-86.
11. Needham R.M., Schroeder M.D. Using encryption for authentication in large networks of computers // Communications of the ACM. - 1978. - Vol. 21, No. 12. - P. 993-999.
12. Шошмина И.В., Карпов Ю.Г. Введение в язык Promela и систему комплексной верификации S in. - СПб.: Санкт-Петербургский государственный политехнический университет, 2009.
13. Миронов А.М. Верификация программ методом Model Chec ing. - M., 2012. - 84 c.
14. Лукин М.А., Шалыто А.А. Верификация автоматных программ с использованием верификатора SPIN // Научно-технический вестник информационных технологий, механики и оптики. - 2008. - № 8 (53). - С. 145-162.
15. Карпов Ю.Г. Темпоральные логики для спецификации свойств программных и аппаратных систем // Компьютерные инструменты в образовании. - 2009. - № 2. - C. 45-56.
16. Holzmann G.J. The model checker SPIN // IEEE Transactions on software engineering.
- 1997. - Vol. 23, No. 5. - P. 279-295.
17. Barnat J., Brim L., Stnbmä J. Distributed LTL model-checking in SPIN // International SPIN Workshop on Model Checking of Software. - Springer, Berlin, Heidelberg, 2001. - P. 200-216.
18. Борхаленко В.А. Модель нарушителя для формальной верификации криптографических протоколов // Естественные и математические науки в современном мире: C6. ст. по матер. XXVI междунар. науч.-практ. конф. - Новосибирск: СибАК, 2015. - № 1 (25).
19. CorradiniA. The SPIN Model Checker. Metodi di Verifica del Software. Lezione 5.2013.
20. Lowe G. An Attack on the Needham - Schroeder Public - Key Authentication Protocol // Information processing letters. - 1995. - Vol. 56, No. 3.
REFERENCES
1. Meadows C. Formal Verification of Cryptographic Protocols, Proceedings of the 4th International Conference on the Theory and Applications of Cryptology: Advances in Cryptology. Springer-Verlag, 1995, pp. 135-150.
2. Cheremushkin A.V. Kriptograficheskie protokoly. Osnovnye svoystva i uyazvimosti [Cryptographic protocols. Basic properties and vulnerabilities]. Moscow: Akademiya, 2009, 272 p.
3. Kosachev A.S., Ponomarenko V.N. Analiz podkhodov k verifikatsii funktsiy bezopasnosti i mobil'nosti [Analysis of approaches to verification of security and mobility functions]. Moscow: Institut sistemnogo programmirovaniya RAN, 2004, 101 p.
4. Scyther tool: automated analysis of security protocols. Available at: https://people.cispa.io/ cas.cremers/scyther/.
5. The AVISPA Project. Available at: http://www.avispa-project.org/.
6. ProVerif: Cryptographic protocol verifier in the formal model. Available at: https://prosecco.gforge.inria.fr/personal/bblanche/proverif/.
7. Kotenko I.V., Reznik S.A., Shorov A.V. Verifikatsiya protokolov bezopasnosti na osnove kombinirovannogo ispol'zovaniya sushchestvuyushchikh metodov i sredstv [Security protocols verification combining existing approaches and tools], Tr. SPIIRAN [SPIIRAS Proceedings], Vol. 8, pp. 292-310.
8. SPIN home page. Available at: http://SPINroot.com.
9. KlarkE., Gramberg O., PeledD. Verifikatsiya modeley programm: Model Checking [Program Model Verification: Model Checking]. Moscow: MTSNMO, 2002.
10. Lependin A.A., Ubert A.V. Metod verifikatsii modeley v prilozhenii k analizu protokolov autentifikatsii [Model verification method as applied to authentication protocol analysis], Izvestiya Altayskogo gosudarstvennogo universiteta [Proceedings of the Altai state University], 2012, Vol. 2, Issue 1 (73), pp. 84-86.
11. Needham R.M., Schroeder M.D. Using encryption for authentication in large networks of computers, Communications of the ACM, 1978, Vol. 21, No. 12, pp. 993-999.
12. Shoshmina I.V., Karpov Yu.G. Vvedenie v yazyk Promela i sistemu kompleksnoy verifikatsii Spin [Introduction to the language Promela and the verification system of complex Spin]. Saint Petersburg: Sankt-Peterburgskiy gosudarstvennyy politekhnicheskiy universitet, 2009.
13. Mironov A.M. Verifikatsiya programm metodom Model Checking [Verification of programs using Model Checking]. Moscow, 2012, 84 p.
14. Lukin M.A., Shalyto A.A. Verifikatsiya avtomatnykh programm s ispol'zovaniem verifikatora SPIN [Verification of automated programs using the SPIN verifier], Nauchno-tekhnicheskiy vestnik informatsionnykh tekhnologiy, mekhaniki i optiki [Scientific and technical Bulletin of information technologies, mechanics and optics], 2008, No. 8 (53), pp. 145-162.
15. Karpov Yu.G. Temporal'nye logiki dlya spetsifikatsii svoystv programmnykh i apparatnykh sistem [Temporal logics for specifying the properties of software and hardware systems], Komp'yuternye instrumenty v obrazovanii [Computer tools in education], 2009, No. 2, pp. 45-56.
16. Holzmann G.J. The model checker SPIN, IEEE Transactions on software engineering, 1997, Vol. 23, No. 5, pp. 279-295.
17. Barnat J., Brim L., Stnbrna J. Distributed LTL model-checking in SPIN, International SPIN Workshop on Model Checking of Software. Springer, Berlin, Heidelberg, 2001, pp. 200-216.
18. Borkhalenko V.A. Model' narushitelya dlya formal'noy verifikatsii kriptograficheskikh protokolov [The intruder model for cryptographic protocols formal verification], Estestvennye i matematicheskie nauki v sovremennom mire: Cb. st. po mater. XXVI mezhdunar. nauch.-prakt. konf. [Natural and mathematical Sciences in the modern world: a Collection of articles on the materials of the XXVI international scientific and practical conference]. Novosibirsk: SibAK, 2015, No. 1 (25).
19. CorradiniA. The SPIN Model Checker. Metodi di Verifica del Software. Lezione 5.2013.
20. Lowe G. An Attack on the Needham - Schroeder Public - Key Authentication Protocol, Information processing letters, 1995, Vol. 56, No. 3.
Статью рекомендовал к опубликованию д.т.н., профессор Я.Е. Ромм.
Перевышина Елена Андреевна - Южный федеральный университет; e-mail: lobova.elena702@gmail.com; 347928, г. Таганрог, ул. Чехова, 2; тел.: 89518327147; кафедра БИТ; аспирант.
Бабенко Людмила Климентьевна - e-mail: l baben o@sfedu.ru; тел.: 89054530191; кафедра безопасности информационных технологий; д.т.н.; профессор.
Perevyshina Elena Andreevna - Southern Federal University; e-mail: lobova.elena702@gmail.com; 2, Chehov street, Taganrog, 347928, Russia; phone: +79518327147; the department of security in data processing technologies; postgraduate student.
Babenko Lyudmila Klimentevna - e-mail: blk@fib.tsure.ru; phone: +79054530191; the department of security of information technologies; dr. of eng. sc.; professor.
