Комментарии 19
Подключиться попробуйте с российского, а в идеале, московского IP. При подключении через VPN за рубежом, наблюдал такую же проблему (не коннектился WebSocket).
В прошлой теме на аналогичный вопрос бросали ссылку на гугл диск https://drive.google.com/drive/folders/1fudrkl4YZdyWeREuJ7B4BNbp6kYUPEFV?usp=sharing .
Без обязательного self-custody ключей и подробно описанного протокола для которого можно написать свой клиент доверия к системе априори быть не может. Причём ключи должны быть достаточно важными (на уровне возможности создания юридически значимых ЭЦП) дабы их нельзя было собирать или покупать пачками. Блокчейны тоже по сути дела не нужны и являются пусканием модной пыли в глаза.
Я разбирал выложенный на Гитхаб код и могу ответить на некоторые вопросы.
Там было два блокчейна — публичный (который выложен) и приватный, который не публиковался. В приватный при подаче бюллетеня записывались:
- хеш транзакции приема бюллетеня из публичного блокчейна
- точное время подачи бюллетеня
- идентификатор 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 тут ).
Нет никакой проблемы опубликовать эти логи в урезанном формате: время, событие, номер участка. Такие логи не содержат никаких персональных данных и не раскрывают тайну голосования, но позволяют проверить его ход. Однако, логи не опубликованы.
А мне интересно, что при голосовании никто не гарантирует отсутствия параллельной записи на другие сервера данных в открытом незашифрованном виде о том, кто и как голосовал.
Ну и шоу с генерацией ключа и разделением его на 7 частей, где гарантия что во время генерации он не писался сразу же куда-то ещё.
Ну и по мотивам статей, уже опубликованных. Походу участники процесса этого типа голосования сами друг другу не доверяли и поэтому как в технической части, так и в организационной столько нестыковок.
В очередной раз повторю своё мнение. Не имеет абсолютно никакого значения, используется ли блокчейн или нет: он либо бесполезен, либо ненужен, и его, вероятнее всего, внедрили для "отпугивания" части недовольных: типа, раз блокчейн, значит, всё в порядке (а это в принципе не так).
Есть ровно 2 фактора, которые должны быть обеспечены, но которые обеспечены не были:
Доступ членов избирательной комиссии ко всей системе: исходному коду, всем логам сервера, базе данных. На выборах не может быть никакой скрытой информации, которая была бы недоступна избирательной комиссии. К этому же пункту относится право наблюдателей ознакомиться с исходным кодом.
Общественное, а не административное, комплектование избирательных комиссий ДЭГ, аналогично обычным ТИК и УИК.
Всё остальное - элементарные технические вещи, которые на уровне алгоритмов разработаны давным-давно. Если ТИК ДЭГ комплектуется административно, то её члены заряжены на обеспечение результата, а не на честные выборы. Если нет доступа к исходному коду и логам, то даже честная ТИК ДЭГ будет работать с неизвестно чем. Проблема не в алгоритмах, а в том, что выборы были непрозрачными и доступными для полного контроля только неустановленным лицам, а не наблюдателям. В частности, организованный за несколько дней до выборов "аудит исходного кода всеми желающими" был профанацией, потому что никто не знает, тот ли код они аудировали или непонятно что.
Если исходить из закона, то "голосование" должно обладать возможностью воспроизводимости (пересчитываемости). Имеющийся лохотрон под названием ДЭГ делали (кодили) и проводили (выполняли) не избирательные комиссии (члены которых в том числе имеют по закону право на доступ к персональным данным избирателей), а собянинская администрация (вплоть до тендера мэрии на портале госзакупок на написание софта для ДЭГ, который сам по себе образует состав преступления) и частная иностранная компания "Лаборатория Касперского" (kaspersky lab - это АО с уставным капиталом 100 тыс. руб., управляемое через офшор). Ни одна комиссия не сможет ни воспроизвести (пересчитать), ни проверить "результат" ДЭГ
Никакие исходники или логи или настройки никому никогда не покажут, потому что из них станет очевидно, что ДЭГ проектировался и писался (кодировался) как специализированный софт для нарушения закона, следоваптельно все его заказчики, авторы и участники - преступники.
Я надеюсь, что техническое (инженерное) сообщество русских программистов сделает вывод относительно ФСБшулеров (напёрсточников kaspersky lab, просто нарисовавших результаты лохотрона и пытающихся их выдать за результаты выборов) и их продуктов.
Репутация завоёвывается годами, а теряется меньше чем за неделю.
Я раньше пользовался продуктами Лаборатории Касперского, доверял им.
После того, как Лаборатория сфальсифицировала ДЭГ (электронное голосование) - перестал пользоваться и активно не советую другим.
Брезгую иметь хоть что-то общее с преступниками.
Работаю с компаниями VISA, Mastercard, EMVCo, FIME, UL, ATOMWORKS, ELITT, банками и платёжными системами по всему миру
и если коллеги спросят - обязательно расскажу им, как Лаборатория Касперского участвовала в вооруженном захвате и удержании власти, сделав и запустив софт, который позволил их сообщникам сфальсифицировать ДЭГ тремя разными способами https://youtu.be/3tO4HaYEdYw
Позором России до 21 сентября 2021 г. были мусора, теперь ещё программисты из ДИТ мэрии Москвы стали и из международной ИБ-компании kaspersky lab
Тут скорее обратная зависимость - использование блокчейна (действительное или на словах) в большинстве случаев свидетельствует о планируемом мошенничестве.
Интересно, существуют ли зарубежные системы ДЭГ? Уж к ним то никаких вопросов не должно быть заведомо. Было бы интересно сравнить реализацию.
Плюсануть почему-то не могу ((
Спасибо за статью!
Кажется главный косяк в observer-20210921_143000.sql в том, что три первых часа количество проголосовавших всегда больше количества получивших бюллетень при чём на десятки тысяч в моменте, что учитывая что переголосовывать можно не чаще чем раз в три часа смысла не имеет, такого просто не может быть.
На этот счёт есть "оправдание".
У них, есть некий миксер. Якобы есть, Якобы миксер. Который перемешивает голоса перед добавлением в базу, чтобы по времени голоса, никто не догадался кто и как теоретически мог проголосовать.В таком случае, то, что часть голосов пришла раньше выдачи бюллетеней может быть объяснена.
Я не следил за приходом данных в блокчейн во время голосования, поэтому не могу сказать, так ли это было, но...
Зачем дата-время блока указаны? Ведь тогда, это ложная информация, потому что блоки заходят достаточно плавно и регулярно, я не просто так указал на то, что их по несколько в секунду заходит. Если подстановка фейковых-даты и времени, умышленная, то вопрос - зачем вообще создавать БД с ложными данными? Сам принцип нарушен, БД содержащая ложную информацию уже считается сломанной. Априори.
Несколько технических вопросов к ДЭГ