Пишет alm:
Результаты моего небольшого исследования.
Во время инициализации КОИБ программа просит вставить флешку с исходными данными для голосования. Там содержится название выборов, список кандидатов для голосования, координаты квадратиков — и т.д. Всё как и должно быть.
Но самое интересное, что алгоритм заполнения протокола (формулы всякие, контрольные соотношения) зашиты прямо в том же файле. Включая расчёт строк протокола, в которых прописывается количество голосов за кандидата. Я думаю, что разработчики предполагали, что КОИБ может использоваться не только в России, и что правила заполнения протоколов могут поменяться. Но вот почему эти правила распространяются не в виде отдельного класса, который можно качественно обложить юнит-тестами, а в виде конфигурации, которая заливается на флешку и компилируется динамически, вот это вопрос.
В файле исходных данных все формулы пишутся прямо на C#. Некоторые метапеременные разворачиваются на этапе загрузки в соответствующие C#-выражения.
Имеющийся функционал позволяет запрограммировать перераспределение итоговых голосов в пользу какого-либо Сокандидата. Убедиться, что такая фальсификация не имела места, можно только если достоверно известно, что участки для ручного пересчёта выбирались справедливым равновероятным жребием. Как мы знаем из новостей, Венедиктов подтвердил, что ручной пересчёт совпал до единого голоса. Вопросы — насколько мы верим Венедиктову, и насколько честным было определение участков для пересчёта.
Также, учитывая, что протокол распечатывается после того, как в КОИБ введены данные о неиспользованных бюллетенях, председатель УИК мог втихаря залезть в сейф и хорошо спрятать некоторое количество бюллетеней. При обычных выборах без КОИБ такая фальсификация достаточно сложная, т.к. пришлось бы вбросить примерно то же самое количество бюллетеней, сколько спрятано (или чуть меньше). Иначе будет очень подозрительно, когда количество унесённых избирателями бюллетеней будет зашкаливать. Когда есть «заряженный» КОИБ, накидывание голосов желаемому кандидату может проводиться автоматически по формулам с флешки так, чтобы это не было подозрительно. Защищаться можно, как обычно — гарантируя справедливый жребий при определении участков для пересчёта.
Судя по коду, накрутить общее количество принятых бюллетеней во время голосования не представляется возможным. А значит, счётчику на панельке КОИБ можно доверять. Если в конце дня он показывает N, то будьте уверены, что внутри N бюллетеней. Если в протоколе окажется M > N, значит имело место жульничество. Одно но — КОИБ при этом не должен быть подключен к сети. В противном случае, эмулируя удалённый сканер (второй КОИБ, который стоит рядом с главным называется RemoteScanner), можно через процедуру AcceptNewStateвнедрить желаемые результаты по команде из центра. Прям натурально КОИБ примет хэш «кандидат => число_голосов». Чтобы защититься, наблюдатели должны внимательно проверять наличие лишних проводов, ведущих к КОИБам. А также не позволять их подключать после того, как голосование завершено, что бы там ни вешал на уши председатель.
В общем, резюме, как защищаться от фальсификаций на участках с КОИБами:
1. следить за ростом счётчика принятых бюллетеней. Какое значение было за 1 секунду до конца голосования, такое должно попасть в протокол.
2. следить, чтобы ничего не подключали к КОИБу ни во время, ни после голосования.
Ну и совсем мёртвая зона — это доверие к выбору участков для ручного пересчёта. Кстати, проверить это тоже довольно легко. Можно сравнить результаты на участках, где был пересчёт, и где были КОИБ без пересчёта. Есть у кого такие данные?
Источник http://habrahabr.ru/post/193414/#commen t_6717714
Вот здесь еще пишет наблюдатель о том, что система со стороны совершенно непрозрачная и потенциально уязвимая http://flaring-tille.livejournal.com/86 292.html
