California Internet Voting Task Force
Technical Committee Recommendations
Table of Contents
The Internet Voting Task Force did not attempt to design a system for i-voting. Rather, we have concentrated on specifying requirements that such systems must meet. There are many possible implementations that will meet all of these requirements; the actual designs will reflect the influence of the Legislature, vendors, certifiers, and county procurement processes.
The following requirements recommended by this Task Force apply broadly to i-voting systems, and are not tied to any particular step in the process.
Requirement: In addition to certification with respect to traditional criteria for voting systems, any i-voting system should be certified by a Technical Review Committee composed of experts in computer- and communication security and privacy, including experts in cryptography.
The security and privacy of i-voting systems will depend critically on the entire range of computers, networking, and software used in both vote servers and vote clients, and also on careful end-to-end analysis of cryptographic authentication, and privacy protocols. The kinds of expertise sufficient to certify the traditional paper-based or mechanical voting systems are wholly inadequate for i-voting systems.
Requirement: i-voting systems should be recertified regularly.
The computing world, changes rapidly. At this stage in history the software that is commonly available for servers and clients may change considerably within any two-year election cycle, so that what was a good, efficient architecture one year may be very inefficient, or even incompatible with widely available systems, only two years later. This is particularly true of security systems and infrastructure.
Eventually cheap special-purpose voting devices may appear on the market; or perhaps more general machines with strong security architectures built-in to the operating system will become widespread (as opposed to the extremely insecure PC environments of today). Such eventualities would call for re-evaluation of i-voting systems, perhaps with the decertification of older systems and certification of new ones. (This is not as expensive as it seems; costs for all kinds of hardware will continue falling so fast that for the foreseeable future two-year-old systems will always be substantially depreciated anyway.)
Requirement: Laws against vote fraud must be reviewed in the context of i-voting.
Current laws regarding vote fraud, vote coercion, vote selling, and other election violations were drafted with paper-based balloting systems in mind. All such laws should be re-examined, and extended or broadened where appropriate, to be sure that they prohibit interference with the privacy and security of i-voting as well.
Special consideration should be given to criminal penalties for
Consideration should also be given to the legal recourse California may have if its i-voting processes are attacked through the Internet from foreign locations. The Federal government should consider international law or treaties to cover the case of one countryís citizens interfering by Internet with the elections of another.
Requirement: The secrecy of a voterís ballot choices should be preserved, and every reasonable technical means should be used to prevent anyone from violating ballot privacy anywhere along the path from the voter to the canvass.
The natural response to this requirement is that ballots must be encrypted for transmission from the vote client to the vote servers, and we require that. But there are other potential threats to voter privacy that may occur before the ballot is encrypted. There are many standard commercial or freeware systems that allow one computer to monitor another, or "share" files or devices with it, or control it, through a network or through the Internet. These tools are usually quite legitimate; they are used by traveling workers who want access to the home base machine, by system administrators in the management of networks, by managers monitoring the work of employees, and often in home situations where a knowledgeable person helps maintain the computer of a less knowledgeable person, and does so remotely.
But remote monitoring or management software can also be used by a person at one computer to spy on someone who is voting at another computer, or even to control the voterís computer during voting. Voting software should therefore be designed to check for the presence of the common kinds of remote control software, and it should then inform the voter, and not allow voting on the remotely monitored or controlled machines.
Even in cases where no known remote monitoring software is found in the configuration, i-voting software should check to see if the computer is networked at all, via LAN, or open PPP or SLIP connection, or wireless connection, or any other means; if so, it should warn the voter that it may still be possible for voting to be monitored through another computer on the network, and that the voter should not use a networked computer for voting if he or she is concerned about privacy.
In voting software configurations designed for kiosks, the configuration simply should not have any remote control or remote monitoring facilities at all.
Requirement: The ballot that is transmitted to the vote server must be an accurate copy of the voterís choices, with no reasonable possibility of undetected modification anywhere in the transmission path in any of the intervening computers and networks, including within the voterís own computer.
This requirement may sound fairly direct to people unfamiliar with computer security, but it is probably the most difficult-to-satisfy requirement in this document, and it may disqualify many otherwise attractive i-voting systems. It is vital that vendors take this requirement seriously, and that certification authorities do likewise.
Requirement: Internet voting should not continue through Election Day, i.e. there should be a time in advance of Election Day, fixed by law, when i-voting is cut off.
It is only natural that voters will wait until almost the last hour to vote by Internet. As with absentee balloting, there is an incentive for voters to wait until near the deadline so that they will have the most time to study the candidates and issues, and so they will be able to watch for as long as possible how the campaigns develop.
But with i-voting, waiting until the last minute can be risky. The first problem is that the voterís own computer might encounter hardware or software trouble. If this were to occur in the last hours of election day, such a technical problem might prevent the voter from voting because he or she will not have time either to correct it or to go to the polls.
Another concern is that a large fraction of the entire i-voting electorate can be expected to wait until the last hours to vote. Since the heaviest vote load will hit the vote servers then, it is the most likely time for overload, attack, or failure of the vote servers or of the communication links to them. Such a problem in the last hours of election day would effectively disenfranchise all procrastinating Internet voters.
For these reasons it seems wise to close i-voting a day or two before election day itself. That way, voters will be much less likely to be disenfranchised because of technical failures, either of the client machine or of the vote servers. If a voter is not out of town, he or she would be able to vote (provisionally) at the polls.
Requirement: During the i-voting window, test ballots should be regularly transmitted from all county-controlled vote clients to verify the end-to-end integrity of the entire system.
Throughout the time when i-voting is permitted, county officials should cause special test ballots to be submitted from all of the Internet vote clients under its control as part of a continuous, online logic and accuracy (L&A) test. These ballots would be indistinguishable from real ballots for all purposes except that they would not count in the final vote tally. County officials should know exactly how many test ballots are sent, and when, and from which machines, and what "votes" the test ballots contain, so that any lost ballots, extra ballots, or changed ballots can be immediately detected and appropriate action taken.
For vote clients not under county control, e.g. in homes or institutions, this procedure may not be practical. But some other L&A protocol that makes it more difficult for malicious code to interfere with voting without being detected should be employed.