NIST STS Subc. Report: DOES IT MEAN the death of the machine?

What do you all make of this? It seems that had NIST's STS committee followed its own principles it would not have endorsed VVPAT except in the most qualified way.

The NIST report by the STS subcommittee just realeased around November 30, 2006 specifically doubts that improvements in computer software can lead to increased correctness and accuracy, stating in its Section 7 on Conclusions:



The only way NIST's STS subcommittee can see to try to rescue computers from this fate is the notion of "software independence" that it ballyhooes in this report, i.e., making the software so irrelevant that it can't affect the election result.

This "SI" or Software independence is defined in twin tests as essentially "not relying on complex technology" "or software" of any kind and also the inability of a malicious code introduction to change the election result. Even if these standards are met "this does not obviate the need for thorough testing" of election computers...

NIST claims this SI test is met because of recounts of paper trails or ballots will result in software mistakes or malicious code being "caught". That's a huge assumption.

Here's where NIST gets it wrong: NIST says VVPAT or paper ballots in opscans rescue the computers and make them SI because they are recountable, and thus malicious code won't change the result, reasons NIST.

But in reality, the paper ballots are recounted so rarely, surely less than 1% of all races, that it is erroneous in the extreme to suggest that malicous code can not affect the election result, a required element for the SI status that NIST's STS committee considers to be the only way around the fatal flaws of computers. For example, there is often a high price tag placed on a recount or audit, such as $150,000 in a recent congressional election in San Diego. For this and many other reasons, recounts and even required audits don't happen as they should.

But in the final analysis we have this: A true recount must be by a different method than the original count, and is therefore usually a hand count in the end. (it would seem unlikely to go from DRE to opscan)

IN ORDER TO MEET THE NIST STS RECOMMENDATIONS, THERE WOULD HAVE TO BE 100% RECOUNTS BY HAND IN ALL RACES, TO MEET THE SOFTWARE INDEPENDENCE TESTS.

But then in that case we'd have all the labor of HCPB, except we'd have this ridiculous technological superstructure designed to be "independent" or basically irrelevant. Alternatively, a proper "audit" might possibly satisfy NIST, but the requirement is that there be NO inaccuracy from malicious code, so an audit with any margin of error would not seem to allow that test to be met.

If STS of NIST is followed, the principles are bringing us inexorably to HCPB, it's only the admitted ignorance of STS as to the election law (they pretty much admit as much to limitations in this area and even say they volunteered as pollworkers to learn a little more about elections...) that prevents them from fully realizing that, as a practical matter, their Software independence tests can not be met in real life without building a HCPB system on top of a expensive computer skeleton, or an extremely robust and super-accurate "audit" without a margin of error, if such a thing actually exists.

It would appear to be a battle between HCPB, understandable by the average voter, vs some kind of super duper incredible audit. If anyone thinks its hard to do HCPB in every jurisdiction, how do we do some kind of super sophisticated audit in Podunk, Idaho and every other place in america? Are we sure we won't have some expert shortages in some areas relative to others??

---Paul

on edit: The citation above is incorrect. Sorry, i cited paragraph 7 of the new NIST report when it is instead paragraph 7 of a report from July 2006 that the new NIST report "builds on" and essentially incorporates by reference into the new NIST report. The earlier report from which I quote lays out the definition of SI in far more detail, and is called "On the Notion of Software Independence in Voting Systems." The new NIST report "Builds on" the report specifically on SI as stated in footnote 2 of the new NIST report.

Doesn't software independence mean technology can't be trusted? Essentially?

We are still going to be software-dependent for the foreseeable future.

You can thank the elections officials on the EAC's Technical Guidelines Development Committee and of course the usual vendor shills.

They will have us voting wirelessly and via the Internet soon if we don't pass a bill to prevent that.

Have you written your Congress Critter yet?

<http://computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005632>

It strikes me that the logic on this thumbs down was because the "paper trail" is produced down stream of the "electronics". Is this incorrect?

<Snip>

The proposal, advanced by NIST staff and TGDC member Ronald Rivest, a computer science professor at the Massachusetts Institute of Technology, would have required "software independent" DREs with some kind of independent audit mechanism, such as the voter-verified paper trail printouts advocated by some e-voting critics.

One advocate of paper-trail audits for DRE said he was disappointed with the TGDC's vote


...and thank you BB for your interpretive post on the NIST white paper in Brad's thread the other day.

The software independence part refers only to the ability to count (i.e., audit) the paper independently of software. This is NIST's definition -- not mine. But all that is moot if the TGDC (which was created by HAVA) does not support NIST's recommendations.

"I'm not sure that we've really proven that the processes that state election officials have used for a few decades now of testing and verifying that the systems work ... are failing," said Paul Miller, voting systems manager at the Washington state Secretary of State's Office. "Now we're adding another requirement."

I guess all politics is local huh?

in their "Procedures"

HAVA and the EAC
appointed by Bush


U.S. Election Assistance Commission
Public Meeting Agenda

1225 New York Avenue, NW
Suite 150
Washington, DC
Thursday, December 7, 2006
10:00 AM – 3:30 PM EST
http://www.eac.gov/Public_Meeting_120706.asp

new business

Review and Adoption of EAC Certification Program (Brian Hancock,
Director, Voting Systems Certification, U. S. EAC and Gavin Gilmour,
Deputy General Counsel, U. S. EAC)





Mr. DeGregorio is nationally renowned in the elections field. His areas of expertise include U.S. election administration, democracy building, and international elections.
Prior to his appointment with EAC, Mr. DeGregorio served as Executive Vice President and Chief Operating Officer of the International Foundation for Election Systems (IFES), a leading institution involved in the promotion of democracy worldwide
http://www.eac.gov/degregorio.asp?format=none

It will now just take some time to migrate to software independent systems through attritution of the software dependent machines. Much more work to do, but at least that is my read.

http://computerworld.com/action/article.do?command=viewArticleBasic&articleId=9005632

Government rejects e-voting paper trail proposal
Government, banking officials claim it's not necessary

December 04, 2006 (IDG News Service) -- A U.S. government board looking at ways to improve the security of electronic voting has rejected one proposal that would have required election officials to use paper-trail ballots or other audit technologies with the machines.

The Technical Guidelines Development Committee (TGDC), an advisory board to the U.S. Elections Assistance Commission (EAC), on Monday failed to pass a proposal to certify only those direct record electronic (DRE) machines that use independent audit technology. Before the 6-6 vote, TGDC members expressed concerns that a requirement would create a costly mandate to local governments.

TGDC members said they will continue debate on ways to improve e-voting security. The TGDC could bring the proposal or an amended one back up at any time, said Michael Newman, a spokesman at the National Institute of Standards and Technology (NIST), the agency that helps the TGDC develop voting standards.

The proposal, advanced by NIST staff and TGDC member Ronald Rivest, a computer science professor at the Massachusetts Institute of Technology, would have required "software independent" DREs with some kind of independent audit mechanism, such as the voter-verified paper trail printouts advocated by some e-voting critics.

One advocate of paper-trail audits for DRE said he was disappointed with the TGDC's vote. The recommendation was a "much-needed step toward making certain that voting systems are secure, useable, and reliable," said Eugene Spafford, chairman of the U.S. policy committee at the Association for Computing Machinery (ACM).

"Software independence avoids reliance on the accuracy and security of the voting machine software in order to verify an election outcome," Spafford said by e-mail. "The ... initial recommendation was well-grounded, carefully balanced, and addressed an issue that is critical to the integrity of our election process."

Rivest and NIST staff members argued that there's no way to recount elections in which DREs were used without an independent audit mechanism, repeating e-voting critiques in a draft e-voting security white paper circulated last month.

"Simply put, the DRE architecture's inability to provide for independent audits of its electronic records makes it a poor choice for an environment in which detecting errors and fraud is important," the NIST paper said.

But advocates of the software independence approach aren't accusing DREs of being insecure, Rivest said. "What we're saying is we can't tell if they're secure or not," he added. "We don't know how to create requirements to tell if they're secure."

Other committee members said the proposal created new problems, including new requirements for local governments that have already spent their funding from the U.S. government to update election equipment.

"I'm not sure that we've really proven that the processes that state election officials have used for a few decades now of testing and verifying that the systems work ... are failing," said Paul Miller, voting systems manager at the Washington state Secretary of State's Office. "Now we're adding another requirement."

Rivest argued that nearly all software contains bugs, and voting officials shouldn't rely on imperfect software. "When students write software, it's buggy," he said. "When I write software it's buggy."

But Brittain Williams, representing the National Association of State Election Directors, said the U.S. banking industry has largely figured out how to conduct large-scale electronic transactions with few mistakes. "You say all software is buggy," he said. "The question is, can you test it to an acceptable list of security? The banking industry ... moves billions of dollars around every day with this buggy software without ever producing a single piece of paper."