Over the last few days, Alex Halderman and his team at the University of Michigan hacked an Internet Voting System being field-tested by the DC Board of Elections. First, we need to commend both Alex’s team for their dutiful analysis of this system, and, more importantly, the DC Board of Elections for running an open security evaluation of their system. I say “more importantly” because there is very little good press to gain from such a test: in fact the DC Board of Elections is already getting a lot of grief, the hah-hah-they-got-haxored articles just write themselves. I think they did exactly the right thing: they experimented with a technology, and they did so by running an open security evaluation. Kudos to them. I sincerely hope that this is the beginning of a trend, and even those who criticize Internet Voting should take a few moments to first commend the DC Board of Elections.
The Halderman DC Internet Voting Hack is not specific to voting: it’s a fairly standard input-corruption attack on a web application. With more work and more security testing, the voting system will probably get better and more difficult to attack. More consistent input validation, running the server chrooted to limit the effects of this kind of attack, etc. Much can be done to make the voting application more secure. But, as Halderman and team correctly point out, it will never be fully secure, because nothing ever is.
The first and obvious conclusion is that Internet Voting for high-stakes public-office election is a very risky proposition, because suddenly your world of eligible attackers includes anyone with an Internet connection. But there’s a deeper conclusion, and I find it surprising that many voting security pros don’t see this more clearly: when we say “every system is vulnerable to attack”, that includes paper-based voting systems! Without an internet connection, it’s harder to attack a paper-based voting system, but it’s still doable. And the key problem is that, when a paper-based voting system gets attacked, the recovery story is not much better than that of an Internet Voting system.
The best example of this sad state of voting security is one I learned from Alex’s previous work hacking the Indian voting machines: in remote precincts in India, with their paper-ballot voting system (prior to the recent Electronic Voting Machines that have resulted in so much controversy), there’s long a type of attack called “precinct capture,” where attackers literally hijack a precinct and take the staff hostage while they stuff the ballot box with extra votes. Then they leave. Oh sure, you know who did it. But what can you possibly do to recover? Which votes do you discard?
My friend and voting technology veteran Jim Adler likes to talk about “Fort Knox vs. Barking Dog.” If you think about security like Fort Knox, where you focus on preventing someone from penetrating your defenses, you’ve got to invest incredible amounts of money and build incredibly sophisticated fences. If your defenses fail, and someone penetrates Fort Knox, gets the gold, and leaves, you are screwed. Because it’s gold, it’s not traceable, and once it’s stolen, it’s gone for good and there’s no way to recover.
The Barking Dog model is different. You still build fences. Maybe even a fancy lock. But more importantly, you get a well-trained dog, maybe even two or three for redundancy. And you assume that some of your fences will fail, because that’s what fences do when faced with smart intruders. When they do fail, and someone comes in, that’s where the barking dog comes in. Your defenses may fail, but your detectors will sound the alarm, allow you to respond and, hopefully, recover from the intrusion.
So back to voting with our new-found Knox v. Dog wisdom. Can we get a “barking dog” model of voting? The main reason it’s not so easy is because of the secret ballot: we want to ensure that, other than you, no one knows how you really voted. Because of this simple requirement, it’s very, very difficult to detect a problem. Even with paper-based systems, the answer is “sort of” at best. There’s a bunch of fascinating research into optimal auditing techniques, but the problem with all of these techniques is that the dog barks only under certain conditions, and even then only way too late. By the time you find out that something bad happened, there’s no way to recover. Consider again the Indian precinct capture attack. What can you possibly do to recover from that?
The Barking Dog is only useful if it barks in time for you to do something about it. That’s why I am increasingly convinced that, now that we have the technology to build systems that can be truly audited by the public thanks to individual tracking numbers and cryptographic auditing techniques, all while preserving the secret ballot, it’s simply sound engineering to do so. With these open-audit systems, any voter can be a barking dog.
So, we should clearly rethink our attempts at Internet Voting in high-stakes public-office elections. But, by the same token, we should rethink all election processes that do not provide recovery from error or attack. Paper-ballot systems may be noticeably less vulnerable to attack than Internet voting systems, but once they are attacked, they are hardly more recoverable. Now that we know how to do better, we should not rely on a Fort Knox, impenetrable-fence model of voting security, even with paper ballots.
UPDATE: Jim dug up the archeological trail of the Barking Dog in voting technology: a VoteHere blog post referencing an MSNBC report on their technology. Also, typo fix and clarification regarding the Indian precinct capture attack.
Comments
2 responses to “Fort Knox vs. the Barking Dog”
An inherent vulnerability of currently proposed Internet Voting systems (or other internet services with high security requirements, such as electronic banking) is that you have a trusted intermediate party to your transaction, namely your workstation. After all, it is your workstation which will need to interpret and apply your voting preference to the downloaded ballot.
However, nowadays a significant portion of workstations is infected with malware, which could lead to election fraud without any possibility for detection (as the perceived behavior of the workstation is no different from when it would not be under malware control). In my opinion, this is a larger risk to online voting, as it has nothing to do with web application security.
The mistakes made by the programmers of this application could have been easily prevented if they had performed a code review themselves (e.g. with the OWASP standard in hand: http://code.google.com/p/owasp-asvs/wiki/Verification) – which is something you cannot do three days before going live, and you cannot just depend on ‘the community’ to do that for you.
[…] subscribe to my RSS feed (using BlogBridge, of course) . Welcome, and thanks for visiting!Check out Fort Knox vs. the Barking Dog(from Benlog: "The Barking Dog model is different. You still build fences. Maybe even a fancy […]