Friday, November 17, 2006

Science Applications International Corporation (SAIC) Electronic Voting System Security Report for the Maryland Board of Elections, Sept. 2003

By Stephen Spoonamore
[Gratis Virginia McCullough]

Under a Freedom of Information Act request in mid-October of 2006 we were provided with an edited, but apparently complete SAIC report (35 MB PDF) dated September 17, 2003, reviewing electronic voting system security, with specific reference to Diebold TS DRE machines. A hugely abbreviated and redacted version of this report (1.3 MB PDF) has been publicly available since October of 2003. These reports are of more than academic interest as many problems with Maryland's Diebold voting machines occurred three years later in the November 7, 2006, election, as documented by TrueVoteMD.

The numerous security issues in the apparently complete report (35 MB PDF) now available match some, but not all of the security issues that have been of concern for some time with regard to electronic voting in general, and Diebold in particular. What sets this report apart are the obvious efforts to redact hundreds of legitimate issues and to add language implying a far greater degree of security than this system will ever be capable of providing. One has the impression, reading the complete report, that an extensive effort was made to make a damning document politically palatable.

It appears to us that the Maryland State Board of Elections is overseen by five board members who, unfortunately, do not have very much, if any, technical training. By the nature of their roles they been dependant on professional staff and consultants. Quite obviously they have not been well served by their staff or consultants as regards to security, software assurance, testing, or system risk analysis. Further, the SAIC report primarily addresses security issues at the state level (SBE), as they were contracted to do, whereas attacks seem most likely to occur at the county level. While problems with Local Boards of Elections (LBE) are discussed, apparently none were examined in detail during the three week period of August 5 to August 26, 2003, in which the risk assessment was carried out. However, SAIC did interview a number of individuals from Montgomery and Prince George counties (Appendix C) during their investigation.

After reviewing the SAIC report as first written, the 90% of the content that was then redacted, and the few, but highly dangerous additions of language implying a false degree of security, it appears that the board and the people of Maryland are the victims of, at the very least, malicious deception and, more likely, fraud.

The SAIC report is an unambiguous warning of the clear and present dangers of using a voting system riddled with flaws. As SAIC notes (p. 20) "It is prudent to assume that where vulnerabilities exist there is the possibility the vulnerability will be exploited." This in a system where the simplest mistake, or deliberate misuse of the system by a single person can lead to catastrophic results. We also found it curious that in the human threat sources (Fig. 5.1, p. 21) SAIC did not include a "Foreign State", e.g. China. In addition, the report makes it evident that the SAIC auditors were not permitted to review major sections of the code in the system they considered critical and requiring further investigation.

There is also a clear indication that election security for voting machines will grow into a bureaucracy of its own. Initially, three new positions were to be created just at the state level. No estimate of additional security personnel required at the county levels was given. As a System Security Plan (section 2.1.3, p. 4) was not in place, it is obvious no consideration was given to the ultimate cost of implementing the security and audits deemed essential.

Among the elements the SAIC report does address:

The Diebold Touch Screen (TS) DRE voting machine works on the inherently buggy and attack-prone Microsoft Windows CE operating system and requires serious oversight at all voting locations by technically-skilled individuals.

The voting machine software, including GEMS, is written in the widely used, and insecure, C++ programming language.

Votes are stored on an unencrypted PCMCIA memory card. In practice these cards have developed a tendency to wander off on their own and become lost, particularly since the use of the modem included in the DRE has been largely, and wisely abandoned.

The TS machine is using a series of uninspected, untested, and custom operations not made available to SAIC for this review.

The TS machine testing mode in no way validates that the actual election mode is working properly, it only tests that the ballot is set up correctly.

The TS machine and GEMS server lack auto-audits, fault, or tamper reporting in its software.

The TS machine does not have a tamper shut-off if opened during voting operations.

The TS machine has built-in erasure features generally forbidden in secure systems.

The GEMS server uses an unencrypted Microsoft Office Access database to secure the most sensitive and important election data.

The motherboard with boot code is built and installed in China and each machine is not audited for malware.

The primary programming operations for the "confidential" TS DRE to count from 0 to ~2000 are done overseas by programmers of unknown allegiance or nationality.

There seems to be the naive assumption that if they just don't connect the voting machines to the Internet that most of their security problems are solved.

Despite claims to the contrary, but made very clear in the SAIC report, the TS machines and central accumulator are a totally networked system using a mixture of hard-ports and IR ports for numerous purposes both on the upload and download of votes, the update of software, the loading of ballots, and patch management. Machines may be off-network while in voting mode, or may not be, it is impossible to tell on the version of the machine tested.

Even such elementary steps as installing firewalls and antivirus software on the Windows-based GEMS server and keeping offisite backups of the voting records were not being taken.

And all this complexity for what?

We would hope any voting system would simplify, validate, and better assure that a few times a year one can do a transparent count from 0 to maybe 2000 at each ballot box for each issue or candidate. That is not very hard to do. Especially when the basic entry increments are +1 or +0 each time. Yet somehow Diebold is actually taken seriously that it has inviolable trade secrets inside their voting machines.

Compare these voting machines with the very complex issues in credit card and ATM networks. In those networks all certified firms are given 100% access to every line of code, every piece of hardware, every instruction set, every manufacturing plant, and every interface and switch. Every day IT security structures manage 9-10 billion such highly sensitive transactions. Even with 100% access to every element of all systems, a background "fault, error, and fraud" rate between 0.2% and 2.5% depending on the region, networks, and local regulations is considered acceptable.

If we were handed a thorough report, as the SAIC one was pre-redaction, our recommendation would be to shut down and scrap the entire system.

We've seen many research projects make it to the stage SAIC documents and then be rejected as not cost effective, unreliable, insecure, untrustworthy vendor, lack of documentation, inability to scale, and so on. It is quite apparent that Maryland, nor any other state, has conducted such a standard review of electronic voting, largely because of the mandate of the Help America Vote Act of 2002 (HAVA) sponsored by Republican Congressman Bob Ney of Ohio.

Had we been given the complete report two years ago it would have been our recommendation to shut down the system immediately, move to manual or other back-ups, and immediately begin a fraud investigation.

Instead, it appears that in the fall of 2003 parties, at this time unknown, redacted 90% of the report and added reassuring language to allow the voting system to move forward for public use in general elections. It is clear from some of the reports presented to the Maryland Board of Elections that they must "know" they have a problem. However, they clearly haven't gotten their minds around what the shape and size of it may be.

Further, we note that the HAVA sponsor, Republican Congressman Bob Ney of Ohio, pled guilty on October 13, 2006, to conspiracy and making false statements, acknowledging taking trips, tickets, meals, and campaign donations from disgraced lobbyist Jack Abramoff in return for official actions on behalf of Abramoff clients. Rumor has it that those clients included Ohio-based Diebold. It is hardly a secret that the Diebold CEO at the time, Wally O'Dell, was a leading financial supporter of Republican candidates.
BONUS NOTE #1: The Board of Elections was put on further notice of another serious security flaw in their systems in mid-October 2006. They were provided a report that the reason for some DRE jams in the primary was the failure of the DRE machines to erase the Voter Access Cards in previous elections. Diebold has previously provided assurances that during voting there are no pieces of software capable of erasing any information installed on any DRE machines. Normally you either can or can not have software with erasure systems on one machine. We leave it to a forensic audit to determine which is correct.

BONUS NOTE #2: Several factories in China that are known to have, at times, made a large number of motherboards for Diebold's lowest-end hardware products (including the TS line) have recently been decertified by U.S. manufacturers to make motherboards and control boards for financial management or Point of Sale products. This was based (primarily) on repeated findings of rogue code on their products during Q&A testing. After several efforts to resolve the matter the audit teams determined this code was not accidental but had been installed with future unapproved intent.

Has the Maryland Board of Elections ever determined if the motherboards in their machines have any rogue code? SAIC wanted to know the same thing.

BONUS NOTE #3: In managing parallel audits the intent is to choose machines after they are configured, and in the real environment they will be used in, without letting anyone you are overseeing know you are doing it in advance. By moving all the machines to a single location you instantly inject a new set of variables into the problem. If we had installed rogue tools for input or extraction usage we would now be overjoyed. You are now moving the machines out of the places where this bad-actor event might be detected into an isolated sub-zone. A parallel test might detect a time-released trojan, a hard-coded trojan, and a number of other faults. But not an active day-0 attack.

BONUS NOTE #4: 600 temporary employees of basically unknown background are given only four hours of training by Diebold for an election. Once they have that training they have virtually unfettered access to Maryland's future. As a matter of principle one should be checking their background at least for criminal history. Indeed, they should also be checked for history in political processes and for even moderate understanding of programming. If any one of those temps is a moderate hacker who dumbed down his/her resume and gets a job on the election staff, the State may never know it has been attacked.

Stephen Spoonamore
Chief Executive Officer, Cybrinth

Charles E. Corry, Ph.D., F.G.S.A.
President, Equal Justice Foundation