William Kelleher
has been
publicizing
a
paper
entitled "Internet Voting: The Great Security Scare". Here's his thesis:
This paper will present a social science paradigm for critically
evaluating the security concerns most often expressed by opponents of
Internet voting. In 2003, these concerns were so effectively expressed
that they resulted in the US government ceasing all efforts to even
experiment with voting from overseas via the new technology. However,
when examined within a context of social scientific reasoning, the
arguments that stopped the progress of Internet voting in the US
appear as mere appeals to fear, bereft of rationality.
First, the problem of how to think about e-crime in general will be
discussed. Secondly, the framework that emerges from that discussion
will be applied to the arguments against Internet voting. The
conclusion will suggest that Internet voting can be conducted with a
degree of security similar to an online purchase, a million dollar
bank transfer, or a secret military communication. As shown in the
essay, the technology already exists, and has been honed over many
years of use. While there are differences between the military uses of
the Internet, e-commerce, and Internet voting, this paper will argue
that the degree of security for each need not vary significantly.
Ordinarily, I don't bother to engage with this weak an argument,
but Dr. Kelleher is starting to get some publicity and so I
thought it was worth giving it a read. I didn't find it very
convincing, but rather than make a point by point rebuttal,
I want to focus on what I think is generally agreed to be the
most serious obstacle to any Internet voting system:
the security of voter's computers. As I've mentioned
before, malware on the user's computer has the opportunity to
totally compromise his vote, and writing that kind of malware
isn't particularly difficult.
Kelleher's discussion of these issues is mostly framed as a rebuttal
to the SERVE report,
which discussed the security of a particular proposed Internet voting
system. The SERVE authors were quite concerned about this sort of
malware and discussed a number of vectors by which it might
get on a user's computer, including backdoors on installed
system software, viruses/worms, and booby-trapped websites.
Kelleher's paper takes each of these on in sequence. Let's take
a look at just one example, the material about backdoors (the dismissive tone is fairly
typical).
This statement suggests that a company favoring Republicans could
program all the computers with its software to vote Republican, even
if the voter thinks he or she is voting for a Democrat or Independent.
A Socialist-favoring company could jigger the vote its way, etc.
Here, the Super Sleuths think they have uncovered the potential for a
massive conspiracy by software makers to control US elections by
selling people loaded software. But, what would be necessary to carry
out such a scheme, and what risks would the perpetrators be taking?
First, such a scheme could only affect an Internet-based election in
our country if the company sells tens of thousands of loaded product.
But, the more they sell, the greater the risk of being caught.
Someone who is wary of just such a scheme, whether a citizen computer
scientist, or a law enforcement official, is going to examine the code
in every type of voting-related product and discover the trick.
Once caught, the executives, and all who conspired with them, risk
having to pay huge fines, being sentenced to prison, and losing their
livelihood. After they do their time, no software company would hire
them, because customers would become suspicious of the company's
product. These convicted felons would be lucky to find jobs as taxi
drivers, or doormen. How many people who are intelligent enough to
run a software manufacturing business are going to be stupid enough to
risk these consequences in the forlorn hope of changing some votes to
favor their own political party or candidate?
First, this seriously misrepresents the SERVE report, which doesn't
at all contemplate that the company would insert the backdoor.
In fact, it quite clearly implies the contrary:
"Today's computers come loaded with software developed by many different entities; any employee at any of those companies could conceivably leave a backdoor that attacks SERVE."
Modern software is generally developed by large teams and controls
on the code that authors check in is generally fairly lax. In many
environments it wouldn't be at all difficult for an attacker to inject
arbitrary code without being detected, especailly if they made some
effort to hide it. (More on this in a bit.)
Second, the suggestion that outsiders would actually review
all the code in your average computer and detect this kind of
attack is, let's say, extremely problematic. As the SERVE authors
correctly observe, any software on your machine could
have a backdoor in it, not just the voting software. This
means that on your average machine you need to audit all
of Windows, Office, IE, Firefox, etc. Estimates I've heard
of the number of lines of code in Windows alone run into
the tens of millions, and the cooldifficult
thing about a backdoor is that it can be anywhere in the code
base. Auditing this sort of system is a massive (read: totally
impractical) project. When we did the Top-To-Bottom Review,
we had our hands full just looking for unintentional vulnerabilities
in a code base about 1% as large, we didn't even try to look for
backdoors. And of course, we had the advantage of the source code,
which vendors generally regard as pretty secret. Your average
reviewer is not going to have the source code for Windows.
Moreover, there's no reason to inject something as obvious as a
program to change votes. All you need is a remotely exploitable
vulnerability known only to you, and this can be as simple
as a missing array bounds check, integer overflow check, etc.
Then when you're ready to install your malware you exploit
the vulnerability and there doesn't need to be any voting specific
code to find at all. This has two advantages: (1) it's hard to find
because it's a small error and (2) even if you get caught you
can plead incompetence. Given the number of vulnerabilities found
in your average program, it's extremely improbable that you
would suffer any consequences—certainly none of the existing
voting vendors have been arrested for vulnerabilities found in their
systems. [To be totally fair, the SERVE report doesn't make this point
quite as clearly as one might like]
I don't propose to go through the rest of the paper point by point.
Suffice to say that overall it betrays a fairly shallow understanding
of the state of computer security and mostly depends on the
ever-popular "argument from incredulity". In particular, Kelleher
is incredulous that there could ever be widely deployed malware
that infects a large number of computers. As it happens, however,
not only is this possible, we already have several worked examples
in the form of large botnets. It's not hard to envision repurposing
that sort of software to mount attacks on voting systems. Actually
it's in some respects easier because you don't need any command
and control, you just deliver the attack payload; it waits
till election day and then activates. Far from being
incredible, then, this attack seems fairly practical.
Recent Comments