Этот пост — ответ на habrahabr.ru/post/244753
Для повышения доверия и прозрачности к РОИ, можно применить достаточно простое решение, описанное в этом посте. Когда пользователь голосует за, против, или отзывает свой голос за какую либо инициативу, необходимо чтобы РОИ генерировал специальный проверочный код, но не содержащий личной информации пользователя. Список таких кодов должен быть доступен в общем пользовании. Таким образом, каждый мог бы проверить результат учета своего голосования в публичном доступе. Данное техническое решение является простым, дает возможность контроля подсчета голосов до некоторой степени и, таким образом, повышает доверие граждан к РОИ.
Предлагаемый протокол действий.
Для начала, РОИ генерирует 2048 битный RSA ключ-пару (SK, PK) для использования в качестве электронной цифровой подписи (ЭЦП), где SK-секретный ключ и PK-публичный ключ. Публичный ключ публикуется в открытом доступе, а секретный хранится и используется только на сервере РОИ. Таких ключей может быть один для всего РОИ или много разных для разных инициатив. Например, можно генерировать свой отдельный ключ для каждой инициативы. Или обновлять ключ для всего РОИ время от времени. Для идентификации ключа будем использовать понятие «версия ключа» (или индекс, номер ключа). Дополнительно, но совсем не обязательно для первой версии системы, РОИ может публиковать сертификат ключа.
Структура и генерация кодов, которые должны быть в публичном доступе.
1. При голосовании пользователем, РОИ формирует следующий вектор V, длинною 49 байт:
Версия (номер) ключа: 4 байта
Номер инициативы: 4 байта
Время события (UTC время): 8 байт
Тип события: 1 байт (ЗА, ПРОТИВ, ОТЗЫВ)
Хеш проголосовавшего пользователя, вычисляемый как
H = SHA256(UserSecret; СНИЛС; Номер Инициативы): 32 байта.
UserSecret это секрет, источник которого — сам пользователь. Например, это может быть пароль на голос, который пользователь вводит на сайте РОИ при голосовании. Если технически РОИ позволяет, то это может быть и пароль при входе на РОИ или его хеш, в таком случае РОИ может автоматически подставлять его в поле. В любом случае, это должно быть то, что исходит от пользователя, и что известно ему одному и никому другому. О причинах нововведения — читайте в спойлер-комментарии.
2. Далее, РОИ использует соответствущий секретный RSA ключ SK для того, чтобы получить вторую часть кода — цифровую подпись (ЭЦП):
S = RSA_Sign(SK; V) – результат будет 256 байт.
3. Пара (V; S) высылается электронной почтой проголосовавшему пользователю, а также помещается в публичный доступ (например, в текстовом PEM формате).
Для повышения доверия и прозрачности к РОИ, можно применить достаточно простое решение, описанное в этом посте. Когда пользователь голосует за, против, или отзывает свой голос за какую либо инициативу, необходимо чтобы РОИ генерировал специальный проверочный код, но не содержащий личной информации пользователя. Список таких кодов должен быть доступен в общем пользовании. Таким образом, каждый мог бы проверить результат учета своего голосования в публичном доступе. Данное техническое решение является простым, дает возможность контроля подсчета голосов до некоторой степени и, таким образом, повышает доверие граждан к РОИ.
Предлагаемый протокол действий.
Для начала, РОИ генерирует 2048 битный RSA ключ-пару (SK, PK) для использования в качестве электронной цифровой подписи (ЭЦП), где SK-секретный ключ и PK-публичный ключ. Публичный ключ публикуется в открытом доступе, а секретный хранится и используется только на сервере РОИ. Таких ключей может быть один для всего РОИ или много разных для разных инициатив. Например, можно генерировать свой отдельный ключ для каждой инициативы. Или обновлять ключ для всего РОИ время от времени. Для идентификации ключа будем использовать понятие «версия ключа» (или индекс, номер ключа). Дополнительно, но совсем не обязательно для первой версии системы, РОИ может публиковать сертификат ключа.
Структура и генерация кодов, которые должны быть в публичном доступе.
1. При голосовании пользователем, РОИ формирует следующий вектор V, длинною 49 байт:
Версия (номер) ключа: 4 байта
Номер инициативы: 4 байта
Время события (UTC время): 8 байт
Тип события: 1 байт (ЗА, ПРОТИВ, ОТЗЫВ)
Хеш проголосовавшего пользователя, вычисляемый как
H = SHA256(UserSecret; СНИЛС; Номер Инициативы): 32 байта.
UserSecret это секрет, источник которого — сам пользователь. Например, это может быть пароль на голос, который пользователь вводит на сайте РОИ при голосовании. Если технически РОИ позволяет, то это может быть и пароль при входе на РОИ или его хеш, в таком случае РОИ может автоматически подставлять его в поле. В любом случае, это должно быть то, что исходит от пользователя, и что известно ему одному и никому другому. О причинах нововведения — читайте в спойлер-комментарии.
UPD: Изменения к первой редакции, мотивация
Было: H = SHA256(SK; СНИЛС; Номер Инициативы): 32 байта.
В результате обсуждений вяснилось, что в системе дыра. Представим себе следующий сценарий: РОИ кэширует результаты и выдает их, скажем, раз в 5 минут. Допустим какой то пользователь проголосовал, и ему генерируется и отсылается правильный код (Vx, Sx). Допустим кто то другой тоже голосует в эти 5 минут, и РОИ может отослать ему не новый код, а код предыдущего пользователя (Vx, Sx). Позже, при проверке своих кодов, оба пользователя увидят что их код есть в выписке, но счетчик на РОИ увеличится только на 1, и это проверить невозможно. То есть мы получим сценарий, при котором на РОИ может пропасть голос. Слабое звено тут — вектор Hx. Поэтому необходимо, чтобы сам пользователь мог проверить правильность исходных данных этого вектора, но никто другой не мог бы. Это немного усложняет систему.
Тут надо отметить, что если пользователь производит несколько действий, например, ЗА-ОТЗЫВ-ПРОТИВ, то UserSecret должен оставаться неизменным для всех этих действий, чтобы в логах Hx был один и тот же для этих операций для одного пользователя и выбранной инициативы. В случае, когда отзывать голос нельзя (как это сейчас на РОИ), то этот вопрос становится не актуальным и проблемы тут нет.
Следствие: Теперь пользователю необходимо не только проверить, что его код (Vx, Sx) находится в списке выгружаемых логов, но и проверить, что уникальный вектор Hx из Vx был сформирован верно.
В результате обсуждений вяснилось, что в системе дыра. Представим себе следующий сценарий: РОИ кэширует результаты и выдает их, скажем, раз в 5 минут. Допустим какой то пользователь проголосовал, и ему генерируется и отсылается правильный код (Vx, Sx). Допустим кто то другой тоже голосует в эти 5 минут, и РОИ может отослать ему не новый код, а код предыдущего пользователя (Vx, Sx). Позже, при проверке своих кодов, оба пользователя увидят что их код есть в выписке, но счетчик на РОИ увеличится только на 1, и это проверить невозможно. То есть мы получим сценарий, при котором на РОИ может пропасть голос. Слабое звено тут — вектор Hx. Поэтому необходимо, чтобы сам пользователь мог проверить правильность исходных данных этого вектора, но никто другой не мог бы. Это немного усложняет систему.
Тут надо отметить, что если пользователь производит несколько действий, например, ЗА-ОТЗЫВ-ПРОТИВ, то UserSecret должен оставаться неизменным для всех этих действий, чтобы в логах Hx был один и тот же для этих операций для одного пользователя и выбранной инициативы. В случае, когда отзывать голос нельзя (как это сейчас на РОИ), то этот вопрос становится не актуальным и проблемы тут нет.
Следствие: Теперь пользователю необходимо не только проверить, что его код (Vx, Sx) находится в списке выгружаемых логов, но и проверить, что уникальный вектор Hx из Vx был сформирован верно.
2. Далее, РОИ использует соответствущий секретный RSA ключ SK для того, чтобы получить вторую часть кода — цифровую подпись (ЭЦП):
S = RSA_Sign(SK; V) – результат будет 256 байт.
3. Пара (V; S) высылается электронной почтой проголосовавшему пользователю, а также помещается в публичный доступ (например, в текстовом PEM формате).