Распределенная система

Материал из Сервис Облачной Демократии
(Различия между версиями)
Перейти к: навигация, поиск
Строка 95: Строка 95:
 
Непонятно каким образом получить достоверные подписи граждан РФ. Не все настолько хорошо работают с компьютером, чтобы самостоятельно установить необходимое программное обеспечение, помнить пароли, хранить закрытые ключи. Без решения этой проблемы система носит лишь академический характер и лишена практического смысла
 
Непонятно каким образом получить достоверные подписи граждан РФ. Не все настолько хорошо работают с компьютером, чтобы самостоятельно установить необходимое программное обеспечение, помнить пароли, хранить закрытые ключи. Без решения этой проблемы система носит лишь академический характер и лишена практического смысла
  
== Техническая информация ==
 
=== Структура пакетов ===
 
Предлагаю следующую структуру пакетов:
 
* <type> - 1 байт - Тип пакета. Т.к. у многих пакетов их размер может быть жестко фиксированным в зависимости от типа, тип лучше размещать в первом байте;
 
* <packet> - пакет;
 
Если тип пакета подразумевает его идентификацию, то в начале <packet> следует
 
* <id> - 16 байт - идентификатор пакета (UUID);
 
Если тип данных подразумевает определенный размер этих данных, то далее в <packet> для таких типов содержатся данные.
 
Если тип данных переменного размера, то далее следует:
 
* <size> - 2 байта - общий размер данных пакета;
 
* <data> - данные пакета;
 
Данные пакеты представляют из себя набор записей вида:
 
* <field type> - 1 или 2 байта - [[Коды данных|тип поля]];
 
* <field record> - Данные поля;
 
Если данные поля не фиксированного размера, то в <field record> сохраняются данные с указанием размера:
 
* <field size> - 2 байта - размер данных поля;
 
* <field data> - данные поля;
 
 
=== Типы пакетов ===
 
Требует согласования с разработчиками. Возможно, не актуально.
 
 
{| border="1" cellpadding="2" cellspacing="0" style="text-align: center;"
 
!Код типа пакета
 
!Размер данных
 
!Идентифицируемый
 
!Описание типа
 
|-
 
|0x00
 
|0
 
| -
 
|align="left" |Пинг
 
|-
 
|0x01
 
|0
 
| -
 
|align="left" |Понг
 
|-
 
|0x02
 
| ~
 
| +
 
|align="left" |Запрос на данные
 
|-
 
|0x03
 
| ~
 
| +
 
|align="left" |Публичный ключ
 
|-
 
|0x04
 
| ~
 
| +
 
|align="left" |Голосование
 
|}
 
=== Коды данных ===
 
Требует согласования с разработчиками. Возможно, не актуально.
 
 
На этой странице собраны коды для различных данных в системе.
 
 
{| border="1" cellpadding="2" cellspacing="0" style="text-align: center;"
 
!Мнемокод
 
!Числовой код
 
!Назначение данных
 
|-
 
|NULL
 
|0x00
 
|align="left" |Пустые данные
 
|-
 
|U.PKEY.FP
 
|0x01
 
|align="left" |Отпечаток персонального ключа пользователя
 
|-
 
|U.PTKEY.FP
 
|0x02
 
|align="left" |Отпечаток транспортного ключа пользователя
 
|-
 
|U.BD
 
|0x03
 
|align="left" |Дата рождения пользователя из программы
 
|-
 
|U.TR
 
|0x04
 
|align="left" |Основная территория пользователя из программы
 
|-
 
|U.ATR
 
|0x05
 
|align="left" |Дополнительная территория пользователя из программы
 
|-
 
|U.TID
 
|0x06
 
|align="left" |Налоговый идентификатор пользователя из программы
 
|-
 
|U.SID
 
|0x07
 
|align="left" |Социальный идентификатор пользователя из программы
 
|-
 
|U.PKEY
 
|0x08
 
|align="left" |Публичный персональный ключ пользователя
 
|-
 
|U.PTKEY
 
|0x09
 
|align="left" |Публичный транспортный ключ пользователя
 
|-
 
|S.TYPE
 
|0x10
 
|align="left" |Тип голосования
 
|}
 
=== Коды типов голосований ===
 
Требует согласования с разработчиками. Возможно, не актуально.
 
 
{| border="1" cellpadding="2" cellspacing="0" style="text-align: center;"
 
!Код
 
!Описание
 
|-
 
|0x00
 
|align="left" |Открытое голосование в субъекте
 
|-
 
|0x01
 
|align="left" |Тайное голосование в субъекте
 
|-
 
|0x02
 
|align="left" |Голосование по субъекту (создание, изменение параметров)
 
|-
 
|0x03
 
|align="left" |Вотум недоверия
 
|}
 
  
 
[[Category:Распределенная система]]
 
[[Category:Распределенная система]]

Версия 21:06, 10 марта 2012

Содержание

Концепция

Общие сведения

  1. Изначально по сети будут распространятся IP адреса работающих систем;
  2. Подключение пользователя к системе будет состоять из:
    • Генерации персонального ключа;
    • Генерации транспортного ключа;
    • Отправки в сеть публичной части персонального и транспортного ключа;
    • Запрос из сети анонсов (краткой информации) об имеющихся субъектах;
  3. Любой пользователь может подписать доверие к достоверности данных ключа после соответствующей проверки достоверности указанных в нем данных;
  4. Любой пользователь может подписать доверие к подписи ключа;
  5. Любой пользователь может подписать недоверие к достоверности ключа после неудачной процедуры удостоверения;
  6. Любой пользователь может подписать недоверие к подписи ключа;

Субъекты голосований

  1. Субъекты верхнего уровня могут создаваться любым пользователем;
  2. Подсубъекты создаются по результатам голосования в основном субъекте по правилам данного субъекта. При этом фильтрация в них должна настраиваться так что-бы все пользователи основного субъекта стали пользователем одного из вновь образованных;
  3. Необходимая степень авторизации пользователя (распределение подписей доверия и недоверия у ключа) будет регулироваться в свойствах субъекта;
  4. В качестве одного из фильтров субъекта может выступать:
    • Фильтр по любому значению в ключе пользователя;
    • Ссылка на сервер авторизации субъекта голосования;
  5. Изменение свойств субъекта голосования будет производиться только с помощью голосования;
  6. Возможны "закрытые" субъекты голосований, данные которых в общей сети будут шифроваться и будут доступны только участникам субъекта;

Голосования

  1. Голосование может инициироваться любым пользователем субъекта голосований;
  2. Процедура тайного голосования:
    • Инициирование голосования;
    • Отправка пользователями по сети голоса в голосовании (зашифрованный голос + подпись разными путями);
    • По окончании голосования необходим некоторый резервный период на распространение голосов по сети;
    • По окончании резервного периода начинается "период проверки голосов и подписей", в течении которого каждый клиент проверяет наличие у него всех голосов и подписей (соответствие количества голосов количеству подписей). В данном случае возможно несколько проблем:
      • если не хватает голосов, то клиент отправляет в сеть запрос на голоса данного голосования. Если по окончанию этого периода голосов все еще не хватает, то недостающие голоса признаются утерянными (аналог испорченного бюллетеня). Если кто-то из проголосовавших не обнаружит своего голоса в результатах, можно провести отслеживание по цепочке отправки от данного пользователя.
      • если голосов больше чем подписей, тогда клиент рассылает запрос на все подписи по данному голосованию. Если по окончанию резервного периода подписей все еще не хватает, инициируется автоматическая процедура обнаружения неподписанных голосов (как Юрий описал в последнем сообщении);
    • Если проверка соответствия количества голосов и подписей проходится, начинается третий период - "период открытия данных о голосах". В течении которого клиенты в автоматическом режиме (можно с подтверждением пользователем) рассылают одноразовые публичные ключи которыми можно расшифровать их голос. В определенную часть завершения данного периода если остаются нераскрытые голоса, рассылаются запросы на раскрытие данного голоса.
    • Каждый клиент на основании имеющихся у него данных формирует результат голосования. Если по окончанию предыдущего периода остаются нераскрытые голоса, они признаются "испорченными бюллетенями" и игнорируются при формировании результатов.
  3. Открытое голосование будет происходить аналогичным образом, но голос будет отправляться вместе с подписью в голосовании. И будут отсутствовать этапы, связанные с согласованием количества голосов и подписей;

Объяснение процедуры тайного голосования

Прежде всего, предполагается наличие у пользователя следующих вещей:

  1. Главного авторизованного ключа
  2. Одноразового НЕ персонализированного ключа (пара открытый/закрытый ключ) для каждого отдельного голосования. До окончания голосования публичный ключ этой пары держится в тайне.

Пользователь голосует формируя два блока данных:

  1. Свой голос в голосовании, зашифрованный одноразовым ключем. Этот блок подписывается обычной персонализированной подписью пользователя.
  2. Свою подпись об участии в голосовании. Формируется обычным персонализированным ключем.

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

Взаимный контроль

Взаимный контроль означает то, что в системе нет контролирующих органов или отдельных людей для этого, которые обладают большими возможностями чем остальные. Для этих целей в системе будет служить система подписания своей ЭЦП определенных данных других пользователей. Подписываемый таким образом пакет будет состоять из следующих частей:

  1. Тип подписи:
    • Удостоверение данных
    • Уровень доверия к подписи
    • Удостоверение данных субъекта в ключе пользователя
  2. Ссылка на подписываемые данные:
    • Идентификатор или список идентификаторов в ключе пользователя
    • Отпечаток ключа пользователя
  3. Уровень доверия указанным данным: число от -10 (полное недоверие) до 10 (полное доверие)
  4. Текстовый комментарий

Подтверждение достоверности идентифицирующих данных

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

Установка доверия к подписи

Вы можете указать свой уровень доверия к подписи определенного пользователя и/или ключа. Этот механизм призван защитить систему от необоснованных действий со своей подписью. Ее действие может быть признано ничтожным при наличии соответствующего количества подписей, устанавливающих низкий уровень доверия к ней.

Удостоверение данных субъекта в ключе

Некоторые субъекты для своих участников могут требовать наличия в ключе определенных данных, подписанных участниками субъекта (например, просто идентификатора субъекта). По этим данным, например, может определяться имеет-ли право данный пользователь голосовать в субъекте.

Другие типы подписей

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

Безопасность

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

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

"Вброс" голосов при открытом голосовании

Т.к. каждый голос подписывается персональной ЭЦП, предварительно заверенной определенным образом, вброс голосов возможен только при подделке и мошенническом удостоверении GPG ключа.

Анонимность при тайном голосовании в распределенной системе

В данном варианте анонимность будет обеспечиваться многими факторами:

  1. Голос будет передаваться в систему в зашифрованном виде. Шифрование будет осуществляться одноразовым анонимным ключем.
  2. Расшифровка голоса будет производиться лишь по окончанию голосования при признании его состоявшимся (отсутствия разницы в поданных голосах и подписях об участи в голосовании).
  3. Цепочка, раскрывающая анонимность голоса может быть отслежена лишь в случае согласия большого числа участников сети. Что является крайне маловероятным событием после завершения голосования.

Подделка или "вброс" голоса при тайном голосовании в распределенной системе

В следствии того, что путь голоса по сети будет документироваться, незаметно вбросить его в систему будет нереально. При таком вбросе будет наблюдаться несоответствие количества поданных в голосовании голосов и количества подписей в нем. Это является следствием того, что никто не может гарантированно не допустить в распределенную сеть какой-то определенный голос. В силу принципа распространения в ней информации. При обнаружении такого несоответствия еще ДО открытия данных о зашифрованных голосах голосование признается не состоявшимся и автоматически инициируется сбор информации о путях всех пакетов. А т.к. они по всему пути прохождения подписываются авторизованными подписями, источник проблемы в виде "крайнего" персонального сертификата обнаруживается достаточно быстро. Что немаловажно, при такой процедуре совершенно не страдает тайна голоса (смотрите начало абзаца). Дальнейшие действия по отношению к владельцу данного сертификата могут носить различный характер. При такой системе, так-же невозможно вбросить в систему голос, не подписанный заверенным определенным образом персональным ключем. Он просто не начнет распространяться по сети.

Подделка ключей GPG

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

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

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

Метка времени в подписи

Пока GnuPG не позволяет создавать электронную подпись без времени ее создания. Это может представлять некоторую проблему с точки зрения сопоставления времени подписи с онлайн-данными, например, по тайному опросу. Поэтому, пока принято решение не публиковать список участников тайных опросов. Возможно, мы будем публиковать эти списки не в режиме онлайн, что несколько снизит опасность, связанную с наличием времени в подписи.

Получение достоверных подписей

Непонятно каким образом получить достоверные подписи граждан РФ. Не все настолько хорошо работают с компьютером, чтобы самостоятельно установить необходимое программное обеспечение, помнить пароли, хранить закрытые ключи. Без решения этой проблемы система носит лишь академический характер и лишена практического смысла

Личные инструменты
Пространства имён
Варианты
Действия
Навигация
Инструменты