VxAdmin supports a variety of results exports.

Tally reports contain contest results for the full election or a specific subset of ballots. They can be printed directly from VxAdmin, exported as PDFs, or exported in CSV format. In addition, full election results can be exported as an Election Results Reporting CDF JSON file.

Ballot count reports include only ballot counts, without contest results. They can also be printed directly from VxAdmin, exported as PDFs, or exported in CSV format.

The write-in adjudication report acts as a summary of all write-in adjudication activity or as a "scatter report." The tally reports consolidates write-in candidates whose vote totals are too small to affect the contest outcomes. The counts for those write-in candidates are available in the write-in adjudication report. The write-in adjudication report may be printed directly from VxAdmin or exported as a PDF.

For all VxAdmin reports, the report is either "Official" or "Unofficial." If the report is exported before the results are marked as official in the application, the results are "Unofficial." If the report is exported after the results are marked as official in the application, the results are "Official." All visual reports have "Official" or "Unofficial" included in the title and all exported files will have "official" or "unofficial" included in the filename.

After a voter is done making vote selections with VxMarkScan, the machine will print a ballot representing the selections. The voter reviews the ballot and verifies ballot selections. The ballot is then cast into the attached ballot box.

Ballot Layout

The ballot displays information about the election, metadata about the ballot, and the voter's selections. The selections are both displayed and encoded in the QR code.

The blank space at the top of the ballot is included so that all of the ballot content is visible when VxMarkScan presents the ballot for the voter to review (since the top part of the ballot is held in the machine).

Multi-Lingual Ballots

If VxMarkScan is being used in a language other than English, the resulting ballot will be multi-lingual and feature the other language. All pieces of text that appear on the VxMarkScan ballot may have translations specified in the , which will then be used when printing the ballot.

QR Code

The QR codes on VxMarkScan ballots are different than the in that they actually contain voter selections in addition to the ballot metadata. For full specifications on how metadata and selections are encoded, refer to the .

The VotingWorks voting system (a.k.a. VxSuite) consists of four primary components:

• VxAdmin: election setup and election results manager

• VxMarkScan: ballot-marking device (BMD)

Polls Opened and Closed Reports

When polls open or close on VxScan, a tally report is printed. The tally report contains the tally results (pre-adjudication) of all ballots scanned at the scanner.

The tally report header contains the following information:

Basic Structure

The basic structure of the tally reports printed from VxAdmin is similar to the printed from VxScan.

This page covers guidance for test labs that isn't relevant for election workers.

Power Cycling

While test labs are free to run machines for long periods of time and naturally need to for tests like the 104-hour continuous operations test, we generally recommend powering down machines every couple of days. Rebooting a machine triggers necessary log file compression and rotation to save disk space. While some log files are compressed and rotated automatically on a daily basis, others are not in order to maintain the highest possible fidelity and are only compressed and rotated on reboot.

On VxSuite machines, there are no passwords for election administrators to use – only smart cards as described previously. The smart cards all use 256-bit elliptic-curve digital signatures, which makes them cryptographically strong. In addition, the PINs that gate usage of those cards follow the NIST recommendations for authentication – 6 digits long, randomly generated (as opposed to chosen by the user who might use a birthdate), and never a weak PIN like 000000.

The election package contains all of the information that defines an election. VxAdmin is configured by inserting a USB drive and selecting an election package from the drive.

After VxAdmin is configured, the election package can then be digitally signed and exported onto a USB drive in order to configure VxScan, VxCentralScan, and VxMarkScan. The digital signature verifies that the election package is legitimate. The other devices require that the signature is present. As a result, an election package from outside the system cannot be used to directly configure VxScan, VxCentralScan, or VxMarkScan.

Election Package Contents

The election package is a zip archive (a .zip file). The zip archive contains 6 files:

• Election Definition (election.json)

• App Strings (appStrings.json)

• Audio IDs (audioIds.json)

Election Definition

The election definition file includes the information that defines the election and ballots, including but not limited to definitions for contests, ballot styles, precincts, parties, multi-lingual ballot translations, and ballot layouts. The system accepts two formats - the format or the . When using the Ballot Definition CDF, some features are not available.

The election definition file is required to be present in the election package.

App Strings

The app strings file contains all voter-facing strings in the user interface and their translations. For example, at the beginning of the voter flow in VxMarkScan there is a button labelled, by default, "Start Voting." If the voter has set VxMarkScan to another language, however, the button will display the translation for that language specified in the app strings file. Additionally, the default English text can be overridden by specifying a different English value in the app strings file.

In the case of specifying a Spanish translation and overriding the English translation for "Start Voting", which has an internal key of buttonStartVoting, the following values and overall structure would appear in the app strings file:

Notes:

• Voter-facing strings that appear on ballots (contest names, candidate names, the name of the jurisdiction, etc.) are not included in the app strings file because they are already included in the election definition.

• The language codes in the app strings file are the for supported VxSuite languages: English, Spanish, Simplified Chinese, and Traditional Chinese.

• The keys for the various user interface app strings (e.g. buttonStartVoting) are defined in VxSuite's .

The app strings file is optional. If not provided, default English strings will be used.

Audio IDs & Audio Clips

The audio IDs file is a JSON file structured identically to the app strings file except that instead of containing text values for each voter string, it contains audio IDs for each voter string. Each audio ID corresponds to an entry in the audio clips file.

Each row of the audio clips file contains one audio clip with relevant metadata. The audio itself appears as an MP3 file encoded in base 64. For example, a row representing an audio clip for the "Start Voting" button would appear as:

Together, the two files allow specifying audio playback for any text read to a voter in audio mode, including both non-English translations and English overrides.

The audio IDs and audio clips files are optional. If they are not provided, audio playback will be disabled.

System Settings

The system settings file contains settings which are not specific to an election definition but do impact machine behavior.

• Authentication Settings

  • arePollWorkerCardPinsEnabled - When set to true, poll worker cards are created with PINs which are then required when authenticating.

  • inactiveSessionTimeLimitMinutes

The system settings file is optional. If not provided, the following default settings will be used:

Metadata

The metadata file is a JSON file that contains a single key, version. In the current software version, the value will only ever be "latest". In other words, the metadata file is a JSON file with the contents:

In future software versions, the "version" value will be used to differentiate versions of the election package that correspond to different software versions. For example, if a user flow is updated, a new app string may be added and the "version" value will indicate which app strings to expect.

Ballot Hash and Election Package Hash

There are two hashes for each election which are both critical to operation and security of each election.

The ballot hash is the SHA256 hash of the election definition file and represents a snapshot of all election-specific data which determines the ballot, including contest definitions and ballot layout. Ballots must include a machine-readable version of the ballot hash (e.g. a QR code or a pattern of timing marks). When a ballot is scanned, the scanner checks to make sure the ballot has the expected ballot hash. The ballot hash from the ballot must match the ballot hash from the scanner's configured election definition.

If any election content changes, the ballot hash will change, meaning the system will consider it to be a new election definition, and any ballots with a different ballot hash will not scan. The system's strict checking of the ballot hash prevents situations where a change to the election definition leads to ballots being miscounted (for example, if the order of two candidates is swapped). As a result, any changes to the election definition require reprinting all ballots.

The election package hash is the SHA256 hash of the entire election package, which includes both the election definition and all other files. The election package hash is displayed on screen to election managers and system administrators. It allows the user to ascertain which election package was used to configure a machine. The election package hash is not used during ballot scanning.

For example, imagine that an election administrator wants to change the audio clip for candidate's name. The audio clip is not a part of the election definition but it is a part of the election package, so the ballot hash remains the same while the election package hash changes. The election administrator can reconfigure VxMarkScan with an updated election package but does not have to reprint ballots.

The election ID shown on screen and included in printed reports contains a shortened version of both the ballot hash and the election hash in the format: {ballot hash}-{election hash}. For example, with ballot hash 083e2e0afbb19191a4d2850562ddef050ff860b0d61acee15d3bb26954932941 and election hash db5c379b71accbf991e42ab23d26202f88b2539b6c69b814a0d3c8dc9f4072dc, the election ID would be: 083e2e0-db5c379. This enables identification of both the specific election package and election definition that a machine is configured with.

Ballot Rotation

Ballot rotation is specified by the defined candidate order in each ballot style as opposed to specifying a rule that the voting system should apply to a given list of candidates. The system supports tabulation of ballots with any type of candidate ordering. This enables flexibility for jurisdiction-specific ballot rotation rules that can be defined in the source system creating the ballot definition.

Election officials can verify their ballot rotation configuration by configuring VxMarkScan, selecting different precincts (and by extension ballot styles), and confirming that the order of candidates differs per precinct as expected.

VxSuite can tabulate a wide variety of ballot designs as long as they conform to the following requirements:

1. Ballot size must be one of the available system options

2. Ballot must include correctly formatted timing mark borders

3. Ballot must include an appropriately positioned metadata QR code

4. Ballot must use a specific bubble shape

5. Ballot must adhere to

Ballot Size

All supported ballot sizes are 8.5 inches in width, but vary in height as specified in .

These lengths correspond to the length specified in the within the election definition.

Timing Mark Borders

Every ballot must have timing mark borders on both front and back. The timing marks and page margins are strictly defined:

As for number of timing marks, there are always 34 in the top and bottom borders, which has a 32 x 39 grid of possible bubble positions inside the timing mark border. The number of marks in the left and right borders varies based on the length of the ballot, and should be calculated by the formula (# inches * 4) - 3. For example, a letter-sized ballot (11 inches) should have 41 left and right timing marks whereas a legal-sized ballot (14 inches) should have 53 left and right timing marks.

The timing marks must be aligned to the margins of the page and evenly spaced.

QR Code Metadata

The ballot must include a QR code which contains key metadata about the ballot.

QR Code Content

The QR code includes ballot metadata:

• Precinct Index - corresponds to a precinct in the election definition

• Ballot Style Index - corresponds to a ballot style in the election definition

• Page Number - page number within the ballot style

In addition, the QR code includes the ballot hash. The ballot hash ensures that the ballot was generated from the same election definition that will be used to interpret the ballot.

For full specifications on how to generate readable QR codes, refer to the .

Metadata QR Code Placement

The interpreter looks for the QR code in the bottom-left corner of the ballot. The detection area is a square whose sides are 1/4 of the ballot width.

Bubble Format

In order to be interpreted correctly, bubbles must meet the following dimensions:

Grid Coordinates

The timing mark borders define an abstract grid that VxSuite uses to assign coordinates to positions on the ballot. In the election definition, bubble positions and other ballot regions are specified using these grid coordinates. The ballot grid is an XY grid with the origin in the top-left corner. For example, the coordinate (5, 3) would correspond to the following position on the ballot:

Notes:

• Coordinates correspond to the center of each timing mark

• Coordinates specify the center of each bubble

• Fractional coordinates are allowed

Complete Example

Below is a complete ballot that, when paired with the appropriate election definition, could be interpreted within VxSuite:

When a VxSuite machine exports data to a USB for another VxSuite machine to import, the first machine digitally signs that data so that the second machine can verify its authenticity. We use this mechanism in two places in particular:

1. To authenticate election definitions/packages — These configuration bundles are exported by VxAdmin and used to configure VxCentralScan, VxMarkScan, and VxScan.

2. To authenticate cast vote records — These are exported by VxCentralScan and VxScan and imported by VxAdmin for tabulation.

The exporting machine digitally signs the following message using its TPM private key:

Software installation involves two steps:

1. Generating software images via Trusted Build:

2. Imaging machines with those images:

Disabling Network Access

By default, newly created VMs have networking enabled. To ensure the offline VM does not have access to the internet, the networking link is disabled before the VM is ever used. This is accomplished by editing the VM's configuration (found in /etc/libvirt/qemu/offline.xml) and setting the link state to down. This functionality can be seen in the vxsuite-build-system repo, in .

If an offline VM exists, the XML configuration file is updated to set the link state to down. After that, the offline VM is explicitly re-defined from this updated XML configuration file. These steps always execute, even if the network link state is already set to down.

Supported Voting Variations

• N-of-M contests

• Yes/No contests

• Partisan Primary Elections

  • The voting system itself does not have a concept of an open vs. closed primary as primary ballot styles are restricted to one party, but can support both types of primaries through procedurally restricting a voter to a given ballot style.

Supported Languages

• English

• Spanish

• Chinese (Simplified & Traditional)

Voter-facing content in an election package can be translated to additional left-to-right languages and imported into VxSuite, but is not formally supported or tested by VotingWorks.

The processing capabilities of the system are enumerated in the System Overview.

Specifically, capabilities that may be bypassed or enabled by the user are configured in the system settings file within the Election Package.

This section walks through the steps to install a Trusted Build image on a VotingWorks component using vx-iso.

Note: If you are installing a VotingWorks application for use in an election, you are required to create a software installation record. The details of this software installation record can be found here: Software Installation Record Creation

Marks are determined valid and counted by the system if the amount of darker pixels in the bubble area exceeds a configurable "definite" mark threshold set in the Election Package system settings file. This mark threshold can be adjusted to have a stricter or looser interpretation of what is considered a valid mark. On both VxScan and VxCentralScan, the voting system does not process any marks as ambiguous. All marks are either valid or invalid.

The recommended and default threshold is 7%. With this threshold setting, hand marked paper ballot interpretation detects a valid mark per the mark conditions described by VVSG 1.1.6-H.

At this default threshold, marks such as a light dot, a fold through a bubble, a stray mark outside of the bubble, or a small line just on the corner of a bubble will be considered invalid. Marks such as a completely filled bubble, half filled bubble, or an X in a bubble will be considered valid.

Examples of invalid and valid marks along with the score for that mark (in green) are shown below.

The mark threshold set on a scanner can be checked by an election official at any point by viewing the readiness report for that device as described in Diagnostics (see also & in the user manual).

Invalid Marks

Valid Marks

Marginal Marks

The system also supports setting a marginal mark threshold for flagging ambiguous marks close to but not quite over the definite mark threshold. If a marginal mark threshold is set and marginal mark adjudication is enabled, the definite mark threshold can be increased without having to worry about completely missing marks.

If this is the first time that a VotingWorks application has been installed to a machine, the machine will boot into a basic configuration wizard. If the machine has been previously configured with a certified VotingWorks application of the same type, this wizard will be skipped.

The majority of the steps are self-explanatory, but "Step 1: Set Machine ID" and "Step 4: Create Machine Cert" require some extra clarification.

Setting Machine ID

It is important that the machine ID be unique for each machine. Many machines have a physical placard on them indicating the machine ID. That is the ID that should be used here.

Creating Machine Cert

On VxAdmin, you'll first see a prompt to enter a jurisdiction:

Then, on all machines, you'll see this prompt:

Insert a USB drive that you designate for this purpose. From here on out, we'll refer to this USB drive as the VxCertifier USB drive.

After selecting the VxCertifier USB drive, a certificate signing request will be written to it. You'll then be prompted to:

Because you'll be certifying your machine at your own facility as opposed to a VotingWorks facility, you won't be able to take the USB drive to VxCertifier, our VotingWorks certification terminal. We'll need to use a remote certification process instead.

You'll need to remove the VxCertifier USB drive, find the "csr-<machine-id>.pem" file inside the "certs/" directory on it, and share that file with VotingWorks. This file does not contain any private information so can be shared over the internet, e.g., via email. VotingWorks will prepare a certificate given this "csr-<machine-id>.pem" file and send the certificate back to you, in the form of a "cert-<machine-id>.pem" file. This file, too, does not contain any private information so can be shared over the internet. You'll need to copy this "cert-<machine-id>.pem" file back onto the VxCertifier USB drive, placing it in the same "certs/" directory that we pulled the "csr.pem" from. Re-inserting the USB drive into the machine and pressing enter should allow you to proceed successfully.

On VxAdmin, you'll be prompted to program your first system administrator card as a last step. Remember to record the displayed PIN. On other machines, no steps remain. You'll reboot into the app after this.

The following defines the minimal specifications for VxSuite paper stock. Ballot layout requirements are enumerated in Hand Marked Ballots and Machine Marked Ballots in the System Overview.

Hand Marked Ballots

VxSuite supports a wide range of paper for hand-marked paper ballot style printing within the following supported specifications:

• Width: 8.5"

• Length: 11", 14", 17", 19", 22"

• Weight: 105-177gsm

• Coating: uncoated

• Opacity: >90%

• Color: white or any pastel color ≥70 brightness. Contrast ratio of printed black text is 21:1 for white paper and will exceed 10:1 on other paper colors of specified brightness.

• Watermarking: none

• Ink: typical oil-based or soy-based inks are appropriate for printing presses; typical laser toner or inkjet ink are appropriate for smaller printers & copiers.

• Folding: ballots should not be folded through bubbles.

• Bleed-through: bleed through should not be present when using recommend paper weight (105-177 gsm) and marking method (ball point pen).

• Margins: the paper margins listed below are required for proper timing mark interpretation and adequate space for VxCentralScan imprinting outside of the ballot selection area and timing marks:

  • Left/right: 5mm (0.19685 in)

  • Top/bottom: 12pt (0.16667 in)

• Scale: 100% — all VotingWorks ballot PDFs must be printed at 100% scale. Any print scale deviation will render the ballot imprecisely.

• Print Run Size: defer to your print vendor's established best practices for quality assurance. In the absence of a vendor recommendation, we recommend that print runs are a consistent size between 500 to 1,000 sheets — consistency eases ballot accounting and the moderate size allows for semi-frequent quality checks.

Ballot Marking Device Ballots

VxMarkScan requires a specific type of thermal paper ballot stock as required by the VSAP BMD 150 component:

• Manufacturer: Mitsubishi

• Model: Thermoscript TF 1467

• Width: 8"

TF 1467 paper is only provided in one configuration on white paper with a weight of 140gsm, an opacity greater than 90%, and thermal coating on one side. VxMarkScan expects the thermal side to be fully blank and therefore pre-printing attributes such as watermarking, ink, and margins are not applicable. Similarly, these ballots are only to be used with ballot marking devices and attributes specific to hand-marking such as folding and bleed-through are also not applicable. Printed text contrast ratio of blank ink on white paper is 21:1.

Build Machine Requirements

• Operating system: Debian 12

• RAM: 8GB minimum

• Chip: x86-64 / amd64 CPU architecture, Intel i5 or higher

• Storage: 250GB minimum

Build Machine Configuration

Debian 12 will need to be installed on the build machine. You can find detailed instructions for that process under . Once that is complete, we can install the VotingWorks build system, .

Throughout the rest of this document, substitute <inventory-name> with the inventory provided by VotingWorks.

At this point, you should have two separate VMs: debian-<inventory-name>-<apt-snapshot-date>-<debian-release-name>and online. You can confirm this by running:

First make sure that you've prepared USB drives for imaging, following the instructions under Preparing USB Drives for Imaging. Then follow these steps:

1. Power off the machine.

2. Insert the vx-iso USB drive into the system. If this is a VxMarkScan or a VxScan, connect a keyboard as well. If there aren't enough ports available, use a USB hub as provided by VotingWorks.

3. Power on the machine to begin booting vx-iso.

   1. By default, VotingWorks systems should boot from the USB. If not, you will need to select the USB drive from a BIOS or Boot Menu. For central system components, you can access the Boot Menu by pressing F9 during the boot sequence. For other components, please reach out to VotingWorks for assistance.

4. Select "Install Image". You can navigate vx-iso with the keyboard. This option will be auto-selected after 30 seconds.

5. If the machine already has Secure Boot keys installed, it should not prompt you to install keys. If it does for some reason, you should reach out to VotingWorks for assistance. Only if you know the keys need to be installed should you opt to install them.

6. The application image(s) on the vx-iso USB drive will be displayed. Select the number that identifies the correct image. In the event there is only one image, it will be automatically selected.

7. The imaging process will begin automatically after 10 seconds.

8. Once imaging completes, remove the USB drive as prompted. The system will then automatically reboot.

9. After rebooting, the system will perform an automatic encryption of the var filesystem. If Secure Boot was not enabled when the image was installed, you'll see a note about needing to enable Secure Boot. The machine will auto-boot you into the BIOS. Once Secure Boot has been enabled and the system reboots, the encryption process should complete successfully.

10. The /var partition should encrypt and expand, followed by a reboot. If this is the first time that a VotingWorks application has been installed to a machine, you should find yourself in the . Proceed to that section. If the machine has been previously configured with a certified VotingWorks application of the same type, the will be skipped.

Note: VotingWorks system software will be installed to the directory path: /vx/code/vxsuite

The underlying storage for /vx/code/vxsuite will depend on the hardware type. By default, NVMe storage is used. In the event an NVMe storage device is not available, an eMMC storage device will be used.

The write-in adjudication report includes the results of all write-in adjudication organized by contest:

The values in the contest table above are as follows:

VxSuite has four authenticated user roles. Authentication is performed with JCOP4 Java Cards, a security-oriented type of smart card. Each card is programmed with a single role and, in most cases, a PIN for two-factor authentication. Details of the authentication system can be found here: .

Poll Worker Role

The poll worker role is the lowest privilege role for election day tasks at the precinct.

The poll worker role allows a user to manage the polls on the precinct equipment, VxScan and VxMarkScan. On both devices, the poll worker card is used to open and close polls on election day. On VxMarkScan, the poll worker card is used to enable voter sessions. There are a few other actions enabled by the poll worker card - reprinting reports, powering down the machine, or checking the software hash - but overall the role is quite limited.

The VxSuite TDP is open-source and publicly available. The public documents required by VVSG are listed below:

• Election Event Log Coding:

• CDF Implementation:

The maximum tabulation rate for batch-fed scanners is primarily limited by the hardware scanning speed limit for each central scanner model:

• Ricoh fi-8170: 80 sheets per minute

• Ricoh fi-7600: 100 sheets per minute

The sheet per minute rate is reduced by the need to interpret ballot images. Ballot interpretation speed varies based on the following ballot variables:

1. Open virt-manager:

1. Double-click the online VM.

2. Press the start button ▶️.

Cryptographic Modules

VxSuite v4 contains four distinct cryptographic modules:

• Smart cards

When installing VotingWorks applications that will be used in one or more elections, it is necessary to create a record of the software installation. There are multiple requirements, as described below.

3.1.4-I.1 a unique identifier (such as a serial number) for the record; 3.1.4-I.2 a list of unique identifiers of storage media associated with the record; 3.1.4-I.3 the time, date, and location of the software installation; 3.1.4-I.4 names, affiliations, and signatures of all people present; 3.1.4-I.5 copies of the procedures used to install the software on the programmed devices of the voting system; 3.1.4-I.6 the certification number of the voting system; 3.1.4-I.7 list of the software installed as well as associated digital signatures and mechanisms for installation and verification on programmed devices of the voting system; and 3.1.4-I.8 a unique identifier (such as a serial number) of the vote-capture device or election management system (EMS) which the software is installed.

To satisfy the above requirements, VotingWorks recommends following these best practices related to each requirement.

3.1.4-I.1 - We recommend using the machine ID for this record, e.g. SC-11-004 If necessary, appending the install date and time can further ensure uniqueness, e.g. SC-11-004-20250325-1300

We'll now clone the offline VM to prepare images for specific machine types, i.e., VxAdmin, VxCentralScan, VxMarkScan, and VxScan. We'll create one clone/VM per machine type.

In the following steps, the vxadmin VM will be referenced, but these steps can be repeated for each machine type: vxcentralscan, vxmarkscan, and vxscan.

1. To clone the offline VM, run the following command on the build machine:

Signed Hash Validation

Once a machine has been imaged with a signed image, you can verify the system hash against the hash of what was built and signed during the Trusted Build process. To perform this verification, VotingWorks provides Signed Hash Validation.

See for details.

Note: On older releases (v4.0.1 and earlier), the Secure Boot signing process only output a SHA256 hash value. That hash value needs to be converted to a base64 encoded value to match what is provided by Signed Hash Validation. That can be accomplished with the following command:

1. To create the offline VM with networking disabled, run the following command on the build machine:

1. Open virt-manager if not already open:

1. Double click the offline

To install an image on a VotingWorks component, i.e., to image a machine, you need a vx-iso USB drive with one or more VotingWorks application images stored in the "Data" partition. There is also a "Keys" partition that can optionally contain VotingWorks Secure Boot public keys, necessary if a machine hasn't had these keys installed yet.

USB drives used as vx-iso drives must be zeroed out before first use. This step will also ensure the USB drive is empty and no longer contains any previous data prior to use as installation media. You can zero out a drive with the following command, substituting /dev/sdX with the appropriate path to the USB you are using, e.g. /dev/sda

Drives provided by VotingWorks are already initialized with this process and contain the appropriate vx-iso release for installing an application image. You will only need to ensure the appropriate application image(s) are copied to the vx-iso USB drive. If you are creating your own vx-iso USB drive, please contact VotingWorks for assistance.

The VotingWorks build process consists of three distinct build phases: , , and . The build process uses an inventory definition containing all the necessary information for a Trusted Build. All three phases are executed within a separate virtual machine (VM) managed by the tool, running on a Debian 12 operating system.

In the online phase, the build process utilizes a base Debian 12 VM with network access enabled. All necessary code repositories and build tools are securely retrieved for use during the offline phase.

In the offline phase, the build process utilizes a clone of the online VM with network access disabled.

In the final configuration phase, the build process utilizes clones of the offline VM to prepare images for specific machine types, i.e., VxAdmin, VxCentralScan, VxMarkScan, and VxScan.

After completing the final configuration phase, an unlocked installation image has been created. While this image is not appropriate for production use, it can be used for testing.

There is a tension between the requirement that (a) voter privacy should be strongly protected, and (b) cast vote records should be continuously exported in order to ensure that they can be immediately available in the case of hardware failure. For example, if each scanned ballot naively results in the creation of a new CVR file on the USB drive with a timestamp, the order of CVRs is obviously preserved on the USB drive, as the file creation and modification timestamps reveal the order in which those CVRs were stored.

To meet both requirements, VxScan performs some amount of "shuffling" every time a CVR is saved to the USB drive. Every time a ballot is cast and its CVR is saved to the disk, VxScan picks one or two CVRs already stored on the USB drive and updates their creation and modification time on the USB drive. This is the digital equivalent of taking one or two random ballots from a pile and bringing them to the top of the pile. Thus, if an attacker were to view the CVRs on the USB drive, they would not be able to determine the order in which those ballots were cast, because of this constant shuffling.

Recall from that a single CVR is structured, on disk, as a directory that contains the JSON data of the CVR and the ballot images for that CVR. The VxScan operation performed to move a single CVR "up to the top of the pile" involves four steps:

All VxSuite components are blocked from connecting to any network. Thus, there is no networking in a VxSuite implementation. Our network design is secure by virtue of it being completely absent.

Networking is disabled through several layers of defense:

• Network drivers and known network connections are purged in the software setup process. See script.

• Secure boot ensures that the hard drive is not modified, thus preventing software that isn’t part of the approved VotingWorks bundle from running.

The following article and linked related articles are intended to cover VVSG 2.0 3.1.2-A.4.

Safety

Per VVSG 2.0 8.1-K - Eliminating Hazards, devices associated with the voting system are certified in accordance with the requirements of UL 62368-1. See . VxSuite hardware is designed to eliminate hazards from shock, radiation, heat, and mechanical dangers when used and maintained in accordance with the .

Beyond the application-level protections and system integrity assurances built to ensure that unauthorized access is thwarted and unauthorized software cannot be executed, VxSuite is also designed with defense-in-depth and least-privilege principles. This ensures that a failure of some defenses, due to unforeseen bugs or novel attacks, can be limited in its impact.

Minimal Operating System

VxSuite runs a modern, stripped down Linux installation with the minimum number of packages to reduce the attack surface of any unexpected partial penetration. The set of packages is manually curated by our team and specified in our installation manifests when building a base Linux image.

User Centered Design

User centered design (UCD) is a design philosophy and process that prioritizes the needs, preferences, and behaviors of end users throughout the design and development process.

VotingWorks implemented user centered design in the following ways:

To finalize an image for production use, it's necessary to sign the image with the VotingWorks Secure Boot keys so that the image can be used on a Secure-Boot-enabled machine. This process requires the use of sensitive keys and a passphrase that should only ever be known to and used by VotingWorks. Since the Trusted Build process is performed by a third-party vendor (SLI), a process to securely sign the image without compromising the keys or passphrase is needed. This document describes that process.

Transferring an Unsigned Image from SLI to VotingWorks

Once SLI has created a Trusted Build image, the image and its VM definition (an XML file) must be securely provided to VotingWorks. To transfer the image and definition, SLI will upload to a shared S3 bucket only accessible to SLI and VotingWorks. This access is controlled via IAM permission policies.

The election definition within the election package can be a JSON Ballot Definition CDF Version 1.0 file. The full specification is defined by NIST and can be accessed on their website.

VxSuite CDF Implementation

VxSuite accepts the Ballot Definition CDF Version 1.0 as defined by NIST without any data extensions. VxSuite requirements differ from the NIST CDF schema only in the following respects:

• Some fields not required in the NIST CDF are required in VxSuite

• Some enumeration values are more restricted in VxSuite than in the NIST CDF

• Some classes and attributes are ignored in VxSuite

The exact VxSuite schema is defined as a which is derived from the . The differences between the two are documented in the below tables.

Required Class Attributes

Restricted Enums

Ignored Classes and Enums

Ignored Class Attributes

VxSuite CDF Conversion

When importing a Ballot Definition CDF file, attributes will be mapped to the and used across the system in the exact same way.

Attribute Mappings

Translations

Most attributes in the Ballot Definition CDF that could require translation are defined with the CDF InternationalizedText class which allows specifying variants for each language. InternationalizedText maps directly onto VxSuite's . When an InternationalizedText attribute is mapped to a ballot string, the English version is used as the default which will appear on reports and administrator interfaces while the translations are maintained in the election definition for multi-language experiences on voter devices.

Geographies

The Ballot Definition defines all geographies as GpUnits, whereas the VxSuite Election Definition defines various geographies.

Some geographies must exist in the Ballot Definition CDF file to be used in VxSuite. There must be one GpUnit of type state and one of type county to populate the relevant metadata on the .

Any GpUnit of type precinct is mapped to a .

Any GpUnit with an associated contest is mapped to a .

VxSuite CDF Limitations

Because VxSuite does not utilize any data extensions to the Ballot Definition CDF, some information cannot be included when using the Ballot Definition CDF. The missing information creates some limitations when using the Ballot Definition CDF when compared to the format:

• Contest term descriptions (e.g. “2 years”) will always show up in English because there is no field in the CDF for internationalized term descriptions

• The full party name will be displayed for each candidate on VxMarkScan (e.g. “Democratic Party” instead of “Democrat”) because the CDF only has one attribute for party name. In contrast, the VxSuite format supports two separate fields, one for the full name and one for showing on the ballot.

• When adjudicating write-ins, the highlighted contest option area will be set to a default because there is no field in the CDF for this parameter.

All VxSuite components have a diagnostics interface accessible to system administrators and election managers that allows a user to monitor or test key components. Diagnostic information is shown to the user and can be exported as a PDF readiness report.

When a test is performed, the system logs the result and creates a diagnostic record which includes the outcome of the diagnostic, pass or fail. The outcome and date of the most recent diagnostic is displayed on the readiness report. One possible use case of the readiness report is to run all diagnostics before an election and then produce a readiness report that confirms all tests passed.

Common Diagnostics

Storage

Retrieves the current amount of disk space used and disk space available for the application. The displayed total disk space will not be as large as the actual disk because some space is reserved for the system. The disk space usage will not always return to 0% after clearing election data because the database may not have liberated that disk space back to the operating system, but the space will be reused once more election data is loaded.

Battery

For components with internal batteries - VxAdmin and VxCentralScan - the operating system is polled for battery status. The application will report the current charge level and whether or not the battery is currently charging.

Uninterruptible Power Supply (UPS)

For components that operate with an external UPS - VxMarkScan, VxScan, and VxCentralScan - there is a test flow for the user to confirm that the UPS is connected and fully charged.

Configuration

Election Identifier

If there is an election configured on the machine, it will display the election title and hash.

Ballot Styles

For precinct equipment, the list of ballot styles will include only those appropriate for the current precinct configuration. For central equipment, the list of ballot styles will be all ballot styles in the election. The languages for each ballot style are also enumerated.

Precinct

For precinct equipment - VxScan and VxMarkScan - the currently configured precinct will be shown, if any.

Mark Thresholds

For scanners - VxScan and VxCentralScan - the currently configured mark and write-in area thresholds will be shown. The thresholds reflect what was set in the system settings.

VxAdmin Diagnostics

Printer

The toner level and any alerts from the printer are displayed, such as sleep mode, paper jams, or hardware malfunctions. The user may perform a test print, which will send a mock report to the printer. The user inspects the printed document and confirms whether the test print was successful or failed.

VxCentralScan Diagnostics

Batch Scanner

The user may perform a test scan, which requires that a blank white sheet of paper be scanned. The scanned image is broken up into small cells and each cell is checked for the percent of black pixels after binarization. If that percent is more than slightly over 0%, that cell is flagged and the entire diagnostic fails. The goal of the diagnostic is catch any defects in the scanned images, such as streaking produced by a dirty scanner.

VxScan Diagnostics

Embedded Scanner

The user may perform a test scan, which requires that a blank white sheet of paper be scanned. The scanned image is broken up into small cells and each cell is checked for the percent of black pixels after binarization. If that percent is more than slightly over 0%, that cell is flagged and the entire diagnostic fails. The goal of the diagnostic is catch any defects in the scanned images, such as streaking produced by a dirty scanner.

The test scan process is identical to that for VxCentralScan, and the images above apply.

Thermal Printer

The user may test the printer by printing a test page. After the print, the user must indicate whether the page printed successfully or not. The diagnostic available in the diagnostics interface is identical to that which election managers are encouraged to run after loading paper, and the outcome is recorded in either case.

The diagnostics page will also display details about any printer errors if the printer is in an error state.

Speaker

The user may test the speaker by triggering the chime sound and confirming whether they heard the chime or not.

VxMarkScan Diagnostics

Printer-Scanner

The user may perform a test of the printer-scanner which mocks the ballot flow during a voting session:

1. User loads thermal paper

2. Mock ballot is printed onto paper

3. Mock ballot is scanned and presented in the front input tray

4. Mock ballot is ejected into the ballot box

A successful test indicates that the printer and scanner can properly produce and handle ballots during a voting session.

Accessible Controller

The user may perform a test of the accessible controller which validates that each button on the controller is producing the expected signal. The flow guides the user through pressing each button.

PAT Input

The user may perform a test of the PAT input, which is simply confirms that a PAT device can be successfully calibrated as it would be during a voting session.

Front Headphone Input

The user may perform a test of the front headphone input by connecting headphones and triggering a chime. The user must indicate whether they heard the chime or not, corresponding to a pass or fail respectively.

Ballot-Comparison Risk-Limiting Audit

In a ballot-comparison risk-limiting audit, the goal is to compare, for a random sample of the cast ballots, the paper ballot and the corresponding cast-vote record. The specifics of sample selection and risk-limit calculation are out of scope for this document – VotingWorks Arlo or other RLA tool may be used for this purpose.

To enable a ballot-comparison risk-limiting audit, VxSuite provides:

• imprinting of ballots on VxCentralScan, with a unique identifier of the form <BATCH-ID>_<SEQUENCE-NUM>

• cast-vote records including the field BallotAuditId which matches the imprinted identifier

Then, to run a ballot-comparison risk-limiting audit with VxSuite:

1. scan all ballots with VxCentralScan and the imprinter module on the Ricoh scanner. See .

2. store ballots by batch, recording the batch ID displayed on VxCentralScan display. Storing ballots in the order they were scanned is helpful for later retrieval, but not strictly necessary since the sequence numbers printed on the ballots can be used to recover the proper order.

3. export CVRs from all the VxCentralScan's

Alternatively, unique identifiers may be added by VxScan — see for the associated audit procedure.

Batch-Comparison Risk-Limiting Audit

In a batch-comparison risk-limiting audit, the goal is to compare, for a random sample of ballot batches, the hand tally of that batch with the corresponding batch tally. The specifics of sample selection and risk-limit calculation are out of scope for this document – VotingWorks Arlo or other RLA tool may be used for this purpose.

To enable a batch-comparison risk-limiting audit, VxSuite provides:

• Tallies partitioned by scanner and/or by batch in VxAdmin

• Ballot counts by scanner and by batch in VxAdmin

Then, to run a batch-comparison risk-limiting audit with VxSuite:

1. scan ballots either with VxScan or VxCentralScan. No need to use imprinting for VxCentralScan.

2. store ballots by batch – where a batch in VxCentralScan is indicated by the batch ID on screen, and a batch in VxScan is the entire set of ballots scanned by a single VxScan over the course of the election. Order of the ballots need not be maintained in either case.

3. export CVRs from all VxCentralScans and gather the CVRs on USB drives from all VxScans

Image Audits

In an image audit, various risk-limiting audit procedures are used, but instead of physically retrieving the ballots to audit, the scanned image of the ballot is used.

VxSuite supports image audits very simply – every VxScan and VxCentralScan produces images of the scanned ballots that can be immediately associated with the interpreted CVR. Thus, the protocols defined above for ballot-comparison and batch-comparison audits can be used, with the following simplification:

• imprinting is unnecessary

• instead of "retrieving a ballot", simply look up the image files corresponding to the CVR ID and interpret on screen

The foundation of our system integrity solution is the TPM (described in greater detail under Cryptography).

Our design for system integrity maps closely to that of ChromeOS:

1. The hard drive is partitioned such that executable code lives on the read-only partition /, and only /var and /home are mounted read/write for configuration, logs, and working data like scanned ballot images.

2. The read-only partition is verified by , which generates a hash tree of all the raw partition blocks, culminating in a single hash root for the entire read-only filesystem.

3. The kernel boot command line includes the dm-verity hash root as an argument, ensuring that Linux halts if the read-only partitions are not successfully verified against this hash root.

4. The BIOS is configured to only boot a properly signed bootloader+kernel+command-line, with public keys managed by VotingWorks and configured in the BIOS as secure boot keys. The bootloader+kernel+command-line that we want is set up as the default boot option in UEFI.

5. The private key described previously in is generated in the TPM and bound to Platform Configuration Registers (PCRs) that include the BIOS, the Secure Boot public keys, and the bootloader+kernel+command-line. Thus, this private key is only usable if the machine boots appropriately sanctioned source code with a hard drive whose read-only partitions are unmodified.

As a diagram:

The integrity of the overall system is ensured because:

• Any change in the executable portion of the hard drive will be detected when dm-verity checks the hard drive blocks against its stored hashes.

• Any change in the hashes stored on disk will be detected against the mismatched root hash, present in the kernel boot command line.

• Any live changes to the read-only portion of the drive, even while the machine is already booted up, will be detected the moment Linux tries to read those modified blocks, as all disk reads are live-checked against the hashes.

Thus, if the system boots, it means that the hard drive corresponds, by hashing, to the expected value that we baked into the bootloader+kernel+command-line and signed. If the system does not boot due to a failed cryptographic boot validation, it may be indicative of malware, so the user should make note of the error message and contact VotingWorks.

The only time that the system hash is expected to change is after a software update, which involves completely reimaging the machine per the process laid out in .

Hard Drive Partitioning

Our system is configured so that /var, /tmp, and /home are mounted read-write, and / for everything else is mounted read-only. This requires writing logs and other runtime-generated VotingWorks data, e.g., scanned ballot images, to /var. Variable system configuration, e.g. timezone information, also needs to be redirected to /var. A USB mount point is pre-created at /media/vx/usb-drive.

Protecting Critical Read-Write Data

In addition to locking down the / partition, the /var partition is encrypted and authenticated using dm-crypt. This ensures that, even if an attacker removes the physical hard drive and connects it to a different CPU, they cannot read or modify the contents of the /var partition in an attempt to make the VxSuite component behave differently.

Furthermore, as an extra layer of defense, every individual VxSuite component instance uses a unique random encryption key for its /var partition. Thus, if an attacker were to break the encryption on one VxSuite machine, they would have gained no advantage in penetrating a second machine. This is ensured through rekeying of the /var partition encryption on first boot of a VxSuite component.

Signed Bootloader and Kernel

With Secure Boot, UEFI passes control to the bootloader only if the bootloader is appropriately signed. Then, the bootloader passes control to the kernel. We choose to bundle the bootloader, kernel, and command line that is used to run the kernel all as one, and to present that to the UEFI as the single executable whose signature should be verified before running. The three are combined into a single object file, along with the dm-verity root hash. This single object file is signed by VotingWorks secure boot private keys.

Secure Boot

Every VotingWorks machine’s BIOS is configured with VotingWorks secure boot public keys, and the BIOS is configured to require Secure Boot. Thus, only a properly signed object file can serve as bootloader.

Mounting USB Drives

When mounting USB drives, VxSuite always mounts them using standard Linux mount configuration options that makes files on the USB drive NOT executable. This further protects from any unauthorized software running, even in a transient fashion.

Ballot count reports contain ballot and ballot sheet counts, not contest results.

If there are multi-sheet ballots in the election, the sheet counts (e.g. "Sheet 1", "Sheet 2") can be added to the report in the ballot count report builder by selecting "Sheet" as a Report By dimension. The total ballot count is always defined as the first sheet count.

If there are manual results, the manual ballot count will always be displayed separately from the scanned ballot count, and the total of the two will also be displayed.

When grouping is applied in a ballot count report, each group corresponds to a row in the table. In the following example, the ballot counts are grouped by both precinct and voting method:

The following metadata columns may appear in a ballot count report table in order to specify groupings:

Filters apply to the entire report. Simple filters are shown in the title, while complex filters are listed in a box below the title.

VxScan supports generating a unique audit identifier for each cast paper ballot. During a post-election audit, auditors can use these audit IDs to match a ballot to its corresponding cast vote record.

Overall Process

1. A serial number is added to each hand-marked paper ballot. This serial number is encoded in the ballot's metadata QR code.

2. VxScan generates a random secret key when configured with an election package.

3. When a ballot is cast, VxScan generates a unique audit ID for the ballot by randomizing the ballot's serial number using AES-256. It adds the randomized audit ID to the CVR.

4. After polls are closed, an election manager saves the secret key from VxScan.

5. During a post-election audit, an election official with access to the VxScan secret key derandomizes the audit IDs in the CVRs using any tool that implements VotingWorks's publicly specified derandomization logic, as documented in . For convenience, VotingWorks has deployed a proof-of-concept tool for this step in VxDesign.

6. Auditors compare the derandomized audit IDs to the serial numbers encoded in the ballot QR codes, pairing CVRs with their corresponding physical ballots for a ballot-comparison audit.

Ballot Serial Numbers

At the point of election definition and ballot design, the QR code on each paper ballot is encoded with an optional Ballot ID value as defined in .

If using VxDesign as the source ballot creation system, one can automatically generate unique ballot PDFs with sequential serial numbers encoded in each QR code. Before exporting an election package and ballots, check the box labeled "Generate audit IDs for ballots" and enter the number of audit IDs or serial numbers to generate.

Randomized Unique IDs

When configured with an election definition, VxScan generates a random secret key that it uses to randomize the ballot serial numbers as unique identifiers in the cast vote record. When ballots are cast and cast vote records are created, VxScan randomizes the ballot's serial number using AES-256 and adds this randomized unique ID to the BallotAuditID field in the CVR. See for the complete CVR file format.

Saving VxScan Secret Key

An election manager can save the VxScan secret key to a USB drive through the following steps:

1. Authenticate using an election manager smart card

2. Navigate to the CVRs and Logs screen in the election manager menu

3. Select Save Ballot Audit ID Secret Key

Derandomizing Audit IDs in CVRs

The unique IDs generated by VxScan can be derandomized using standard AES-256 decryption with the secret key and CVRs generated from the same VxScan. This procedure can be incorporated into any tool that implements VotingWorks's publicly specified derandomization logic, as documented in .

For convenience, VotingWorks has deployed a proof-of-concept tool for this step in VxDesign. Under the "Export" tab for any election is a "Decrypt CVR Ballot Audit IDs" section. Copy and paste the value of the secret key from the "ballot-audit-id-secret-key.txt" file on the USB drive that you saved the secret key to. Then locate the relevant CVR directory on your VxScan USB drive. From the root of the USB drive, navigate into <election-specific-folder>/cast-vote-records/. Pick out the relevant directory, e.g., machine_0000__2025-07-25_11-44-45, and zip it. In VxDesign, click "Select CVR Export Zip File" and upload the ZIP file that you just prepared. VxDesign will output a new ZIP file titled "decrypted-cvrs.zip" containing a copy of each CVR file with the derandomized ID, i.e., the ballot serial number, as the file name. For example, the CVR for ballot serial number 1 will be saved in the file 1.json.

Comparing Derandomized IDs to Physical Ballots

Auditors can use the the public to identify the original serial number encoded on a given paper ballot and map that to the CVR for that ballot based on file name. The ballot selections on the physical ballot can then be compared to the selections recorded in the CVR.

For convenience, VotingWorks has implemented a QR code scanning website meant to be accessed on a smartphone: . When pointed at a valid VotingWorks paper ballot QR code, the website will display the parsed contents of that QR code, including the ballot serial number. The website refers to the ballot serial number, if present, as the "Ballot ID" as you can see in the screenshot below.

This risk assessment reviews threats and vulnerabilities identified in:

• VxSuite hardware, including VxCentralScan, VxAdmin, vxMark, and VxScan. Also included are any items and peripherals needed to operate the equipment listed above (e.g., USB drives, scanners, printers).

• VxSuite software and source code

• VotingWorks internal communication and operation support systems.

This assessment was conducted following the framework outlined in NIST Special Publication 800-30 - Guide for Conducting Risk assessments.

For additional information on how physical, technical, and operational controls work together to meet the requirements of VVSG 14.1-C.1-4, please refer to , specifically:

Please also refer to the , notably the documentation.

[PDF]

[Excel]

The VotingWorks build system, vxsuite-build-system, utilizes many different tools to install, configure, and build VotingWorks applications. To ensure the integrity of the build system and tools used, all third-party tools are verified against known hashes, checksums, or digital signatures. This appendix provides a description of the mechanism used to verify each tool and any additional resources those tools may be responsible for providing during the build process.

In addition to verifying third-party tools against known hashes, checksums, and digital signatures during the build process, a report of COTS tools, with applicable hashes/checksums, is provided to the VSTL for independent verification and is available here. These tools are defined within the vxsuite-build-system for each release of VotingWorks applications, and only those tools are installed during builds.

APT

Debian's package manager, apt, is built on a secure framework described here: SecureApt.

The VotingWorks build process relies on this fundamental tool to install many of the system level tools required to build our applications. As an added measure of security, all packages are pinned to specific versions to ensure a consistent build environment over time.

To further ensure that consistent versions of dependencies and transitive dependencies are used, we create our own VotingWorks-hosted apt snapshot to pull from.

pip

Python's package manager, pip, does not verify package integrity by default. However, secure installation is possible via the method described here: .

The VotingWorks build process implements the above method in the script. The required packages are listed, along with their hash, in unique requirements files based on the operating system version and architecture. You can see an example here: .

RubyGems

Ruby's package manager, gem, does not verify package integrity by default. However, the official gem repository provides SHA256 checksums for hosted packages. You can see an example here: .

The VotingWorks build process requires the version and SHA256 checksum for any installed gems. Once the gem file has been downloaded, it is checked against this checksum to verify its integrity. You can see that checksum verification in the rubygems playbook here: .

Rust

By default, Rust is installed over an active internet connection. Since that method is not available during the offline phase of the VotingWorks build process, we use a standalone, offline installer binary provided by Rust. To verify the integrity of the installer, the downloaded file is verified against the officially published checksum that can be found in each version's official manifest. You can see that checksum verification in the rust playbook here: .

Cargo

Cargo is the Rust package manager. It provides secure installs via the combination of a manifest listing packages and their versions, along with a lock file containing the checksum for each package. That method is described here: .

Node

Node is typically installed via package managers like apt, or via a direct install from a specific version. We do not install Node via apt since we explicitly version it. As a result, we download the appropriate installer from the official Node repository. That downloaded file is then checked against the officially provided checksum. You can see that checksum verification in the node playbook here: .

npm

npm is the default Node package manager. It is installed as part of the Node install previously described.

Packages installed via npm are checked against the officially provided checksums for each package. You can see that checksum verification in the node playbook here: .

pnpm

pnpm is another package manager for the Node ecosystem. It is installed via npm as previously described to ensure its integrity.

Packages installed via pnpm use a lockfile: pnpm-lock.yaml. This lockfile includes the version and checksum to verify integrity when packages are installed during the build process. In addition, the VotingWorks build process explicitly requires the use of --frozen-lockfile to ensure that only the packages explicitly required are installed.

Yarn

Yarn is another package manager for the Node ecosystem. It is installed via npm as previously described to ensure its integrity.

Packages installed via yarn use a lockfile: yarn.lock. This lockfile includes the version and checksum to verify integrity when packages are installed during the build process. In addition, the VotingWorks build process explicitly requires the use of --frozen-lockfile to ensure that only the packages explicitly required are installed.

Signed Hash Validation provides end users with a way to verify that a VotingWorks machine is running authentic unmodified VotingWorks software.

The machine preps a payload consisting of the following, with 1//shv1// as a prefix and # as a separator:

• System hash

• Software version

• Election ID

• Current timestamp

The machine signs that payload with its TPM private key and then bundles the following together, with ; as a separator:

• Payload

• Payload signature

• Machine cert

This combination is displayed as a QR code. Putting this all together, the QR code contains:

This QR code can be scanned at . The site parses the QR code and performs the following verification:

• Verifies the machine cert using the root VotingWorks cert.

• Extracts the machine's public key from the machine cert.

• Uses that public key to verify the payload signature against the original payload. If this verification succeeds, we can be confident that the machine possesses the TPM private key that pairs with the public key in the machine cert.

After completing the above verification, displays a success indicator alongside the payload components and the machine ID as extracted from the machine cert. These attributes can be matched against what's displayed on the machine.

QR Code Specifications

Signed Hash Validation QR codes are with .

Code Links

Refer to the following code links for more details:

Election Definition Limits

Ballot interpretation begins with the front and back images of the ballot transmitted from the scanner. Once the images are available to the application, it starts by trying to interpreting the ballot as a .

The interpreter first crops the image received from the scanner and converts the grayscale image from the ballot into binary images using . Otsu's method computes a dynamic black and white threshold that allows the interpreter to filter out differences due to tinted paper or light streaking.

Before trying to make sense of the ballot, the interpreter checks the images for vertical streaks. Vertical streaks likely indicate some sort of smudge or debris in the scanner that could interfere with the ballot image. The interpreter looks for columns of black without gaps, excluding the edges of the ballot which may be black simply from the way the scanner creates images.

If a streak is detected, the interpreter exits and surfaces the error to the application which will alert the user.

VxCentralScan is the system's batch scanner which enable election managers to efficiently scan large batches of ballots.

Configuration

VxCentralScan is configured with a signed exported from VxAdmin. The election definition includes the ballot layouts necessary for interpreting ballots and the system settings which indicate what type of ballot issues (e.g. overvotes) require adjudication. After the election package is loaded by an authenticated election manager, no further configuration is required.

Electronic Display Screen Specifications

The voting system features three electronic display screens - on VxScan, on VxMarkScan, and an identical screen on the laptops for VxAdmin and VxCentralScan. All screens are in conformance with 8.1-A's requirements for electronic display screens.

• All screens include anti-glare technology to prevent distinct virtual images from appearing on the screen (8.1-A.1.a)

Both tally reports and ballot count reports can be exported in comma-separated values (CSV) format.

Tally Report CSV Structure

In the CSV tally report, the vote total for each candidate or contest option is listed in a single row. In addition, there are rows for overvote and undervote totals for a contest.

For example, here is an excerpt of a tally report including the results for one contest:

The "Precinct" and "Precinct ID" columns are that are included because this example export groups results by precinct. The other fields are standard fields:

If manual results were entered, two additional columns will be added - "Scanned Votes" and "Manual Votes." These columns denote which votes for each selection came from the scanners vs manual entry.

The results of write-in adjudication are always included in the CSV exports. All write-in candidates will appear with their adjudicated name and a UUID assigned by VxAdmin. Unadjudicated write-in candidates will appear as "Unadjudicated Write-In" with the ID "write-in". Unlike in the printed reports, write-in candidates are never consolidated.

Ballot Count Report CSV Structure

The ballot count report CSV is the same as the table presented in the . For example:

The "Precinct", "Precinct ID" and "Voting Method" columns are that are included because this example export groups results by precinct and voting method. The "Total" field is a standard field on all ballot count CSV exports, but other ballot or sheet count fields may appear depending on the election and loaded results:

Shared Metadata Structure

Any filters or groupings which apply to each row will be indicated in the row itself by metadata columns. For example, in the example export above, the "Precinct" column lists which precinct group each row represents.

If a row is filtered by a single attribute value (e.g. represents one precinct rather than multiple precincts) then the following basic metadata fields are used:

If a row is filtered by multiple attribute values, the following columns may be used:

In cases as above, where a row value includes comma-separated values, those values will be wrapped in quotation marks per typical CSV formatting in order to allow consumers to properly differentiate columns.

VxSuite can be operated securely using the following these procedures. Some of these procedures are intentionally redundant for defense-in-depth as it is always expected that some operational mistakes are made.

Using Proper Equipment

VxSuite should be used only with sanctioned equipment and peripherals. In particular, when connecting USB devices to any VxSuite component, use only USB devices of the type specified in this documentation, and only devices of known and reputable source.

In Between Elections

When there are no active elections happening, VxSuite equipment should be physically secured so it is difficult to access and so that any access is evident at a later date.

• VxAdmin laptop and peripherals should be kept in their case, with numbered seals through both case seal points, preventing the case from being opened without breaking one or both seals.

• VxCentralScan laptop and peripherals should be kept in their case, with numbered seals through both case seal points, preventing the case from being opened without breaking one or both seals.

• The small Fujitsu/Ricoh scanner that works with VxCentralScan should be kept in its supplied soft case, with a numbered seal through the appropriate zipper hole, preventing the case from being opened without breaking the seal.

You may consider occasionally resetting the PIN on the system administrator cards. This can be done using the VxAdmin laptop.

During L&A Testing

Both VxAdmin and VxScan are required for Logic & Accuracy testing. VxCentralScan is required if it is planned to be used for counting absentee ballots. VotingWorks's recommended practices take into account that this testing is often performed in view of the public.

• When retrieving all components from their locked storage location, ensure that the seal numbers match the logs.

• Keep clear and strong custody of all smart cards.

• Use the system admin card only long enough to un-configure VxAdmin, VxScan, and VxCentralScan from the last election, and to program VxAdmin for the new election. Then return the system admin card to its secure storage.

At the end of L&A testing, ensure that the VxScan is ready and secured for election day:

• the correct USB drive is inserted into one of the two USB slots.

• the system has been switched to official-ballot mode.

• the VxScan is powered down.

If using VxCentralScan, ensure that that:

• it is switched to live mode

• it is shut down and put away in its case

• the case is closed and sealed.

Store all L&A'ed equipment, with recorded seal numbers, in a secure location until election day.

During an Election

Ensure that seals on equipment are untouched and appropriately numbered since L&A.

Opening The Polls

After setting up VxScan on the ballot box and opening the polls, ensure that:

• the ballot box is locked and/or sealed

• the auxiliary ballot box is locked and/or sealed

• the VxScan is attached to the ballot box using the locking mechanism

All seal numbers should be recorded.

During Vote Casting