DC Internet Voting Trial Attacked 2 Different Ways 123
mtrachtenberg writes "University of Michigan Professor J. Alex Halderman and his team actually had two completely separate successful attacks on Washington, DC's internet voting experiment. The second path in was revealed by Halderman during testimony before the District of Columbia's Board of Elections and Ethics on Friday. Apparently, a router's master password had been left at the default setting, enabling Halderman to access the system by a completely different method than SQL injection. He presented photographs of a video stream from the voting offices. In addition, he found a file that had apparently been left on the test system contained the PINs of the 900+ voters who would have used the system in November. Others on the panel joined Halderman in pointing out that it was not just this specific implementation of internet voting that was insecure, but the entire concept of using today's internet for voting at all. When a DC official asked why internet voting could not be made secure when top government secrets were secure on the internet, Halderman responded that a big part of keeping government secrets secret was not allowing them to be stored on internet-connected computers. When a DC official asked the panel whether public key infrastructure couldn't allow secure internet voting, a panel member pointed out that the inventor of public key cryptography, MIT professor Ronald Rivest, was a signatory to the letter that had been sent to DC, urging officials there not to proceed with internet voting. Clips from the testimony are available on YouTube." Update: 10/09 19:24 GMT by T : Reader Cwix points out two newspaper stories noting these hearings: one in the Washington Post, the other at the Chicago Tribune. Thanks!
Please use internet voting (Score:5, Informative)
to mod me up to +5 informative, to show it does work perfectly!
Inventor? (Score:5, Informative)
> the inventor of public key cryptography, MIT professor Ronald Rivest,
Rivest is a brilliant, very accomplished man, and was one of the inventors of one of the earliest and best-known public-key cryptosystems. But it's misleading to refer to him as "the" inventor of public-key cryptography in general. He co-invented RSA with Shamir and Adleman (several years after Cocks came up with it and kept it secret). But the concept of public-key cryptography was described before RSA, by such luminaries as Diffie, Hellman, and Merkle. He is certainly one of the pioneers of public-key crypto, and deserves acclaim for that, but is not "the" inventor of the concept.
Incidentally, much of Rivest's recent work is in the area of electronic voting (how to make it simultaneously accurate/auditable, privacy-preserving, and usable by non-technical people)--so he's not just speaking as a luminary in the field, but as someone who has studied this specific problem.
Actual article (Score:5, Informative)
The youtube videos are all well and good.. heres a few links to written articles about this though
http://voices.washingtonpost.com/debonis/2010/10/prof_explains_how_dc_online_vo.html [washingtonpost.com]
http://www.chicagotribune.com/news/chi-ap-dc-dcelections-heari,0,541741.story [chicagotribune.com]
Corrrections to post text (Score:5, Informative)
Re:Facts don't matter (Score:1, Informative)
With ATM's, it's much easier to see if something has been tampered with. Historical data is being saved, and people on both sides of the transaction are keeping records and correlating things (at least in theory).
With votes, keeping a significant historical log with detailed correlations between what 'client' made what input into the system is something that actually can't be kept, due to the anonymity of the voting process.
So, from a strictly 'what is being done' context, there is definitely an additional wrinkle and difficulty in the design of a voting system.
Add in the highly cynical analysis of the real world situation and the fact that the ones in charge of ATM's are the banks, who will lose money either directly or indirectly for the lack of security, but with voting, you've got elected officials who would benefit from being able to game the system are the ones in charge of setting up the voting system...
It's a tougher problem, paired with less motivation to do it right (combined with a possible motivation to do it wrong...) Makes sense when seen from that perspective.
Re:Votes simply don't matter... (Score:4, Informative)
'I don't understand why people are so up and up about the voting system...'
Because letting a bad system become worse is not a good way to improve it.
Re:Facts don't matter (Score:3, Informative)
When user votes, for his vote a checksum is created using one-way algo (digest) which is formed from:
Session ID, Voter name, Vote result, a unique key given only to voter and known only by voter and govt, date.
Now crack that one ;)
It doesn't need to be cracked, it's already broken; that unique key known to the govt breaks voter anonymity.
Re:A solution to a problem that doesn't exist (Score:3, Informative)
Programs aren't open source and are not available to scrutinize.
Yes and no. The EAC (Election Assistance Commission, formerly the Federal Elections Commission) has a very fat book full of regulations and specifications to which voting systems should be certified. (Technically certification is voluntary, in practice many states and counties will only approve certified systems for purchase.) The testing and certification is done by independent Voting System Testing Laboratories (VSTLs). Testing covers everything from hardware (security of locking mechanisms and seals, resistance to ESD and power glitches, etc) to software (line-by-line inspection of source code, independent builds of the source using independently acquired or verified compilers, etc) to running simulated elections and verifying counts, etc. A lot of the validation data for certified systems is available on the EAC web site.
Not that any of this is 100% foolproof, the standards don't cover everything conceivable.
(I worked for a VSTL mostly doing source code review, also security analysis of the system design,both as documented and checking that implementation matched documentation. I rejected a lot of code, although much of that was for commenting that wasn't up to standard rather than potential security holes -- although there was a lot of failing to check for null pointers. If the logic really looked squirrelly, but met coding standards, I had to okay the code but could write up a test case to check it out during system testing. The code itself of course was all under NDA and security in the labs was pretty tight -- although not quite as tight as for the game testing lab next door.)
Too bad you're clueless. (Score:4, Informative)
A democracy means there is a vote to either directly approve laws (direct democracy) or to elect representatives to do the same (representative democracy). Republic literally means ruled by the public, not by a monarch or a non-elected supreme rule. America is a representative democracy that limits government power with a constitution, but since that constitution can be changed by democratic action, you cannot say that it isn't a democracy. We could do away with the constitution in another constitutional convention and replace it with another if we so chose.
Just because you read Atlas Shrugged yesterday doesn't mean shit to anyone else. Crawl back over the Drudge Report, where you can eat up the talking points regurgitation with the rest of the libertarian zombies.
Re:There's an even bigger problem: selling votes (Score:3, Informative)
Whats to prevent someone from paying you to vote a certain way, by having you fill out the ballet, giving it to them, and if you have followed their instructions, they pay you and they put the ballot in the envelope and mail it for you.
Not a lot, which is why the availability of absentee ballots has often been strictly regulated and monitored. A few years ago, the UK tried an experiment in some areas in which all voting was by mail and there were no ballot boxes. There were some fairly impressive issues with fraud - people from the Labour party were going door-to-door, collecting people's blank ballots and filling them in.
Re:You had me until "stooges" (Score:3, Informative)
f it could, this would be known well in advance, since it's trivial to compare the proof with the code to see if they differ, and trivial to inspect a proof to see if the code could do that.
Really? You can somehow walk up to a computer and know the code on it is the same code that other people inspected?
That is...implausible to say the least.
This is because, of course, security certifications don't protect against the people installing the software. At all. Not a single one of them is even slightly designed to let users verify things administrators have done.
Seriously, you sound so knowledgeable, but somehow you think there's a way to walk up and verify that computers have had the software installed on them that you think they've had installed on them, and nothing else. That is so cute.
No, nobody can tamper with it, that's why I've stipulated so much bloody security. Machines that are input-only (where the voter registration office adds users) have mandatory access control, as do the voting machines themselves (by definition, since that is part of what A1 means). The counting system is essentially output only from the users perspective and therefore has no user account to crack. Input over the network would be via IPSec-utilized certificates with both client and server validating each other. Since the server has a pre-programmed list of acceptable voting machines, additional machines cannot be added in.
And, of course, nowhere in the list is there any way, nor can there be any way, to stop someone from sitting down at one of the machines and using a dozen of public keys to vote. (Which, as I pointed out, anyone working in a vote registration office can get.)
Because that is not, in any sense, 'tampering' with the machine.
Now, you'll probably assert they'd have to each vote individually, limiting their effect to a couple of dozen votes before they'd obviously be caught, because of the magical software you're sure will be there.
I will point out that, in no circumstances, would any TCSEC requirement restrict doing thousands of perfectly valid inputs in a few seconds, although obviously that could be an additional requirement of the system. TCSEC systems verify input. Ten thousand votes with public keys attached are correct input.
I will also point out that A1 security ranking is, um, impossible without physical security...and they get tested after being installed. You can't stick a computer in a box, pull it out six months later, and claim it's A1 security, unless you had someone watching the box at all times.
And note you've added at least two other computers to each polling site. And each voting computer needs some way to read the public key, so you've added a barcode reader, at least, to them.
To actually install A1-level security computers, you would spend millions of dollars per site.
Which makes the whole thing rather idiotic to start with, as we could never afford it, on top of the problem that A1 security is not designed to protect against a) programmer/administrative tampering (Which is what we're fucking talking about when we talk about tampering...we're not assuming voters figure it out.), and b) there's a rather obvious hole in the system of assigning public keys, so people can have entirely, utterly, completely 'valid' inputs that rig an election.
Here are the three specific security issues I've pointed out, that do not exist under paper voting. Please explain how your system catches them:
a) The person who loads the software onto a machine alters it before doing so.
b) Someone in the voter registration office adds extra voters to the roles, and takes their public keys, and they and others vote multiple times when they enter the booth. (This actually is fixable.) c) b, but with one poll worker also helping them. Perhaps by, when setting up the computers, they simply set one up in another room, so someone can