CC BY
19
УДК 004.056 DOI 10.23683/2311-3103-2019-5-46-57
Л.К. Бабенко, И.А. Писарев
ВЕРИФИКАЦИЯ БЕЗОПАСНОСТИ КРИПТОГРАФИЧЕСКИХ ПРОТОКОЛОВ ПО ИСХОДНЫМ КОДАМ СИСТЕМЫ ЭЛЕКТРОННОГО ГОЛОСОВАНИЯ С ПРИМЕНЕНИЕМ МНОЖЕСТВЕННОГО БРОСАНИЯ
БЮЛЛЕТЕНЕЙ*
Разработка систем электронного голосования является сложной и актуальной задачей. В основе безопасности любой системы, использующей сетевое взаимодействие, лежат криптографические протоколы. Их качество проверяется с помощью средств формальной верификации. Однако средства формальной верификации работают с протоколами в абстрактном виде формата Alice-Bob, что не позволяет полностью проверить протокол на всевозможные атаки. Кроме того, при реализации протокола на практике с помощью какого-либо языка программирования возможно изменение данного протокола относительно его первоначального вида. В итоге получается, что абстрактный первоначальный вид протокола, который был проверен средствами формальной верификации считается безопасным, но вот измененный реализованный протокол, имеющий другой вид уже не может быть признан безопасным. Таким образом актуальным является проведение верификации криптографического протокола системы электронного голосования по исходным кодам. В работе была описана система электронного голосования с применением множественного бросания бюллетеней. Описан парсер для извлечения структуры криптографического протокола, с помощью которого была получена структура протокола голосования. Произведена трансляция криптографического протокола электронного голосования с применением множественного бросания бюллетеней в язык спецификации CAS+ для автоматизированного верификатора Avispa для верификации безопасности протокола.
Электронное голосование; криптографические протоколы; криптографическая защита; верификация безопасности криптографических протоколов.
L.K. Babenko, I.A. Pisarev
SECURITY VERIFICATION OF CRYPTOGRAPHIC PROTOCOLS OF ELECTRONIC VOTING SYSTEM USING MULTIPLE THROWING OF BULLETINS BY SOURCE CODES
The development of electronic voting systems is a complex and urgent task. The security of any system using networking is based on cryptographic protocols. Their quality is checked using formal verification tools. However, formal verification tools work with protocols in an abstract form of the Alice-Bob format, which does not allow fully checking the protocol for all kinds of attacks. In addition, when implementing the protocol in practice using any programming language, it is possible to change this protocol with respect to its original form. As a result, it turns out that the abstract initial form of the protocol, which was verified by means offormal verification, is considered safe, but the modified implemented protocol, having a different look, can no longer be considered safe. Thus, it is relevant to verify the cryptographic protocol of the electronic voting system using source codes. The paper described the electronic voting system using multiple casting of ballots. A parser for extracting the structure of a cryptographic protocol is described, with the help of which the structure of the voting protocol was obtained. The cryptographic protocol of electronic voting was translated using multiple casting of ballots into the CAS + specification language for the Avispa automated verifier to verify the security of the protocol.
Electronic voting; cryptographic protocols; cryptographic protection; security verification of cryptographic protocols.
* Работа поддержана грантом РФФИ № 18-07-01347 А. 46
Введение. При разработке систем электронного голосования важным является верификация безопасности используемых в ней криптографических протоколов. Обычно, криптографический протокол проверяется средствами формальной верификации [1-3] на этапе его создания. Авторами работы уже были проведены исследования безопасности криптографических протоколов системы электронного [4] голосования. Стоит отметить, что данный подход не позволяет полностью проверить безопасность протокола, поскольку при его реализации на языке программирования могут происходить его изменения и появляться новые ошибки. Таким образом, наиболее эффективным вариантом верификации безопасности криптографических протоколов является их верификация по исходным кодам. Для возможности ее проведения необходимо извлечь структуру криптографического протокола из исходного кода, транслировать структуру в выбранный язык спецификации для инструмента формальной верификации и непосредственно произвести верификацию. На данный момент существует ряд работ, в которых поднимается этот вопрос для языков программирования C [5-7], Java [8-10], F# [11-16]. Однако, большинство данных работ используют специальные аннотации в исходном коде, которые упрощают процесс извлечения структуры криптографических протоколов. В данной работе предлагается провести анализ безопасности криптографического протокола системы электронного голосования с применением множественного бросания бюллетеней, реализованной на языке программирования C#, по исходным кодам.
Электронное голосование с применением множественного бросания бюллетеней. Система электронного голосования [17] основана на принципе слепых посредников. В протоколе непосредственно голосования учувствуют 4 стороны: клиент, сервер аутентификации, сервер голосования и доска бюллетеней. Основная идея в том, что сервер аутентификации аутентифицирует клиента и перенаправляет информацию серверу голосования. При этом отсутствует какая-либо связь аутентификационных данных с информацией о голосе. Общая схема взаимодействия сторон представлена на рис. 1.
Рис. 1. Общая схема взаимодействия сторон
Принцип множественного бросания бюллетеней заключается в создании L количества бюллетеней, где L - количество кандидатов. Сервер присылает идентификатор голосования ID аутентифицированному пользователю. Генерируются фейковые идентификаторы Fa eID. Пользователь делает свой выбор, например, в нашей случае он голосует за Petrov (рис. 2). Создается 4 бюллетеня, в случайном порядке выставляются голоса в них, но так, чтобы не было двух одинаково заполненных бюллетеня. Для бюллетеня с реальным голосом используется идентификатор голосования ID, а для остальных Fa eID. После чего все бюллетени шифруются асимметрично публичным ключом и отправляются на BB, а голосующий может себе оставить 1 бюллетень с фейковым Fa eID. Для recei t-freeness, coercion-resistance необходимо убрать какие-либо способы доказать, что пользователь проголосовал определенным образом. Поэтому оставить себе бюллетень с реальным
голосом нельзя. В тоже время бюллетень с фейковым Fa eID позволит проверить, что все бюллетени пользователя дошли с вероятностью в данном случае 1/4. Поскольку сервер не знает, какой именно из бюллетеней является реальным, ему придется опубликовать без подмены все. В противном случае, если хотя бы 1 пользователь обнаружит, что бюллетень не дошел до ВВ, это покажет, что сервер нарушил правила, подменив бюллетень или не опубликовав их. В клиенте используется проверка того, что голос дошел до ВВ вне зависимости от того хотел ли пользователь проверить свой голос или нет.
ID: ff23ab
1. Petrov
2. Sidorov
3. Pupkin
4. Serov
ID: abfc52
1. Petrov
2. Sidorov
3. Pupkin
4. Serov
ID: 414f2c
1. Petrov
2. Sidorov
3. Pupkin
4. Serov
ID: abaca3
1. Petrov
2. Sidorov
3. Pupkin
4. Serov
Рис. 2. Пример заполнения бюллетеней для голосования типа 1 из 4
В системе бюллетень представляет собой пару: [ID, Индекс кандидата]. Для примера выше список будет следующим:
[ID1,2], [ID2,4], [ID3,1], [ID4,3]
Шифруются только идентификаторы и в виде, приведенном ниже, бюллетени отправляются на BB.
[Epk(ID1),2], [Epk(ID2),4], [Epk(ID3),1], [Epk(ID4),3]
[EID1,2], [EID2,4], [EID3,1], [EID4,3]
Сервер голосования пропускает только бюллетени с равномерным распределением голосов, то есть не должно быть двух одинаково заполненных бюллетеней. Это процесс верификации голоса. В нашем принципе проверка осуществляется открыто и сразу, в отличие от применения доказательства с нулевым разглашением в других схемах.
Протокол голосования:
1. VS->V: Evvs(N)
2. V->AS: Evas(AuthData, Evvs(N))
3. AS->VS: Easvs(Evvs(N))
4. VS->V: Evvs(N, ID, Sign(ID))
5. V:
5.1. Epk(FakeID1),2: EID1,2
5.2. Epk(EakeID2),4: EID2,4
5.3. Epk(ID),1: EID3,1
5.4. Epk(FakeID3),3: EID4,3
6. V->VS: Evvs(N, EID1, 2, EID2, 4, EID3, 1, EID4, 3)
7. VS->BB:
EID1 - 2
EID2 - 4 EID3 - 1 EID4 - 3
8. VS->V: Evvs(N, Sign(EIDl), Sign(EID2), Sign(EID3), Sign(EID4))
9. V: EID1 - 2, V check EID1 - 2 on BB and Sign(EIDl).
Перед началом протокола симметричные ключи vas, asvs, vvs генерируются с помощью протокола ECDHE Диффи-Хеллмана на эллиптических кривых с применением эфемерных ключей между сторонами V-AS, AS-VS, V-VS соответственно.
В сообщении (1) посылается случайное число для аутентификации. В сообщении (2) с помощью принципа слепых посредников посылается случайное число N зашифрованное на ключе vvs, к этому прикладываются аутентификационные данные пользователя AuthData, все это шифруется на ключе vas и отправляется стороне AS. AS может прочесть только AuthData. Проверяет наличие этих аутентификационных данных в БД и в случае успеха перенаправляет другую часть в виде сообщения (3). VS проверяет значение числа N, и посылает пользователю сообщение (4) с идентификатором для голосования ID и его подписью Sign(ID). На шаге (5) клиент делает свой выбор и клиентское ПО формирует фейковые бюллетени вместе с реальной, шифруя каждый идентификатор публичным ключом, после чего посылает пары [EID, голос] серверу голосования в виде сообщения (6). VS посылает бюллетени на BB. VS отправляет обратно подписи EID после чего пользователь выбирает проверочный бюллетень, проверяет его наличие на BB и его подпись Sign(EID).
Верификация безопасности по исходным кодам. Для начала необходимо получить исходный код рассматриваемой системы. В случае готовой системы можно использовать декомпиляцию кода и тем самым получить исходный код. В случае же разрабатываемой системы в данный момент исходный код уже имеется. Далее из исходного кода необходимо извлечь структуры криптографических протоколов. Это делается с помощью разрабатываемого авторами cry togra hic protocols extractor [18]. На данный момент возможно извлечение структур протоколов из исходных кодов языка программирования C#. В результате получаются два вида описания протокола. Краткое описание протокола в виде Alice-Bob и полное описание, содержащего информацию об исходном коде.
Рис. 3. Получение структур криптографических протоколов
Блок 2 изображен на рис. 4. Здесь на основе краткого описания протокола осуществляется трансляция в языки спецификации для автоматизированных верификаторов безопасности протоколов, таких как Avis a, Scyther. В результате формальной верификации будет получен список атак на данный протокол.
Краткое описание протокола формата Alice-Bob
Трансляция в
язык спецификаци и для Avispa, Scyther
Формальная Атаки на
верификация протокол
Рис. 4. Проведение формальной верификации для нахождения атак на протокол на основе краткого описания протокола
Извлечение структуры криптографического протокола. Алгоритм анализа использует парсер исходного кода C# Roslyn [19]. С помощью него можно получить древовидную структуру исходного кода, причем возможно использование фильтров. В нашем случае интересны фильтры:
1. InvocationExpressionSyntax - вызов выражений.
2. VariableDeclarationSyntax - объявление переменных.
3. AssignmentExpressionSyntax - выражение присваивания.
4. IfStatementSyntax - утверждение с оператором условия.
С помощью фильтров можно получить нужное выражение, после чего можно просмотреть древовидную структуру этого выражения. Главной целью использования данного парсера является нахождение перехода от одной переменной к другой. В данном случае нас интересует переход Mlencl -> M1. Достигается это путем поиска данных типа "IdentifierName" совместно с применением черного списка выражений. Например, здесь используется вызов метода "Encry t", а так же ранее объявленный объект класса асимметричного шифрования "RSA", которые присутствуют в черном списке, а как раз нужные нам Mlencl и M1 отсюда можно получить, причем при операции присвоения осуществляется поиск с начала списка, где первый элемент будет переменная, которой будет присваиваться значение, а остальные те что ниже и не входят в черный список будет являться новым присваиваемым значением.
В основе алгоритма лежит определение ключевых участков кода, содержащих специфичные для криптографических протоколов конструкции. В конечном счете, задача сводится к определению цепочки преобразования переменных от состояния посылки или приема сообщений (помечено красным) до их первоначальной инициализации (помечено зеленым), при этом учитывая возможные криптографические преобразования (помечено желтым). В ходе построения цепочки строится дерево, узлами которого являются переменные с дополнительной информацией о них, включающей определения типа данных для конечных листьев дерева и криптографических алгоритмов в узлах дерева. Структура дерева позволяет описать все цепочки преобразований данных, поскольку данные в сообщении комбинируются различными способами, цепочки могут сильно разветвляться и соединяться.
В результате была извлечена структура следующего вида:
1. VS->V: Evvs(MessLengthl)
2. VS->V: Evvs(N)
3. VS->V: Evas(MessLength2)
4. V->AS: Evas(AuthData, Evvs(N))
5. VS->V: Easvs(MessLength3)
6. AS->VS: Easvs(Evvs(N))
7. VS->V: Evvs(MessLength4)
8. VS->V: Evvs(N, ID, Sign(ID))
9. VS->V: Evvs(MessLength5)
10. V->VS: Evvs(N, Epk(IDl), Indl, Epk(ID2), Ind2, Epk(ID3), Ind3, Epk(ID4), Ind4)
11. VS->V: Evsbb(MessLength6)
12. VS->BB: Evsbb(N, Epk(ID1), Ind1, Epk(ID4), Ind4)
13. VS->V: Evvs(MessLength7)
14. VS->V: Evvs(N, Sign(Epk(ID1)), Sign(Epk(ID4)))
Epk(ID2), Ind2, Epk(ID3), Ind3, Sign(Epk(ID2)), Sign(Epk(ID3)),
Транслятор в язык CAS+ для верификатора Avispa. В формальных верификаторах существуют схожие понятия, которыми оперируют при верификации безопасности криптографических протоколов. Эти понятия: Роли, каналы передачи данных, изначальные знания ролей, модель злоумышленника, изначальные знания злоумышленника, передача сообщений. Задачей является автоматизированным способом транслировать описание протокола вида Alice-Bob в язык спецификации используемого верификатора. Для выполнения данной задачи необходим парсер описания представления протокола вида Alice-Bob, который позволит получить отдельные части протокола из этого описания. Как пример рассмотрим предлагаемый авторами подход к трансляции в абстрактный язык спецификации.
1. В начале обработки создаются упорядоченные множества, в которых будут содержаться: имена ролей, публичные ключи, симметричные ключи, случайные числа, элементы сообщений, смысловые данные, цели секретности, цели аутентификации и знания злоумышленника. Каждая строка, представляющая собой сообщение, считывается и разбивается на составные части по разделителям. Приведем пример разделенного списка данных для первого сообщения:
1. A -> B: AE_Pka(Na, A)
Список элементов приведен в табл. 1.
Таблица 1
Список частей сообщения 1
Индекс Значение
[0]
[1] "A"
[2]
[3] "B"
[4] "AE_Pka"
[5] "Na"
[6] "A"
2. Содержимым сообщения являются все элементы с индексом 4 и более включительно. Из индексов 1 и 3 из всех сообщений берутся названия ролей и добавляются только уникальные в множество имен ролей. В множество элементов сообщений добавляются все данные после 4 и более индекса, которые не содержат в себе имен криптографических функций с ключами, в нашем случае это "AE_" и
Однако если ключ встретится в содержании сообщения, то он будет являться элементом сообщения. Идентификаторы ролей не являются элементами сообщений и из итогового множества удаляются. Множество цели секретности заполняется всеми элементами сообщений с припиской между какими сторонами данные должны быть секретны.
3. Далее идет заполнение множеств публичных и симметричных ключей. Это осуществляется путем поиска названий криптографических функций. Для нашего протокола только "AE_" и "^Е_". В итоге для первого сообщения эта часть сообщения с индексом 4. Теперь необходимо извлечь ключ путем разделения элемента 4 по разделителю на две части. В первой части будет вид шифрования - асимметричный, во второй части будет публичный ключ "Р а".
4. Далее необходимо выявить цели аутентификации. Чаще всего для аутентификации используется принцип запрос-ответ, в котором сторона посылает случайное число другой стороне, после чего получает в ответ это же число либо какую-нибудь известную обеим сторонам функцию от этого числа. Таким образом,
находятся моменты, в которых роль 1 отправила элемент сообщения другой роли 2, после чего в каком-либо последующем сообщении роль 2 отправила в ответ этот элемент либо функцию от него роли 1. Такие моменты будут свидетельствовать о том, что присутствует аутентификация сторон по принципу запрос-ответ. Причем в множество целей аутентификации помимо самого случайного числа записывается, и кто кому его отправил в первый раз. Если инициатор взаимодействия роль 1, то в множество запишется информация о том, что роль 1 аутентифицирует роль 2 по указанному случайному числу. Помимо этого, элементы сообщения, участвующие в этом обмене, будут считаться случайными числами. Все остальные, не являющиеся случайными числами, а также передаваемыми в теле ключами, использующимися в дальнейшем для шифрования сообщения, будут считаться смысловыми данными. В нашем случае смысловыми данными будет считаться элемент "M1".
5. Далее начинается построение непосредственно спецификации CAS+ согласно необходимым полям: роли, секция передачи сообщений, знаний сторон, злоумышленника, сессии и цели верификации.
Транслятор был реализован на языке программирования C# как консольное приложение, у которого задаются два параметра: исходный файл с описанием Alice-Bob и файл для сохранения описания на языке спецификаций CAS+.
protocol VotingFull; identifiers AS,V,VS,BB : user;
Nv,Id,Fake1,Fake2,Fake3,Ind1,Ind2,Ind3,Ind4,UserData, MessLength1,MessLength2,
MessLength3,MessLength4,MessLength5, 5 MessLength6,MessLength7 : number;
Kasvs,Kvas,Kvvs,Kvsbb: symmetric key;
6
7
8
9
10 1. 11 2.
12 3.
13 4.
14 5.
15 6.
16 7.
17 8.
18 9.
19 10
Kpvs, Kpbb
messages VS -> V VS -> V
V -> AS
V -> AS AS -> VS AS -> VS VS -> V: VS -> V:
V -> VS V ->
public key;
{MessLength1}Kvvs {Nv}Kvvs {MessLength2}Kvas {UserData, {Nv}Kvvs}Kvas {MessLength3}Kasvs {{Nv}Kvvs}Kasvs {MessLength4}Kvvs {Nv, Id, {Id}Kpvs'}Kvvs {MessLength5}Kvvs VS: {Nv, {Fake1}Kpbb, Ind1,
{Fake2}Kpbb,
Ind2, {Id}Kpbb, Ind3, {Fake3}Kpbb, Ind4}Kvvs
20 11. 21 12 . {Id}Kpbb, 22 13. 2314. VS
{{Fake2}Kpbb}Kpvs {{Fake3}Kpbb}Kpvs
24
25 knowledge
VS -> BB: {MessLength6}Kvsbb VS -> BB: {{Fake1}Kpbb, Ind1, Ind3, {Fake3}Kpbb, Ind4}Kvsbb VS -> V: {MessLength7}Kvvs
{Fake2}Kpbb, Ind2,
->
}Kvvs
V:
{Nv,{{Fake1}Kpbb}Kpvs', {{Id}Kpbb}Kpvs',
2 6AS : AS,V,VS,BB,Kasvs,Kvas;
27V : AS,V,VS,BB,Kvas,Kvvs;
28VS : AS,V,VS,BB,Kasvs,Kvvs,Kvsbb,Kpvs;
2 9BB: AS,V,VS,BB,Kvsbb;
30
31 session instances
32
[AS:asrole,V:vrole,VS:vsrole,BB:bbrole,Kasvs:asvs,Kvas:vas, Kvvs:vvs,Kvsbb:vsbb,Kpvs:pvs]
33
[AS:asrole,V:vrole,VS:vsrole,BB:bbrole,Kasvs:asvs,Kvas:vas, Kvvs:vvs,Kvsbb:vsbb,Kpvs:pvs];
34
35 intruder knowledge
36 asrole,vrole,vsrole,bbrole;
37
38 goal
39 VS authenticates V on Nv;
40 secrecy_of MessLength1 [VS,V];
41 secrecy_of Nv [VS,V];
42 secrecy of MessLength2 [AS,V];
43 secrecy of UserData [AS,V];
44 secrecy_of MessLength3 [AS,VS];
45 secrecy_of MessLength4 [V,VS];
46 secrecy_of Id [V,VS];
47 secrecy_of MessLength5 [V,VS];
48 secrecy_of Fake1 [V,BB];
49 secrecy_of Fake2 [V,BB];
50 secrecy_of Id [V,BB];
51 secrecy of Fake3 [V,BB];
52 secrecy of Ind1 [VS,V];
53 secrecy of Ind2 [VS,V];
54 secrecy_of Ind3 [VS,V];
55 secrecy_of Ind4 [VS,V];
56 secrecy of MessLength6 [BB,VS];
Верификация. Для верификации безопасности криптографического протокола был использован инструмент Avis a [1]. С помощью него можно произвести формальную верификацию криптографического протокола, увидеть ход атаки и схемы взаимодействия сторон. Для верификации была проведена трансляция из языка Alice-Bob в язык спецификации CAS+ для возможности верификации данного криптографического протокола с помощью верификатора Avis a. Был использован разработанный авторами транслятор.
Avis a работает с языком HLPSL и имеет собственный транслятор из языка CAS+ в HLPSL. Таким образом, после трансляции была проведена верификация в режиме OFMC [20]. Как видно из рис. 5 была найдена атака на аутентификацию сторон. Стоит отметить, что в работе авторов [4] производилась верификация безопасности чуть более ранней версии протокола данной системы и было выявлено, что он безопасен. Однако, из-за реализации на практие протокол был модифицирован, что привело к появлению атаки. Атака стала возможной поскольку перед каждым сообщением протокола посылается предварительное сообщение, содержащее размер будущего сообщения. Для исправления этой ситуации необходимо пересмотреть логику реализации протокола на практике. Как уже описыва-
лось ранее каждое сообщение прогоняется через функцию отправки, которая изначально отправляет информацию о длине сообщения, а затем само сообщение. Стоит отметить, что в контексте именно текущего протокола электронного голосования, для получающей стороны сообщения с неизвестной заранее длиной являются сообщения 10, 12, 14 из-за динамического количества кандидатов.
Рис. 5. Атака на аутентификацию
Как уже описывалось ранее каждое сообщение прогоняется через функцию отправки, которая изначально отправляет информацию о длине сообщения, а затем само сообщение. Стоит отметить, что в контексте именно текущего протокола электронного голосования, для получающей стороны сообщения с неизвестной заранее длиной являются сообщения 10, 12, 14 из-за динамического количества кандидатов. Таким образом, достаточным является добавление сообщений о длине только перед данными сообщениями. Кроме того, в работе [17] протокол был сокращен для демонстрации принципа множественного бросания бюллетеней. В результате некоторые аутентификационные числа были убраны что привело так же к атаке на аутентификацию. Поэтому необходимо добавить схему аутентификации запрос-ответ. В результате протокол изменится следующим образом: VS >У: Еууг^Мег^епдП^)
1. VS->V:
2. AS->V: Evas(Na)
VS >У: Evas(MessLength2)
3. V->AS: Evas(Na, АиШай, Evvs(N, Nvs)) VS >V: Easvs(MessLength3)
4. AS->VS: Easvs(Evvs(N, Nvs)) VS >V: ЕуугХМег^епдП!!)
5. VS->V: Егге^, ID, Sign(ID))
6. 7.
9.
10. 11.
VS->V: Evvs(MessLength5)
V->VS: Evvs(N, Epk(ID1), Ind1, Epk(ID2), Ind2, Epk(ID3), Ind3, Epk(ID4), Ind4)
VS->V: Evsbb(MessLength6)
VS->BB: Evsbb(N, Epk(IDl), Indl, Epk(ID2), Ind2, Epk(ID3), Ind3,
Epk(ID4), Ind4)
VS->V: Evvs(MessLength7)
VS->V: Evvs(N, Sign(Epk(ID1)), Sign(Epk(ID2)), Sign(Epk(ID3)), Sign(Epk(ID4)))
Данный протокол был так же описан на языке спецификации CAS+ и верифицирован с помощью Avis a. На рис. 6 представлены результаты верификации. В данном случае протокол оказался безопасным.
Рис. 6. Результаты верификации исправленной версии протокола голосования
Заключение. В работе была рассмотрена система электронного голосования на основе принципа множественного бросания бюллетеней. Описан парсер для извлечения структуры криптографического протокола, с помощью которого была получена структура протокола голосования. Произведена трансляция криптографического протокола электронного голосования в язык спецификации CAS+ для автоматизированного верификатора Avis a для верификации безопасности протокола. В результате верификации было выяснено, что реализация протокола была подвержена атаке на аутентификацию. Предложена и описана исправленная версия криптографического протокола электронного голосования. Проведена верификация исправленной версии протокола, которая подтвердила безопасность предложенного протокола голосования.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Vigano L. Automated security protocol analysis with the AVISPA tool // Electronic Notes in Theoretical Computer Science. - 2006. - Vol. 155. - P. 61-86.
2. Cremers C.J.F. The scyther tool: Verification, falsification, and analysis of security protocols // International Conference on Computer Aided Verification. - Springer, Berlin, Heidelberg, 2008. - P. 414-418.
3. KüstersR., Truderung T. Using ProVerif to analyze protocols with Diffie-Hellman exponentiation // Computer Security Foundations Symposium, 2009. CSF'09. 22nd IEEE. - IEEE, 2009. - P. 157-171.
4. Babenko L., & Pisarev I. Cryptographic Protocol Security Verification of the Electronic Voting System Based on Blinded Intermediaries // In International Conference on Intelligent Information Technologies for Industry. -Springer, Cham, 2018, September. - P. 49-57.
5. Chaki S., Datta A. ASPIER: An automated framework for verifying security protocol implementations // Computer Security Foundations Symposium, 2009. CSF'09. 22nd IEEE. - IEEE, 2009. - P. 172-185.
6. Goubault-Larrecq J., Parvenues F. Cryptographic protocol analysis on real C code // International Workshop on Verification, Model Checking, and Abstract Interpretation. - Springer, Berlin, Heidelberg, 2005. - P. 363-379.
7. Goubault-Larrecq J., Parvenues F. Cryptographic protocol analysis on real C code. - Technical re ort, Laboratoire S écification et Vérification, Re ort LSV-09-18, 2009.
8. Jürjens J. Using interface specifications for verifying crypto-protocol implementations // Workshop on foundations of interface technologies (FIT). - 2008.
9. Jürjens J. Automated security verification for crypto protocol implementations: Verifying the jessie project // Electronic Notes in Theoretical Computer Science. - 2009. - Vol. 250, No. 1.
- P. 123-136.
10. O'Shea N. Using Elyjah to analyse Java implementations of cryptographic protocols // Joint Workshop on Foundations of Computer Security, Automated Reasoning for Security Protocol Analysis and Issues in the Theory of Security (FCS-ARSPA-WITS-2008). - 2008.
11. Backes M., Maffei M., Unruh D. Computationally sound verification of source code // Proceedings of the 17th ACM conference on Computer and communications security. - ACM, 2010.
- P. 387-398.
12. Bhargavan K. et al. Cryptographically verified implementations for TLS // Proceedings of the 15th ACM conference on Computer and communications security. - ACM, 2008. - P. 459-468.
13. Bhargavan K., Fournet C., Gordon A.D. Verified reference implementations of WS-Security protocols // International Workshop on Web Services and Formal Methods. - Springer, Berlin, Heidelberg, 2006. - P. 88-106.
14. Bhargavan K. et al. Verified interoperable implementations of security protocols //ACM Transactions on Programming Languages and Systems (TOPLAS). - 2008. - Vol. 31, No. 1. - P. 5.
15. Bhargavan K. et al. Verified implementations of the information card federated identity-management protocol // Proceedings of the 2008 ACM symposium on Information, computer and communications security. - ACM, 2008. - P. 123-135.
16. Bhargavan K. et al. Cryptographically verified implementations for TLS // Proceedings of the 15th ACM conference on Computer and communications security. - ACM, 2008. - P. 459-468.
17. Бабенко Л.К., Писарев И.А. Электронное голосование с применением множественного бросания бюллетеней // Известия ЮФУ. Технические науки. - 2018. - № 5 (199). - С. 48-56.
18. Babenko L.K., & Pisarev I.A. An algorithm for analysis of C# code initial for extracting the structure of cryptographic protocols1 // Cybersecurity. - 2018. - Issues 4, 28.
19. CapekP., Kral E., SenkerikR. Towards an empirical analysis of. NET framework and C# language features' adoption // Computational Science and Computational Intelligence (CSCI), 2015 International Conference on. - IEEE, 2015. - P. 865-866.
20. Basin D., MOdersheim S., and Vigan^o L. OFMC: A Symbolic Model-Checker for Security Protocols, International Journal of Information Security, 2004.
REFERENCES
1. Vigano L. Automated security protocol analysis with the AVISPA tool, Electronic Notes in Theoretical Computer Science, 2006, Vol. 155, pp. 61-86.
2. Cremers C.J.F. The scyther tool: Verification, falsification, and analysis of security protocols, International Conference on Computer Aided Verification. Springer, Berlin, Heidelberg, 2008, pp. 414-418.
3. KüstersR., Truderung T. Using ProVerif to analyze protocols with Diffie-Hellman exponentiation, Computer Security Foundations Symposium, 2009. CSF'09. 22nd IEEE. IEEE, 2009, pp. 157-171.
4. Babenko L., & Pisarev I. Cryptographic Protocol Security Verification of the Electronic Voting System Based on Blinded Intermediaries, In International Conference on Intelligent Information Technologies for Industry. Springer, Cham, 2018, September, pp. 49-57.
5. Chaki S., Datta A. ASPIER: An automated framework for verifying security protocol implementations, Computer Security Foundations Symposium, 2009. CSF'09. 22nd IEEE. IEEE, 2009, pp. 172-185.
6. Goubault-Larrecq J., Parrennes F. Cryptographic protocol analysis on real C code, International Workshop on Verification, Model Checking, and Abstract Interpretation. Springer, Berlin, Heidelberg, 2005, pp. 363-379.
7. Goubault-Larrecq J., Parrennes F. Cryptographic protocol analysis on real C code. Technical re ort, Laboratoire S écification et Vérification, Re ort LSV-09-18, 2009.
8. Jürjens J. Using interface specifications for verifying crypto-protocol implementations, Workshop on foundations of interface technologies (FIT), 2008.
9. Jürjens J. Automated security verification for crypto protocol implementations: Verifying the jessie project, Electronic Notes in Theoretical Computer Science, 2009, Vol. 250, No. 1, pp. 123-136.
10. O'Shea N. Using Elyjah to analyse Java implementations of cryptographic protocols, Joint Workshop on Foundations of Computer Security, Automated Reasoning for Security Protocol Analysis and Issues in the Theory of Security (FCS-ARSPA-WITS-2008), 2008.
11. Backes M., Maffei M., Unruh D. Computationally sound verification of source code, Proceedings of the 17th ACM conference on Computer and communications security. ACM, 2010, pp. 387-398.
12. Bhargavan K. et al. Cryptographically verified implementations for TLS, Proceedings of the 15th ACM conference on Computer and communications security. ACM, 2008, pp. 459-468.
13. Bhargavan K., Fournet C., Gordon A.D. Verified reference implementations of WS-Security protocols, International Workshop on Web Services and Formal Methods. Springer, Berlin, Heidelberg, 2006, pp. 88-106.
14. Bhargavan K. et al. Verified interoperable implementations of security protocols, ACM Transactions on Programming Languages and Systems (TOPLAS), 2008, Vol. 31, No. 1, pp. 5.
15. Bhargavan K. et al. Verified implementations of the information card federated identity-management protocol, Proceedings of the 2008 ACM symposium on Information, computer and communications security. ACM, 2008, pp. 123-135.
16. Bhargavan K. et al. Cryptographically verified implementations for TLS, Proceedings of the 15th ACM conference on Computer and communications security. ACM, 2008, pp. 459-468.
17. Babenko L.K., Pisarev I.A. Elektronnoe golosovanie s primeneniem mnozhestvennogo brosaniya byulleteney [Electronic voting with the use of multiple casting ballots] Izvestiya YuFU. Tekhnicheskie nauki [Izvestiya SFedU. Engineering Sciences], 2018, No. 5 (199), pp. 48-56.
18. Babenko L.K., & Pisarev I.A. An algorithm for analysis of C# code initial for extracting the structure of cryptographic protocols1, Cybersecurity, 2018, Issues 4, 28.
19. CapekP., Kral E., SenkerikR. Towards an empirical analysis of. NET framework and C# language features' adoption, Computational Science and Computational Intelligence (CSCI), 2015 International Conference on. IEEE, 2015, pp. 865-866.
20. Basin D., MOdersheim S., and Vigan^o L. OFMC: A Symbolic Model-Checker for Security Protocols, International Journal of Information Security, 2004.
Статью рекомендовал к опубликованию д.т.н., профессор Я.Е. Ромм.
Бабенко Людмила Климентьевна - Южный федеральный университет; e-mail: lkbabenko@sfedu.ru; 347928, г. Таганрог, ул. Чехова, 2, корпус "И"; тел.: 88634312018; кафедра безопасности информационных технологий; профессор.
Писарев Илья Александрович - e-mail: ilua. isar@gmail.com; г. Таганрог, ул. Котлострои-тельная, 7, кв. 35; тел.: 89885350837; кафедра безопасности информационных технологий; аспирант.
Babenko Lyudmila Klimentevna - Southern Federal University; e-mail: blk@fib.tsure.ru; Block "I", 2, Chehov street, Taganrog, 347928, Russia; hone: +78634312018; the de artment of security of information technologies; professor.
Pisarev Ilya Aleksandrovich - e-mail: ilua.pisar@gmail.com; 7, Kotlostroitelnaia street, Apt. 35, Taganrog, Russia; phone: +79885350837; the department of information technology security; postgraduate.
