Повышение доверия к РОИ при сохранении секретности персональных данных

Этот пост — ответ на habrahabr.ru/post/244753

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

Предлагаемый протокол действий.

Для начала, РОИ генерирует 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 был сформирован верно.


2. Далее, РОИ использует соответствущий секретный RSA ключ SK для того, чтобы получить вторую часть кода — цифровую подпись (ЭЦП):
S = RSA_Sign(SK; V) – результат будет 256 байт.

3. Пара (V; S) высылается электронной почтой проголосовавшему пользователю, а также помещается в публичный доступ (например, в текстовом PEM формате).

Плюсы:

• Любой человек по открытому списку пар {V;S} может подсчитать общее число голосов для выбранной инициативы, предварительно верифицировав каждое значение Vx, используя публичный ключ РОИ следующим образом: RSA_Verify(PK; Sx; Vx) возвращает значение «успех» или «не успех». По сути, функция дешифрует подпись Sx с помощью открытого ключа PK и сверяет результат с Vx, если равно то «успех».

• Любой по списку {V;S} может найти свой код голосования, так как он должен быть послан по электронной почте пользователю сразу после голосования. Если код не найден в общем списке, пользователь может предъявить свою пару (Vx, Sx) как доказательство неучтенного голоса. Кроме того, пользователь должен проверить что его собственный вектор Hx из Vx был сформирован верно, исключая возможность сценария, где РОИ отсылает одну и ту же пару (Vx, Sx) двум пользователям, а учитывает только один голос.

• Третьи лица не смогут говорить об неучтенном голосе Vx без предоставления соответствующей пары-подписи Sx, так как для этого необходимо знать секретный ключ РОИ. Таким образом, РОИ защищено от необоснованных претензий такого рода.

• Поле H добавлено в строку V для того, чтобы однозначно идентифицировать действия одного и того же пользователя в рамках выбранной инициативы. Например, последовательность ЗА-ОТМЕНА-ПРОТИВ должна быть привязана к конкретному пользователю, чтобы можно было отследить эту последовательность в списке событий {V;S}. При этом сам СНИЛС пользователя является недоступным, так как в хеш, который генерируется на сервере РОИ, включен секретный ключ РОИ. По хешу невозможно узнать ни секретный ключ, ни СНИЛС человека. И даже если СНИЛС известен, то невозможно узнать секретный ключ РОИ по хешу. Также, невозможно проверить каким образом голосовал тот или иной человек, зная его СНИЛС, так как связь между СНИЛС и H не является публичной информацией, она известна только проголосовавшему, как и сам результат голосования – эта информация и сейчас высылается пользователю по электронной почте. Таким образом, данная конструкция не изменяет нынешний уровень безопасности личной информации (как голосовал человек), а также нет утечки информации по СНИЛС или секретному ключу РОИ.

• При предъявлении потерянного голоса (Vx, Sx) конкретным пользователем в публичный доступ, создается связующая пара между голосом и конкретным человеком, и тогда всем становится ясно как этот конкретный человек голосовал. Но и сейчас ситуация похожая – если я голосовал а мой голос не был учтен, то я, заявляя об этом, выдаю публично информацию о том как я проголосовал. Однако, плюс в том, что потерянный голос (Vx, Sx) и, таким образом, претензия к РОИ, может быть передан в публичное пространство анонимно, не выдавая при этом связь с конкретным пользователем.

Минусы:

• Невозможно отследить сценарий, в котором РОИ может добавлять голоса ЗА или ПРОТИВ для несуществующих СНИЛС. Но этот сценарий возможен и сейчас.

Техническая реализация:

Для реализации идеи, РОИ может установить OpenSSL (открытая и бесплатная криптографическая библиотека, широко используемая во многих системах а также при установления зашифрованных каналов в IP соединениях, в браузерах и многих других приложениях), и использовать ее из своих скриптов для всех вышеперечисленных операций: генерация RSA ключа (для ЭЦП), подписывание и хеширование SHA256. Генерация ключа – медленная операция, но редкая (один раз или при открытии новой инициативы). Подписывание секретным ключем и хеширование – быстрые операции. OpenSSL можно использовать как из коммандной строки или скрипта, так и из различных компилируемых языков программирования, таких как C/C++. Реализация не требует никаких инфраструктурных или других сложных шагов, и вполне может уложиться в несколько строк скрипта или кода.

UPD: Уточнения и дополнения по просьбам читателей.
У меня такое ощущение, что если все мнения сложить, то получится ноль. Но я попробую:

1. Уточнил по тексту, что RSA ключ генерируется на стороне РОИ для использования в качестве ЭЦП. Также RSA_Encrypt/RSA_Decrypt были заменены на RSA_Sign/RSA_Verify, соответственно.

2. Поступил вопрос, почему не ECDSA 256 бит (elliptic curve digital signing algorithm). Да, преимущества есть в размере цифровой подписи S. Будет не 256 байт, как в случае RSA, а 72. Но есть и минусы по скорости. Операция RSA_Verify работает в разы быстрее ECDSA_Sign и Verify. И если мы просто поменяем RSA_Sign/Verify на RSA_Encrypt/Decrypt и опубликуем SK вместо PK, то мы получим сервер который может быстро подписывать, в разы быстрее чем ECDSA.

3. Почему не ГОСТ? Про наши советские стандарты вообще слышал краем уха, знаю только что какие то из них скопированы с зарубежных идей и там что то добавлено немного чтобы выглядело по-другому. Пример — шифр «GOST», созданные в КГБ (ну, мне он известен под таким именем в научной среде) который копирует 3DES с небольшими вариациями. Те же вопросы и по ГОСТ хеш алгоритму — понятия не имею.

4. Давайте, чтобы предотвратить подобные вопросы китайцев (у них там тоже что то свое есть), как в пп.2-3, сразу просто заменим: ассиметричный алгоритм пусть будет X, а алгоритм хеширования Y, и выбирайте какой хотите. Просто соблюдайте уровень безопасности минимум 128 бит для используемых алгоритмов (а лучше 256), а в остальном это дело выбора и на суть сильно не влияет.

Спасибо!
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 88

    +6
    Вся суть топика во фразе «необходимо чтобы РОИ генерировал специальный проверочный код, но не содержащий личной информации пользователя. Список таких кодов должен быть доступен в общем пользовании». Эта мысль и так встречается в исходном топике и комментариях.

    Все остальное — детали реализации, коих можно придумать сколько угодно, и делать топик на каждую нет необходимости. Так что статья не несет како-либо ценности.
      +1
      Немного ниже дан ответ, если коротко то:
      Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно....(cut) я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
      +1
      Всё это хорошо, только вот функция отзыва голоса вчера была окончательно отключена: www.roi.ru/news/51/
      А без неё почти прозрачный контроль достигается простым мониторингом неубывания количества голосов.
        +6
        Одновременно с отключением функции отзыва голоса было введено довольно большое время кэширования счетчика голосов. Да, счетчик теперь не может уменьшаться, но нет способа проверить, что он будет увеличиваться ровно настолько, сколько человек проголосовало. Например, если в течении интервала кэширования независимо друг от друга проголосует 10 человек, а счетчик увеличится на 1, то каждый будет думать, что именно его голос учтен, хотя это не так.

        Единственный вариант проверить систему в этом случае — это собрать в одном месте достаточно большое количество еще не голосовавших людей (больше чем среднее количество голосов за интервал кэширования) и проголосовать одновременно. Но даже если при этом счетчик увеличится на меньшее значение, чем количество проголосовавших, это все равно можно будет списать на особенности кэширования (мол, эти голоса были учтены только при следующих обновлениях счетчика).
          0
          Даже при отключении процедуры отзыва остаётся ещё масса способов подтасовать исход голосования.
          Не обязательно же списывать голоса — можно устраивать вбросы. Резко увеличилось за секунду на 1000 количество голосов «против» инициативы.
          Поэтому контроль — это всегда комплексная вещь, а не только «контролировать только один параметр».
            +4
            Насколкьо я знаю, голоса «против» формально ничего не дают. Инициатива должна быть рассмотрена экспертной группой при наборе 100 000 голосов «за». Всё.
              0
              Хорошее замечание, спасибо. Я смутно припоминаю, что вроде действительно (на текущий момент) всё так и есть: голоса против не учитываются. Значит, подобным образом не получится злоумышленничать.
              Какие ещё остаются альтернативы для злонамеренных манипуляций? Смотрим на число голосов «за», проверяем, что их не убывает. Всё?
              Или что-то можно сделать такое?
              Я вижу только ещё одну альтернативу: не учитывать голоса «за», хитрым образом закрывая подобный факт («число на счётчике кэшируется» или ещё что), об этом писали в комментариях к этой/прошлой статье.
              Вроде точно всё?
          +3
          Для начала, РОИ генерирует 2048 битный RSA ключ-пару (SK, PK), где SK-секретный ключ и PK-публичный ключ.


          О, опять этот глюк, когда путают понятия модуль/экспонента RSA и открытый/закрытый ключ.

          Открытость или закрытость ключа — это не свойство RSA, это свойство сценария, в котором RSA применяется. Если RSA использовано в шифровании, открывают модуль, а если в ЭЦП — открывают экспоненту.

            0
            Кстати, почему RSA-то, в конце концов? Может, уже ECDSA задействуем?
              0
              Хмм… ну, можно взять EC 226 если с тем же уровнем секьюрити, или 256. Ну я так понял вы на размер кода (V, S) обратили внимание? Хотя, если поменять местами использование PK и SK то подпись в RSA будет работать в разы быстрее чем ECDSA (а верификация медленно), что важно для сервера. Как думаете?
              RSA 2048 Encryption/Verification 0.16ms <<< наша цель по скорости
              RSA 2048 Decryption/Signature- 6.08ms
              ECDSA over GF(p) 256 Signature 2.88ms
              ECDSA over GF(p) 256 Signature with precomputation 2.14ms
              ECDSA over GF(p) 256 Verification 8.53ms
              ECDSA over GF(p) 256 Verification with precomputation 3.58ms
              Отсюда: www.cryptopp.com/benchmarks.html
                0
                Я думаю, что вам, как разработчику предложения, стоило бы не ограничиваться одним алгоритмом, а предложить по каждому пункту альтернативы, указав плюсы и минусы каждой. Про ГОСТ вам ниже тоже правильно написали.
                  0
                  Ну я понял, надо было просто в абстрактном виде подать. Назвать ассиметричный алгоритм X и алгоритм хеширования Y и все было бы верно. А там уже выбирай любой под них :)… я и правда, не подумал, что придется еще и список алгоритмов перечислять, плюсы-минусы, сравнивать их.
                    0
                    Так ваш подход тогда, простите, не очень-то отличается от РОИшного. Те тоже выбрали первый попавшийся вариант реализации, не рассмотрев плюсы и минусы альтернативных решений. Теперь неплохо бы переделать. А вам неплохо бы доказать, что за вами-то через 2 года переделывать не придётся.
                      –1
                      Да мне по сути все равно что они там выберут в качестве X Y, главное чтобы по уровню безопасности подходило.
                      Я ради вас даже топик подправил, в конце собрал все претензии вместе в секции UPD. И потом, я вообще не в курсе кто и как это предложит в РОИ, и пойдет ли все это дальше куда то. Сам я активно этим заниматься точно не буду, на уровне идеи остановлюсь пожалуй. Денег мне за это не платят, семью не накормишь этим.
                    0
                    А почему, кстати, ГОСТ? Они там на РОИ ГОСТ применяют? Если так, то через что?.. Могу предположить OpenSSL Engine ГОСТовский какой нибудь (ну если это скрипты). Не писали же они SSL/TLS библиотеку всю с нуля.
                      0
                      openssl поддерживает ГОСТ уже много лет.
                        0
                        понятно.
              +1
              В вектор V логично включить подпись предыдущего голоса.
              Каждый следующий голосующий фиксирует все предыдущие голоса.
                +1
                А если одна запись «выпадет» или потеряется где то? Например, сам Масух проголосует а потом выдернет из БД? Вся последующая цепочка событий будет разорвана.
                  0
                  То вся последующая цепочка теряет доверие.
                  Собственно задача побороть «выпадания голосов» по самым разным причинам.

                  Вставить пачку голосов задним числом тоже не получится.
                    +1
                    Можно будет вставлять пачку голосов в конец цепочки, каждые 6 минут, например.
                      0
                      Отличная диверсия. А главное — отлично демотивирует людей, чтобы они не пошли на повторное голосование.
                      Хотя в целом это, наверное, всё-таки необходимо.
                    +1
                    Еще совсем чуть-чуть допилить, и получится блокчейн.
                      0
                      Теоретически блокчейн добавить просто — SHA256(от предыдущего sign), это 32 байта к 49 — не проблема. Практически немного сложнее из за возможной рассинхронизации. Только не могу понять что это дает, против какой возможной атаки, какой сценарий тут?
                        0
                        Насчет блокчейна изначально была шутка: поскольку у нас система централизована, это не очень поможет — сервер РОИ по-прежнему имеет возможность незаметно вставлять несуществующие СНИЛСы (правда, каждый не более одного раза).

                        Но потом я заметил, что некоторая польза от цепочки всё же есть. Благодаря монотонности публикуемой информации, становится невозможно подбрасывать фальшивые голоса (с несуществующими СНИЛСами) задним числом, можно лишь по ходу дела. На первый взгляд от этого пользы мало, но тем не менее жизнь фальсификаторов осложняется — замести следы и уйти от ответственности намного труднее.

                        (Насчет технической реализации: не вижу проблем с синхронизацией, ведь сервер РОИ один, и может выстраивать полученные заявки в любой последовательности. То есть у него копится пул необработанных заявок, и он из пула их последовательно выбирает в произвольном порядке, встраивает в цепочку и отправляет уведомление. Это никак не параллелится, поэтому, если будут проблемы с производительностью, можно тянуть несколько цепочек одновременно, изредка провязывая их друг с другом. Тогда заявка будет считаться полностью валидной, если на нее есть ссылки из всех цепочек.)
                          0
                          «подбрасывать фальшивые голоса (с несуществующими СНИЛСами) задним числом»
                          Ну, я с Вами отчасти согласен, но сильно такой необходимости подбрасывать назад я не вижу. Ну, во-первых сам счетчик будет гулять, если вы бросите назад на неделю (и это будет заметно), а если подбрасывать назад в пределах времени кэширования, то, опять же, нет нужны бросать назад на 5 минут, когда можно просто добавить в конец чейна. А вот объяснить Массуху такой чейн и как его реализовать — гораздо сложнее. Для таких людей на стол надо ложить самые простые схемы, чтобы уж совсем просто было понять.
                            0
                            Я придумал, зачем фальсификаторам может понадобиться подбрасывать задним числом. Дело в том, что большинство инициатив безобидны или не вызывают ажиотажа у народа, поэтому вмешиваться, как правило, не нужно. Требуется лишь выявить опасные и популярные инициативы, и нужно время, чтобы осознать опасность и выявить тренд. Тогда и нужно принимать решение о вбросе, но если сделать его в конце голосования, то будет сильно заметно и подозрительно, поэтому лучше аккуратно размазать его во времени.
                            Второй момент заключается в следующем: допустим сделали вброс неаккуратно, так что народ заметил и возмутился; здесь лучше откатить назад, то есть извлечь фальшивые голоса из базы и заявить, что это хулиганы фальсифицировали фальсификацию, а сейчас, видите, какой на сайте правильный и по-гауссовски красивый результат.
                              0
                              Пример можете привести? Выберите сценарий:
                              — Это инициатива: (а) моя, в которой я заинтересован, или (б) от РЖД, которую проталкивают кто то из РОИ?
                              — Вбросы назад будут какие — голоса ЗА или ПРОТИВ?
                                0
                                Пример достаточно прост — любая инициатива, которая противоречит политике партии власти и при этом окажется достаточно популярной. Тогда появляется интерес надавить на РОИ с целью вбросить голосов ПРОТИВ. Насчет того, что кто-то будет нечестным образом лоббировать свою инициативу, я как-то сразу не подумал, хотя такое тоже может быть. В любом случае, ситуация, когда власть хочет играть против воли народа, бывает достаточно часто, это нормально и естественно. Речь здесь идет о том, что если решаешься на фальсификацию, то выгоднее подбросить равномерно, а не кучей в конце. Цепочка лечит ровно этот случай.
                                  0
                                  Выше уже писали, что голоса ПРОТИВ не учитываются, поэтому нет смысла их накидывать — хоть равномерно, хоть в конце. Набрала инициатива 100тыс и все, на рассмотрение. Кроме того, учесть виртуальных ПРОТИВ все равно невозможно — смотрите «минусы» в посте. Тут простых решений нет.
                      • UFO just landed and posted this here
                          0
                          Это всё верно, но есть некоторая сложность с поддержанием безденежных блокчейнов — получается, что никто из участником явным образом не заинтересован в поддержке системы по хранению данных и проверке корректности новых узлов. (Идея довольно очевидна, хотя я не сам придумал, а видел, кажется, в статьях у Виталика Бутерина (Ethereum), если нужно, поищу ссылку).

                          Отсюда вывод, что для системы голосования или чего-нибудь еще на основе блокчейна, требуется привязываться к существующей денежной системе (Bitcoin) или создавать новую (Ethereum).

                          В качестве альтернативы можно поставить задачу реализовать систему так, чтобы ее поддерживал кто-то централизовано, но при этом не требовал бы к себе доверия, то есть не мог бы добавлять невалидных узлов, и чтобы целостность блокчейна легко проверялась кем угодно. Я не знаю, возможна ли в принципе такая реализация.
                          • UFO just landed and posted this here
                      +3
                      Отвечу сразу всем выше:
                      1. gbg. Это не умаляет сути понятий «секретный ключ» и «открытый ключ», а перегружать читателя тонкостями криптографии и определений думаю ни к чему. Важна суть.
                      2. ruikarikun. Да, я знаю что закрыли возможность отозвать голос. На сегодня достаточно 1 бита для типа голоса — да/нет. Ну а если завтра снова вернут возможность отзыва, то надо предусмотреть и такой вариант.
                      3. homm. Да, я позже тоже увидел похожие предложения. Но даже если кто то сказал что надо использовать ЭЦП (и верно сказал), то остается вопрос КАК именно. А поскольку у меня степень в области криптографии (извините за нескромность), то я предложил свое детальное решение — как должен выглядеть проверочный вектор, и что в него должно быть включено. Мог конечно где то ошибиться, но пока я ошибки не вижу, нужен взгляд со стороны.
                        +4
                        Я уточню еще раз, чтобы подчеркнуть масштаб трагедии:

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

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

                        То есть относительно терминов типичного изложения RSA произошло переворачивание с ног на голову, которое может неискушенного читателя поставить в тупик с вопросом «Так каким же черт подери ключом шифруют? Толи открытым, толи закрытым?!!» (я ссылку на тостер дал выше). Так как криптография — дело тонкое, наплевательство здесь недопустимо, важна ясность.
                          0
                          «Так каким же черт подери ключом шифруют?» — В посте предельно четко указано каким ключем зашифровываем, а каким расшифровываем. А разошлись мы с Вами по части формулировок. Ценность и суть поста в другом — структура пары (V,S), то есть какая информация там должно быть, чтобы предотвратить возможные атаки. Если вы так категоричны, могу подправить формулировки заменив RSA на ЭЦП, и Encrypt/Decrypt на Sign/Verify. Так будет лучше?
                            +2
                            А теперь представьте себе, что этот пост в сознании читателя напарывается хотя бы на статью из Википедии, где говорят, что в RSA шифруют открытым ключом, а обратно расшифровывают — закрытым. Читатель будет немножко в непонятках.

                            Разумеется, если вы подробно укажите, что RSA применяется по сценарию ЭЦП, да еще со ссылками на хорошие статьи с разъяснениями, откуда что берется, вы сделаете доброе дело!
                            0
                            Открытость/закрытость ключа не зависит от сценария использования. Одна и та же пара ключей используется и для (1) шифрования/дешифрования, и для (2) подписи/верификации. Разница в том, что в первом сценарии вначале используется открытый ключ, потом секретный, а во втором — наоборот.
                              0
                              Это как это она не зависит, если в сценарии криптографии из пары раскрывают модуль, а в сценарии подписи из той же пары нужно раскрыть экспоненту?

                              То есть если человек желает подписывать и шифровать сообщения, ему надо две пары ключей. Если у него будет одна пара, он будет вынужден опубликовать из нее и модуль и экспоненту.
                                +2
                                Я исправил пост, и надеюсь на этот раз все окей. Извините, просто я не по-российским учебникам учился, и для меня ЭЦП — это немного странная аббревиатура. У нас тут RSA обозначает алгоритм, а ключи деляться на «RSA encryption key» и «RSA signing key» по типу применения. Поэтому такая чехарда с формулировками получилась. Надеюсь на понимание.
                                  0
                                  Да, вот теперь все стало на свои места. Непонятный момент «шифрования» заменен на «подписывание», и теперь становится понятным, что:
                                  • Открытым ключом шифруют в сценарии шифрования и верифицируют электронную цифровую подпись
                                  • Закрытым ключом расшифровывают шифрованное и подписывают электронной цифровой подписью

                                  Исчезла путаница в ролях ключей, спасибо!
                                  +2
                                  Я сейчас сходил на вики и освежил свои воспоминания по теме (в частности, я помнил, что для PGP достаточно было одной пары ключей на все случаи жизни). Там описана схема и шифрования, и верификации, и обе они использую одну и ту же пару ключей. Модуль (произведение пары простых чисел) входит в оба ключа (секретный и публичный), кроме того, в публичный входит произвольная (?) экспонента, а в секретный — комплементарная ей экспонента.
                                    0
                                    Перепроверил себя еще раз, вы правы. А я неправильно ставил эксперимент, к сожалению.
                            +1
                            Все это гарантирует наличие отданного голоса — но никак не гарантирует отсутствие «дополнительных» голосов.
                              0
                              О чем, собственно, уже написано в посте:
                              Минусы:
                              • Невозможно отследить сценарий, в котором РОИ может добавлять голоса ЗА или ПРОТИВ для несуществующих СНИЛС. Но этот сценарий возможен и сейчас.
                                0
                                Об этом сказано в «минусах». Думаю, чтобы гарантировать отсутствие дополнительных голосов система должны быть на много сложнее, включая PKI независимый от РОИ, и ЭЦП для каждого пользователя. Это уже инфраструктура. Данное решение — то что можно сделать просто и прямо сейчас без дополнительных затрат.
                                  0
                                  Чтобы проверять отсутствие «дополнительных» голосов, нужно решить проблему «мёртвых душ».
                                  Решение этого вопроса мне видится в открытой части баз данных государственных учреждений. Чтобы было видно, живёт ли владелец данного ID (СНИЛС или что-то другое). Без приватной информации, но записи типа «в таком-то роддоме родился такой-то» должны присутствовать. В такой ситуации нужно быть очень виртуозным, чтобы поддерживать виртуалов от самого рождения и нигде за это время не проколоться.
                                    0
                                    Достаточно узнать список людей, не зарегистрированных на сайте госуслуг… Если не сильно наглеть, то вероятность раскрытия околонулевая.
                                      0
                                      Наоборот, достаточно узнать список людей которые зарегистрированы. Это проще.
                                        0
                                        Это верно. Просто я размышлял о более общей ситуации, типа выборов.
                                        И даже при небольшой вероятности риска десять раз подумают, стоит ли оно того.
                                  • UFO just landed and posted this here
                                      0
                                      Я им ничего не предлагаю и не собираюсь этого делать ни по емайлу, ни за 3000км. Надеюсь что это сделают другие если это кого то будет волновать больше чем меня… И обойдутся, пусть используют шифры на которых 2/3 мира работает. ГОСТ для меня вообще незнакомый зверь. На самом деле ответ на ваш вопрос я вынес в статью — там в конце есть прям список UPD.
                                      Лучше предложите чем можно преодолеть упертость РОИ — это более сложная задача.
                                      • UFO just landed and posted this here
                                      0
                                      Не совсем понимаю зачем такая сложность с критографией.

                                      При голосовании РОИ может просто выдавать пользователю достаточно длинную для уникальности случайную строку.
                                      Пользователь может записать себе куда-нибудь эту строку. Для удобства список всех строк полученных пользователем при голосовании за разные инициативы может быть в личном кибнете РОИ.
                                      По каждой инициативе на РОИ публикуется список всех строк, разделенный на две части — «за» и «против».
                                      Каждый пользователь может проверить, что его код есть в списке и его голос учтен. Более того он может опубликовать строку в другом месте — чтоб каждый мог проверить что он голосовал.
                                      Любое третье лицо может просто посчитать количество строк — голосов «за» и «против».
                                        +2
                                        Допустим я не голосовал, а просто сгенерировал себе такую строку. А потом предоставил ее общественности и заявил «РОИ украла у меня голос, вот моя строка!» — как РОИ будет оправдываться? И как я докажу общественности что я действительно получил эту строку от РОИ? Приводить принтскрин что ли?
                                          0
                                          Да, согласен.
                                            0
                                            Можно продолжить список. РОИ просто одинаковые «случайные» последовательсти будет генерировать для, скажем, двоих. Оба видят себя в списке, а голос учтен один. Оба будут думать что все хорошо. Один голос зачтут, а второй украден.
                                              0
                                              Тут важно, чтобы со страницы инициативы можно было всегда скачать список этих последовательностей (с таймстампами и отсортированный по таймстампам) и каждый мог проверить, что:
                                              • в списке столько же кодов, сколько и голосов
                                              • они все уникальны
                                              • там есть его код (если он голосовал)
                                              • за время N между скачиваниями новые коды добавлялись только в конец списка
                                                0
                                                Все верно. Про кэширование не забудьте, между обновлениями данных может быть 5 минут, за которые у РОИ развязаны руки.
                                                  0
                                                  Тут уже обсуждали, как организовать честное электронное голосование взамен бумажному. Я не разбираюсь в теме, но вроде большинство сошлись во мнении, что это будет работать, и проблема только организационная. Как раз тут этой проблемы нет (у нас чисто электронное голосование).
                                                    0
                                                    Соглашусь с Вами что это возможно, и проблема организационная. Но у нас тут другой случай.
                                                    То о чем Вы говорите — по хорошему нужна полностью другая архитектура, но РОИ этого делать не будут. Они могут сделать лишь незначительные изменения в своей системе, и то возможно, если хорошо попросить. Приведенная схема предлагает минимум затрат для РОИ в конкретном случае, чтобы хорошие инициативы не теряли (не исчезали) живые голоса.
                                        +2
                                        Вот по чеснаку мне эта анонимность на РОИ во многих случаях нафиг не уперлась. Я всё таки надеюсь что меня не будут политически прессовать за то что я поддержал ограничение стоимости авто для чиновников или против цензуры в интернете.

                                        А если это не так то нафига так жить.
                                          0
                                          Я согласен и тоже могу в принципе публично объявить что да, я голосовал за такую то инициативу.
                                          Проблема появляется тогда, где вам Моссух говорит что то о «конфиденциальности личных данных».
                                          И тут нужны железобетонные аргуметы.
                                            0
                                            Очевидное решение — сделать кнопки «Голосовать анонимно» и «Голосовать под своим именем». Кого беспокит конфиденциальность будет анонимом.

                                            Соотношение людей и анонимусов при голосовании какой то инициативы тоже может дать кое какую инфу.
                                              0
                                              будут воровать голоса как сейчас, но с выборкой тех кто «анонимно».
                                          0
                                          Мне кажется, в этой схеме не хватает доказательства того, что голосовали реальные люди.
                                            0
                                            об этом сказано в разделе «минусы» в статье
                                            –2
                                            Все обсуждение ушло в математику крипто-алгоритмы и прочее. Конечто это понятнее и интереснее, но почему-то никто не упомянул совершенно простую и очевидную вещь.

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

                                            До тех пор, пока руководству не интересны наши инициативы, какой смысл обсуждать улучшение реализации этих инициатив.
                                              0
                                              Это в интересах казино доказать клиентам, что карты не крапленые. Иначе никто играть не будет.
                                              А само казино выигрывает чисто на математике. Вот и обсуждаем.
                                              +1
                                              Меня честно говоря смущает другой момент: почему голосование на РОИ тайное? Сама инфраструктура ЭЦП подразумевает идентификацию с целью неоткрекаемости подписанных сведений. Можно сделать список подписей открытым хотя бы для какого-нибудь общественного наблюдательного совета и пусть общественники уже сами ищут недостоверные или скомпрометированные ЭЦП.
                                                0
                                                На Ваше предложение сделать список подписей открытым Массух скажет (точнее уже так ответил на подобное предложение), что это будет нарушать «конфиденциальность личных данных», поэтому отказ. Никаких проверочных общественных организаций не будет — угроза утечки личных данных.
                                                  0
                                                  «Конфиденциальность личных данных» нарушает личная электронная подпись, созданная с целью идентификации пользователя! Да что не так с этими людьми! Голос на РОИ отправляется путем подписания ЭЦП петиции, если кого-либо интересовала конфиденциальность, то для подписания генерировали бы анонимную (желательно разовую) подпись на основание уже созданного закрытого ключа.
                                                    +1
                                                    1. Голосование тайное, а не открытое. Есть такое понятие как «тайна голосования» 2. Личная ЭЦП не создана для идентификации пользователя, а создана для верификации связи между каким либо событием (или данными) и пользователем. 3. Почему вы считаете что голос на РОИ подписывается с помощью ЭЦП пользователя? Откуда у Вас такая информация? И где, в таком случае, можно посмотреть открытые ключи всех людей на РОИ? Буду признателен.
                                                  +1
                                                  Тайное оно чтобы не было никаких отрицательных последствий для проголосовавшего/не проголосовавшего. Понятно, что «в верхах»-то список всегда смогут получить, но «на местах» его практически наверняка не смогут увидеть и при этом сохранить в тайне, а если он выплывет — это будет гарантированный скандал, т.к. подлинность такого списка верифицируется на раз-два.
                                                  –1
                                                  Все проблемы от анонимности.
                                                  Нужно публиковать список проголосовавших и все.

                                                  Если нет, то SHA(время голосования+ИД инициативы + СНИЛС).
                                                    0
                                                    А как потом проверить, что Константинопольский Иван Табуретович действительно существует?
                                                      0
                                                      Так… я, кажется, нашел дыру в системе. Но в целом знаю как ее прикрыть. Куда писать — тут или сразу в статью править?
                                                        0
                                                        Это-то как раз элементарно.
                                                        БД ФИО и СНИЛСов если не в открытом доступе, то довольно широко распространены.
                                                          0
                                                          Так это же прекрасный источник фейков. Это надо вместе с каждым проголосовавшим выгладывать сорокасекундное видео, где он размахивает свежей газетой, а камера его облетает. И то, в связи с последними прорывми в графике и анимации, это скоро будет неактуально.
                                                            0
                                                            Вы так говорите, будто для того, что бы получить ЭЦП достаточно просто собственного желания и полное отсутствие документов.
                                                              0
                                                              А где будет root of trust? И почему ему можно будет доверять? Если РОИ — нагенерируют себе сколько захотят.
                                                      0
                                                      Друзья, я нашел дыру в системе. В статью добавил изменения для решения проблемы. Также добавил подкатом сценарий атаки и мотивацию.
                                                        0
                                                        Зачем совать UserSecret в H и усложнять себе жизнь? Достаточно было добавить его в V, всё-равно он весь подписывается.
                                                          0
                                                          Чтобы защитить СНИЛС от третьих лиц
                                                            0
                                                            В первой версии СНИЛС и так был защищен ключом SK.
                                                              0
                                                              А в этой самим пользователем. Ведь и СНИЛС и номер инициативы ему известен. В отличие от первой версии юзер может проверить правильность H.
                                                                0
                                                                Зачем так проверять правильность H, если подписывается и публикуется весь V? Если в V есть UserSecret, то уже украсть голос не получится, не зависимо от того что в H. Зато теперь H перестал быть уникальным идентификатором голоса.
                                                                  +1
                                                                  Там подкатом есть мотивация. Если коротко — РОИ может двум юзерам выдавать один и тот же код (V, S) в пределах одного окна кэша, а счетчик увеличивать на 1 вместо 2. Чтобы это предотвратить, H должен быть уникальным и проверяемый. Согласны?

                                                      Only users with full accounts can post comments. Log in, please.