Security risks of electronic voting systems

This page tries to list all my notes about possible security problems of electronic/online voting, and list possible mitigation procedures.

These are NOT all implemented in PyVotons in its current alpha state !

Requirements

One voter can vote once only

Only the voter can cast a vote in his/her name

The content of the vote is secret to all third parties (no one can check who you voted for)

You can check that your vote was counted (vote register)

Social aspects

– someone else uses your identity (for example inside a family)
– stolen or lost identifiers
– someone looks over your shoulder to check the vote (pressure to vote one way or the other, corruption…)
– server admin : what code is running, how truthful are the results… Multiple people should be able to check (ideally anyone should have read access to the server (except ID and votes until the end of the vote)
– Humans should deal with problems signalled by users (fast detection of problems, good opportunities to correct problems).

Technical aspects

– Encrypt client-server communication over the internet : https keys management and signing. OpenSSL library used by the Python server is NOT perfectly secure, as the recent Heartbleed bug has shown…
– storing passwords (hash, salt, pepper, bcrypt or PBKDF2), nice explanation, 3rd authentication (SMS code?)
– timing attacks (success or fail for username and password should take the same time, whether authentication fails or succeds)
– signing votes ? GnuPG
– sanitize client-received data and treat all input data as potentially malicious.
– SQL : prepare all statements
– memory exploits : use a managed language (Python), or use smart pointers/secure mallocs/valgrind…
– DDOS (IP filtering ? Flood detection on the system ?)
– Have one vote and only one per user
– should not be able to link user and vote content
– timing analysis should not allow vote content retrieval (no realtime results, or if you know when X voted, you can know what X voted)
– validating client-side data on the server
– keeping the servers updated
– minimize surface exposed to the outside (firewalling, user rights of webserver and DB as weak as possible)… Break up the server side in multiple processes (one for authentication, one webserver : compromising one should not compromise everything.
– write tests to check reactions to client-supplied malicious data
– no data leaks between logged in users : one processper logged in user ?
– what is logged by the server ? What is necessary to detect attacks/malfunctions vs user privacy ?