Русский
Русский
English
Статистика
Реклама

Электронное голосование

Медуза, паспорта и говнокод почему номера паспортов всех участников интернет-голосования попали в Интернет

10.07.2020 22:15:48 | Автор: admin
После завершения интернет-голосования, которое закончилось удивительно хорошо, меня и многих людей долго не покидало чувство того, что в России просто не может что-то пройти так хорошо. Сейчас можно расслабиться реальность не подкачала и мы увидели двойное безумие: как с точки зрения архитектуры решения, так с точки зрения криптографии.
Кстати, Минкомсвязь до сих пор исключает ЛЮБУЮ возможность утечки паспортных данных избирателей

Между тем распределение серий паспортов выглядит вот так:
image

Давайте воспроизведем события и попробуем понять как всего этого можно было избежать


Что произошло?


9 июля появляется материал Медузы Власти фактически выложили в открытый доступ персональные данные всех интернет-избирателей где они рассказали про архив degvoter.zip.

Как найти архив degvoter.zip?


Я нашел так. Внимательный поиск через Yandex привел меня к странице:
vudu7.vuduwiki.duckdns.org/mk.ru/https_check.ege.edu.ru.html

Там был найден текст Https checkvoter.gosuslugi.ru degvoter.zip. Датировка на тот момент была 7.7.2020 (до публикации Медузы!), сейчас этот текст уже переехал на начало страницы и датировка изменилась.
Сам архив был убран с сайта госуслуги, но его копия сохранилась в web.archive.org, откуда его скачали все заинтересованные в исследовании лица в том числе и я. Чтобы понять почему так произошло рекомендую обратиться к первоисточнику файлу robots.txt на сайте ГосУслуги.

Что внутри degvoter.exe?


Сама программа degvoter написана на C# и представляет из себя написанное на коленке WinForms приложение, которое работает с sqlite базой данных. Файлы в архиве датированы 2020-06-30 22:17 (30 июня 2020 года). Видно, что приложение писалось в кратчайшие сроки, ибо на Камчатке в этот момент уже было 1 июля 7:17, а тот факт, что участки открывались в там в 8:00 говорит о том, что дедлайн был как никогда близок (хорошо что электронно голосовали только Москва и Нижний Новгород).

Код проверки паспорта:
image

Приложение как с архитектурной точки зрения, так и с криптографической адовейший говнокод. И вот почему:

Описание просчетов архитектуры и принципа атаки на восстановление индентификаторов паспортов


В комплекте с программой находилась локальная БД в которой находилась таблица passports с двумя полями num и used. Где num было SHA256(<серия>+<номер>).
Очень часто, когда программист без соответствующего опыта подходит к вопросам криптографии, он делает кучу однотипных ошибок. С одной из таких ошибок относится применение хэш-фукнции без какой либо обвески. Идентификатор паспорта состоит из 4-ех циферной серии и 6-циферного номера [xxxx xxxxxx]. Т.е. у нас 10^10 вариантов. Номер телефона, к слову, состоит также из 10 цифр [+7(xxx)xxx-xx-xx]. В масштабах современного цифрового мира это не такие большие цифры. Так один Гбайт это больше 10^9 байт, т.е. 100Гбайт хватит чтобы записать все варианты. Вполне вероятно что их банально можно перебрать. Я измерил что в однопоточном режиме современный Intel Core i5 процессор перебирает все sha256 хеши для одной серии паспорта за 5 секунд (000000-999999). И это на стандартной реализации sha256 без каких либо дополнительных ухищрений. Т.е. полный перебор всего пространства на обычном компьютере займет меньше дня. Если же учесть, что перебор можно вести в несколько потоков, то средненький процессор справится с такой задачей за несколько часов. Это является демонстрацией факта непонимания разработчиком системы принципов использования хеш-функций. Но даже правильное применение хэш-функций при такой архитектуре не спасает паспортные данные от раскрытия, если противник имеет неограниченные ресурсы. Ведь человек получивший доступ к БД может за конечное время получить идентификаторы паспортов, т.к. проверка одного паспорта должна проходить конечное время. Весь вопрос только в ресурсах (хотя если бы здесь просто применили хэширование в пару миллионов раундов, даже такое спорное архитектурное решение, как распространение БД вместе с приложением, не привело бы к такому громкому эффекту, т.к. позволило бы защититься хотя бы от журналистов). Медуза всего лишь продемонстрировала некомпетентность людей, проектировавших эту часть системы.

Давайте попробуем придумать, как сделать с одной стороны сильно лучше, с другой стороны уложиться также в одну ночь разработки.

Архитектура на коленке


Предположим, что у нас вообще нет времени и надо написать решение в течении ночи.
Очевидным требованием является то, что БД с хешами паспортов должна находиться на сервере и это обязательно должно быть клиент-серверное приложение. Сразу же возникнет вопрос, а что делать если вдруг на участке сломается Интернет? Для этих целей нужно сделать Android-версию клиентского приложения, которую нужно также дать скачать членам УИК. В местах, где нет ни интернета, ни сотовой связи на этом голосовании люди не голосовали.
Хэш в базе не должен вычисляться непосредственно из идентификатора паспорта. Это делается для того, чтобы хэши в базе нельзя было подобрать, используя существующие таблицы для перебора. Во-первых, нужно использовать стойкую-хеш функцию. Главный вопрос в том, КАК её нужно использовать. Возможных реализаций тут много, но по сути всё сводится к применению алгоритма в котором будут три параметров: тип хеш-функции, количество итераций, а также значение(я) которое нужно использовать для подмешивания к хэшу (оно будет общее для всех хешей). Конечное требование внутри каждой итерации должен быть использована стойка хеш-функция, а скорость вычисления хэша должна быть несколько единиц в секунду. Даже завладев БД с сервера злоумышленнику в этом случае потребовалось бы значительное время на восстановление всех данных.
Каждое из клиентских приложений будет представлять из себя просто поле ввода + Http-клиент, которые отправляет запрос на сервер.
Сервер работает только по HTTPS и только во время голосования и имеет ограничение в 1 RPS в секунду с IP. В качестве ограничителя RPS используем Redis, куда пишем в качестве ключа IP-адрес и TTL в одну секунду. Есть значение запрос с IP не разрешен, нет значения запрос с IP разрешен. Это даст возможность избежать перебора извне.
Написанное таким образом наше, буквально из говна и палок, решение окажется на порядок более защищенным чем текущее degvoter. При этом разница во времени написания невелика и с сам процесс написания кода может быть распараллелен на 3 человек (сервер, win-client,android-client).

Разберем возможные сценарии утечек.
У нас есть следующие точки где можно получить информацию о системе
1. Исходный код серверной части
2. Скомпилированные файлы серверной части
3. Серверная БД
4. Клиентские приложения

Клиентские приложения в этом случае не несут никакой информации, при этом к ним имеет доступ максимальное число людей и именно здесь максимальная вероятность утечек (что и произошло)
Для того чтобы восстановить информацию потребуется получить доступ к информации из точек (1,2) или (1,3). Если есть только база, то без известного метода хеширования восстановить что-то будет невозможно.

Выводы


1. Каждый раз, когда нужно в каком-то виде работать с персональными данными привлекайте архитектора
2. Каждый раз, когда нужно в каком-то виде работать с персональными данными привлекайте разработчика с опытом/образованием в сфере криптографии или информационной безопасности
Эти два простых правила помогут избежать позора, который мы наблюдали на примере с приложением degvoter, (Помните, что обычный разработчик может и не разбираться в нюансах применения хэш-функций)

Утилита для демонстрации возможности восстановления персональных данных DegvoterDecoder находится в репозитории, посвященном анализу данных голосования. По-умолчанию она настроена на 8 потоков. В случае если вы уже скачали архив degvoter.zip и вы программируете на C# вы без труда разберетесь в принципе её работы.
github.com/AlexeiScherbakov/Voting2020
Подробнее..

Обзор криптографического протокола системы дистанционного электронного голосования

15.09.2020 12:21:41 | Автор: admin
В этой статье мы разберем детали реализации криптографического протокола системы дистанционного электронного голосования.

Применение криптографических механизмов и алгоритмов на различных этапах избирательного процесса дает системе дистанционного голосования необходимые свойства. Давайте разберемся подробнее и рассмотрим этапы проведения голосования, описанные в обзорной статье.

Инициализация системы. На этапе инициализации голосования выполняются следующие криптографические операции:

  • Выработка ключевой пары валидатора для выдачи и проверки слепой подписи, как наиболее стойкий и рекомендуемый академическим сообществом для процедуры анонимизации в системах электронного голосования. В настоящий момент системой поддерживается алгоритмы слепой подписи на эллиптических кривых и на базе алгоритма шифрования RSA. В проводимом голосовании использовался алгоритм выдачи и проверки слепой подписи на базе алгоритма шифрования RSA с длиной ключа 4096 бит.
  • Выработка общего открытого ключа шифрования. Для большей безопасности в процессе выработки ключа используется сразу два криптографических алгоритма: протокол DKG Pedersen 91 распределенной выработки ключа и протокол разделения ключа Шамира. Выработка ключа осуществляется как участниками, обладающими техническими средствами, позволяющими контролировать непосредственно ноды сети и сервера подсчета, так и участниками, которые являются хранителями ключей, записанных на внешние носители. Итогом работы двух этих алгоритмов является общий открытый ключ шифрования бюллетеней. Далее мы более подробно рассмотрим процедуру выработки этого ключа.

Предоставление доступа к бюллетеню. На данном этапе работают следующие механизмы:

  • Выработка ключевой пары электронной подписи на устройстве избирателя по ГОСТ Р 34.10-2012
  • Выработка слепой подписи для маскированного открытого ключа избирателя для удостоверения и последующей проверки его права принять участие в голосовании. В настоящий момент механизм базируется на алгоритме шифрования RSA. Подробно механизм анонимизации рассматривается в отдельной статье.

Заполнение и отправка бюллетеня. На данном этапе используется следующий набор криптографических алгоритмов:

  • Шифрование бюллетеня по схеме Эль-Гамаля на эллиптических кривых. Данная схема используется в протоколе, поскольку обладает свойством гомоморфности по сложению, что позволяет получить результаты голосования без расшифрования каждого бюллетеня.
  • Доказательство с нулевым разглашением Disjunctive Chaum-Pedersen range proof используется для доказательства корректности содержимого бюллетеня без его расшифрования. Данный механизм мы разберем подробно в следующей статье.
  • Электронная подпись зашифрованного бюллетеня по ГОСТ Р 34.10-2012.

Подсчет итогов. На этапе подведения итогов выполняется:

  • Гомоморфное сложение зашифрованных бюллетеней.
  • Предварительное частичное расшифрование итогового суммированного бюллетеня частями закрытого ключа участниками, контролирующими отдельные ноды и серверы подсчета с получением шифротекстов от каждого участника;
  • Сборка закрытого ключа в Избирательной комиссии и частичное расшифрование итогового суммированного бюллетеня собранным ключом.
  • Окончательное суммирование шифротекстов и получение итогов подсчета.
  • Выработка и проверка доказательства с нулевым разглашением Chaum-Pedersen proof. Используется для доказательства корректности расшифрования итогового суммированного бюллетеня. Данный механизм мы разберем подробно в следующей статье.

Аудит. На данном этапе могут быть выполнены проверки корректности всех этапов протокола, и в этой статье мы подробнее рассмотрим возможные проверки.

Давайте разберем криптографические механизмы подробнее.

Блокчейн-платформа


Перед тем, как говорить о процедуре выработки ключей, нужно дать вводные о реализации блокчейн-платформы.

Ниже на рисунке приведена упрощенная целевая схема размещения блокчейн-платформы.



Размещение и резервирование узлов блокчейна происходит в географически распределенных ЦОД ПАО Ростелеком. При этом ответственность за атомарный набор компонентов, участвующий в хранении всех данных голосования, может быть возложена на избирательную комиссию или различные институты общественного наблюдения.

Это сделано для того, чтобы предоставить участникам возможность контролировать основные компоненты системы и узлы сети, и при этом не заниматься решением вопросов с информационной безопасностью, разворачиванием и эксплуатацией технических средств, а также обеспечением возможности масштабирования системы.

Список участников может со временем меняться от минимального на этапе запуска системы в промышленную эксплуатацию, до достаточно широкого и полностью децентрализованного по мере развития системы. При этом всегда существует возможность размещения набора компонентов вне ЦОД.

В качестве блокчейн-платформы используется отечественное решение Waves Enterprise. Транзакции и блоки подписываются по ГОСТ Р 34.10-2012.

Выработка ключей шифрования


Общий открытый ключ шифрования бюллетеней вырабатывается с применением двух криптографических алгоритмов: протокол DKG Pedersen 91 распределенной выработки ключа и протокол разделения ключа Шамира. На базе каждого из этих алгоритмов вырабатывается промежуточный открытый ключ. Затем эти два ключа комбинируются в один общий.

Схема сборки ключа приведена ниже на рисунке.



В целом такая схема может показаться избыточной, но именно так мы можем получить максимальную конфиденциальность голосованию до его окончания. Это получается за счет того, что закрытый ключ, вырабатываемый по протоколу DKG, никогда не находится в одном месте в собранном виде и не может быть украден злонамеренно до или после генерации, а его частями владеют независимые стороны, которые взаимодействуют между собой только через блокчейн.

Но если нет возможности собрать кворум независимых участников блокчейн-сети, запускается процедура разделения ключа между независимыми участниками, которые являются хранителями отдельных частей ключа, записываемых на внешние носители (ключ Комиссии)

Процедура выработки общего открытого ключа шифрования начинается накануне голосования с процедуры выработки открытого ключа Комиссии. В определенный момент времени перед началом голосования в присутствии наблюдателей и журналистов на защищенном ноутбуке, не подключенном к локальной сети или сети Интернет, с помощью специальной утилиты производится выработка ключевой пары с последующим разделением приватного ключа на n1 частей и записью их на специальные носители. Избирательная комиссия своим решением определяет носителей частей закрытого ключа. На этапе создания и инициализации голосования открытый ключ комиссии будет записан в блокчейн.

Затем инициализируется создание голосования в блокчейн сети. После создания голосования на серверах подсчета автоматически запускается процедура выработки открытого ключа DKG.

Участниками процедуры распределенной выработки ключей являются n серверов подсчета голосов, о которых мы писали ранее в обзорной статье. Все операции взаимодействия серверов подсчета, как промежуточные, так и конечные фиксируются в блокчейне, а, следовательно, прозрачны и проверяемы. В системе реализована пороговая схема k из n, то есть при расшифровании данных не требуется участие всех n сторон, формировавших открытый ключ DKG, достаточно меньшего числа участников k. Это позволяет расшифровать результаты голосования, даже если n-k серверов подсчета недоступно, либо их закрытые ключи утрачены.

Для формирования открытого ключа используется алгоритм DKG (Distributed Key Generation), описанный в статье A threshold cryptosystem without a trusted party автора Torben Pryds Pedersen, перенесенный на эллиптические кривые. Предполагается, что каждый сервер обладает постоянной (фиксируются регистратором в учетчике) ключевой парой Диффи-Хеллмана, используемой для защищенной передачи данных этому серверу (экспорт/импорт долей ключа).

Параметры протокола


  • Эллиптическая кривая E и генератор P подгруппы этой кривой большого простого порядка q. В текущей реализации используется кривая secp256k1.
  • Другой генератор Q той же подгруппы, для которого значение $x: Q=xP$ неизвестно никому.
  • (k,n), где n общее число участников, сгенерировавших пары ключей, а k минимальное число участников, которое необходимо для восстановления общего секрета, при этом $k(n+1)/2$. То есть, если k-1 участников скомпрометированы или у них украли ключи, то это никак не повлияет на безопасность общего секрета.


В общем виде алгоритм получения точки Q выглядит следующим образом: берется любая последовательность байт, например строка Hello, World!, и от нее считается хэш h = Hash(Hello, World!) после чего преобразуем последовательность байт h в число и считаем $x0=h mod p$, где p модуль кривой, подставляем $x0$ в уравнение кривой: $y^2= x0^3+ a*x0+b mod p$ и пытаемся его решить относительно y. При отсутствии решения мы инкрементируем x0 и снова пытаемся решить уравнение для нового значения x0 и т.д.

Шаг 0.
Каждому из n серверов присваивается уникальный порядковый номер от 1 до n. Это необходимо, поскольку коэффициент Лагранжа зависит от порядкового номера сервера.

Шаг 1 создание открытого ключа DKG.

Каждый j -й сервер, j=1,,n:
1. Генерирует пару закрытый ключ priv_j и открытый ключ $Pub_j=priv_jP.$
2. Делает Pedersen commitment для открытого ключа:
Генерируется случайное число r_j
Вычисляется точка $C_j=r_jQ+Pub_j$
$C_j$ публикуется с помощью учетчика
3. После того как все серверы опубликовали свои значения C_i, публикуется скаляр r_j.

Используя скаляры, каждый может восстановить открытые ключи каждого сервера $Pub_j=C_j-r_jQ$ и вычислить открытый ключ DKG $Pub=_(j=1)^n Pub_j $.
Отрытый ключ DKG записывается в блокчейн.

Шаг 2 генерация полиномов и раздача теней.

Каждый j -й сервер, j=1,,n:

1. Генерирует случайным образом полином степени k-1:
$f_j (x)=f_(j,0)+f_(j,1)x++f_(j,k-1)x^(k-1),$
где коэффициент $f_(j,0)=priv_j$, а остальные случайные элементы поля GF(q).

2. Считает значения полинома $f_j (i),i=1,,n,ij.$

3. Зашифровывает значение $ f_j (i)$ при помощи открытого ключа экспорта/импорта i -го сервер для каждого i и публикует с помощью учетчика результаты шифрования.

Шаг 3 проверка коэффициентов полиномов.

Каждый j -й сервер, j=1,,n:

1. Публикует каждый коэффициент своего полинома, умноженный на генератор P.
$F_(j,0)=f_(j,0)P,F_(j,1)=f_(j,1)P,,F_(j,k-1)=f_(j,k-1)P$
2. Расшифровывает все значения $f_i (j),i=1,..,n,ij$ и проверяет их корректность:
Вычисляет $A=f_i (j)P$
Вычисляет сумму
Если A=B, то результат принимается, иначе публикуется жалоба на сервер i, и протокол запускается с самого начала переход к шагу 0.
3. Если ни у кого нет жалоб, то вычисляет свой секретный ключ



Открытый ключ DKG может быть восстановлен и проверен по данным, которые записывают в блокчейн серверы подсчета на этапе инициации голосования. Необходимо взять точки публичных ключей всех декриптов и произвести их сложение. В результате получится то же значение, что записано в блокчейн как открытый ключ DKG.

Далее на основании открытого ключа комиссии, который загружается в систему, и открытых ключей серверов подсчета вырабатывается общий открытый ключ шифрования по следующей формуле:

MainPubKey = Hash(PubDKG, PubCommission)*PubDKG + Hash(PubCommission,PubDKG)*PubCommission

Все открытые ключи записываются в блокчейн вместе с промежуточными вычислениями для упрощения проверки наблюдателями. Общий открытый ключ шифрования считывается из блокчейна и передается на устройства пользователей при отображении бюллетеня.

Описание схемы шифрования бюллетеней


Ниже приведем описание процедуры шифрования бюллетеней по схеме Эль-Гамаля на эллиптических кривых.

Схема шифрования Эль-Гамаля на эллиптических кривых позволяет реализовать гомоморфное относительно сложения шифрование, при котором в результате операции сложения над зашифрованным текстом получается зашифрованная сумма исходных значений.

Encrypted (A) + Encrypted (B) = Encrypted (A+B).

Чтобы использовать это свойство алгоритма, заполненный бюллетень в электронном виде представляется как строка нулей и единиц. Количество символов соответствует количеству вариантов выбора, при этом выбранный вариант представлен единицей, остальные варианты выбора представлены нулями.

Длина закрытого ключа при использовании алгоритма Эль-Гамаля на эллиптических кривых выбирается равной 256 бит, открытый ключ при этом представляет из себя точку эллиптической кривой. Это соответствует уровню безопасности в 128 бит (для взлома необходима 2^128 операций с точками кривой). Такой уровень считается оптимальным для большинства современных промышленных и финансовых систем, в том числе для российского стандарта ГОСТ 34.10-2018 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи (вариант 256 бит).

В качестве эллиптической кривой используется secp256k1.

Допустим, мы имеем ключевую пару priv, Pub:
Число priv: 0 < priv < q
Точка Pub = priv*Base

Зашифрование:

  • Есть сообщение m, небольшое число, которое мы хотим зашифровать на ключе Pub.
  • Вычисляем точку M = m*Base
  • Генерируем случайное число r: 0 < r < q
  • Вычисляем точку R = r*Base и точку C = M + r*Pub
  • Шифротекст: (R, C)

Расшифрование:

  • Имеется закрытый ключ priv и шифротекст (R, C)
  • Вычисляем точку M = C priv*Base
  • Восстанавливаем m: решаем перебором ECDLP для соотношения M = m*Base

Гомоморфность схемы.

Мы видим, что если зашифровать два сообщения $M1 = m1*Base$ и $M2 = m2*Base$ на ключе Pub:
$(R1, C1) = (r1*Base, M1 + r1*Pub)$
$(R2, C2) = (r2*Base, M2 + r2*Pub)$

То их сумма $(R1 + R2, C1 + C2)$ соответствует зашифрованному сообщению $M1 + M2$.

Таким образом, можно шифровать и складывать покандидатно все бюллетени. К примеру, пусть открытый бюллетень выглядит так:

Иванов Петров Сидоров

0 1 0


Тогда, преобразовав его в точки, получим:

Иванов Петров Сидоров

ZeroPoint Base ZeroPoint

где ZeroPoint это точка на бесконечности.

И, наконец, шифруем бюллетень на ключе Pub:

Иванов Петров Сидоров

$(r1*Base, r1*Pub)$$(r2*Base, Base + r2*Pub)$$(r3*Base, r3*Pub)$

Допустим, что мы провели такое голосование с N избирателями. Если для Иванова, Петрова и Сидорова отдельно сложить шифротексты из разных бюллетеней, то получим суммарный бюллетень, который содержит зашифрованные суммы за каждого из кандидатов. Этот суммарный бюллетень можно расшифровать ключом расшифрования и узнать результаты голосования за каждого из кандидатов.

Ниже на рисунке изображена схема гомоморфного сложения бюллетеней и проверки корректности заполнения на базе доказательств с нулевым разглашением.



Как мы видим из схемы, у потенциального злоумышленника нет возможности вбросить лишние голоса, зашифровав некорректное число, на уровне криптографического протокола. Это реализуется с помощью доказательств с нулевым разглашением, о которых пойдет речь дальше в статье. Помимо этого, необходимые проверки реализованы также в веб-приложении избирателя.

Описание процедуры расшифрования


Подсчет голосов происходит без расшифровки благодаря гомоморфному шифрованию по схеме Эль-Гамаля, что позволяет сохранить конфиденциальность всей процедуры голосования и каждого отдельного голоса. Также, ни один из серверов не имеет возможности самостоятельно и тайно расшифровать итоги голосования.

Для того, чтобы расшифровать шифротекст (R,C) необходимо, чтобы любые k из n серверов вычислили и опубликовали значение $s_jR$ и доказательство корректности расшифрования Chaum-Pedersen (доказательство, что посчитанный $s_jR$ это именно точка R, умноженная на $s_j$, не раскрывая значения $s_j$). Также для этого необходимо собрать закрытый ключ комиссии из не менее чем k1 из т1 частей и с его помощью также выполнить вычисление $s_jR$ с публикацией в блокчейн.



Расшифрование происходит в несколько этапов, результаты каждого из которых фиксируются в блокчейне.

Первый этап частичная расшифровка. Каждый K из N серверов системы проводит сложение шифротекстов голосов, получает суммарный бюллетень и выполняет расшифровку на своей части закрытого ключа голосования. Результатом этой операции будет являться шифротекст, комбинирование которого с шифротекстами, полученными в результате таких же операций, выполненных на остальных серверах подсчета, а также же с шифротекстом, полученным на закрытом ключе комиссии, будет давать расшифрованный итоговый результат. Важно отметить если не будет шифротекста, полученного от расшифровки на закрытом ключе комиссии, все остальные шифротексты становятся бесполезными. Получить из них какие-либо итоги невозможно.

Результаты операции публикуется в блокчейн.

Второй этап сборка закрытого ключа комиссии и частичное расшифрование суммарного бюллетеня. Эта операция выполняется на специальном ПК без подключения в сеть Интернет. После того как ключ собран происходит описанная в предыдущем абзаце операция по формированию шифротекста на ключе комиссии. Результаты этой операции также записываются в блокчейн.

Третий этап итоговая расшифровка. Серверы подсчета голосования агрегируют результаты K из N серверов, результат расшифрования на закрытом ключе комиссии, и производят окончательную расшифровку, затем производят публикацию результатов голосования.

Обратите внимание, что наличие шифротекста, сформированного на закрытом ключе комиссии, является обязательным условием. Без него подсчет итогов не состоится.

На основе опубликованных результатов частичной расшифровки любая заинтересованная сторона может повторить процесс и убедиться, что результаты подсчитаны верно.

Доказательства с нулевым разглашением


Хотя система ДЭГ защищена от злоумышленников и ошибок пользователей на уровне программного обеспечения и инфраструктуры, на уровне криптографического протокола были предусмотрены дополнительные математические доказательства и проверки, которые не позволяют передавать в систему ложную информацию. Для этого было разработано несколько механизмов, основанных на неинтерактивных доказательствах с нулевым разглашением (NIZK).

Первый тип ZKP (zero-knowledge proof), применяемых в cистеме доказательства диапазона. Данные ZKP используются при публикации зашифрованного бюллетеня, чтобы в отсутствие информации о том, как проголосовал участник голосования, можно было убедиться, что участник не испортил бюллетень на своем устройстве одним из следующим способов:

  • участник не зашифровал в бюллетене по отдельному варианту голосования значение больше единицы, что повлияло бы на итог голосования при зашифрованном сложении;
  • участник не выбрал более одного варианта по каждому вопросу в бюллетене, если это не предусмотрено порядком заполнения бюллетеня.

Более подробное описание реализации NIZK, а также их проверки, будет рассмотрено в отдельной статье.

Структура записей в блокчейне


Вся информация в блокчейне записывается тремя типами транзакций:

  • CreateContract для создания смарт-контракта под конкретное голосование. Далее в этом смарт-контракте будет агрегироваться вся информация по голосованию. Если одновременно проводится два (и более) голосования, то создается, соответственно, два (и более) экземпляра контракта.
  • CallContract для взаимодействия со смарт-контрактом по различным операциям, перечень которых приведем далее.
  • Data transaction для записи списка избирателей после создания экземпляра смарт-контракта голосования и перед началом непосредственно голосования.

Взаимодействие со смарт-контрактом производится по следующим операциям:

  • Запись базовых данных в смарт-контракт. Здесь сохраняются публичные ключи северов подсчета, которые будут участвовать в криптографическом протоколе, threshold схема, ключи проверки слепой подписи и другие данные, необходимые для организации работы протокола и голосования в целом.
  • dkgScalar, dkgCommit, dkgShadows данные, необходимые для сборки публичного ключа шифрования бюллетеней и реализации пороговой k из n схемы. Подробнее об этом поговорим далее в статье.
  • addMainKey запись набора публичных ключей и общего публичного ключа шифрования бюллетеней.
  • blindSigIssue запись факта выдачи слепой подписи.
  • vote запись непосредственно зашифрованного голоса избирателя.
  • finishVoting команда завершения голосования. После нее новые бюллетени не принимаются.
  • Decryption запись частичного расшифрования результатов голосования. Отправляется каждым сервером подсчета.
  • ComissionDecryption запись частичного расшифрования результатов голосования на закрытом ключе комиссии.
  • Results запись расшифрованных итогов голосования. О расшифровании, подведении итогов и записи результатов подробнее далее в статье.

Транзакция с голосом избирателя включает в себя блокчейн-адрес и открытый ключ голосующего, зашифрованный бюллетень, слепую подпись и электронную подпись, сформированную на анонимном закрытом ключе избирателя (см ранее опубликованную статью по анонимизации).

Ниже на рисунках представлено отображение транзакции с голосом в блокчейн-клиенте.





Вся информация о голосовании агрегируется на смарт-контракте и будет доступна через блокчейн-клиент наблюдателям или в виде csv-файла любому желающему.

Ниже на рисунке представлено отображение агрегированной информации в смарт-контракте.


*Данные с тестового сервера.

Особенности платформы Waves Enterprise позволяют реализовать довольно сложную логику со статусной моделью, проверкой слепых подписей, подсчетом валидных и испорченных бюллетеней.

Проверки криптографического протокола и процесса голосования


Первая базовая проверка, которую можно сделать, используя блокчейн-платформу и блокчейн-клиент, это проверка на соответствие количества избирателей в списке избирателей, а также количества выданных бюллетеней и количества зафиксированных голосов.

Проверка корректности подсчета осуществляется путем повторения наблюдателем работы сервера подсчета по суммированию зашифрованных бюллетеней покандидатно. Это делается путем последовательного сложения точек эллиптической кривой, соответствующих каждому кандидату.

Затем, используя полученный зашифрованный суммарный бюллетень и доказательство корректности расшифрования, которые опубликованы в блокчейне, можно проверить корректность суммирования и частичного расшифрования, выполненного каждым сервером подсчета.

На этом этапе видно, соответствует ли полученная наблюдателем зашифрованная сумма, тому, что записал каждый из серверов подсчета.

После этого можно выполнить проверку корректности расшифрования итогов голосования. Для этого нужно взять шифротексты из транзакций с типом операций Decryption и CommissionDecryption и, по аналогии с бюллетенями, выполнить сложение точек эллиптической кривой для каждого кандидата.

Исходный код, реализующий криптографические операции, доступен в этом репозитории на GitHub.
Подробнее..

Честное онлайн-голосование миф или реальность?

27.05.2021 22:07:59 | Автор: admin

Привет, Хабр! Меня зовут Иван, я разрабатываю сервис онлайн-голосований WE.Vote на основе блокчейн-платформы Waves Enterprise. Сама идея голосований в онлайне уже давным-давно реализована разными компаниями, но в любых кейсах повышенной ответственности все равно прибегают к старой доброй бумаге. Давайте посмотрим, как электронное голосование сможет посостязаться с ней в максимально строгих условиях.

Идея проведения онлайн-голосований не нова. Появляются соответствующие сервисы, но традиционное очное голосование на бумажных бюллетенях все еще является наиболее распространенным способом принятия важных коллективных решений. Например, в национальных выборах с миллионами бюллетеней, тысячами избирательных участков, наблюдателей и волонтеров. Или на собраниях акционеров крупного общества, где даже на стадии уведомления о грядущем собрании нужно разослать вагон заказных писем и убедиться что они были получены. Или на общих собраниях собственников дома, где приходится ловить момент, когда каждый из жильцов не на работе, не в отпуске и не на даче, чтобы с опросным листком обойти все квартиры. Да, бумага это долго и дорого. Но несмотря на все недостатки бумажного голосования, она продолжает активно использоваться частично в силу инерционности регулирующего законодательства, и, наверное, в большей степени из-за веры в надежность традиционных, устоявшихся процедур.

Тем не менее дистанционные решения возникают и отвоевывают себе место под солнцем. Онлайн-голосования набирают популярность и в государственном, и в корпоративном секторе. На стороне онлайна очевидные преимущества в плане эффективности людям, находящимся в разных уголках мира, гораздо проще и дешевле разослать бюллетени в электронном виде, чем собирать их в арендованном конференц-зале. Пандемия добавила нюансов в виде необходимости социального дистанцирования, еще больше подсветив преимущества методов дистанционного принятия решений.

Подавляющее большинство сервисов онлайн-голосований это централизованные решения, управляемые конкретной компанией-оператором. Есть ли здесь угрозы конфиденциальности и манипуляций? С технической точки зрения понятно, что оператор такой системы имеет доступ ко всем ее данным. Соответственно, теоретически у него есть возможность вмешаться в ход голосования или подправить результаты. Но многие решения, используемые бизнесом, опираются на доверие ив этом нет ничего страшного.

Системы выстраиваются не на технической невозможности, а на экономической нецелесообразности вмешиваться в бизнес-процессы клиентов. Может ли банк подправить баланс вашего счета? Может. Станет ли он это делать?Скорее всего, нестанет (но это неточно).Вокруг подобных сервисов выстраивается юридическая инфраструктура в виде договоров между клиентом и оператором сервиса, соглашений о неразглашении, государственное регулирование и т.д.В результате получается вполне рабочая история: бизнес делает свое дело, оператор сервиса онлайн-голосований помогает бизнесу принимать решения. Но, кажется, осадочек остается.

Но что если вам нужно больше?Что если одновременно нужна экономическая эффективность, конфиденциальность принимаемых решений и максимальная теоретическая невозможность для оператора сервиса онлайн-голосований повлиять на их результат? Представьте гипотетическую ситуацию, в которой одна глобальная корпорация Кэппл принимает решения о своей глобальной стратегии развития на инфраструктуре другой глобальной корпорации Тубель.Сколько бы соглашений и договоров нибыло подписано удержится ли Тубель от возможности подсмотреть, о чем там договаривается его прямой или косвенный конкурент? Будет ли менеджмент Кэппла спать спокойно, будучи уверенным, что никто не вмешается в их прорывные планы развития?

Стоит ли, положившись на идеальность нашего мира, отвечать на оба вопроса да? Или мы можем создать техническое решение, отвечающее всем требованиям?Давайте посмотрим.

Чего мы хотим добиться

На самом абстрактном уровне всё, что делают информационные системы, это создают/изменяют данные, передают данные, хранят данные, а также дают доступ к этим данным.В применении к онлайн-голосованиям это выглядит следующим образом:

  1. Организатор голосования создает повестку и хочет управлять правилами доступа к этой повестке: сделать ли ее публичной или раскрыть только участникам голосования.

  2. Организатор голосования создает список его участников и хочет быть уверенным, что в его голосовании примут участие именно они. Сами участники также заинтересованы в этом, так как подразумевается, что они принимают решение по важному для них вопросу и мнение/намерения/выгода третьих лиц не должны на это решение повлиять.

  3. Организатор задает правила проведения голосования. Эти правила без раскрытия сути голосования должны быть доступны широкой публике, чтобы организатор, участники голосования и третьи лица (например, регулятор) могли убедиться, что способ принятия решения был выбран корректно и все прошло по заранее известному плану.

  4. Участник голосования получает повестку голосования и хочет убедиться, что это именно тот список вопросов, который получат все остальные, что ему не прислали укороченную версию. Эти сомнения выглядят нелепо для бумажного голосования, где все бланки заранее распечатаны, все выдаются из общей стопки и нет никакой возможности персонализировать бюллетень. Но в случае онлайн-голосования все, что мы имеем, это байты информации, которые легко изменить на лету. Поэтому хотелось бы иметь больше гарантий аутентичности.

  5. Участник голосования заполняет бюллетень и хочет убедиться, что его голос будет учтен, его голос не будет изменен и никто не сможет определить, как именно он проголосовал (частный случай открытых голосований оставим в стороне).

  6. Организатор и участники голосования узнают его результаты. В этот момент все хотятбыть уверены,что никто не вмешивался в ход голосования, не фильтровал бюллетени, не делал вбросов, не подправлял итоги и т.п.. Все включая и оператора онлайн-сервиса голосований.

При чем тут блокчейн

Если бегло пробежаться по первому разделу, то единственной проблемой онлайн-голосований выглядит всевластие оператора сервиса голосования. Хорошая новость в том, что с появлением блокчейна мы научились ограничивать эту власть, разделяя ответственность за данные системы между ее участниками. Но очевидно, что блокчейн не являетсясеребряной пулей. По сути, это сравнительно медленная и капризная база данных инструмент, имеющий определенные положительные свойства и некоторые недостатки. Чтобы полностью решить задачу, необходимо правильно определить роль блокчейна в системе, понять,чего еще нам недостает.И кажется, у нас получилось сложить кусочки пазла посмотрим как.

Распределенное хранение

С ходу напрашивается решение использовать блокчейн для хранения данных голосования.Так при правильном развертывании сети блокчейн-узловмы сможем не беспокоиться о том, что оператор сервиса единолично подменит записанные данные. Проблема надежного хранения исторической информации решена.

Дополнительно мы можем решить вопрос аутентичности данных: вся информация, которая попадает в блокчейн (в виде транзакций) должна быть подписана отправителем. Публичный ключ участника процесса становится его внутрисистемным идентификатором, а подпись на отправленной транзакции доказывает, что именно он ее отправил.

Естественно, встает вопрос хранения конфиденциальных данных. Блокчейнсам по себене позволяет таких фокусов, поэтому нам надо разобраться,какие данные в системе являются открытыми, а какие приватными. Атакженайти методы защиты конфиденциальных данных. Например, при создании голосования мы имеем следующий набор данных:

  • повестка и материалы голосования;

  • контактные данные пользователей идентификатор пользователей в реальном мире (e-mail или номер телефона);

  • персональные данные пользователей в целом, в системе не требуются, но делают работу удобнее как для организатора голосования, так и для самих участников;

  • пара публичного и приватного ключей участника голосования работают как внутрисистемный идентификатор пользователя и дают возможность участвовать вголосовании.

С повесткой и материалами голосования мы можем работать как любой другой облачный сервис: организатор голосования загружает их на сервер (бэкенд), и их доступность определяется ролевой моделью: участникам голосования мы их показываем, от остальных прячем. Для уверенности в том, что на бэкенде ничего с повесткой не произойдет, сохраним в блокчейне хеш от материалов, хранящихся на сервере. Организатор видит, что в голосовании зафиксировано именно то содержание голосования, которое он планировал, участники голосования при получении повестки также могут убедиться, что повестка эта у всех едина.

Персональные и контактные данные хранятся на сервере в виде учетной записи пользователя.Публиковать их на блокчейне было бы неправильно, и мы этого делать не будем.На блокчейне список участников голосования будет сохранен в виде списка публичных ключей.

Пара ключей создается пользователем локально, на его персональном устройстве. Приватный ключ этого устройства не покидает, а публичный сохраняется набэкендекак параметр учетной записи. Организатор голосования работает со списком участников в виде Ф.И.О. и e-mail. При сохранении данных голосования в блокчейне туда же уходит список публичных ключей. Голос подписан ключом пользователя, и если публичный ключ отправителя есть в списке участников, мы принимаем бюллетень. Такая схема позволяет,с одной стороны,не светить персональными данными пользователей, а с другой сделать более прозрачной работу системы.

Но с заполненными бюллетенями участников голосования простым хешированием не обойтись. Да, хеш бюллетеня на блокчейне спасет его от подмены но нам же надо будет ещё и посчитать результаты голосования. Чтобы работа системы не выглядела как цирковое представление, когда бюллетени и результаты появляются магическим образом из шляпы, попробуем сделать всё прозрачно и сохранить в блокчейн не только сам факт отправки голоса, но и его содержание.Естественно, таким образом, чтобы всё осталось конфиденциально.

Получив бюллетень с сервера и убедившись, что повестка соответствует сохраненному в блокчейне хешу, участник голосования заполняет форму, затем шифрует его общеизвестнымоткрытымключом голосования и, наконец, подписывает своим приватным ключом (в формате блокчейн-транзакции).В результате этих манипуляций мы получаем заполненный бюллетень участника, который нельзя ниизменить (на нем стоит подпись), ни прочитать (он зашифрован).

Такой бюллетеньможно только потерять.Но у нас нет никаких оснований потерять именно этот бюллетень, так как мы не знаем за что голосовал пользователь, да и пропажа бюллетеня очень легко обнаруживается как самим голосующим, так и сторонними наблюдателями. Ведь в блокчейне виден и список зарегистрировавшихся участников голосования, и отправленные ими бюллетени. А распределенная природа блокчейна позволяет участнику голосования напрямую отправить транзакцию в любой из блокчейн-узлов, минуя бэкенд и любых других посредников. Узел блокчейна совершенно не интересуется голосованиями или любыми другими процессами, которые мы пытаемся строить поверх блокчейн-сети. Всё, что интересует сеть, это корректный формат транзакции: если всё верно, то транзакция, а значит и голос, будут зарегистрированы в блокчейне.

Подводя промежуточный итог, можно сказать,что:

  • Мы решили проблему прозрачности и immutable-хранения исторических данных, используя блокчейн.

  • Управление видимостью конфиденциальных данных мы организовали классическим централизованным образом, но внесли дополнительный механизм контроля информации на бэкенде через хеши-якоря, хранящиеся в блокчейне.

  • Работу с информацией об участниках голосования мы разделили. Персональные данные хранятся классическим образом, а взаимодействие происходит с уникальным блокчейн-идентификатором, от имени которого пользователь отправляет свой голос.

Но, несмотря на то что мы обещали обойтись без магии, она все-таки произошла. Для шифрования бюллетеней нам понадобился открытый ключ голосования, но никто не сказал, откуда он взялся! Очевидно, что это предельно важная часть всего процесса голосования и к нему нельзя отнестись легкомысленно. Еще более интересным кусочком пазла является приватный ключ, соответствующий открытому ключу голосования, так как именно с его помощью мы сможем получить итоги голосования.Настал момент шагнуть в область криптографии (которая для 99.9% людей не сильно отличается от магии).

Криптография

Итак, мы добились того, чтобы данные, сохраненные в системе, не могли быть изменены. Но до того, как данные попадут в блокчейн, существует достаточно просторное поле для злоумышленников, где они могли бы повлиять на исход голосования. Например, оговорка в предыдущем разделе о возможности потерять голос. У нас нет мотивации это сделать, если мы не можем прочитать зашифрованный бюллетень. Но что если все-таки можем?

Допустим, мы решили создавать ключ голосования на бэкенде, отправлять открытую часть всем участникам голосования и после завершения голосования использовать закрытую для расшифровывания? Даже на первый взгляд такая реализация выглядитненадежно. Что помешает оператору системы (или злоумышленнику, попавшему на сервер) получить доступ к приватному ключу голосования, на лету расшифровывать бюллетени до их попадания в блокчейн и отфильтровывать неправильно заполненные? Или еще до начала голосования подкинуть свой открытый ключ голосования на сервер? Тогда только у злоумышленника будет соответствующий закрытый ключ и никто кроме него не получит итоги голосования. Что если в ходе голосования злоумышленник получит возможность расшифровывать попавшие в блокчейн бюллетени, получит доступ к промежуточным результатам голосования и каким-либо образом повлияет на итоговый исход?

Несколько болеенадежным вариантом будет техника разделения приватного ключа после генерации хорошо известная схема разделения секрета Шамира. Ключевая пара создается, публичный ключ сохраняется в блокчейне как открытый ключ голосования, а приватный ключ разделяется на несколько частей, которые независимо хранятся доверенными участниками. Чтобы подвести итоги голосования, приватный ключ необходимо собрать и после этого расшифровать бюллетени. Если кто-то из доверенных участников заболел, схема Шамира предполагает возможность сбора приватного ключа меньшим количеством участников. То есть если ключ был разбит на N частей, собрать обратно его можно, используя K частей, где K < N.

Такой вариант выглядит гораздо более надежным и продвинутым, и это действительно так. Но есть нюансы. Во-первых, в промежуток времени между генерацией ключа и его разделением он является очевидной мишенью для злоумышленников и единой точкой отказа системы. Во-вторых, после сбора ключа мы получаем возможность расшифровать каждый индивидуальный бюллетень. Это не позволит нам их отфильтровать, так как они уже находятся в блокчейне и никуда оттуда не денутся. Но это позволит нарушить конфиденциальность голосования. На бэкенде есть связка Ф.И.О. и публичного ключа участника голосования, а в блокчейне связка публичного ключа и теперь уже расшифрованного бюллетеня. Мы знаем, как и кто проголосовал можем взять и, например, лишить премии неугодных.

Конечно, существуют механизмы разрыва первой связки персональных данных и открытого ключа через технику слепой подписи, но это очень своеобразный механизм, который необходимо правильно внедрить. При этом всё равно может сохраниться возможность вычислить по IP голосующего. Он приходит на авторизованный метод получать слепую подпись, а потом стучится на неавторизованный метод отправить голос. Формально во втором случае мы не знаем, кто именно к нам пришел, и опираемся только на проверку слепой подписи. Но у нас есть возможность сопоставить параметры устройства/браузера/соединения и понять, что это тот самый Иванов, который 5 минут назад получал у нас слепую подпись. Или представим похожую атаку на сопоставление по времени получения подписи и отправки голоса. Когда голосующие идут толпой по 500 человек в секунду, такая атака теряет свою эффективность, но при меньшей нагрузке вполне себе работает.

Попробуем сделать лучше?

Распределенная генерация ключа

Попробуем и сделаем. В этом нам поможет протокол конфиденциального вычисления, позволяющий нескольким участникам произвести вычисление, зависящее от тайных входных данных каждого из них, таким образом, чтобы ни один участник не смог получить никакой информации о чужих тайных входных данных. Этот протокол обеспечивает процесс шифрования, в котором несколько сторон участвуют в вычислении общегооткрытогоключа голосования и соответствующего ему набора приватных ключей. При этом приватные ключи исходно создаются независимо, участники протокола конфиденциального вычисления не обмениваются ими - мы избавились от единой точки отказа. При этом мы имеем возможность реализовать пороговую схему K из N, аналогично схеме Шамира.

Для формирования общегооткрытогоключа голосования (MainPubliсKey) используется алгоритм DKG (distributed key generation) из статьи TorbenPrydsPedersenA threshold cryptosystem without a trusted party,перенесенный на эллиптические кривые (в оригинальной статье используется мультипликативная группа конечного поля (поля Галуа)GF(p)). При этом есть ограничение:при любой жалобе (не сходится контрольная сумма) одного из участников на другого необходимо перезапустить процесс генерации с самого начала.

В нашей текущей реализации DKG используются стандартные эллиптические кривые seсp256k1 (Bitcoin, Ethereum) и функция хеширования SHA-256. Можно легко добавить, например, Ed25519 или даже российские кривые ТК-26 и хеш Стрибог, если потребуется. Также можно не завязываться на 256-битных кривых, а использовать 512-битные.

Участниками DKG у нас будут несколько экземпляров криптографических сервисов, выполняющих всю криптографическую магию. Чтобы не возникало вопросов о возможности непрозрачного общения между сервисами, единственным их интерфейсом будет взаимодействие с блокчейн-нодой. Один декрипт одна нода. Принципиально такое соотношение 1 к 1 не требуется, декриптов может быть больше или меньше чем нод, но выглядит логичным иметь одинаковый уровень децентрализации как на слое хранения/транспорта данных (см. раздел выше), так и на слое криптографии.

Протокол созданияоткрытогоключа мы будем запускать для каждого нового голосования, что позволит снизить ущерб для данных системы в случае компрометации одного из ключей.

Протокол DKG Pedersen 91 на эллиптических кривых

Параметры протокола:

  1. Эллиптическая кривая E и генератор (Base) подгруппы этой кривой большого простого порядка q.

  2. Другой генератор (BaseCommit) той же подгруппы, для которого число x из соотношения BaseCommit = x * Base неизвестно никому.

  3. (k, n), гдеnобщее число развернутых криптографических сервисов (DecryptService), сгенерировавших пары ключей, аkминимальное число сервисов, которое необходимо для восстановления общего секрета. k <= (n+1)/2, то есть еслиk - 1участниковнечестные или у них украли ключи, то это никак не повлияет на безопасность общего секрета (MainPubliсKey).

Шаг 0. Индексы DecryptService

Каждому изnDecryptServiceприсваивается уникальный порядковый номер от 1 доn. Это нужно, потому что от порядкового номераDecryptServiceзависит коэффициент Лагранжа, который потребуется для реализации схемы K из N.

Шаг 1. Создание открытого ключа голосования

Каждый изnDecryptServiceгенерирует пару публичного (Pub_n)и приватного (priv_n) ключей для эллиптической кривой: j-йсервер генерирует пару ключей:priv_j,Pub_j,гдеPub_j = priv_j * Base(точка Base генератор простой подгруппы). И делает Pedersen commitment для публичного ключа:

  1. Генерируется случайное число, скалярr_j.

  2. Вычисляется точка, коммитС_j = r * BaseCommit + Pub_j.

  3. С_jпубликуется в блокчейн.

После того как каждый изnDecryptServiceопубликовал свой коммит ПедерсенаС_j, каждый DecryptService публикует свой скалярr_j. На основе опубликованных в блокчейне скаляров любой сторонний наблюдатель может восстановить публичные ключи каждого DecryptService Pub_j =С_j -r * BaseCommit а затем вычислить общий публичный ключ Pub (MainPublicKey) как сумму отдельныхPub_j.

Однако помимооткрытогоключа голосования нам необходимо создать набор приватных ключей ему соответствующих, для расшифровывания итогов голосования. Для этого перейдем на...

Шаг 2. Генерация полиномов и раздача теней

Каждыйj-йDecryptService случайным образом:

  • Генерирует полином степениk - 1:f_j(x) = f_j_0 + f_j_1*x + ... + f_j_k-1* x^(k-1), где коэффициентf_j0 = priv_j, а остальные случайные элементы поляGF(q), гдеq порядок подгруппы точек.

  • Считает значения полинома для каждогоi-гоизnзначений:f_j(i) = f_j_0+ f_j_1*i + ... + f_j_k-1* i^(k-1). Значениеf_j(i)называется тенью (shadow).

  • Шифруетf_j(i)при помощиPub_iдля всех других серверов и публикует результаты шифрования. Таким образом,значениеf_j(i)может узнать только владелецpriv_i, т.е. DecryptService номерi.

Шаг 3. Проверка коэффициентов полиномов

Чтобы убедиться, что каждый из DecryptService следует протоколу DKG, они проверяют значения теней, полученных друг от друга. Каждый DecryptServiceпубликует каждый коэффициент своего полинома, умноженного на генератор Base: j-й сервер:fj,0* Base, fj,1* Base, ... , fj,k-1* Base, где fj,k-1 это коэффициент при степениk - 1.

После этого каждыйi-йDecryptServiceпроверяет все расшифрованные тениf_j(i)(гдеjиз множества от 1 доn, исключаяi), которые для него зашифровали другиеn - 1участников DKG. i-йDecryptServiceдля тени от сервераj:

  1. Вычисляетf_j(i) * Base

  2. Берет экспоненты его коэффициентов:fj,0* Base, fj.1* Base, ... , fj,k-1* Base

  3. Домножает каждый на соответствующую степеньi:fj,0* Base, i * ( fj,1* Base), ... , i^(k-1) * ( fj,k-1* Base)

  4. Складывает их.

Если результат сложения равенf_j(i) * Base(тень отjдляi, умноженная на генератор), то результат принимается. В противном случае публикуется жалоба на серверj: значение тениf_j(i), и протокол запускается с самого начала шага 0.

Если ни у кого нет жалоб, то каждый сервер вычисляет свой секретный ключs_iкак сумму значенийf_j(i)от всехjсерверов, включая себя.

Если взять любые изkучастников, то сложив ихs_i * Lagrange(k, i), где Lagrange(k, i) коэффициент Лагранжа, который зависит от номеров из выбранной группы (k) и номераi, мы получим приватный ключ, соответствующий общему ключу Pub (MainPublicKey), то есть по сути сумму всехpriv_i.

После того как мы выполнили шаг 3, мы можем быть уверены что у нас есть валидныйобщий открытый ключголосования (MainPublicKey), а также набор соотвествующих ему приватных ключей, хранящихся на независимых криптографических сервисах. После этого мы можемопубликовать открытый ключголосования в блокчейне и использовать его для шифрования бюллетеней.

Мы решили проблему угона приватного ключа до начала голосования. Он не был создан централизовано, и чтобы получить доступ к данным голосования, злоумышленнику необходимо взломать K серверов, а не один. Но остается вопрос: как мы будем проводить расшифровывание. Будем ли мы собирать приватный ключ в этот момент и дадим ли шанс злоумышленнику? Пожалуй, не дадим.

Шаг 4. Распределенное дешифрование

Допустим, мы зашифровываем сообщение M на открытом ключе голосования (MainPublicKey):

  1. Генерируем число r и считаем R = r * Base.

  2. ВычисляемС = M + r *MainPublicKey.

  3. Получившийся шифротекст пара точек (R, C) мы публикуем в блокчейне.

  4. Владелец приватного ключаprivвычисляет значение:priv * R.

  5. И расшифровываетM:M = С -priv * R.

Таким образом, для расшифровывания (R, C) нужно вычислитьpriv * R.

Если наш приватный ключ распределен (допустим, что (k, n) = (3,6)), каждый криптографический сервис независимо считает значениеs_i * R, используя свою часть приватного ключа, и публикует результат в блокчейне. Назовем это значение частичной расшифровкой. Дальше остается домножить любые 3 из 6 результатовs_i * Rна соответствующий коэффициент Лагранжа, сложить три точки и получить priv * R. А используя это значение, мы расшифровываем сообщение М.

Таким образом, мы получили возможность расшифровывать результаты голосования, не храня и не собирая приватный ключ в одном месте. Мы проводим распределенное дешифрование, когда каждый из DecryptService вычисляет результат частичной расшифровки, публикует его, и на основании этих данных мы проводим итоговое дешифрование. При этом ни один из DecryptService не имеет возможности выполнить полное дешифрование единолично, а так как всё взаимодействие между криптографическими сервисами происходит в публичной области через блокчейн, мы всегда знаем, сколько раз выполнялись попытки дешифрования результатов.

Гомоморфное шифрование

Теперь у нас есть неплохой наборинструментов:мы защитили исторические данные (блокчейн), мы умеем создавать ключи шифрования и расшифрования без единой точки отказа (DKG), умеем пользоваться этими ключами прозрачным образом, также не имеющим единого слабого звена. Оба инструмента опираются на общую идеологию децентрализации, где мы не вынуждены доверять единому оператору системы, а можем положиться на нескольких независимых участников.

Но пока у нас не решен вопрос, что именно и каким образом мы будем шифровать. А также остается проблема нарушения конфиденциальности голосования, обозначенная выше, в случае расшифровывания индивидуальных бюллетеней.

На помощь нам приходит техника гомоморфного шифрования. Этот метод позволяет проводить арифметические операции над зашифрованными данными без их расшифровывания. То есть в системе, гомоморфной по сложению, мы можем сложить два зашифрованных числа, получить их зашифрованную сумму и расшифровать только результат сложения.

Использовать такую возможность в голосовании мы можем, представив бюллетень в виде матрицы, где каждая строка это отдельный вопрос, по которому принимается решение, а ячейки в пределах строки это варианты ответов на этот вопрос. Заполняя бюллетень, участник голосования выбирает вариант, и мы обозначаем его единицей. Остальные ячейки заполняются нулями. Затем мы шифруем каждую ячейку бюллетеня. Именно в таком зашифрованном виде бюллетень попадает в блокчейн. Что именно зашифровано в каждой ячейке мы не знаем.

Бюллетень в виде матрицы вопросов и вариантов ответовБюллетень в виде матрицы вопросов и вариантов ответов

Но,благодаря гомоморфному шифрованию,мы имеем возможность отдельно по каждому вопросу провести сложение столбиком всех полученных бюллетеней. После чего мы можем расшифровать уже только итоги голосования, без расшифровывания индивидуальных бюллетеней.

Подсчет результатов в зашифрованном видеПодсчет результатов в зашифрованном виде

В итоге мы получаем не только совместную и прозрачную работу нескольких независимых сервисов при вычислении итогов голосования, где ни один из них не может эти результаты подтасовать. Мы также добились очень высокого уровня конфиденциальности голосования. Мы анонимизировали выбор участников голосования через сложение столбиком у нас есть сумма, но нам неизвестны слагаемые!

Чтобы добиться этого, мы используем криптосистему Эль-Гамаля.Исходно эта криптосистема опирается на задачу дискретного логарифма на конечном поле и является гомоморфной к умножению, но она может быть модифицированадля работы на эллиптических кривыхи приведена к гомоморфизму по сложению. В разделе выше показано, как выглядит зашифрованное сообщение:

Зашифрованное сообщение 1: ( R1, С1 ) =( r1 * Base,M1 + r1 *MainPublicKey)

Зашифрованное сообщение 2: ( R2, С2 ) =( r2 * Base,M2 + r2 *MainPublicKey)

Их сумма: ( R1 + R2, C1 + C2 ) = ( ( r1+r2 ) * Base, M1 + M2 + ( r1 + r2 ) *MainPublicKey)

Сумму расшифровываем так же, как отдельные сообщения (помним чтоMainPublicKey= priv * Base):

( M1 + M2 ) = ( C1 + C2 ) priv * ( R1 + R2 ) = M1 + M2 + ( r1 + r2 ) *MainPublicKey priv * ( r1 + r2 ) * Base = M1 + M2

Кто-то скажет магия, кто-то возразит математика.

В результате мы, кажется, сделали все возможное, чтобы защитить участника голосования. Его голос нельзя подделать, его нельзя прочитать, его практически нельзя заблокировать или потерять. Участника голосования нельзя лишить премии за выбор неправильного кандидата.

Более того, мы можем предложить решение для проблемы, характерной для всех систем голосования, где участник отправляет заполненный бюллетень не в защищенном и изолированном пространстве избирательной кабины, а в произвольном месте и в непредсказуемом окружении проблемы принуждения к голосованию. То есть когда на голосующего, в момент отправки голоса оказывается давление выбрать конкретного кандидата. Так как голос, отправленный под давлением, считается технически валидным, система примет его как голос, отправленный от имени публичного ключа пользователя. Но ничего не мешает голосующему отправить свой голос несколько раз. Каждый отправленный бюллетень будет зарегистрирован в системе, но при подсчете итогов мы посчитаем только последний из бюллетеней, отправленных от имени публичного ключа участника голосования.

Доказательства с нулевым разглашением (ZKP Zero Knowledge Proofs)

Однако не только организатор или внешний злоумышленник могут иметь мотивацию повлиять на исход выборов. Нарушитель может затесаться и в ряды участников голосования. Поскольку мы используем очень простую механику сложения столбиком и не заглядываем в индивидуальные бюллетени, у участника голосования есть возможность покопаться в клиентском приложении и сформировать бюллетень, где он вместо "1" проставит за своего кандидата значение 100500. Или 100500 за того, кого недолюбливает. Система посчитает итоги, и кандидат нарушителя победит с внушительным преимуществом.

Чтобыисключитьтакую возможность, мы используем еще одну крипто-магическую технику доказательства с нулевым разглашением. Эта механика позволяет доказать обладание какой-либо информацией без ее раскрытия или доказать, что вы зашифровали корректное значение (например, находящееся в допустимых пределах) не раскрывая самого значения.

Одна из самых наглядных демонстраций работы ZKP (интерактивной разновидности) это Пещера Али-Бабы или Лабиринт:

Участник A обладает ключом, открывающим дверь в лабиринте, и хочет доказать это участнику B, но не хочет показывать ключ. Чтобы В мог убедиться в верности утверждения А, они организуют серию испытаний:

  1. А заходит в лабиринт пока В отвернулся. В не знает, в какую сторону пошел А.

  2. В дает А указание выйти с какой-либо стороны, например, слева.

  3. Если А действительно обладает ключом, он может появиться с любой стороны и выполняет указание В.

Шанс того, что А просто повезло, и он, не имея ключа, изначально пошел налево, составляет 50/50. Поэтому они повторяют испытание еще и еще раз, пока вероятность везения не станет пренебрежимо малой, и В не признает, что А действительно обладает ключом. При этом В не увидит самого ключа, не получит никакой информации, которой обладает А (направление, которое А выбирает в каждом испытании), но в результате серии испытаний он получит достоверное (вероятностное, но с любой необходимой В точностью) доказательство.

Неинтерактивные доказательства с нулевым разглашениемпозволяют упростить взаимодействие между сторонами, и именно их мы будем использовать. Для защиты от нечестного участника голосования мы применим следующую схему доказательств:

ZKP на бюллетене

По каждому вопросу мы, помимо заполненных и зашифрованных ячеек с вариантами выбора, к каждой ячейке приложим NIZK, доказывающее, что в этой ячейке зашифровано одно из значений 0 или 1 но не раскрывающее, какое именно. И дополнительно приложим доказательство, что зашифрованная сумма значений всех ячеек по вопросу равна 1. Это означает, что участник голосования может поставить 1 в любую из ячеек и выбрать только один вариант.

При желании (а оно у нас есть) мы можем на базе этой схемы ZKP реализовать более сложные схемы голосований. Например, взвешенное голосование, где каждый участник отдает не один голос, а количество голосов, пропорциональное своей доле акций компании. Для этого мы должны вместо 1 создать ZKP для значения веса голоса участника. Или вариант голосования с множественным выбором, где каждый голосующий может выбрать не один вариант из N, а несколько. Для этого мы по каждой ячейке добавляем ZKP для ряда значений [0, 1, 2, 3]. Суммарный ZKP может быть на значение [3] тогда голосующий должен распределить все свои голоса. Или на ряд значений[1, 2, 3] то есть он может выбрать от 1 до 3 вариантов, но не может не ответить на вопрос.

В итоге каждый бюллетень будет иметь формат последовательности шифротекстов и соответствующих им доказательств, где каждая пара шифротекст и proof относится к определенному варианту ответа на вопрос. В конец этой последовательности прибавляется доказательство для суммы всех шифротекстов по вопросу.

Структура зашифрованного бюллетеня выглядит следующим образом:

(R_1, C_1), Proof_1,

.........................

(R_M, C_M), Proof_M,

Sum_Proof

Система принимает только те бюллетени, все ZKP которых прошли проверку валидности. То есть наш нарушитель из числа участников голосования может испортить свой бюллетень (так же как в случае с бумажным бланком), но не может воспользоваться тем, что мы не подсматриваем в содержимое его голоса мы имеем возможность убедиться в правильном заполнении бюллетеня без его расшифровки.

ZKP на частичных расшифровках

Хорошо, у нас есть список бюллетеней, подписанных и отправленных валидными участниками голосования, эти бюллетени правильно заполнены, они зашифрованы, и мы не знаем, кто и как проголосовал. Настал момент, когда мы должны получить результаты голосования. Использовав свойство гомоморфности,мы получили зашифрованные результаты суммарный бюллетень. Этот суммарный бюллетень получен независимо каждым из наших криптографическихсервисов,и они должны провести процедуру распределенного расшифрования.

Первое очевидное условие: каждый декрипт должен получить такой же итоговый бюллетень,как и все остальные,иначе магия распределенного расшифрования не сработает. Но это не выглядит большой проблемой, когда у нас есть общий публичный список бюллетеней в блокчейне и именно он является источником данных для всех криптосервисов.

Второе условие: если расшифровывание нескладывается,и мы подозреваем, что некоторые криптографические сервисы решили саботировать голосование, неплохо бы иметь возможность проверить, какой именно из сервисов сбоит. Для этого при публикации частичных расшифровок каждый криптосервис создает и прикладывает ZK-доказательство расшифровки, используя алгоритмZKP Chaum-Pedersen, который доказывает знание числа x для двух соотношений A = x * B и C = x * D (где A B, C, D точки на одной кривой).

Теперь у любого квалифицированного стороннего наблюдателя есть возможность:

  • самостоятельно провести гомоморфное сложение валидных бюллетеней и получить итоговый бюллетень;

  • проверить доказательства расшифровки этого суммарного бюллетеня от каждого криптографического сервиса;

  • самостоятельно провести итоговую расшифровку итогов голосования, используя публичные данные, опубликованные по ходу голосования в блокчейне.

Для удобства последний шаг мы проведем сами и зафиксируем итоги голосования в блокчейне как массива массивов вида [ [ 2,5,6 ], [ 3,5,5 ], [ 7,6 ], [ 10,3 ] ].

Смарт-контракты

Фух, кажется, мы описали протокол голосования, который, используя распределенные технологии и криптографию, позволяет дать честным участникам и организаторам голосований все необходимые гарантии и защищает процесс коллективного принятия решений от внутреннего и внешнего нарушителя. Очевидно, при условии правильной децентрализации распределении узлов системы между независимыми участниками; без этого мы получаем замороченные Google Forms :)

Осталось рассказать еще об одном интересном компоненте системы о смарт-контрактах. В принципе, они не являются обязательным компонентом. Всё, что мы описали выше, может работать через простую регистрацию данных и их внешнюю обработку на бэкенде. Но согласитесь, мы в этом случае будем иметь на блокчейне просто корзину,в которую забрасывают данные все кому не лень а нам с этим хаосом разбираться.В идеалеэта корзина должна быть умной:понимать кто может отправить данные, иметь возможность проверить формат данных или даже провалидировать соответствие данных некоторой бизнес-логике голосования.

Именно такую роль выполняют смарт-контракты в блокчейне. Это умный ящик для голосования, который фиксируетправила голосования,хранит список участников и статусную модель голосования: какой публичный ключ принадлежит участнику, какой криптографическому сервису. Также смарт-контракт регистрирует публичные данные протокола DKG, проверяет и сохраняет отправленные голоса и результаты голосования.

А что дальше?

К сожалению, нельзя все операции системы возложить на смарт-контракт.Во-первых,он может оперировать только открытыми данными никаких приватных ключей и паролей, а именно они участвуют в процессе DKG. Во-вторых, это все-таки распределенные, а значит дорогие и медленные вычисления. Не всю тяжелую математику можно положить в смарт-контракт. Нотак или иначе,это является одним из направлений развития системы оптимизация криптографических библиотек и возможность более полной автоматизации процесса голосования.

Еще одно важное для нас направление развития то, о чем разработчики, увлеченные красивым решением технической проблемы, склонны забывать. А именно UX опыт пользователя :)Прикрутить блокчейн это современно, модно,и в данном случае даже целесообразно, но попробуйте пользователю, который привык к UX современных мобильных и веб-приложений, объяснить, что такое его персональный приватный ключ и что без него он не сможет сделать в системе ровным счетом ничего.Или дать ему одновременно гарантию, что отправленная им транзакция будет принята системой, не заставляя ждать его, пока мы сами в этом убедимся. Нода майнит, прелоадер крутится, пользователь ждет и не понимает чего именно: Ну не знаю, почту я отправляю, все работает мгновенно, а тут чего-то ждать надо?. Поэтому мы активно работаем над тем, чтобы система сохраняла привычные пользовательские свойства, не теряя своих технологических преимуществ.

Также не стоитзабывать о том, чтолюбое техническое решениедолжны закрывать реальные потребности и боли пользователей из реального мира.Протокол блокчейн-голосования в вакуумеможет быть интересен исследователям и разработчикам, но не бизнесу. Бизнес хочет эффективного решения своих задач. Для этого голосование должно не только иметь необходимые технические характеристики, но также соответствоватьустановившимсябизнес-процессам принятия решений, удовлетворять требованиям законодательного регулирования и т.д.

Каждое из этих направлений развития это множество нетривиальных и разноплановых задач, которые совершенно точно не дают нам скучать.Надеюсь, вам было интересно. Буду рад ответить в комментариях на вопросы по статье.

Подробнее..

Электронное голосование по поправкам в Конституцию. Инструмент для визуализации метрик

27.06.2020 14:19:52 | Автор: admin
Электронное голосование уже идет как два дня и вашему вниманию представляется инструмент для визуализации метрик блокчейна голосования.

image



Поскольку в этом году я в составе экспертов по наблюдению за голосованием от Партии Прямой Демократии, то я подготовил небольшую утилиту для просмотра и выгрузки в Excel (в 2019 году у меня некоторые журналисты просили, т.к. они эти графики рисуют самостоятельно в стилистике издания) технических метрик.

В выгрузке минимально измеряемый интервал ограничен 1 секундой, то для блоков идущих подряд при визуализации метрики среднее время блока будут наблюдаться артефакты связанные с округлением по границам 1 секунды это нормально.

И Москва и Нижний Новгород используют физически один и тот же блокчейн. В качестве реализации выбран Exonum.

График показывающий время добавления блока сейчас выглядит так:
image
В 2019 году он выглядел так (тогда использовался блокчейн Parity):
image
На тестовом голосовании в 2020:
image
Нестабильная работа блокчейна была одной из претензий к системе в 2019 году и, учитывая, пик нагрузки уже прошёл (явка уже составляет 70%), похоже что эта проблема была исправлена.

График количества голосов в блоках выглядит так:
image

Инструмент предоставляется для всех желающих, репозиторий с исходным кодом находится тут:
github.com/AlexeiScherbakov/Voting2020
Обсервер для наблюдения и скачивания файлов выгрузок можно найти по ссылке:
cikrf.ru/analog/constitution-voting/participants/distantsionnoe-elektronnoe-golosovanie
На текущий момент это:
observer2020.mos.ru/observer/blocks-list

Другие статьи по теме электронного голосования
1. Алексей Щербаков Анализ данных блокчейн-голосования 2019 года в Московскую Городскую Думу
2. Алексей Щербаков Уроки электронного голосования в Московскую Городскую Думу 2019 года
3. Олег Артамонов Дистанционные электронные голосования: архитектура доверенной электоральной системы
4. Нажми на кнопку: теория и практика электронных голосований круглый стол 30 мая
Подробнее..

Мы наблюдали за голосованием на ТИК ДЭГ и вот что из этого получилось (анонс пресс-конференции)

03.07.2020 18:07:41 | Автор: admin
Привет, Хабр!

Как вы все знаете, на этой неделе прошло по сути первое в России по-настоящему масштабное электронное голосование по поправкам в Конституцию. Прошло оно только в двух регионах, Москве и Нижнем Новгороде, но собрало при этом 1,2 млн. избирателей (в основном в Москве, где электронно проголосовали 15 % от общего числа избирателей).

Формально оно проходило в территориальной избирательной комиссии дистанционного электронного голосования (ТИК ДЭГ), реально, конечно, мы работали удалённо, кроме торжественных мероприятий в начале и конце. Работали мы там сразу в двух качествах: во-первых, официальных наблюдателей на ТИК ДЭГ от Общественной палаты РФ, во-вторых, экспертной рабочей группы. Такое сочетание очень удачно: во-первых, позволяет иногда не только просить, но и требовать, во-вторых, если официальный статус наблюдателя доступен избранным, то в экспертную группу мы могли вводить людей по своему собственному усмотрению.



Сейчас мы готовим большой отчёт о ходе голосования, возникавших вопросах и замечаниях, а также предложениях на будущее, а также ждём от ДИТ Москвы полную выгрузку всех транзакций блокчейна (не только поданных голосов, они уже выгружены) и статистику очередей Rabbit MQ, в которых данные могли находиться, иногда значимое время, до попадания в блокчейн.

Однако полный отчёт это много времени и сил, так что, чтобы сейчас начинать делиться наблюдениями и соображениями, завтра, 4 июля, в 12:00 по Москве мы проводим онлайн пресс-конференцию по итогам голосования.

Подробности ниже, бонусом перечень тезисов, которые мы силами рабочей группы составили в последний день электронного голосования.

Итак, сначала анонс.

Итоги электронного голосования. Пресс-конференция экспертной группы



Суббота, 4 июля, 12:00 по московскому времени

На завершившемся на этой неделе голосовании по поправкам в Конституцию Партия прямой демократии не только выступала в качестве наблюдателей от Общественной палаты РФ в территориальной избирательной комиссии дистанционного электронного голосования (ТИК ДЭГ), но и сформировала экспертную группу по контролю за ходом и результатами голосования.

На пресс-конференции мы расскажем о том, как проходило электронное голосование, с какими проблемами оно столкнулось, можно ли доверять его результатам а также какие шаги необходимо предпринять для дальнейшего развития и применения ДЭГ в России, в том числе на региональных выборах осени 2020 и думских осени 2021 года. О ситуации с ДЭГ расскажут эксперты по электоральным системам, блокчейну, криптографическим системам и информационной безопасности.

Трансляция будет доступна на YouTube-канале Партии прямой демократии.

Вопросы спикерам можно задавать в комментариях к трансляции или через Телеграм-канал партии.

Участники экспертной группы:

  • Олег Артамонов, член ВКС Партии прямой демократии, наблюдатель на ТИК ДЭГ
  • Мона Архипова, независимый эксперт, соучредитель и операционный директор компании Межрегиональный информационно-расчётный центр
  • Александр Исавнин, независимый эксперт, член Пиратской партии России
  • Вячеслав Макаров, генеральный секретарь ВКС Партии прямой демократии, наблюдатель на ТИК ДЭГ
  • Сергей Нестерович, независимый эксперт, заместитель главного редактора Агентства Политических Новостей
  • Александр Подшивалов, независимый эксперт, член Партии прямой демократии
  • Тимофей Шевяков, пресс-секретарь и член ВКС Партии прямой демократии
  • Алексей Щербаков, независимый эксперт, соавтор доклада Романа Юнемана Электронное голосование. Риски и уязвимости


Приглашённые гости:

  • Андрей Ларин, руководитель проекта ДЭГ, ДИТ Москвы
  • Юрий Максимов, д.э.н., к.ф.м.н., профессор МГУ, советник заместителя председателя Государственной Думы РФ, член ЛДПР


Как вы видите, состав подобрался крайне интересный. На пресс-конференции сначала выступим я и Слава Макаров как официальные наблюдатели, а потом дадим слово каждому из присутствующих экспертов и гостей. Темы и содержание их выступлений мы заранее не согласовывали, так что даже для меня они пока загадка (хотя, конечно, примерно я представляю, что Мона вряд ли будет про блокчейн, а Алексей про IDS).

Немного про ход голосования



Мы пока не оформили все материалы и не сопроводили их комментариями, но базовые метрики работы системы можем показать уже сейчас как вы все помните, на голосовании в МГД в 2019 году технические проблемы были настолько вопиющими, что прочие проблемы на их фоне потерялись.

В этот раз всё случилось намного, намного интереснее.

Во-первых, данные по явке и голосам за, по выгрузке из уже расшифрованного блокчейна:



Уже по этому графику видно, что значительных сбоев не было, видна абсолютно нормальная динамика.

Отмечу несколько моментов:
  • это выгрузка из блокчейна, она не учитывает очередей в Rabbit MQ
  • на графике не совсем корректно посчитана явка она не учитывает выданные, но не полученные обратно бюллетени, таких было около 1,7 %
  • было бы очень интересно сопоставить данные по голосам с медиамониторингом: с высокой вероятностью события 25.06 в 17:10, 26.06 в 16:30 и 29:06 в 14:10 обусловлены выходом материалов, подстёгивающих интерес к голосованию, причём первый раз в чисто московском и лоялистском канале, а второй и третий в оппозиционных СМИ
  • отдельно интересно, что пятидневное голосование выгодно противникам поправок скорее всего, потому, что изначально они были настроены в целом скептически, и не торопились голосовать, даже подав заявку на ДЭГ
  • 27.06 в районе полуночи была попытка атаки на блокчейн, которая на час вывела из строя интерфейс наблюдателя и ненадолго перегрузила блокчейн; поэтому виден скачок это поданные голоса после окончания атаки прогрузились из Rabbit MQ в блокчейн


Также положу сюда PDF-файлик с отчётом о работе блокчейна. Это рабочие наброски на основе данных ДИТ Москвы, надеюсь, к середине следующей недели мы представим более подробный и детализированный отчёт, с цифрами и комментариями.

Вывод и тезисы



С предварительными коллективно составленными тезисами экспертной группы можно ознакомиться на Google Docs.

Тезисы составлялись к пресс-брифингу Общественной палаты РФ 30 июня, но актуальности своей не утратили.

Как нетрудно заметить, они далеко выходят за тему технической работоспособности системы и затрагивают организационные, информационные и законодательные моменты. В целом, могу сказать, что в этот раз мы благодарны ДИТ Москвы за стабильную работу системы ДЭГ как минимум, это позволило отвлечься от обсуждения сколько бюллетеней блокчейн пожевал и выплюнул и сфокусироваться на более широком круге задач.

Итого



Очень ждём всех интересующихся завтра на пресс-конференции, где мы дадим слово каждому из экспертов рабочей группы потому что даже внутри рабочей группы, разумеется, нет абсолютного единства мнений, не говоря уже о том, что у разных экспертов разная специализация.

YouTube: https://youtu.be/PAhFGnLDBjI

P.S. Если вы представитель прессы, и хотите поучаствовать непосредственно в Zoom, с возможностью задавать вопросы, пишите мне напрямую в Хабре или в Телеграм olartamonov.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru