Welcome Guest. | Log In| Register | Membership Benefits
  • Email this page E-mail this page
  • |  Print Print this page
  • |   Bookmark and Share

Cryptographic Voting System Runs First Election

Scantegrity II is an open-source election verification technology that uses privacy-preserving confirmation numbers to ensure each vote is counted

Nov 20, 2009 | 09:17 AM

By Dr. Dobb's, Special to Dark Reading

In a recent Takoma Park, Md. election, a new cryptographic voting system that ensures accurate vote counts was used for the first time in a real election. Scantegrity II is an open source election verification technology for optical scan voting systems. It uses privacy preserving confirmation numbers to allow each voter to verify her vote is counted. The confirmation numbers also allow anyone to verify that all the votes were counted correctly. The system is a variation on conventional optical-scan voting. But instead of filling in a bubble next to a candidate's name, the voter uses a special pen that exposes a code printed inside the bubble in invisible ink. Voters can write down that code, along with the serial number of their ballot, to later verify the results online.

A voter can't, however, offer a would-be vote buyer proof that they selected a particular candidate, since the code isn't associated with the candidate's name. If enough people confirm their codes -- about 2 percent of voters -- it's almost impossible for vote tampering to go undetected.

The key to the system is that before the election, the election commission prepares a set of tables that link the ballot codes and the candidates' names. Then, it publicly releases a set of digital signatures that cryptographically describe all the entries in the tables without actually revealing them. That way, the tables can't be tampered with after the ballots are cast, but neither do they reveal any information that ballot stuffers could use before the election.

In the Takoma Park election, the election commission used 20 distinct sets of tables, with three tables in each set. In each set, the first table listed the codes printed on each ballot. The codes were listed in a random order to make it impossible to tell which code was associated with which candidate. The third table featured only the candidates' names at the top -- it was simply a grid for recording the votes assigned to each candidate. The second table mapped each code in the first table to a unique slot in the third table. This second table ensured that the slot fell under the right candidate's name, but the mapping was otherwise random to make it impossible to tell from a slot's location which ballot it corresponded to.

After the election, for each of the 20 sets of tables, the election commission web site posted the final tally using the grid in table three. It released the codes in table one that were actually exposed in the voting booth, along with encryption keys that verified their authenticity. And it randomly released half of the information in table two: either the half that pointed backward, to the codes in table one, or the half that pointed forward, to the slots in table three. Finally, it flagged all the entries in table two correlated with recorded votes -- with exposed codes in table one and slots checked in table three.

Exposing only half of table two preserves voter anonymity: There's no way to figure out which ballot went for which candidate. But it also provides enough information that any attempt to tamper with the results can be detected. To change the final tally, a ballot stuffer would have to insert fake votes into table three. But that would entail spuriously flagging the corresponding entry in table two. And that would entail revealing the corresponding code in table one -- which a voter who checked her code online would notice.


Subscribe to RSS










Bugs
ENTERPRISE VULNERABILITIES
Vulnerability:suse linux
Published:2010-01-22
Severity:High
Description:SUSE Linux Enterprise 10 SP3 (SLE10-SP3) configures postfix to listen on all network interfaces, which might allow remote attackers to bypass intended access restrictions.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:The URL validation functionality in Microsoft Internet Explorer 7 and 8 does not properly process input parameters, which allows remote attackers to execute arbitrary local programs via a crafted URL, aka "URL Validation Vulnerability."
Vulnerability:bind
Published:2010-01-22
Severity:Medium
Description:ISC BIND 9.0.x through 9.3.x, 9.4 before 9.4.3-P5, 9.5 before 9.5.2-P2, 9.6 before 9.6.1-P3, and 9.7.0 beta does not properly validate DNSSEC (1) NSEC and (2) NSEC3 records, which allows remote attackers to add the Authenticated Data (AD) flag to a forged NXDOMAIN response for an existing domain.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:Microsoft Internet Explorer 6, 6 SP1, 7, and 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka "Uninitialized Memory Corruption Vulnerability," a different vulnerability than CVE-2009-2530 and CVE-2009-2531.
Vulnerability:ie
Published:2010-01-22
Severity:High
Description:Microsoft Internet Explorer 8 does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by accessing an object that (1) was not properly initialized or (2) is deleted, leading to memory corruption, aka "Uninitialized Memory Corruption Vulnerability," a different vulnerability than CVE-2009-3671, CVE-2009-3674, and CVE-2010-0246.


Briefing Centers
POWERFUL INFORMATION
AT YOUR FINGERTIPS
(SPONSORED LINKS)