SERVE

SERVE was a proposed trial of internet voting to be conducted in 2004. After the SERVE security report came out, the trial was halted. SERVE lacked adequate defenses for many problems regarding practical security. These include viruses and outsider attacks - voters can't verify their votes to ensure that it was not changed by a virus, and the system suffers from a single point of failure.

Infrastructure attack protection
All internet voting systems are vulnerable to denial-of-service attacks. There are defenses to these kind of attacks, but they can't stand up to an adversary given sufficient computing power. In the event of such a situation voters would have to vote in person (or by mail). But SERVE makes this problem worse: most other internet voting systems close a few days before the election (for instance, Norway's closes before election day ) but SERVE stays open during election day. As Jefferson et. al note in the SERVE security analysis - "This introduces the threat of last-day denial-of-service attacks in which the attacker mounts a denial-of-service attack starting on the morning of Election Day and lasting until polls close." Therefore, voters may not have time to choose another option to vote if this occurs. Exacerbating the problem is the fact that many of them are overseas voters - if they were to switch to VBM at the last minute their ballots probably wouldn't be counted.

Outsider hacking protection
As Jefferson et. al write in the SERVE security analysis "Since the servers are a central single point of failure, it is absolutely vital that they resist attack. The risk of intrusion into SERVE's centralized computers is, unfortunately, significant. SERVE has deployed a careful and well-designed firewalling architecture designed to prevent many kinds of direct attacks; however, there remain possible vulnerabilities in the software exposed to the outside world that could enable attackers anywhere on the Internet to penetrate SERVE's defenses and gain control of the servers.... Designers of safety-critical systems typically avoid the use of commercial software, because it is widely accepted that standard commercial programming practices pose an unacceptable risk for such applications. Designers of safety-critical software employ known techniques for building highly reliable software. These elaborate and costly techniques have not been used in the development of SERVE." What's problematic here is that there is a central point of failure and once one machine goes offline the whole system is taken down. There's no auditor to tell if the results have been skewed, changed, or partially deleted. Even if the SERVE security analysis overstates the risk, it's still a major one.

Malware and virus protection
SERVE does not seem to have any protection against attacks from viruses. Users can't verify their vote using another channel (like in the Norwegian system with the receipt generator, or like in bulletin board systems), and can't re-vote.

Man in the middle attack protection
In theory, votes are encrypted and thus should be difficult for a man in the middle to tamper with. While SSL isn't perfect it effectively negates eavesdropping by use of Diffie-Hellman Key Exchange (which is secured from MITM attacks by the usage of certificate identities - the user just needs to trust the certificate authority). This, however, may not solve the issue that Jefferson et. al mention, namely that "attackers could engage in election fraud by spoofing the voting server and observing how the voter votes," and could then redirect the voter if the vote is to their liking.

Insider attack protection
There is not adequate protection against insider hacking attempts. Triinu Magi's game theory analysis noted that not only is it possible for insiders to control the Votes Storing Server, they could be incentivized to do so. Jefferson et. al note in the SERVE security analysis that "insider attacks are the most common, dangerous, and difficult to detect of all security violations" and that there are no countermeasures within SERVE architecture. Though this is a problem for voting system, it's especially problematic for SERVE because there is a centralized point of attack that can get compromised: the votes storing server. Because votes aren't stored encrypted they could be easily changed.

Coercion resistance
There is little protection against vote selling and coercion. Not only is this possible (through selling credentials or through selling modified ActiveX software) but it also could be rational for attackers to buy people's votes, as a game theory analysis purports to show.

Ensuring one person, one vote
The system should not allow multiple votes, assuming that keys are passed out successfully. (However, people can still break into the system and change votes via other means.)

Counting and tallying accuracy
Assuming everything runs perfectly, it should accurately count and record votes. But this is a big assumption. Votes in the vote storing system are not encrypted, and there's little to no voter verifiability. There's no auditor to help ensure that votes received are counted correctly as well.

Voter anonymity
Local election officials can deduce who voted for which candidate, votes exist unencrypted on the vote storing system, and there are giant databases with encrypted ballots + names (which poses a risk because they can be downloaded and then later cracked.) Also, man in the middle attacks could be easily performed when the goal is to compromise privacy - as Jefferson et. al note, "any man in the middle could act as an SSL gateway, forwarding data between the voter and the vote server unaltered."

Voter verifiability
There is verifiability, but it only comes into play after the voting period ends. As Jefferson et. al not, "is not clear what the procedure would be if after the election, a large percentage of absentee voters said that they had voted but did not see their names."

Immediate results protection
Because votes are stored unencrypted, results could be obtained before the voting system ends so long as the adversary in question has access to the votes storing server.

Ease of performing a recount
Performing a recount is not possible because there is no auditing trail. Votes can be counted again, but this doesn't solve for the insecurity issues present throughout the system.

Usability
It's unknown how usable SERVE was because it was never implemented, and there don't seem to be any articles that mention its ease of use.

Transparency
The Department of Defense allowed an independent set of security researchers (Jefferson et. al) to publish the SERVE security report, which is good in terms of transparency. The source code isn't open, however (it's based on commercial software). Overall, it's a great step forward in terms of transparency but it doesn't match what Norway is currently doing (for example).