This area is for everyone who uses (or wants to use) GNU.FREE but isn’t really interested in adding to it or altering it.
There is full documentation available here which always supersedes the version included with the downloads if there are any differences.
What does GNU.FREE stand for?
GNU indicates that we are an official package of the Free Software Foundation’s GNU project. GNU stands for GNU’s not UNIX! It’s a recursive name – a programmer’s joke.
FREE stands for Free Referenda and Elections Electronically, and also represents the Freedom that the General Public License, Democracy and the Internet are all about.
Why use GNU.FREE? Why not use it?
GNU.FREE, at the time of writing this FAQ, is the only fully working Internet voting software available under the GPL. It is totally cross-platform having been written in Java. It is also extremely scalable having been designed with a distributed architecture.
So why not use it? GNU.FREE is not a polling program and thus isn’t for small web-page based polls, it’s an Internet Voting program. It provides heavy-duty Internet voting and requires a bunch of computers and some technical skill. Also the General Public License means that any changes you make must be made available to others, so if you can’t live with such terms – go somewhere else!
Why doesn’t x/y/z work? What does this error message mean?
I don’t know! We are always happy to help but before you ask please check the documentation on this site. That includes the JavaDoc documentation, the areas on SourceForge.
When you email someone it for help please include at least: GNU.FREE version number, Platform you are running, Version of Java Virtual Machine, relevant log files. If you have modified code or the problem is hard to explain consider including relevant code and screenshots.
So where does GNU.FREE come from? What’s the history?
GNU.FREE was developed as part of a joint project at the University of Warwick Department of Computer Science and the Warwick Business School. The project was examining the impact of the Information Revolution on activism and the political process.
One major impact that people have been predicting for years is electronic voting, but during Jason’s research it became apparent that all the current implementations were pretty flakey and also commercial. Jason felt this was an unacceptable state of affairs so he set about making a system that would be useful with today’s technology and could be released under the General Public License. GNU.FREE is the result.
More details on his research and also copies of the papers produced as a result of the research are available in the writings section. These papers include the detailed original technical design with UML diagrams.
Why isn’t there a real-time indication of how each party/candidate is doing?
This feature isn’t included because it could influence the outcome of any ballot. In fact in some countries polling data and results are banned for the whole period that people can vote to help prevent a feedback loop.
If this was allowed people might see who appeared to be winning and feel that it was pointless voting for the opposition and then create a self-fulfilling prophecy. Alternatively you might like to vote for the underdog and change your vote on seeing one party apparently gaining a lead. Be it positive or negative feedback, we need to avoid this situation.
How does GNU.FREE’s version numbering work?
The GNU.FREE project uses a three-tiered version numbering system which may confuse some. Here’s what we track…
Distribution Version – This is the number you see in the logo at the top of this page. It counts the progression of complete releases to the public. Note that we started at v1.0 because GNU.FREE v0.x was initially developed internally at the University of Warwick for seven months before being made available under the GPL.
Program Version – GNU.FREE consists of several programs including FreeClient, RTServer, ERServer and FreeTest. Each of these change at a different rate and so they are assigned different version numbers to show this.
Class Version – Some classes go through a lot more change than others. To keep track of all the changes every individual class also has its own version number.
Despite the several tiers most people need only concern themselves with the distribution version which is the most important one for non-developers.
So what happens when a voter uses GNU.FREE?
Here’s the process as it is in GNU.FREE version 1.5, some detail has been removed to make the diagram clearer. ====> or <==== indicate packets being sent, time progresses as we move down the page: FreeClient ERServer RTServer (regional mode) User enters login info & clicks ok. ====> Check login info against database.
Store AuthKey and show user next screen. <==== OK! Send authorisation key and mark db entry.
Close connection. <====> Close connection.
User confirms vote choice and packet is made.
Vote, AuthKey and a time stamp are sent to RTServer. ====> ====> ====> Vote checked for validity.
Copy of time stamp retrieved and deleted from memory. <==== <==== <==== OK! Details stored and time stamp asked for again. Time stamp alone is sent. ====> ====> ====> If time stamp matches with previously sent then continue.
Decrypt AuthKey and check it is valid. OK!
AuthKey received, voter cannot login again. <==== Send AuthKey to ERServer. OK! ====> If so store vote and delete AuthKey & time stamp.
Tell user. End. <==== <==== <==== Confirm to FreeClient.
Close connection. <====> <====> <====> Close connection.
So what happens when a voter uses GNU.FREE? [The really detailed answer]
(This is from an email conversation with email@example.com, this was written by Jason Kitcat)
All communications are encrypted in the following way:
1. The client always sends the first packet which contains a session key (created using a SecureRandom) which is encrypted using RSA and the server’s public key. The message body is encrypted using BlowFish and the session key.
2. The server can decrypt the session key with its private key and then decrypt the message body.
3. When the server replies (the client always sends the last message) it doesn’t send the session key (the client knows it already) and just BlowFish encrypts the message with the session key.
(note that every HMAC uses a sequence number in its creation ensuring that every single one is unique)
Encryption is ommitted from this sequence….
1. A client sends an HMAC initialisation message consisting of a client seed to the Electoral Roll Server protected with a simple SHA-1 message digest. It also creates a client key from this seed.
2. The Electoral Roll Server uses the seed to create its copy of the client key. The server has created its own seed (and thus key). It sends the client the server seed and an HMAC (using the client key) of the key sent by the client protected using an HMAC with the server key.
3. The client checks the HMAC of the whole message and also the the HMAC of its first message to ensure that the server’s seed is authentic. It then creates a server key. The client sends authentication information protected by HMAC (from now on made with the client key). The PIN code and password are message digested as well (no plain text sent).
4. The ERServer checks the data and if ok replies with a one-time Authorisation Key protected by HMAC (from now on made with the server key).
5. A client sends an HMAC initialisation message consisting of a client seed to the Regional Server protected with a simple SHA-1 message digest. It also creates a client key from this seed.
6. The Regional Server uses the seed to create its copy of the client key. The server has created its own seed (and thus key). It sends the client the server seed and an HMAC (using the client key) of the client’s message payload protected using an HMAC with the server key.
7. The client sends the vote, the authorisation key and a checkdate protected with HMAC.
8. The server holds this temporarily and asks for the checkdate again, protected with HMAC.
9. The client replies with the checkdate and the AuthKey again protected with HMAC.
10. The server checks the AuthKey is in its list of valid keys.
a. The RTServer sends an HMAC initialisation message consisting of a client seed to the Electoral Roll Server protected with a simple SHA-1 message digest. It also creates a client key from this seed.
b. The Electoral Roll Server uses the seed to create its copy of the client key. The server has created its own seed (and thus key). It sends the RTServer the server seed and an HMAC (using the client key) of the RTServer’s message payload protected using an HMAC with the server key.
c. The RTServer checks the HMAC of the whole message and also the the HMAC of its first message to ensure that the server’s seed is authentic. It then creates a server key. It sends the key to the ERServer protected with an HMAC – the ERServer can use the AuthKey to figure out who has voted in a one-way manner.
d. The ERServer checks the database for a matching key (in fact it generates keys for each record until one matches, it’s one way so this is the only way it can be done). If a match is found the ERServer replies with the AuthKey and confirmation protected by an HMAC. If no match is found the reply still contains the key but a ‘false’ value protected by an HMAC.
e. If the ERServer returned ok then the RTServer stores the vote. Note that the vote alone is stored in the database and the AuthKey is removed from the server’s list of valid keys. If ERServer returns false then the vote has still been stored but the AuthKey isn’t deleted. There is a reason for this and it is to do with voter rights over system rules… big debate and I may change it.
11. The server confirms the vote has been stored to the client with HMAC protection.
So what happens when a voter uses GNU.FREE? [The really really detailed answer]
(This resulted from an email conversation with firstname.lastname@example.org and was created by Olivier Paul)
Ese(Epe(x)) is the decryption with private key se of the message x encrypted with public key pe.
Ds1(Es1(d)) is the decryption with secret key s1 of the message d encrypted with secret key s1.
The client is in black, ERS (ERServer) in red and RTS (RTServer) in blue.
kce = random()
Sa = Digest(kce, nce)
s1 = random()
u = username
m1 = Es1(kce, Sa), Epe(s1), u
s1 = Ese(Epe(s1))
Check Digest(kce, nce[u]) = Sa
kec = random()
Sj = Digest(kec, Sa, nec[u])
m2 = Es1(kec, Sa, Sj))
Check Digest(kec, Sa, nec) = Sj
Sb = Digest(pin, pwd, kce, nce)
m3 = E s1(Sb), u
Check Digest(u, pin[u], pwd[u], kce, nce[u])=Sb
Tc = Authorisation-key;
Sc = Digest(kec, Tc, nec[u])
m4 = E s1(Tc, Sc)
D s1(E s1(m4))
Check Digest(kec, Tc, nec) = Sc
kcr = random()
Sd = Digest(kcr, ncr)
s2 = random()
m5 = Es2(kcr, Sd), Epr(s2), C
s2 = Esr(Epr(s2))
Check Digest(kcr, ncr[C]) = Sd
krc = random()
Sk = Digest(krc, Sd, nrc[C])
m6 = Es1(krc, Sd, Sk)
Check Digest(krc, Sd, nrc) = Sk
Se = Digest(Tc, V, cd, kcr, ncr)
m7 = Es2(Tc, V, cd, Se), C
Ds2(Es2(Tc, V, cd, Se)
Check Digest(Tc, V, cd, kcr, ncr[C]) = Se
m8 = ok
Sf = Digest(Tc, V, cd, kcr, ncr)
m9 = Es2(Tc, V, cd, Sf), C
Ds2(Es2(Tc, V, cd, Sf))
Check Digest(Tc, V, cd, kcr, ncr[C]) = Sf
kre = random()
Sg = Digest(kre, nre)
s3 = random()
m10 = Es3(kre, Sg), Epe(s3), RTS
s3 = Ese(Epe(s3))
Check Digest(kre, nre[RTS]) = Sg
ker = random()
Sl = Digest(kre, Sg, ner[RTS])
m11 = Es3(ker, Sg, Sl))
Check Digest(kre, Sg, ner) = Sl
Sh = Digest(Tc, kre, nre)
m12 = Es3(Tc, Sh)
Check Digest(Tc, kre, nre[RTS]) = Sh
V[Tc] = True
Si = Digest(Tc, ker, ner[RTS])
m13 = Es3(Tc, Si)
Check Digest(Tc, ker, ner) = Si
V[Tc] = V
m14 = Es2(V, Se)
Check Digest(Tc, V, cd, kcr, ncr) = Se
Why are communications over the Internet secure with GNU.FREE?
There are many aspects to the GNU.FREE security design but the main approach to securing Internet communications in GNU.FREE is twofold.
First we try ensure that nobody can understand what is being sent between different programs. We do do this by using the proven Blowfish encryption system with session keys shared using a RSA public key system.
Secondly we work to prevent what is being sent from being tampered. Thus even if a malicious person cracks the encryption it would be highly improbable for them to also be able to tamper the message. We use the RFC-compliant HMAC system which includes a client-server key initialisation process and uses sequence numbers to protect against reply attacks.
Further layers of independent protection are used on the actual message that sends a vote and the design of the whole system means that even if all of these were cracked someone still wouldn’t be able to find out who voted for who.