Seven Principles For Secure E-Voting

E-voting can be as secure and confidential as paper-based voting, as discussed in the "Point/Counterpoint" "The U.S. Should Ban Paperless Electronic Voting Machines" by David L. Dill and Daniel Castro (Oct. 2008). However, to work properly, such systems must first incorporate seven design principles:

Proven security. All protocols and techniques must be mathematically proven secure. One-time-pad-based methods qualify, while popular cryptographic methods (such as AES, DES, RSA, and SHA) do not; historically, every cipher not proven secure has been broken;

Trustworthy design responsibility. Government security agencies (such as the U.S. National Security Agency and the German Bundesamt für Sicherheit in der Informationstechnik;) should be responsible for creating secure voting systems, though this work must be inspected and audited by experts selected and approved by all major parties taking part in elections. Private companies have shown they are unable to secure critical systems, including government ciphers and nuclear launch codes, so should not be entrusted to secure elections;

Published source code. The source code of all election software must be published and made publicly accessible;

Vote verification. All voters must be able to verify their votes as part of a complete nationwide tally of votes, as well as of individual voting-district-based tallies;

Voter accessibility. A full list of voters must be available to all citizens, allowing them to verify its accuracy; date and place of birth might be necessary parts of voter records to assure detection of duplicate entries;

Ensure anonymization. Techniques like onion routing must be used to ensure anonymization; and

Expert oversight. The government’s responsibility in the election system (including defense against denial-of-service attacks) must be handled by a team of experts selected and approved by all major parties taking part in elections.

Simple, mathematically secure methods for e-voting are conceivable, and voters’ confidence can be increased by allowing them to verify their votes in the nationwide tally, as well as review the full list of voters. As with any cryptographic method, the system must still rely on a chain of mutual trust, which will always be necessary. The chain of trust inherent in practical cryptography cannot be ignored in e-voting. Moreover, boot-from-CD voting software like Linux Live CDs, one-time pads, and onion routing would support more direct democracy. The economics of e-voting allow for much cheaper voting, thereby allowing more elections on a larger number of specific policy decisions.

Frank Gerlach, Baden-Württemberg, Germany

Back to Top

Dill Responds:

Rather than critiquing Gerlach’s complex yet vague proposal, I return to the question addressed in the debate. Suppose, for the sake of argument, that an elaborated version of that scheme allowed its operator to change votes without detection. The current and proposed standards and certification processes would be completely ineffective at protecting voters from such a system. A certification system that would be able to assure the security of paperless voting systems will not exist for many years, maybe never. On the other hand, it is possible to write testable requirements for secure voter-verified paper-ballot systems. That’s one reason they should be mandated.

David L. Dill, Stanford, CA

Back to Top

Castro Responds:

Many of Gerlach’s suggestions can (and often are) used in today’s e-voting systems and elections. Security, accountability, usability, and cost will all continue to be important factors in evaluating these systems. However, I disagree with the premise that in essence "nationalizing" the voting-machine industry is a good solution. The quality of an engineer’s final product is not dependent on whether or not the engineer works for private industry or for government. Competition can ensure that innovation continues and better voting system standards protect the electorate from unnecessary risk.

Daniel Castro, Washington, D.C.

Back to Top

Send IT Employees to Teach

Reading "Crossroads for Canadian CS Enrollment" by Jacob Slonim et al. (Oct. 2008), I thought of something not discussed directly in the article: Why not have industry employees contribute directly to the education process? Many of the causes the authors attributed to the decline of CS enrollment can be, at least partially, addressed by increasing the participation of IT employees in high school and university education. A general proposal would involve companies in the technology community initiating employee-teaching programs that give employees the option of serving as high school teachers or as visiting university professors for some period of time, say, two to five years. They could use their practical knowledge and industry ties to:

Share industry trends and create curricula for high schools and university CS departments that more closely align with the demands of industry;

Teach university courses on industrial topics or new technologies not traditionally addressed by CS departments;

Provide the kind of computing knowledge high school faculty often lack;

Serve as a visible representative of computing in the educational setting, as well as a role model for students; and

Create a direct line of communication between industrial and educational organizations.

This program should coincide with other industrial initiatives (such as donating equipment to schools and giving universities access to online training materials).

Declining interest in computing is disheartening and must be addressed for the future health of both the Canadian and the U.S. technology industries. For industry, money and effort spent today on education should be seen as an investment in its own future.

Bill Bushey, New Paltz, NY

Back to Top

Trickle Algorithm Corrections

The article "The Emergence of a Networking Primitive in Wireless Sensor Networks" on the Trickle algorithm I coauthored in July 2008 had two errors:

Sun SPOT sleeps. The article’s description of the Sun SPOT platform said SPOT sleeps by writing its RAM contents to flash while requiring significant time and energy to do so. The SPOT has an external RAM bank to which it saves its internal processor state when it sleeps and, by itself, does not incur a significant cost. However, SPOT wakeup requires tens of milliseconds to stabilize timing circuits and restore processor state. The alternative, used in most simple sensor-node designs, is to require just a few kilobytes of RAM and microcontroller wakeup times of tens of microseconds. This fast wakeup time allows nodes to quickly check for network traffic while spending less energy warming up to perform the checks; and

Srcr mesh routing protocol. The citation for the Srcr mesh routing protocol designed by John Bicket incorrectly cited Douglas S.J. De Couto’s MobiCom 2003 paper "A High-Throughput Path Metric for Multi-Hop Wireless Routing" when it should have cited John Bicket’s MobiCom 2005 paper "Architecture and Evaluation of an Unplanned 802.11b Mesh Network." The citation for De Couto’s paper also incorrectly listed the author’s name as Couto, D.D. rather than as De Couto, D.

Please accept my apology for these errors. I thank Randy Smith, as well as Douglas De Couto, for pointing them out.

Philip Levis, Stanford, CA

Back to Top