Кілька років тому ми почали проект «Відкриті голосування», покликаний створити систему для зручного проведення надійних і перевірених голосувань. На жаль, справа обмежилася тільки теоретичними розробками, а в плані конкретних реалізацій ми так і не просунулися вперед. Не так давно я почав розмірковувати - чому так? Я сам розробник. У команді теж є кілька розробників. Так що ж нам заважає? І дійшов висновку, що головна перешкода - занадто великі початкові плани. Тому я вирішив почати з малого - з інструменту для простого використання електронного підпису звичайними людьми. Причому, не тільки для нашого проекту, а для будь-якого сайту, який вважатиме це за необхідне.
На даний момент це рішення готове і я хочу поділитися ним з громадськістю. Вихідні коди поширюються під відкритою ліцензією (посилання в кінці статті).
Отже, що ж я пропоную...
Мобільний додаток, що знаходиться на смартфоні користувача, забезпечує всю базову криптографію - створення ключів, їх зберігання і підписання документів. Документи є набором даних та шаблоном для їх відображення. Зараз доступні два типи шаблонів: простий список і HTML шаблон.
Користувачі ідентифікуються за хешем їх публічного ключа. Сайти, які запитують підписання будь-яких документів (далі - «клієнти») ідентифікуються за їхнім символьним ідентифікатором (у загальному випадку - за доменом сайту). У системі так само присутній проміжний елемент, який забезпечує передачу пакетів між користувачем і клієнтами - проксі сервер. Відразу хочу зауважити, що на проксі-серверах не доступна інформація про підписувані документи, оскільки вона шифрується відкритим ключем користувача.
Порядок роботи
Природно, що сайт клієнта міг відправити документ на підписання певному користувачеві, йому потрібно спочатку якимось чином отримати відкритий ключ користувача і прив'язати його до своєї внутрішньої логіки (наприклад, до логіна користувача). Для цього призначена процедура «Реєстрації підпису». Полягає вона в наступному:
- сайт видає користувачеві пару рядків: свій ідентифікатор (зазвичай домен) і одноразовий код;
- користувач вводить ці дані в мобільний додаток який формує пакет з наступними даними: своїм відкритим ключем і одноразовим кодом, який ним підписаний. І відправляє цей пакет на проксі сервер;
- сайт клієнта отримує від проксі сервера цей пакет і прив'язує публічний ключ до своєї логіки.
Після цього, у разі необхідності підписання документа на сайті:
- клієнт формує документ на підписання (включаючи внутрішній ідентифікатор документа), шифрує дані документа відкритим ключем користувача, встановлює для нього ідентифікатор користувача за його публічним ключем і відправляє на проксі;
- користувач, коли йому буде зручно, перевіряє наявність нових документів на підпис;
- при отриманні такого документа користувач розшифровує його дані і формує з них, шаблони і деяких інших атрибутів документа його підпис;
- отриманий підпис він відправляє на проксі сервер разом з ідентифікатором клієнта і внутрішнім номером документа. Самі дані документа не відправляються (вони збережені у клієнта);
- клієнт отримує підпис, за внутрішнім ідентифікатором витягує оригінальні дані документа, перевіряє підпис і, якщо він коректний, зберігає його для подальших дій.
На цьому цикл закінчується.
Підсумки та перспективи
Звичайно, я можу визнати що система не ідеальна. Але це перший варіант і, що найважливіше, він є і він працює. Так само важливо те, що його можна використовувати не тільки для цілей нашого проекту, які пов'язані з реалізацією голосувань. Його можна використовувати, наприклад, для забезпечення двофакторної авторизації. Або для захисту критичних дій користувача типу зміни пароля або прив'язаного до логіна e-mail (такий опціональний функціонал вже впроваджується на одному з популярних сайтів). Це базовий інструмент і на його основі можна побудувати все що завгодно - справа обмежена лише нашою фантазією.:)
У планах багато доопрацювань. Мобільний клієнт зараз має самий мінімальний функціонал - тільки реєстрацію на сайті і підписання або відмову в підписанні документа. У планах на наступну версію - запам'ятовування всіх документів користувача в мобільному додатку, реалізація можливості зв'язку з сайтами клієнтів безпосередньо (без використання проксі серверів), якщо вони підтримують цю можливість, а так само створення версії для iOS (зараз доступна версія мобільного додатку тільки для Android).
Проект повністю відкритий і ми вітаємо як власні розробки на основі нашого коду, так і допомогу нашому проекту (наприклад, нам-би дуже не завадила допомога в портуванні програми на iOS).:)
Ну і посилання:
Мобільний додаток в Google Play Market: GPLVote Sign Doc
Початковий код мобільної програми на GitHub
Тестовий сайт клієнта для тестування мобільного додатку
Perl додаток GPLVote::SignDoc::Client, що полегшує прикрутку потрібного функціоналу до сайтів клієнтів
Початковий код тестового клієнта на GitHub (Perl)