July 31, 2016

avatar

NIST Recommends Not Certifying Paperless Voting Machines

In an important development in e-voting policy, NIST has issued a report recommending that the next-generation federal voting-machine standards be written to prevent (re-)certification of today’s paperless e-voting systems. (NIST is the National Institute of Standards and Technology, a government agency, previously called the National Bureau of Standards, that is a leading source of independent technology expertise in the U.S. government.) The report is a recommendation to another government body, the Technical Guidelines Development Committee (TGDC), which is drafting the 2007 federal voting-machine standards. The new report is notable for its direct tone and unequivocal recommendation against unverifiable paperless voting systems, and for being a recommendation of NIST itself and not just of the report’s individual authors.

[UPDATE (Dec. 2): NIST has now modified the document’s text, for example by removing the “NIST recommends…” language in some places and adding a preface saying it is only a discussion draft.]

The key concept in the report is software independence.

A voting system is software-independent if a previously undetected change or error in its software cannot cause an undetectable change or error in an election outcome. In other words, it can be positively determined whether the voting system’s (typically, electronic) CVRs [cast-vote records] are accurate as cast by the voter or in error.

This gets to the heart of the problem with paperless voting: we can’t be sure the software in the machines on election day will work as expected. It’s difficult to tell for sure which software is present, and even if we do know which software is there we cannot be sure it will behave correctly. Today’s paperless e-voting systems (known as DREs) are not software-independent.

NIST does not known how to write testable requirements to make DREs secure, and NIST’s recommendation to the STS [a subcommittee of the TGDC] is that the DRE in practical terms cannot be made secure. Consequently, NIST and the STS recommend that [the 2007 federal voting standard] should require voting systems to be [software independent].

In other words, NIST recommends that the 2007 standard should be written to exclude DREs.

Though the software-independence requirement and condemnation of DREs as unsecureable will rightly get most of the attention, the report makes three other good recommendations. First, attention should be paid to improving the usability and accessibility of voting systems that use paper. Second, the 2007 standard should include high-level discussion of new approaches to software independence, such as fancy cryptographic methods. Third, more research is needed to develop new kinds of voting technologies, with special attention paid to improving usability.

Years from now, when we look back on the recent DRE fad with what-were-we-thinking hindsight, we’ll see this NIST report as a turning point.

Comments

  1. Are conventional voting machines “hardware independent”? Undetected changes in mechanical voting machines’ hardware don’t seem to lead to necessarily detectable changes in election outcomes. Are DREs held to a higher standard?

  2. Josh,

    Here’s what the report says, on page 5:

    It should be noted that in SI [Software Indepencence], “software” really means complex technology, which can be software implemented in hardware, e.g., burned into PROMS or built into ASICS. “Software independence” should be interepreted to really mean complex technology independence.

  3. avatar Jon Marcus says:

    Josh, it’d be pretty hard for an undetected change in the hardware to change my punchcard or pencil on paper vote. (The voting methods I used in the past two elections.) At best you could do something difficult to detect (e.g. deliberately misaligning punchcards). But a careful inspection would reveal something like that.

    But it’s easy to come up with an undetectable change to software. (See http://www.freedom-to-tinker.com/?p=1063)

  4. avatar the_zapkitty says:

    Josh tauberer Said:

    “Are conventional voting machines “hardware independent”? Undetected changes in mechanical voting machines’ hardware don’t seem to lead to necessarily detectable changes in election outcomes. Are DREs held to a higher standard?”

    (the zapkitty pursues a tangent…)

    Because DRE voting failures have the potential to be, and have recently been proven to be, vastly more damaging to the stated goal of fair and free elections than compromised mechanical ballots could possibly have been, then shouldn’t DRE’s be held to a higher standard?

    Following that thread there is a logic… the more complex and “interactive” the voting technology is, the higher the standards it should be held to… … and if you start off with the basic requirements for a working election with hand-counted paper ballots then the ramp-up in security requirements for successively more complex voting technologies would seem to get very steep very fast.

  5. WE

  6. I predict that years from now, we will be voting from home, using high-assurance, open-source software, and cryptographic verification. There will be no paper trail. We will look back on today, not with superior what-were-we-thinking hindsight, but rather recognizing the difficult choices and tradeoffs which were being explored as we came to grips with new technology.

  7. avatar the_zapkitty says:

    *sigh*

    Here we go again… the magic solution to e-voting… endless epicycles of encryption! Unless you’ve somehow come up with solutions to the problems inherent in e-voting that have been overlooked by the rest of us?

    “We will look back on today, not with superior what-were-we-thinking hindsight… “

    Well, some of us won’t… some of us seem unable to learn from our mistakes.

  8. Here’s a little background on why I think trends are going this way. First, absentee voting and voting by mail is growing rapidly. See this chart of California’s experience: http://www.ss.ca.gov/elections/hist_absentee.htm . Absentee voting in California has grown steadily and is now at over 46% of all votes. California is a bellwether state and trends that start here tend to move elsewhere. Oregon does all its elections by mail now and has had good experiences. People like voting from home because it is convenient, they can take their time and study the issues, and they have flexibility about when they vote.

    Given the growth in absentee voting, it is natural to see it moving from paper mail to the internet over the next, say, 20 years. Electronic communication is growing and replacing old fashioned paper communication in many areas, and voting is likely to be no exception. California did a study on Internet voting in the year 2000: http://www.ss.ca.gov/executive/ivote/final_report.pdf . The report concluded that although the technology was not yet ready, the potential is there: “Despite these challenges, it is technologically possible to utilize the Internet to develop an additional method of voting that would be at least as secure from vote-tampering as the current absentee ballot process in California.”

    Obviously the security of home computers is of paramount concern in considering Internet voting, and of course at this time the security is lacking. However I am optimistic that this situation will change, as there are so many advantages to having a secure computer. One technology that has potential is secure virtualization. You will be able to run multiple virtual machines, each protected from the other by a relatively simple Virtual Machine Monitor. Some of the VMs can run legacy OSs whose complexity makes them inherently vulnerable to malware, but these compromised VMs won’t be able to touch the others. Other VMs can run high assurance software designed for banking, shopping and other transactions that you’d rather not let your viruses do for you. Voting software would be similarly isolated and designed using such techniques. In this way users will gain the benefits of legacy software compatibility while allowing new software modules to run in a clean environment. This should provide adequate security for voting as well as other sensitive applications.

  9. “Oregon does all its elections by mail now and has had good experiences.”

    But that is not e-voting at all–in fact it is about as non-electronic as you can get. And trends that start in Oregon (for example urban growth limits) tend to get distorted when they are implemnted in other states, because no one really wants to take the time to understand them.

    “Given the growth in absentee voting, it is natural to see it moving from paper mail to the internet over the next, say, 20 years.”

    Perhaps there should be a reason given for this, other than ‘electronics are the wave of the future”?

    “Obviously the security of home computers is of paramount concern in considering Internet voting,..”

    So I suppose you’d have use implement some form of Treacherous Computing (as RMS calls so-called Trusted Computing) on all computers? I would suggest you review RMS’s essay on why he calls Trusted Computing Treacherous Computing.

  10. avatar Ned Ulbricht says:

    The new report is notable for […] being a recommendation of NIST itself and not just of the report’s individual authors.

    Ed,

    The draft report is not a recommendation.

    From Questions and Answers on the Draft Report: “Requiring Software Independence in VVSG 2007: STS Recommendations for the TGDC”:

    Recent news accounts discussing the vulnerabilities of electronic voting systems contained in the report titled “Requiring Software Independence in VVSG 2007: STS Recommendations for the TGDC,” have raised theuestion of whether the report’s recommendations represent the official position of NIST. […] [T]he report is a discussion draft and does not represent a consensus view or recommendation from either NIST or the TGDC.

    (Emphasis added).

    You might want to revise this blog entry to clearly reflect the draft status of the report.

  11. I do hope the recommendations are adopted by the TGDC. This report is clear and well thought out.

  12. Ned,

    NIST has modified the report, and started saying it is only a discussion draft — though even the modified report says “NIST recommends…” in at least one place. It looks like NIST has changed its story here, which is interesting.

  13. avatar the_zapkitty says:

    Damn… and here I’d thought they’d decided to stop being a political football and actually do their fucking job…

  14. I hope this standard passes as the current standard leaves the electronic voting machines far too vulnerable to election fraud. I wrote about this subject almost two years ago, and the whole article can be read at http://tinyurl.com/rpdm4

    I’ll quote the most relevant sections here:

    I agree that an electronic voting machine should be used… but it must be one that has an audit trail as well as a way to confirm to the voter that their vote has been registered as they intended. The United States already has a fairly secure large network of computerized data terminals that could easily be adopted for this purpose, or used as a basis for the design of a secure, auditable, electronic voting terminal network. You are probably asking what network am I talking about.

    It’s simple… it is one that you see in use every day. It is fairly secure and the data entry system is fairly easy to use. The machines are capable of giving a printed confirmation of the voter’s selections for their records, as well as allowing the original paper ballots to be used as an audit trail in case of questionable vote counts. I am talking about the Powerball/MegaMillions lottery ticket terminal network. The terminals are close to being everywhere.

    The terminals are designed for robust use, being in use every day—in fact there are probably more people playing Powerball and Megamillions than usually vote in this country’s elections. Sad, but true. The network these lottery ticket terminals use is fairly secure… with all that money at stake, the security has been pretty well proven.

    The entry form for a five-ticket Powerball or Megamillions drawing has thirty data points on it. Easily enough to handle most elections, including state, local and federal races. The paper ticket can be retained in the machine to act as an audit trail. With no name on the ballot, anonymity is preserved. And the voter can get a printed sheet indicating their vote as registered by the machine, like the Powerball player gets their printed lottery ticket. As for simplicity… let’s face it… the average lottery machine operator isn’t a rocket scientist. These machines are designed to be operable by almost anybody with a minimum of training.

    The election equipment should be designed and manufactured by a group of manufacturers, with no one company controlling the full-design and manufacture of any single machine. This may make the election equipment more expensive, but it would reduce the chances of an election being influenced by the political bias of any one manufacturer or designer.

    The software and code for the election equipment should be open source-based code and tested by a politically diverse group of programmers and software engineers. The reason I say politically diverse as opposed to politically neutral, is no individual is going to be truly neutral, but by having a broad range of political diversity in the testing group, no one political philosophy will be able to bias the results of the software testing. All communications used by election equipment and its associated network must be encrypted using openly accepted standards of encryption security.

  15. avatar Ned Ulbricht says:

    It may be technically possible (though I haven’t researched it) that NIST may recommend some recommended recommendations outside a recommendation.

    At least as far as I’ve seen, a NIST “recommendation” typically has a section along the lines of:

    Authority

    This document has been developed by NIST in furtherance of its statutory responsibilities (under the Computer Security Act of 1987 and the Information Technology Management Reform Act of 1996, specifically 15 U.S.C. 278 g-3(a)(5)). This is not a guideline within the meaning of (15 U.S.C. 278 g-3(a)(3)).

    This document is recommended for use by Federal organizations which process sensitive information, and is consistent with the requirements of OMB Circular A-130, Appendix III.

    The recommendations herein are not mandatory and binding standards. This document may be
    used by non-governmental organizations on a voluntary basis. It is not subject to copyright.

    Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding upon Federal agencies by the Secretary of Commerce under his statutory authority. Nor should these recommendations be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, the Director of the Office of Management and Budget, or any other Federal official.

    There might possibly be some standards, guidelines or other authorities regarding the use of some of these words, somewhere….

  16. Dan, that’s a fascinating observation about the security of the Lottery network. It reminds me of an oped appearing in the New York Times in 2004 about the security of slot machines, and how much more well-regulated gambling equipment is than electronic voting machines. Clearly, if there is money at stake we as a society are willing and able to find good ways of conducting secure transactions, even over large networks. We apparently don’t feel that way about our political process.

  17. avatar Chris Grigg says:

    It would be well to keep in mind that the NIST draft appears to be limited to saying that DREs shouldn’t be used, without specifying too much about what should be used instead.

    Point being, even if you use paper ballots (which would be good to specifically require) and optically scan them at the polling place and in the presence of the voter (also good), the scanner/tabulator machines may still serve as a point of malicious attack on an election outcome, depending on their particular design. Remember, the same companies make the optical gear as make the DREs.

    So… it seems to me that in addition to standardizing on optically scanned paper ballots, there is an immediate need for extremely careful specification of either (A) the internals of all scanner/tabulator gear, or else perhaps (B) some form of highly hack-resistant mechanism for double-checking on a per-ballot basis the operation of the scanner/tabulator, probably with a second scanner/tabulator of different make & model. Option B, if implemented well, might be the stronger solution.

  18. avatar the_zapkitty says:

    Just for reference the current versions of the documents seem to be here:

    Preliminary Security Reports
    http://www.vote.nist.gov/meeting20061204.htm

    Draft Requiring Software Independence in VVSG 2007: STS Recommendations for the TGDC

    Draft Voter Verified Paper Records: Issues and Recommendations

    Draft Wireless Issues

    Draft Open Ended Vulnerability Testing of Voting Machines

    Draft Access Control Requirements

    Draft Set Up Validation Requirements

    Draft Cryptography Requirements

    I tried posting the individual links for the documents but WordPress silently ate it. Maybe they’ll show up later :)

  19. “Oregon does all its elections by mail now and has had good experiences.”

    Logistically they’ve had good experiences—it’s been cheap, convenient, and easy. But security-wise, vote-by-mail is terrible. It doesn’t even possess the secret ballot property, since family members can casually watch each other fill out ballots.

    In a way, vote-by-mail is like DRE voting: both are attempts to solve logistical problems of voting, and both discard some basic element of ballot security in exchange for ease of use.

    We won’t wonder “what were we thinking?” about DRE machines, because we already know exactly what we were thinking: we were thinking, let’s fix the whole mess of butterfly ballots and tiny print, let’s make voting easy and obvious, and we completely forgot that an election is a security problem.

  20. from Letter to the Editor:

    Recently, the National Institute of Standards and Technology concluded that electronic voting machines cannot be secure. This conclusion is just plain wrong-headed.

    A proprietary electronic voting machine, known as a DRE, contains software that cannot be subjected to public scrutiny. Such a machine, by definition, precludes a vote count that protects the voters’ right to vote. Furthermore, such a machine, by definition, will create a risk that the vote count might be altered or manipulated without human detection. This intolerable risk is framed by some as a challenge. It is proclaimed that the public must provide conclusive evidence that such intolerable risk be demonstrated before corrections will be made. Otherwise, such intolerable risk must be accepted by voters, without recourse.

    The NIST report has not been allowed to stand on its own merits. Continuing addenda are being created in order to lessen the truth of the document, until, of course, discussion about the fallacy of our present electronic voting efforts is washed away, and those who truly believe our right to vote has been replaced with a secret vote are left with no more affirmation of the issue of our right to vote than what we had before the NIST report was issued.

    The issue of proprietary electronic voting machines is not about being made secure. The issue of proprietary electronic voting machines is about voters being able to subject the machines to public scrutiny. If the software used in the electronic voting machines was open to public scrutiny, the intolerable risk that the vote count might be altered or manipulated without human detection is diminished dramatically. In such a circumstance, would the voters’ right to vote be protected to a level that is tolerable? Maybe.

    As it stands, now, the NIST report does not address the issue that is before the voters. It does seek in a weak and apathetic way to absolve itself from further discussion of the issue, with or without additional poisonous addenda. To address the issue, directly, it is readily apparent that the options open to discussion are simple. Either accept a secret vote count, using the present proprietary certified electronic machines that do not permit public scrutiny, or don’t vote.

    If the next election were to be boycotted by voters, what would result? The governments holding the election, i.e., local, state and federal governments, would have to fix the problem, and hold another election. Fortunately, for most of the country, this would be tolerable. The continuation in office of present elected officials would not be devastating. We would officially be a country without fair elections. We would also be a democracy voicing its petition to our elected officials, who, by virtue of not having been elected, are governing without consent of the People.

    The other option is to vote in the next election on proprietary electronic machines that guarantee a secret vote count. How foolish do those who stand in lines to vote in an election that holds a secret vote look?

    In Australia, at least for a couple of elections, the Elections Commission required that all electronic voting machines utilize software that was subject to public scrutiny. The stated purpose of the requirement was to protect the voters’ right to vote. The voters of Australia were willing to accept a dramatically reduced risk of altered or manipulated vote count. Are we? Why don’t we simply download their freely available software that costs nothing, modify it to meet our needs, and resolve the inherent risk now attended by proprietary electronic voting machines?

    In our country, we have developed an industry devoted to discussion of an issue as to whether voters have lost their right to vote, or not. It’s time to shut that industry down, before it becomes institutionalized. It won’t happen, unless we, the voters, understand that our right to vote belongs to each of us, not others. Please consider boycotting the next election, and let’s resolve the issue, once and for all. My right to vote has been taken away. I want it back. Do you?

  21. avatar the_zapkitty says:

    Unfortunately adopting open source code for the machines, assuming the voting machine corporations all don’t expire of apoplexy at the thought, will only mitigate one area of the problems with e-voting machines. It does not fix the other serious problems with e-voting tht have been discussed here and elsewhere.

    And you’d still wind up having to jump through hoops in attempts to ensure that the software on the machines is the software the voters approved… and you’d still have to have a paper ballot trail to ensure checking.

    In this instance it might be a case of the Australians having implemented e-voting in a much more sane fashion than we did after seeing how we screwed it up… but in turn we now know some of the other drawbacks to e-voting via bitter first-hand experiences they have not had… yet.

  22. avatar Ned Ulbricht says:

    The Preliminary Core Requirements Reports section contains a Discussion Paper on Coding Conventions and Logic Verification. Coding conventions are discussed in terms of the readibility of complex systems, for the purposes of verification.

    On p.3, under section 5.1, the discussion draft contains the paragraph:

    The requirement most likely to stir controversy is the requirement to use block-structured exception handling, which in turn requires the use of a programming language that supports it. This rules out the C language, which remains in wide use, and forces a migration to a descendant language, namely C++, C#1 or Java. Similarly, older versions of Visual Basic that lacked block-structured exception handling are superseded by Visual Basic .NET.

    Does this requirement to use block-structured exception handling rule out the use of Verilog or VHDL?

    Is there no requirement to verify anything at that level?

    Of course, if “software independence” (complex system independence) is adopted, that may be a reasonable cost-cutting measure….

  23. avatar Ned Ulbricht says:

    Arggh… blockquote ending tag problem again…. Here’s a clean version:

    The Preliminary Core Requirements Reports section contains a
    Discussion Paper on Coding Conventions and Logic Verification. Coding conventions are discussed in terms of the readibility of complex systems, for the purposes of verification.

    On p.3, under section 5.1, the discussion draft contains the paragraph:

    The requirement most likely to stir controversy is the requirement to use block-structured exception handling, which in turn requires the use of a programming language that supports it. This rules out the C language, which remains in wide use, and forces a migration to a descendant language, namely C++, C#1 or Java. Similarly, older versions of Visual Basic that lacked block-structured exception handling are superseded by Visual Basic .NET.

    Does this requirement to use block-structured exception handling rule out the use of Verilog or VHDL?

    Is there no requirement to verify anything at that level?

    Of course, if “software independence” (complex system independence) is adopted, that may be a reasonable cost-cutting measure….

  24. avatar i have no name says:

    Boo you suck

  25. avatar i have a name says:

    umm that guy before me is right you guys really do suck… Hey did you ever see that show family guy? oh man that is like the funniest show ever i was watching a deleted scene the other day and it was about the outsiders and stewie was johnny and cris was pony boy and stewie says in a weak voice “ponyboy, just remember the socs there people too. and cris says JOHNNY