Безопасные онлайн-выборы: полное техническое руководство по созданию системы без махинаций

Время чтения: 45-60 минут
Уровень: от базового до экспертного
Дата публикации: Январь 2026

Онлайн-голосование на государственных выборах — одна из самых сложных технических задач современности. Это не просто «сайт с формой». Это криптографическая система, которая должна одновременно гарантировать анонимность избирателя, позволять каждому убедиться в корректности результатов и противостоять атакам государственного уровня.

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

Содержание

Для широкой аудитории (30%)

1. Часть I: Почему онлайн-выборы могут быть надёжнее бумажных
   • 1.0 Короткая версия: как вас не обманут и как вы это проверяете
   • 1.1 Уязвимости бумажного голосования
   • 1.2 Парадокс: цифровая система может быть прозрачнее
   • 1.3 Три уровня проверяемости (E2E-V)
   • 1.4 Связывать ли голос с личностью? Парадокс анонимности
   • 1.5 Как работает система — пошаговое объяснение
     • 1.5.1 Что означает квитанция (и что НЕ означает)
   • 1.6 Публичная проверяемость — каждый сам убеждается
     • 1.6.1 Как выглядит индивидуальная проверка на практике
     • 1.6.2 Если запись по квитанции не находится: что делать
     • 1.6.3 Кому всё равно приходится доверять (границы доверия)
   • 1.7 Защита от принуждения и «голосования под угрозой»
     • 1.7.1 Границы защиты: что система НЕ может гарантировать
   • 1.8 Противодействие массовому мошенничеству
   • 1.9 Как происходит мониторинг и наблюдение
     • 1.9.1 Как публиковать статистику, не ломая приватность
   • 1.10 Визуальная схема: как работает вся система
   • 1.11 Почему обычному избирателю это важно
   • 1.12 Ответы на частые вопросы
   • 1.13 Блокчейн в системе выборов — что это и зачем
   • 1.14 Памятка: как отличить надёжную систему от ненадёжной

Для технических специалистов (70%)

2. Часть II: Криптографические основы
   • 2.1 Гомоморфное шифрование
   • 2.2 Доказательства с нулевым знанием (ZKP)
   • 2.3 Схемы разделения секрета
   • 2.4 Слепые подписи
   • 2.5 Commitment-схемы и Merkle Trees
   • 2.6 Миксеры (Mix-Networks)
3. Часть III: Архитектура системы
   • 3.1 Структуры данных (Bulletin Board)
   • 3.2 Блокчейн в избирательных системах
   • 3.3 Протокол голосования: пошаговый алгоритм
   • 3.4 Системы верификации
   • 3.5 Мониторинг в реальном времени
4. Часть IV: Все угрозы и методы защиты
   • 4.1 Модель угроз
   • 4.2 Технические угрозы
   • 4.3 Организационные угрозы
   • 4.4 Социальная инженерия и манипуляции
   • 4.5 Проблема «последней мили»
5. Часть V: Практические кейсы
   • 5.1 Эстония: i-Voting
   • 5.2 Швейцария: CHVote
   • 5.3 Helios Voting
   • 5.4 Voatz (критический анализ)
   • 5.5 Belenios, ElectionGuard, Scytl
   • 5.6 Сравнительная таблица систем
6. Часть VI: Государственные выборы — специфика
   • 6.1 Масштаб и требования
   • 6.2 Правовые аспекты
   • 6.3 Интеграция с существующими системами
   • 6.4 Гибридная модель: онлайн + традиционное
7. Часть VII: Roadmap внедрения
   • 7.1 Этапы создания системы
   • 7.2 Общий таймлайн
   • 7.3 Критерии готовности
   • 7.4 Оценка ресурсов
   • 7.5 Рекомендуемая архитектура
   • 7.6 Серверная архитектура для 40 млн избирателей
   • 7.7 Оценка рисков и митигация
8. Источники и ссылки

Часть I: Почему онлайн-выборы могут быть надёжнее бумажных

Эта часть написана простым языком для всех: избирателей, журналистов, общественных активистов. Здесь мы объясним, как работает система и почему ей можно доверять.

1.0 Короткая версия: как вас не обманут и как вы это проверяете

Главная идея надёжных онлайн-выборов — не “поверьте нам”, а “проверьте сами”. Если система сделана правильно, она устроена так, чтобы ни администратор, ни хакер, ни “комиссия” не могли тихо поменять результат, не оставив публичных следов.

Как выглядит проверка для обычного человека (в 5 минут):

1. Вы получаете квитанцию после голосования (код/хеш/commitment).
2. Вы находите свою запись на публичной доске по квитанции и убеждаетесь, что она опубликована (Recorded-as-Cast).
3. Вы проверяете, что доска одна и та же для всех (несколько независимых зеркал/чекпойнтов — иначе возможны “две реальности”).
4. После окончания голосования любой наблюдатель пересчитывает результат по публичным данным и проверяет доказательства (Tallied-as-Recorded).

Что должно быть публично заранее (иначе “проверка” превращается в веру):

• Официальные адреса и каналы: понятный список доменов/приложений, опубликованный в нескольких независимых местах.
• Публичные параметры выборов: публичный ключ/параметры протокола и их отпечатки (fingerprints), чтобы их нельзя было “тихо заменить”.
• Зеркала публичной доски: несколько независимых источников, где можно проверить совпадение данных.
• Правила гибридного голосования: как именно бумажный голос отменяет онлайн и как это отражается в данных для проверки.

Если интернет хороший / плохой / очень плохой: в надёжной модели голосование идёт несколько дней, чтобы вы могли проголосовать не “в один момент”, а когда связь появится. Если связь настолько плохая, что онлайн недоступен — сохраняется обычное голосование на участке. Онлайн-канал должен быть дополнительным, а не единственным.

Если вы не доверяете телефону/компьютеру: у вас должна оставаться возможность проголосовать на участке. В гибридной модели обычно действует правило: бумажный голос имеет приоритет и отменяет онлайн-голос (это также снижает риск принуждения).

1.1 Уязвимости бумажного голосования

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

• Вбросы: пачки бюллетеней добавляются в урны
• Карусели: одни и те же люди голосуют многократно
• Подмена урн: контейнеры с бюллетенями заменяются по дороге в избирком
• Фальсификация протоколов: реальные цифры подменяются при подсчёте
• Административное давление: контроль за тем, как голосуют сотрудники предприятий

Главная проблема бумаги — невозможность полной проверки. Вы опустили бюллетень в урну. Что произошло дальше? Вы не знаете. Вы доверяете членам комиссии, наблюдателям, транспорту, программному обеспечению для подсчёта. Каждое звено — потенциальная точка отказа.

1.2 Парадокс: цифровая система может быть прозрачнее

Интуитивно кажется, что бумага надёжнее компьютеров. «Бумагу не взломаешь». Но это иллюзия. Бумагу легко подделать, подменить, уничтожить. А главное — бумажный процесс непрозрачен для обычного гражданина.

Криптографически защищённая электронная система может дать то, что недоступно бумаге: математически доказуемые гарантии. Не «мы доверяем комиссии», а «каждый избиратель может проверить свой голос, и любой желающий может проверить итоговый подсчёт».

Что это даёт на человеческом языке: система проектируется так, чтобы ключевые виды обмана становились публично обнаруживаемыми:

• Нельзя “тихо удалить” ваш голос: если у вас есть квитанция, вы можете найти запись на публичной доске. А наблюдатели проверяют, что доска едина (нет split-view).
• Нельзя “тихо подменить” голос: попытки изменить опубликованные данные ломают проверки (подписи/доказательства/хеш-цепочки), и независимые верификаторы это покажут.
• Нельзя “тихо нарисовать результат”: итог должен получаться из публичных данных и проверяемых доказательств, а значит любой желающий может пересчитать.
• Нельзя заставить вас доказать выбор: квитанция подтверждает факт записи, но не раскрывает “за кого”, иначе это превращается в инструмент давления.

1.3 Три уровня проверяемости (End-to-End Verifiability)

Надёжная система онлайн-голосования должна обеспечивать три типа проверки:

Эти три уровня называются End-to-End Verifiability (E2E-V). Система, которая обеспечивает E2E-V, позволяет каждому убедиться в честности выборов, не полагаясь на доверие к организаторам.

1.4 Связывать ли голос с личностью? Парадокс анонимности и проверяемости

На первый взгляд, требования анонимности и проверяемости противоречат друг другу:

• Анонимность требует, чтобы никто не мог узнать, как голосовал конкретный человек
• Проверяемость требует, чтобы избиратель мог убедиться, что его голос учтён

Ответ: связь нужна, но она разрывается.

Система работает в два этапа:

1. На этапе регистрации — система знает, кто вы. Это необходимо, чтобы убедиться, что вы имеете право голоса и не голосуете дважды.
2. На этапе голосования — связь между вами и вашим голосом разрывается криптографически. Даже операторы системы не могут её восстановить.

Аналогия с конвертами:

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

В криптографии это делается через слепые подписи: государство «подписывает» ваш голос, не видя его содержимого.

1.5 Как работает система — пошаговое объяснение для всех

Разберём весь процесс от начала до конца простым языком:

Шаг 1: Подготовка (за месяцы до выборов)

Что происходит: Создаётся «замок», ключ от которого разделён между несколькими независимыми организациями.

Почему это важно: Никто в одиночку не может открыть замок и прочитать голоса до окончания выборов. Нужно, чтобы 5 из 9 организаций (например, ЦИК + оппозиция + наблюдатели + общественность) собрались вместе.

Аналогия: Представьте сейф с 9 замками, который открывается только когда вставлены минимум 5 ключей. Каждый ключ — у отдельной организации. Ни одна из них не может открыть сейф самостоятельно.

Шаг 2: Регистрация избирателя

Что вы делаете:

1. Заходите в приложение «Дія» или на сайт выборов
2. Подтверждаете личность (ID-карта с NFC, BankID или электронная подпись)
3. Система проверяет, что вы в реестре избирателей
4. Вы получаете специальный «токен» — криптографический пропуск для голосования

Что происходит «под капотом»: Система фиксирует, что Иван Иванович имеет право голоса. Но токен, который вы получаете, уже не связан с вашим именем — благодаря криптографии «слепых подписей».

Шаг 3: Голосование

Что вы делаете:

1. Выбираете кандидата в интерфейсе
2. Нажимаете «Голосовать»
3. Получаете уникальный код-квитанцию

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

Что происходит «под капотом»:

1. Ваш телефон/компьютер шифрует голос так, что прочитать его может только «сейф с 9 замками»
2. К голосу прикрепляется математическое доказательство, что это действительно голос за одного кандидата (а не попытка накрутки)
3. Зашифрованный голос отправляется на сервер
4. Сервер проверяет доказательство и ваш токен, но не может прочитать сам голос
5. Голос публикуется на публичной доске — его видят все, но никто не может расшифровать

Шаг 4: Проверка вашего голоса

Что вы делаете:

1. Заходите на публичную доску (открытый сайт)
2. Вводите свой код-квитанцию
3. Видите: да, ваш зашифрованный голос есть в списке

Важно: Вы видите, что ваш голос принят, но никто (включая вас) не может доказать третьим лицам, за кого вы голосовали. Квитанция не раскрывает содержимого голоса.

Шаг 4.1: Что именно означает квитанция (и что НЕ означает)

Квитанция/код — это ключ к поиску записи на публичной доске. Когда вы находите запись по коду, это означает:

• Recorded-as-Cast: в системе действительно есть запись, соответствующая вашему отправленному сообщению (зашифрованному бюллетеню) — её нельзя “тихо” удалить, не оставив следов.
• У вас есть объект для проверки: теперь вы (и наблюдатели) можете проверить, что запись корректна формально: подписи/токены валидны, доказательства корректности голоса (ZKP) проходят проверку, запись встроена в журнал.

Но важно понимать, чего квитанция сама по себе не гарантирует:

• Не гарантирует, что интерфейс не соврал при выборе: если устройство заражено или приложение подменено, оно может зашифровать не тот выбор. Поэтому у серьёзных систем есть механизмы “проверки до отправки” (например, challenge-проверка/повторная независимая проверка на другом устройстве).
• Не является доказательством “за кого вы проголосовали”: иначе это превращается в инструмент принуждения/скупки голосов.
• Не доказывает окончательный результат: итог доказывается совокупностью данных: журналом, доказательствами перемешивания (shuffle proofs), доказательствами расшифровки и воспроизводимым пересчётом.

Шаг 5: Подсчёт голосов

Что происходит:

1. Голосование закрывается
2. Все зашифрованные голоса перемешиваются специальными серверами (миксерами) — как карты в колоде. После этого невозможно понять, какой голос от какого человека.
3. Представители 5+ организаций собираются и совместно «открывают сейф»
4. Голоса расшифровываются суммарно: не каждый по отдельности, а сразу итог — сколько голосов у каждого кандидата
5. Всё это происходит публично, все доказательства публикуются

Шаг 6: Проверка результатов любым желающим

Что может сделать любой гражданин или организация:

1. Скачать все данные с публичной доски
2. Запустить программу-верификатор (открытый код, можно написать свою)
3. Проверить все математические доказательства
4. Убедиться, что подсчёт выполнен корректно

Это и есть «публичная проверяемость»: не нужно доверять словам — можно проверить математику.

1.6 Публичная проверяемость — каждый сам убеждается

Это ключевое отличие от бумажных выборов. Разберём подробнее:

Что именно можно проверить?

Как выглядит индивидуальная проверка на практике (минимальный сценарий)

Представьте, что вы получили код-квитанцию после отправки голоса. Дальше у вас есть “короткий путь” проверки:

1. Найти запись на доске: вы вводите код и находите строку/запись, соответствующую вашему шифротексту (или хешу/commitment).
2. Проверить неизменяемость записи: запись должна входить в хеш-цепочку/дерево (например, иметь ссылку на предыдущую запись или Merkle-proof). Это нужно, чтобы нельзя было “подменить задним числом”.
3. Проверить формальную корректность: у записи должны быть валидные подписи/метки авторизации и корректное ZKP, доказывающее, что бюллетень допустим (например, выбран ровно один вариант, и значения находятся в разрешённом диапазоне).
4. Проверить, что данные доступны из нескольких независимых источников: серьёзная система публикует одинаковый журнал на нескольких зеркалах/узлах наблюдателей. Это защищает от ситуации, когда разным людям показывают разные версии доски.

Если запись по квитанции не находится: что делать (без “веры на слово”)

В надёжной системе должен существовать понятный “протокол действий”, не разрушающий тайну голосования:

1. Проверить время: запись могла попасть на доску с задержкой (очередь/буферизация). На странице должны быть опубликованы целевые задержки и статус очередей.
2. Проверить несколько зеркал: если доска реплицируется, запись должна появляться одинаково на всех публичных копиях.
3. Проверить корректность кода: банально — опечатки. Но интерфейс должен позволять копирование без ошибок.
4. Проверить статус голоса: система должна различать состояния “принят”, “отклонён” (с причиной), “ожидает публикации”. Причина отклонения должна быть публично классифицирована (например: невалидный токен, некорректный ZKP, повторное использование токена и т.д.).
5. Если несоответствие подтверждено: должен существовать официальный канал подачи жалобы, а у комиссии — регламент расследования. Важно: расследование опирается на журналы событий и публичные данные, а не на “внутренние логи, которые никто не видит”.

Что такое «публичная доска» (Bulletin Board)?

Это открытый сайт/база данных, где публикуется ВСЁ:

• Каждый зашифрованный голос (без привязки к личности)
• Все криптографические доказательства
• Действия избирательной комиссии
• Результаты перемешивания
• Итоговая расшифровка

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

Кому всё равно приходится доверять (границы доверия)

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

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

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

1.7 Защита от принуждения и «голосования под угрозой»

Проблема удалённого голосования: если вы дома, кто-то может стоять рядом и заставлять вас голосовать «правильно».

Как система защищает от этого:

1. Возможность переголосования

Вы можете голосовать несколько раз. Учитывается только последний голос. Если кто-то заставил вас проголосовать — подождите, когда он уйдёт, и переголосуйте.

2. Бумажный голос отменяет электронный

Если вы проголосуете на физическом участке — ваш электронный голос автоматически аннулируется. Это «аварийный выход» для тех, кого принудили.

3. Невозможность доказать свой голос третьему лицу

Квитанция подтверждает, что вы проголосовали, но не раскрывает, за кого. Вы не можете «продать» голос, потому что не можете доказать покупателю, как голосовали.

4. «Панический» режим (опционально)

Некоторые системы позволяют создать «фейковый» код, который принимается системой, но голос не учитывается. Если вас принуждают — используете этот код.

Границы защиты: что система НЕ может гарантировать

Важно честно проговорить ограничения. Даже с переголосованием и “анти-квитанциями” остаются ситуации, которые полностью криптографией не закрыть:

• Контроль до конца: если принуждающий имеет возможность контролировать вас вплоть до закрытия голосования (или заставляет переголосовать “в последний момент”), переголосование может не помочь.
• Цифровой захват личности: если злоумышленник получил доступ к вашей цифровой идентичности (SIM-swap, украденная подпись/ключи, компрометация аккаунта), он может проголосовать “за вас”. Это уже зона защиты идентификации и процессов восстановления.
• Наблюдение/слежка: если за вами наблюдают физически или технически (камера, запись экрана), “невозможность доказать” не работает, потому что доказательство создаётся вне протокола.
• Социальное давление: криптография не отменяет давление работодателя/родственников — она лишь усложняет массовую скупку и принуждение через требование квитанций.

1.8 Противодействие массовому мошенничеству

Рассмотрим типичные сценарии мошенничества и как система их предотвращает:

1.9 Как происходит мониторинг и наблюдение

В режиме реального времени (во время голосования):

Публичный дашборд показывает:

• Сколько голосов подано (общее число)
• Распределение по регионам и времени
• Количество отклонённых голосов (с причинами)
• Статус всех серверов системы
• Хеши последних записей (для верификации целостности)

НЕ показывается до окончания голосования:

• За кого голосуют (промежуточные результаты)
• Связь голосов с регионами (чтобы избежать давления)

Что могут делать наблюдатели:

• Следить за публичной доской в реальном времени
• Запускать независимые верификаторы
• Присутствовать при церемонии расшифровки
• Скачивать и анализировать все данные
• Публиковать независимые отчёты

Автоматическое обнаружение аномалий:

Система сама отслеживает подозрительные паттерны:

• Аномально высокая активность с одного IP-адреса
• Необычные всплески голосования
• Массовые отклонения голосов
• Попытки атак на сервера

Как публиковать статистику, не ломая приватность

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

• Задержка публикации: статистика выкладывается с лагом (например, десятки минут или часы), чтобы не привязывать события к конкретному времени голосования человека.
• Крупные “бакеты”: регионы и временные интервалы агрегируются так, чтобы в каждом бакете было достаточно событий (никаких “село N, 3 голоса за 5 минут”).
• Ограничение метаданных: не публикуются списки IP/устройств/браузеров; причины отклонения — только в классифицированном виде, без персональных деталей.
• Запрет на промежуточные результаты: не только “за кого голосуют”, но и любые прокси-сигналы (например, распределение по малым регионам), которые могут стать инструментом давления.

1.10 Визуальная схема: как работает вся система

Общая архитектура системы онлайн-голосования:

┌─────────────────────────────────────────────────────────────────────────────┐
│                           ПОДГОТОВКА (до выборов)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   ┌─────────────┐    │
│   │ ЦИК         │   │ Оппозиция   │   │ Наблюдатели │   │ ... (9 org) │    │
│   │ Доля ключа  │   │ Доля ключа  │   │ Доля ключа  │   │ Доля ключа  │    │
│   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘   └──────┬──────┘    │
│          │                 │                 │                 │           │
│          └────────────────┬┴─────────────────┴─────────────────┘           │
│                           │                                                 │
│                           ▼                                                 │
│              ┌────────────────────────┐                                     │
│              │   ПУБЛИЧНЫЙ КЛЮЧ       │ ← Публикуется открыто               │
│              │   (для шифрования)     │                                     │
│              └────────────────────────┘                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                           РЕГИСТРАЦИЯ ИЗБИРАТЕЛЯ                            │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌───────────┐          ┌─────────────────┐         ┌──────────────────┐  │
│   │ Избиратель│ ───ID───▶│ Сервер авторизац│ ──────▶ │ Токен            │  │
│   │ (Дія/eID) │          │ "Вы в реестре"  │         │ (не связан с ID) │  │
│   └───────────┘          └─────────────────┘         └──────────────────┘  │
│                                    │                                        │
│                                    ▼                                        │
│                          [Связь разрывается]                                │
│                          [Слепые подписи]                                   │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                              ГОЛОСОВАНИЕ                                    │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌───────────┐    ┌──────────────────┐    ┌─────────────────────────────┐ │
│   │ Избиратель│    │ Телефон/компьютер│    │ Сервер голосования          │ │
│   │           │    │                  │    │                             │ │
│   │ Выбирает  │───▶│ 1. Шифрует голос │───▶│ 3. Проверяет токен + ZKP    │ │
│   │ кандидата │    │ 2. Создаёт ZKP   │    │ 4. НЕ МОЖЕТ расшифровать    │ │
│   │           │    │    (доказат-во)  │    │ 5. Публикует на доске       │ │
│   └───────────┘    └──────────────────┘    └──────────────┬──────────────┘ │
│                                                           │                 │
│                                                           ▼                 │
│                                            ┌─────────────────────────────┐  │
│                                            │    ПУБЛИЧНАЯ ДОСКА          │  │
│                                            │ ┌─────┬─────┬─────┬─────┐   │  │
│                                            │ │Голос│Голос│Голос│ ... │   │  │
│                                            │ │ #1  │ #2  │ #3  │     │   │  │
│                                            │ │(зашифрованные)         │   │  │
│                                            │ └─────┴─────┴─────┴─────┘   │  │
│                                            │ Все видят, никто не читает  │  │
│                                            └─────────────────────────────┘  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                              ПОДСЧЁТ                                        │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────────────────────┐    ┌──────────────────────────────────┐  │
│   │    ПУБЛИЧНАЯ ДОСКА          │    │           МИКСЕРЫ                │  │
│   │    (все голоса)             │───▶│  Перемешивают голоса             │  │
│   │                             │    │  + публикуют доказательство      │  │
│   └─────────────────────────────┘    └──────────────┬───────────────────┘  │
│                                                     │                       │
│                                                     ▼                       │
│   ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐          │
│   │ ЦИК: частич.│ │ Оппоз: част.│ │ Наблюд: част│ │ ... (5+ из 9)│          │
│   │ расшифровка │ │ расшифровка │ │ расшифровка │ │              │          │
│   └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘          │
│          └───────────────┼───────────────┼───────────────┘                  │
│                          ▼               ▼                                  │
│                 ┌────────────────────────────────┐                          │
│                 │     ИТОГОВЫЙ РЕЗУЛЬТАТ         │                          │
│                 │ Кандидат A: 12,345,678 голосов │                          │
│                 │ Кандидат B: 10,234,567 голосов │                          │
│                 │ + все доказательства           │                          │
│                 └────────────────────────────────┘                          │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                           ВЕРИФИКАЦИЯ                                       │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌───────────┐     ┌─────────────────────────────────────────────────┐    │
│   │Любой      │────▶│ Скачивает все данные + запускает верификатор    │    │
│   │гражданин  │     │                                                 │    │
│   └───────────┘     │ ✓ Проверяет все ZKP голосов                     │    │
│                     │ ✓ Проверяет shuffle proofs миксеров             │    │
│                     │ ✓ Проверяет доказательства расшифровки          │    │
│                     │ ✓ Проверяет математику подсчёта                 │    │
│                     │                                                 │    │
│                     │ Результат: КОРРЕКТНО / ОШИБКА                   │    │
│                     └─────────────────────────────────────────────────┘    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

1.11 Почему обычному избирателю это важно

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

1. Открытый исходный код: система должна быть полностью открыта для аудита. Если код закрыт — это красный флаг.
2. Независимые аудиторы: код и протоколы должны проверять разные организации — университеты, международные эксперты, общественные организации.
3. Возможность личной проверки: вы должны иметь возможность убедиться, что ваш голос учтён, по полученной квитанции.
4. Публичная доска: все зашифрованные голоса и итоги должны быть доступны для анализа любому желающему.
5. Пороговая расшифровка: ключ должен быть разделён между несколькими независимыми организациями.
6. Несколько независимых зеркал доски: данные должны совпадать у разных наблюдателей, иначе возможен split-view.
7. Прозрачность релизов клиента: опубликованные хеши релизов и возможность независимой проверки, что приложение/сайт не подменены.

Если система не предоставляет этих возможностей — ей нельзя доверять, какой бы «современной» или «блокчейн-защищённой» она ни выглядела.

1.12 Ответы на частые вопросы

❓ А что если хакеры взломают сервер?

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

❓ А что если вирус на моём телефоне изменит голос?

Для этого есть «Benaloh Challenge»: перед отправкой вы можете попросить систему «раскрыть» голос и проверить, что он зашифрован правильно. Раскрытый голос уничтожается, вы создаёте новый. Вирус не знает, какой голос вы проверите, поэтому не может подменять выборочно.

❓ Мой голос анонимен?

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

❓ Могу ли я продать свой голос?

Нет. Вы не можете доказать покупателю, за кого проголосовали — квитанция не раскрывает содержимого. Плюс вы можете переголосовать после «продажи».

❓ Что если меня заставят голосовать под угрозой?

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

❓ Как я узнаю, что мой голос учтён?

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

❓ Что если интернет отключат?

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

❓ А если интернет очень плохой и постоянно пропадает?

Поэтому голосование не должно длиться “один час”. Надёжная система проектируется на несколько дней, чтобы вы могли проголосовать тогда, когда связь появилась (и проверить публикацию по квитанции позже). Практическое правило: голосуйте заранее, не в последний вечер. Если онлайн недоступен совсем — остаётся голосование на участке.

❓ Можно ли проголосовать на участке, если я уже голосовал онлайн?

В гибридной модели — да. Как правило, бумажный голос имеет приоритет и отменяет онлайн-голос. Это важно и для доверия, и как защита от принуждения: если вас заставили проголосовать онлайн, вы можете прийти на участок и “перекрыть” этот голос.

❓ Как проверить, что я не на фейковом сайте и что приложение настоящее?

Надёжная система использует несколько уровней защиты: официальные домены, прозрачность сертификатов (certificate transparency), заранее опубликованные отпечатки (fingerprints) ключей/релизов и независимые каналы подтверждения (официальные объявления, зеркала наблюдателей). Если “официальность” нельзя проверить независимо — это красный флаг.

❓ Кто увидит, за кого я голосовал?

Никто. Голоса расшифровываются не по одному, а суммарно. Результат — «Кандидат А: 15 млн голосов», а не «Иванов голосовал за А».

1.13 Блокчейн в системе выборов — что это и зачем

Вы наверняка слышали слово «блокчейн» в контексте электронного голосования. Давайте разберёмся, что это и как оно используется.

Что такое блокчейн простыми словами

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

• Виден всем участникам
• Невозможно стереть или изменить
• Связан с предыдущими записями криптографически

Аналогия: представьте, что 100 нотариусов одновременно записывают каждую сделку. Чтобы подделать запись, нужно договориться с более чем 50 из них. Это практически невозможно.

Нужен ли блокчейн для выборов?

Короткий ответ: Блокчейн может быть полезен, но он не является главным. Главное — криптография.

Что блокчейн ДЕЛАЕТ:

• Гарантирует, что записанные голоса невозможно удалить или изменить
• Создаёт независимую временную метку (таймстамп)
• Позволяет множеству независимых организаций вести одну и ту же базу данных

Что блокчейн НЕ ДЕЛАЕТ:

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

Как блокчейн используется в нашей системе

Важно понимать: «Блокчейн» часто используется как маркетинговое слово. Система Voatz (США) заявляла о «блокчейн-защите», но была признана небезопасной. Настоящая защита — в криптографических протоколах, а не в модных словах.

1.14 Итоговая памятка: как отличить надёжную систему от ненадёжной

✅ Признаки надёжной системы:

• ☑️ Открытый исходный код — весь код опубликован, любой может проверить
• ☑️ Независимые аудиты — минимум 3 разных организации проверили код и протоколы
• ☑️ E2E-V (End-to-End Verifiability) — вы можете проверить свой голос, любой может проверить подсчёт
• ☑️ Пороговая криптография — ключ разделён между независимыми организациями (5 из 9 и т.д.)
• ☑️ Публичная доска — все зашифрованные голоса и доказательства публично доступны
• ☑️ Переголосование — можно изменить голос до окончания выборов
• ☑️ Бумажный fallback — можно проголосовать на участке, отменив электронный голос
• ☑️ Bug Bounty — публичная программа поиска уязвимостей с вознаграждениями

❌ Красные флаги — признаки ненадёжной системы:

• ⚠️ Закрытый код — «наш код секретный для безопасности» — это ложь
• ⚠️ Нет независимых аудитов — или аудиты проведены «карманными» компаниями
• ⚠️ Невозможно проверить свой голос — «просто доверьтесь нам»
• ⚠️ Единый оператор с полным контролем — нет разделения ключей
• ⚠️ «Блокчейн-защита» без деталей — маркетинг вместо криптографии
• ⚠️ Нет публичной доски — результаты нельзя независимо проверить
• ⚠️ Невозможно переголосовать — нет защиты от принуждения
• ⚠️ Нет бумажного варианта — система принудительно только электронная

Золотое правило: если вам говорят «доверьтесь» вместо «проверьте» — это плохая система.

Часть II: Криптографические основы

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

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

Зачем нужно

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

Как работает (концептуально)

Пусть E(x) — зашифрованное значение x. Гомоморфное шифрование обладает свойством:

E(a) ⊕ E(b) = E(a + b)

То есть результат операции над шифротекстами равен шифротексту результата операции над открытыми текстами.

Для голосования это означает: если каждый голос за кандидата A представлен как «1», а за других — как «0», то сумма всех зашифрованных голосов даст зашифрованное количество голосов за A. Расшифровав только итоговую сумму, мы узнаём результат, не раскрывая индивидуальных голосов.

От “простого” бюллетеня к реальному: что меняется

В примере выше бюллетень бинарный (“0 или 1 за кандидата A”). В реальных выборах бюллетени часто сложнее — и это влияет на стоимость криптографии и дизайн доказательств:

• Один выбор из N кандидатов (plurality): бюллетень — это вектор из N значений, где ровно одно значение равно 1, остальные 0. Нужно доказать в ZKP, что “ровно один выбран”.
• Партийные списки / несколько выборов в одном бюллетене: появляется несколько независимых “подбюллетеней” и несколько наборов ограничений (“ровно один”, “не более K” и т.д.).
• Рейтинговое голосование / предпочтения (ranked-choice): доказательства становятся заметно сложнее (нужно доказать корректность перестановки/рангов, отсутствие повторов, допустимый диапазон). Это сильнее увеличивает размер и время проверки ZKP.
• Порог “не более K” (например, выбрать до 3 кандидатов): вместо “ровно один” нужно доказать ограничение на сумму.

Вывод: “гомоморфное шифрование + ZKP” работает для большинства типов бюллетеней, но сложность бюллетеня напрямую превращается в вычислительную и организационную стоимость (размер доказательств, время проверки, требования к инфраструктуре и аудитам).

Основные схемы

Рекомендация

Для государственных выборов оптимальным выбором на 2025-2026 годы является Exponential ElGamal в сочетании с пороговой криптографией. Эта схема хорошо изучена, имеет эффективные реализации и позволяет создавать доказательства корректности.

Для долгосрочной перспективы следует рассматривать Lattice-based схемы, которые устойчивы к атакам квантовых компьютеров.

2.2 Доказательства с нулевым знанием (Zero-Knowledge Proofs)

Концепция

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

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

Применения в избирательных системах

1. Доказательство корректности голоса: голос содержит допустимое значение (0 или 1, только один кандидат выбран)
2. Доказательство корректности шифрования: шифрование выполнено правильно
3. Доказательство корректности расшифровки: расшифровка выполнена честно
4. Доказательство корректного перемешивания: mix-net не изменил голоса

Какие ZKP реально нужны в протоколе голосования (карта “где и зачем”)

В e-voting ZKP используются не “один раз”, а как связка доказательств на разных этапах. Типовой набор выглядит так:

• Well-formed ballot proof (валидность бюллетеня): доказывает, что зашифрованный бюллетень удовлетворяет правилам (ровно один выбор, не более K, корректные ранги и т.д.), не раскрывая выбор.
• Proof of correct encryption / consistency: доказывает, что шифротекст корректно сформирован (например, относится к нужной группе/параметрам) и связан с публичным ключом выборов.
• Shuffle proof (для mix-net): доказывает, что выход миксера — это честная перестановка и перешифрование входа (без удаления/добавления/подмены бюллетеней).
• Proofs for partial decryption (пороговая расшифровка): каждый держатель доли ключа публикует частичную расшифровку и доказательство, что она корректна.
• Proof of correct tally / homomorphic aggregation: доказывает, что объявленный результат соответствует данным на доске (либо через проверку корректности агрегации, либо через проверку корректности расшифровки агрегатов).

Ключевая идея: ZKP превращает “нам сказали, что всё честно” в “любой может проверить, что этап выполнен корректно”, а значит переносит доверие с людей на математику и публичные артефакты.

Сравнение ZKP-систем

Рекомендация

Для избирательных систем оптимальны Sigma-протоколы (Schnorr, Chaum-Pedersen). Они:

• Не требуют trusted setup
• Имеют простую и проверенную математику
• Достаточно эффективны для реальных приложений
• Легко интегрируются с ElGamal-шифрованием

Для сложных доказательств (например, сложных бюллетеней с рейтинговым голосованием) можно использовать PLONK или zk-STARKs.

2.3 Схемы разделения секрета

Проблема единой точки отказа

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

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

Схема Шамира (Shamir’s Secret Sharing)

Принцип: секрет кодируется как свободный член полинома степени (t-1). Каждый участник получает точку на этом полиноме. Для восстановления секрета требуется минимум t точек (через интерполяцию Лагранжа).

Пример: Секретный ключ делится на 7 частей (для 7 независимых организаций). Порог — 4. Это значит:

• Любые 4 из 7 организаций могут совместно расшифровать результаты
• 3 или менее — не могут
• Если 3 организации скомпрометированы, секрет всё ещё защищён

Пороговая криптография

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

Алгоритм пороговой расшифровки:

1. Каждая из t сторон вычисляет частичную расшифровку
2. Каждая сторона публикует доказательство корректности своей частичной расшифровки
3. Частичные расшифровки комбинируются публично
4. Полный секретный ключ никогда не существует в одном месте

Distributed Key Generation (DKG)

Возникает вопрос: как изначально создать разделённый ключ без доверенной стороны?

DKG-протоколы позволяют нескольким сторонам совместно сгенерировать ключевую пару так, что:

• Публичный ключ известен всем
• Секретный ключ никогда не существует целиком — только доли у участников

Классические протоколы: Pedersen DKG, Gennaro DKG, FROST.

Рекомендация

Для государственных выборов: пороговая схема (t, n) с параметрами, например:

• n = 7-9 независимых держателей ключей (представители разных партий, гражданского общества, международных наблюдателей)
• t = порог 50%+1 (например, 4 из 7 или 5 из 9)
• Использовать DKG для генерации ключей
• Требовать публикации доказательств корректности на каждом этапе

2.4 Слепые подписи (Blind Signatures)

Проблема авторизации без идентификации

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

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

Как работает (концептуально)

1. Избиратель «ослепляет» свой голос (применяет математическое преобразование)
2. Сервер подписывает ослеплённый голос (убедившись, что избиратель имеет право голоса)
3. Избиратель «снимает ослепление» и получает действительную подпись на своём голосе
4. Голос с подписью отправляется анонимно

Критически важно: сервер подписал голос, но не знает его содержимого. Сервер знает, что избиратель Иванов получил подпись, но не знает, на каком голосе эта подпись стоит.

Как предотвратить двойное голосование и при этом сохранить анонимность

Слепая подпись решает “подписать, не видя содержимого”, но сама по себе не решает две практические задачи: (1) не дать проголосовать дважды, (2) поддержать переголосование/отзыв, не связав личность с бюллетенем.

Типовые принципы проектирования выглядят так:

• Разделение ролей: сервер регистрации/авторизации проверяет право голоса и выдаёт право на голосование (credential), сервер приёма голосов принимает бюллетени и проверяет их корректность, но не знает личность.
• Уникальность без личности: credential содержит (или позволяет вывести) уникальный “тэг”, который не раскрывает личность, но позволяет системе обнаружить повторное использование. То есть тэг “связывается сам с собой”, но не “связывается с человеком”.
• Список использованных прав (spent list): при получении бюллетеня система проверяет, что credential/тэг ещё не использован (или что этот бюллетень — “последний” при разрешённом переголосовании).
• Переголосование (если предусмотрено): правило должно быть формализовано: либо принимаются все бюллетени с одним тэгом, но в подсчёт попадает только “последний по времени закрытия/порядку”, либо действует иной публичный критерий. Главное — чтобы правило можно было проверить независимо по данным на доске.

Важно: детали (как именно устроен тэг, как обеспечивается “последний голос”, как устроен отзыв/аннулирование) зависят от выбранного протокола. Но в любом случае система должна публиковать достаточно данных, чтобы наблюдатели могли проверить: (а) двойные бюллетени обработаны по правилам, (б) лишние голоса не добавлены.

Типы слепых подписей

Рекомендация

Для современных систем — Schnorr или BLS blind signatures. Они эффективнее RSA и хорошо интегрируются с другими криптографическими компонентами на эллиптических кривых.

2.5 Commitment-схемы и аудируемость

Зачем нужны

Commitment-схема позволяет «зафиксировать» значение так, что:

• Binding: автор не может изменить зафиксированное значение после публикации
• Hiding: никто не может узнать значение до раскрытия

В избирательных системах commitments используются для:

1. Фиксации зашифрованных голосов до окончания голосования
2. Создания аудиторского следа
3. Построения Merkle-деревьев для эффективной верификации

Pedersen Commitment

Формула: C = g^m * h^r, где m — значение, r — случайность, g и h — генераторы группы.

Свойства:

• Информационно-теоретический hiding (невозможно взломать даже с бесконечными вычислительными ресурсами)
• Вычислительный binding (защищён, пока не решена проблема дискретного логарифма)
• Аддитивная гомоморфность: C(a) * C(b) = C(a + b)

Hash-based Commitments

Простейшая схема: C = H(m || r), где H — криптографическая хеш-функция.

Применение: более простые случаи, когда не требуется гомоморфность.

Merkle Trees

Структура данных, которая позволяет:

• Эффективно «зафиксировать» большой набор данных одним хешем (корнем дерева)
• Доказать включение конкретного элемента в набор через короткий «путь» доказательства

Применение в выборах:

1. Все зашифрованные голоса образуют листья Merkle-дерева
2. Корень дерева публикуется
3. Избиратель может получить Merkle-proof, доказывающий, что его голос включён в дерево
4. Изменение любого голоса изменит корень — подлог обнаружится

Рекомендация

Использовать Pedersen commitments для голосов (благодаря гомоморфности) и Merkle trees для создания публичного аудиторского следа. Корень Merkle-дерева может публиковаться, например, в блокчейне для неизменяемости.

2.6 Миксеры (Mix-Networks)

Проблема: traffic analysis

Даже если голоса зашифрованы, злоумышленник может отслеживать, какой голос от какого избирателя поступил (по времени, IP-адресу, порядку). Это нарушает анонимность.

Mix-networks решают эту проблему: набор зашифрованных голосов проходит через несколько «миксеров», которые перемешивают их так, что связь между входом и выходом невозможно установить.

Типы миксеров

Verifiable Shuffle

Критическая проблема миксеров: как убедиться, что миксер честно перемешал голоса, а не подменил их?

Verifiable shuffle — протокол, в котором миксер публикует доказательство с нулевым знанием, что выходные данные — это корректная перестановка входных данных.

Ключевые алгоритмы:

• Neff shuffle: эффективный verifiable shuffle для ElGamal
• Wikström shuffle: улучшенная версия с лучшими доказательствами
• Bayer-Groth shuffle: субlinear proof size

Рекомендация

Использовать Re-encryption Mix-net с Wikström или Bayer-Groth shuffle proofs. Это обеспечивает:

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

Часть III: Архитектура системы

3.1 Структуры данных

Bulletin Board (Публичная доска)

Центральный элемент E2E-V системы — публичная доска объявлений. Это append-only хранилище, куда записываются:

• Все зашифрованные голоса
• Все доказательства корректности
• Действия избирательной комиссии
• Промежуточные результаты миксеров
• Итоговая расшифровка

Требования к Bulletin Board:

Split-view (equivocation): самая опасная атака на “публичную доску”

Фраза “всё публикуется на доске” звучит убедительно, но есть тонкий класс атак: split-view (или equivocation). Суть: злоумышленник пытается показывать разным людям разные версии публичной доски — например, в одной версии ваш голос “есть”, а в другой (для наблюдателей) — “нет”, или наоборот.

Почему это важно: без защиты от split-view система может создавать иллюзию прозрачности, оставаясь манипулируемой на уровне “кто какую реальность видит”.

Типовые меры защиты:

• Независимые зеркала + сравнение: доска публикуется одновременно несколькими независимыми организациями (наблюдатели, партии, университеты). Любой может сравнить, совпадают ли данные.
• Подписанные “чекпойнты” состояния: периодически публикуется Merkle root/хеш состояния, подписанный несколькими независимыми ключами (кворумом). Это усложняет ведение “двух журналов”.
• Witness / transparency подход: отдельные “свидетели” (witnesses) подписывают увиденные ими чекпойнты и распространяют их. Несовпадения быстро обнаруживаются.
• Консенсус между операторами (BFT): если доска ведётся консорциумом, то запись считается принятой только после подтверждения кворумом узлов, что предотвращает “двойные ветки” в нормальном режиме.

Практический критерий: у надёжной системы должно быть так, чтобы любой наблюдатель мог убедиться, что все видят одну и ту же доску, а не просто “довериться сайту”.

Immutable Log

Техническая реализация append-only хранилища:

1. Hash chain: каждая запись содержит хеш предыдущей записи
2. Подписи: каждая запись подписана автором
3. Merkle tree: периодические «снимки» состояния
4. Репликация: множество независимых зеркал

Интеграция с блокчейном

Блокчейн может использоваться как:

1. Anchor: корни Merkle-деревьев публикуются в публичный блокчейн (Bitcoin, Ethereum) для неизменяемой временной метки
2. Полный Bulletin Board: все данные хранятся в блокчейне (требует private/permissioned blockchain из-за объёма)

Когда блокчейн нужен:

• Нет доверия к единому оператору
• Требуется децентрализованное хранение
• Важна независимая временная метка

Когда блокчейн НЕ нужен:

• Есть доверенный консорциум операторов
• Достаточно репликации и подписей
• Критична производительность

3.2 Блокчейн в избирательных системах: детальный анализ

Типы консенсуса для выборов

Рекомендация: Для государственных выборов — BFT-консенсус (например, Tendermint, HotStuff) между независимыми организациями (ЦИК, партии, наблюдатели, международные организации).

Архитектура блокчейн-компонента

1. Публичная часть: корни Merkle-деревьев, хеши ключевых документов — в публичном блокчейне (Ethereum, Bitcoin)
2. Приватная часть: полные данные голосования — в permissioned blockchain или традиционной системе с репликацией
3. Верификация: любой может проверить соответствие приватных данных публичным якорям

3.3 Протокол голосования: пошаговый алгоритм

Фаза 0: Подготовка (за месяцы до выборов)

1. Определение держателей ключей: выбор независимых организаций для пороговой криптографии
2. Distributed Key Generation: совместная генерация ключевой пары без единой точки доверия
3. Публикация публичного ключа: ключ для шифрования голосов становится общедоступным
4. Аудит кода: независимые аудиторы проверяют исходный код
5. Тестовые выборы: пробные голосования для проверки системы

Важное усиление для гос-уровня: “подготовка” — это не только генерация ключа. Должны существовать формализованные церемонии и публичные артефакты, иначе доверие снова превращается в “поверьте нам”. Типовой набор:

• Key ceremony (DKG/HSM): регламентированная церемония генерации ключа с протоколированием, участием наблюдателей и публикацией артефактов (протоколы, подписи, публичные параметры).
• Публикация отпечатков (fingerprints): публичные ключи, параметры групп/кривых/хеш-функций, версии протокола — публикуются заранее и “замораживаются” (чтобы нельзя было тихо поменять математику на другую).
• Прозрачность релизов клиента/верификатора: должны быть опубликованы исходники, хеши релизов и способ независимой проверки того, что бинарник соответствует исходникам (воспроизводимые сборки).
• Независимые реализации: минимум один независимый верификатор (от другой организации/команды) — чтобы “проверка” не зависела от одной программы.

Фаза 1: Регистрация избирателей

1. Идентификация: избиратель подтверждает личность (eID, BankID, Дія и т.д.)
2. Проверка права голоса: система проверяет наличие в реестре избирателей
3. Выдача credential: избиратель получает криптографический токен, позволяющий проголосовать один раз
4. Разрыв связи: механизм слепых подписей или аналогичный для отвязки credential от личности

Фаза 2: Голосование

1. Выбор: избиратель делает выбор в интерфейсе
2. Шифрование: клиентское устройство шифрует голос публичным ключом выборов
3. Создание ZKP: генерируется доказательство корректности голоса (допустимое значение)
4. Подписание: голос подписывается credential избирателя
5. Отправка: зашифрованный голос с доказательством отправляется на сервер
6. Проверка: сервер проверяет ZKP и credential (но не может расшифровать голос)
7. Публикация: зашифрованный голос публикуется на Bulletin Board
8. Квитанция: избиратель получает криптографическую квитанцию для проверки

Фаза 3: Завершение и подсчёт

1. Закрытие: в установленное время приём голосов прекращается
2. Фиксация: финальный Merkle root публикуется, в том числе в публичном блокчейне
3. Перемешивание: голоса проходят через mix-network с публикацией shuffle proofs
4. Пороговая расшифровка: держатели ключей совместно расшифровывают результаты
5. Публикация доказательств: все доказательства корректности расшифровки публикуются
6. Объявление результатов: итоги публикуются вместе со всеми данными для аудита

Фаза 4: Верификация (бессрочно)

1. Индивидуальная проверка: каждый избиратель может проверить свой голос по квитанции
2. Универсальная проверка: любой желающий может проверить корректность всех операций
3. Независимый пересчёт: при наличии всех данных любой может пересчитать результаты

3.4 Системы верификации: детальный разбор

Individual Verifiability (Cast-as-Intended + Recorded-as-Cast)

Механизм квитанций:

1. После шифрования голоса вычисляется его хеш (или commitment)
2. Хеш отображается избирателю и/или отправляется на email/телефон
3. Избиратель может найти этот хеш на публичной доске
4. Если хеш найден — голос записан

Benaloh Challenge (проверка корректности шифрования):

1. Избиратель создаёт зашифрованный голос
2. Перед отправкой может потребовать «вскрыть» его (reveal randomness)
3. Если вскрытие показывает корректное шифрование — система честна
4. Вскрытый голос уничтожается, создаётся новый
5. Система не знает заранее, какой голос будет проверен

Universal Verifiability (Tallied-as-Recorded)

Любой наблюдатель может проверить:

1. Все ZKP голосов: каждый голос содержит допустимое значение
2. Shuffle proofs: миксеры честно перемешали голоса
3. Decryption proofs: расшифровка выполнена корректно
4. Математика подсчёта: сумма расшифрованных голосов соответствует заявленным результатам

Публичный аудит-инструментарий:

• Открытые verifier-программы (референсные реализации)
• Полные данные в машиночитаемом формате
• Документация форматов и протоколов
• Инструкции по независимой проверке

Независимость верификации: почему одного “официального” верификатора недостаточно

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

• Несколько независимых реализаций: минимум 2–3 верификатора от разных команд (например, государственная команда, университетская команда, независимая NGO/компания).
• Фиксация входных данных: верификаторы должны работать на одних и тех же публичных данных (с чётко определёнными форматами и версиями протокола).
• Воспроизводимый результат: независимые пересчёты должны сходиться — и это становится публичным фактом, а не внутренним отчётом.

Dispute resolution: что делать при обнаружении несоответствий

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

1. Фиксация артефактов: публикуются текущие чекпойнты (подписанные хеши состояния доски), чтобы “заморозить” предмет спора.
2. Сверка между независимыми источниками: сравнение журналов/чекпойнтов разных зеркал. Если обнаружен split-view — это автоматически критический инцидент.
3. Публичное воспроизведение ошибки: любой желающий должен суметь воспроизвести несоответствие на публичных данных (это отличает “математическую ошибку” от “нам показалось”).
4. Регламент решения: заранее определены правила (например, продление голосования, переключение на резервный канал, аннулирование конкретного периода/сегмента) и юридическая процедура оспаривания.

Принцип: спор решается публичными проверяемыми данными, а не закрытыми внутренними логами.

3.5 Мониторинг в реальном времени

Dashboard для наблюдателей

Во время голосования публично доступны (в реальном времени):

• Количество поданных голосов (по регионам, времени)
• Количество отклонённых голосов (с причинами)
• Статус компонентов системы
• Хеши последних блоков данных

НЕ доступны до окончания голосования:

• Промежуточные результаты
• Распределение голосов

Статистические методы обнаружения аномалий

Автоматические алерты

Система должна автоматически уведомлять о:

• Необычно высокой/низкой активности
• Массовых отклонениях голосов
• Технических сбоях компонентов
• Попытках неавторизованного доступа

Часть IV: Все угрозы и методы защиты

4.1 Модель угроз

Для государственных выборов следует исходить из worst-case сценария:

• Атакующий имеет государственные ресурсы
• Атакующий может контролировать отдельные компоненты системы
• Атакующий может подкупать или принуждать инсайдеров
• Атакующий имеет мотивацию потратить значительные ресурсы

Цели атакующего:

1. Изменить результаты (добавить/убрать голоса)
2. Нарушить анонимность (узнать, как голосовали конкретные люди)
3. Сорвать выборы (сделать результаты недействительными)
4. Подорвать доверие (создать видимость нечестности)

4.2 Технические угрозы

4.2.1 Атаки на клиентское устройство

Benaloh Challenge подробнее:

Это ключевой механизм защиты от malware. Идея:

1. Клиент создаёт голос и показывает commitment
2. Избиратель может «бросить вызов» — потребовать раскрыть randomness
3. Если раскрытие корректно, значит шифрование честное
4. Раскрытый голос не отправляется (он скомпрометирован)
5. Избиратель создаёт новый голос и отправляет его

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

Supply-chain и подмена клиента: когда “взломали не вас, а путь до вас”

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

• Компрометация канала распространения: подмена в магазине приложений, подмена ссылок на скачивание, компрометация CDN.
• Подмена JavaScript/ресурсов: для веб-клиента достаточно подменить один скрипт, чтобы изменить выбор до шифрования.
• Компрометация зависимостей: “невинное” обновление библиотеки может внедрить вредоносный код в цепочку сборки.

Типовые меры защиты:

• Воспроизводимые сборки (reproducible builds): независимые организации могут собрать приложение из исходников и получить тот же бинарник/хеш.
• Прозрачность релизов: публикация хешей релизов, подписей и журналов обновлений (чтобы нельзя было “тихо” выдать разным людям разные версии).
• Защита веб-клиента: строгая политика загрузки ресурсов (CSP), Subresource Integrity (SRI) для скриптов, минимизация внешних зависимостей.
• Независимый “проверяющий клиент”: возможность проверить результат шифрования/квитанцию вторым устройством/каналом снижает риск “одна программа вас обманула”.

4.2.2 Атаки на серверную инфраструктуру

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

Самая практическая серверная угроза: реестр и выдача полномочий (eligibility)

Криптография защищает бюллетени, но право голосовать приходит из внешнего мира: реестр избирателей, идентификация (eID/BankID), процессы выдачи credential. Если здесь произошла атака или ошибка, система может честно “криптографически” подсчитать не тот набор людей.

Типовые сценарии:

• Массовая ошибочная/злонамеренная выдача credential: “лишние” полномочия появляются до этапа шифрования и выглядят в протоколе как валидные.
• Компрометация провайдера идентификации: атаки на аккаунты, SIM-swap/соц-инженерия, сбои интеграции.
• Манипуляции реестром: ошибки данных, несвоевременные обновления, внесение “мертвых душ” или удаление групп.

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

4.2.3 Сетевые атаки

Метаданные как угроза приватности

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

• сопоставлять события голосования с конкретными людьми (особенно в малых группах или при наблюдении на стороне провайдера),
• выделять “аномальные” группы избирателей,
• проводить targeted denial-of-vote (блокировки) против конкретных регионов/операторов/каналов.

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

4.2.4 Denial of Service

Специальные меры для выборов:

• Заблаговременное тестирование нагрузки (минимум 10x ожидаемого пика)
• Резервные каналы связи
• Возможность продления голосования при технических сбоях
• Оффлайн-резервы для критических компонентов

Denial-of-vote: “не дать проголосовать” как политическая атака

Для выборов очень опасна не только “перегрузка”, но и целевые сценарии: блокировки по провайдерам, по регионам, по типам устройств, отключение мобильного интернета, цензура доменов, деградация DNS. Это может бить по конкретным группам избирателей и искажать явку.

Типовые меры:

• Длинное окно голосования: несколько дней снижает эффект кратковременных блокировок.
• Альтернативные каналы: офлайн-участки/бумажный fallback, резервные домены/точки входа, заранее опубликованные официальные адреса.
• Публичный мониторинг доступности: независимые наблюдатели измеряют доступность из разных сетей/стран и публикуют отчёты.
• Юридический регламент: заранее описано, при каком уровне недоступности автоматически продлевается голосование или включается резервный канал.

4.2.5 Side-channel атаки

4.3 Организационные угрозы

4.3.1 Компрометация должностных лиц

Угроза: члены избирательной комиссии, администраторы системы или держатели ключей действуют злонамеренно.

Защита:

• Пороговая криптография: нужно скомпрометировать t из n участников
• Разделение обязанностей: никто не имеет полного контроля
• Прозрачность: все действия записываются и верифицируемы
• Независимость: держатели ключей из разных организаций с конфликтующими интересами

4.3.2 Коллюзия (сговор)

Угроза: несколько независимых участников договариваются действовать злонамеренно.

Защита:

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

4.3.3 Атака на процессы

Угроза: манипуляции не с технологией, а с процедурами вокруг неё.

Примеры:

• Намеренное создание технических проблем для определённых групп избирателей
• Распространение дезинформации о работе системы
• Атака на процесс аудита

Защита:

• Чёткие, заранее опубликованные процедуры
• Множество независимых каналов информации
• Обучение избирателей
• Горячая линия поддержки

4.4 Социальная инженерия и манипуляции

4.4.1 Coercion (принуждение)

Проблема: злоумышленник заставляет избирателя голосовать определённым образом и требует доказательство.

Это фундаментальная проблема удалённого голосования: в отличие от кабинки на участке, дома никто не гарантирует, что избиратель один.

Технические решения:

Эстонская модель: избиратель может голосовать многократно, учитывается последний голос. Также доступно голосование на участке (бумажное), которое перекрывает электронное. Это позволяет «отменить» голос, поданный под принуждением.

4.4.2 Vote buying (скупка голосов)

Проблема: избиратель продаёт свой голос и должен доказать покупателю, как он проголосовал.

Защита:

• Receipt-freeness: избиратель не может получить доказательство своего голоса, которое мог бы показать третьей стороне
• Переголосование: даже если покупатель видел процесс, избиратель может переголосовать позже
• Невозможность связи: квитанция не раскрывает содержимое голоса

Важно: система должна балансировать между verifiability (избиратель может проверить свой голос) и receipt-freeness (избиратель не может доказать свой голос третьему лицу). Это сложная задача.

4.4.3 Манипуляции и дезинформация

4.5 Проблема «последней мили»

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

• Изменить голос до шифрования
• Записать выбор пользователя
• Заблокировать голосование

Подходы к решению

Trusted Execution Environments (TEE)

TEE (Intel SGX, ARM TrustZone, AMD SEV) — технологии, создающие изолированную среду выполнения, защищённую даже от ОС.

Преимущества:

• Код выполняется в защищённом «анклаве»
• Даже root-доступ не позволяет вмешаться
• Возможна remote attestation (доказательство, что запущен правильный код)

Проблемы:

• Не все устройства поддерживают
• Известны side-channel атаки на SGX
• Доверие переносится на производителя чипа

Hardware Security Modules (HSM)

Для серверной части: критические криптографические операции (хранение долей ключей, подписание) выполняются в сертифицированных HSM.

Требования:

• Сертификация FIPS 140-2 Level 3 или выше
• Физическая защита от вскрытия
• Аудируемость операций

Часть V: Практические кейсы

5.1 Эстония: i-Voting

Эстония — единственная страна, где интернет-голосование используется на национальных выборах с 2005 года.

Как работает

1. Идентификация: через eID-карту или Mobile-ID (криптографическая идентификация)
2. Голосование: через специальное приложение
3. Шифрование: голос шифруется публичным ключом выборов
4. Подпись: зашифрованный голос подписывается личным сертификатом избирателя
5. Переголосование: можно голосовать многократно, учитывается последний голос
6. Бумажный приоритет: голос на участке отменяет электронный
7. Расшифровка: после снятия подписей (анонимизации) голоса расшифровываются

Статистика

• Парламентские выборы 2023: 51% голосов подано онлайн
• Более 15 лет использования без доказанных успешных атак на результаты

Плюсы

• Удобство для избирателей (особенно диаспоры)
• Высокое доверие населения
• Экономия на организации участков
• Защита от coercion через переголосование

Критика и уязвимости

• Client-side malware: нет полной защиты от вредоносного ПО на устройстве пользователя
• Связь голоса с личностью: на этапе до снятия подписей технически возможно связать голос с избирателем (требует сговора нескольких операторов)
• Закрытый исходный код: долгое время код не был полностью открыт (частично исправлено)
• Отчёт 2014 года: независимые исследователи указали на серьёзные уязвимости в операционных процедурах

Уроки

1. Работающая система возможна, но требует зрелой цифровой инфраструктуры (eID)
2. Переголосование — эффективная защита от coercion
3. Нужен полностью открытый исходный код и независимые аудиты
4. Операционная безопасность так же важна, как криптография

5.2 Швейцария: CHVote

История

Швейцария экспериментировала с электронным голосованием с 2004 года. Несколько кантонов использовали различные системы.

CHVote (Женева)

• Разработана государством (не частной компанией)
• Полностью открытый исходный код
• End-to-end verifiability
• Использовала ElGamal + Mix-nets + ZKP

Почему приостановлен (2019)

1. Обнаруженные уязвимости: в ходе публичного аудита найдены криптографические недостатки
2. Политическое решение: федеральное правительство ужесточило требования
3. Стоимость: доработка системы признана слишком дорогой

Уроки

1. Открытый исходный код и публичный аудит работают — уязвимости были найдены
2. Высокие требования к E2E-V оправданы
3. Государственная разработка не гарантирует качество

5.3 Helios Voting

Обзор

• Академическая система с открытым исходным кодом
• Разработана Ben Adida (2008)
• Используется для выборов в университетах, профессиональных организациях
• Полная E2E-V

Технические особенности

• ElGamal шифрование
• Homomorphic tallying (подсчёт без расшифровки отдельных голосов)
• ZKP корректности голосов
• Публичный Bulletin Board
• Benaloh Challenge для cast-as-intended верификации

Ограничения

• Не решает проблему coercion (нет переголосования)
• Не предназначена для масштаба государственных выборов
• Требует определённой технической грамотности избирателей

Значение

Helios — референсная реализация E2E-V. Многие современные системы основаны на её принципах.

5.4 Voatz

Обзор

• Мобильное приложение для голосования (США)
• Использовало блокчейн и биометрию
• Применялось для голосования военнослужащих и граждан за рубежом в нескольких штатах

Критика

Аудит MIT (2020) выявил серьёзные проблемы:

• Отсутствие E2E-V
• Закрытый исходный код
• Проблемы с идентификацией
• Централизованное хранение данных
• Уязвимости в мобильном приложении

Уроки

1. «Блокчейн» не равно «безопасность»
2. Закрытый код недопустим для выборов
3. Маркетинговые заявления не заменяют криптографические доказательства
4. Мобильные приложения имеют специфические уязвимости

5.5 Другие системы

Belenios (Франция)

• Развитие идей Helios
• Добавлена protection against coercion
• Используется для профессиональных выборов во Франции
• Открытый исходный код
• Формальная верификация критических компонентов

ElectionGuard (Microsoft)

• Открытый SDK для создания E2E-V систем
• Фокус на гибридных системах (бумага + электронная верификация)
• Homomorphic encryption (ElGamal)
• Используется в пилотных проектах в США

Scytl

• Коммерческая компания (Испания)
• Использовалась во многих странах
• Обанкротилась в 2020
• Критиковалась за закрытость и уязвимости

5.6 Сравнительная таблица

Часть VI: Государственные выборы — специфика

6.1 Масштаб и требования

Президентские выборы в стране с населением 35-45 миллионов (типа Украины) предъявляют особые требования:

Баланс доступности и безопасности

Одно из ключевых противоречий:

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

Решение: Уровневая система с выбором:

1. Базовый уровень: Приложение «Дія» с NFC-верификацией ID-карты или BankID
2. Расширенный уровень: Квалифицированная электронная подпись (КЭП)
3. Альтернативный канал: Голосование на физических участках с электронной верификацией

Инклюзивность

Система должна быть доступна для:

• Людей с нарушениями зрения (screen readers, голосовое управление)
• Людей с нарушениями моторики (увеличенные элементы интерфейса, альтернативные методы ввода)
• Пожилых людей (простой интерфейс, телефонная поддержка)
• Людей без смартфонов (веб-интерфейс, публичные терминалы)
• Избирателей за рубежом (работа через VPN, устойчивость к блокировкам)

6.2 Правовые аспекты

Международные стандарты

Базовые правовые принципы

Любая система онлайн-голосования должна обеспечивать:

1. Тайну голосования: невозможность связать голос с личностью
2. Свободу волеизъявления: защита от принуждения
3. Равенство: один избиратель — один голос
4. Всеобщность: доступность для всех имеющих право голоса
5. Прямое голосование: избиратель голосует лично

Необходимые законодательные изменения

Для внедрения системы потребуется:

• Легализация электронного голосования в Избирательном кодексе
• Определение правового статуса криптографических доказательств
• Процедуры аудита и оспаривания результатов
• Ответственность операторов и держателей ключей
• Интеграция с существующим законодательством о электронных документах

6.3 Интеграция с существующими системами

Реестр избирателей

Источник данных: Государственный реестр избирателей.

Интеграция:

1. Синхронизация данных о праве голоса
2. Исключение двойного голосования (онлайн + оффлайн)
3. Обработка изменений (переезд, смерть, достижение совершеннолетия)

Критически важно: Реестр используется только для проверки права голоса. После выдачи credential связь с личностью разрывается через слепые подписи.

Системы идентификации

Рекомендация: Комбинация методов — обязательная идентификация через один из высоконадёжных методов + дополнительная верификация (SMS, email) как второй фактор.

Избирательные комиссии

Роль ЦИК и окружных комиссий в онлайн-системе:

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

6.4 Гибридная модель: онлайн + традиционное голосование

На переходном этапе рекомендуется гибридная модель:

Важное правило (эстонская модель):

• Можно переголосовать онлайн (последний голос имеет силу)
• Бумажный голос на участке отменяет все электронные
• Это защита от coercion: если вас заставили проголосовать онлайн, вы можете прийти на участок и отменить этот голос

Часть VII: Roadmap внедрения

7.1 Этапы создания системы

Этап 1: Исследование и проектирование (12-18 месяцев)

Этап 2: Разработка (18-24 месяца)

Этап 3: Аудит и тестирование (12-18 месяцев)

Этап 4: Пилотное внедрение (12-24 месяца)

Этап 5: Полноценное внедрение

7.2 Общий таймлайн

Реалистичный срок до первых национальных выборов с онлайн-голосованием: 4-6 лет при стабильном финансировании и политической воле.

7.3 Критерии готовности

Технические критерии

• ☐ Минимум 3 независимых криптографических аудита пройдены успешно
• ☐ Открытый исходный код опубликован минимум за 12 месяцев
• ☐ Bug bounty программа работает минимум 12 месяцев
• ☐ Нагрузочные тесты подтверждают 10x запас производительности
• ☐ Penetration testing от минимум 2 независимых компаний
• ☐ Успешные тестовые выборы с независимой верификацией

Публичные артефакты готовности (что должно быть опубликовано заранее)

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

• ☐ Threat model и модель доверия: какие акторы, какие допущения, что система не обещает
• ☐ Спецификация протокола с версионированием (что именно считается “правильным” голосом/журналом/подсчётом)
• ☐ Спецификации форматов данных (схемы JSON/CSV/бинарные форматы, контрольные примеры)
• ☐ Описанная и наблюдаемая key ceremony: регламент, список участников, опубликованные публичные параметры/ключи, подписи и чекпойнты
• ☐ Инструкции по воспроизводимым сборкам (reproducible builds) и опубликованные хеши релизов клиента/верификаторов
• ☐ Минимум 2 независимых реализации верификатора + результаты их независимых прогонов на публичных данных
• ☐ Описанный dispute resolution: что делать при расхождениях, какие данные считаются доказательствами, кто принимает решения

Организационные критерии

• ☐ Законодательная база принята
• ☐ Консорциум держателей ключей сформирован
• ☐ Персонал ЦИК обучен
• ☐ Процедуры аудита и оспаривания документированы
• ☐ Горячая линия поддержки функционирует
• ☐ Информационная кампания проведена

Критерии общественного доверия

• ☐ Пилотные проекты прошли без существенных инцидентов
• ☐ Международные наблюдатели дали положительную оценку
• ☐ Общественные организации провели независимую верификацию
• ☐ Опросы показывают достаточный уровень доверия

7.4 Оценка ресурсов

Примерный бюджет

Для сравнения: Стоимость проведения традиционных выборов для страны с 30-40 миллионами избирателей составляет порядка 100-200 миллионов долларов за один избирательный цикл. Онлайн-система может окупиться за 2-3 цикла при условии частичного перехода.

Команда

• Криптографы: 5-10 человек с PhD в криптографии
• Security-инженеры: 10-15 человек
• Backend-разработчики: 15-20 человек
• Frontend/Mobile-разработчики: 10-15 человек
• DevOps/SRE: 5-10 человек
• QA: 10-15 человек
• Юристы: 3-5 человек
• Менеджмент: 5-10 человек

7.5 Рекомендуемая архитектура для Украины

На основе анализа всех существующих систем, рекомендуется следующая архитектура:

Криптографический стек

• Шифрование: Exponential ElGamal на кривой Curve25519
• ZKP: Sigma-протоколы (Chaum-Pedersen) для доказательств корректности
• Пороговая криптография: (5, 9) схема с DKG
• Слепые подписи: Schnorr blind signatures
• Mix-net: Re-encryption mix-net с Bayer-Groth shuffle proofs
• Hash-функция: SHA-3 или BLAKE3

Инфраструктура

• Bulletin Board: Replicated log с BFT-консенсусом между операторами
• Anchoring: Merkle roots в Ethereum для публичной временной метки
• Идентификация: Дія + NFC ID-карта, BankID как альтернатива
• HSM: FIPS 140-2 Level 3 для держателей ключей

Держатели ключей (9 организаций)

1. Центральная избирательная комиссия
2. Представитель правящей партии/коалиции
3. Представитель оппозиции
4. Общественная организация (например, ОПОРА)
5. Техническая организация (например, университет)
6. Международный наблюдатель (ОБСЕ/БДИПЧ)
7. Международный наблюдатель (Венецианская комиссия)
8. Технический партнёр (независимая IT-компания)
9. Нотариальная служба или аналогичный орган

Порог: 5 из 9 для расшифровки результатов.

7.6 Серверная архитектура для 40 миллионов избирателей

Проектирование инфраструктуры для страны с населением 40 миллионов — отдельная инженерная задача. Основная сложность: экстремально неравномерная нагрузка.

Расчёт нагрузки

Архитектура серверов

┌─────────────────────────────────────────────────────────────────────────────┐
│                           ГЛОБАЛЬНЫЙ УРОВЕНЬ                                │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│                          ┌─────────────────┐                                │
│                          │   CLOUDFLARE /  │                                │
│                          │   AWS SHIELD    │ ← DDoS Protection              │
│                          │   (Anycast DNS) │                                │
│                          └────────┬────────┘                                │
│                                   │                                         │
│         ┌─────────────────────────┼─────────────────────────┐               │
│         │                         │                         │               │
│         ▼                         ▼                         ▼               │
│   ┌───────────┐           ┌───────────┐           ┌───────────┐             │
│   │  CDN EU   │           │ CDN USA   │           │ CDN ASIA  │             │
│   │ (статика) │           │ (статика) │           │ (статика) │             │
│   └───────────┘           └───────────┘           └───────────┘             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                           РЕГИОНАЛЬНЫЙ УРОВЕНЬ                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌────────────────────────────────────────────────────────────────────┐    │
│   │                    LOAD BALANCER (L7)                              │    │
│   │                    (Geographic routing)                            │    │
│   └────────────────────────────────────────────────────────────────────┘    │
│                                   │                                         │
│         ┌─────────────────────────┼─────────────────────────┐               │
│         │                         │                         │               │
│         ▼                         ▼                         ▼               │
│   ┌───────────┐           ┌───────────┐           ┌───────────┐             │
│   │ Регион EU │           │Регион USA │           │Регион ASIA│             │
│   │ (Франкфур)│           │ (Вирджин) │           │(Сингапур) │             │
│   └─────┬─────┘           └─────┬─────┘           └─────┬─────┘             │
│         │                       │                       │                   │
│         └───────────────────────┼───────────────────────┘                   │
│                                 │                                           │
│                                 ▼                                           │
│                    ┌────────────────────────┐                               │
│                    │   ОСНОВНОЙ ДАТА-ЦЕНТР  │                               │
│                    │   (Украина / EU)       │                               │
│                    └────────────────────────┘                               │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│                        ОСНОВНОЙ ДАТА-ЦЕНТР                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │                     API GATEWAY CLUSTER                             │   │
│   │            (20-50 нод, auto-scaling)                                │   │
│   │   • Rate limiting • Authentication • Request validation            │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                                   │                                         │
│         ┌─────────────────────────┼─────────────────────────┐               │
│         │                         │                         │               │
│         ▼                         ▼                         ▼               │
│   ┌───────────────┐       ┌───────────────┐       ┌───────────────┐         │
│   │ AUTH SERVICE  │       │ VOTE SERVICE  │       │ VERIFY SERVICE│         │
│   │ (10-20 нод)   │       │ (30-50 нод)   │       │ (10-20 нод)   │         │
│   │ • Дія API     │       │ • Шифрование  │       │ • ZKP проверка│         │
│   │ • BankID      │       │ • Токены      │       │ • Квитанции   │         │
│   └───────────────┘       └───────┬───────┘       └───────────────┘         │
│                                   │                                         │
│                                   ▼                                         │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │                      MESSAGE QUEUE                                  │   │
│   │         (Kafka / RabbitMQ — 10-20 брокеров)                         │   │
│   │         Буферизация для обработки всплесков                        │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                                   │                                         │
│         ┌─────────────────────────┼─────────────────────────┐               │
│         │                         │                         │               │
│         ▼                         ▼                         ▼               │
│   ┌───────────────┐       ┌───────────────┐       ┌───────────────┐         │
│   │ BULLETIN BOARD│       │  POSTGRESQL   │       │ REDIS CLUSTER │         │
│   │   CLUSTER     │       │   CLUSTER     │       │ (кеширование) │         │
│   │ (BFT-репликац)│       │ (Patroni HA)  │       │               │         │
│   │ 9 независ. нод│       │ 3+ нод        │       │ 6+ нод        │         │
│   └───────────────┘       └───────────────┘       └───────────────┘         │
│                                                                             │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │                         HSM CLUSTER                                 │   │
│   │              Hardware Security Modules                              │   │
│   │         (FIPS 140-2 Level 3, физически изолированы)                │   │
│   │                   9 модулей для 9 держателей                        │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Технологический стек

Параметры масштабирования

Глобальное распределение для диаспоры

Для 5-8 миллионов избирателей за рубежом (Польша, Германия, Чехия, США, Канада и др.):

Важно: региональные ноды только проксируют трафик. Все данные хранятся централизованно для консистентности.

7.7 Оценка рисков и митигация

Матрица рисков

Катастрофические сценарии и “красные кнопки” (что делать, если всё пошло не по плану)

Честная архитектура заранее описывает сценарии, когда выборы нужно останавливать, продлевать или переводить на резервный канал. Типовые критические сценарии:

• Split-view/equivocation обнаружен: разные зеркала/наблюдатели видят разные версии доски.
• Критическая уязвимость клиента/цепочки поставки: выявлено, что приложение/веб-клиент мог менять голос до шифрования.
• Компрометация идентификации/реестра: массовая ошибочная выдача credential или подозрение на захват провайдера идентификации.
• Компрометация доверия сети: атака на DNS/CA/маршрутизацию привела к массовому перехвату или подмене точек входа.
• Компрометация долей ключа/инсайдерский инцидент у держателей ключей: угроза целостности церемонии или раскрытия долей.

Типовой набор немедленных действий:

1. Заморозить состояние: срочно публикуются подписанные чекпойнты (Merkle root/хеши состояния) из всех независимых источников, чтобы зафиксировать “что было”.
2. Публично объявить статус: прозрачное сообщение о типе инцидента и о том, какие операции временно приостановлены (например, приём голосов, публикация новых записей).
3. Переключиться на резерв: если риск влияет на корректность/равенство голосования — активируется бумажный/офлайн канал и/или продление голосования согласно регламенту.
4. Ротация доверенных артефактов: при компрометации клиента/ключей — выпуск новых релизов с новыми хешами, обновление публичных параметров, отзыв скомпрометированных компонентов.
5. Независимая проверка и решение: решение о продолжении/остановке принимается не “внутренне”, а на основе публичных артефактов и независимых отчётов наблюдателей.

SLA и целевые метрики

План реагирования на инциденты

Уровни инцидентов:

• P1 (Критический): Система недоступна, невозможно голосовать → Немедленная эскалация, активация резервного дата-центра
• P2 (Высокий): Деградация производительности >50% → Масштабирование, переключение трафика
• P3 (Средний): Отдельные компоненты сбоят → Перезапуск, замена нод
• P4 (Низкий): Незначительные проблемы → Мониторинг, плановое исправление

Процедура продления голосования:

Если суммарный downtime превышает 4 часа в день голосования — автоматическое продление на следующий день. Решение принимает ЦИК на основе данных мониторинга.

Источники и ссылки

Академические работы

1. Adida, B. (2008). «Helios: Web-based Open-Audit Voting». USENIX Security Symposium.
2. Chaum, D. (1981). «Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms». Communications of the ACM.
3. Benaloh, J. (2006). «Simple Verifiable Elections». USENIX/ACCURATE Electronic Voting Technology Workshop.
4. Groth, J. (2010). «A Verifiable Secret Shuffle of Homomorphic Encryptions». Journal of Cryptology.
5. Shamir, A. (1979). «How to Share a Secret». Communications of the ACM.
6. Pedersen, T. (1991). «Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing». CRYPTO.
7. Bayer, S., Groth, J. (2012). «Efficient Zero-Knowledge Argument for Correctness of a Shuffle». EUROCRYPT.
8. Neff, A. (2001). «A Verifiable Secret Shuffle and its Application to E-Voting». ACM CCS.
9. Wikström, D. (2009). «A Commitment-Consistent Proof of a Shuffle». ACISP.
10. Cortier, V., Galindo, D., Glondu, S., Izabachène, M. (2014). «Election Verifiability for Helios under Weaker Trust Assumptions». ESORICS.

Технические стандарты и рекомендации

1. Council of Europe. Recommendation CM/Rec(2017)5 on standards for e-voting.
2. OSCE/ODIHR. Handbook for the Observation of New Voting Technologies.
3. Venice Commission. Code of Good Practice in Electoral Matters.
4. NIST. Voluntary Voting System Guidelines (VVSG).
5. Common Criteria. Protection Profiles for Voting Systems.

Исследования и отчёты

1. Halderman, J.A. et al. (2014). «Security Analysis of the Estonian Internet Voting System». CCS.
2. Specter, M., Koppel, J., Weitzner, D. (2020). «The Ballot is Busted Before the Blockchain: A Security Analysis of Voatz». USENIX Security.
3. Swiss Post. (2019). «Public Intrusion Test on the Swiss Post E-Voting System».
4. Estonian National Electoral Committee. Internet Voting in Estonia technical documentation.

Действующие системы и их документация

1. Helios Voting: https://heliosvoting.org/
2. Belenios: https://www.belenios.org/
3. ElectionGuard: https://www.electionguard.vote/
4. i-Voting (Estonia): https://www.valimised.ee/en/internet-voting/internet-voting-estonia

Криптографические библиотеки

1. libsodium: https://libsodium.gitbook.io/
2. Microsoft SEAL (homomorphic encryption): https://github.com/microsoft/SEAL
3. Verificatum (mix-net): https://www.verificatum.org/

Заключение

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

1. End-to-End Verifiability: каждый избиратель может проверить свой голос, любой наблюдатель может проверить подсчёт
2. Пороговая криптография: никто в одиночку не может расшифровать голоса или подтасовать результаты
3. Открытость: исходный код, протоколы, данные — всё публично доступно для аудита
4. Прозрачность: все действия системы записываются и верифицируемы
5. Защита от принуждения: возможность переголосования и другие механизмы

Технология готова. Вопрос — в политической воле, инвестициях и терпении. Путь от концепции до первых национальных выборов занимает 4-6 лет. Но результат — избирательная система, которой можно доверять не потому, что мы верим людям, а потому, что мы можем проверить математику.

Криптография не требует доверия — она предоставляет доказательства.

Эта статья является частью Power Hub об электронном голосовании. Для более глубокого погружения в отдельные темы смотрите связанные материалы.