1  Comments on the Pima County “Election Security Plan”

The Pima County Division of Elections has put out a notice (reference 1) “to solicit input regarding the Pima County Election Security Plan.”

I surmise from reference 2 that the “Election Security Plan” they are talking about is reference 5. The only source I know of for this is as an attachment to reference 3. (If this is not the right “Security Plan”, please let me know, the sooner the better!)

Here are some specific observations. (See section 2 for additional discussion.)

1.    We don’t need a security plan per se. We need a plan.

That is, Division of Elections needs to have a comprehensive plan, covering all phases of operations.

Why? Because security needs to be baked-in, like the straw in the biblical bricks. It is not satisfactory to make bricks without straw and then sprinkle straw over them later.

Actually there are two sorts of plans that are needed:

• A day-to-day plan of operations, providing for security (among other things) in routine operations. Item 2, item 7, item 8, and item 15 serve as illustrations of why this is important.
• A longer-range plan, a strategic plan if you will, spelling out where we want to go and how to get there. This, too, needs baked-in security. As an example, when it comes time to replace equipment, we don’t want a “security plan” for buying equipment; we need a plan that takes security into account along with initial cost, reliability, durability, compatibility, and a host of other things.

2.    There needs to be a well-codified procedure to account for each tamper-evident seal, from cradle to grave. There needs to be a record of each seal that has been used, and what it was used for.

This needs to be part of the overall operational plan. This may seem mundane, but it needs to be done right. Mundane things like this contribute to security in an important way. If we see a seal on the GEMS CPU, or on something else, how do we know it is the right seal?

This is an example illustrating that many details have been left out of reference 5.

3.    Reference 5 is incomplete in that it fails to provide a plan for recovering from a breach of security. Such a plan is required by the Arizona Secretary of State, according to reference 10.

There needs to be a well-codified procedure for what happens, for instance, if a box of ballots comes in from the field with its seals broken. Reference 5 says this "shall require immediate notification of Pima County Elections" ... but this leaves us with the question, what happens next? Mere "notification" doesn’t solve the problem. Should workers notify and then count the ballots? Or notify and then set the ballots aside? Should they re-seal the box pending further action, to prevent further problems?

And what will Pima County Elections do after they have been notified? It is nice that this problem has been foreseen; now the next step should be to foresee some solutions.

4.    Breached ballot boxes are not the worst of it. What will Pima County Elections do if they discover that the seals on one or both GEMS boxes have been broken?

There needs to be a plan for restoring confidence in the GEMS hardware. It is not easy to solve this problem without the risk of making things worse. Much worse. A broken seal could easily signify the beginning of an attack.

5.    Any modern plan contains use-case scenarios. In the case of a security-related plan, the watchword is WYTM ... i.e. What’s Your Threat Model? Reference 5 sorely lacks a systematic discussion of threat models. As a result, there is no analysis of whether all the threats have been met, or (conversely) whether each of the proposed security measures actually serves a useful purpose.

6.    Page 10 of reference 5 requires “voting equipment and voted ballots” to be returned. It is disturbingly silent about the fate of unvoted ballots.

7.    Reference 5 apparently expects all workers who log in to the GEMS host use the same userID.

As a rule, the sharing of userIDs is a bad idea. It is a violation of fundamental security principles. It leaves no record (except via the surveillance cameras) of who actually was at the computer. There needs to be a better way of accounting for who made what changes.

The split password idea does not solve this problem at all. It means that two people were present at the moment of login, but we don’t even know which two ... and the second person is free to leave immediately thereafter. There is nothing in the procedure to suggest that the second person takes any responsibility for what happens after login.

If you want to have each login countersigned by a second person, that’s fine ... but both the login and the countersigning need to be done using individual, unshared userIDs ... and individual, unshared passwords.

Individual userIDs with individual passwords are necessary as a prerequisite for item 8, for controlling access during the inevitable personnel turnover, for limiting the damage caused by the compromise of one password, and for many other reasons.

8.    There absolutely needs to be a version control system that records which files were modified when and by whom. For example, git (reference 6) is a widely-used version control system.

In particular, it there are multiple copies of the git repository, and no one person has access to all the copies, it becomes much harder for anyone to make surreptitious changes in any of the version-controlled documents.

Reference 9 mentions the importance of unalterable logs. The County Administrator’s report (reference 3) calls for the introduction of “change control”.

9.    It is naive to think that hash code testing suffices to verify "that the ballot tabulation software is exactly the same as the software tested and analyzed in the federal and state certification process". A hash code is not the same as a digital signature. Not even close.

10.    Reference 5 doesn’t seem to say who is responsible for hardware maintenance of the voting machines. This applies to all machines, including GEMS especially, but including other machines as well. There is almost unlimited opportunity for tampering during repair or during routine maintenance.

11.    In reference 7, Appendix A lists 126 separate “flaws” in the Diebold equipment. On page 26 it lists 37 of these as “fixed” and another 37 as definitely not fixed; the status of most of the others is not clearly stated.

A proper operational plan would include an item-by-item recitation of these flaws, along with a plan for mitigating each one.

12.    The bull’s-eye (Figure 1) on page 5 of reference 5 is misleading. For example, at one point it mentions “encryption technology”. At best that falls into the category of wishful thinking; it does not fall into the category of “fact” or even “plan”. As documented in reference 7 and elsewhere, the crypto in the Diebold machines is so badly mishandled as to be essentially worthless. Reference 5 does not give any hint as to how strong crypto might be introduced.

13.    The statement on page 7 of reference 5 that video tapes will be “archived for up to 24 months” does not instill confidence. We all know what “up to” means. I can go to the used-car dealer and get “up to” 70% off. If some of the tapes were kept for 24 months but others were kept for only 20 days, it would comply with this rule of “up to 24 months” in the technical sense. Wouldn’t it be better to have an explicit regulation as to the minimum time for retaining these tapes?

And what about retention of other records, such as sign-in and sign-out logs?

14.    Many of the procedural safeguards mentioned in reference 3 need to be formally incorporated into the overall operational plan. For example, open cabling and color-coded cabling is important, but not mentioned in reference 5.

15.    Along the same lines, page 13 of reference 5 lists a few things that may not be brought into the Counting Room. This list is nowhere near adequate.

It might make more sense to make a short list of what is allowed, and to forbid everything else. Why? Well, for starters, it would have been hard to foresee that it would be necessary to forbid Cropscan boxes.

16.    On page 5, page 6, and elsewhere, reference 5 emphasizes an “Open and Transparent Election Environment”. Again that is neither “fact” nor “plan”. There have been incidents in the past where records that clearly should have been released to the observers were inexplicably locked away and not released. There is nothing in the “plan” to prevent this from happening again.

Also: At present the County refuses to give observers the records of votes cast in previous elections. This is a problem, yet reference 5 does not offer any hint as to how this problem might be solved. In fact there are good reasons why such records should be released, and no good reasons why they should be withheld, as discussed in reference 8.

2  The Larger Picture

A proper security program has many elements. It is sometimes useful to categorize these as follows:

1. Physical security.
2. Security procedures.
3. Software security.

It is true, indeed proverbial, that you cannot have security without physical security. Reference 3 recommends spending millions of dollars to upgrade the physical security of buildings and facilities.

It is also true that you need to have systematic procedures with baked-in security. Reference 5 touches on some procedural issues. Some of them (such as split passwords) are not very good procedures, but at least this illustrates the sort of procedural detail that is needed. More generally, management needs to instill an attitude, a habit, a culture of incorporating security and transparency into every activity.

Last but not least, computers and computerized equipment need secure software and firmware. This is the moose on the table. This is the huge, huge problem that nobody is talking about.

The problem is that the Diebold software is terrible. Year after year, in report after report, the software is found to be deficient. As reference 11 put it, «Systems that are architecturally unsound tend to exhibit “weakness-in-depth” — even as known flaws in them are fixed, new ones tend to be discovered. In this sense, the Diebold software is fragile.»

The iBeta forensic report to the County (reference 4) pointed out that it is possible to steal an election in such a way as to leave “no clue that the files had been altered or replaced”. This is just completely unacceptable.

The County has not solved this problem, and apparently does not even have a plan for solving this problem. Reference 3 gives the impression that the County does not even recognize this as being a problem.

Reference 3 suggests replacing some voting equipment because it is “old” – not because it is horrifically insecure, but merely because it is “old”. Let’s be clear: replacing worn-out hardware will not alleviate the main security problem. Diebold software running on new hardware will still be horrifically insecure.

Fixing this problem will not be easy, because software quality problems afflict not only Diebold but its principal competitors as well. The California Secretary of State recently found it necessary to decertify Diebold, Hart InterCivic, Sequoia, and especially ES&S. See reference 12.

3  Priorities

• Mail-in ballots are a problem. There is unbounded opportunity for vote-buying and voter coercion before the ballots are mailed in. On top of that, there is opportunity for wholesale hanky-panky after the ballots are received but before they are counted. This includes “losing” ballots or fabricating extra ballots, or more subtle attacks involving early counting. Early counting results are tantamount to a super-accurate pre-election poll, and are super-valuable to anyone who can get access to them.

  Lately there has been a campaign to encourage mail-in ballots. This is a mistake. This needs to be reversed. The policy should be that only persons who really need to use a mail-in ballot should do so.

• Any sort of DRE (“Direct Recording Electronic”) voting system is bad news. DRE needs to be eliminated. See reference 13. Adding“voter verification” to DRE doesn’t solve the problem. Using marked paper ballots as the front end (as Pima County mostly does now), followed by optical scanning, is the best available front end. (The back end is another story.)
• Diebold software is horrifically insecure. The machines in the polling places are insecure, and the central tabulating machines are insecure. The door is open to attacks that are unlimited in magnitude ... and undetectable.

  Alas, this problem is not easily fixed because Diebold’s principal competitors are as bad or worse.

  However, even if this problem is not easily fixed, it still needs to be fixed. It must remain the focus of attention until it is fixed.

• We need a major upgrade in procedural security. Procedural security is desirable in general, but it looms even larger given the lack of technical security mentioned in the previous item.
• Experience indicates that problems are fewest in jurisdictions where the election is overseen by a nonpartisan (or “multipartisan”) Election Board. In Pima County, as I understand it, the Board of Supervisors has final responsibility under the law, but they can of course delegate the details. In recent years they have delegated a great deal to the Division of Elections. It might be better to delegate to a nonpartisan Election Board instead.
• Polling-place security is important, but it is fairly far down on the list of things to worry about, because it is a manageable problem. Polling places have been around for a long time, and people have a fair idea how to secure them.

  Polling-place fraud is retail fraud. It happens (usually) on the scale of onesies and twosies. We should be much more worried about wholesale fraud, which is more likely to occur in back rooms.

4  Conclusions

Reference 5 takes a few steps in the right direction, but it is not a satisfactory plan. It cannot be converted into a satisfactory plan by minor editing here and there.

The County needs to call in an expert to prepare a comprehensive operational plan that includes baked-in security in all phases of operations.

The County needs to take strong measures to identify and procure a secure voting and counting system.

It appears that none of the staff involved in the preparation of reference 5 have sufficient expertise to prepare a plan of the sort that is needed. This conclusion is based on what we learned from the recent court case as well as from reference 5 itself. (I can go into details if anybody really needs them.)

5  References

1.

http://www.pima.gov/current/Public%20Notice-2007%20election%20security%20plan.htm

NOTICE OF THE PIMA COUNTY DIVISION OF ELECTIONS PUBLIC HEARINGS REGARDING THE PIMA COUNTY ELECTION SECURITY PLAN

The Pima County Division of Elections will hold public hearings at the dates, times and places listed below to solicit input regarding the Pima County Election Security Plan. Anyone may submit comments or suggestions pertaining to the Election Security Plan at the public hearing. Written comments or suggestions will also be accepted by the Pima County Division of Elections Office, 3434 E. 22nd Street, Tucson, Arizona 85713 until Friday, December 14, 2007 at 5:00 p.m.

These hearings are accessible for persons with disabilities. Requests for accommodations must be at least 48 hours in advance by contacting (520) 351-6830.

Friday, December 7, 2007 @ 2:00 p.m.
Oro Valley Public Library
1305 W. Naranja Drive
Meeting Room                                                               
Oro Valley, Arizona

Monday, December 10, 2007 @ 2:00 p.m.
JLK/Bear Canyon Library
8959 E. Tanque Verde Road
Meeting Room
Tucson, Arizona

Tuesday, December 11, 2007 @ 2:30 p.m.
Pima County Public Works Building
201 N. Stone Avenue
Basement, Conference Room "C"
Tucson, Arizona

Friday, December 14, 2007 @ 2:00 p.m.
Green Valley Library
601 N. La Canada Drive
Meeting Room
Green Valley, Arizona

2.

Pima County Public Comment — Election Security Report http://www.pima.gov/comment/blog/blog.aspx?blog_id=1mg_blog_control=blog_view_postpost_id=2

3.

C.H. Huckelberry, "Election Security Report" http://www.pima.gov/GenInfo/Pdfs/Election Security 101907.pdf

4.

iBeta “Final Report” (forensic analysis) included as Attachment 1 to reference 3.

5.

“Security Plan” included as Attachment 2 to reference 3.

6.

GIT – Fast Version Control System http://git.or.cz/

7.

Alec Yasinsac, John Kerski, David Gainey, Michael Gerke, Kristine Amari, and Donald Newell, “‘Software Review and Security Analysis of the Diebold Voting Machine Software”, TSX Supplement, For the Florida Department of State, September 28, 2007 http://election.dos.state.fl.us/pdf/SAITreport.pdf

8.

John Denker “Pima Election Security” ./pima-election-security.htm

9.

Michael Ian Shamos, “Voting System Security Review” http://evote-mass.org/Shamos_Security_Report.pdf

10.

Arizona Secretary of State, Election Procedures Manual http://www.azsos.gov/election/Electronic_Voting_System/2006/2006_Electronic_Procedures_Manual.pdf (former title, Electronic Voting System, Instructions and Procedures Manual)

11.

Joseph A. Calandrino, Ariel J. Feldman, J. Alex Halderman, David Wagner, Harlan Yu, William P. Zeller, “Source Code Review of the Diebold Voting System” (July 20, 2007) (Report commissioned as part of the California Secretary of State’s Top-To-Bottom Review of California voting systems.) http://www.sos.ca.gov/elections/voting_systems/ttbr/diebold-source-public-jul29.pdf

12.

“Decertification/Recertification Decisions Issued by Secretary of State Debra Bowen” http://www.sos.ca.gov/elections/elections_vsr.htm

13.

Jon Stokes, "How to steal an election by hacking the vote" (October 25, 2006) http://arstechnica.com/etc/How_to_steal_an_election-ArsTechnica.pdf