Нет никого, кто не слышал бы о спорах вокруг электронного голосования. Претензии от оппозиции, выглядят верными, а сопротивление со стороны держателей БД, которое противоречит заявленным принципам, которые должны быть заложены в системе, выглядит как попытка скрыть правду.
Главный редактор эХО Москвы, Венедиктов, который упорно проталкивал ЭГ, и утверждает, что всё честно, и никто его ни в чём, обратном, не убедил.
Вопрос технический и интересный. И поэтому, я изучил Что же не так с ДЭГ в Москве? от Жижина. Зашёл на https://observer.mos.ru/all/ и скачал дампы базы данных, которые лежат там, PostgreSQL server и попробовал разобраться, что именно не так.
Техническая сторона, первое впечатление
Для изучения, я выбрал БД в которой информация о "Выборах депутатов Государственной Думы Федерального Собрания Российской Федерации восьмого созыва по одномандатному избирательному округу.", файл: observer-20210921_143000.sql
Всё очень плохо.
Дело в том, что БД, которая лежит там, не является блокчейном, это сопутствующая БД, которую, как предполагается, можно использовать для простого и быстрого доступа к данным, которые содержит блокчейн. Но, об этом можете забыть навсегда.
Первая и главная претензия всех, кто прикасался к этой БД в том, что нет связи с Зарегистрированным для голосования человеком и всеми последующими действиями с бюллетенями.
Таким образом, избиратели и бюллетени никак не связаны, а лежат в разных кучках. И соответственно вопрос, если есть переголосование, то как понять, какой именно голос был ранее? Ведь его нельзя учитывать.
Как это происходит и почему?
Это происходит потому, что БД на https://observer.mos.ru/all/ создавалась не для работы, а именно для целей наблюдения. И была сделана абы как. Нельзя утверждать, что это было сделано специально, чтобы сделать невозможной проверку голосования. Потому, что если это просто "какая-то" база для наблюдателей, то с ней никто особо возиться не стал, и тем более проверять и тестировать, а потому и сделали криво и косо.
Техническая сторона. Знакомство с БД
таблица "blocks" - здесь эта таблица по существу бесполезна, в ней мог бы быть смысл, если бы предполагалась сверка с живым блокчейном. Но для любых проверок и изучений, от неё нет никакой пользы, поскольку она содержит только ссылки на транзакции, которые лежат в таблице "transactions", а в ней самой, уже содержатся данные о блоке. Единственное, что можно было бы сверить, действительно ли, все транзакции содержащиеся в блоке, есть в таблице транзакций.
таблица "transactions" - главная таблица, где есть всё (что туда положили), а мы, из других материалов изучения этих данных уже знаем, что туда положили далеко не всё. Поле method_id, содержит код назначения этой транзакции, (описание взял у Жижина) важные для нас: 1 - регистрация избирателей, 4 - выдача бюллетеня, 5 - проверка доступа голосующего, 6 - приём бюллетеня (с зашифрованным голосом), 9 - расшифровка голоса
таблица: "decrypted_ballots", содержит хэши транзакций с id 6 и id 9, и результат голосования в расшифрованном виде
Техническая сторона. Изучение данных
таблица "blocks", как оказалось, содержит множество пустых блоков. Создаётся впечатление, что система, зачем-то постоянно создаёт блоки, без особой зависимости от того, есть данные или нет. Как будто они создают некий time lapse, подтверждающий, что всё работает, просто операций нет. Теоретически, в этом нет ничего плохого, но и хорошего тоже нет. На графике, это выглядит это примерно так:
-
таблица "transactions" - главная таблица, где есть всё (что туда положили), а мы, из других материалов изучения этих данных уже знаем, что туда положили далеко не всё.
И тут возникает проблема, транзакции c method_id 1 и 4, содержат "voter_id" в виде "
22443685531066461899103156899237857105006237160299631129744914447305194856993", а транзакции c method_id 5 и 6, содержат связанные поля voter_key и author в виде хеша "78cc1e391507d9ef8bcddfbf72d1cbde95c1f36f84940a5b8be4e8fa0542096a"Таким образом, связать избирателя с его бюллетенем невозможно. Есть вероятность, что voter_key это зашифрованный voter_id, но это не подтверждается, поскольку, если предполагать, что у нас в БД есть переголосования, то будут дубликаты voter_key в списке транзакций 5 и 6 типа.Поиск двойных транзакций, дал результат для method_id = 4, но они не относятся к голосованию, а содержат записи об ошибках, которые произошли в одно и то же время. Всего, в базе есть 34294 избирателя у которого были записи об ошибках, и судя по времени этих ошибок (почти без интервала между ними), они носят чисто технический характер, запись в поле "status" для них выглядит так
"{"type":"service_error","description":"Ballot cannot be issued","code":5,"runtime_id":0,"call_site":{"instance_id":1001,"call_type":"method","method_id":4}}". Бюллетень в результате выдаётся 1.-
Итого, для method_id = 5 и 6, двойных записей нет, при проверке записей, где есть дубликаты voter_id, показали, что таких voter_id, в базе 34294, и всего записей, 78077. Итого, что получается?
method_id = 4 = 1987373 - 78077 + 34294 = 1943590 выдано бюллетеней, что соответствует данным на обсервере.
method_id = 5 = 2021969 записей о подтверждении
method_id = 6 = 2021969 записей о голосовании,
Как такое может быть? Переголосования? но для него тоже выдаётся бюллетень (должен выдаваться, иначе как? О_о).
Итого: 2021969 - 1943590 = 78379 лишних бюллетеней! это что вообще такое? Вбросы? но как проверить, связи с избирателями нет, просто бюллетени, которые лежат сверх тех, что были "напечатаны типографией". И этот вопрос уже за гранью переголосований и т.п. method_id 9 - расшифровка голоса, таких записей в таблице "transactions" - 1319943, что значительно меньше выданных бюллетеней, они содержат информацию о расшифровке голоса в бюллетене, и эти данные содержатся в следующей таблице: "decrypted_ballots". Почему их так мало, вопрос отдельный. Слышал такое объяснение, что данные о переголосованиях, лежат в отдельном секретном блокчейне, и вот с учётом сверки с ним, и были посчитаны голоса.
-
таблица: "decrypted_ballots", содержит 1318977 записей, что на 966 меньше чем в транзакциях о расшифровке!, Такого быть не должно в принципе! Записи попросту пропали, вдруг. Транзакции о расшифровке есть, а самой расшифровки нет. Конечно же, их можно расшифровать, но стоп. Зачем нам это делать? Есть программа, блокчейн, БД, которые должны работать. Но получается, что в их работе содержатся серьёзные проблемы, которые приводят к тому, что попросту пропадают данные.
-
Но как понимать 1318977 из 1943590 выданных бюллетеней?:
Можно было бы предположить, что вот эти вот 1318977 записей получились потому, что вот расшифровывали, и не успели. Такое может быть, ведь расшифровку делали не одним запросом, а блоками. Но есть проблема, не расшифрованные записи в базе есть за весь период голосования. Возможно ли, что они брались не последовательно, по дате, а рандомно?
Есть предположение, что эта разница, с учётом того, что были переголосования, и по причине правок из таинственного скрытого блокчейна, вот эти голоса и должны быть посчитаны. Но вопрос, как тогда выглядит наша расшифровка? Ведь если есть переголосование, то отменяемые голоса, будут скорее всего в самом начале периода голосования, и их число будет снижаться к концу. Проверяем:
-
на графике видно, что динамика, действительно похожа на переголосования, но возникает вопрос, как переголосование могло быть в районе 23 часов 2021.09.19? 236 голоса, сделанные в период с 19 до 20 часов, не были посчитаны. А мы помним, что переголосовать можно только через 3 часа после голосования. В то время, как последний блок был создан в 2021-09-19 21:19:07.902+03. Если это переголосования, а система должна блокировать возможность на 3 часа, тогда, это могло быть сделано только специальным ботом, который не учёл эту особенность.
Возникла идея, сравнить голоса расшифрованные и нерасшифрованные, (которые вероятно отменили по вероятному переголосованию):
-
Получается лютый треш. Последние нерасшифрованные 236 голоса, просто не были учтены, в этот час и после него, просто не было новых. Поэтому, необходим точный и ясный ответ. Являются ли голоса в таблице "decrypted_ballots" полными и корректными?
И если да, тогда что это за такое странное расхождение в переголосованиях? то 0%, то 100%, что с этими голосами не так? Куда пропадают часть голосов и по какой причине?
Если нет, тогда и говорить не о чем, неверные данные = нет никаких данных, а значит не было и наблюдения за голосованием, а было просто шоу для маскировки.
Почему я не стал делать статистику?
Нет данных на которых будет правильно делать статистику, да, её делают, она показывает аномалии, и её делать важно и нужно, но, по моему мнению, достаточно прямых ошибок в данных, которые показывают, что эта система полностью непригодна для голосования.
Уже тех фатов того, что:
Бюллетеней учтено больше чем было выдано - провал.
Пропали часть расшифрованных бюллетеней - провал.
Невозможно понять, что именно происходит в базе данных - нет связи между избирателем и бюллетенем, а значит невозможно правильно посчитать - провал.
Понять почему расшифрованы только 65,23% - невозможно - провал.
Если эти данные, которые нам дали не корректны, то дайте корректные, они не могут их предоставить - провал.
Достаточно, чтобы признать систему нерабочей и отменить результаты ЭГ полностью.
Даже если "они" предоставят некие корректные базы позже, увы, им будет сложно доверять. Я сомневаюсь, что они сумеют достаточно хорошо фальсифицировать цепочки хэшей, для создания подходящего фейкового блокчейна. А потому ничего и не дадут.
Вопрос чем поможет статистика, если организаторы не признают прямых и очевидных ошибок?
Некоторые выводы
Как вообще интерпретировать такие соотношения, неизвестно. Факт в том, что у наблюдателей, по сути нет корректного материала для наблюдения и проверок.
Понятно только то, что некоторые данные, вероятно корректные, и по ним, множество людей делают довольно интересные статистические обзоры, которые указывают на невозможные без вмешательства извне, аномалии.
-
Если от нас скрывают некоторые данные, то возникает вопрос - почему? Блокчейны с деньгами лежат в свободном доступе, а от нас скрывают блокчейн с голосованием. Если у этого есть цель, то какая? Варианты, которые приходят в голову:
Ничего не сработало и получилась куча ошибок, и данные которые нам всучили, некорректные. И скрывают сломанный, некачественный продукт.
Скрывают реальные данные, поскольку они отличаются от тех итогов, которые нам предлагают как результаты голосования.
Вероятно, что в реальном блокчейне, сделали вбросы, но настолько топорные, что они будут очевидны.
Их секретный блокчейн содержит реальные данные избирателей, кто и как проголосовал. Увы, но система не может быть анонимной по определению. Регистрация на госсайтах не анонимная. СМС отправляются реальным людям. Поэтому, нам врут, что всё анонимно, а на самом деле нет.
Любые комбинации на выбор.
Если данные, которые нам предложили, нужно считать верными и полными, тогда единственны вывод, который можно сделать - система ЭГ не сработала, мы видим множество ошибок и нестыковок, которых быть попросту не может в корректно работающей системе, а если она работает не корректно, то доверять результатам её работы невозможно, а значит их следует отменить, а систему доработать.
Комментарии (19)
newpavlov
09.10.2021 22:09+3Без обязательного self-custody ключей и подробно описанного протокола для которого можно написать свой клиент доверия к системе априори быть не может. Причём ключи должны быть достаточно важными (на уровне возможности создания юридически значимых ЭЦП) дабы их нельзя было собирать или покупать пачками. Блокчейны тоже по сути дела не нужны и являются пусканием модной пыли в глаза.
Sabubu
09.10.2021 23:43+10Я разбирал выложенный на Гитхаб код и могу ответить на некоторые вопросы.
Там было два блокчейна — публичный (который выложен) и приватный, который не публиковался. В приватный при подаче бюллетеня записывались:
- хеш транзакции приема бюллетеня из публичного блокчейна
- точное время подачи бюллетеня
- идентификатор group_id (в зашифрованном виде, позже он расшифровывается), который одинаковый для одинаковых пользователей и таким образом позволяет найти бюллетени, поданные одним и тем же пользователем и учесть только последний. Алгоритм подсчета итогов есть в файле services/actual-ballots-service/src/transactions/tally_results.rs в коде приватного блокчейна.
Некоторым интересно, наверно, узнать, как получается group_id? Он формируется в "компоненте X". Он получался примерно таким образом: за основу берется sudir_id (id пользователя на сайте mos.ru, если я не путаю), он хешируется (HMAC) с добавлением какого-то ключа, отправляется в MDM (Master Data Management — код этой системы не опубликован), оттуда возвращается external_id, он хешируется еще раз с добавлением другого ключа, затем шифруется (обратимо) и этот id уже используется как group_id. При этом компонент X зачем-то логгирует отправленные и полученные из MDM данные.
Часть кода получения group_id есть в коде "компонента X", который для этого и предназначен. Так как кода MDM у нас нет, то восстановить полный алгоритм нельзя.
После расшифровки голосов в публичном блокчейне и расшифровки зашифрованных group_id из приватного блокчейна в приватный блокчейн загружались данные по голосованию по бюллетеням и расшифрованные group_id. Далее в нем определялись итоги выборов: брались бюллетени с выбором, из них брался последний поданный и засчитывался.
Впрочем, это я сужу по опубликованному коду. Как было на самом деле, я не знаю.
И тут возникает проблема, транзакции c method_id 1 и 4, содержат "voter_id" в виде "22443685531066461899103156899237857105006237160299631129744914447305194856993", а транзакции c method_id 5 и 6, содержат связанные поля voter_key и author в виде хеша
А вы не пробовали перевести это длинное десятичное число в шестнадцатеричную форму? Получается как раз 32-байтное 16-чное число.
Как такое может быть? Переголосования? но для него тоже выдаётся бюллетень (должен выдаваться, иначе как?
В том -то и трюк, что при повторном голосовании в публичном блокчейне это никак не фиксируется. То есть запись "выдача бюллетеня" — это выдача первого бюллетеня.
method_id 9 — расшифровка голоса, таких записей в таблице "transactions" — 1319943, что значительно меньше выданных бюллетеней, они содержат информацию о расшифровке голоса в бюллетене, и эти данные содержатся в следующей таблице: "decrypted_ballots".
Почему их так мало, вопрос отдельныйОбъясняют это тем, что подсчет долго шел, и чтобы его ускорить, отключили запись результатов расшифровки. Также говорят, что можно самостоятельно расшифровать результаты, используя приватный ключ голосования. Код на Раст с использованием библиотеки NaCl можно увидеть в https://github.com/moscow-technologies/blockchain-voting_2021/blob/main/blockchain/dit-blockchain-source.tgz в файле services/votings-service/src/schema/ballots_storage.rs
Есть предположение, что эта разница, с учётом того, что были переголосования, и по причине правок из таинственного скрытого блокчейна, вот эти голоса и должны быть посчитаны.
Нет, в публичном блокчейне расшифровывались все бюллетени и не было информации о повторных голосованиях.
В то время, как последний блок был создан в 2021-09-19 21:19:07.902+03. Если это переголосования, а система должна блокировать возможность на 3 часа, тогда, это могло быть сделано только специальным ботом, который не учёл эту особенность.
Выдавать бюллетени перестали в 20:00, подавать бюллетени можно было до 20:15. Также по уверениям организаторов, бюллетени перемешивались и искуственно задерживались, чтобы нельзя было определить голосующего. Видимо, период задержки как раз и составлял до 10 минут. По концу голосования можно попробовать как-то определить параметры задержки.
Что касается недостатка данных — это верно. Не опубликован приватный блокчейн. Также, компоненты ведут подробные логи событий вроде: отправка СМС, успешная/неуспешная проверка кода, открытие бюллетеня, отправка бюллетеня, ошибки при отправке бюллетеня. Также, в "кабинет председателя" отправлялась информация об этих событиях (очень подробная: например, при создании бюллетеня в кабинет отправлялась ссылка на бюллетень и даже id сессии пользователя. Если председатель был быстр и злонамерен, он мог бы зайти в бюллетень раньше пользователя и сессия бы привязалась к нему, а пользователь бы получил отказ — см файл app/Component/Election/Keeper.php тут ).
Нет никакой проблемы опубликовать эти логи в урезанном формате: время, событие, номер участка. Такие логи не содержат никаких персональных данных и не раскрывают тайну голосования, но позволяют проверить его ход. Однако, логи не опубликованы.
MaximRV
10.10.2021 04:37+1А мне интересно, что при голосовании никто не гарантирует отсутствия параллельной записи на другие сервера данных в открытом незашифрованном виде о том, кто и как голосовал.
Ну и шоу с генерацией ключа и разделением его на 7 частей, где гарантия что во время генерации он не писался сразу же куда-то ещё.
Ну и по мотивам статей, уже опубликованных. Походу участники процесса этого типа голосования сами друг другу не доверяли и поэтому как в технической части, так и в организационной столько нестыковок.
StjarnornasFred
10.10.2021 09:06+11В очередной раз повторю своё мнение. Не имеет абсолютно никакого значения, используется ли блокчейн или нет: он либо бесполезен, либо ненужен, и его, вероятнее всего, внедрили для "отпугивания" части недовольных: типа, раз блокчейн, значит, всё в порядке (а это в принципе не так).
Есть ровно 2 фактора, которые должны быть обеспечены, но которые обеспечены не были:
Доступ членов избирательной комиссии ко всей системе: исходному коду, всем логам сервера, базе данных. На выборах не может быть никакой скрытой информации, которая была бы недоступна избирательной комиссии. К этому же пункту относится право наблюдателей ознакомиться с исходным кодом.
Общественное, а не административное, комплектование избирательных комиссий ДЭГ, аналогично обычным ТИК и УИК.
Всё остальное - элементарные технические вещи, которые на уровне алгоритмов разработаны давным-давно. Если ТИК ДЭГ комплектуется административно, то её члены заряжены на обеспечение результата, а не на честные выборы. Если нет доступа к исходному коду и логам, то даже честная ТИК ДЭГ будет работать с неизвестно чем. Проблема не в алгоритмах, а в том, что выборы были непрозрачными и доступными для полного контроля только неустановленным лицам, а не наблюдателям. В частности, организованный за несколько дней до выборов "аудит исходного кода всеми желающими" был профанацией, потому что никто не знает, тот ли код они аудировали или непонятно что.
solntsepek
10.10.2021 12:48+13Если исходить из закона, то "голосование" должно обладать возможностью воспроизводимости (пересчитываемости). Имеющийся лохотрон под названием ДЭГ делали (кодили) и проводили (выполняли) не избирательные комиссии (члены которых в том числе имеют по закону право на доступ к персональным данным избирателей), а собянинская администрация (вплоть до тендера мэрии на портале госзакупок на написание софта для ДЭГ, который сам по себе образует состав преступления) и частная иностранная компания "Лаборатория Касперского" (kaspersky lab - это АО с уставным капиталом 100 тыс. руб., управляемое через офшор). Ни одна комиссия не сможет ни воспроизвести (пересчитать), ни проверить "результат" ДЭГ
Никакие исходники или логи или настройки никому никогда не покажут, потому что из них станет очевидно, что ДЭГ проектировался и писался (кодировался) как специализированный софт для нарушения закона, следоваптельно все его заказчики, авторы и участники - преступники.
Я надеюсь, что техническое (инженерное) сообщество русских программистов сделает вывод относительно ФСБшулеров (напёрсточников kaspersky lab, просто нарисовавших результаты лохотрона и пытающихся их выдать за результаты выборов) и их продуктов.
Репутация завоёвывается годами, а теряется меньше чем за неделю.
Я раньше пользовался продуктами Лаборатории Касперского, доверял им.
После того, как Лаборатория сфальсифицировала ДЭГ (электронное голосование) - перестал пользоваться и активно не советую другим.
Брезгую иметь хоть что-то общее с преступниками.
Работаю с компаниями VISA, Mastercard, EMVCo, FIME, UL, ATOMWORKS, ELITT, банками и платёжными системами по всему миру
и если коллеги спросят - обязательно расскажу им, как Лаборатория Касперского участвовала в вооруженном захвате и удержании власти, сделав и запустив софт, который позволил их сообщникам сфальсифицировать ДЭГ тремя разными способами https://youtu.be/3tO4HaYEdYw
Позором России до 21 сентября 2021 г. были мусора, теперь ещё программисты из ДИТ мэрии Москвы стали и из международной ИБ-компании kaspersky lab
Paskin
12.10.2021 08:09Тут скорее обратная зависимость - использование блокчейна (действительное или на словах) в большинстве случаев свидетельствует о планируемом мошенничестве.
corvair
10.10.2021 16:22Интересно, существуют ли зарубежные системы ДЭГ? Уж к ним то никаких вопросов не должно быть заведомо. Было бы интересно сравнить реализацию.
vokalbo
19.10.2021 03:44+1Кажется главный косяк в observer-20210921_143000.sql в том, что три первых часа количество проголосовавших всегда больше количества получивших бюллетень при чём на десятки тысяч в моменте, что учитывая что переголосовывать можно не чаще чем раз в три часа смысла не имеет, такого просто не может быть.
PFFyodor Автор
19.10.2021 03:49На этот счёт есть "оправдание".
У них, есть некий миксер. Якобы есть, Якобы миксер. Который перемешивает голоса перед добавлением в базу, чтобы по времени голоса, никто не догадался кто и как теоретически мог проголосовать.В таком случае, то, что часть голосов пришла раньше выдачи бюллетеней может быть объяснена.
Я не следил за приходом данных в блокчейн во время голосования, поэтому не могу сказать, так ли это было, но...
Зачем дата-время блока указаны? Ведь тогда, это ложная информация, потому что блоки заходят достаточно плавно и регулярно, я не просто так указал на то, что их по несколько в секунду заходит. Если подстановка фейковых-даты и времени, умышленная, то вопрос - зачем вообще создавать БД с ложными данными? Сам принцип нарушен, БД содержащая ложную информацию уже считается сломанной. Априори.
vokalbo
19.10.2021 06:10Там в первый час пятницы по одномандатному округу проголосовало 100 тысяч, а получила бюллетень всего 20 тысяч человек - это никакой задержкой не оправдывается.
А дата в таблице транзакций совпадает с датой в таблице блоков, транзакции просто вносятся порциями по 400 за раз.
Cost_Estimator
Нет ли у вас этой базы где-то в хранилище? Обсервер не хочет делиться, уже почти час вижу это:
sergiks
Подключиться попробуйте с российского, а в идеале, московского IP. При подключении через VPN за рубежом, наблюдал такую же проблему (не коннектился WebSocket).
vokalbo
В прошлой теме на аналогичный вопрос бросали ссылку на гугл диск https://drive.google.com/drive/folders/1fudrkl4YZdyWeREuJ7B4BNbp6kYUPEFV?usp=sharing .
Cost_Estimator
Спасибо, удалось скачать с первоисточника.