Проект "Свободные голосования"

Задумался о способе аутентификации пользователей (п.1.2). По идее - это одна из самых ответственных и трудоемких задач.

Опять-же, я вижу здесь несколько способов реализации:

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

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

3. Система взаимной подписи. Насколько я понимаю, такая практикуется в системе pgp (gpg). Когда собираются люди и видя друг друга перед собой, подписывают сертификаты друг друга. Такой способ хорош тем что не требует специальных офисов, но плох в том, что не исключена возможность создания большой группы "троллей" с взаимным подписыванием сертификатов. Можно как-то обезопаситься от этого попробовав отслеживать связи при подписывании и если обнаруживается изолированная группа, то ставить такие подписи под сомнение. И, естественно, если обнаруживаются такие "тролли", то все сертификаты, подписанные им сразу выводятся в статус "сомнительные". В данном случае необходимо что-бы к голосоанию допускались лишь те пользователи, надежность которых, вычисляемая на основе всех, подписавших его сертификат, была выше некоторой границы.

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Пришла интересная мысль по поводу вычисления надежности.

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

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

Немного сумбурно, возможно что-то не совсем додумано, но сам принцип, возможно, достоин того что-бы его обсудить.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Еще один вариант регулирования подписи.

Пользователь, имеющий уровень допуска "1" или выше, может подписывать сколько угодно много пользователей, но с соблюдением следующих принципов:

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

2. Если при подписывании следующего пользователя, уровень надежности одного из уже подписанных снизиться ниже "1", подпись запрещается.

3. Подписывать пользователей могут только пользователи с уровнем надежности "1" или выше.

4. Подписание дает пользователю "надежность" с определенным коэффициентом меньшим 1 (величина H(1)). Т.е. для получения одним пользователем уровня надежности "1" или выше, необходимо несколько подписей.

6. Пользователю запрещается подписывать сертификаты тех пользователей, которые подписали его сертификат.

Если взять вариант двух пользователей с коэффициентом > 0.5 (т.е. два пользователя имеют право подписать третьего), тогда такая подпись будет регулироваться формулой:

H(n) = H(1)+H(1)/n;

где H(n) - коэффициент подписи передаваемый n-му подписываемому.

Таким образом, если приравнять H(n) = 1, можно найти сколько пользователей можно подписать в данном случае в зависимости от начального значения H(1) (передаваемый коэффициент при подписывании одного пользователя):

n = H(1)/(1 - H(1));

Например, при H(1) = 0.9, два пользователя могут подписать 9 пользователей.

Можно найти так-же величину H(1) для того что-бы два пользователя могли подписать определенное количество пользователей:

H(1) = 1/(1 + 1/n);

Например, для того что-бы два пользователя могли подписать 1000 пользователей, коэффициент H(1) должен быть 0,999000999. Вполне возможно что таким образом можно попробовать регулировать возможности подписывания с течением времени.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

Хотя, не помешает и подумать по поводу параллельного использования обеих систем. Может быть одно другому и не помешает.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Излишняя сложность системы идентификации... будет наруку врагам...облачной демократии (а это практически все стоящие у власти и оппозиция тоже) внутри своих партий никто из них не выдержит облачной демократии...
убежден что уровень используемый например Альфа-банком ...дополнительный обратный пароль через телефон..достаточный...
или даже уровень защиты в Контакте....

И вот еще мысль...Уровень защиты при создании акаунта это одно...а уровень защиты при каждодневных решениях это другое...он может быть гораздо ниже...

В конце концов можно ужесточить наказание за взлом именно этой системы...

Наруку врагам я имею ввиду будет служить козырем на дебатах...(весомым аргументом против введения)

Ну, алгоритмы архивирования и шифрования тоже довольно сложны в описании. Тем не менее, все ими пользуются без особых проблем.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68