Этот пост является ответом на habrahabr.ru/post/244753 Чтобы повысить доверие и прозрачность рентабельности инвестиций, вы можете применить довольно простое решение, описанное в этом посте.
Когда пользователь голосует за, против или отзывает свой голос за какую-либо инициативу, ROI необходимо сгенерировать специальный проверочный код, но такой, который не содержит личной информации пользователя.
Список таких кодов должен быть общедоступным.
Таким образом, каждый мог проверить результаты своего голосования в открытом доступе.
Данное техническое решение является простым, позволяет в некоторой степени контролировать подсчет голосов и тем самым повышает уверенность граждан в рентабельности инвестиций.
Предлагаемый протокол действий.
Для начала ROI генерирует 2048-битную пару ключей RSA (SK, PK) для использования в качестве электронной цифровой подписи (ЭCP), где SK — закрытый ключ, а PK — открытый ключ.
Открытый ключ публикуется в открытом доступе, а секретный ключ хранится и используется только на сервере ROI. Такой ключ может быть один для всей рентабельности инвестиций или много разных для разных инициатив.
Например, для каждой инициативы можно сгенерировать свой отдельный ключ.
Или время от времени обновляйте ключ для всего ROI. Для идентификации ключа будем использовать понятие «версия ключа» (или индекс, номер ключа).
Дополнительно, но совсем не обязательно для первой версии системы, ROI может публиковать сертификат ключа.
Структура и генерация кодов, которые должны быть общедоступными.
1. При голосовании пользователя ROI формирует следующий вектор V длиной 49 байт: Версия ключа (номер): 4 байта Номер инициативы: 4 байта Время события (время UTC): 8 байт. Тип события: 1 байт (ЗА, ПРОТИВ, ОБЗОР) Хэш проголосовавшего пользователя, рассчитываемый как H = SHA256(UserSecret; СНИЛС; Инициативный номер): 32 байта.
UserSecret — секрет, источником которого является сам пользователь.
Например, это может быть голосовой пароль, который пользователь вводит на сайте ROI при голосовании.
Если технически ROI позволяет, то это может быть пароль при вводе ROI или его хэш, в этом случае ROI может автоматически вставить его в поле.
В любом случае это должно быть что-то, исходящее от пользователя и известное только ему одному и никому другому.
О причинах нововведения читайте в комментариях к спойлеру.
UPD: Изменения в первой редакции, мотивация Было: H = SHA256(SK;СНИЛС;Номер инициативы): 32 байта.
В результате обсуждений стало ясно, что в системе есть дыра.
Представим себе следующий сценарий: ROI кэширует результаты и выдает их, скажем, раз в 5 минут. Допустим, какой-то пользователь проголосовал, и ему генерируется и отправляется правильный код (Vx, Sx).
Допустим, в течение этих 5 минут голосует еще кто-то, и ROI может отправить ему не новый код, а код предыдущего пользователя (Vx, Sx).
В дальнейшем при проверке своих кодов оба пользователя увидят, что их код есть в выписке, но счетчик ROI увеличится только на 1, и проверить это невозможно.
То есть мы получим сценарий, при котором голос может пропасть в ROI. Слабым звеном здесь является вектор Hx. Поэтому необходимо, чтобы пользователь сам мог проверить корректность исходных данных этого вектора, а никто другой не мог.
Это немного усложняет систему.
Здесь следует отметить, что если пользователь выполняет несколько действий, например, ЗА-ПРОСМОТР-ПРОТИВ, то UserSecret должен оставаться неизменным для всех этих действий, чтобы логи Hx были одинаковыми для этих операций у одного пользователя и выбранного инициатива.
В случае, когда голосование невозможно отозвать (как сейчас в ROI), то этот вопрос становится неактуальным и проблемы здесь нет. Следствие: Теперь пользователю нужно не только проверить, что его код (Vx, Sx) есть в списке загруженных логов, но и проверить, что уникальный вектор Hx из Vx сформировался правильно.
2. Далее ROI использует соответствующий секретный ключ RSA SK для получения второй части кода — цифровой подписи (ЭCP): S = RSA_Sign(SK; V) — результат будет 256 байт. 3. Пара (V;S) отправляется по электронной почте проголосовавшему пользователю, а также размещается в открытом доступе (например, в текстовом формате PEM).
Плюсы: • Любой, у кого есть общедоступный список пар {V;S}, может подсчитать общее количество голосов за выбранную инициативу, сначала проверив каждое значение Vx с помощью открытого ключа ROI следующим образом: RSA_Verify(PK; Sx; Vx) возвращает значение « успех» или «неудача» успех».
По сути, функция расшифровывает подпись Sx с помощью открытого ключа PK и сверяет результат с Vx, если он равен, то «успех».
• Любой человек из списка {V;S} может найти свой код голосования, поскольку его необходимо отправить пользователю по электронной почте сразу после голосования.
Если код не найден в общем списке, пользователь может предъявить свою пару (Vx, Sx) в качестве доказательства неучтенного голоса.
Кроме того, пользователь должен проверить, что его собственный вектор Hx из Vx сформировался правильно, что исключает возможность сценария, когда ROI отправляет одну и ту же пару (Vx, Sx) двум пользователям, но засчитывает только один голос.
• Третьи лица не смогут говорить о неучтенном голосе Vx без предоставления соответствующей пары подписей Sx, поскольку для этого необходимо знать секретный ключ ROI. Таким образом, ROI защищен от необоснованных претензий такого рода.
• Поле H было добавлено в строку V для уникальной идентификации действий одного и того же пользователя в рамках выбранной инициативы.
Например, последовательность PRO-CANCEL-CON должна быть связана с конкретным пользователем, чтобы эту последовательность можно было отслеживать в списке событий {V;S}.
При этом сам СНИЛС пользователя недоступен, поскольку генерируемый на сервере РОИ хеш включает в себя секретный ключ РОИ.
По хешу невозможно узнать ни секретный ключ человека, ни СНИЛС.
И даже если СНИЛС известен, узнать секретный ключ ROI по хешу невозможно.
Также невозможно проверить, как проголосовал тот или иной человек, зная его СНИЛС, поскольку связь между СНИЛС и Н не является публичной информацией, она известна только тому, кто голосовал, как и сам результат голосования – эта информация теперь отправлено пользователю по электронной почте.
Таким образом, данная конструкция не меняет текущий уровень безопасности личной информации (как человек голосовал), и не происходит утечки информации через СНИЛС или секретный ключ РОИ.
• Когда проигранный голос (Vx, Sx) публично представлен конкретным пользователем, между голосом и конкретным человеком создается связующая пара, и тогда всем становится понятно, как проголосовал этот конкретный человек.
Но сейчас ситуация аналогичная – если я голосовал и мой голос не был засчитан, то, заявляя об этом, я публично выдаю информацию о том, как я голосовал.
Однако преимущество состоит в том, что проигранный голос (Vx, Sx) и, следовательно, претензия на рентабельность инвестиций могут быть анонимно переданы в публичное пространство, не раскрывая связи с конкретным пользователем.
Минусы: • Невозможно отследить сценарий, при котором ROI может добавить голоса ЗА или ПРОТИВ за несуществующий СНИЛС.
Но этот сценарий все еще возможен.
Техническая реализация: Для реализации идеи ROI может установить OpenSSL (открытую и бесплатную криптографическую библиотеку, широко используемую во многих системах, а также при установлении зашифрованных каналов в IP-соединениях, в браузерах и многих других приложениях) и использовать ее из своих скриптов для всех вышеперечисленные операции: генерация ключа RSA (для ЦП), подписание и хеширование SHA256. Генерация ключей — операция медленная, но редкая (однократно или при открытии новой инициативы).
Подписание и хеширование закрытого ключа — быстрые операции.
OpenSSL можно использовать либо из командной строки или сценария, либо из различных компилируемых языков программирования, таких как C/C++.
Реализация не требует какой-либо инфраструктуры или других сложных шагов и может быть легко реализована с помощью нескольких строк сценария или кода.
UPD: Уточнения и дополнения по просьбам читателей.
У меня такое ощущение, что если сложить все мнения, то получится ноль.
Но я попытаюсь: 1. В тексте я уточнил, что ключ RSA генерируется на стороне ROI для использования в качестве ЦП.
Также RSA_Encrypt/RSA_Decrypt заменены на RSA_Sign/RSA_Verify соответственно.
2. Я получил вопрос, почему не ECDSA 256 бит (алгоритм цифровой подписи на основе эллиптической кривой).
Да, есть преимущества в размере цифровой подписи S. Она будет не 256 байт, как в случае с RSA, а 72. Но есть и недостатки с точки зрения скорости.
Операция RSA_Verify во много раз быстрее, чем ECDSA_Sign и Verify. А если мы просто поменяем RSA_Sign/Verify на RSA_Encrypt/Decrypt и опубликуем SK вместо PK, то мы получим сервер, который умеет быстро подписывать, во много раз быстрее, чем ECDSA. 3. Почему не ГОСТ? О наших советских стандартах я почти не слышал, просто знаю, что некоторые из них были скопированы с зарубежных идей и кое-что добавлено, чтобы они выглядели по-другому.
Примером может служить шифр «ГОСТ», созданный КГБ (ну, я знаю его под этим названием в научном сообществе), который копирует 3DES с небольшими вариациями.
Те же вопросы по алгоритму хэширования ГОСТ - понятия не имею.
4. Давайте, во избежание подобных вопросов со стороны китайцев (у них там тоже есть что-то свое), как в пунктах 2-3, сразу заменим: пусть асимметричный алгоритм будет X, а алгоритм хеширования Y и выберите тот, который вам нужен.
Просто поддерживайте уровень безопасности не ниже 128 бит для используемых алгоритмов (а еще лучше 256), а в остальном это вопрос выбора и не сильно влияет на суть.
Спасибо! Теги: #roi #roi2014 #roi2014 #электронная демократия #голосование #информационная безопасность
-
Защита От Спама На 8800 Во Freepbx
19 Oct, 24 -
Монеты От 3Com
19 Oct, 24 -
Примеры Поиска Shodan
19 Oct, 24
