Scantegrity Election Manager

From Scantegrity Wiki

The Scantegrity Election Manager (SEM) creates and manages Scantegrity (and also Punchscan) elections. It provides the following functionality:

  1. Pre-election data creation, commitment, and ballot generation.
  2. Responds to pre-election audit challenges, opening all commitments for physically or virtually spoiled ballots.
  3. Tallies results using the data from scanners, and posts confirmation codes online.
  4. Responds to post-election audit challenges, opening all commitments for physically audited ballots, and also opens partial commitments for the tally audit.

Section 3.3, Page 22 of the Punchscan VoComp Submission has more details about this component. We encourage interested readers to add more details to this page or propose changes in the discussion tab.


SEM is responsible for managing secrets, and it's security plays a role in protecting voter privacy. The security threshold in SEM partially relies on the context in which it is used. The various contexts (from lower to higher levels of security) are as follows:

  1. Part of a web interface.
  2. Java applet in a web page.
  3. Downloadable Java Web Start program.
  4. Standalone program on a personal computer.
  5. Bootable application on a diskless workstation.

In 1-3 above, security of the secrets is considered to be pretty low. In 4 it is slightly better. In 5, which is what we expect to see in official government or high-security private elections, multiple trustees cooperate to use the software and protect the secrets. A special section at the end of this document covers the additional requirements for 5. A 6th context, where multiple, distinct copies of the software perform secure multiparty computation is in the works for future versions.

N.B. All data processed by SEM is audited. While it is undesirable and could cause catastrophic problems, using SEM on a compromised system does not effect integrity of the election. Such scenarios motivate much of the design behind Scantegrity.

While SEM assumes the system it is running on isn't hacked, it does not leave data in an unprotected state. Data on system that becomes compromised should stay safe, provided the compromise is detected. Also, third parties should not be able to retrieve data by directly accessing the disk, etc.

When communicating with other components, SEM will attempt to do so through asymmetric (public key) cryptography. This involves cryptographically pairing with the other components during the pre-election phase. This pairing involves reading and storing the public keys generated by other components, then generating it's own (or using a pre-existing) public key to be pushed back out to the components.

When security hardware, such as a Trusted Platform Module (TPM), is present on the system SEM will give the user the option of utilizing that hardware.

Pre-Startup (High Security Only)[edit]

Ask the users to insert their read-only drives, and run the integrity check on them. Then give the users an option to reboot or continue on to the next step.


Search for ballot or election definition files in standard system locations (the user's home directory, mount points, etc). If found, list each file for the user to select. If not found, display a prompt for the user to find the appropriate file and select.

Detect the current state of the election. Pre-election is just a ballot definition file with no election details filled in. The other states will contain election data files with information.


For each of the states, SEM follows a common workflow:

This picture should have 4-5 boxes describing the various phases (Load software, ask for input files, process, etc). Maybe it's not worth it to put a picture here? It seems like it would help newer people, though.

  1. Loads all available elections into election chooser.
  2. Verifies all cryptographic information for each chosen election.
  3. Asks for passwords for secret sharing system (if necessary).
  4. Run the necessary state-specific operations.
  5. Signs and timestamps the file using the secret data.
  6. Saves a log file attached to the end.

State-specific information is as follows.


  1. Reads the ballot definition file created by the Ballot Creator.
  2. Using the ballot data, generates the Digital Audit Trail (DAT) file to post online before the election.
  3. Generates ballots...
    1. for printing directly to an attached printer.
    2. in an encrypted equally split set of monolithic PDFs for printing.
    3. in individual PDFs stored in a compressed format for upload to the web.

Pre-Election Auditing[edit]

  1. Reads the election definition file, and tries to detect the audit file.
  2. Provides a listing of the ballots to be audited and those to be printed to allow users to verify the files were read correctly.
  3. When users press okay, audit-response file is generated to be posted online and saved in the location presented by the user.

Results Tallying[edit]

  1. Reads the election definition file and audit file, then tries to find the tally file.
  2. If it fines the tally file, it verifies that no audited ballots were used during the election, and produces a tally along with any errors.
  3. When users save, the tally file is saved to be posted online.

Post-Election Auditing[edit]

  1. Looks at all previous election definition files and verifies for correctness.
  2. Finds post-election audit file, and summarizes results for users.
  3. Saves the post-election audit file for posting online.

Cryptographic Description[edit]

A description of the cryptographic details is available.


The interface is a wizard style interface that enables users to perform certain actions based on the current state of the election. At the end of each series of actions, the user gets the chance to go back and perform the same actions for another election that was detected or added to the system.

Known Error States[edit]