2

Let's say I created a voting system where each voter would use an app and vote on a candidate. The app would send the vote to a server. The server would store the vote on a DB with the request IP.

Is it possible to implement something to guarantee in a future audit/forensic work, my DB represents real requests and not something was forged?

My idea is that my DB should be a proof that I had n votes and they are real votes, not something I created myself.

  • Each IP would allow a single vote
  • I won't store personal information on DB, the IP address and related data would be the only thing to store
Danilo Gomes
  • 121
  • 1
  • 1
    You should allow only signed-in users to vote and store a flag in the database. Also, you'll have to ensure that users cannot easily create multiple accounts. – user3382203 Oct 12 '18 at 03:04
  • *" ... my DB represents real requests and not something was forged?"* - what exactly is the difference? If you can clearly define how the receiver of a request could distinguish a forget request from a real one for sure even before it gets put into the database then you might also store this kind of prove in a database too. One might start with some kind of authentication or voter registrations but who controls all these but you? If you want some third party to trust the process the third party need to be probably involved from start, i.e. in the process of voter registration. – Steffen Ullrich Oct 12 '18 at 05:16
  • Let me give an example. This system could be used as a voting system for an election of a mayor. Then each citizen would vote from an app then the IP of the app would get registered in the database together with the vote. Later on, somebody from a city council would execute an audit in my system. They will inspect every row on the DB. And they might say: "I think you created yourself a couple of rows here to elect your favorite mayor". – Danilo Gomes Oct 12 '18 at 07:52
  • I'm not sure if it's possible. Is there anything in a HTTP request that I can use and in the future use to prove it was a real request and not something never existed?. In other words, is it possible to capture some "fingerprint/dna" of the request? – Danilo Gomes Oct 12 '18 at 07:53
  • Maybe the service/hosting providers could have a log history of all requests executed, I don't know. Anyway, this is more an idea than an actual real project. It's something I was wondering to use as a possible voting system in the future. – Danilo Gomes Oct 12 '18 at 07:55
  • The idea here is to somehow prove to a 3rd party my data is real and not something I created myself. – Danilo Gomes Oct 12 '18 at 07:57
  • Some analogy: let's say while an user is voting we have somebody recording with a camera the user holding the phone and voting, including the option the user voted. then this video is stored together with the vote on the db. then during the audit of the system, the audit team would compare the vote of the row with the video, check if the video is real and it's a person in there, and compare the votes. That's just an analogy/idea to explain what I'm trying to do. – Danilo Gomes Oct 12 '18 at 08:05
  • @DaniloGomes: please don't write all the details in the comments but update the questions accordingly. And no, a request has not some magic in it where you can decide if it is faked or not. It is just data. It has no soul. – Steffen Ullrich Oct 12 '18 at 08:27

4 Answers4

2

Your specs begin with:

Each IP would allow a single vote

Do not go further. If you can control a router for example in a corporate environment, you can:

  • either make all internal machines present externally the same address (and only one user in the organization could submit a valid vote)
  • either allow the router admin to submit a valid vote by faking any of the addresses of their organization

And as a single person, I currently use:

  • a private computer
  • a corporate computer (only presents the IP address of the corporate firewall)
  • a private smartphone
  • a corporate smartphone

Does it mean that I can submit 3 different votes or 4 in nobody in my organization has already submitted one from its corporate computer?

Above was about why I think that your idea is wrong. Following part in my opinion of how to build a voting system.

I just think that I am not clever enough to invent from scratch what others have built upon centuries, so I will just try to translate in IT world how an ordinary election work.

  • Rule 1: all voters are registered, and their identity must be controlled before a vote is accepted as valid - stop imagining anonymous votes for a serious election.
  • Rule 2: the content of the vote must be kept secret - nobody except the voter himself should be able to know what the vote contained
  • Rule 3: it is possible to know who participated to a vote - at least to control that dead people did not vote (it used to be common in some places)
  • Rule 4: the observance of the previous rules can be controlled by people representing the various candidates (a candidate can be here a human being, a full staff, or a simple proposal)

Those 4 rules are observed for physical voting, as well as post voting. For the latter, an inner enveloppe (no possible identification of it) contains the vote, and an outer one carries the name and manual sign of the voter. The outer enveloppes are opened only by the people in charge of controlling the validity of the vote.

In IT world it would give:

  • each voter should be informed of the how to vote
  • the system should be able to identify each voter. The up to date way would be a certificate on a smartcard, but depending on the importance/cost ratio a username+password could be considered
  • the voting system should keep a track of which user voted and when - this is the voting register
  • the voting system should increment counters and not store any individual votes
  • it must not be possible to know at what time the counter changed value to prevent correlation with the time at which someone voted (may impact the underlying counter store). Only the final value must be kept.
  • the counters should not be accessible to anybody before the end of the election, unless it can be proved that it does not allow to know the recent votes by polling the counters on short intervals
  • the system should be audited before and after the vote by the candidates or people representing them
Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
  • I'd like to add to "the voting system should increment counters and not store any individual votes" -> It is important to add a random delay between user lookup and identification and counter++ in order to nullify the possible correlation attack to find out who voted for what. (Through DB logs for exemples) – Guillaume Beauvois Oct 12 '18 at 13:17
  • 1
    @GuillaumeBeauvois: More exactly it must not be possible to know at what time a counter was incremented: only the final value shall be readable. Post edited with that. – Serge Ballesta Oct 12 '18 at 14:46
1

Short answer to your question, as it currently stands: No.

The reason:

Each IP would allow a single vote

Due to NAT-translation, a single IP address may represent a lot more than a single user (a public IP might point to an entire corporate network, for instance). Furthermore, using an IP address to identify someone is nowhere near feasible anyway; it can easily be changed, spoofed, etc., not to mention the obvious fact that several people living at the same address and possibly even sharing the same computer would obviously also have the same IP address.

I really can't see how you could achieve anything like this without including some form of user / voter registration, and the problem with that is obviously anonymity: How can you guarantee that a person only votes once, without storing at least some minimal amount of personal information?

At best, I can envision some kind of split system solution, where a vote is anonymous, but where it is backed up by some other service which can guarantee the uniqueness of each voter (at least to a certain degree of confidence).

As a basic idea, consider the following:

Create a voting system where anonymous users can log in using an access token, and register a vote which was digitally signed using asymmetric cryptography. That digital signature would be performed using a private key which would have a corresponding public key which was explicitly linked to the users access token. The token itself would be provided by a distinct service, so that the voting system itself would be cleanly separated from anything containing personal data about the voters.

From this, an auditor would be able to check the following for each vote simply by looking at the votes and the tokens:

  • The vote was cast by a user carrying the access token X.
  • No other votes have been cast by a user carrying that specific token.

Now you'll need to back this up with a token-provider service which can guarantee that each token has been granted only to a single individual (who is eligible to vote), and that no individual has been granted more than a single token (An auditor would probably want to evaluate this part of the solution too, but might be able to do so while still limiting access to personal information about the voters).

So how could you do this while keeping the amount of personal data at a minimum? The best option I can think of would be a system that stores a hash (an irreversible cryptographic "fingerprint") of some personal identifier, such as a social security number. That could be used to verify that no single identifier is ever used more than once, and yet prevent someone with access to the database from producing a full list of all those who have voted (since the list would only contain hashed values, which are by nature irreversible).

What this would not prevent though, is account enumeration; checking whether specific individuals are registered, provided you already have their identifier (if they were registered, then attempting to register again with their credentials should cause an error or warning, which would confirm that their account existed).

One possible workaround for this might be to simply register all potential voters from the start. That way, looking for an account belonging to someone who has voted would return the same type of result as looking for someone who had not, and the token based logic should still work. The main point is to split the identification and the actual voting into two separate parts, and use cryptography to secure the vote, while keeping the personal info out of it as much as possible.

This is pretty conceptual, and there is obviously a lot more to consider, but I hope it gives you a few ideas to think about in the context of your question.

Kjartan
  • 999
  • 11
  • 17
  • I just want to add that Social Security Number is not a good solution everywhere. In France, SSN are predictible because it's construction is codified. Therefore someone could easily iterate through all possible SSN and owned all possible accounts. – Guillaume Beauvois Oct 12 '18 at 10:29
  • 1
    Good point. The same applies to Norwegian SSN's by the wa; in fact, due to the way they are created, if you know the gender and birth date of a person in Norway, you can generally reduce the possible number of SSN's to around 250 or less. That does not mean it's useless as an ID number, it just means you have to keep in mind that is should be treated as public information, and that that has certain implications. – Kjartan Oct 12 '18 at 11:02
1

TL;DR : The secret is not "Who" but "What".

I think you are taking the wrong path. What you wan't to achive is :

Votes are made by real people.

I don't see why you shouldn't store personnal data if that can make you achive this goal. There is no problem of having personnal data on a voting system, when I go to vote, I have to sign a register so they know I did vote, and the gouvernment knows a lot on me.

What has to be secret is the vote.

So as far as the vote is being keept secret, you can store any personnal informations about the voter you want (and they agreed with).

Guillaume Beauvois
  • 411
  • 4
  • 11
0

No. You can't be sure the users voted the way they did, because of the possibility of malware on each user's device. It could lie about who you voted for, and vote for someone else. Heck, they might not even be using a real browser, and there's no way to verify that from the server.

In short, you can count incoming votes securely, no problem, but you can't control the validity of the input, casting doubt on the results.

dandavis
  • 2,658
  • 10
  • 16