SecureAppender - confirmation from TDWTF

ammoQ has kindly confirmed by suspicions over at the The Daily WTF. Good to see it's visible to others.

Return to the Wired article

One specific thing from that Wired article I commented on the other day:

"There's really no way to secure the transmission of votes over the internet," Jefferson said, pointing out that home PCs' vulnerability to viruses and other malicious code makes it impossible to assure that a vote is cast and counted the way it was intended.

Yes there is. As was stated in my comments... pre-encrypted ballots ensure that:

1. The vote is unalterable without being unintelligable to the voting system (assuming a 10 horse race, with a 4 digit PCIN we get a 1 in 1,000 chance of altering the entered value to another correct value... not that you know who the new value is for)
2. No one in the middle can tell how you voted without your original candidate sheet!

I'm surprised that the assertion from Jefferson hasn't been challenged before.

Greatest threat to democracy now available online!

Mother of all that's Holy! The Germans are manufacturing a device that could bring down the entire basis of our democracy overnight. The devils are producing "erasers" that can be used to alter the marks on paper ballots made using pencils. My colleague Neil has helpfully provided us all with an image of these infernal devices!

Warning: The above is a joke - if you take it seriously then well... *sigh*

www.electronic-vote.org

Just happened up this site (linky) that makes some arguments against the use of electronic voting, and how it threatens the fundamental nature of democracy (insert special FX noises).

The argument is made that a completely anonymous election can only be assumed to be correct if the electoral processes are open to verifiability by the electorate. Whilst the generalised process may be open to verification by everyone, it is not practical for every stage of the process to be witnessed by everyone (which is what is required for everyone to have confidence in the correctness of the vote). This then assumes that the majority of the people place trust in those who are witnessing every stage of the election. It also assumes that there is a witness present at all times, at all points in the election. This quite simply is not the case. In the UK there are not individuals present at every stage in the electoral process, do people accompany the election workers picking up the ballot boxes from the distribution centers, staying at the polling station for the whole time the polls are open? Accompanying them back to the counting station with the ballot box? No, they're not. So there are plenty of points at which electoral fraud can be committed that won't be witnessed, all the transperancy in the world does you no good if no-one is there to witness it!

Specific counterpoints:

"because computer procedures are not verifiable by humans as we are not equipped for verifying operations occurring within an electronic machine" - the writer of this may not be able to verify the operation of compuer procedures but I'm surrounded by 30 odd people that CAN. To be honest this claim is like saying : "Computers, if it's too hard, I can't understand it!". Sure not everyone can, but enough can. Probably more people than bother to witness a paper ballot anyway.

"Thus, for people who did not program them, computers act just like black boxes and their operations can truly be verified only by knowing the input and comparing the expected output with the actual output (see Reflections on Trusting Trust, by Ken Thompson).
Unfortunately, due to the secrecy of vote, elections have no known input nor any expected output with which to compare electoral results, thus electronic electoral procedures cannot be verified by humans! This applies to electronic elections independently of any technical solution that could ever be implemented." - I don't know if it's because it's Monday, but I'm having troubling parsing this. Is the writer saying that you can't produce a set of data to plug into a system to check it does what it's supposed to? I hope not, since I can pull a set of test data out of thin air, feed it into a system and verify the results against what I expected. We do it all the time, it's called testing! Or is he saying that since the inputs to an election are not knowable before or after the election (ummmmm, yes they are, we captured the inputs, search for pre-encrypted ballots and you can find out how to capture a voters intention without exposing who they voted for) and therefore you can't create an exact set of test inputs? Bzzzt - can't do that in a real election either (I know the counter will be that you don't need to, since the process is verified, see above). And since we did capture the inputs we can retest the election, in fact any decent election system would involve rerunning the count and comparing results to ensure a correct result (just in case a sun-spot disrupts things). And besides, eVoting systems are not "black boxes" to anyone other than the original programmer, there's this thing called "source-code" that when examined makes the system what we call a "white box". Basically - you can see inside the system and verify it's operation.

"To accept electronic electoral result ordinary people need to have an absolute faith in the accuracy, honesty and security of the whole electoral apparatus (people, software, hardware and networks)." - How, do tell, is this different to having absolute faith in the accuracy, honesty and security of the whole electoral apparatus for a paper ballot? As was mentioned above, if not everyone is present to witness all the stages in the vote, then they must have faith in those that were present to witness the system! And since we've allowed a chain of trust in a paper ballot why can't we allow it in an electionic ballot?

"In fact let's imagine to have a perfect electronic voting system with all the security, auditing, accountability, meaningful public standards and public evaluations we like. Even in such a very optimistic case in the end all the votes would be stored in anonymous records and this unverifiable data, processed by unverifiable electronic procedures, would decide the (unverifiable) winner of the election." - See above please, its not unverifiable.

"Ballot paper elections are very robust and have no single point of failure: there is NOT a single place which abnormal functioning could lead to the impossibility to declare the winner. Paper elections can be held despite of black outs and interruptions of computer networks. Infact paper elections have properly worked also when electricity and computer did not even exist!" - See previous post, no eVoting system would having a single point of failure.

I'm sure there's more but I've not got time for it right now. Breaking down these points seems to break the illogical chain put forward on site, so hopefully this demonstrates just how wrong it is.

Warning - Sunspots may bring down democracy

Quick last post for the night. Check out this great vid of Mr Kitcat, the best bit is at the end :

"Powercuts, sunspots" - Yes because it's beyond the wit of man to provide backup power at a hosting center. Or to provide a DR site that duplicates the systems in use at the main site isn't it? I visited hosting centres over the past couple of weeks that have multiple diesel generators that can power the hosting center for three days with just the fuel onsite. And the centers are a priority for delivery of fuel in the event of a fuel crisis. As to the sunspots bit, I'm not even to going to gratify that with an answer. I mean really, sunspots?

"Open to manipulation by the election officials" - WOW! So a paper ballot isn't? And given what has been said about the technical ability of election officials by the anti-eVote brigade I'd thought they'd be lucky if they could identify a server, let alone find theirs in a SECURE HOSTING FACILITY, then gain privileged access to encrypted databases... yes it's the mild mannered election officials that are the biggest threat to democracy in this country.

"By people that have access to them surreptitiously" - Again, very little chance of this in a SECURE HOSTING FACILITY.

Sorry for the shouting, but I really think Mr Kitcat has no idea how these pilots are run. But that's hardly surprising, the man's never done any serious systems work himself and that seems to be the pattern. These people get the idea into their heads that they are the be all and end all of knowledge in computing and try and dictate to the majority as to how we use technology.

Well good luck Mr Kitcat, because neither the Government, the public nor Local Authorities are listening (and don't think you swung the decision in B&H not to run an eVoting pilot Jason, that was all just politics anyway, the subject for another post).

2007 eVoting Pilots - Funding clarification

Just a quick post to clarify how the May 2007 eVoting pilots are being funding. They are not (as has been noted by a number of talking heads) being funded by the Local Authorities themselves, but rather by funds set aside by the Treasury for the DCA to use for the pilots. So don't worry, your Council Tax isn't being used to fund these wild and fanciful ideas that arrogant technologists such as yours truly think might be a good idea.

Realtime web stats

I've just integrated realtime web stats from these people into the site. Very good for something that's free (up to 9,000 page impressions per day). Extremely detailed analysis of visitor trends and navigation. To be honest I'm amazed they can afford to offer this level of detail in a free product!

Modern twist on an old saying

Rather than :

"Those who can, do. Those who can't, teach."

How about :

"Those who can, do. Those who can't, consult."

Robot abuse

Time for a quick clue stick beating:

Don't list sensitive files / folders in your robots.txt file

More info can be found in The Web Robots FAQ.

Also make sure you've turned directory browsing off and protected anything sensitive with even basic access controls, the Internet's a wild place. Very basic stuff really.

Weird Wired article

On the ongoing "problems" with eVoting (linky), which are basically summed up as:

• General purpose PCs are inherently insecure and vulnerable to viruses and other attacks that could compromise votes without detection.
  
• Denial of service attacks could disenfranchise voters.
  
• Database hacks could change vote tallies.
  
• Putting voting into the home would destroy poll-booth privacy, exposing voters to intimidation and bribery.

Subversion at or near the client

First point concerns keyloggers / trojans et al on the client altering the voters intended selection on a ballot. A simple mechanism to address this is the pre-encrypted ballot (detailed description is here) which basically goes:

1. Voter receives list of candidates and an assigned PCIN (Personal Candidate Indentification Number) and response code pair for each candidate.
2. When voting the voter enters the PCIN for their choice rather than picking from a list
3. The voting system returns the response code for the candidate

This prevents two different attacks at two different locations, the attacks being:

• Exposure of who the voter voted for (the PCIN is a random number on the wire / at the client, it doesn't identify the candidate without the original list).
  
• Alteration of the selection (since an alteration would return the wrong response code, and since the attacker wouldn't know the correct response code couldn't fake it)
  

With the locations being at the client and a Man in the Middle attack (the most common approach to exposure / alteration on the wire when using SSL).

Denial Of Service

Any solution to the eVoting problem worth its' salt will have this solved in the Internet cloud well before packets get close to the actual webservers of the voting system.

Then you've got geocaching of the front end, someone in China or some quasi-fictional terrorist can hammer on the webservers all they like, they'll only be hitting the one that's down the road from them.

Quite frankly the thought of running a general election without active packet filtering in the Internet cloud or geocaching should be an automatic barrier to adoption of the system.

DB Hacks changing ballot tallies

I still don't get this one, I've heard it as an argument many times before. Basically it goes : "The tally is only a number in a database so it can be altered". To which the answer seems to be : "Yes the tally is only a number... the 25 million ballots in the ballot storage, ballot verifier and auditing systems aren't." Who would seriously run an election where the only storage of voters intent was to increment a tally when we receive a ballot? No one that's running my general election that's for damn sure (just think of the locking issues).

I suppose the next argument would be that you only need to alter the stored ballots... and the verifier ballots... and the audit ballots... each stored in separate databases in separate systems (with separate message verification processes and procedures) on a network that will have been audited to national security standards by people that don't officially exist. Yes only change all those ballots, making sure that every ballot is changed the same way in all three systems. And if we add in the pre encrypted ballots where only the PCIN is stored on the ballot until the counting stage you can only invalidate ballots in storage as you won't know who to change the PCIN to.

Voting at home

Voting selling and coercion are very real dangers when you move the polling place into everyones homes. However, we can mitigate this somewhat with the following provisions:

• Voter verification systems that don't explicitly state who was voted for
• Multiple votes per vote, where only the last vote counts (subject to adjudication during the counting process)

To be honest, this is probably the only real problem with the concept of remote eVoting. All the others are implementation details that are solvable by building a well designed, well coded, well tested, well audited, well monitored and well verified eVoting system.

Quote of the Day

From Google:

"How much easier it is to be critical than to be correct."

- Benjamin Disraeli

Government exposing petition creators personal details

Interesting article just popped up on The Register :

http://www.theregister.co.uk/2006/11/17/downing_street_e-petitions/

That links to the new beta Government e-petition site @

http://petitions.pm.gov.uk/

Look at the source of one of the forms (such as http://petitions.pm.gov.uk/Help-Sally-B/) and you can find a Base64 encoded string in one of the hidden form fields (called "ser"). Decode the string using one of the many online tools (such as this one) and you can find out the name, postal address, email address and telephone number of the person who set the petition up!

*sigh*

Update

Just had the following email from mysociety.org:

Thanks very much for bringing this to our attention; I've hopefully now fixed this so the ser field only contains the public parts of the petition.
Thanks again.

Nice to see someones on the ball!

False Sense of Security

OSS can be great... sometimes. Other times it can produce some fairly terrible things, like this (taken from the now defunct GNU.Free project, laughably labeled at a 1.9 release) that only serve to act as security snake-oil:

/**
* Implements the org.apache.log4j.Appender interface to provide a secure
* addition to GNU.FREE logging.

*

* This class creates a chain of Message Digests, so that the every log entry creates a
* digest of itself with the previous entry. Thus altering the log would result in it
* being inconsistent with the digests unless the entire log was edited.
*
* @version 0.1  11 April 2001
* @author Jason Kitcat
* @since 1.6
*/
public class SecureAppender implements Appender {

private String previous_string;
private String name;

public SecureAppender(String previous_val) {

  super();
  previous_string = previous_val; // prime previous_string val

}

public void doAppend(LoggingEvent le) {
  try {
    FileWriter out = new FileWriter("erserver.sec.log", true);

    out.write(AuthSys.makeDigest(le.message + previous_string) + "\r\n");
    out.close();

    previous_string = le.message;
  } catch (Exception e) {
  }
} //EOF doAppend

// other methods removed for clarity
}

Oh dear. Where shall we start? Major points first:

1. The implementation is wrong. You need only alter the digest of the entry you've changed and the subsequent digest. I suspect the doAppend method was meant to look like:

public void doAppend(LoggingEvent le) {
 try {
   FileWriter out = new FileWriter("erserver.sec.log", true);

   string digest = AuthSys.makeDigest(le.message + previous_digest);

   out.write(digest + "\r\n");
   out.close();

   previous_digest = digest;
 } catch (Exception e) {
 }
} //EOF doAppend

2. The clear text log and the digest log are on the same machine, worse still in the same directory. If the clear text and the digests are on the same machine just forget about it. Anything like this is just wasting CPU cycles.

Minor stuff now:

3. Where the heck do the exceptions go when you can't write the event? Nowhere, which is bad practice in my codebook.

Just give it up. This sort of thing isn't simple, there's no hashing Holy Grail to solve these kinds of problems, the real solutions rely on defense in depth which involves separate logs on separate systems behind layers of security that you can't squeeze a gnat through.

Single Transferrable Voting - Pitfalls and Praise

I've recently been working on a test implementation of a ballot counter for Single Transferrable Votes both at work and at home. I've seen various descriptions of STV including this one on Wikipedia (which seems to have too many holes to mention).

By far and away the best description I've been able to get hold of is that put forward by the Electoral Reform Society (linkies - model election - detailed instructions). My only criticism is the lack of an overview of the processes and stages involved. And this is the overall problem with STV : the counting process is too complex.

Voting in an STV election is fairly straightforward and the concept for the voter is simple, namely list your candidates in the order of your preference for them. But try getting an ordinary voter to verify a count! I've not found a resource that attempts to explain in clear language to a voter how their vote was counted, and this lack of transparency from a lay persons perspective is only going to limit adoption of STV. The result might be fairer but until the voter can judge that it is fairer it will only engender suspicion.

Of course politics plays it part in any attempt to adopt STV at a national level in the UK, the only parties calling for it are those with the most to gain whilst those able to push through the changes aren't interested as they have the most to lose.

Either way, until the counting process can be made significantly more transparent I couldn't see the public trusting the counts.

Off Topic - Testing

I have to say this new beta interface for Blogger is fairly impressive. I'd used the previous incarnation of Blogger before, as well as .Text for internal blogs at work, but this really is much better. The ability to arrange page elements without having to care about the underlying HTML is very liberating... just wish there was a way to build web apps without having to care about the HTML! (yes I know about Flex)