Navigation
Topics
Log In
Log Out
:
Special Search
New Today
New This Week
Advanced Search
Tree View
Your Account
Edit Profile
Register
Forgot Password
Tools
Help/Instructions
Policies
CLICK STATE TO SEE:
"WATCH LIST"
Marked with: 
"OPEN & HONEST"
Marked with: 
...
|
| 12-20-05: California 'Hack' test stal... |
|
| Author |
Message |
    
BBV Admin
Board Administrator
Username: Admin
Post Number: 3006
Registered: 12-2004
Best of Black Box? 
Votes: 20 (A keeper?) | | Posted on Tuesday, December 20, 2005 - 5:33 pm: | 
|
BREAKING -- California Secretary of State Bruce McPherson has laid a subtle and elegant trap.
Today, California threw Diebold Election Systems’ pending certification into a tailspin, using Machiavellian logic designed to cast doubt on the federal testing lab process, the upcoming HAVA deadline and Diebold voting systems simultaneously (while standing neatly aside to watch the house of cards collapse).
This move follows on the heels of a devastating hack demonstration by Harri Hursti sponsored by Black Box Voting, which took place in Leon County, Florida on Dec. 13. This hack manipulated memory cards by exploiting design defects and Diebold's customized "AccuBasic" program code.
Here's how the California trap works: In a terse letter to Diebold, State elections chief Caren Daniels-Meade writes,
"Unresolved significant security concerns exist with respect to the memory card used to program and configure the AccuVote-OS [optical scan] and the AccuVote-TSX [touch-screen] components of this system because this component was not subjected to federal source code review and evaluation by the Independent Testing Authorities (ITA) who examined your system for federal qualification. It is the Secretary of State's position that the source code for the AccuBasic code on these cards, as well as for the AccuBasic interpreter that interprets this code, should have been federally reviewed.
"…we are requesting that you submit the source code relating to the AccuBasic code on the memory cards and the AccuBasic interpreter to the ITA for immediate evaluation. We require this additional review before proceeding with further consideration of your application for certification in California."
And herein lies the trap. Federal testing authorities are supposed to rely on standards set by the Federal Election Commission. The FEC standards prohibit "Interpreted code" – thus, the AccuBasic "interpreter" is illegal. (The entire AccuBasic source code tree is written in a home-brewed language that Diebold programmers made up themselves, making it more difficult for certifiers to examine.)
The Hursti memory card attack demonstrated in Leon County Florida manipulated the voting system by passing code through -- drum roll please -- the Diebold interpreter, using a set of programs called AccuBasic which was written in a concocted computer language and (now it is revealed) was never examined at all by federal testing labs.
The ITA dilemma: ITAs have the choice of either recommending code that explicitly violates FEC standards (placing an unsupportable liability burden on them) or admitting that the original certification was defective. If the ITAs retract their recommendation, it will effectively strip Diebold of its federal certification, and may also affect its older products.
The Diebold dilemma: Diebold can refuse to submit its code to the ITAs, but that will lose the state of California, continuing a pattern initiated last week when two Florida counties dumped their Diebold machines. Alternatively, Diebold can submit its code and watch as the federal authorities sever their product line from the U.S. market.
The position is made more unstable because Diebold is now fending off stockholder suits by an armload of attorneys piling on to solicit clients for a voting machine-related securities fraud lawsuit.
California Secretary of State letters to Diebold Election Systems:
http://www.bbvdocs.org/legal/Dumpty1.pdf and http://www.bbvdocs.org/legal/Dumpty2.pdf
Something terribly wrong has happened here
American citizens have been commenting on the unacceptable performance of the ITAs since before Black Box Voting was incorporated in 2004.
In November 2002, Dan Spillane (a former senior test engineer for VoteHere) met with Black Box Voting founder Bev Harris.
"It’s a house of cards," he said, showing her stacks of bogus ITA reports. "The bottom card is the certification process." Spillane says he flagged more than 250 system integrity errors in the touch-screen system he evaluated, yet the system passed every level of certification. He was terminated by VoteHere, he sued, and the case was settled by VoteHere with details kept confidential.
Here are writings by computer programmer Jim March on this subject: "The Federal testing process was subverted multiple times by Diebold staff…we’re going to need to study the Federal certification process, in public."
http://www.equalccw.com/lewisdeconstructed.pdf (Date 9/23/2003; Jim March)
Bev Harris's book, Black Box Voting, took the ITAs, NASED and the state examiners to task: http://www.blackboxvoting.org/bbv_chapter-6.pdf(Date 10/10/2003; Bev Harris). Harris published interviews with state voting machine examiners exposing slipshod state certification that relies on the flawed premise of strong federal certification: http://www.blackboxvoting.org/bbv_chapter-9.pdf(Date 10/15/2003)
A Riverside (Calif.) computer programmer Jeremiah Akin writes of ITA failure during testing of Sequoia voting software: "Failure of certification process to catch major security flaws in software:…Riverside has run elections on software that was later found to contain major security vulnerabilities that were not spotted in the certification process."
http://www.exit.com/RiversideVoteTest/letters/response_to_mudslinging.pdf
(Date 2/29/2004; Jeremiah Akin)
Black Box Voting published ITA reports from Ciber Labs for Diebold showing that "penetration tests" (security evaluations) were marked “not applicable” and "not tested."
http://www.bbvdocs.org/general/ciber-reports.zip
(Date: Oct. 17, 2004; Black Box Voting, Inc.)
Susan Pynchon, an ordinary citizen who now runs the Florida Fair Elections Coalition, wrote this analysis demonstrating a breakdown in Florida's state certification process:
http://www.bbvdocs.org/general/FFECreport.pdf(Date July 11, 2005; Susan Pynchon)
Ordinary citizens led this investigation, gathering momentum and evidence nationwide, resulting in the Thompson and Hursti security tests in Florida, culminating in the California Secretary of State ordering Diebold and federal testing labs to go clean up their room (while neatly diverting attention from state-level certification failures).
And now, a word from one of our forefathers
"There is only one force in the nation that can be depended upon to keep the government pure and the governors honest, and that is the people themselves. They alone, if well informed, are capable of preventing the corruption of power, and of restoring the nation to its rightful course if it should go astray. They alone are the safest depository of the ultimate powers of government."
-- Thomas Jefferson
PERMISSION TO REPRINT GRANTED, WITH LINK TO http://www.blackboxvoting.org
P.S.: Thank you, from all of us at Black Box Voting, for the courage of Dr. Herbert Thompson and Harri Hursti to tell it like it is. And more: Thank you to our still-protected source, "Cape Cod," who identified the GEMS defect and the strangeness of the accubasic code back in June, 2003. You know who you are. And thank you to the "swarm" -- all of you -- the swarm that unscrupulous vendors have been unable to behead. |
John Reilly
Voting Rights Forum Participant
Username: Occam
Post Number: 1
Registered: 12-2005
Best of Black Box? 
Votes: 2 (A keeper?) | | Posted on Tuesday, December 20, 2005 - 7:48 pm: |
|
I think that you are overly optimistic. The Sec says in the AP story that it is a "unique case." (Google for the AP story or see http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2005/12/20/state/n174200S20.DTL). "A unique case" signals neither a problem nor urgency. "Unique case" is very close to "an anomoly."
Further, I'll tell you what Diebold will do. It is neither of the outcomes you cite above. Diebold will say, like they did in NC, that the Sec wants them to submit Microsoft's OS. They will insisist that their code is dependent on Microsoft's. Perhaps they will even try to ask Microsoft to submit their code, just as a tactic to delay the process. And, they will quote the secretary that it was a "unique case."
Meanwhile, sales will continue. The Diebold machines that are out there will stay out there, because elected officials will not admit that they were wrong, unless you can give public officials repeated evidence that they were deceived.
Quite frankly, I'm disappointed. I thought you were going to sue for access to all of Diebold's machines in CA, and other states. There is simply too much at stake for Diebold for it to go down becasue of this. You suppose they will implicate themselves in fraud? You will have to sue eventually, as Diebold drags its feet. Why don't you get it over with? Access is what you need, not just in Florida, but repeated access.
To end with a joke:
A a physicist, a engineer and a computer scientist conduct a test on safety. They strap a man to a board and release the board down a flight of stairs. The man crashes into a wall at the bottom of the stairs and dies.
The physicist says, "He gained alot of speed and hit the immovable object with great speed, the test failed and cannot succeed because of the laws of nature."
The engineer says, "The board should have had a breaking device, the test failed, and will need modifications to succeed."
The computer scientist says, "Let's put another man in the board and do the test over again, and see if the same thing happens."
- I would argue that there is an even greater need to prove again, and again, Diebold machines insecure. It may be self-evident to you but, in this case, one must prove the obvious. |
BBV Admin
Board Administrator
Username: Admin
Post Number: 3007
Registered: 12-2004
Best of Black Box? 
Votes: 1 (A keeper?) | | Posted on Tuesday, December 20, 2005 - 8:03 pm: |
|
John: Thanks for your insights, and you may be right that this is overly optimistic.
However, this particular situation is entirely unrelated to the North Carolina situation.
This is a defect in the architecture of the (non-Windows, fully proprietary Diebold-created) embedded system used in the Diebold memory card structure.
This is a subtle and elegant development. It forces fiduciary responsibility on the ITAs to put in writing their analysis of the non-standard home-brewed accubasic programs, along with their FEC-noncompliant interpreter. Since they are federal, their findings apply nationally. They can only endorse this architecture or recommend that it not be certified.
Microsoft is not a related issue, in this case.
My favorite quote from the above article:
"This is a unique case in which we discovered that the source code had never, ever been reviewed," said Kerns. "There were potential security risks with it."
Uh, raising my hand here...the source code was in plain view in the main source code tree. Why did they "forget" to review it -- never, ever, reviewing it at all?
By the way, this source code uses a nonstandard computer language which Diebold made up. Similar to C++, but different. (German is similar to English, but different. If regulations say you must write something in standard English, you can't use German, sorry.)
Bev Harris |
Samuel Scharff
Voting Rights Forum Participant
Username: Abacus
Post Number: 27
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 20, 2005 - 9:59 pm: |
|
Striking!
Would appreciate views on another aspect that's bothered me for months...
We have thousands of machines in service, nominally 'qualified' but essentially unexamined.
Is there any way to recall the lot?
Abacus
|
BBV Admin
Board Administrator
Username: Admin
Post Number: 3013
Registered: 12-2004
Best of Black Box?
Votes: 1 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 5:38 am: |
|
Product recall is an appropriate remedy. Unfortunately, many public officials seem blind to the fact that purchase of defective voting systems is no different than purchase of a defective fleet of trucks, from a product liability standpoint. It is up to the vendor to make them whole again.
Further, the vendor, Diebold, continues to lie. Just this week Diebold's Mark Radke and David Bear persisted in telling the press that Harri Hursti was given the passwords.
No passwords were provided and he was banished outside the room during the testing, preventing him from touching any machine during the election. |
Karla Bean
Voting Rights Forum Participant
Username: Cleanbean
Post Number: 66
Registered: 01-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 5:47 am: |
|
Maybe the SoS's office doesn't want to take a chance that, when you proved Diebold hackable using actual California machines, it might provide the impetus for a judge to grant you access to the actual memory cards from the election - where you might actually find proof of election fraud occurring. Maybe he truly isn't aware of any fraud, but doesn't want to find out there was during his watch. |
Edward Robles
Voting Rights Forum Participant
Username: Tedeger
Post Number: 20
Registered: 11-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 6:14 am: |
|
Middling good news - but I don't see the Calif. SoS inviting BBV to come take a hack at the machines - is that still in the works? Knowing the smarmy way Diebold has operated all along, I wouldn't be surprised if they withdrew from Calif. altogether, rather than allow their machines to undergo a real world test. |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 307
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 6:45 am: |
|
Wyle Lab DID perform a source code examination of the AccuBasic interpreter. This is in the Appendix of the both Wyle reports submitted to the State of Wisconsin. As a matter of fact the source code files are listed in excruciating detail.
The finding was the source code as written conformed to VVSG development standards.
What the ITA's failed to ask was the obvious question: If interpreted code is prohibited, why does the system have a code interpreter?
John Washburn
Only bad software is delayed by good testing.
|
BBV Admin
Board Administrator
Username: Admin
Post Number: 3014
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 7:45 am: |
|
John --
I saw the Wyle lab code examinations (much redacted). Now I need to go look again. I noticed the code line entries, but have been so up against the wall that I haven't examined the peripheral information to see if they describe the source code they examine in terms of "accubasic" etc.
It is very interesting that they seem to be withholding the release notes portion of the examination even from the state examiners.
--- Bev |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 308
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 7:56 am: |
|
What you are looking for (and this is from memory as my copy is at home 90 miles away) is after the hundreds of pages of redacted fluff.
One of the appendices of each Wyle reports have is a listing of souce code examined broken out by directory.
A typical entry would be:
\AccuBasic\
parsetree.cpp 1/14/2005 1.27 AF3723C9
where AF3723C9 is the CRC-32 for the file contents. The other entries on the line are Name, date, and revision number
Damn why don't I carry those 626 pages whereever I go. 
John Washburn
Only bad software is delayed by good testing.
|
John Reilly
Voting Rights Forum Participant
Username: Occam
Post Number: 2
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 10:05 am: |
|
I’m not sure what is going on with BBV and the CA SOS is clear. On Dec. 9, BBV cited California Elections Code Section 19202 as the basis for its right, without undue delay, to examine the voting machines. Has the CA SOS responded to BBV’s request?
Is he trying to squirrel out of it? To quote from the BBV Dec. 9 letter, 19202 states, “Any person or corporation owning or being interested in any voting system or part of a voting system may apply to the Secretary of State to examine it and report on its accuracy and efficiency to fulfil its purpose. The Secretary of State shall complete his or examination without undue delay.” De-certification of the machines makes them de-certified parts of the voting system. However they are still part of the voting system in that they are owned by CA, and presumably will be certified by a body outside the CA gov’t. So, this recent action by the CA SOS cannot abrogate the responsibility of the SOS to carry out 19202. At the time of the request, the machines were certainly part of the CA system. Where does this leave BBV’s request for testing? Is there any part of the law that defines “voting system?”
(Additionally, I would like to point out that the shareholders lawsuits also have nothing whatsoever to do with BBV, and little to do with the voting machines. For instance, one lawsuit states, “Diebold's election machines continued to have severe problems that would hurt the Company in the future due to adverse publicity and reduced sales.” Note that the claim does not state the problems with the election machines are hurting the company now or have hurt the company: Diebold's machines are still selling very well. This is not a damage claim. Damages are not awarded on speculation of what “would hurt the Company in the future.” So, this claim is likely to be thrown out by a judge.
The plaintiffs also will not be able to test the machines as part of the suit. The judge will not allow this testing during a trial because it would only serve to introduce the idea of potential future damage. A damage claim is a past event, not a potential event. The plaintiffs put these allegations in their suit, because if, during the course of the suit, Diebold's machines were proved to be unreliable, they could then introduce the outside evidence of unreliability, if and only if, the stock dropped because of this outside evidence. They would then be able to expand their legal claim.
So, these lawsuits are neither good news or bad news for BBV. Actually, because the claim that Diebold’s election machines is likely to be thrown out by a judge [again, damages are impossible to prove at this time], there is a potential that if the claim is thrown out because of lack of evidence, Diebold’s machines will be seen as being more secure than they actually are.) |
BBV Admin
Board Administrator
Username: Admin
Post Number: 3015
Registered: 12-2004
Best of Black Box?
Votes: 64 (A keeper?) | | Posted on Wednesday, December 21, 2005 - 11:01 am: |
|
I’m not sure what is going on with BBV and the CA SOS is clear. [19202 request]
An elegant minuet has been going on behind the scenes. At the moment, nobody is stepping on anyone's toes and we like the music very much.
"...will be certified by a body outside the CA gov’t.
You misunderstand. It was ALREADY recommended for certification by the testing labs, and it has ALREADY been federally certified. What California did was call the federal testing labs on their negligence and send all the kids back to clean up their room before California will let them come out and play.
So, this recent action by the CA SOS cannot abrogate the responsibility of the SOS to carry out 19202.
That is correct. However, by taking a short breather to force the federal testing labs to put in writing their examination of a program that violates the standards to which they test, California does something very nice: They potentially put the whole thing in play nationwide, and also potentially take out the older machines.
If the federal ITAs revoke their recommendations, NASED has to revoke its certification. If NASED revokes its certification, California can't certify. Then all that remains is what to do about the old systems that have been in use.
"(Additionally, I would like to point out that the shareholders lawsuits also have nothing whatsoever to do with BBV, and little to do with the voting machines.
That is partially correct. Black Box Voting discussed a stockholder's lawsuit while in Boston some time ago, with a voting integrity action group there. That group went so far as to locate a stockbroker willing to do small buys to give standing. However, Black Box Voting is an educational nonprofit, not a corporate raider, and it would be inappropriate for us to involve ourselves as plaintiffs. We have been contacted by attorneys involved in the class action suit, and we will provide evidence if and when it is required. The way class actions go, first they collect plaintiffs and then they go into discovery after merging all the actions into one. We've been assembling evidence for years, and at the appropriate time we'll be happy to turn it over to authorities or attorneys as needed, as we always have.
Some of the lawsuits do blame the company for failing to warn investors of known flaws in its voting machines. As we have pointed out at this site, the problems with its ATM division seem to be most culpable in the stock price dropping. However, note that Diebold represented to its investors that they expected to make "$1.5 to $2 billion" on selling voting machines. That was an idiotic claim that shows they did not do proper due diligence, or failed to disclose what they knew.
"Diebold's machines are still selling very well.
The figure Diebold was shooting for was $2 billion. I don't think they've even hit a quarter of that, nor will they. You call that "selling very well?" Our contacts with counties indicate that they are practically giving them away now.
"Diebold ... could then introduce the outside evidence of unreliability, if and only if, the stock dropped because of this outside evidence.
Or failed to accumulate value as projected. Or failed to perform because they didn't tell what they knew. When Diebold agreed to pay the state of California $2.6 million for making false claims, as I recall, the stock dropped five percent in a single day. Diebold is STILL liable on false claims acts, for up to treble damages on some $300 million in false claim voting machine sales. That's nearly a billion in damages. Damn dangerous, if you ask me.
So, these lawsuits are neither good news or bad news for BBV.
The lawsuits hamper Diebold's ability to maneuver. Clearly, what happened is that Diebold acquired a rogue company and didn't get control of it. If I was to guess what might happen next, I'd think they may spin off the elections division under a third party's management to clean it up, retaining options to buy it back when it knows how to behave properly.
Actually, because the claim that Diebold’s election machines is likely to be thrown out by a judge [again, damages are impossible to prove at this time], there is a potential that if the claim is thrown out because of lack of evidence, Diebold’s machines will be seen as being more secure than they actually are.)
When it comes to judges, you never know what they're going to do. Bribe a clerk and you get nice judge assignments. Then again, you might pull a free thinking maverick, or someone who plans to run for office, or a guy who is actually fair and balanced. The winner is often the one who has the best lawyer, not the one who has the best case. A lot will depend upon which law firm ends up running the combined class actions.
I'm not particularly impressed with admonishments that doing something might damage something else. Great things are not achieved by sitting there doing nothing, hoping someone else can pull out a magic wand. I take my hat off to everyone involved in the stockholder's lawsuit. For our part, we will continue to press forward with actions on multiple angles. I know for a fact that other activists all over the country are taking unexpected and independent actions of their own.
That's what's meant by the term "swarm." It is the single most effective way to deal with abuse of power and corporate malfeasance there is. Lots of ordinary people doing what makes sense to them, loosely allied but not particularly coordinated. Impossible to behead the swarm, very difficult to figure out what to watch for next.
Bev Harris |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 310
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, December 22, 2005 - 11:44 am: |
|
RE: Wyle Lab DID perform a source code examination of the AccuBasic interpreter.
I was wrong there is no documentation the AccuBasic code was inspected. I appologize for my poor reading of this document.
This is actually worse than I stated.
Supposedly, all the source which was used to create the BIN file burned into the PROM. But none of the source modules listed in the WYLE reports (3 of them) have an name which would imply the source is to an interpreter. E.g. Parser.CPP, TokenExe.CPP, or Token.h.
Harri Hursti proved in Leon county there is an interpreter firmware of the OS box for those compile AccuBasic tokens on the memory card.
So where is the source examination for this code in any of the 3 Wyle reports?
Better questions:
Where is the source code for the interpreter? not delivered to ITA's or in file with names that do not call attention to themselves?
If not, delivered then how did the reference build test pass? Creating firmware from the delivered source code if not all the source code was delivered would create a BIN file different than the firmware actually on the chip of the delivered TSx unit.
If all the firmware source was delivered, where is then is the interpretr? Is the interpreter executing under WinCE as a separate EXE/DLL and thus not firmware according to Wyle?
How do you receive the manual for ABasic (listed as appendix J in the TDP listing on page 4 of the Ciber report) and not ask why is this manual here?
How do you execute the elections test (as described on pages 12, 13, 14 of the Ciber report) and not become aware of the ABO file? Especially execute the test step: print report tapes?
[ITA's], you got some 'splaining to do.
John Washburn
Only bad software is delayed by good testing.
|
BBV Admin
Board Administrator
Username: Admin
Post Number: 3022
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, December 22, 2005 - 1:47 pm: |
|
Ay-yi-yi-yi-yi. |
Jim March
Voting Rights Forum Participant
Username: Jimmarch
Post Number: 95
Registered: 01-2005
Best of Black Box?
Votes: 1 (A keeper?) | | Posted on Friday, December 23, 2005 - 1:50 pm: |
|
Wyle Coyotes: Supergeniuses...
 |
Pat A. Vesely
Frequent Voting Rights Forum Participant
Username: Pat_vesely
Post Number: 2038
Registered: 12-2004
Best of Black Box?
Votes: 1 (A keeper?) | | Posted on Friday, December 23, 2005 - 2:06 pm: |
|
Damnit Jim! You owe me a new keyboard!
I've got to learn not to 'sip and surf'.
Thanks for the laugh! (he says wyle wiping monitor off!)
PAV ;-) |
Roy Lipscomb
Voting Rights Forum Participant
Username: Lipscomb
Post Number: 7
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 8:33 am: |
|
From the original message:
'The FEC standards prohibit "Interpreted code"...'
Do you have the URL for this?
Here's my reason for asking:
It's always puzzled me that "interpreted code" is
supposedly illegal. I can't see any particular
reason for such a prohibition.
So I'm wondering if the FEC guidelines read
something like this: "Computer codes, which
require interpretation, are prohibited."
That COULD make sense. Computer techies see a
world of difference between the simple phrase
"computer code" and the phrases "a computer code"
or "computer codes." The former refers to
software, the latter refers to data.
The FEC guidelines might be intended to prohibit
the use of "data codes," which are inherently
ambiguous and require "interpretation" to make
sense.
Thus, "007" usually means "James Bond," but on
a ballot it could just as well be intended to
mean "candidate #7 in the first race" or
"candidate #1 in the fourth race." Or it might
mean nothing more than "ballot #7"!
How could such a slippery item be verified by the
voter?
Compare that to the phrase "James Bond," which
(on a ballot) is unambiguous.
Interpreted computer code, on the other hand,
is a different story.
Whether computer code is interpreted or not
makes little difference to a hacker. It might
make a difference if he is trying to hack
unfamiliar software while the election is in
progress. But it should make no difference to
a hacker who has prepared ahead of time.
A review of the pertinent clauses in the FEC
guidelines will hopefully reveal whether it is
"interpreted data code" or "interpreted
software code" that is under prohibition. |
Marian Beddill
Voting Rights Forum Participant
Username: Uu7thprinciple
Post Number: 2
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 10:06 am: |
|
I can cite circumstances where either of Roy's cases of interpreted code are subject to fraudulent execution - programming code "interpreted" by a compiler, or data code "interpreted" by the program as it arrives, either capable of giving different results depending on the "conditions" it encounters on the fly.
And the greatest risk, imho, is with insiders - either associated with the vendors or the election officials. Back when I was programming in Assembler language, one of the great innovations was "smart programs", which "learned" from the data that ran through it, as people do. Future behavior of the program actions changed, derived from the past datasets it had processed. A typical case (for processing efficiency) would be relegating rare cases to secondary processing, letting more common cases to be dealt with, first.
In interpreted code, the program can change behavior on the fly, thus making its behavior (and the results of its calculations) inconsistent between successive runs, and thus unpredictable.
Not good circumstances for elections. So, whether the Feds rules prohibit interpreted code or not, we should all insist that no jurisdiction allow it.
I wrote a demo that shows how a single ballot can change the tally results when a batch is run, if the program rules are set to recognize a peculiar combination of votes. An insider (vendor or hacker) could set that rule, then implement it via a single voter (paid handsomely?).
See http://NoLeakyBuckets.org
Marian
NoLeakyBuckets.org
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1366
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 11:25 am: |
|
Gosh that would be elegant. Very sneaky. That would mean a particular combination of votes (such as XXX for dogwarden and YYY for school board and ZZZ for leiutenant governor and BBB for governor) could activate a program. And that program itself could change its behavior over time, depending on the votes that come down the line. (E.g., if votes for a certain person exceed 20% they can do one set of things, and when they exceed 30% they can do something slightly different, etc.) Have I understood this correctly from your example?
Something similar could theoretically be used in our very different (Irish) PR-STV elections where we can rank a list of up to maybe 15 or 20 preferences in a single election--it would make it easy to have something such as you suggest, activated by the preferences cast within just one race.
Since I'm not a programmer, let me know if I've understood this properly. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1367
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 11:31 am: |
|
And if I understaood this correctly, behavior such as this could be triggered by interpreted code which is either within a software program (e.g. on the memory card, the individual DRE or scanner, or the counting computer), or within software data that is put into the computer later (e.g. the election data used to set up the election, for example, or even a particular series of votes that could serve as code to trigger the interpreter).
Am I overstating the case here as to what is possible with where interpreted code could reside or how it could be triggered? |
Marian Beddill
Voting Rights Forum Participant
Username: Uu7thprinciple
Post Number: 3
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 12:01 pm: |
|
You have got it exactly. My example - which is downloadable - lets you do exactly that as "a voter".
If one person casts a ballot with exactly two votes - one for the DogCatcher and one for a Senator, that Senator wins. It happens because the program has been taught to respond to such a special case, with an alternate set of tally rules, shifting a determined percentage of votes to the "favored" candidate.
In programming, it is duuuhh-simple to set up. Hiding it would be a bit trickier, but a crafty programmer could accomplish it.
Marian
http://NoLeakyBuckets.org
|
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 311
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 3:25 pm: |
|
Volume I, Section 4.2.2 reads: Self-modifying, dynamically loaded, or interpreted code is prohibited except under the security provision of 6.4.e[sic]. I think the reference is supposed to be 6.4.1.e.
John Washburn
Only bad software is delayed by good testing.
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1369
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, December 27, 2005 - 3:28 pm: |
|
What is the exception 6.4.e (or 6.4.1.e) about? |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 2
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, December 29, 2005 - 8:38 pm: |
|
Catherine Ansbro wrote:
quote:Since I'm not a programmer, let me know if I've understood this properly.
Catherine, you are right, the dirty tricks which you described are possible (in fact, easy). But they don't have anything to do with AccuBasic. These tricks can be done in any Turing-complete (i. e. general purpose) programming language, including so-called interpreted languages, and so-called compiled languages, and machine language.
I said "so-called" above because when computer experts talk about "interpreted versus compiled" they are using a kind of shorthand, a deliberate oversimplification to save words. In truth there is a nearly continuous spectrum of different degrees of compilation. The amount of compilation varies between different languages, and even between different vendors' versions of the same language.
Decades ago there was a clear division: all languages were positioned at one end of the spectrum or the other. But today the division is so unclear that it doesn't make much sense, even as a shorthand. Ask 100 programmers whether Java is "interpreted" or "compiled," and you'll probably get almost a 50-50 split in the answers.
When you start thinking about "interpreted code" and security, the most important thing you need to understand is that, when you get past the shorthand, ALL code is interpreted code. Even if the source language is fully compiled, all the way down to machine language, the compiled code will still be interpreted by the microprocessor. The processor in a Diebold machine (I think it's an 80386) is essentially an "interpreter on a chip." That's true of every microprocessor, not just the 80386.
Every hacker intuitively understands that a microprocessor is the same thing as an interpreter, even though many computer professionals who aren't hackers don't really understand it. I see that Roy Lipscomb, who posted above, has this same intuitive understanding: he was right when he wrote "It's always puzzled me that 'interpreted code' is supposedly illegal. I can't see any particular reason for such a prohibition." and "Whether computer code is interpreted or not makes little difference to a hacker." |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1388
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, December 29, 2005 - 11:30 pm: |
|
Thanks for that explanation, Robert.
How then is one to understand the FEC standards which explicitly prohibit "interpreted code"? (I.e. as opposed to "non-interpreted code" which technically doesn't exist if one looks at all code as being "interpreted".)
I fully accept your point that there is a range of options and that they are actually all vulnerable to being used as a vehicle for tempering. What, then, is the distinction that the FEC was seeking to draw? How might they have intended to discriminate between whether or not a given segment of code is "self-modifying, dynamically loaded, or interpreted" or not?
Does it partly have to do with the degree of transparency of someone looking at the code and being able to accurately assess everything that code does when it is executed?
But if some part of its function is "hidden", how does one know?! And if one believes something is "hidden", doesn't that carry implications concerning motivation? Can one discern whether something was less-than-transparent by design, by accident, or by incompetence?
If this understanding is correct (that it's related to degree of transparency in what the code does), then how clear/unclear is the distinction in the case that's being discussed here: Diebold's use of AccuBasic and/or its use of .abo files on the memory cards? This code seems to be "self-modifying" and "dynamically loaded", and possibly also "interpreted" depending on where one draws the line.
(Message edited by catherine_a on December 29, 2005) |
Ami Silberman
Frequent Voting Rights Forum Participant
Username: Jol
Post Number: 121
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, December 30, 2005 - 9:01 am: |
|
Speaking as a Computer Scientist, I think that although Robert is correct in viewing a microprocessor as an interpreter, the key vulnerability in interpreted vs. compiled code is still valid. To tweak interpreted code just requires someone to edit the program. To tweak compiled code either requires recompiliation of the code, or patching (modifying) the binary file. The problem with libraries is analogous. Dynamically linked libraries (DDLs in the Windows world) are inherently dangerous because modification of the library modifies the execution of the program without having to recompile. |
BBV Admin
Board Administrator
Username: Admin
Post Number: 3052
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, December 30, 2005 - 9:02 am: |
|
Dynamically linked libraries, typo: DLLs. |
James Domenico
Voting Rights Forum Participant
Username: Whyte_rabbyt
Post Number: 1
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, December 30, 2005 - 10:52 pm: |
|
You know where this is taking us? Right back to manual voting, because you will never be able to trust electronic voting, it is just too easy to cheat.
(Message edited by whyte_rabbyt on December 30, 2005)
Been down so long it looks like up to me!
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1399
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, December 31, 2005 - 3:01 am: |
|
Hi James,
I hope this does take us back to manual voting--and more importantly, to manual counting.
At least with manual counting the risks are well known and understood, and many places have already developed best practice security protocols that work, are more efficient, are disabled-accessible, and are more cost-effective.
I'm looking forward to Pat A. Veseley's forthcoming book about manual vote casting and vote counting.
(Message edited by catherine_a on December 31, 2005) |
William Shipley
Voting Rights Forum Participant
Username: Williamshipley
Post Number: 1
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, December 31, 2005 - 11:48 am: |
|
My reading of the regulations is that interperated code is allowed so long as the processor that converts the source to tokens is not present on the system after election day testing (6.4.e)
My belief is that the interpreted issue is a red herring and following it will eventually lead to embarassment. While interpreted code may be slightly easier to hack than compiled code, depending on the file format, compiled code may also be hacked as a practical, not theoretical matter.
People are willing to spend millions of dollars to influence elections. They can clearly hire high quality experts to hack a system. 'Harder' is not a sufficient standard. The executable or interpreted code must be checksummed and verified prior to running. It is equally possible to verify compiled and interpreted code as what you are doing is verifying the integrety of a binary file. |
BBV Admin
Board Administrator
Username: Admin
Post Number: 3058
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, December 31, 2005 - 1:06 pm: |
|
William: And what if the interpreter IS used on the system after election day testing?
Thanks for your insights, and welcome to Black Box Voting.
Bev Harris |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 3
Registered: 12-2005
Best of Black Box?
Votes: 2 (A keeper?) | | Posted on Sunday, January 1, 2006 - 11:58 am: |
|
Catherine Ansbro wrote:
quote:What, then, is the distinction that the FEC was seeking to draw? How might they have intended to discriminate between whether or not a given segment of code is "self-modifying, dynamically loaded, or interpreted" or not?
Catherine, those are good questions. I don't know who originally put those prohibitions in the standard, and I shouldn't speculate about people I don't know, but this is important so I'll make an exception.
When I hear about the prohibition of interpreted and self-modifying code, I get a distinct impression that this part of the standard was probably authored by people who just don't "get" computer hacking: not in the original constructive sense (exemplified by TMRC, the AI Lab, and the Free Software movement) nor in the mainstream media's spurious destructive sense of the word.
It seems to me as if the authors of that part of the standard might have spent half a day listening to some real hackers, and never fully understood what the hackers said, and instead just tried to ban every technique the hackers mentioned.
I imagine the hackers probably would have tried to explain that "secure voting software" is an oxymoron, an impossible fantasy, the modern equivalent of a perpetual-motion machine. They would have advised that the only way to achieve real security would be to educate election officials and voters about the need to treat the computerized tally as what it really is: an unverified hearsay estimate of the election's outcome, provided by a possibly biased third party. In other words: instead of trying to secure the software, count the paper ballots.
The hackers would have reeled off a list of software techniques which are available to any potential tamperer, and which can virtually guarantee the impossibility of electronically detecting a well executed fraud. This list certainly would have included self-modifying code. The authors of that part of the standard, instead of actually understanding what the hackers said, would just try to prohibit every technique the hackers mentioned.
Roy and I already explained why prohibiting interpreted code doesn't help. Now I'll explain why prohibiting self-modifying code is even sillier.
Self-modifying code is a technique which the attacker can use in his own exploit code, not a weakness which makes him smile when he sees it in the victim's code. It isn't like an unlocked door which lets him in; it's more like a handkerchief which he brings along to erase his fingerprints. Prohibiting it won't work, because he simply won't obey the prohibition. Imagine a county where a serial home invader has been hitting people with a club, and the county commission tries to stop his crime spree by banning the possession of clubs. The prohibition won't work, because the criminal won't obey it, and he can make a club in two minutes by breaking off a chair leg or tree branch. Likewise it takes only minutes to create self-modifying code.
The other prohibition you asked about is dynamically loaded code. This one is not silly. In fact, with this prohibition, they have nearly hit the nail on the head. Harri Hursti's exploit was made possible by Diebold's use of dynamically loaded code, not by their use of interpreted code. Without the AccuBasic interpreter, Hursti's exploit would still be possible; but without dynamic loading, it would not. Therefore I think everyone who wants to protest about Hursti's exploit should really be yelling about dynamically loaded code, not about interpreted code.
Not all dynamically loaded code is bad. The problem happens when you have code in one security context, loading code from another security context. This is what Diebold did. Any time you have code migrating between security contexts, you are asking for trouble.
quote:Does it partly have to do with the degree of transparency of someone looking at the code and being able to accurately assess everything that code does when it is executed?
I wouldn't think that that would have been the intent of this prohibition. In fact, code written in an "interpreted" language like BASIC is often easier to examine, and more secure, than the equivalent code written in a "not interpreted" language like C or C++.
quote:But if some part of its function is "hidden", how does one know?!
There are many ways to hide what your code is doing, and it isn't really possible to detect them all. "Obfuscated code" is the trick that gets the most attention, but it's often more effective just to arrange that the code you don't want people to analyze will simply not be included in their copy of the source code. You can do this by sending one version for certification but installing a different version on the voting machines (as Diebold did in 17 counties in California) or by dynamically loading exploit code which obviously has never been seen by the certification authorities (as Harri Hursti did on two occasions).
quote:And if one believes something is "hidden", doesn't that carry implications concerning motivation? Can one discern whether something was less-than-transparent by design, by accident, or by incompetence?
In general, in this kind of situation, if a guy is both evil and incompetent, his incompetence will cause him to leave evidence of his evil intent in the code. But if he is evil and competent, there won't be any clues that would allow you to conclude that he isn't just honest and incompetent. In fact, I can think of an easy trick that would be 100% certain to leave absolutely no indication of evil intent in the source code.
quote:If this understanding is correct (that it's related to degree of transparency in what the code does), then how clear/unclear is the distinction in the case that's being discussed here: Diebold's use of AccuBasic and/or its use of .abo files on the memory cards? This code seems to be "self-modifying" and "dynamically loaded", and possibly also "interpreted" depending on where one draws the line.
When I look at the details of Hursti's exploit I just see an ordinary garden-variety security context gaffe, the kind of thing that happens many times per day in the software business, nothing to get suspicious about. But, as I explained above, if I wanted to open a pathway for election fraud I could easily make it indistinguishable from an ordinary gaffe. So I'm afraid I can't provide any firm conclusion about whether this is evidence of malice or just carelessness.
You know, I wouldn't worry too much about this problem or any of Diebold's other problems, not even about the CEO's promise to swing Ohio's electoral votes, if they had only been honest enough to tell us from the beginning that we need to count the paper ballots. This idea that we don't need to count the ballots is really the mother of all security defects, next to which all the other defects are just trivia.
Think of it this way: if we do count the paper ballots, Hursti's exploit can't really hurt us, because it can't change the paper ballots. If we don't count the paper ballots, fixing Hursti's exploit won't really help us very much, because there are probably ten or twenty or fifty other ways that an insider could change the tally electronically, and we will never find them all.
I think the number one goal has to be what I wrote above:
Educate election officials and voters about the need to treat the computerized tally as what it really is: an unverified hearsay estimate of the election's outcome, provided by a possibly biased third party. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1406
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 1, 2006 - 12:15 pm: |
|
Thanks for those comments, Robert.
Even though closing the security loophole demonstrated by Harri Hursti's hacks wouldn't make systems secure, the demonstration of just a couple of the security vulnerabilities is crucial to getting people to recognize the crucial importance of ALL of the following:
1) requiring a paper ballot for all votes
2) requiring that all paper ballots be counted, by hand, for all elections
3) requiring that a meticulous chain of custody of all ballots be maintained (perhaps we need laws requiring serious repercussions if the chain of custody is not properly documented--such as equating this with election fraud in terms of consequences)
4) election officials, vendors, and voting machine certifiers at any level need to be made personally liable and accountable when problems occur |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 4
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 1, 2006 - 3:16 pm: |
|
Ami Silberman wrote:
quote:To tweak interpreted code just requires someone to edit the program. To tweak compiled code either requires recompiliation of the code, or patching (modifying) the binary file.
Ami, the AccuBasic code on the memory card *is* compiled (it just happens that it isn't compiled all the way down to native code, hence the presence of the interpreter). Hursti's exploit did in fact require him to compile his own code; he even needed to tweak his compiled code with a hex editor. You can search for the string "compile" in the Hursti Report.
I suppose someone could argue that the need for a compiler added some difficulty to the exploit, but I would say the added difficulty was trivial; it sure didn't prevent Hursti from stealing the test election!
quote:The problem with libraries is analogous. Dynamically linked libraries (DDLs in the Windows world) are inherently dangerous
Right. DLLs do not require any interpreter except for the microprocessor itself, so people classify DLLs as "not interpreted" code. Yet the use of DLLs would have allowed the exact same exploit that Hursti used. Any kind of code which can be loaded dynamically, including an ordinary .exe program or .bat script, will allow this kind of exploit.
quote:because modification of the library modifies the execution of the program without having to recompile.
It's not just about whether the attacker will need to recompile; it's about which parts of the system the attacker will need to be able to modify. Hursti only needed to modify the card, because that's where the .abo file was; but if the card had instead contained a .dll or .exe or .bat file, Hursti still would only have needed the ability to modify the card.
I have several little replies, so instead of separate postings I'll just stick them all below.
James Domenico: you are right.
Catherine Ansbro: you're right. Paper ballot fraud can be prevented, often just by having multiple people watching the ballots at all times. This can't be done with software, because people can't watch what happens inside a microprocessor.
William Shipley: I agree, the interpreted issue is a red herring. An even bigger red herring is the whole idea of "securing" the software instead of just counting the paper ballots.
Bev Harris: that's a good question. When people tell you some type of voting machine is "more secure" because an interpreter or compiler is not present, they are making the same kind of specious argument as people who tell you a central tabulator is more secure because MS Access is not present. The alleged security benefit is an illusion, because the attacker can just bring his own tools. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1407
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 1, 2006 - 3:31 pm: |
|
Robert,
I understand and accept the point you are making about interpreted code. The interpreted code issue isn't a red herring if it is successful in getting the systems in use de-certified, and if this is a way to buy time until there can be a more thorough debate about the issues.
It is also invaluable as a weay of generating more public awareness about the fact that serious security vulnerabilities really do exist and that it is not hypothetical. This doesn't mean that so-called "interpreted code" or "dynamically loaded code" are the only serious security risks. But their presence and their proven ability to hack election results will help to wake up the media and the general public to the reality of the existence of these and other risks.
Hopefully this will lead to more discussion about the implications for electronic voting systems in general, and the impossibility of securing them in any workable way. As you put it so well, "people can't watch what happens inside a microprocessor." |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 5
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 2, 2006 - 10:06 am: |
|
Catherine, I agree with what you wrote, except there is one part in the middle which makes me think I may not have explained the technology issue clearly enough.
quote:This doesn't mean that so-called "interpreted code" or "dynamically loaded code" are the only serious security risks. But their presence and their proven ability to hack election results
I wasn't trying to say that interpreted code is only one small part of the problem; I was trying to say that it isn't ANY part of the problem.
Trying to think about an "interpreted code problem" involved in Hursti's exploit, is like trying to think about a "pink car problem" in the asphyxiation of a person who was in a closed garage with an idling pink car. The pinkness of the car just isn't any part of the problem; a car of any other color would have had the same effect. In Hursti's exploit the "interpretedness" of his program wasn't any part of the problem; a non-interpreted program, if loaded and executed from the memory card, would have had the same effect. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1411
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 2, 2006 - 10:18 am: |
|
Ok so can you have another go at defining the problem as you see it? (Other than that no one can observe what a microprocessor does.) Is it possible to speak at all meaningfully of subcategories of threat that could be mitigated against?
E.g., if there were no memory cards at all--would that be better? (not perfect, but better?)
Or are you saying that it's pointless--and a mistake--to even try to identify something that is electronic but "not as bad"?
Some folks like to think that "in the future" we'll come up with some technical solution that will address all the concerns and so we'll have e-voting at shopping malls, post offices, etc. I'm not so sanguine--like you, it comes back to the "can't see what the microprocessor's doing" argument--but this feels hard to get across in such a techno-friendly society. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1412
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 2, 2006 - 10:20 am: |
|
And there are far more techno-vendors than there are hand-counting "vendors".
And you know how it is in our commercialized society--if you don't see constant ads for something, it doesn't exist and isn't worth having. |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 6
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 2, 2006 - 3:44 pm: |
|
Catherine Ansbro wrote:
quote:Ok so can you have another go at defining the problem as you see it? (Other than that no one can observe what a microprocessor does.) Is it possible to speak at all meaningfully of subcategories of threat that could be mitigated against?
OK, here's a quick summary. (1) Interpreted code is not a problem. (2) Self-modifying code is a problem when the bad guy writes it, but we can't remove it from his toolbox just by making rules, as long as there's a general-purpose microprocessor in the machine. (3) Dynamically loaded code is a big problem, especially when the vendor prevents election officials from making informed decisions about appropriate procedures, by repeatedly lying about the fact that there is software on the memory card. (4) Trusting software to safeguard the integrity of the election is a huge problem.
quote:Or are you saying that it's pointless--and a mistake--to even try to identify something that is electronic but "not as bad"?
Computer software can be very helpful, as long as we don't allow it to control the outcome of a election.
Imagine you're a game show team captain, and the question is "How can you get 1147 by multiplying two-digit numbers?". You have a guy who can do this stuff in his head, in seconds, but you don't trust his motivation. He says "It's 31 x 37" but before you say that's your final answer, you multiply it and make sure it gives 1147. The guy solved the problem for you but you didn't have to trust him. That's how we need to treat computers.
quote:Some folks like to think that "in the future" we'll come up with some technical solution that will address all the concerns and so we'll have e-voting at shopping malls, post offices, etc.
It couldn't be anything like today's general-purpose computers. It would have to be a fundamentally different kind of computing device, and it would somehow have to achieve ubiquity and universal trust. My hunch is that any such device would have Orwellian ramifications which we really don't want.
quote:I'm not so sanguine--like you, it comes back to the "can't see what the microprocessor's doing" argument--but this feels hard to get across in such a techno-friendly society.
I don't understand why people would be so trusting. In today's America, how many people still exist who have not yet experienced an infuriating computer problem?
Bev Harris: I didn't understand what you were asking for. Now I understand and can give a better answer. The program which William Shipley called "the processor that converts the source to tokens" is the same program which Harri Hursti called "the compiler" in his report. I would be very surprised if this compiler is ever present on the optical scanner, but not surprised if it's on the central tabulator. You could ask Harri about when and where the compiler is present. |
Bob Fleischer
Voting Rights Forum Participant
Username: Rjf7r
Post Number: 42
Registered: 09-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 2, 2006 - 10:04 pm: |
|
Re "but this feels hard to get across in such a techno-friendly society" -- that's part of the problem, but the other, and I think bigger, problem is that people just don't see any threat. They act as if significant tampering just won't be attempted, can't happen, and would be quickly seen and exposed by the millions of patriotic election workers across the country.
A case in point: that small group with which I've been working drafted a legislative proposal to the Massachusetts legislature. We submitted it to a staff member of the appropriate committee with whom we had been working for months. It was a modest proposal, which mostly banned DREs and required a random sample audit after every election.
Recently we were shown an edited response to our submission. All mention of auditing was removed. There will remain no way to detect sophisticated tampering.
Bob |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1415
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 12:49 am: |
|
This seems to indicate that they really don't want to know whether or not tampering is occurring.
Finding tampering is perceived as such a liability that they'd prefer not to look. |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 312
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 7:53 am: |
|
Thank you all for the cogent and thoughtful comments to this article. After reading the threads I see three main questions arise:
1. How absolute is the prohibition against interpreted code (and self-modifying and dynamically loading code) under section 4.2.2 of Volume I of the 2002 VVSG.
2.If the prohibition in 4.2.2 is not absolute, under what conditions is interpreted code allowed. This is the exception 6.4.e reference in section 4.2.2.
3.Would not a better argument be that the .ABO file is dynamically loaded code and not it is interpreted code? Since, both types of code are prohibited by section 4.2.2 why not use the more generic feature (dynamic loading) of the .ABO as the basis of the objection?
It is my position the prohibition against interpreted code is absolute because paragraph 6.4.e does not exist. In the world of standards and legality the document is to be interpreted as written; often this is in spite of what is sensible. But, such an interpretation would also bar the use of the Microsoft Windows operating system. Dynamically loaded code is also prohibited by Volume I section 4.2.2 of the 2002 VVSG. Microsoft Windows it is nothing but a collection of dynamically linked libraries (DLL) which are dynamically loaded at execution time. This view of section 4.2.2 is a legal interpretation of the 2002 VVSG not a technical interpretation. A forgiving technical interpretation of Section 4.2.2 is the exception reference as paragraph 6.4.e is a typographical error and should actually be paragraph 6.4.1.e.
Paragraph 6.4.1.e would allow interpreted code if the compiler did not reside on the voting system. For the question at hand the compiler is the AccuBasic compiler which converts a BASIC program into a stream of tokens stored in an .ABO file. This boils down to what is the definition of voting system. Under the 2002 VVSG the system is the totality not any particular part. If the compiler is on any machine (not just the optical scanner), the compiler is on the system as defined by the 2002 VVSG. It is my understanding the process of ballot definition programming done on the GEMS central server can customize the .ABO in order to accommodate the needs of local election officials. If so, then the compiler is on the GEMS server and thus on the voting system. This is also a clear violation of 4.2.2 even with the exception interpreted as paragraph 6.4.1.e instead of paragraph 6.4.e.
I could be wrong and the AccuBasic compiler is not on the GEMS server. But, I do not think this is the case. It is not as if the various vendors are providing information or manuals so such questions can be resolved with authority. Mr. Shipley’s interpretation of the exception to section 4.2.2 is that as long as the compiler is not present on the voting system then any self-modifying, dynamically loaded, or interpreted code is permitted. This is a difficult interpretation to accept. My absolutist interpretation at least has the virtue it is supported by the document as written.
Is interpreted code a deeper problem than dynamically loaded code? Yes, interpreted code is easier to create than machine executable code. This is because there are fewer steps (no linking) needed to create interpreted code and the interpreter is (in general) often more forgiving of coding mistakes than the CPU; e.g. the on error resume statement. So I will stick with interpreted code as my primary objection. But, the point is well taken regarding the prohibition against dynamically loaded code. If this were a Windows .DLL or and .EXE file on the memory card, the security defect discovered by Harri Hurtsi and Black Box Voting would still exist. The only difference would be field of possible fraudsters would be slightly narrower. For ES&S, Sequoia, Hart interCivic and other systems, perhaps the dynamic loading would be the better way to argue the system violates section 4.2.2 of the VVSG. But, Diebold optical scanners use code which is both interpreted and dynamically loaded. According to Steve Freeman of California SoS office, the Diebold touch screens also use dynamically loaded, interpreted .ABO files.
If you accept the absence of the compiler under 6.4.1.e grants an exception to the prohibitions of 4.2.2, then section 4.2.2 prohibits nothing of consequence. Why have section 4.2.2 at all? At least my absolutist position is supported by the document as written, even if the implications are as unpalatable to the vendors as the 6.4.1.e exception is unpalatable to voting integrity activists.
John Washburn
Only bad software is delayed by good testing.
|
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 7
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 10:18 am: |
|
John Washburn: if you can find a court which is willing to enforce the standard literally, exactly as written, with no exceptions (good luck!) then I hope you will ask the court to prohibit Microsoft Windows (which contains multiple interpreters, including the one used by Dr. Herbert Thompson in his exploit) and the 80386 microprocessor (which, as Ami Silberman and I explained above, is in fact an interpreter).
The fact that "a microprocessor is an interpreter" is a fundamental truth in computer science, not just a technicality. When a programmer is concerned about program execution speed, it makes sense to pretend that a microprocessor is not an interpreter, because the code which is interpreted directly by the microprocessor runs very fast. But when a programmer is concerned about security, it makes no sense at all to pretend that a microprocessor is not an interpreter, because an attacker who writes his exploit code at the "native code" level can take advantage of all the same tricks which attackers writing code at other levels can use, and more. |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 313
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 12:04 pm: |
|
What do I have in the world of standards and Law if not the written word? You have Humpty Dumpty's world where a word means what ever Humpty Dumpty wants the word to mean nothing more and nothing less. If this is a typo then the EAC should fix it. The whole point of writing it down is to avoid disputes such as this.
Until this thread, I actually thought the typo in 4.2.2 was 6.4.e was supposed to be 6.4.d. Fat fingering an e for a d is a common typing mistake. Paragraph 6.4.1.d as the exception to 4.2.2 is a sensible exception. It does not eviscerate 4.2.2 as 6.4.1.e does and still allows for Microsoft Windows as an operating system. If 4.2.2 has a typographical error, this is the more sensible guess as to what the intended exception was supposed to be. This was, until this thread, the only way I could reconcile the 2 sections 4.2.2 and 6.4.1 in a meaningful way.
There is a dispute as to what the correction to typo should be. Mr. Shipley presents a plausible theory as to what the exception paragraph could be. It could also be the typo is 6.4.d. Which is correct?
There are equally plausible guesses as to which is the proper exception paragraph referenced by 4.2.2. We have lawyers on this forum. What are the rules of construction in the face of alternate constructions? Previous versions or drafts while under construction such as in an ANSI or ISO document is usually used. Do any prior versions, drafts or notes of the 2002 VVSG exist? If not, then as written in the final form is all there is. Don't blame me if the standard was written badly.
It is still possible the compiler resides on the system qualified under number N-1-06-22-22-001 (2002) or N-1-06-22-22-002 (2002) because it is on or part of the GEMS software. If so then this thread is a tempest in a teapot as the interpreted .ABO code would be prohibited under either exception paragraph (6.4.1.e or 6.4.1.d).
John Washburn
Only bad software is delayed by good testing.
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1418
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 1:20 pm: |
|
John,
Thanks for pointing out that other typo option.
So someone would have to ask the VVSG for an earlier draft or notes so as to understand how to interpret the problemmatic error? And if they cannot illuminate then the exception is "void"? |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 314
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 2:32 pm: |
|
No. The exception is what ever Brian Hancock, chairman of NASED Voting Systems Board, says the exception is. See section 9.6.4 of the 2002 VVSG:
Resolution of Testing Issues
The NASED Voting Systems Board (the Board) is responsible for resolving questions about the application of the Standards in the testing of voting systems. The Secretariat for the Board will relay its decisions to the NASED certified ITAs and voting system vendors. The Federal Election Commission will monitor these decisions in order to determine which of them, if any, should be reflected in a subsequent version of the standards.
Normally such errors are never in the final version of a standard. Too many confilcting interested parties are reading the emerging standard too closely. I vaguely recall the 1989 ANSI standard for the C programming language had some small typographical error. Many C compiler vendors complained bitterly that the final standard or final draft (from which they were making reference implementations of compilers for the soon to be standard language) was different from the previous draft. But, in that case it was clear from the record of drafts and notes from the technical meetings what the proper interpretation should be until the standard would be published without the error.
Without such clear direction though, void is often the construction used in a legal or standards context especially with conflicting interpretations.
Also, even the exception I was thought was the proper interpretation of the typographical error in 4.2.2 would gut the prohibition of 4.2.2. I overlooked the use of the word “may” in 6.4.1.d. I am ashamed to admit both times I read it. This indicates indicates putting election-specific programming into firmware is optional not required. I had it in my head the 6.4.1.d exception required self-modifying, dynamically loaded or interpreted code must be in firmware (which the memory card is not); just not on the motherboard with the CPU. Sensible given the volatility and danger such code presents.
But if the proper interpretation of 6.4.1.d is optional not required, then the prohibition of 4.2.2 is not worth the paper it is written on.
Where is the compiler to the AccuBasic found? If on, the GEMS server in some form then 6.4.1.e clearly applies.
If the AccuBasic compiler is not on the GEMS server, then the Diebold design is not prohibited by section 4.2.2. Section 4.2.2 prohibits nothing of consequence because either of the exception paragraphs allows self-modifying, dynamically loaded or interpreted code in all but the most rare of circumstances.
That is a truly depressing statement about the quality and utility of the 2002 VVSG. I like the void interpretation more and more.
P.S.
For those without access to the 2002 VVSG here is the except of Section 6.4.1:
6.4 Software Security
Voting systems shall meet specific security requirements for the installation of software and for protection against malicious software.
6.4.1 Software and Firmware Installation
The system shall meet the following requirements for installation of software, including hardware with embedded firmware:
a.If software is resident in the system as firmware, the vendor shall require and state in the system documentation that every device is to be retested to validate each ROM prior to the start of elections operations;
b.To prevent alteration of executable code, no software shall be permanently installed or resident in the system unless the system documentation states that the jurisdiction must provide a secure physical and procedural environment for the storage, handling, preparation, and transportation of the system hardware;
c.The system bootstrap, monitor, and device-controller software may be resident permanently as firmware, provided that this firmware has been shown to be inaccessible to activation or control by any means other than by the authorized initiation and execution of the vote-counting program, and its associated exception handlers;
d.The election-specific programming may be installed and resident as firmware, provided that such firmware is installed on a component (such as computer chip) other than the component on which the operating system resides; and
e.After initiation of election day testing, no source code or compilers or assemblers shall be resident or accessible.
(Message edited by johnwashburn on January 03, 2006)
John Washburn
Only bad software is delayed by good testing.
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1422
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 3:37 pm: |
|
"Section 4.2.2 prohibits nothing of consequence because either of the exception paragraphs allows self-modifying, dynamically loaded or interpreted code in all but the most rare of circumstances."
Are you sure? 
I am getting more and more confused. Is a dumbed-down translation of this possible? |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 315
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 6:08 pm: |
|
Under the exception granted by 6.4.1.e, I can have self-modifying code, dynamically loaded code and/or interpreted code, IF I remove both the ABasic source and the ABasic compiler from the GEMS system as part of the election testing and install neither prior to election day.
Under the exception granted by 6.4.1.d, I can have self-modifying code, dynamically loaded code and/or interpreted code, IF the code is stored in Read Only Memory not on the mother board (i.e. firmware on a separate card) or the code is store in read-write memory (not firmware).
Both options reduce the plain language prohibition in 4.2.2 to nothingness.
P.S. Section 4.2.2 reads [emphasis mine]
Self-modifying, dynamically loaded, or interpreted code is prohibited, except under the security provisions outlined in section 6.4.e. This prohibition is to ensure that the software tested and approved during the qualification process remains unchanged and retains its integrity. External modification of code during execution shall be prohibited. Where the development environment (programming language and development tools) includes the following features, the software shall provide controls to prevent accidental or deliberate attempts to replace executable code:
Unbounded arrays or strings (includes buffers used to move data);
Pointer variables; and
Dynamic memory allocation and management.
The problem is 6.4.e referenced above does not exist in the 2002 VVSG.
I hope I have not added to the confusion.
John Washburn
Only bad software is delayed by good testing.
|
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 191
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 7:27 pm: |
|
Where is the compiler to the AccuBasic found?
From Accu-Basic Developer Reference Manual.htm
"The person developing the report (the developer) uses a text editor to edit a file containing the Accu-Basic source (.abs). When ready to test the report, the developer runs the Accu-Basic compiler to generate an object file (.abo). If the compiler reports errors, the developer will need to make corrections to the source and recompile until the compiler finds no errors. Should the compiler still report warnings, the resulting object file may or may not be valid and normally these should be dealt with before continuing."
"The object file should be tested before being used in elections. This may be done by downloading it to an Accu-Vote for each of the election configurations that it is designed to handle. All options should be exercised for each election configuration before releasing the file for general use. In order to download a new object file using GEMS, one can either substitute it for a currently supported object file or add an entry in the ABasic.ini file in the main GEMS directory."
"It is strongly recommended that the Accu-Vote reports be run as part of the election testing for each election. Should there be a problem, the program will need to be fixed and all affected memory cards will need to be reprogrammed with the new program."
available from: http://www.bbvdocs.org/diebold/ab-manual.pdf
The compiler is on the GEMS server.
HG |
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 192
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 7:36 pm: |
|
Ok, so I'm not an expert in compilers, and this may be WAY out of context, but in reading through the source code for the ABasic 2.00 compiler (ab200.c,v) I came across this comment which just struck me as odd.
"Fix encoding of unary minus operator".
Would a report compiler for voting machines need a minus function, or am I getting too jittery with this stuff?
Oh, and just in case anyone ever disputes that the .abo report file requires an interpreter, in the same source file (ab200.c,v) is this little ditty....
"First pass of a version 2 Accu-Basic compiler. It compiles a fairly
complete source file. Now to get the abo to work with the interpreter."
(Message edited by harmonyguy on January 03, 2006) |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 316
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 8:27 pm: |
|
Thanks, HarmonyGuy.
That is good news for the particular paper on the particular Diebold paper I wrote.
This typographical error is still problematic in a standards document and an old one at that. I am ashamed that when I read this document back in October and again for this paper I missed the importance of this typo. But it bothers me more though I am the first to publicize this error and the confusion it casts on the prohibition against interpreted code. Who reviewed this document for correctness and completenes before publication?
Now that my panic has subsided slightly, I am curious how, who and when this programming is done.
Where does a developer get the .ABS files in the first place? Do they come with GEMS or on a separate disk? Seems a reasonable question, but, probably not one the ITA's have ever asked.
(Message edited by johnwashburn on January 03, 2006)
John Washburn
Only bad software is delayed by good testing.
|
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 194
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 8:59 pm: |
|
Certainly the ABO file (the 'compiled' version) comes with GEMS. I stand to be corrected, but my undertanding is that the ABS file either comes with the GEMS system, or is custom built by Diebold for a particular jurisdiction's needs. I remember seeing files like 194us.abo, 194usaga.abo, 194usavm.abo whose differences are pretty much self explanatory.
Here's a comment that's VERY telling....It comes from http://sims.berkeley.edu/~ping/diebold/lists/support.w3archive/200003/msg00019.h tml
"Finally, am I correct in concluding that this additional message is 100% a product of firmware not memory card programming?
Actually all messages between (but not including) "GENERATING REPORT..." and "READY TO TURN UNIT OFF?" are generated by the .abo report program. Thus they have nothing to do with the firmware release and are 100% a product of the memory card programming."
Looking at the compiler itself, I suggest that it would be easy enough to DE-compile the abo files back to source code - ABS.
HG |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 317
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 9:03 pm: |
|
The point on the executing code from mixed security contexts is very on point. I love the pink car anaology. That is brilliant.
Unfortunately I have nothing in the standard which prohibits executing code from mixed security contexts.
I was trying to use the 2002 VVSG to club
vendors for a change instead of taking the clubbing. I.e. "The system conforms to the 2002 VVSG. See it says so right here on the ITA label.".
And, present the issue in a way even an elected official in a state legislature might understand.
Clearly, I should examine my tools/weapons more carefully.
John Washburn
Only bad software is delayed by good testing.
|
BBV Admin
Board Administrator
Username: Admin
Post Number: 3087
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 3, 2006 - 10:30 pm: |
|
Are you guys not able to find the .abs source code files? I thought I'd posted them here. If not, let me know and I'll get them posted tomorrow. Or, are you just debating what part of the system applies?
John, I think you're reading it wrong.
Consider more carefully the nature of the pseudo-code.
Accu-Basic programming is a two phase process. First the Accu-Basic program source code needs to be pre-compiled with a compiler, converting it from a human readable source code form into token based pseudo-code. The pseudo-code is still a non-binary, ascii file. This first phase programming is normally done on a standard PC running Windows or *ix –variant operating system. The author used the FreeBSD platform. Then this pseudo-code is transferred to the final execution environment (that is, to the voting machine), where the pseudo-code is executed by an interpreter.
Note: The interpreter, built into the optical scan firmware, will execute the code following the instructions on the memory card. No information has been provided about the interpreter.
Consider the argument that the pseudo-code should be considered source code. It is, of course, used AFTER the election begins.
Bev |
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 195
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 5:04 am: |
|
Your right!
In looking at the 'compiled' abo files, I have to say that the term 'compiled' is used VERY loosely. The pseudo-code IS still very readable ASCII, with the instructions and variable-names simply tokenized into two or four-character names rather then thier original lengthier names. Using the tokenized file, along with a lookup chart of the tokens (conveniently provided on the original FTP site), would be all that's needed in order to 'DE-compile' the pseudo code.
The pseudo-code ABSOLUTELY should be considered source code. With a bit of practice, it is as humanly-readable as the original pre-shrunk .abs files. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1425
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 6:27 am: |
|
Maybe what we need is a flow chart showing the code's journey and the points at which it undergoes certain processes, and what controls those processes and where these controlling things reside.
Then we need some text pointing out where the issues are according to the VVSG guidelines--what in the diagram shouldn't be there according to various interpretations of VVVSG/typos. |
David Gatwood
Voting Rights Forum Participant
Username: Dgatwood
Post Number: 1
Registered: 01-2006
Best of Black Box?
Votes: 1 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 3:39 pm: |
|
Three points that a bunch of folks seem to be missing:
1. The issue of the tokenizer (that's what the "processor that converts the [human-readable] source to [executable] tokens" is called) being verboten on the system after testing is a total red herring. One could easily run that program on a separate machine and introduce new tokenized code. I can't imagine why such a policy would even exist except to detract attention away from real flaws....
2. The biggest problem here is that executable code (whether in the form of binary code or tokenized source code) can be introduced by simply inserting a memory card---and worse, that this ability isn't even limited to boot time!!!
If these companies really are shipping software with those sorts of obvious flaws, I wouldn't trust their programmers to mow my lawn, much less design voting systems.... That's a level of ineptitude that should not be tolerated. Really, it's a sign of someone designing software quickly, trying to throw it out the door, rather than making sure that it's right. Might be okay if you're vote counting for a CNN Quick Poll, but.... :-)
3. A CPU is not the same thing as an interpreter. An interpreter is defined as a piece of software that takes a tokenized form of software and performs operations based upon that. A CPU is not software, therefore, it is not an interpreter.
This distinction is not a minor one. It is the fundamental reason why interpreted languages in voting machines are bad. With an interpreted language, the interpreter determines what happens when a particular piece of code occurs. There can be an arbitrarily large amount of complexity hidden from a code review of the interpreted code, up to and including completely falsifying the resulting output.
If the interpreter is not fully audited, this casts serious doubt on the suitability of the system. Even if it is fully audited, it is awfully easy to make an interpreter whose code seems sensible until you pair it with the program being interpreted and vice-versa. In other words, if they aren't audited as a pair, with thorough proofs that a given interpreter version will execute a given interpreted program in a provably correct way, the auditing becomes less than useless.
With compiled code (using an industry standard compiler that is not under the control of the voting machine manufacturer), one could still make the argument that a modified processor could execute the code in a different way, but you'd be laughed at because:
a. Producing custom silicon is extremely expensive.
b. It is exceedingly difficult (if not impossible) to take advantage of existing processor errata in a compiled language.
c. Producing a CPU that does large, complex operations in a single instruction is very, very, difficult even if you know what you're doing.
In effect, the proof of correctness for interpretation comes from the preponderance of evidence---the CPU executes tens of thousands of different programs correctly, which means the odds of an undiscovered bug significantly changing an election's outcome are relatively slim. (That said, hardware should still be required to be on the market for a couple of years before certifying it for use in a voting system, just to be safe.)
This, of course, excludes the issue of some newer CPUs that have the ability for someone to upload custom firmware for glue logic in which CISC instructions are turned into a RISC instruction stream in "hardware", but even if somebody could find a way to change that, you'd win the hack of the century contest if you pulled it off....
As such, the odds of someone being able to commit fraud by mucking with the CPU "interpreter" are basically nil, while doing so by modifying an actual software interpreter is downright easy.
Just my $0.02. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1430
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 4:08 pm: |
|
In other words, if they aren't audited as a pair, with thorough proofs that a given interpreter version will execute a given interpreted program in a provably correct way, the auditing becomes less than useless.
Thanks for putting this so clearly. It seems like an important point and I haven't seen it expressed this way before. |
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 198
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 6:22 pm: |
|
Hey Bev - is it time to post an abo file aloing with its abs equivalent?
I did find the abs files in my backups - staring at them all along. Are they allready posted on here somewhere?
HG |
Phil McCracken
Voting Rights Forum Participant
Username: Phil_mccracken
Post Number: 1
Registered: 01-2006
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 7:25 pm: |
|
What is the point of placing an "ABO" file on this thread? What can be intepreted by it? |
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 199
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 8:04 pm: |
|
Welcome to BBV, 'Phil'. An important question for your first post.
Perhaps I misunderstand the intent of your question - Given that this thread mentions ABO files more than a dozen times, and gets into some pretty good detail on them, I don't understand your concern over placing an ABO file in this thread? Is the issue the thread in which to place it or the placing it at all?
Likely, different people will interpret different things from it. More eyes with different skills means more and potentially better interpretation - hence better understanding.
HG |
Phil McCracken
Voting Rights Forum Participant
Username: Phil_mccracken
Post Number: 2
Registered: 01-2006
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 8:12 pm: |
|
I am trying to understand the intent of posting an ABO file? What can we garner by it? I am not very familar with it. That's all. Appreciate the feedback John. |
John Howard
Frequent Voting Rights Forum Participant
Username: Harmonyguy
Post Number: 200
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 4, 2006 - 8:17 pm: |
|
Comparing the ABS and ABO files might help others better understand just how simplistic the AccuBAsic 'compiler', (and I use that term loosely), really is.
More eyes...... |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 8
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, January 5, 2006 - 5:32 am: |
|
John Washburn wrote:
quote:That is a truly depressing statement about the quality and utility of the 2002 VVSG.
I don't think we should be surprised when we find a lack of quality and utility in the VVSG. After all, this is a document which said ballotless touch-screen voting machines were acceptable. In 2002! There's no way any legitimate group of experts could have believed that in 2002.
If you can find a way to use the VVSG to accomplish something good, that's great... but never forget that this document, as a whole, is garbage.
quote:Unfortunately I have nothing in the standard which prohibits executing code from mixed security contexts.
If you could get a court to prohibit dynamically loaded code, that would prohibit the kind of security context gaffe that Hursti exploited.
quote:I was trying to use the 2002 VVSG to club vendors for a change instead of taking the clubbing. [...] Clearly, I should examine my tools/weapons more carefully.
Harri Hursti already performed this exercise (looking through the VVSG to find which sections violated by Diebold contributed to the success of his exploit) except he used the 1990 version. He chose sections 5.1, 5.3 and 5.5 as the most relevant.
David Gatwood wrote:
quote:Three points that a bunch of folks seem to be missing:
David, it's great to see you here, if you're the person I think you are. I was a big fan of MkLinux, back in the day.
This thread seems a bit confusing, because two separate goals are getting mixed together: (1) the search for techniques which ought to be used, in order to make voting machines more difficult to subvert; (2) the search for requirements which may (or may not) have any real benefit, but which have already been officially sanctioned, and can be used against today's crop of absurdly inappropriate voting machines.
Personally I have doubts about both #1 and #2. Regarding #1: I think we absolutely need to have good old-fashioned 19th-century security procedures (based on paper) which could protect an election even if it's conducted on totally compromised equipment. Then we'll probably want reasonably secure computer equipment, but just as a way to save time and money, not as a way to prevent election fraud. Regarding #2: I hope John Washburn will succeed in this effort, but frankly the VVSG smells so bad to me that I don't even like to think about trying to use it as an ally.
When we call something a red herring in this thread, I guess we should try to remember to specify whether we're talking about computer security or about violation of the VVSG.
quote:3. A CPU is not the same thing as an interpreter. An interpreter is defined as a piece of software that takes a tokenized form of software and performs operations based upon that. A CPU is not software, therefore, it is not an interpreter.
Gee, I hate arguing about definitions! But I'll do it anyway, just a little.
I can see that you are a "software person." Among software people it makes sense to use the word "interpreter" to refer to interpreters which are software. But among "hardware people" who design CPUs, the word "interpreter" refers to the part of the CPU which interprets the machine language instructions. This usage goes way back, to von Neumann and the first computers. Here's a good succinct explanation from an old textbook ("Computer Structures, Readings and Examples" by Bell and Newell of Carnegie-Mellon):
quote:From the hardware point of view, an interpreter consists of the mechanisms for fetching a new instruction, for decoding that instruction and executing the operations so designated, and for determining the next instruction.
Notice that their idea of an interpreter is essentially identical to yours, but implemented in hardware. The definition I learned, which is purely functional (i. e. names a device based on what it does, not on how it's made) cleanly includes both kinds of implementation under a single definition.
But this issue about the exact meaning of the word "interpreter" is only important for goal #2 above (tactical use of the VVSG) and may be pointless, because that part of the VVSG is so carelessly written. I am more interested in discussing goal #1 above (better security) and, in that context, I disagree with your belief that "interpreted languages in voting machines are bad."
quote:There can be an arbitrarily large amount of complexity hidden from a code review of the interpreted code, up to and including completely falsifying the resulting output.
You are right. Reviewing interpreted code tells us nothing, if the enemy has control over the interpreter which interprets that code. But this problem has nothing to do specifically with interpreters: this is a general category of vulnerability which happens with any layered system when you fail to scrutinize the lower layers. It happens with compilers, and libraries, and operating systems, and bootloaders. In fact, the failure of various people (including the authors of the VVSG) to understand this general category of vulnerability is one of our biggest problems.
This issue is important, so I hope you won't mind if I take your sentence above about interpreters and re-target it for compilers:
If the enemy has control of the COMPILER, there can be an arbitrarily large amount of complexity hidden from a code review of the SOURCE code, up to and including completely falsifying the resulting output.
I could just as easily re-target that sentence (and all your other sentences about interpreters) for libraries and operating systems and bootloaders as well as for compilers, but I'll omit all those variations of sentences to save space.
quote:a. Producing custom silicon is extremely expensive.
Yes it's expensive, but anyone who can steal enough votes to gain control of the executive and legislative branches of government can gain control of TRILLIONS of dollars. When the stakes are that high, I have to agree with William Shipley's comment that "'Harder' is not a sufficient standard."
(You're right that no one is going to produce custom silicon, but that's only because there are easier ways. If we proceed to protect ourselves from every other kind of cheating but not from custom silicon, they will produce custom silicon.)
But this is only a side issue; when I said that the attacker can take advantage of the presence of a microprocessor just as well as he could take advantage of the presence of an interpreter, I wasn't referring to the possibility of replacing the 80386 with custom silicon; I was referring to the fact that the microprocessor is effectively Turing-complete and therefore the attacker can make it do anything he wants it to do, if he can take control of it. "Anything he wants it to do" in the Turing sense means he can make it interpret any language, including whichever language we tried to forbid!
quote:As such, the odds of someone being able to commit fraud by mucking with the CPU "interpreter" are basically nil,
But would they really need to muck with the actual silicon, in order to muck with the behavior of the CPU? If you are who I think you are, I'm sure you must be aware of MacOnLinux. I haven't read the MOL source code, but it seems to me that if someone had physical access to my G4 and wanted to muck with the CPU, but didn't have the ability to make custom silicon, he could modify MOL and install it on my machine, and then he would effectively be able to modify the behavior of my CPU, and I might never find out. Right?
I highly recommend that you read section 3.1.2 of this article <http://www.verifiedvoting.org/downloads/shamos-rebuttal.pdf> by Ron Crane et al. In fact, I recommend reading the whole thing. Incidentally, Ron Crane agrees with me that there is nothing wrong with interpreted code in voting machines.
By the way: I assume you are aware of the Linux kernel/exit.c sabotage attempt of November 2003? It's interesting to contemplate what would happen in a "battle of wits" between the perpetrator of that attempt and the authors of the VVSG. Yikes!
quote:while doing so by modifying an actual software interpreter is downright easy.
Yes, true, but only because doing ANYTHING with software is downright easy.
Except securing it. |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 93
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 6, 2006 - 7:38 pm: |
|
> But would they really need to muck with the actual silicon, in order to muck with the behavior of the CPU?....
I highly recommend that you read section 3.1.2 of this article <http://www.verifiedvoting.org/downloads/shamos-rebuttal.pdf> by Ron Crane et al. In fact, I recommend reading the whole thing. Incidentally, Ron Crane agrees with me that there is nothing wrong with interpreted code in voting machines.
<
I don't think you meant that last sentence quite the way it came out. I think that any code of any sort in a voting machine creates insurmountable transparency and security issues, and that, therefore, computer-assisted voting machines should not be used. I gather from your previous posts here that you have taken a similar position.
Hence, I would rephrase "there is nothing wrong with interpreted code in voting machines" to "in voting machines, interpreted code is no worse than compiled code: both should be prohibited".
-R
P.S. Over the summer I changed my position on computer-assisted voting. When I wrote the paper you cite, I still believed that it was reasonably practical to build a sufficiently transparent and secure computer-assisted voting system. Having seen, in the interim, what passes for "supervision" of voting technology (e.g., the VVSG: see my comments here), I now believe that it is not practical for any such system to attain a sufficient level of security. Further, due in large part to the efforts of others here, I have become convinced that it is vital for ordinary citizens, lacking any special training, to be able effectively to supervise their voting systems. Since only computer security experts effectively can supervise e-voting systems, they should not be used.
BTW, I and the other authors have revised that paper to reflect my new viewpoint (and for submission to a conference); you can pick it up here. For some reason verifiedvoting hasn't gotten the new one yet.
(Message edited by ron_crane on January 06, 2006) |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 333
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:16 am: |
|
RE: If you can find a way to use the VVSG to accomplish something good, that's great... but never forget that this document, as a whole, is garbage.
Garbage it may be but some sections have some suprisingly sharp edges. For example the configuration management requirements of section 8 are as if they are lifted out book on best practicies which, if followed, would make voting machinery software more similar to avionics software than commercial business software.
I am under no illusion though the CM practices of sections 8 and 9 are actually being followed. I have enough evidence to contrary on that point.
But, as a software tester of 11 years standards and conformance to spec (even mal-formed specs) is within my professional "sweet spot". I believe I can do some good on this front.
More of the swarm effect. I am good at this particular aspect of the game and I would like to see the software on machines be well-tested. My pursuit of those ends will undoutedly help in both eliminating bad machinery and help define a framework from which trusted machinery can be brought forth.
In retrospect, (hopefully) my work, your work, Bev's work, and the work of all others will look like superb planning and coordination of a brilliant master plan. In fact it will just be the result of convergent self-interests in a common goal: Reliable, trustworthy elections.
John Washburn
Only bad software is delayed by good testing.
|
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 334
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:25 am: |
|
The mixed topics of this thread is a good point. We do have 2 topics here:
What are good/bad practices for software particulary for voting machinery in particular?
Within the existing framework of standards, laws, regulations, etc., can enforcment of and adherence to this framework be used to block or delay the deployment of manifestly bad machinery?
You are absolutely correct these two, distinct ideas are intertwined in this one thread.
To the Admins: Is it possible to retroactively detangle this thread and separated out the discussions on these two topics into 2 new threads?
(Message edited by johnwashburn on January 07, 2006)
John Washburn
Only bad software is delayed by good testing.
|
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 335
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:50 am: |
|
RE: If you could get a court to prohibit dynamically loaded code, that would prohibit the kind of security context gaffe that Hursti exploited.
Section 4.2.2 of Volume I of the 2002 VVSG bind self modifying code, dynamically loaded and interpreted code together. If one form is allowed, all three are allowed. What ever prohibition exists against one exists for all.
Dynamically loaded code is as prohibited/allowed as self-modifying code and both are as prohibited/allowed as interpreted code. It may very well be my interpretation of the 2002 VVSG on this point is deeply flawed and incorrect. The correct interpretation is 2002 VVSG allows self-modifying code, dynamically loaded and interpreted code under almost all conditions.
If I am a voting machinery vendor, how many such victories of this kind can be endured? Our dynamically loaded, interpreted voting software conforms to the VVSG because self-modifying, dynamically loaded or interpreted code is not prohibited by the VVSG.
There is some rhetorically utility on my focus on interpreted code. It seems to me intepreted code is more tractable and easier to explain to a non-techinical audience than dynamically loaded code. Even though the latter (from a lower security context) is the proper nature of the Hursti exploit.
The risk (as you point out with the pink car analogy) is my rhetorical decision undermines understanding by the general public of the truer nature of the problem: the security context gaffe. I hope this is not the case. But, it is a real risk I had not considered very well with my blinkered focus on using the VVSG as written.
At this point the die is cast and only time will tell which of us was correct.
Note: this is on the topic can the existing framework to the good?
John Washburn
Only bad software is delayed by good testing.
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1453
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:53 am: |
|
And maybe John could you correct that little typo.
It took me too long to rule out "writhing" or "writing". (Finally figured out it's supposed to "within"). |
John Washburn
Frequent Voting Rights Forum Participant
Username: Johnwashburn
Post Number: 336
Registered: 04-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 4:06 am: |
|
Done.
My only defences are I am a poor typist and it is late here in Milwuakee.
This is why draft documents for standards are reviewed by as many people as possible. Typographical errors cause misunderstandings.
John Washburn
Only bad software is delayed by good testing.
|
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 10
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:34 pm: |
|
John Washburn wrote:
quote:if followed, would make voting machinery software more similar to avionics software than commercial business software
That's great, but... I hope we all understand that making voting machine software resemble avionics software DOES NOT solve the fundamental problem. The comparison with avionics has been debunked by many people; in fact this is covered in section 2.4 of the same article already linked above, by Ron Crane et al.
quote:The correct interpretation is 2002 VVSG allows self-modifying code, dynamically loaded and interpreted code under almost all conditions.
If that is true, then you might want to follow Harri Hursti's lead in choosing a more appropriate part of the VVSG. You could look at his claim that sections 5.1 and 5.3 and 5.5 of the 1990 standard were violated, and then study those sections to understand why he said that, and then find the corresponding sections in the newer standard.
quote:It seems to me intepreted code is more tractable and easier to explain to a non-techinical audience than dynamically loaded code.
I don't understand why you believe that. I think dynamically loaded code is extremely easy for an average person to understand. "The voting machine loads and runs a program from the memory card (in other words, it obeys a list of instructions which it finds on the memory card) so anyone who can put stuff on the memory card can take control of the voting machine." What's difficult about that? That's a heck of a lot easier than interpreters and compilers.
The weakness that Harri Hursti exploited was like a nuclear reactor security procedures manual which says "After completing the steps in section 4, check to see if someone has inserted a new version of section 5 in the front door mail slot. If so, follow the steps in that new version instead of the version of section 5 printed here." |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 11
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 2:38 pm: |
|
Ron Crane wrote:
quote:Hence, I would rephrase "there is nothing wrong with interpreted code in voting machines" to "in voting machines, interpreted code is no worse than compiled code: both should be prohibited".
Ron, thank you for posting that correction. I agree that elections must be protected by procedures which are seen and understood by ordinary citizens, but I have not yet been convinced that this rules out all computer-assisted voting. I would think that the equipment and procedures could be arranged such that the security of the election does not depend on the security of the computers.
I am confident that Leon County's elections have been secure (even though they were conducted on grossly insecure equipment) because appropriate procedures were followed. I would think that something similar could be done for computer-assisted voting.
I'll give you a sketch of a system which I think would be acceptable, and you can tell me if you disagree. I'm not advocating such a system; but if my county chose to adopt it, I don't think I would protest.
(1) The audio voting station is a computer, but it doesn't store or tabulate votes; it just prints them on a paper ballot. (2) the ballot box is just a box. (3) Public-spirited voters who can see and hear and read, and who are not secretive about their vote, are encouraged to volunteer to mark their ballot with the audio voting station instead of a pen. They are provided with an audiocassette recorder which plugs into the headphone jack. If the paper ballot doesn't match the audio, the machine is taken out of service, and the ballot and audiotape are kept as evidence. (4) Ballots are counted using appropriate procedures, just as if no computers had been involved.
I think this system would be reasonably secure, even if the computers are grossly insecure. In fact, I think anyone who wanted to steal the election would not even bother to attack the audio voting station. Am I wrong? |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1464
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 3:31 pm: |
|
Would deaf voters use a conventional paper ballot?
So essentially, people could choose to mark a paper ballot themselves, or use an audio voting station to mark their paper ballot? And by encouraging non-disabled people to use the audio voting stations you get almost complete auditing as to its accuracy.
And you could issue different audio tapes for different languages.
All the audio tapes could be made available to representatives of all candidates ahead of time to ensure there are no errors; and possibly for test-run purposes.
Sounds interesting to me.
I like the idea of the able-sighted being able to be watchdogs for the non-sighted, w/o violating the secrecy of the ballot. |
Jo Anne Karasek
Voting Rights Forum Participant
Username: Jo_anne_karasek
Post Number: 84
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 3:38 pm: |
|
Robert, you write, "I am confident that Leon County's elections have been secure." I am puzzled why you would say that. Possibly you say that because the Leon County head is a good and honest person.
But unless security is extremely tough, a burglar who is also a cleaning man probably could get access to the voting machines and hack them. The election personnel generally don't know what is being done to the voting machines.
One election personnel in an Ohio county came in on a Sunday to work and found a stranger working on the voting machines before the Presidential election. (The election personnel was put on suspension and quit.) It is very difficult for the best of county heads to be in control of the voting machines. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1465
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 3:51 pm: |
|
Jo Anne, those are great points. That's the first I've heard about that particular incident in Ohio. What county did that happen in? I'm surprised it hasn't been highlighted more. (I heard about the woman who mentioned the Triad workers "servicing" the machines, but this sounds like something different.)
Re: Leon County, Ion Sancho is on record as saying that he believes the vote there was hacked in 2000. He says this based on the unusual results (later shown to be a mistake). This seemed designed to convince Gore to concede--which they nearly did.
If Sancho believes someone could have hacked the vote, it shows that honest attempts to run a tight ship are not necessarily enough. The hackers will always be one step ahead of the game. |
Pat A. Vesely
Frequent Voting Rights Forum Participant
Username: Pat_vesely
Post Number: 2075
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 4:08 pm: |
|
Catherine, If I'm not mistaken, Ion Sancho was referring to Volusia County and the -16,022 Gore votes in the 2000 election.
Pat A. Vesely ;-) |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1467
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 7, 2006 - 11:13 pm: |
|
OK, thanks. One of the reports I read gave me the impression he was referring to his own area. Perhaps the quotation was ambiguous and I jumped to the wrong conclusion. |
BBV Admin
Board Administrator
Username: Admin
Post Number: 3144
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 7:04 am: |
|
I don't understand this statement:
quote:Public-spirited voters who can see and hear and read, and who are not secretive about their vote, are encouraged to volunteer to mark their ballot with the audio voting station instead of a pen.
Why should any system encourage anyone to give up the secrecy of their vote?
As for Leon County's security, the honorable Cynthia McKinney, U.S. Representative from Georgia had it right when she observed. Security in Leon County has been wholly dependent on one man. He seems like a good man, but, as McKinney said on May 2, 2005:
"TJ, you are a powerful man!"
IT personnel shouldn't be put in the position of having sole control over an election. Insisting on multi-layer security, which means having technological layers that work as well as people layers, actually PROTECTS the insiders. Diebold's design puts an unsustainable burden on the perimeter defense -- the person who runs the system.
Bev Harris |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1474
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 8:24 am: |
|
I didn't think that using the audio device would imply giving up secrecy. Especially if a fair number of people used it.
If only 1 person used it in the day, then secrecy would be compromised. But I thought the more use it gets, everyone's secrecy is guaranteed plus everyone knows throughout the day that the device is working. (If sighted people are using it and verifying their ballots visually--it means only the voters who are blind wouldn't be able to visually verify their ballot--unless they opted to have someone in the booth to assist them.) |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 94
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 2:25 pm: |
|
quote:I'll give you a sketch of a system which I think would be acceptable, and you can tell me if you disagree. I'm not advocating such a system; but if my county chose to adopt it, I don't think I would protest.
(1) The audio voting station is a computer, but it doesn't store or tabulate votes; it just prints them on a paper ballot.
(2) the ballot box is just a box.
(3) Public-spirited voters who can see and hear and read, and who are not secretive about their vote, are encouraged to volunteer to mark their ballot with the audio voting station instead of a pen. They are provided with an audiocassette recorder which plugs into the headphone jack. If the paper ballot doesn't match the audio, the machine is taken out of service, and the ballot and audiotape are kept as evidence.
(4) Ballots are counted using appropriate procedures, just as if no computers had been involved.
I think this system would be reasonably secure, even if the computers are grossly insecure. In fact, I think anyone who wanted to steal the election would not even bother to attack the audio voting station. Am I wrong?
You're correct that no one would try to subvert this system when used as proposed, but that has little to do with its level of security.
By implicitly confining its use to the blind, the severely visually-impaired, and a few public-spirited...volunteer[s]", you've radically reduced the incentive to use it to cheat. The National Federation of the Blind estimates that about 1.3 million Americans are blind, or about 0.4% of the population. Multiplying that by 5 to account for everyone with severe visual impairment -- and the volunteers -- gives 2%. While many elections are decided by margins this small (and a cheater can swing a two-way race by transferring half the legitimate winner's margin to the legitimate loser), this would require defrauding most of the system's users. That is, of course, certain to be discovered, so only a fool would try it.
But more broadly, the system you've described has a variety of important vulnerabilities that would become important if it were deployed for use by more than a small proportion of voters.
First, since it presents the ballot to the voter and accepts her selections, a malicious ballot-market could influence the voter's choices by modifying that presentation or acceptance. This technique would especially influence the significant percentage of voters who decide how to vote in the voting booth. For example, a malicious marker could slightly garble disfavored candidates' names, or move them farther down the ballot [1] . Or it could make it more difficult to select disfavored candidates by, for example, dynamically reducing the sensitivity of the device (button, etc.) used to select them. This method is especially desireable because it leaves no hard evidence.
Since these techniques actually change some voters' choices, they do not create mismatches between the audiotape and the resulting paper ballot, and cannot be detected by auditing that relies upon that kind of comparison.
Second, if the paper ballots are tabulated by machine, a malicious ballot-marker could record marks -- invisible to the voter -- that influence how a cooperating malicious tabulator reads the ballots. Equally, it could modify the visible marks to influence how an honest tabulator reads them by, for example, misregistering them. While these frauds can be sidestepped by hand-counting all the ballots, or detected by appropriate sampling hand recounts, officials often fail to take such precautions, even when they're legally-mandated.
Third, this system requires a high level of voter vigilance. Assuming it was used by the general population, and that a malicious vendor wished to swing a 2-way race that its favored candidate was projected to lose by 4%, the vendor would have to swing 2% of the vote. In a precinct of 1000 voters, that's 20 votes. Assuming that that 25% of voters are very vigilant and might detect something [2], that increases the number of votes that it needs to swing to 27. Of that, 7 voters would detect something. Maybe half (4) would complain. If the vendor used only presentation frauds (which leave little or no trace), it's pretty likely that pollworkers (or officials in the unlikely case that it gets that far) would discount this tiny set of complaints as "voter error" or "glitches". [3] I don't know what it would take to push pollworkers and officials over the top, but I suspect it's more than the total number of cheats needed to swing this hypothetical election.
Fourth, this system's security (such as it is) hinges upon careful adherence to complex procedures, the reasons for which are not immediately obvious to people untrained in computer security. In particular, as noted above, the handling of so-called "glitches" is critical. Yet, in real situations, pollworkers and officials routinely disregard even major problems, like when 600 voters somehow "cast" 4,000 votes for a Presidential candidate in Ohio in 2004.
I don't see how we realistically can change this attitude, or if we can, how we can make the change stick over the long term.
Fifth, the vast majority of voters can't effectively supervise this system. They don't understand how it can defraud them, and they're inclined to believe that any computerized system adopted by elections officials is, ipso facto, secure. This places elections' outcomes into the hands of a tiny group of vendors and officials. While today's vendors and officials might (or might not) be scrupulous enough to resist seizing the power that makes available, nothing guarantees that future vendors and officials will be so, um, forbearing.
-R
[1] This could be detected by careful voters, but a malicious vendor could provide several excuses for it. First, it could allege that the tapes were incorrectly recorded or even doctored. Second,
it could allege that the voter caused it to happen by asking the machine to replay the list before it had completely been recited, or by making some other superflous selection.
[2] I think that's generous, particularly over the long term, especially considering that most voters are "comfortable" with the security of existing touchscreen systems.
[3] Consider also that a well-programmed cheat would monitor the voting rate and cheat when the polls are busy, thus reducing the chances of detection and effective followup.
(Message edited by ron_crane on January 09, 2006) |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 12
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 4:52 pm: |
|
I see that I need to give more detail about two subjects: (1) encouraging sighted voters to volunteer to use an audio voting station; and (2) my confidence that the Diebold machines in Leon County haven't been tampered with.
About #1, audio voting: I think Catherine Ansbro understands what I meant. The sighted volunteer only gives up his or her secrecy if the machine needs to be taken out of service. I will do something similar in November, on my own initiative, if my county acquires Automark machines. I will vote by audio without looking at the screen, and I will check my paper ballot when it comes out, and if the ballot doesn't match I will tell a poll worker how I intended to vote (thus giving up my secrecy) so the poll worker can reproduce the problem. Note that this won't really work if the problem is intermittent: the poll worker won't be able to reproduce the problem and will think I'm just confused. That's why I suggested the use of an audiocassette recorder plugged in to record all the audio that comes into the headphone: the audiotape would allow the poll worker to hear what I heard, instead of just trying to reproduce the problem. It wouldn't make much sense for me to bring my own recorder in November, because the poll workers wouldn't know how to handle the situation; but if the county would provide the audiocassette recorder and instruct the poll workers in advance, I think tampering with audio voting stations would be so pointless that no one would even attempt it.
About #2: I am confident that the Diebold voting machines in Leon County haven't been tampered with in a real election, because Mr. Sancho instituted a policy of manually auditing paper ballots when the machines were first acquired in the early 1990s, and has continued that policy. In 2004 I think they hand counted the ballots from the three polling locations which swung best for Bush, and the three which swung best for Kerry, and another half dozen selected randomly: about twelve locations in all (out of about 120 total) counted by hand. That's not perfect but it's pretty darn good, especially compared to other counties. If they hand audited every election that way for more than a decade, and they didn't find any problems, then there probably just weren't any problems to find. (I'm not sure the numbers I gave are exactly right, but I'm sure this is the general idea of the auditing strategy used in Leon County. You could ask Mr. Sancho if you want more certainty.)
You could argue that I am confident only because I trust Mr. Sancho, and that I shouldn't expect that all other voters will trust him. That is true, but that problem can be solved by having enough other people observe the whole process. If you have trusted members of the local R and D and G and L parties, vigilantly observing the handling of the ballots and the hand counting, then everyone will have a good reason to trust the process, except for the hopefully small number of people who distrust all of those observers.
Jo Anne Karasek: you are right that even the best county official can't prevent the voting machines from misrecording and mistabulating. That's why it's critically important to secure and audit the paper ballots. Fortunately for the voters of Leon County, their county official has been doing exactly that.
P. S. Of course there's a good logical reason why Leon County has not been targeted: the lower-hanging fruit effect. If a criminal looks at 67 houses, and one of them is guarded by a Doberman while most of the other 66 are guarded by quivering Chihuahuas... guess which house the criminal will not enter.
Ron Crane: I didn't see your reply until after I wrote the above. I'll comment later.
(Message edited by munyer on January 12, 2006) |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1478
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 6:32 pm: |
|
Ron Crane said: "Since these techniques actually change some voters' choices, they do not create mismatches between the audiotape and the resulting paper ballot, and cannot be detected by auditing that relies upon that kind of comparison."
This is the only part of your lengthy response that I might disagree with. From what I understood of Robert's proposal, the ballot would be verified visually by the voter. (Only blind voter's wouldn't have this option, unless they chose to relinquish secrecy by having someone assist them in the visual verification.) I don't believe Robert was proposing an audio verification.
The reason for encouraging everyone to vote using the audio system is that it'd provide the blind voters secrecy, and be constantly verifying the accuracy of the system throughout the day.
All this is beside the point, though--your numerous well-reasoned arguments have persuaded me for now that this system would only introduce more attack vectors that I hadn't thought of.
Do your comments about marking imply that you would also avoid the AutoMark ballot marking device, for similar reasons? |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 95
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 8, 2006 - 7:41 pm: |
|
quote:Ron Crane said: "Since these techniques actually change some voters' choices, they do not create mismatches between the audiotape and the resulting paper ballot, and cannot be detected by auditing that relies upon that kind of comparison."
This is the only part of your lengthy response that I might disagree with. From what I understood of Robert's proposal, the ballot would be verified visually by the voter. (Only blind voter's wouldn't have this option, unless they chose to relinquish secrecy by having someone assist them in the visual verification.) I don't believe Robert was proposing an audio verification.
Let me clarify. Presentation frauds influence the voter *actually to cast* the vote the fraudster wants her to cast. They work, of course, only on some subset of undecided voters. But when they work, there's nothing left for "voter verification" to operate on, since the voter actually cast the vote the malicious machine wanted her to cast, and the machine recorded that same vote on the ballot.
quote:All this is beside the point, though--your numerous well-reasoned arguments have persuaded me for now that this system would only introduce more attack vectors that I hadn't thought of.
Do your comments about marking imply that you would also avoid the AutoMark ballot marking device, for similar reasons?
Absolutely. And ditto for "open source" voting systems, which, like all other computer-assisted systems, must be protected by an impractically-large and -complex set of security procedures. And even then they're beyond the supervisory ability of all but the tiny portion of the public that understands computer security -- and that actually is allowed sufficient access to conduct meaningful supervision.
-R
(Message edited by ron_crane on January 08, 2006) |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1480
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 9, 2006 - 2:32 am: |
|
My comment wasn't meant as a response to your justified concern about presentation fraud or ways that the audio could make it more or less likely to vote for a particular candidate. It was only addressing the "verification" stage.
I think ALL your concerns are well-founded and thanks for articulating them so clearly. |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 13
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 9, 2006 - 9:31 pm: |
|
Ron Crane, I think I understand your objections, but I have not yet been convinced that all computer-assisted voting is unacceptable. If there are good procedures for removing an audio voting station from service when it misbehaves (and reverting to human-assisted voting as a fallback) then the only thing a computer tamperer could really hope to accomplish would be to destroy blind voters' ability to vote unassisted: hardly an objective worth any tamperer's time.
I would think that the procedures for taking an audio voting station out of service could be encoded into reasonably simple rules, which could be followed (and possibly even understood) by a person with absolutely zero computer knowledge, i. e. a person who thinks the box contains a little humanoid gremlin, whose tinny little gremlin voice gets funneled out to the voter's headphone.
Of course there will always be some jurisdictions where even simple procedures are not obeyed; but that is unacceptable, and must be stamped out, even when the only voting machine is a felt tip pen. We absolutely must have a system in which officials and poll workers follow the rules (and we must have citizens who can force them to follow the rules). This is true, with or without computer-assisted voting.
Your hypothesis about voting machines printing and scanning "secret" markings, which are not meant to be visible to the human eye, is entirely feasible: millions of Americans already own computer printers and photocopiers which have been tampered with in exactly this way. But this specific problem does not cause me any additional worry, because it will not affect manual ballot counting, and I think we all agree that manual counting is absolutely necessary.
The idea that a tampered machine could actually change the voter's mind (instead of just misrecording the vote) is very interesting, but it doesn't cause me any additional worry. A gross attempt at persuasion would be noticed by a voter, and be captured on audiotape, and cause the machine to be taken out of service. Extremely subtle persuasion would probably go unnoticed, but I would think that its persuasive value would be so weak that the unscrupulous party would do much better by devoting that effort toward ordinary campaigning instead of tampering with audio voting stations.
The idea that blind voters might be forced to push the buttons really hard, if they try to vote against the tamperer's wishes, made me laugh. Not a laugh of derision at your idea, but a quiet laugh of dark humor at the image of cartoonish Snidely Whiplash villainy which arose in my mind. It's not that I doubt that any real person would stoop so low as to put a physical obstruction in the way of a blind person trying to vote; I don't place any limit on the evil of real-world election tamperers. I think it must have been a certain quality of transparent shamelessness in this particular act of evil, which made me laugh and think of cartoon villains.
So I'm not discounting your idea; I'll have to think about it some more. My first reaction (after the involuntary laughter) is that this attack would probably need to be done without the cooperation of the vendor. Difficulty in getting pushed buttons to register correctly will inevitably be seen as a machine failure, and blamed on the vendor, even among people who believe that vendors are incorruptible and computer software is infallible. The typical American voter doesn't get angry when his vote disappears into the ether, but he does get angry when he can't even get the equipment to pretend to record his vote. A fraud which causes people to get angry at the machine (and possibly even physically damage the machine, by whacking the button really hard) is not in the vendor's self-interest. All vendors and local officials, regardless of how corrupt they may be, want the voting process to appear to be smooth and problem-free. So I think it would have to be someone else who would try this attack.
quote:Yet, in real situations, pollworkers and officials routinely disregard even major problems, like when 600 voters somehow "cast" 4,000 votes for a Presidential candidate in Ohio in 2004.
I don't see how we realistically can change this attitude, or if we can, how we can make the change stick over the long term.
Ron, if that is correct, then our country is doomed. Even if we eliminate all voting machines except the felt tip pen, the attitude you described above will destroy democracy.
Regardless of whether we use pens or computers, we absolutely must institute a system under which citizens can force officials and poll workers to follow appropriate procedures. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1489
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 10, 2006 - 2:12 am: |
|
Robert said: The idea that a tampered machine could actually change the voter's mind (instead of just misrecording the vote) is very interesting, but it doesn't cause me any additional worry. A gross attempt at persuasion would be noticed by a voter, and be captured on audiotape, and cause the machine to be taken out of service. Extremely subtle persuasion would probably go unnoticed, but I would think that its persuasive value would be so weak that the unscrupulous party would do much better by devoting that effort toward ordinary campaigning instead of tampering with audio voting stations."
Actually what Ron suggests would be extremely effective for races where people might not be familiar with all the names. Just be a little muddy in one's pronunciation, or use a subtly different tone of voice, and you could influence some very important local elections. Local corruption is a powerful motivating factor. |
Jim Eldon
Voting Rights Forum Participant
Username: Vegsledman
Post Number: 1
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 10, 2006 - 9:29 am: |
|
Robert Munyer wrote:
Regardless of whether we use pens or computers, we absolutely must institute a system under which citizens can force officials and poll workers to follow appropriate procedures.
---
See article at
http://seattletimes.nwsource.com/cgi-bin/PrintStory.pl?document_id=2002123626&zs ection_id=2002107549&slug=danny18&date=20041218
which describes King County WA's governor's race recount. Both partisan appointees applauded the procedure in the strongest terms:
"I'm so impressed with this system," McClellan [Republican] said. "It's near impossible to corrupt, and it seems much more sensitive than a machine count. All the criticisms I hear about what we're doing are wrong."
Reese [Democrat] agreed. "I don't have much faith in the American political system, but I have faith in what we're doing here," he said. "I would put people counting over machine counting any time."
This seems to me a convincing argument for starting with paper ballots (w/braille for the blind?).
-Jim |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 14
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 11, 2006 - 9:06 pm: |
|
Jim Eldon, Braille would be great, except it is going out of style: today most blind children do not learn to read (<http://www.nbp.org/ic/nbp/braille/case_for_braille.html>).
Thank you for linking to that Seattle Times article; it's a good one. The former governor, who claimed that ordinary citizens can't be trusted to count ballots accurately, was just plain wrong. If the procedures are good, ordinary citizens can be trusted to follow (and even understand) them.
I've been thinking about our discussion above, about computer-assisted voting, and I think the difference of opinion boils down to a very similar question: can ordinary citizens, who do not have specialized computer knowledge, be trusted to follow (and understand) the procedures for taking an audio voting station out of service when it misbehaves?
If the procedures are good, I believe the amount of computer knowledge which ordinary citizens would need to have, in order to follow (and even understand) the procedures, is ZERO. In fact, I would say that in these last few years of voting system crisis, the people who have zero computer knowledge have often understood the situation rather better than the people who have moderate computer knowledge.
Imagine a medieval explanation of computer insecurity:
"The Device is controlled by a Demon which lives within. The Alchemist who captured the Demon swears that he has tamed it, and constrained it to serve the Good of all Mankind. In our Tests, the Demon has behaved as promised. But it is still a Demon, and at any Moment it could revert into supernatural Communion with the Prince of Darkness. We must keep Watch, and we must be prepared to cast the Device into the Ocean at the first Sign of Deviltry."
In my opinion, a person who espouses the 12th-century logic above will do a good job in a modern election-- a better job, in fact, than a person who has taken a couple of computer programming courses but who doesn't understand hacking. |
Kathleen Wynne
Moderator
Username: Admin_ii
Post Number: 182
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, January 12, 2006 - 8:09 am: |
|
Robert,
The medieval explanation is an excellent way of looking at computerized voting.
Since I am not a "techie" and have never taken a computer course, nonetheless, it wasn't necessary in order to understand how relatively easy (and tempting) it would be for a technocrat to figure out how to manipulate any one of these electronic voting machines. You don't need a Ph.D. to understand human nature. Also, I knew I wouldn't be satisfied with just a scientific explanation and a pat on the head and "go away and let us fix it" from the experts.
No way. I wanted to do for elections, what Ross Perot was famous for saying he wanted to do with our economy -- "take a look under the hood!" Nothing beats good 'ol American common sense. I'm sure that's why juries are full of average citizens and not lawyers and judges.
Another thing that shouldn't be lost in the shuffle for which side of the fence these experts and election officials eventually choose to be on regarding the solution to the problems we face with election reform...that it was the "citizens", and not the technocrats, who would not be satisfied with a patch here and a patch there to solve the problem. Someday someone should have to answer the question, "why did it take 2 middle-aged women to bring Harri Hursti to America, give him access to the Diebold confidential files found by Bev Harris and ultimately, make it possible for him to turn his theories into the proof?
When Mr. Hursti proved these machines were not only vulnerable to manipulation, but that they were literally "open for business" and should never have been certified in the first place, a phenomonon took place, that didn't seem possible. Experts and election officials were now openly and publicly talking about the lack of security in these machines and actually challenging the vendors. They were being specific in their grievances against these machines and demanding an explanation from the vendors and the testing labs. Wow, we thought, when the California Sec. of State didn't certify Diebold's machines but sent them back to the testing labs for more testing. DOUBLE WOW, we thought...when some states were even getting rid of these machines.
Another thing we've proven in our journey to achieve election reform and I think it's the most important one...citizens have shown why they should always be a major part of the equation in the election process from start to finish. As it should have been all along.
Kathleen Wynne
* * * * * *
* * * * * *
* * * * * *
* * * * * *
Protect election 2006: 'Candid America' project. Don't leave home without your camcorder! What to do:
http://www.bbvforums.org/forums/messages/6/15733.html
|
Jim March
Voting Rights Forum Participant
Username: Jimmarch
Post Number: 97
Registered: 01-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, January 12, 2006 - 10:47 am: |
|
All of this is connected with criticism of the Federal test labs - the ITAs such as Wyle and Cyber.
One of the best "official criticisms" of the labs is the Jefferson report from California:
http://ss.ca.gov/elections/voting_systems/vstaab_volume_test_report.pdf
...particularly the bottom of page 1.
* * * * * *
* * * * * *
* * * * * *
* * * * * *
Protect election 2006: 'Candid America' project. Don't leave home without your camcorder! What to do:
http://www.bbvforums.org/forums/messages/6/15733.html
|
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 15
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Thursday, January 12, 2006 - 9:04 pm: |
|
Kathleen Wynne wrote:
quote:Someday someone should have to answer the question, "why did it take 2 middle-aged women to bring Harri Hursti to America, give him access to the Diebold confidential files found by Bev Harris and ultimately, make it possible for him to turn his theories into the proof?
Kathleen, maybe I can answer that question. I'll try.
The people who couldn't see a problem before Harri Hursti's demonstration just weren't thinking straight. Hursti's demo should not have been necessary.
About five years ago, Dr. Rebecca Mercuri proved that every computerized vote tally can be altered undetectably. Period. No further proof needed.
Even before Dr. Mercuri provided rigorous proof, the problem was intuitively obvious to people who took some time to think about it. Ronnie Dugger had no difficulty understanding it in 1988, and I'm sure many thousands of his readers also understood.
So if you two middle-aged women were the first to attempt something like Hursti's demo, maybe it's because you were the first to understand the mental confusion that made Hursti's demo necessary. I still don't understand it. I bet Dr. Mercuri and the other computer scientists don't understand it either.
Jim March wrote:
quote:One of the best "official criticisms" of the labs is the Jefferson report from California:
http://ss.ca.gov/elections/voting_systems/vstaab_volume_test_report.pdf
...particularly the bottom of page 1.
That's a good report. I used the MTBF from that report to calculate the number of Diebold TSx machines Volusia County would need to buy, if they wanted to be reasonably sure that every precinct would have at least one machine still running at the end of election day. I was told that this calculation helped them decide to change vendors.
Another interesting criticism of the ITAs is here: http://www.avirubin.com/vote/ita.challenge.pdf (a challenge issued in June 2004 by Avi Rubin). |
Samuel Scharff
Voting Rights Forum Participant
Username: Abacus
Post Number: 29
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 13, 2006 - 12:05 pm: |
|
“The people who couldn't see a problem before Harri Hursti's demonstration just weren't thinking straight. Hursti's demo should not have been necessary.”
This is of course correct; but I think there may be an underlying problem which is very important to recognize.
I got this from an interview with Mark Crispin Miller.
In effect the interviewer asked Miller why people seem impervious to the data showing theft of the elections and the abundantly clear technical feasibility of subverting the machines. Miller said, in a way, they’re blinded.
Miller: “Because [they think] it can't happen here. That's the creed we're up against -- a creed based on an absolute estrangement from the wisdom of the Framers. The republic's founders understood that "it" can always happen anywhere, including here. That, indeed, is why they had the wit, and took the trouble, to devise our system with its checks and balances. They would have been amazed that anyone could be naive enough to say that ‘it can't happen here.’
“As that notion is based not on reason or on history but on ideology, it doesn't matter if the risk is wholly plausible--not even if you have a wealth of evidence to make the case that it has happened here. “In fact, resistance to that case seems to grow more intense the stronger it becomes.
“It's a faith-based notion, and so evidence and logic by themselves cannot dislodge it. The only way around the problem is to give up merely arguing with those who keep refusing to believe it, and to take the case directly to the people, insofar as that is possible. I think the people grasp that what has happened here has really happened here. It's those who have a strong material and psychological investments in the status quo--politicians, media types--who won't accept the reality.”
http://www.huffingtonpost.com/bob-cesca/a-conversation-with-mark-_b_12134.html
This seems to say that, while bedeviling politcians and media people is necessary, we won’t make real traction except by raising consciousness with citizens on everyday levels...
Abacus
|
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1510
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 13, 2006 - 12:45 pm: |
|
Sam,
You and Mark Crispin Miller are surely accurate. This issue interacts with many US citizens' deeply-seated framework of reality about their country and government.
The notion that "it can't happen here" (because the USA is Free and Democratic and Better Than Everywhere Else) is based on the very effective brainwashing many of us received as part of our school-age indoctrination (which we typically call education.) Surely most if not all of it was well-intentioned and sincere--but it was brainwashing, all the same.
When we present information that conflicts with or challenges someone's framework of reality we will never be able to argue them into changing their mind. People will cling to their framework for dear life, until their internal timing is right.
We can make information available, and do everything we can to see that the facts reach the mainstream media and the public. But we should expect a persistent drip-drip-drip approach to success (the drops that wear away stones or create cracks that will later split) rather than expecting that any one new scandal or revelation to change someone's mind overnight.
Changing one's framework of reality is something that is intimately personal. The timing is unique and cannot be forced. In fact, attempting to force change of this nature is likely to lead to resistance.
A Taoist approach might be to go around the obstacle--or recede far enough that there is no longer an obstacle. This is an alternative to using force which is guaranteed to create an equal opposing force. Persistently making information available, w/o the energy of forcing, will be more constructive.
Strength in relation to government officials, public institutions, and media is certainly called for. Here, too, the strategies that prove most effective are not necessarily those that involve pushing against an obstacle. (E.g., Kathleen Wynne's dumpster escapades, and posting the info, is a way of following the path of least resistance and being incredibly effective at the same time.) Let the facts speak for themselves.
On the personal level (family, friends, work colleagues), it's rather a question of discerning whose framework is ready to shift, giving people the information they ask for, and respecting their individual timing if they're holding on tight to a dearly-held belief. |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 96
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 13, 2006 - 12:56 pm: |
|
quote:I've been thinking about our discussion above, about computer-assisted voting, and I think the difference of opinion boils down to a very similar question: can ordinary citizens, who do not have specialized computer knowledge, be trusted to follow (and understand) the procedures for taking an audio voting station out of service when it misbehaves?
That isn't really the issue, for a variety of reasons. First, you say "taking *an* audio voting station out of service when *it* misbehaves". I think it's quite clear that, with vendor fraud, misbehavior by one of several identical machines indicates a global problem. Removing "a" machine from service prevents it from cheating further, but does nothing about undetected frauds on the remaining machines, and also about undetected frauds perpetrated by the removed machine before its removal. And there will be undetected frauds, as my 1/8 note shows.
Further, I am not at all convinced that presentation frauds (e.g., modulating the sensitivity of the selection buttons) could not influence enough of the electorate to swing close elections -- assuming that the entire electorate used the audio voting machines in question [1].
quote:If the procedures are good, I believe the amount of computer knowledge which ordinary citizens would need to have, in order to follow (and even understand) the procedures, is ZERO.
This is half correct. Any person of ordinary intelligence and experience can theoretically follow procedures involving the setting up and taking down of machines, at least when those procedures don't involve too much judgement [2]. However, understanding them is something else altogether. And, I would submit, two types of understanding are required adequately to supervise such machines: (a) enough understanding to *feel* that the procedures are necessary (that is, to act automatically in obedience to them); and (b) enough understanding to actually verify the procedures' correctness. Most persons lacking (a) will execute the prescribed procedures less than perfectly well, especially as they become more familiar with the systems and see that their (apparent) failure rate is very low. And persons lacking (b) must perforce "trust the experts" that the procedures are really sufficient to ensure appropriate security. I believe that requiring this kind of trust around the mechanics of elections (read: peaceful, legitimate transitions of power) is perilous to our republic's future. In fact, we're where we are now in large part because of exactly this kind of "trust the experts" ethos.
-R
[1] If only blind and near-blind voters use them (<< 2% of the population), the incentive to use them to defraud will be substantially reduced, per my 1/8 note.
[2] Questions involving the detection of fraud, and the consequent removal of machines from service, involve considerable judgement. How can a volunteer pollworker (having very little training) tell whether the voter made a mistake (e.g., pushed the wrong button), changed her mind after casting her ballot and doesn't want to lose face over it, is trying to monkeywrench the process, or is reporting a real fraud? And how should elections officials handle such reports? What's the threshold for shutting down a single machine? A precinct's worth? The entire jurisdiction's worth? If there's a shutdown, what about the votes already cast on the suspect machine(s)? Should you re-run the election? Can you do so legally (it's far from clear you can do this in, e.g., Presidential races)? What kind of investigation should be launched? Who should conduct it?
The procedures that need to surround e-voting are much more subtle and complex than we've discussed so far. I'm far from convinced that we realistically can formulate them, let alone that we realistically can expect ordinary mortals to execute them properly. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1511
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 13, 2006 - 2:05 pm: |
|
Re: [2]
Thanks for such an explicit description of the problems in how to respond when apparent errors surface. It is much more problemmatic when a machine is involved compared to a paper-only hand-counted system. |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 97
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Friday, January 13, 2006 - 8:01 pm: |
|
By the way, I've thought of another way a malicious vendor could subvert the audio voting machine we've been discussing. The vendor arranges for the machine to send a radio-frequency pulse to the headphone jack immediately before deciding whether to cheat. If the return signal (analogous to a radar return) matches the return signal produced by a single pair of vendor-supplied headphones, the machine knows it's not being recorded, so it cheats. If the return signal does not match, that indicates that something else (possibly a recorder, a second set of headphones, etc.) is connected to the headphone jack, so the machine acts honestly.
The basic theory behind this cheat is from signal processing, and it permits someone to determine an electrical circuit's essential characteristics by measuring its so-called "impulse response".
Everytime you think you've thought of everything, you think of something else. If nothing else gives us pause when considering the idea of e-voting, that should.
-R
(Message edited by ron_crane on January 13, 2006) |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1512
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 3:58 am: |
|
Wow.
I can't help but wonder--might there be ways this procedure might already be in use? I think of all the networked computers, and the times when tabulating computers were networked to media & political parties' (I think) computers.
Or the places where the modem would be sending results to a central tabulating computer. (If not monitored, change the results. If monitored, send "updated" results.)
If any player had access to this methodology--and it's not "classified" or top secret, right?--then they could do this as a way of risk reduction in some of their exploits.
If I'm mixing up apples & oranges here please let me know. It just seemed that the implications could be broader than only dealing with an audio device.
(Message edited by catherine_a on January 14, 2006) |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 98
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 4:24 pm: |
|
> I can't help but wonder--might there be ways this procedure might already be in use? I think of all the networked computers, and the times when tabulating computers were networked to media & political parties' (I think) computers.
Or the places where the modem would be sending results to a central tabulating computer. (If not monitored, change the results. If monitored, send "updated" results.)
If any player had access to this methodology--and it's not "classified" or top secret, right?--then they could do this as a way of risk reduction in some of their exploits.
If I'm mixing up apples & oranges here please let me know. It just seemed that the implications could be broader than only dealing with an audio device. <
This is rather like mixing apples and oranges.
In the uploading-to-tabulator case, a malicious vendor presumably would assume that the phone line was not being monitored, since only law enforcement (and the NSA) routinely monitor such things. But actually monitoring wouldn't make any difference, because the vendor presumably would simply cheat at the DREs themselves and/or in the tabulator.
In the network case, again presumably there isn't any traffic monitoring: remember that we're dealing with entities who are either malicious (malicious vendors) or don't know the first thing about computer security (elections officials). Neither would, of course, want to add network traffic monitoring: the vendors because it'd cost more and might show up their exploits, and officials because they lack the knowledge even to consider it.
-R |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1519
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 8:09 pm: |
|
I wouldn't limit my list of "interested parties" to the vendors or the elections officials. That's the point.
I can think of plenty of situations in which, for example, a corrupt politician or candidate (or their powerful political or corporate friends) might well have buddies in the law enforcement or intelligence agencies who might be willing to lend a helping hand. Or a candidate might have someone on their campaign staff with the requisite IT expertise (and obvious motivation).
Access wouldn't necessarily be problemmatic given the slipshod security approaches and corresponding lack of expertise on the part of election officials. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1522
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 9:03 pm: |
|
Ron, I must have been tapping into something in the ethers. I just came across a new column by Bob Fitrakis on this very subject.
See my post here with the relevant sections: http://www.bbvforums.org/cgi-bin/forums/show.cgi?tpc=8&post=16183#POST16183
The full original article (Did the NSA help Bush hack the vote?) is here: http://www.freepress.org/columns/display/3/2006/1294 |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 99
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 10:52 pm: |
|
quote:I wouldn't limit my list of "interested parties" to the vendors or the elections officials. That's the point.
I can think of plenty of situations in which, for example, a corrupt politician or candidate (or their powerful political or corporate friends) might well have buddies in the law enforcement or intelligence agencies who might be willing to lend a helping hand. Or a candidate might have someone on their campaign staff with the requisite IT expertise (and obvious motivation).
Access wouldn't necessarily be problemmatic given the slipshod security approaches and corresponding lack of expertise on the part of election officials.
True. But they probably wouldn't be using the approach I outlined for cheating with audio voting machines. Instead, they'll take advantage of slipshod physical security to play with the memory cards (the Hursti hack) or the machines themselves, or play man-in-the-middle during the uploading of the votes, or, for that matter, write a virus that targets tabulators.
But you're right about not limiting the list of "interested parties".
-R |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1523
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 11:10 pm: |
|
It was the "man-in-the-middle during the uploading of the votes" that I was thinking of.
You're suggesting that there wouldn't be a need to monitor whether someone (else!) was monitoring. I.e., if someone is snooping they'd assume they were the only ones snooping. This would probably "normally" be the case in such hypothetical situations but perhaps as time goes by this assumption may be less safe. |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1524
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Saturday, January 14, 2006 - 11:12 pm: |
|
Ron, what's your reaction to the Fitrakis column? While it's speculative, it doesn't seem at all far-fetched. |
Ron Crane
Voting Rights Forum Participant
Username: Ron_crane
Post Number: 100
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 15, 2006 - 12:34 pm: |
|
About Fitrakis: I think that Freeman's hypothesis on exit polls is convincing: fraud swung election 2004. How exactly that fraud was accomplished is still open to some speculation, though some methods were clearly used, such as vote suppression in heavily-Democratic precincts in Ohio by inadequate provision of voting machines. The many problems with computer-assisted voting systems (especially touchscreens) strongly suggest fraud there as well. As for cheating via the NSA, I don't see any specific evidence pointing that way, though doing so is certainly not beyond the Bush administration, and, of course, we need thoroughly to investigate Bush's felonious violations of FISA.
Since it's very easy to get appropriate warrants under FISA (even up to 72 hours *after* placing a tap), and Bush never asked Congress to amend FISA to "fix" the "shortcomings" his supporters suggest that he was working around by violating it, I can only conclude that he was doing something that both the FISA court and the GOP-dominated Congress would strongly disapprove. At best it's a large-scale fishing expedition where he tapped many (most? all?) phone calls, hoping to find a terrorist needle in a vast haystack. More likely it's about spying on political opponents, a la Nixon. I wouldn't be the least bit surprised to find that Bush wiretapped such well-known "terrorists" as Howard Dean, Al Gore, Russ Feingold, and maybe even Bev Harris.
-R |
Catherine Ansbro
Frequent Voting Rights Forum Participant
Username: Catherine_a
Post Number: 1530
Registered: 12-2004
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Sunday, January 15, 2006 - 2:03 pm: |
|
There are probably Democrats with intelligence agency contacts as well.
I look at this as an overall possibility for all parties, since I haven't seen many halos on either side.
I think either major party will exploit any opportunity it is able to find.
I was mostly interested in how practical you thought it might be for anyone to tap in to an information flow in a way that could manipulate the data (party or any other vested interest such as a multinational). |
Ron Crane
Frequent Voting Rights Forum Participant
Username: Ron_crane
Post Number: 101
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Monday, January 16, 2006 - 2:22 pm: |
|
quote:I was mostly interested in how practical you thought it might be for anyone to tap in to an information flow in a way that could manipulate the data (party or any other vested interest such as a multinational).
If the system is not well-designed, outsiders might hack it quite easily. If it is well-designed, that could be very difficult. For example, one might prevent vote-falsification via a man-in-the-middle attack by using an appropriate encryption-based authentication protocol. 'Course, if an insider happens to tell someone else what the key is, or if the key is easily-guessed, or if an insider has added a backdoor upload procedure, or....
In sum, it is far easier and more practical to protect a system from malicious outsiders than from malicious *insiders*.
-R |
Brant Lamb
Frequent Voting Rights Forum Participant
Username: Brantl
Post Number: 316
Registered: 01-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 17, 2006 - 10:36 am: |
|
Everybody reading this, please consider the following:
How many of the vulnerabilities of ballots are due to, or enhanced by, your inability to check your own ballot's recording?
If people were able to check (and correct) their own vote, how many of the rest of these hacks fall by the wayside? (Irrespective of the voting platform, provided it produces the appropriate ballot and 'ballot receipt'.)
and, if all legitimate voters can prove which vote is theirs and separate illegitimate votes from legitimate, how many of the remaining methods of hacking also fall by the wayside?(Irrespective of the voting platform, provided it produces the appropriate ballot and 'ballot receipt'.) |
Marian Beddill
Voting Rights Forum Participant
Username: Uu7thprinciple
Post Number: 14
Registered: 08-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Tuesday, January 17, 2006 - 9:01 pm: |
|
If you mean, by 'ballot receipt', a document produced by the system that you take away that shows how you voted, then we must object. No receipts, please.
Any person with a 'domineering' relationship over one or more voters, can use such a receipt to unduly influence votes. Organizations with political agendas can use that clout to force their members to tow the line, by demanding to see the receipt after voting, with punishment for any who voted "wrong".
The voter alone should be able to verify her/his votes on the machine AND on the paper ballot which matches them, while still in the privacy of the voting booth, and that sole paper record goes separately to the jurisdiction central-count facility to be used for auditing.
This produces the v-v-p-a-t that's needed - the audit trail.
Vote-secrecy is the difference between this system and business or banking systems, where there IS a receipt, the choices of the citizen are known, AND there is a process for correction (credits, product returns) if a difference is discovered.
Marian
http://NoLeakyBuckets.org
|
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 16
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | Posted on Wednesday, January 18, 2006 - 4:27 am: |
|
Ron Crane, I still believe that ordinary citizens could exercise ordinary judgment and protect the election. I don't want this to get boring and repetitive, so I'll try to skip over the parts where we have acknowledged agreement or disagreement, and instead only discuss a few parts where we seem to have miscommunicated or missed something.
quote:What's the threshold for shutting down a single machine? A precinct's worth? The entire jurisdiction's worth?
The poll worker would telephone the supervisor of elections, and probably would be asked to play the last part of the audiotape into the telephone. The supervisor would exercise ordinary human judgment, in determining how serious the problem is, and in deciding whether the other machines also need to be removed from service.
Removing machines from service would force blind voters to revert to human-assisted voting, but I would hope that this would eventually become a rare occurrence: accidental foulups would decrease as the vendor would fix its faulty software (or be replaced by another vendor); and deliberate audio voting station tampering would decrease as the tamperers would realize that they can't accomplish anything beyond harassing blind voters, so they would redirect their effort toward finding some other way to cheat.
Note that the supervisor would not need any special computer knowledge to make good decisions: even the medieval theory of demons talking into voice funnels, with no way to tell whether the demons have reverted to being controlled by satan (except by monitoring their behavior) would be enough computer knowledge to allow the supervisor to make good decisions.
If the poll workers and supervisor have criminal intent, then there is a serious problem, and the citizens must somehow put a stop to it. But that is true with any technology, including felt tip pens. If an election is conducted by criminals, the outcome will not be legitimate, regardless of technology, unless the citizens can somehow stop the criminals.
quote:How can a volunteer pollworker (having very little training) tell whether the voter made a mistake (e.g., pushed the wrong button), changed her mind after casting her ballot and doesn't want to lose face over it, is trying to monkeywrench the process, or is reporting a real fraud?
The idea of having sighted volunteers who can get an audio voting station removed from service was suggested mainly as a way to protect blind voters from one particular kind of problem, the only kind of problem from which they can't protect themselves: a misbehaving audio voting station which correctly speaks the voter's choices into the headphone (in the audio vote review at the end of the voting process) and announces that it is printing those choices, but then actually prints different choices on the paper ballot. This problem leaves very clear evidence, which conclusively differentiates it from the three kinds of false reports you mentioned above-- this problem leaves a recital of the voter's final choices on the audiotape, and a printed ballot, which disagree with each other. This specific evidence could not be produced by a voter mistake, or a changed mind, or a monkey wrench attempt.
quote:However, understanding them is something else altogether. And, I would submit, two types of understanding are required adequately to supervise such machines: (a) enough understanding to *feel* that the procedures are necessary (that is, to act automatically in obedience to them); and (b) enough understanding to actually verify the procedures' correctness.
I don't agree that understanding the procedures would be beyond the ability of ordinary citizens. I would say that the only thing a citizen really needs to understand, in order to achieve your A and B above, is this very simple fact: the machines are not infallible or incorruptible. We need to deal with human beings in elections, and we assume that those human beings are fallible and corruptible; our procedures are designed around that assumption. It's not so difficult to understand that the machines are also fallible and corruptible, and that our procedures must be designed around that assumption as well. Everyone who can understand the procedures which deal with the fallibility and corruptibility of human beings, should be able to understand the procedures which deal with the fallibility and corruptibility of machines.
quote:If there's a shutdown, what about the votes already cast on the suspect machine(s)? Should you re-run the election? Can you do so legally (it's far from clear you can do this in, e.g., Presidential races)?
I don't think we will ever see a Presidential re-vote. Some kinds of mistakes are final. We can give ourselves a second chance in the process of counting the ballots, but there is no second chance in the process of casting them (and securing them after they are cast).
I see this concern the same way I see many of your other concerns: valid, but not specific to computer-assisted voting. Paper ballots can be printed wrong or delivered to the wrong precinct. Voters can be given incorrect instructions. (In Duval County, voters were instructed to vote for a Presidential candidate on the first page, and to vote for another Presidential candidate on the second page.) If we discover such a problem after some number of voters have already applied their felt tip pens and deposited their ballots, there is nothing we can do about those voters. We need to do our best to catch problems as soon as possible, with audio voting stations or with felt tip pens. |
Robert Munyer
Voting Rights Forum Participant
Username: Munyer
Post Number: 17
Registered: 12-2005
Best of Black Box? N/A
Votes: 0 (A keeper?) | | | |
