Блог компании analogbytes conference

После завершения интернет-голосования, которое закончилось удивительно хорошо, меня и многих людей долго не покидало чувство того, что в России просто не может что-то пройти так хорошо. Сейчас можно расслабиться реальность не подкачала и мы увидели двойное безумие: как с точки зрения архитектуры решения, так с точки зрения криптографии.
Кстати, Минкомсвязь до сих пор исключает ЛЮБУЮ возможность утечки паспортных данных избирателей

Между тем распределение серий паспортов выглядит вот так:


Давайте воспроизведем события и попробуем понять как всего этого можно было избежать

Что произошло?

9 июля появляется материал Медузы Власти фактически выложили в открытый доступ персональные данные всех интернет-избирателей где они рассказали про архив degvoter.zip.

Как найти архив degvoter.zip?

Я нашел так. Внимательный поиск через Yandex привел меня к странице:
vudu7.vuduwiki.duckdns.org/mk.ru/https_check.ege.edu.ru.html

Там был найден текст Https checkvoter.gosuslugi.ru degvoter.zip. Датировка на тот момент была 7.7.2020 (до публикации Медузы!), сейчас этот текст уже переехал на начало страницы и датировка изменилась.
Сам архив был убран с сайта госуслуги, но его копия сохранилась в web.archive.org, откуда его скачали все заинтересованные в исследовании лица в том числе и я. Чтобы понять почему так произошло рекомендую обратиться к первоисточнику файлу robots.txt на сайте ГосУслуги.

Что внутри degvoter.exe?

Сама программа degvoter написана на C# и представляет из себя написанное на коленке WinForms приложение, которое работает с sqlite базой данных. Файлы в архиве датированы 2020-06-30 22:17 (30 июня 2020 года). Видно, что приложение писалось в кратчайшие сроки, ибо на Камчатке в этот момент уже было 1 июля 7:17, а тот факт, что участки открывались в там в 8:00 говорит о том, что дедлайн был как никогда близок (хорошо что электронно голосовали только Москва и Нижний Новгород).

Код проверки паспорта:


Приложение как с архитектурной точки зрения, так и с криптографической адовейший говнокод. И вот почему:

Описание просчетов архитектуры и принципа атаки на восстановление индентификаторов паспортов

В комплекте с программой находилась локальная БД в которой находилась таблица passports с двумя полями num и used. Где num было SHA256(<серия>+<номер>).
Очень часто, когда программист без соответствующего опыта подходит к вопросам криптографии, он делает кучу однотипных ошибок. С одной из таких ошибок относится применение хэш-фукнции без какой либо обвески. Идентификатор паспорта состоит из 4-ех циферной серии и 6-циферного номера [xxxx xxxxxx]. Т.е. у нас 10^10 вариантов. Номер телефона, к слову, состоит также из 10 цифр [+7(xxx)xxx-xx-xx]. В масштабах современного цифрового мира это не такие большие цифры. Так один Гбайт это больше 10^9 байт, т.е. 100Гбайт хватит чтобы записать все варианты. Вполне вероятно что их банально можно перебрать. Я измерил что в однопоточном режиме современный Intel Core i5 процессор перебирает все sha256 хеши для одной серии паспорта за 5 секунд (000000-999999). И это на стандартной реализации sha256 без каких либо дополнительных ухищрений. Т.е. полный перебор всего пространства на обычном компьютере займет меньше дня. Если же учесть, что перебор можно вести в несколько потоков, то средненький процессор справится с такой задачей за несколько часов. Это является демонстрацией факта непонимания разработчиком системы принципов использования хеш-функций. Но даже правильное применение хэш-функций при такой архитектуре не спасает паспортные данные от раскрытия, если противник имеет неограниченные ресурсы. Ведь человек получивший доступ к БД может за конечное время получить идентификаторы паспортов, т.к. проверка одного паспорта должна проходить конечное время. Весь вопрос только в ресурсах (хотя если бы здесь просто применили хэширование в пару миллионов раундов, даже такое спорное архитектурное решение, как распространение БД вместе с приложением, не привело бы к такому громкому эффекту, т.к. позволило бы защититься хотя бы от журналистов). Медуза всего лишь продемонстрировала некомпетентность людей, проектировавших эту часть системы.

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

Архитектура на коленке

Предположим, что у нас вообще нет времени и надо написать решение в течении ночи.
Очевидным требованием является то, что БД с хешами паспортов должна находиться на сервере и это обязательно должно быть клиент-серверное приложение. Сразу же возникнет вопрос, а что делать если вдруг на участке сломается Интернет? Для этих целей нужно сделать Android-версию клиентского приложения, которую нужно также дать скачать членам УИК. В местах, где нет ни интернета, ни сотовой связи на этом голосовании люди не голосовали.
Хэш в базе не должен вычисляться непосредственно из идентификатора паспорта. Это делается для того, чтобы хэши в базе нельзя было подобрать, используя существующие таблицы для перебора. Во-первых, нужно использовать стойкую-хеш функцию. Главный вопрос в том, КАК её нужно использовать. Возможных реализаций тут много, но по сути всё сводится к применению алгоритма в котором будут три параметров: тип хеш-функции, количество итераций, а также значение(я) которое нужно использовать для подмешивания к хэшу (оно будет общее для всех хешей). Конечное требование внутри каждой итерации должен быть использована стойка хеш-функция, а скорость вычисления хэша должна быть несколько единиц в секунду. Даже завладев БД с сервера злоумышленнику в этом случае потребовалось бы значительное время на восстановление всех данных.
Каждое из клиентских приложений будет представлять из себя просто поле ввода + Http-клиент, которые отправляет запрос на сервер.
Сервер работает только по HTTPS и только во время голосования и имеет ограничение в 1 RPS в секунду с IP. В качестве ограничителя RPS используем Redis, куда пишем в качестве ключа IP-адрес и TTL в одну секунду. Есть значение запрос с IP не разрешен, нет значения запрос с IP разрешен. Это даст возможность избежать перебора извне.
Написанное таким образом наше, буквально из говна и палок, решение окажется на порядок более защищенным чем текущее degvoter. При этом разница во времени написания невелика и с сам процесс написания кода может быть распараллелен на 3 человек (сервер, win-client,android-client).

Разберем возможные сценарии утечек.
У нас есть следующие точки где можно получить информацию о системе
1. Исходный код серверной части
2. Скомпилированные файлы серверной части
3. Серверная БД
4. Клиентские приложения

Клиентские приложения в этом случае не несут никакой информации, при этом к ним имеет доступ максимальное число людей и именно здесь максимальная вероятность утечек (что и произошло)
Для того чтобы восстановить информацию потребуется получить доступ к информации из точек (1,2) или (1,3). Если есть только база, то без известного метода хеширования восстановить что-то будет невозможно.

Выводы

1. Каждый раз, когда нужно в каком-то виде работать с персональными данными привлекайте архитектора
2. Каждый раз, когда нужно в каком-то виде работать с персональными данными привлекайте разработчика с опытом/образованием в сфере криптографии или информационной безопасности
Эти два простых правила помогут избежать позора, который мы наблюдали на примере с приложением degvoter, (Помните, что обычный разработчик может и не разбираться в нюансах применения хэш-функций)

Утилита для демонстрации возможности восстановления персональных данных DegvoterDecoder находится в репозитории, посвященном анализу данных голосования. По-умолчанию она настроена на 8 потоков. В случае если вы уже скачали архив degvoter.zip и вы программируете на C# вы без труда разберетесь в принципе её работы.
github.com/AlexeiScherbakov/Voting2020

Привет, Хабр!

Как вы все знаете, на этой неделе прошло по сути первое в России по-настоящему масштабное электронное голосование по поправкам в Конституцию. Прошло оно только в двух регионах, Москве и Нижнем Новгороде, но собрало при этом 1,2 млн. избирателей (в основном в Москве, где электронно проголосовали 15 % от общего числа избирателей).

Формально оно проходило в территориальной избирательной комиссии дистанционного электронного голосования (ТИК ДЭГ), реально, конечно, мы работали удалённо, кроме торжественных мероприятий в начале и конце. Работали мы там сразу в двух качествах: во-первых, официальных наблюдателей на ТИК ДЭГ от Общественной палаты РФ, во-вторых, экспертной рабочей группы. Такое сочетание очень удачно: во-первых, позволяет иногда не только просить, но и требовать, во-вторых, если официальный статус наблюдателя доступен избранным, то в экспертную группу мы могли вводить людей по своему собственному усмотрению.



Сейчас мы готовим большой отчёт о ходе голосования, возникавших вопросах и замечаниях, а также предложениях на будущее, а также ждём от ДИТ Москвы полную выгрузку всех транзакций блокчейна (не только поданных голосов, они уже выгружены) и статистику очередей Rabbit MQ, в которых данные могли находиться, иногда значимое время, до попадания в блокчейн.

Однако полный отчёт это много времени и сил, так что, чтобы сейчас начинать делиться наблюдениями и соображениями, завтра, 4 июля, в 12:00 по Москве мы проводим онлайн пресс-конференцию по итогам голосования.

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

Итак, сначала анонс.

Итоги электронного голосования. Пресс-конференция экспертной группы

Суббота, 4 июля, 12:00 по московскому времени

На завершившемся на этой неделе голосовании по поправкам в Конституцию Партия прямой демократии не только выступала в качестве наблюдателей от Общественной палаты РФ в территориальной избирательной комиссии дистанционного электронного голосования (ТИК ДЭГ), но и сформировала экспертную группу по контролю за ходом и результатами голосования.

На пресс-конференции мы расскажем о том, как проходило электронное голосование, с какими проблемами оно столкнулось, можно ли доверять его результатам а также какие шаги необходимо предпринять для дальнейшего развития и применения ДЭГ в России, в том числе на региональных выборах осени 2020 и думских осени 2021 года. О ситуации с ДЭГ расскажут эксперты по электоральным системам, блокчейну, криптографическим системам и информационной безопасности.

Трансляция будет доступна на YouTube-канале Партии прямой демократии.

Вопросы спикерам можно задавать в комментариях к трансляции или через Телеграм-канал партии.

Участники экспертной группы:

• Олег Артамонов, член ВКС Партии прямой демократии, наблюдатель на ТИК ДЭГ
• Мона Архипова, независимый эксперт, соучредитель и операционный директор компании Межрегиональный информационно-расчётный центр
• Александр Исавнин, независимый эксперт, член Пиратской партии России
• Вячеслав Макаров, генеральный секретарь ВКС Партии прямой демократии, наблюдатель на ТИК ДЭГ
• Сергей Нестерович, независимый эксперт, заместитель главного редактора Агентства Политических Новостей
• Александр Подшивалов, независимый эксперт, член Партии прямой демократии
• Тимофей Шевяков, пресс-секретарь и член ВКС Партии прямой демократии
• Алексей Щербаков, независимый эксперт, соавтор доклада Романа Юнемана Электронное голосование. Риски и уязвимости

Приглашённые гости:

• Андрей Ларин, руководитель проекта ДЭГ, ДИТ Москвы
• Юрий Максимов, д.э.н., к.ф.м.н., профессор МГУ, советник заместителя председателя Государственной Думы РФ, член ЛДПР

Как вы видите, состав подобрался крайне интересный. На пресс-конференции сначала выступим я и Слава Макаров как официальные наблюдатели, а потом дадим слово каждому из присутствующих экспертов и гостей. Темы и содержание их выступлений мы заранее не согласовывали, так что даже для меня они пока загадка (хотя, конечно, примерно я представляю, что Мона вряд ли будет про блокчейн, а Алексей про IDS).

Немного про ход голосования

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

В этот раз всё случилось намного, намного интереснее.

Во-первых, данные по явке и голосам за, по выгрузке из уже расшифрованного блокчейна:



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

Отмечу несколько моментов:

• это выгрузка из блокчейна, она не учитывает очередей в Rabbit MQ
• на графике не совсем корректно посчитана явка она не учитывает выданные, но не полученные обратно бюллетени, таких было около 1,7 %
• было бы очень интересно сопоставить данные по голосам с медиамониторингом: с высокой вероятностью события 25.06 в 17:10, 26.06 в 16:30 и 29:06 в 14:10 обусловлены выходом материалов, подстёгивающих интерес к голосованию, причём первый раз в чисто московском и лоялистском канале, а второй и третий в оппозиционных СМИ
• отдельно интересно, что пятидневное голосование выгодно противникам поправок скорее всего, потому, что изначально они были настроены в целом скептически, и не торопились голосовать, даже подав заявку на ДЭГ
• 27.06 в районе полуночи была попытка атаки на блокчейн, которая на час вывела из строя интерфейс наблюдателя и ненадолго перегрузила блокчейн; поэтому виден скачок это поданные голоса после окончания атаки прогрузились из Rabbit MQ в блокчейн

Также положу сюда PDF-файлик с отчётом о работе блокчейна. Это рабочие наброски на основе данных ДИТ Москвы, надеюсь, к середине следующей недели мы представим более подробный и детализированный отчёт, с цифрами и комментариями.

Вывод и тезисы

С предварительными коллективно составленными тезисами экспертной группы можно ознакомиться на Google Docs.

Тезисы составлялись к пресс-брифингу Общественной палаты РФ 30 июня, но актуальности своей не утратили.

Как нетрудно заметить, они далеко выходят за тему технической работоспособности системы и затрагивают организационные, информационные и законодательные моменты. В целом, могу сказать, что в этот раз мы благодарны ДИТ Москвы за стабильную работу системы ДЭГ как минимум, это позволило отвлечься от обсуждения сколько бюллетеней блокчейн пожевал и выплюнул и сфокусироваться на более широком круге задач.

Итого

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

YouTube: https://youtu.be/PAhFGnLDBjI

P.S. Если вы представитель прессы, и хотите поучаствовать непосредственно в Zoom, с возможностью задавать вопросы, пишите мне напрямую в Хабре или в Телеграм olartamonov.