A simple solution for using EDS

    imageA few years ago, we launched the Open Voting project, which aims to create a system for conveniently conducting reliable and verifiable votes. Unfortunately, the matter was limited only to theoretical developments, and in terms of specific implementations, we have not moved forward. Not so long ago, I began to ponder - why so? I am a developer myself. The team also has several developers. So what bothers us? And he came to the conclusion that the main obstacle was too big initial plans. So I decided to start small - with a tool for simple use of electronic signatures by ordinary people. Moreover, not only for our project, but for any site that considers it necessary.

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

    So, what am I suggesting ... A

    mobile application located on the user's smartphone provides all the basic cryptography - creating keys, storing them and signing 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 the hash of their public key. Sites requesting the signing of any documents (hereinafter referred to as “customers”) are identified by their symbolic identifier (in general, by the site’s domain). The system also has an intermediate element, which ensures the transmission of packets between the user and clients - a proxy server. I want to note right away that information about signed documents is not available on proxy servers, as it is encrypted with the user's public key.

    Operating procedure

    Naturally, in order for the client’s site to be able to send a document for signing to a specific user, he first needs to somehow get 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: its identifier (usually a domain) and a one-time code;
    - the user enters this data into a mobile application that generates a package with the following data: his public key and a one-time code that he signed. And sends this packet to the proxy server;
    - the client’s site receives this package from the proxy server and binds the public key to its logic.

    After that, if it is necessary to sign the document on the site:

    - the client generates a document for signing (including the internal identifier of the document), encrypts the document data with the user's public key, sets the user ID for it by its public key and sends it to the proxy;
    - the user, at his convenience, checks for new documents for signature;
    - upon receipt of such a document, the user decrypts his data and forms his signature from them, 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 number of the document. The document data itself is not sent (it is stored at the client);
    - the client receives the signature, extracts the original data of the document using the internal identifier, verifies the signature and, if it is correct, saves it for further actions.

    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 related to the implementation of the voting. It can be used, for example, to provide two-factor authorization. Or to protect critical user actions such as changing a password or email associated with a login (such an optional functionality is already being implemented on one of the popular sites). This is a basic tool and on its basis you can build anything - the matter is limited only by our imagination. :)

    The plans are 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, realizing the possibility of communicating directly with client sites (without using proxy servers), if they support this feature, and also creating a version for iOS (a mobile application version is now 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, help in porting the application to iOS would not hurt us). :)

    Well, and links:

    Mobile application in the Google Play Market: GPLVote Sign Doc
    The source code of the mobile application on GitHub
    Test client site for testing the
    Perl mobile application GPLVote :: SignDoc :: Client module, which facilitates the fastening of the necessary functionality to client sites
    Source code of the test client on GitHub (Perl)

    Also popular now: