A simple solution for using EDS

A few years ago we launched the Open Voting project, designed to create a system for conveniently conducting reliable and verifiable polls. Unfortunately, the matter was limited only to theoretical developments, but in terms of concrete implementations, we have not moved forward. Not so long ago, I began to think - why so? I am a developer myself. There are several developers in the team too. So what's stopping us? And he came to the conclusion that the main obstacle was too big initial plans. Therefore, I decided to start small - with a tool for simple use of an electronic signature by ordinary people. Moreover, not only for our project, but for any site that deems it necessary.



At the moment this decision is ready and I want to share it with the public. Source codes are distributed under open license (links at the end of the article).



So, what am I suggesting ...



The mobile application located on the user's smartphone provides all the basic cryptography - the creation of keys, their storage and signing of documents. Documents are a set of data and a template for displaying them. Two types of templates are now available: a simple list and an HTML template.

')

Users are identified by their public key hash. Sites requesting the signing of any documents (hereinafter referred to as “clients”) are identified by their symbolic identifier (in general, by the site’s domain). The system also has an intermediate element that provides packet transfer between the user and clients - a proxy server. Just want to note that the proxy servers do not have information about the documents being signed, because it is encrypted with the user's public key.

Operating procedure

Naturally, in order for the client's site to send a document for signing to a specific user, he must first somehow obtain the user's public key and bind it to his internal logic (for example, to the user's login). The “Signature Registration” procedure is intended for this. It consists in the following:



- the site gives the user a couple of lines: their ID (usually a domain) and one-time code;

- the user enters this data into a mobile application that forms a packet with the following data: his public key and one-time code that is signed by him. And sends this packet to the proxy server;

- the client's site receives this packet from the proxy server and binds the public key to its logic.



After that, if necessary, sign the document on the site:



- the client forms the document for signing (including the internal document identifier), encrypts the document data with the user's public key, sets the user ID for it using its public key and sends it to the proxy;

- the user, when it is convenient for him, checks the availability of new documents for signature;

- upon receipt of such a document, the user decrypts his data and forms a signature from it, a template and some other attributes of the document;

- he sends the received signature to the proxy server along with the client ID and internal document number. The document data itself is not sent (it is stored at the client);

- the client receives a signature, extracts the original document data using an internal identifier, checks the signature and, if it is correct, saves it for further action.



This ends the cycle.

Results and prospects

Of course, I can admit that the system is not perfect. But this is the first option and, most importantly, it is and it works. It is also important that it can be used not only for the purposes of our project, which are associated with the implementation of votes. It can be used, for example, to provide two-factor authorization. Or to protect critical user actions such as changing a password or an e-mail associated with a login (such optional functionality is already being implemented on one of the popular sites). This is a basic tool and on the basis of it you can build anything you want - the case is limited only by our imagination. :)



The plans of many improvements. The mobile client now has the most minimal functionality - only registration on the site and signing or refusing to sign the document. The plans for the next version include storing all user documents in a mobile application, implementing the ability to communicate with client sites directly (without using proxy servers), if they support this feature, as well as creating a version for iOS (a version of the mobile application is available only for Android).



The project is completely open and we welcome both our own development based on our code, and assistance to our project (for example, we would be very much helped by porting the application to iOS). :)



Well, links:



Mobile app in Google Play Market: GPLVote Sign Doc

Mobile app source code on github

Test client site for mobile app testing

Perl module GPLVote :: SignDoc :: Client, which facilitates the necessary functionality to client sites.

The source code of the test client on GitHub (Perl)