Data Integrity Certification Service

There has been a big hullabaloo around EVMs and electronic voting. And one of the main requirements that has been consistently missing is what is called a "paper-trail".

Many detractors of electronic voting have cited lack of a paper trail is the main reason why electronic voting is being called unreliable. What is it about paper that makes a paper-trail that is more dependable than an electronic trail.

One of the main reasons is that a paper-trail is physical meaning that it is constrained in space and time. And therefore security authentication and authorization mechanisms have been built taking this constraint into account.

What if data were to be provided this type of constraint. If there was a means of constraining data in space in time - prevent duplication and correctly identify the time of entry for a data item, it might be possible to identify the integrity of any given data point.

Consider a mechanism, called the DICS mechanism. This is an based around an online trust that provides time-based data integrity mechanism. Each client of the mechanism has a two-way relationship with the trust. The client asks for and has a tie-up with the service provider.

Lets assume that the client stores data in a relational database. Lets also assume that there is a row of data to be filled in at any time. In order to do this there needs to be another column in the table that stores a data element that is a sum total of all the information stored in the row and is encrypted in a way to prevent its tampering.

The simplest way of doing this would be to concat the data in the row and use a publc key to encrypt the data and store it in the column. The problem with this approach is two-fold. First, there is no time-information, and secondly it is possible for the single entity having access to the system to also have access to the private key, rendering the entire process unviable.

To overcome this, we introduce the entity called the DICS.



DICS <-----------------------------> Client



Assume that there is a row of data that needs to be protected. Call this data as the variable x. (assume that the data in the row is either concatenated or otherwise combined to get this single entity)

Other data variables used are

d and d' which are the private and public keys of the DICS trust while

c and c' are the private and public keys of the Client

f() and f'() are the encrypt and decrypt functions used in the two key algorithm. (data = f'(f(data,c), c') )

The process starts with the client that starts and calculates the values of 'a' given by var_a = f(x, c'). This data is sent across the the DICS server.
The DICS service calculates var_b = var_a + t, where t is the time-stamp. The '+' is a defined combination functions with a simple inverse defined.

The service then returns var_c = f(var_b, d') to the client, while storing var_c and t with itself. The service does not return 't', though as you will see, that is not an issue.

The client stores var_c in the column of his database.

The service opens a simple functions to the client checkData().

Now checkData() sends across the value x recalculated using the same concatenation function and data from the client database along with the var_c stored. The service can then recalculate the value of the var_c from the given x and the time_stamp stored to verify the authenticity of the data.

Now time value is stored with the data, and hence in case of errors with data authenticity, further tests can be performed. Also time-reports can be taken for various requests to detect if there has been any descrepancy in the usage reported by the DICS service and actual usage done by the client.

Secondly any person changing the data needs to get the data re-authenticated by the DICS server showing up as discrepancies between the number of data entries and the number of data authentications. Also if there has been no access to the DICS service during the update/change then the data is directly found to be wrong.

sounds good?

- ravi