Если в прошлом году дистанционное голосование граждан рассматривалось скорее как курьёз или эксперимент, выводы из которого будут сделаны когда-то потом, то в 2020-м мы все внезапно обнаружили, что это — реальность, с которой нам предстоит столкнуться скоро и в полном объёме. В значительной степени к этому подтолкнули карантинные ограничения — проведение выборов оказалось под вопросом, а жизнь политических партий встала на паузу.
В общем, спрос встретился с предложением — и повалили законопроекты. Партиям разрешили проводить праймериз через Госуслуги/ЕСИА, регионы один за другим рапортуют о стремлении организовать ДЭГ (дистанционное электронное голосование) уже в сентябре на местных выборах.
К счастью или к сожалению, одного только законотворчества мало — нужна ещё и техническая реализация, с которой не всё так однозначно. Кто-то верит, что всё уже было сделано в Москве в прошлом году (там даже был блокчейн!), кто-то — что ДЭГ вообще невозможно реализовать на уровне, не допускающем массовых фальсификаций, а потому от ДЭГ необходимо отказаться в принципе.
Поэтому мы решили посвятить разбору этих вопросов небольшой цикл статей и встреч:
- Алексей Щербаков — «Уроки электронного голосования в Московскую Городскую Думу 2019 года»
- Олег Артамонов — «Дистанционные электронные голосования: построение доверенной системы»
- Круглый стол «Нажми на кнопку: теория и практика электронных голосований»
Первую статью начинаем прямо сейчас, а вторую и анонс круглого стола повесим завтра (и добавим сюда ссылки).
Строго говоря, это не статья, а слегка литературно отредактированный текст одноимённого выступления Алексея Щербакова (alexeishch) на нашей конференции 5 марта этого года.
Алексей — приглашенный эксперт команды Романа Юнемана по подготовке доклада «Электронное голосование. Риски и уязвимости», ведущий backend-разработчик компании FoodPlex.
В докладе рассказывается о том, как именно было технически устроено дистанционное электронное голосование на выборах в МГД 2019 года, какие были достоинства и недостатки как в технических решениях, так и в работе с экспертными группами.
Помимо этого текста, можно прочитать также ещё две статьи, уже публиковавшиеся на Хабре:
- Анализ данных блокчейн-голосования 2019 года в Московскую Городскую Думу, также авторства alexeishch
- Параллельный аудит в ходе Электронного голосования авторства Оксаны CryptoTyan
Если вы предпочитаете видео или аудио, полную запись доклада можно посмотреть на YouTube.
***
Здравствуйте, меня зовут Алексей Щербаков, я был экспертом приглашённой команды Романа Юнемана на Московском голосовании. Ну вообще прежде чем рассказывать о самом голосовании, стоит сказать как это вообще происходило.
Всё это началось в марте 2019 года, когда было объявлено об эксперименте, потом уже в мае принят закон о голосовании, а само голосование происходило 8 сентября в трёх округах Москвы. Голосование проходило через интернет в течение 12 часов.
Сама система была построена на базе блокчейна Ethereum фирмы Parity. Там же была использована схема Эль-Гамаля для шифрования. Система логирования использовалась Graylog и для передачи данных между сообщениями использовался какая-то реализация AMQP, мы предполагаем, что скорее всего это был RabbitMQ, просто как корпоративный стандарт. Сама система выглядела вот таким образом:
Большая часть системы находилась вне Департамента информационных технологий (ДИТ) Москвы [это очень важный момент, так как с внешними экспертами общался только ДИТ Москвы — прим. ред.], но блокчейн находился у них. Они работали совместно с порталом Госуслуг. Описание, как эта система создавалась, ДИТ Москвы публиковал на Хабре. И они там же уже говорили в частности о том, что у них проблемы были, в основном, только один час, порядка 400 человек были этим затронуты.
Мы произвели анализ данных на основе выгрузки из блокчейна, которая была представлена Медузой. И отдельно ещё рассматривали свидетельские показания, которые были собраны уже непосредственно наблюдателями на участках. Это был электронный участок, там фотографировались показания на экранах, я подробнее дальше расскажу.
Прежде чем сказать по поводу анализа, который был сделан, расскажу, как мы подходили к задаче. Если бы я сам проектировал эту систему, то я бы использовал определенные стандарты для проектирования системы высокой доступности. В частности, использовались бы метрики для наблюдения непосредственно за здоровьем системы. Для того, чтобы понимать, что начинаются какие-то проблемы — и на них быстро реагировать. И помимо команды, которая должна всё это делать, это должны видеть сами наблюдатели — то есть, наблюдатели должны каким-то образом понимать, что что-то идёт не так. И участковая-избирательная комиссия, которая находилась на этом участке, тоже должна была понимать, что происходило не так, если вдруг что-то идёт не так.
В нашем случае метрика по времени вычисления блоков блокчейна выглядела вот таким вот образом. На ней видно отдельно несколько проблем, первые проблемы связаны с остановкой блокчейна, это первые три зоны. И ещё одна зона — это неизвестная нам проблема, которую мы конкретно на этой метрике не видим. И ещё в конце мы видим плавную деградацию, которая происходила до самого конца голосования.
Если мы рассмотрим вторую метрику — число транзакций на блок — то по ним мы видим проблему уже подробнее. Мы, во-первых, видим, что в зонах отключения, никаких транзакций не записывалось. В нашей подозрительной зоне мы видим крайне мало транзакций, а потом мы видим интересный момент, когда у нас меняется характер записи данных блокчейна. С чем это связано? Изначально, когда данные писались, они писались с определённым интервалом, это сделано для того, чтобы нельзя было по времени голосования точно определить, какой человек голосовал. Данные накапливались и сбрасывались в блокчейн. Однако потом после какой-то реконфигурации блокчейна данные стали записываться уже хаотично. То есть была произведена какая-то операция, но мы не можем точно сказать на основе этой метрики что конкретно ДИТ сделал. Но мы можем сказать, что в данном случае ДИТ каким-то образом вмешался в работу системы.
На основании этих метрик мы можем посчитать время, на которое блокчейн был остановлен. В зонах устойчивой работы время блока было порядка 4 секунд. Соответственно, мы можем посчитать в зонах остановки, сколько уместилось блоков по 4 секунды и сколько оставшееся время блокчейн был остановлен. И на основании этого мы получаем нижнюю оценку для времени остановки, равную 2 часам. Это то время, когда блокчейн полностью не работал.
Помимо этого, у нас ещё есть ещё одна зона, в которой данные не доходили до блокчейна. Суммарно все эти зоны неисправности занимают 4 часа. Зона деградации занимает порядка 6 часов, она началась после обеда и шла до конца голосования. Из-за того, что никак не мониторили блокчейн, они даже не подозревали о том, что были какие-то проблемы. Более того, люди, которые присутствовали на самом участке, часть избирательной комиссии, говорили, что всё, что они могли сделать — это сидеть на диванчике и смотреть, что происходит на экране. То есть они не понимали, что происходит, и узнавали о каких-то проблемах исключительно из СМИ. У них не было вообще никаких инструментов для того, чтобы наблюдать за проблемой.
Помимо этого был интересный момент: у наблюдателей должен был быть доступ к самому блокчейну. То есть, им обещали, что у них будет специальная нода наблюдения и они смогут уже непосредственно обращаться к блокчейну, выполнять на нём операции и смотреть, что происходит. Но эту возможность у них отобрали! Почему? Непонятно. И на экран просто вывели статистику.
Вот так выглядели экраны, там просто четыре позиции: классическая «воронка продаж», когда у нас есть количество людей, которые перешли на страницу голосования, авторизовались, получили бюллетень и проголосовали, и оно с каждым шагом уменьшается.
Здесь есть очень важный момент — время жизни бюллетеня. Если избиратель не успевал за 15 минут заполнить бюллетень, то он считался аннулированным. И сама статистика также шла интервалами по 15 минут. То есть, если у нас избиратель не проходил какой-то участок воронки за 15 минут, то мы можем уверенно сказать, что на следующем этапе статистики он не учитывался. И на каждом этапе у нас получалось меньшее количество. Именно благодаря этому удалось отследить интересные аномалии статистики.
Здесь приведена эта воронка, цветами отмечены времена неисправности блокчейна. Здесь есть интересные аномалии, например, когда красная линия переходит над жёлтой — это количество выданных бюллетеней стало больше, чем количество людей, которые авторизовались, введя код из SMS. Это физически невозможно просто, для того, чтобы получить бюллетень, нужно ввести код. И это произошло в районе двух часов.
Это сравнение статистики, которая получена по данным наблюдателей, и статистики, которая получена из выгрузки из блокчейна. Как видно, они практически совпадают, но есть небольшое отличие, когда, видимо, были небольшие проблемы в статистике на фронтенде. Это нам дает возможность говорить, что статистика, которую получали независимые наблюдатели, и статистика, полученная из блокчейна на основе выгрузки — это практически одно и то же, за исключением этапа, когда у нас были какие-то проблемы.
Помимо статистики, у нас есть интересная аудиозапись — время около 17 часов, проголосовало около 2000 человек, один из представителей ДИТ Москвы рассказывает, какие вмешательства они проводили на работающей системе. В частности он рассказывает, что порядка 900 человек повторно получали SMS для авторизации.
Нам это говорит, во-первых, о том, что благодаря системе логирования, которую они использовали, ДИТ Москвы мог нарушать тайну голосования. Они могли сопоставить время голосования, статус бюллетеня и номер телефона, что очень важно! Они идентифицировали людей, у которых были проблемы, определили их номера телефонов и разослали повторные SMS. Количество этих людей — порядка 40 % от всех проголосовавших на этом участке. Разница между двумя кандидатами, первым и вторым, составила всего 84 человека, в то время как для 900 человек мы даже не можем сказать, какой у них был результат. Потому что над ними производились какие-то действия. Мы не можем сказать, что эти голоса подтасовывали, но мы можем сказать, что у 900 человек были проблемы, мы не можем сказать, за кого они проголосовали и проголосовали ли они вообще. То есть число людей, которые столкнулись с проблемами, в десять раз больше, чем число людей, которые отделяли одного кандидата от победы.
Репозиторий с данными и код, который используется для анализа, можно найти по этой ссылке.
Также мы проивели анализ кода, который использовался для самого голосования. Мы ожидали, что большинство операций будет происходить непосредственно в самом блокчейне и что код должен быть опубликован. Мы получили смарт-контракты, код формы и код, ответственный за отправку сообщения. Но там были части, которые остались неизвестными, потому что они выполнялись на стороне уже другого Департамента — уже портала mos.ru.
Что было интересно найдено в коде? Оказалось, что он не ограничивал возможность одного человека проголосовать в разных округах. Это интересный момент, это было на откуп отдано бэкенду, который находился где-то в другом месте и исходный код которого мы не смогли посмотреть. Непонятно, зачем в системе использовали блокчейн — так как он всё равно не контролировал всё, его можно было заменить на обычную базу данных. Ну и в код формы буквально за день до голосования добавили вот такой волшебный код, который позволял с помощью одной переменной на стороне бэкенда включать дополнительный скрипт в форму, что очень интересно! Зачем они это сделали? По сути, это возможность выполнения произвольного кода в момент голосования на устройстве пользователя.
По криптографии также был интересный момент. Изначально они выбрали 256-бит шифрование, хотя ещё в 1999 году для этой схемы предлагалось использовать 768 бит, а 10 лет назад предлагалось уже 1024 бита. А если сейчас открыть рекомендации Евросоюза, то там будет требование «не менее 1024 бит», если же требуется защита до 2030-го года, то рекомендуется использовать 3072 бита. Есть также интересный момент в том, как они вычисляют энтропию. Понятно, что люди не до конца разобрались, зачем им это всё нужно.
Что я могу сказать об этой системе?
Во-первых, ДИТ Москвы не смог обеспечить хотя бы 90% работоспособности. Вообще считается, что система высокой доступности, она должна иметь не менее 90% времени работы. То есть мы не можем даже сказать, что она была рабочая.
Во-вторых, на продакшн-системе производились операции, которые никто никак не контролировал, никто вообще не мог понять, что происходило. Если посмотреть заседание суда [по обжалованию итогов выборов — прим. ред.], окажется, что ни люди, ни наблюдатели, ни сама комиссия не понимали, что происходит. Всё-таки надо было их как-то подготовить к самой процедуре, которая происходила.
Вместо заключения
Мы не хотим сказать, что электронные выборы — это обязательно бардак, постоянные проблемы, странные технические решения и непонимание, что вообще происходит в данный момент.
Тем не менее, как мы видим по этому материалу, вопрос доверия к результатам голосования по сути своей являлся вопросом доверия к его организаторам — взаимодействие с которыми оказалось весьма неоднозначным. Это, как нам кажется, отвечает и на весьма актуальный вопрос о том, имеет ли ДИТ Москвы достаточно опыта для его масштабирования на всю Москву, а тем более — всю страну, и на вопрос о том, можно ли просто взять какую-нибудь «голосовалку с блокчейном», запустить её на сервере и начать проводить выборы.
О том же, можно ли вообще построить цифровую голосовательную систему, доверие к которой обеспечивается самой её архитектурой, а не честностью её авторов — мы поговорим в следующей статье.
ссылка на оригинал статьи https://habr.com/ru/company/analogbytes/blog/504328/