Dominion Democracy Suite

---

Public Comments on the Dominion Democracy Suite 4.14-A.1
December, 2014

These comments are very close to what I submitted to the California Secretary of State. There are some minor changes to titles, formatting and numbering for the Web version.

SUMMARY:

• There are several security gaps in the system (sections 1 & 2),
• The user interface for the ICE voting system is terrible (Section 5).

---

1 – INTRODUCTION

1.1 Personal Background

I am:

• the author of CountedAsCast.org
• co-chair of the Voting Rights Task Force
• a programmer with more than 30 years of experience
• a former senior software consultant for very large corporations.

1.2 Look At The Whole System

I try to look at voting systems as a consultant. How can we deploy well-designed, well-tested, cost-effective systems to work easily and accurately across many counties, large and small, that come under complex and very high stress just a few times a year?

Personnel is important in this kind of a system. There is a small core of dedicated experts in election departments and vendor organizations. There is another level of many thousands of temporary poll workers who receive a minimum of training, often have no computer background, and have to work an exhausting 15+ hour day. Then there are the voters, who in California, mostly vote on long, frustrating ballots, and who expect to be able to walk in and vote, with little or no training necessary. Finally there is a small number of disabled Californians facing extra challenges to vote, but who are willing to do what it takes to overcome those challenges, as they do most of their lives.

1.3 Documents

These comments address the application for certification of the Dominion Democracy Suite 4.14-A.1 with Adjudication 2.4 voting system described here: http://www.sos.ca.gov/elections/voting-systems/oversight/dominion-voting/.

The staff report is here:
http://votingsystems.cdn.sos.ca.gov/dominion-voting/staff-report.pdf

I shall be referring to the conditional re-approval of Diebold systems on December 31, 2009.
The document refers to the Diebold system. At the time, Premier was the vendor of that system. The conditional re-approval is here:
http://votingsystems.cdn.sos.ca.gov/vendors/premier/premier-11824-revision-1209.pdf

1.4 California Configuration

Please note that the configuration for this system is designed for use in California.

1.5 Styling

At various places in these comments, I use bold styling. This is not for emphasis, but to make various points easier to find in a long document.

2 SECURITY VULNERABILITIES

2.1 SOURCE CODE REVIEWS

The source code reviews are here:

Click to access democracy-suite.pdf

Click to access adjudication.pdf

2.1.1 Insider Attacks

For a long time, my biggest concern with voting systems has been with insider attacks, especially via the source code. This “attack vector” is the most pernicious. This is why I have been in support of disclosed/open source software since 2005. Open source is not enough to ensure the integrity of the system, but it certainly helps to have more and independent programmers inspecting the code.

2.1.2 Backdoors

Section 2.4.5, “Backdoors”, of the Adjudication source code review correctly states that “Backdoors are extremely hard to find because a seasoned programmer can obfuscate code to look benign. The ATSEC team would like to stress that, when facing a competent and sufficiently motivated malicious developer, it is extremely difficult to prove that all backdoors in a system have been identified. … A full backdoor analysis is also impractical in a short period of time because a deep understanding of the data structures and code design is required to be able to recognize functionality that is out of place.” Given that election systems are mission critical to the formation of our government, California must act as if the code on any system is rigged, because we cannot prove the negative.

2.1.3 Unitialized Variables

A few specific points. Section 3 of both documents refer to unitialized variables:

• Democracy Suite, pg. 11, #9
• Adjudication pg. 9, #5, #6

This raises a red flag for me because:

1) Unitialized variables are really easy to find and initialize. For example,

var x;

could be initialized with just 2 more characters

var x = 0;

2) If not followed carefully, there is the potential for those unitialized variables in a carefully prepared program to be pointing to erroneous data, or worse, function addresses that could trigger malicious code undetected. Unitialized variables should not exist in mission-critical code.

2.1.4 Overflows

With respect to Adjudication issue #8 (pg. 9), and Democracy Suite issue #26 (pg. 15), “No detection of overflows in arithmetic performed on vote counters“, while overflows may be very unlikely, given the critical importance of vote counters, every effort should have been made to detect overflows.

2.1.5 Other Vulnerabilities

The Democracy Suite has a series of 14 medium level issues dealing with security (pgs. 12 – 16). Issue # 29 “Poor quality keys” has a high level of severity, again dealing with security. Advanced security is outside my expertise, but just reading these raises red flags.

2.2 RED TEAM REPORT

The red team report is here:

Click to access red-team-support.pdf

2.2.1 Missing Windows Updates

Pages 11-12 ,“Missing Windows Updates”:
The table for October, 2014 indicate 78 “critical” and 172 “important updates”. These are just the known missing updates. All security updates should be installed and retested. The “critical” MS11-058 (pg. 26) vulnerability in particular needs to be patched. The summary table on page 30 lists 3 medium and 7 high risk issues, of which 4 remain unmitigated.

2.2.2 Red Team Conclusion

The conclusion on page 31 states “A remote user could leverage most of the vulnerabilities across the network to obtain information about the system, voter ballots and results, or gain remote access to the system. If remote access is gained, recovery of user credentials through system memory (RAM) analysis could be executed and used to modify the backend database of the EMS Server.” This is a very serious vulnerability.

2.3 RECOMMENDATION

These reports indicate that these systems are vulnerable to insider or outsider attack. Therefore, I recommend that all the security-related conditions applied to re-approval for previous systems (ex: Diebold, 12/31/2009) be applied in this case.

3 IMAGECAST EVOLUTION (ICE)

ICE is the voting system as a ballot marking device and precinct scanner combined into one unit. Dominion deserves special recognition for solving a problem of how to keep ballots private during the transfer from voting machine to scanner. This has been an issue for those not able to handle paper ballots for whatever reason.

3.1 Configuration and Logistics

3.1.1 Physically Large System

The system is physically large, similar in size, though definitely not in function, to a trash bin. It could fit into a SUV with some lifting, but not into the trunk of many cars. Other voting systems and scanners fold down to the size of a suitcase. At that size, some jurisdictions have had the practice of letting precinct captains take one or two with them, for transport to the precinct election morning. This practice poses the “sleepover” problem – allowing access to the voting machine and/or scanner for many hours, providing an opportunity for hacking. In the case of the ICE, some jurisdictions will have to adjust their practices, and deliver the systems by truck or van. While increasing costs, it does reduce the sleepover vulnerability.

3.1.2 Two Scanners Per Precinct

The combination voting system/scanner means that each precinct will need at least two scanners. It can take people using audio recordings 15 to 30 minutes to vote, which would block the scanner. So a second scanner would need to be available for other voters to cast their ballots. A second ballot marking device in the precinct runs contrary to preferred practice in California, where only one system is available for those who need it. (See condition #1 of the 12/31/2009 re-approval of the Diebold system). I do not know if a 2nd ICE ballot marking system can be disabled while leaving the scanner functioning, but that would help. It would be preferable to have a 2nd, standalone scanner available instead of a 2^nd combined unit.

How the Secretary wishes to handle these two issues, I will leave up to her excellent judgment.

3.2 200,000 Kinds of Marks

I was told that the ballot marking device has available 200,000 kinds of marks or ways of filling in the ovals to vote, and that the same mark is used throughout an individual ballot. It is not evident to me why one needs so many. Clearly, ballots in different jurisdictions may look different, so some variety is needed. But there is potential for two kinds of problems:

3.2.1

200,000 different marks could potentially be used to identify individual voters. I would call this a low risk, but present.

3.2.2

When you have 200,000 marks to choose from, certain ones could be selected by the ballot marking device as a signal to the scanner on how to count the votes. Probably a low to medium risk, but present.

3.2.3 RECOMMENDATION

A ballot marking device in a precinct should always use the same mark for all voters on all contests. With that, you eliminate issues 1 and 2.

4 BALLOT STYLE LIMITATIONS

Item ‘a.’ on page 18 of the staff report notes that there are limitations on the number of ballot styles available. The staff report notes this again at the end of their Conclusion, section IV, page 29.

The voting system industry has a long history of misrepresentations. I would note that condition 37 of the 12/31/2009 re-approval of the Diebold system cautions against misrepresenting their systems.

4.1 RECOMMENDATION

The Secretary should make it clear that failure to include limitations such as the above in their California marketing materials would constitute misrepresentation.

5 ICE VOTING SYSTEM INTERFACE

I’m, sorry. I don’t know how to be polite about this. I cannot remember having seen an interface this bad since the mid-80s, with the French Minitel terminal. I shall explain.

5.1

The screen is touch sensitive. I saw our assistant use the touchscreen to bring us to the voter’s interface. The voter, however, cannot use the touchscreen, which makes the system harder to use.

5.2

Voters must use a controller device, somewhat similar to a video game controller. It’s called an ATI, “accessible tactile interface”. It has yellow left and right arrow buttons on the left; a biggish red X button in the middle; blue up and down arrow buttons on the right; and a green bar on the bottom, marked “Help”. The decision to use the controller may have been made for accessibility reasons. However, the failure to develop a touch screen interface for the normal voter makes it harder to use.

5.3

It has been a very long-standing practice in the computer industry, evolved from stoplights, for green to mean “go”, and red to mean “no”. With the ICE, it’s the exact opposite. The very first screen I had to work with showed “English” on a green background, and “Espanol” on a red background. My normal expectation was that I was about to select English. After a bit of confusion, I pressed the X on the controller, and got a screen in Spanish, the red one!

5.4

Stuck in Spanish, I could not see how to get back to the language selection screen. The assistant pulled out what looked like a small round metal device, and restarted the voting process. The lack of an obvious “back” button is poor design.

5.5

The counterintuitive red-green signaling appeared at several other places during voting. Again, I was making mistakes. I am guessing that they wanted the red to match the red X on the controller, but that brings us to another problem. It is also long-standing practice for an X to mean “no”, “close” or “cancel”. To indicate “OK”, “go”, or “I want this”, one uses the word “OK”, or a checkmark, along with the color green. Even a + (plus) button would have been better than an X. Bad design.

5.6

ICE attempts to produce a visual copy of an entire side of the paper ballot on screen. The presentation is well done, but inappropriate. Item “b” on page 18 and item “v” on page 25 of the staff report note that the 2005 VVSG version 1.0, section 3.1.6(a) states: “Voting machines with electronic image displays shall not require page scrolling by the voter.” But the discussion also makes it clear that the problem is with the use of scroll bars. It goes on to say that “Voting systems may require voters to move to the next or previous ‘page.’“. Every other voting system I have seen, including some VVSG compliant, present a screen or more for each contest, with some kind of [Next] and [Previous] buttons available. The yellow left/right buttons on the ATI controller should work here, along with touchable buttons on the screen. Unless you have a huge screen, like a Sequoia system from the 1990’s, trying to present an entire side of a 14″ California ballot on one screen is a non-starter.

5.7

Indeed, with the ICE system, since the ballot is so large, you do have to “scroll” the page anyway, by pressing the controller’s blue up and down buttons. The problem here is that this did not work well. When I got to the bottom of the first column, pressing the blue down button jumped me to the 3rd column, not to the 2nd, where I next needed to vote.  It took quite a bit of experimenting to figure out how to get to the 2nd column. This is where a touchscreen helps.

5.8

It turns out that the ATI controller’s yellow left/right buttons are supposed to move you between columns. I expected to be taken to the top of the next column, since that is where I needed to vote next. Instead, it places you laterally at roughly the same vertical position in the middle of the new column that you were at in the previous one. I was not the only observer to be confused by this.

5.9

There is an overvote screen, when you have submitted a ballot with an overvote. The prompt says “Do you want to continue?” (ie: cast your ballot) The default is “Yes”, and this time, in green, where the default should be “No” (red), since an overvote is normally an error. This is in violation of the 2005 VVSG, vol. 1, section 3.1.4(e), which reads:

The use of color by the voting system should agree with common conventions: (a) green, blue or white is used for general information or as a normal status indicator; (b) amber or yellow is used to indicate warnings or a marginal status; (c) red is used to indicate error conditions or a problem requiring immediate attention.

5.10

The green help bar at the bottom of the ATI should be a more intuitive question mark.

5.11

When I got to the Ballot Review screen, I could not find a way to go back. The only working button on the ATI was the red X.

5.12 RECOMMENDATION

A voting system must be as easy to use as an ATM, or an airport check-in system. Voters cannot be trained, nor take much time to figure out how to work the system. ICE is not just unintuitive, it is so counterintuitive as to be unusable for normal voters. Section 19101 (b)(1) of the California Elections Code states “The machine or device and its software shall be suitable for the purpose for which it is intended.” The ICE interface is not remotely suitable, and should not be certified at all.

Note: Section 19101 of the California Elections Code is at (http://www.leginfo.ca.gov/cgi-bin/displaycode?section=elec&group=19001-20000&file=19100-19105).

6 OTHER USABILITY ISSUES

6.1

I did not have a chance to review the EMS and other parts of the system. The “users” of those systems are normally trained, so it should be useable, I hope.

6.2

Precinct workers get some training. Not having worked with the setup procedures, I cannot gauge how suitable the ICE setup and use procedures are for them. I cannot have confidence, having seen what the voters must work with on the same device.

6.3

I also cannot comment on the accessibility devices. That in the staff report, only 43% found the system “easy to use” (question #5), and 39% of the users found it “confusing to use” (question #9) is not encouraging.

7 SUMMARY

Given the need some jurisdictions might have to renew their voting systems, I was initially inclined to recommend conditional approval. There are security issues that might be mitigated with conditions similar to what we have seen before with Diebold in 2009. The fact that one cannot use the precinct scanner while a voter is using the ballot printer poses questions about limiting the system to 1 per precinct. Most importantly, the user interface for the ICE system is so counterintuitive and confusing, and navigating a full California ballot page on 1 screen is so tricky without practice, that the ICE system is unsuitable for the purpose for which it is intended. It should not be certified under any condition.