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

В общем, как-то мы застряли.

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

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

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

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

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

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

Я предлагаю вот такую процедуру:
1. Пользователь регистрируется на сайте клиента обычным образом и входит под своим логином.
2. На сайте будет кнопка "Привязать электронную подпись", по нажатию на которую сайт клиента выдаст пользователю "название сайта" и "одноразовый код". При этом, клиентский софт должен запомнить соответствие одноразового кода конкретному пользователю сайта (конкретному логину).
3. Пользователь запускает мобильное приложение и выбирает пункт "Регистрация на сайте". Вводит в поля полученные на сайте клиента данные и делает отправку "запроса на регистрацию". Этот запрос отправляется с подписанием с помощью ЭЦП, одноразового кода, полученного на этапе 2 и публичным ключем пользователя.
4. Клиент, получив с прокси сервера документ "запрос на регистрацию", проверяет ЭЦП кода с помощью публичного ключа вложенного в этот документ и, если все нормально, привязывает данный публичный ключ к пользователю, которого находит по одноразовому коду (связь с которым сохранена ПО клиента на шаге 3).

После этого получается что пользователю на сайте клиента соответствует определенный публичный ключ пользователя.

Процедура подписание документа следующая:
1. Сайт клиента на определенные действия пользователя, требующие подписания, создает специальный "запрос на подписание". В этом запросе будет передаваться: название сайта, внутренний идентификатор документа, хэш публичного ключа пользователя (как идентификатор ключа для более удобного поиска); данные документа, зашифрованные публичным ключем пользователя; шаблон для показа данных документа.
2. Далее этот документ отправляется клиентом на прокси сервер (с авторизацией по логину и паролю, который выдается клиенту на этапе ручной регистрации);
3. Пользователь нажимает на мобильном приложении кнопку "Проверить новые документы" и по идентификатору ключа скачивает новые документы с прокси-сервера.
4. Во всех скаченных документах расшифровываются данные документа и документ выдается пользователю в форме на подписание.
5. Если пользователь выбирает "Подписать", то формируется ЭЦП в которую входят: сайт документа, идентификатор документа, данные документа, шаблон документа. Сразу замечу, извлечь данные из подписи невозможно.
6. Документ "Подпись" отправляется на прокси сервер. В этот документ входят: сайт документа, идентификатор документа, подпись документа.
7. Клиент получает документы типа "Подпись" с прокси сервера, по идентификатору документа находит нужный документ, проверяет корректность подписи и, если она правильная, сохраняет ЭЦП в документе и помечает его как "подписанный".
8. После обработки подписи, клиент формирует специальный документ "подтверждение обработки подписи" и отправляет его пользователю.
9. Пользователь, получив документ о подтверждении обработки подписи, помечает локальную копию как "обработано".

В данный момент готового мобильное приложение Android, доступное пока по урл http://ru.gplvote.org/signdoc.apk

Ссылка для тестирования мобильного приложения в Google Play: https://play.google.com/store/apps/deta ... te.signdoc
Исходный код мобильного приложения: https://github.com/UncleAndy/sign_doc
Perl модуль для клиентов: http://search.cpan.org/~uncleandy/GPLVo ... /Client.pm
Тестовый сайт клиента: http://client_signdoc.gplvote.org/
Исходный код тестового сайта: https://github.com/UncleAndy/sign_doc_client

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

В принципе, все работает. Тестовый сервисный сайт вот тут - http://client_signdoc.gplvote.org/

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Присоединится к тестированию приложения на Google Play можно вот тут: https://play.google.com/apps/testing/or ... te.signdoc

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Пришли мысли о дальнейшем развитии мобильного приложения:

Программа на ближайшее развитие:

- сделать прогресс-бары при долгих операциях;
- сделать страницу настройки (таймоут для кэшированного пароля и т.д.);
- сделать страницу "Перезакачать документы" - будет качать все документы за некоторый период (например, за сутки) и проверять на предмет их наличия в сохраненной локально базе обработанных документов)

Стратегически необходимо продумать вариант взаимодействия мобильного приложения с сайтом клиента напрямую и другие варианты взаимодействий: через электронную почту, через различные системы мгновенных сообщений (скайп, ICQ, Jabber) и т.д. Это снимет проблему атаки на прокси-сервера.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Статистика тестирования мобильного приложения по моделям телефонов и версии Android (буду дополнять что-бы было в одном месте):

Удачное тестирование:
- HTC One Dual Sim (Android 4.4.3)
- Sony Xperia S (Android 4.1.2)
- Lenovo A3300-HV (Android 4.4.2)
- Texet X-medium (Android 4.2.2)

Неудачное тестирование:

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Замеченные проблемы:

+ Если в диалоге подписания нажать кнопку "Назад", то все предоставленные на подписание документы не загрузятся при следующей проверке. Время последней проверки нужно запоминать только если в процессе подписания не было нажатия кнопки "Назад".

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

+ Сделать прогресс-бар при инициализации.

+ При нажатии на "Отказать" в диалоге подписания выдавать промежуточный алерт с запросом подтверждения. Иначе кнопка "Отказать" может нажаться у нескольких документов.

+ Реализовать гибридный алгоритм шифрования (RSA+AES) для больших данных;

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Следующее что нужно сделать касается уже логики работы.

+ Первым делом нужно сделать так, что-бы пользователю показывались все данные независимо от того, какие пункты описаны в шаблоне типа LIST. Если для определенных данных нет описания в шаблоне - вместо заголовка выводить метку "<нет описания>";

+ Улучшить алгоритм шифрования больших документов. Случайный IV, который сохраняется вместе со случайным ключем AES;

+ Продумать способ задания формата документа в виде html. С защитой от скрывания каких-либо данных.

Версия с данным набором функционала - 1.1. Последующие разработки будут только с увеличением номера версии.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

+ Сделать хранение всех документов в мобильном приложении. Для "отложенных" документов и "отказных" документов сделать возможность их подписать.

+ Сделать возможность отправлять от клиента пользователю сообщение о подтверждении получения и обработки подписанного документа.

+ При наличии входящих документов на подписание или подтверждений об обработке, в конце обработки открывать экран со списком документов.

+ В списке документов добавить кнопку обновления информации, по которой будет срабатывать функционал кнопки "Проверить текущие документы".

+ Убрать кнопку "Проверить новые документы".

+ В списке документов давать возможность подписывать документы только если доступен интернет.

+ Сделать список документов основным окном приложения.

+ При просмотре документа выдавать полные данные о его текущем статусе, время создания, время последнего изменения статуса и время прихода подтверждения о подписании.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

+ Реализовать возможность подписания документов из соседнего приложения.

+ Добавить одним из атрибутов документа SIGN_REQUEST поле sign_url, которое может установить клиент. Если это поле будет установлено, то подпись после подписания будет отправлена на данный URL POST запросом. При положительном ответе от данного URL подпись помечается как "Обработана".

+ Поле sign_url нужно записывать в БД мобильного приложения и делать отправку при последующем подписании именно на этот URL.

+ Сделать возможность проходить регистрацию подписи сканированием QR-кода и отправкой регистрации на клиент напрямую.

+ Описать в wiki все протоколы мобильного приложения "Sign Doc" для возможности использования его третьей стороной: API взаимодействия клиента с прокси-сервером и API взаимодействия мобильного приложения с приложением "Sign Doc" напрямую.

+ Сделать вызов считывателя QR-кодов прямо из приложения. С открытием считанного URL стандартным системным образом.

+ Сделать возможность просмотра идентификатора публичного ключа.

+ В коде приложения не использовать в setSeed время

+ Удалить из приложения и perl модуля весь функционал для работы с прокси серверами. В perl модуле перевести или удалить русские комментарии

+ Заменить при подписании документа хэш для подписания с SHA1 на SHA256 (в приложении и в модуле GPLVote::SignDoc::Client)

+ Для всех запросов на подписание с большими зашифрованными данными (RSA+AES) в заголовке кроме AES ключей занести еще и контрольную сумму данных в виде SHA256. И проверять ее при расшифровке. Изменения внести сначала в perl модуль, затем в приложение.

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

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

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

- При подписании группы документов сделать эффект листания при смене документа;

- Сделать в настройках приложения систему фильтров, которые можно было-бы настроить на автоматическое подписание документов по их сайту и типу (по шаблону и т.д.);

- Сделать возможность использования любого типа ключа (добавить возможность генерировать и использовать ключ на основе эллиптических кривых);

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

- Добавить возможность в приложении вести список идентификаторов (и публичных ключей) "знакомых"

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

- Сделать возможность изменить основной пароль. Обязательно с запросом и проверкой старого пароля.

- Сделать возможность резервного копирования секретного и открытого ключа на внешнюю память с шифрованием длинным паролем.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Создать систему использования "аннулирующего ключа":

1+. При генерации основной пары ключей генерируется пара "аннулирующий ключей". Она храниться в приложении и может использоваться для процедуры "Отмены ключа".

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

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

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

5. Все URL сайта, принимающие регистрацию подписей, должны принимать так-же пакеты с аннулированием ключей. Пакет должен иметь тип "CANCEL_KEY" и включать в себя:
- идентификатор основного ключа (действие которого отменяется);
- время отмены действия ключа (UNIXTIME GMT);
- подпись ключем аннулирования идентификатора основного ключа и времени отмены его действия;
- публичная часть пары ключей аннулирования;

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68