Matter May Have Far Reaching, National Consequences Concerning the Effectiveness of Escrowing Secret Vote-Counting Software...
Posted By John Gideon On 10th July 2007
Blogged by John Gideon and Brad Friedman
The results of California Secretary of State Debra Bowen's "top-to-bottom review" of electronic voting systems previously approved for use by her predecessor is still underway. But before any of the findings from her teams of security specialists, software analysts and voting systems experts have been made public, the unprecedented analysis has already revealed a disturbing anomaly which may have far-reaching implications for both state and federal voting systems laws across the country.
As The BRAD BLOG reported exclusively almost three weeks ago [1] --- precisely zero media outlets bothered to file their own reports on this matter until last weekend --- all voting machine vendors certified in California had submitted their source code to Bowen for the review, except for ES&S, America's largest voting machine company.
After their refusal to submit the code as required for the test, Bowen demanded the source code used for the InkaVote Plus voting systems marketed by ES&S, and used exclusively in Los Angeles, be released to the state by the escrow firm which had been holding it as per state law.
Following Bowen's demand to the escrow company, Iron Mountain Intellectual Property Management, ES&S reluctantly agreed [2] to give their own version of the source code to the state.
Oddly enough at the time, the voting machine company, in an arrogant letter to Bowen (posted here in full by The BRAD BLOG [3]), demanded that she withdraw her request to receive the version of the source code already stored in escrow at Iron Mountain. The letter succeeded in keeping our already-raised eyebrows at full perk, as the demand that Bowen not review the code in escrow, but rather look only at the one ES&S was sending, raised several troubling questions. Among them, we wondered at the time if perhaps the version stored in escrow was not the version actually used on the county's voting systems during last year's election. If so, there could be enormous ramifications for the company, and for the idea of escrowed source code for voting systems in general.
Over the weekend, an article in the Los Angeles Daily News, the first organization to jump into this matter following our series of reports, filed a story on the matter [4] which began to validate our suspicions. The paper reported that due to the late submission, the InkaVote Plus system would not be included in Bowen's "top-to-bottom review", presenting questions about which voting system would be allowed for use in 2008, in the country's most populous county. LA County is larger than many states in America.
It's as yet unclear whether Bowen will completely decertify the InkaVote Plus system for use, or whether she will take other steps.
Perhaps more disturbingly, however, the Daily News report includes comments from CA's Deputy SoS for Voting Systems, Lowell Finley, indicating that our concerns about differences in the submitted and escrowed source code may have been precisely on target.
We contacted Bowen's office for more details, and they shared with us the letter sent from Finley back to ES&S in response to the company's curious demands. The letter is posted in full at the end of this article. And if the issue Finley raises is indeed true, there may be a whole lotta trouble ahead...
"With regard to the InkaVote Plus source code," Finley writes in the letter, "it has come to our attention that there are version number discrepancies between the description provided by ES&S to Iron Mountain of the source code deposited in escrow and the description of the system as certified by the Secretary of State on April 21, 2006."
"As you know, Section 19213 of the Elections Code prohibits any change to a voting system after it has been certified without written notice to and approval by the Secretary, and Section 19103(a) also prohibits use of a voting system if this requirement is not met."
Finley suggests that perhaps the version number discrepancies "may represent no more than typographical errors," before confirming that his office will, in fact, "continue to insist on access to the escrowed source code."
This issue is no small matter.
If ES&S failed to escrow the version of software that was actually certified by the state, the "serious problem" Finley refers to in the letter raises a number of serious questions, all of which could have great potential national consequences. Among the questions:
- Which set of source code, with what version number was actually used in the last election in Los Angeles County? And was it a certified version at all?
- Was the source code recently provided to the state by ES&S the same version as is in escrow at Iron Mountain or that which was certified for use by the state?
- Was the source code provided by ES&S, as per state law, ever federally inspected by an Independent Test Authority (ITA) and qualified by the National Association of State Election Directors (NASED)?
- Why is there even any discussion about whether to decertify the InkaVote Plus voting system at this point? State law appears to have been violated and it is the Secretary of State's duty to take action.
If Finley's comments are accurate, ES&S may have violated state election law. California Election Law, Section 19103 states:
In other words, when a vendor changes versions they are mandated, by law, to put those changes into escrow. They must also have those changes certified at both the federal and state level before the updated software may be used in any California election.
If the system used in Los Angeles Co. has been modified in any way without any notification to the Secretary of State's office --- and that now appears to be very possible --- state law allows administrative relief to include a fine of up to $10,000 per offense, a ban from use of the vendor's product in the state for up to three years, and/or a refund of all money paid by a locality for the voting system in question ($25 million in the case of Los Angeles County).
Prior to the 2004 Presidential Election, when it was revealed that Diebold, Inc. had installed uncertified hardware and software for their touch-screen (DRE) voting systems in several California counties, then-Secretary of State Kevin Shelley decertified the systems, and banned Diebold from further selling that system in the state. Shelley's successor, Bruce McPherson, who was later appointed by Gov. Arnold Schwarzenegger, surprised many by re-certifying the Diebold TSx system despite the discovery of myriad security flaws and previously undisclosed source code which violated the Federal Voting Systems Standards that all systems in the state must comply with prior to being state-certified.
So how far will the state now go in regards to ES&S under a new Secretary of State? Bowen defeated McPherson last November, largely on the promise of taking voting system security serious in the Golden State for the first time since Shelley was removed from office.
The LA County Matter May Have National Consequences...
The questions begged by this matter may have far reaching national consequences. The practice of requiring the escrowing of voting system source code, for later review as needed (for example, in the event that problems or questions are revealed during an election) has been gaining traction around the country. A number of states, as well as pending legislation in both the U.S. House (Rep. Rush Holt's HR 811) and Senate (Sen. Diane Feinstein's S. 1487) require voting machine companies to submit their source code into escrow for use in a later review as may be required.
However, as the Los Angeles situation reveals, there may be few, if any, safeguards keeping a vendor from storing one version in escrow and then using a complete different version in actual elections.
Such a circumstance would not likely be revealed until, and unless, a problem is later discovered. The result could be a false sense of security by voters and elections officials that the escrowing of voting system source code might actually offer any transparency or safety whatsoever.
Rush Holt's controversial federal Election Reform bill, HR 811 [5], when originally introduced, had been written to require complete disclosure of all voting system source code to any member of the public who might be interested in reviewing it. Once the bill underwent changes in the U.S. House Administrative Committee, however, and after intense lobbying by voting machine companies, the language had been changed to require only the escrowing of source code for possible review by "experts", under non-disclosure agreements, in the event of a problem discovered during an election.
But if vendors are responsible for policing themselves in determining which version of source code will be submitted to escrow, the effectiveness of the entire matter of escrowing source code comes into question.
As Bowen's attempt to access the InkaVote Plus source code from escrow is the first known instance of attempting to require such a release, it's troubling that there are already questions about the validity of the practice.
Finley's letter also goes on to describe another possible violation of state law discovered in the 2006 escrow contract between ES&S and Iron Mountain.
According to the missive, the contract (which we have not yet seen) is said to violate the law "which specifically gives the Secretary of State the right of access to escrowed source code for any purpose that is in furtherance of her responsibility for certifying and conducting periodic reviews of voting systems."
Given ES&S' earlier instructions ordering Iron Mountain not to release the source code to Bowen, it sounds as if they may have written something into the contract disallowing release to the SoS without explicit prior approval.
Old Questions Still Unanswered...
Some questions we'd asked previously of Bowen's office still remain unanswered, though they have told The BRAD BLOG they are working towards sending us the answers.
Among the still-unanswered questions concerning ES&S and the InkaVote Plus system specifically:
- Why did ES&S directly provide the source code to the state and not just allow Iron Mountain to deliver the code that is supposed to be on escrow at that facility for purposes such as the state's lawful inspection? (The answer may be in the contractual violation referred to by Finley in his letter.)
- What steps will be taken to ensure that ES&S has complied with state law and the certification agreement regarding that escrow?
- Did ES&S include the environment and compiler used to build the software from the source code?
- If so, will the SoS be doing their own trusted build to compare against the software used in the last election?
- If not, how will they confirm that the source code was actually used to build the software used in the last election?
We will, of course, keep you up to date as we're able to gain answers to so many of the questions this entire matter now raises.
The 3-page July 5, 2007 letter from Deputy SoS Lowell Finley to ES&S' Steven M. Pearson [6]
Article printed from The BRAD BLOG: http://www.bradblog.com
URL to article: http://www.bradblog.com/?p=4784
URLs in this post:
[1] The BRAD BLOG reported exclusively almost three weeks ago: http://www.bradblog.com/?p=4713
[2] ES&S reluctantly agreed: http://www.bradblog.com/?p=4737
[3] posted here in full by The BRAD BLOG: http://www.bradblog.com/?p=4741
[4] filed a story on the matter: http://www.dailynews.com/news/ci_6318162
[5] Rush Holt's controversial federal Election Reform bill, HR 811: http://www.BradBlog.com/Holt
[6] A PDF version is here...: http://www.BradBlog.com/Docs/CA_SoS_Letter_LowellFinley_ESS_070507.pdf
No comments:
Post a Comment