Election Whitepapers

The Most Recent White Papers or Reports on Voting and Election

On the issue of source code escrow and/or disclosure

(AVANTE International Technology, Inc. Rev B May 28, 2007)

Source code disclosure and escrow is becoming critical because of the pending Federal bills on Election Systems and for this discussion, the current New York State Election Code. The escrowing and supplying to election authorities of source code is one of the murkiest aspects of ensuring integrity of our nation’s voting systems. One of the key reasons is the use and for most part the need to use “third party software” that are commercial-off-the-shelf (COTS).

While AVANTE does not think it has much ingenious ideas to offer beyond what has been superbly discoursed in several Internet blogs[1] and websites[2], we offer our comments from the perspective of a manufacturer of voting systems.

AVANTE generally agrees with the approach taken in the EAC 2005 VVSG in terms of reviewing and escrowing of source codes. The following are some of the key aspects:

• All source codes developed by the voting system manufacturer must be submitted for source code review and certification.
• Final certified source codes are compiled to produce the “witness build” that serves as the “gold” standard.
• All source codes and execution codes that are certified are escrowed in NIST (almost all vendors comply with this voluntary requirement).
• All source codes and execution codes incorporate “hash” code to ensure authenticity that can be independently verified.
• Most States required additional escrowing of the source codes and execution codes for the specific voting systems that may or may not have variations that are certified by State certification only.
• An EAC specific exempt review certifying commercial-off-the-shelf (COTS) third party source codes such as in operating systems, databases and firmware embedded in ancillary devices.
• Most States require the submission of at least a set of certified hardware and software used in their states.

The current New York State Election Codes of escrowing can be and is now interpreted to include all:

• Vendor developed software modules.
• Third party operating systems.
• Third party software functional modules.
• All drivers for components such as printers, touch-screens, etc.

All firmware (software inside hardware components) may include:

• Bios
• Microprocessor codes
• Graphic chips
• Compilers, etc.

In an effort to assist the understanding of the issue of source code, the following are the basic descriptions of source codes and execution codes that are compiled by yet another third party compiler software:

Source Codes (High level programming language):

• Human Readable representation of the instructions that the computer is to use for operations. They are the recipes for all operations.
• FEC 2002 VSS and EAC 2005 VVSG all require detailed explanation of source codes (within the source codes) written by all voting system vendors.
• Standard computers are loaded with different software execution codes so that identified components can perform their respective functions (microprocessor, memory, graphic display, etc.) as well as other functions. All of these sub-components involve either firmware (machine-based software) and/or execution codes of different functional modules.
• Voting systems use third party operating systems to develop functions and provide some complicated functions such as those required for many accessibility features such as foreign languages, speech engines, etc.
• Most election systems use some established software modules, or packages for special functions such as: databases, drivers for printers and/or touch-screen display, etc.
• Most vendors have historically developed simple voting systems such as commonly found in 1970-2000, such as the the touch-button direct electronic recording using a simple processor such as Z80, etc. and will develop all the required functions and interfaces and thus have available to themselves all software source codes and execution codes.
• More functional voting system providing accessibility features use Microsoft based operating systems because of the abundant supply of other functional modules and software from third parties, including Microsoft themselves.

Compilers (Converting high level language to machine level language):

• Compiler is a software package that converts the human-readable source code into machine-readable execution code.
• Most compilers are historic and are pieced together. Full availability may be unlikely.
• Some compilers are developed by developers such as Microsoft. Z80 may have a compiler developed by the chipmaker, etc.
• Having source codes without compiler source codes is almost as good as only having execution codes.

Execution Codes (Machine level or assembler programming language):

• Computer instructions (machine language) that have been converted (compiled) from the source codes.
• Vendors develop source codes and all of the execution codes of the operating system, database, speech-engines, drivers, etc.  All codes are “bound” (hashed) with SHA1 and escrowed.
• Execution codes escrowed can be typically in Federal, State, and County and accessed with proper authorities.
• Expert programmers can also make addition and modification to execution codes directly without using a compiler or language converter and thus source codes.

Note:

• Having execution codes that are hashed and verified to be same as those loaded into voting machines verifies that no “tampering” is performed on the system. This is a key process in auditing (along with system event audit log) any voting system. This is the key to ensure system security.
• Having source codes developed by vendors helps software experts that are familiar with that programming language to find and resolve any errors (unintentional or intentional) that may be made by programmers of such systems. Having source codes does not contribute directly to system security.
• Having third party source codes may help to “understand” (not easily) the potential errors due to communication gaps or mistakes between different functional modules. They do not contribute to the security of the system directly.
• Modifications to the vendor source codes are recompiled for testing.  Such is the normal diagnostic means to eliminate and confirm source errors.
• No one, even those that use a Z-80 processor can provide all source codes.
• No one can yet provide the compiler source codes.
• Requiring the escrowing of all source codes as defined is unreasonable in the search to ensure voting system security.

AVANTE believes the current approach used by EAC with the assistance of NIST is wise and practical.  The following are more specific aspects of EAC actions:

• Require that COTS software and firmware to be defined as those that have established other commercial applications.
• Require that no modifications on such firmware and software can be made to meet the specific needs of the voting systems incorporating them.
• If any modifications of such firmware and software is done to meet the voting system applications, such firmware and software should be certified and source codes be placed into escrow in NIST and other State agencies that require escrowing of source codes.
• Incorporate election codes (Federal or State or EAC requirements) so all source codes in the escrow can be reviewed by court appointed experts. Expert opinions can be rendered for any aspect of the source codes without disclosing the actual codes.

AVANTE agrees with ACCURATE in their position on disclosure[3] of the source codes developed by the voting system manufacturers. Our rational has been stated earlier[4] and additional clarifications are outlined below:

• Because voting systems are managed independently by more than 100,000 independent jurisdictions each with different State election codes with different degrees of security protections, it is unwise to have source codes totally open to the public.
• Very loose penalties are ever imposed for the offenders that change the source codes for elections. The legal precedent provides very little deterrent to those that are willing to commit such offense with the assistance of available public source codes.
• AVANTE agrees that source codes should be available for qualified independent reviews.
• Currently, experts appointed by the State (in some but not all States) can review and examine the source codes used in the voting systems.

AVANTE appreciates communities’ desire for voting integrity and to have a more transparent voting process. The process may be open up for qualified public review and examination.  Qualifications of such public experts might include the following:

• Such experts must be US citizens that are endorsed by publicly registered citizen groups (e.g. 501C, etc.), University, and other public institutions as stipulated by a court of proper jurisdiction.
• Such examination must be done in environments that are controlled by the Court as to prevent any form of copying.
• All such experts must sign an agreement of non-disclosure of the actual source code but be allowed to make comments to the manufacturers but not to the public unless sanctioned and allowed by the Court of proper jurisdictions.
• All such experts having the desire to provide such source code review services on behalf of the public must sign an agreement that they will be barred from working on or consulting for any voting systems manufacturers including that of not-for-profit institutions.

AVANTE believes there is an implicit public responsibility of all voting system manufacturers in such public endeavors as elections so to preserve the nation’s democracy. Such implicit public responsibility should include proper and adequate transparency. However, the public’s right to know must not damage the business interests of the entities that provide such commercial systems and services. We hope the above ideas may be modified to satisfy public and commercial interests.

[1] Bradblog.com, Avi-rubin.blogspot.com, Votertrustusa.org

[2] Bbvforums

[3] Accurate-voting.org

[4] Vote-trakker.com

Providing accessibility of  the “voter verified paper ballot” to visually impaired voters

(Rev B May 17, 2007)

Most people object to the reading back of the VVPB using the original voting system as placing too much trust on the manufacturers of the voting systems. Some indivuals even oppose it when such portions of the source codes are made public as required by some State election codes.

Objecters note that such reading back of the VVPB of DRE requires the system to back track to the database or at least the database table of the candidates being selected for read back.  Alternatively, a true and independent and private verification of paper ballots for the visually impaired voters would be to have a third party equivalent of a machine-reader. Such a device must be independent of the voting system manufacturer. This would require a system (hardware-firmware-software) that is commercial-off-the-shelf (COTS) that has open standards. Even a third party developed system that is open-source may not be independent enough if they are not truly COTS. After all, it is dependent on yet another manufacturer.

Most people forgot that all of the current ballot-marking devices (BMD) use templates to print or mark on pre-printed ballots or print and mark on the same ballot. When ballots are fed back for reading, readers do not use a third party OCR or a barcode reader as independent mechanism. Instead they still go back and use the template to compare on the marked area and use the table to read back to the voters. They are one and the same whether reading from the data stream for printing or reading back by using the template after scanning.

The only commercial-of-the-shelf (COTS) means of reading a paper ballot is the use of optical character recognition (OCR) that still lacks of common industrial standards or scan using a condensed representation such as a 2-D barcode (e.g. PDF-417), a technology that has a public standard.

In the case of the BMD system, the use of OCR coupled with a text-to-speech engine represents the most direct method that may be able to use third party or open source software. The accuracy is still not yet adequate to provide 100% accuracy and thus may cause confusion.

Even if accuracy is not a problem, OCR posses practical concerns:

• OCR with text-to-speech engine system must read a complete ballot including those not selected unless incorporating special software. It will be equivalent to doubling the time of voting that even the visually impaired voters may object to.
• Even then, an OCR with text-to-speech engine system still needs special programming to interpret and “read” only the voters’ filled ovals as a selection and read back interpretive words like “filled oval” and “unfilled oval”. By itself, COTS OCR will not know what a filled or unfilled oval means. And sometimes, the system may be required to pre-program to “read” the signature of the County Clerk of the jurisdiction or must be programmed to disregard other timing marks.
• If only those that have been selected are read, the use of the original software and database will be a pre-requisite.  Certain blind voters and those of similar persuasions object to reading from the sama data stream that is used to print the voter verified paper ballot.
• Another potential issue is the objection to the use of the “computer voice.”  Alternatively, if a recorded voice is to be used, it will need yet a separate programming on top of the otherwise open-source or public domain software.

We agree with many experts on the alternative approach of using barcode representation. To use a commonly available and open standard third party hardware and software system to decipher a representation of the selections made and printed on the VVPB may be technically the only feasible and practical solution. The most commonly used machine-readable representations are 1-D and 2-D barcodes. Using the low data density of 1-D barcode will be inevitably cumbersome when there are multiple contests that are typical in US elections.  Ballots may need as many lines of barcodes as the number of contests.

The use of 2-D such as PDF-417 is common and has relatively high data capacity to accommodate the requirements of reading as much as 500-1000 bytes of characters for 20-50 contests. Even with the data capacity of 2-D barcodes, sometimes multiple barcodes may be required.

There are technical difficulties inherent with this approach as well:

• Typical barcode reading using a handheld device is not adequately accurate for close to 100% read rate required for the election application. A detailed scanner such as a standard fax machine or document imaging system may be currently the only means that can provide such accuracy. As Mr. Noel Runyan[1]noted, it may at present  be difficult for some visually impaired voters to manage to vote and some of them are just physically not possible.
• AVANTE believes it is possible to engineer a solution in which the VVPB from the DRE or BMD and a directly printed 2-D barcode are fed into an imaging device without manual handling. Such a system may have to be developed by a third party or by the original manufacturer of the system in terms of hardware “adaptation.” This third party will have to be responsible to develop software to automatically read the barcode and ignore the rest. It may not be as independent and certainly not COTS with an open standard anymore.
• To be totally independent of the original voting system, the only possible read back voice is again, a synthesized voice. Some visually impaired voters may find it objectionable.

In short, we have several options but none are perfect. Like Mr. Runyan, we believe something has to be compromised. This is the state of our technological know-how. We are sure we will be able to continuously improve over time.

Here are the choices with limitation and costs:

Use a text-to-speech synthesized voice (may incorporate recorded voices of candidates) to read back what was printed from the data stream that is sent to the printer of VVPB. The provisions and points to be aware of are:

• At least a portion of such read back software be open source to allow independent verification.
• Incorporate a third party developed software module that is open source (and better yet a public domain developed with sponsorship from EAC) to read the data stream using the database table provided by the manufacturer of the voting systems.
• This approach costs almost nothing. They are available today from all manufacturers that are providing VVPB solution.

Use a text-to-speech synthesized voice to read the 2D barcode representations of the selections and other relevant ballot identifiers. The provisions and points to be aware of are:

• Only limited ballot-marking devices such as those made by AVANTE and Populex have the capability to print 2-D barcodes. The more popular AutoMARK system is not currently programmed with such capability.
• All visually impaired voters must accept the synthesized voice.
• This approach must still incorporate a third party developed software module to extract the barcode data and ignore the rest of the printed data.
• This third party developer may be sponsored by EAC to provide a public domain software module but must also work with the original voting system manufacturer to ensure proper adaptation to accept the VVPB in whatever form-factor.
• It costs at least $2,000 for physical hardware adaptation and incorporation of another computer independent of the original voting system. If such a ballot- reading module is to be loaded into the original voting system, some form of “handshake” must be worked out. For less independence and customization, the cost may be reduced to $1000 each.

We hope it is clear to all that it is not the intent of AVANTE to discourage and/or encourage specific approaches. We only wish to point out the reality and facts of the current available technologies and those that have been incorporated in our nation’s voting systems today.

[1] “Improving Access to Voting-A Report on the Technology for Accessible Voting Systems”, By Noel Runyan; February 14, 2007