GNU project  -  FREE project  -  Savannah @ GNU Free Software Foundation
The FREE project
home | users | developers | writings | download | connections


On this page

Introduction
Physical Security
Logical Security
Performance
Distribution
Audit
Authentication
Audit Trails & Privacy
The Results
Comments & Ideas


In this section

Section Index
Getting Started
Running Elections
Screen Shots




developers supported by:
Swing Digital


systems:


donate to the project:
 
Running Elections - Intro

RUNNING ELECTIONS - A GUIDE

Running an election or referendum is an important job. GNU.FREE is designed to make it easy and secure, if you set GNU.FREE up according to our guide then the software should run smoothly. But there are more issues than merely software configuration to address, this guide gives you our recommendations for securing your electronic election as a whole.

Remember, it only takes one slip-up for public confidence to be undermined for a VERY long time - so please take the time to read this and be thorough! Thank you.

Physical Security

It may sound obvious, but we just want to remind you that having 'unhackable' servers is useless if someone can break in and physically steal/access/vandalise the hardware. So lock it up and restrict access.

Additionally be careful about who knows where the servers are and how they are connected to the power & Internet. Social engineering is a very powerful tool in the cracker's armoury - make sure that information is made available on a 'need to know' basis only. Furthermore it is essential that people follow procedures and practices and that they never make exceptions - even if it appears to be the boss.

Logical Security

Keep those servers secure! We can't offer any specifics because you could be running GNU.FREE on any system but general hints include:
  • Turn off all uneccessary services such as FTP, file + print sharing etc. ;
  • Make sure only authorised users have access to the area where GNU.FREE is stored;
  • Keep tabs on the latest patches, make sure that they are installed;
  • If you don't know how to configue the operating system, firewall, whatever then get a pro to do it - misconfiguration is a huge problem that won't go away if you pretend it isn't there!
Also keep close tabs on the text files GNU.FREE uses. ERServer.users, the file used for importing user data, could be a massive security risk. So make sure you know where every copy is and we would recommend securely deleting it from Internet connected computers once the data has been imported into the ERServer. rtserver.keys and rtserver.test.keys are less of a potential security risk as they are encrypted but still remember to keep tabs of all copies and we would also recommend deleting them from Internet connected computers after they have been imported into RTServer (remember that if you need them again they can always be re-generated by ERServer).

Performance

Hypersonic SQL (HSQL) the database system included with GNU.FREE was chosen because it is released under the General Public License and also because, like GNU.FREE, it is 100% Java.

HSQL is small and extremely fast but it does have one limitation in that it doesn't support concurrent users (though it is thread safe). This impacts GNU.FREE's performance when a large number of simultaneous voters are being served.

There are two solutions to this if you are expecting over approx. 100 voters concurrently per second: The easier option is to increase the number of Regional servers and thus spread the load but this does increase the difficulty in managing the GNU.FREE clients.

The alternative is to connect GNU.FREE to a more advanced database. This is a relatively trivial piece of programming as long as the database software supports JDBC. Take a look in DBase.java in the Free and ERServer packages to find the JDBC code.

Distribution

To create the secure system that strictly enforces privacy and security the GNU.FREE client software couldn't be a Java applet. Unfortunately this makes distributing the client software a bit more trouble. We are working on improving this through the use of JNLP, which is supported from GNU.FREE version 1.3 and up.

In the mean time we recommend that the client is distributed from multiple secure servers running SSL. Each server should offer the client specific to a certain regional server. You might also want to take advantage of Java's class signing capabilities, though this does requires certificates which are costly. For this reason we chose not to require the use of certificates.

One final thought is that GNU.FREE requires Java 1.1.8... you may need to check if your prospective users support this - but we have aimed GNU.FREE at the lowest possible version of Java to ensure wide spread support.

Audit

Because GNU.FREE is an Free Software project, it is possible that some distributions may have malicious code and/or intential security holes inserted. We strongly recommend that the source code is audited by independent professionals before use in an election/referendum to prevent such code creeping in.

This is an added expense, but any major vote should take this precaution. The release from this site will always have all code checked, but we make no warranty or guarantees of any kind.

Authentication

The current system in GNU.FREE v1.x for authenticating voters, while workable, is not ideal. We will providing more secure and flexible options in the future. In the mean time you will need to populate the Electoral Roll database with the relevant data, this may involve sending some information to voters so that they can login.

We also recommend that each region have it's own independently run ERServer to match each RTServer, thus improving survivability and performance. Additionally this compartmentalisation reduces the impact of any security breaches.

Audit Trails & Privacy

When creating secure systems one aims to prevent people gaining access, but if they do you want to make their actions traceable with an adequate audit/logging trail. This helps catch the perpetrators and also right any wrongs they might have done.

Since GNU.FREE 1.1 a logging system has been implemented for ERServer and RTServer. You can adjust how much detail is written to the log files to address privacy concerns. However even a small amount of the time-stamped information in the logs could be a privacy threat if the logs from ERServer and RTServer can be brought together for analysis.

As with most things in GNU.FREE it comes down to pragmatic compromise. The user may choose to disable logging to preserve 101% privacy but risk being caught unawares by hackers. Alternatively logging may be enabled but the user must be vigilant to prevent misuse of this data.

One other consideration is that any form of logging will result in very slightly reduced performance.

The FREE e-democracy project suggests a compromise could be to enable logging at the NORM setting, disabling DEV level logging. This could be done by DEV.removeAllAppenders() in the relevant start-up section.

Logs are just plain-text files and as such aren't protected in any way by GNU.FREE. However since GNU.FREE 1.6 there has been a tamper resistance system. In rtserver.sec.log and erserver.sec.log there are digests of the logs in a chain fashion - this means that every digest is related to each one so a malicious cracker couldn't just delete lines or edit lines in either file and get away undetected.

To validate that a log hasn't been tampered use the GNU.FREE Testing Suite (FreeTest) - if tampering is found the line at which it beings will be reported (with the first line of a file being 0).

Note that this feature does impact performance due to the extra file-writes and additional process work in the digest creation. If performance is absolutely essential this feature can be disabled by just commenting out the code that loads the SecureAppender category in the logging initialisation.

Your database system may also have an audit trail and/or log when a record was last modified. We would advise disabling such features as they may enable analysis to infer who voted what.
The Results

Before the ballot starts we suggest doing a SELECT * FROM Votes; on each regional server and SELECT * FROM Totals on the Totaller server. This will ascertain that the database is empty and thus that the count started at zero furthermore this query (and its result) will be recorded in the logs.

Don't forget you can get sub-totals by choosing "Local Results" from the "Actions" menu. Note that like choosing "End Vote" this stops the TCPServer to prevent votes arriving during the count.

The Totaller server will provide final results, including turnout, automatically once it has received sub-totals from ALL the regional servers.

Note also that since v1.4 when a Regional server is made to close the ballot and send its sub-totals a verification check is performed. The number of voters registered as having voted against the number of votes registered will be displayed - this is a useful guide to the validity and possible level of error in the results.

Comments & Ideas

We are always working to improve and update this guide. Please submit your ideas, comments etc.


- User Home -

Contact - by Jason Kitcat - j-dom portal

© 2000 - 2003 FREE e-democracy project

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.