North Carolina and Voting Machines. Again -- UPDATED

(Note -- see update near the bottom of this article)

Having worked in MIS/IT for most of my life, I'm usually aware, when someone claims that "he computer made a mistake" that someone is actually referring to a defect in design, or are attempting to cover up a manual error or deliberate action.

Oh, there certainly are times when there are equipment malfunctions, or sometimes very subtle errors in underlying OS(operating system) or driver design ("Drivers" are the subprograms that actually make hardware pieces like the network card, or modem, printer or keyboard work, and allow the hardware and OS to "talk" to each other).

Those defects are the grand exception, however.

And something that really is absurd is the proclamation that something that is really quite simple, and straightforward, is that "too difficult" or "too expensive" to do in an automated system.**

An infamous example was the claim, during the recent election cycle, that providing a physical audit trail of votes cast would be "too expensive" in terms of equipment and development effort. ANd the further claim that "it wasn't needed." A claim that was put to the test, and failed, when a special election in Florida was close enough to trigger the mandatory recount required by law.

January 2004: Florida. In a special election for the State House District 91 seat, with only one item on the ballot, ES&S electronic voting machines showed a total of 134 undervotes – that is, 134 ballots in which voters did not select a candidate even though it was a single-race election.

The winner received 12 more votes than the runner-up. Florida law requires a manual recount of invalid votes when the winning margin is less than one-quarter of one percent. However, election officials determined that no recount was required because the 134 invalid votes were cast on electronic voting machines, and there is no record of the original votes.
(EFF - Electronic Voting Machine Information Sheet Election Systems & Software — iVotronic)>

Because there was no verifiable audit trail, they could *not* do the recount.

In 2003, in an election in North Carolina, where there was only one issue on the ballot (a bond inititive), 354 undervotes were recorded. In both these cases, the undervotes point to problems with the voting machines, as it is extremely unlikely that hundreds of voters would show up for a single-issue election, and then purposely cast blank ballots.

In allied news, in 2003, Maryland election officials requested that Diebold, one of the most prominent vendors of e-vote machines, provide printers to each voting kiosk in order to provide voter-verifiable audit trails. In a leaked memo, one of the Diebold staffers stated that they hoped that the company would "..charge them out the wazoo" to add printers.

The general reliability and security of the automated process, sometimes called "Black Box Voting" (BBV) has been shown time and again to be sadly deficient, with failures of physical security, the discovery of "back door access" to software, the proof, again and again, that these machines are not "ready for prime time."

On the matter of simple security of the code, most of these BBV systems are built around the WIndows CE (Compact Edition) OS, which was not designed to be either a crypographically robust or exceptionally secure system. (Windows CE is the OS designed for use in so-called "palmtop" computer systems -- these systems are almost always being used for personal purposes, primarially as "personal Information Managers' (PIMs) and not as secure end-point terminals or systems).

Additionally, the various vendors have refused to allow for independent audit of the code used, claiming that the code represents "trade secrets" and that nobody, even bonded memebers of the various state agencies that will be charged with using or interfacing with the machines, can see the code. The companies often claim that this will enhance the security of their systems, because of the theory of "protection by obscurity," where the code is "protected" from hacking because the code is hidden from view. This view of "security" is basically flawed, because of the quite well-advanced techniques for "Black box analysis" that can reveal the paramters of input used to the system that will create a particular result, often allowing for analysis of the underlying logic involved in the system processes, even without access to the source code. Indeed, these companies have managed to make, as part of their contracts, silence on the part of officials involved with the decision-making process as to just what factors were involoved in the decisions to purchase, or the details of any process used to "certify" the machines as complying with any "industry standard" or legislative requirement.

A 2005 report from the federal Government Accountability Office (GAO) issued a report with the unweildy, but telling title General Accountability Office Report GAO-05-956:ELECTIONS
Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to Be Completed

The GAO report had over 40 recommendations in the areas of product development, acquisition by electoral commissions and agencies, operations of the equipment and systems, standards, testing and overall management/oversight. The report noted, however, that most of the recommendations would not be able to be put in place in time for the 2006 election cycle, even if the efforts to put impliment the recommendations were to commence right away.

IN 2003, however, some of the source code for one of the Diebold systems was retrieved from a public FTP site that Diebold had, and the code was subsequenjtly examined by a number of computer scientists whose disciplines require them to view the suceptability to hacking, "insider" manipulation and general robustness of computing systems and their interfaces, both to other computing systems and to humans. One of these studies was published in the IEEE Symposium on Security and Privacy 2004, which accepted only referreed submissions. The paper here cited ( Analysis of an Electronic Voting System) examined the source code for vunerabilities, and with an eye to malicious manipulation of the systems.

This paper found that the language used for the system code was used in a manner that made it very vunerable to outside attacks (such as the "buffer overflow" hack that can allow "foreign" code to install and run "new" code in the targeted system), that there were insuffcient safeguards against the "insider" attacks that could cause alterations of the vote counts, and that the internal audit safeguards against repeated voting were non-existent. The researchers also found grave problems with the "security" of the smart-card technology used that was supposed to stop an individual voter from casting more than one ballot. From a code auditability/verification standpoint, there apperared to be no evidence that there was any sort of formal change control process to track changes to the source code, and to enforce restriction of just who could commit changes to any modules in the source code repository.

As I noted above, there have been numerous problems with these BBV systems, and, slowly, some of the various states that have these machines in place, or are anticipating purchase, have begun to require more vigorous oversight and requirements for performance. One of the requirements is to have the final version of the source code to be used in the machines be placed in "escrow" locations. This will allow for recertification that the code, in the escrow repository, matches the code actually executed in the voting terminals. Another purpose of "code escrow" is to protect the investment of the machine purchasors in the event that the vendor either goes out of business or exits the vote tabulation industry.

One of the states that made such a legislative requirement is North Carolina, which anticipates that the one-time costs for upgrading and standardizing the voting equipment currently used will be between $43M and $93M. Part of the legislative requirement was (added emphasis is mine) Senate Bill 223:Public Confidence in Elections

State Board of Elections' Role in Purchasing. -- Effective with any upgrade or new voting system purchased beginning August 1, 2005 and effective for any voting system used in the 2006 elections, the State Board of Elections is directed to develop a Request for Proposal (RFP). The RFP would have to include the following requirements:

• Posting a bond or letter of credit to cover damages from defects in its voting system, including the cost of a new election.
• Compliance with federal law.
• The capacity to include in precinct returns the votes cast by voters outside the voter's precinct as required by law.
• For electronic voting systems, the system must generate a paper record of each individual vote cast, which paper record shall be maintained in a secure fashion and serve as a backup record for purposes of hand-to-eye counts, hand-to-eye recounts, and other audits.
• For DREs [Direct Recording Equipment], the paper record must be viewable by the voter before the vote is cast electronically, and the system must permit the voter to
correct any discrepancy between the electronic summary of the vote and the paper
record before the vote is cast.
• Review of source code by the county, the State Board of Elections, the NC Office of Information Technology, and the Chair of any legally recognized political party in NC.
• A statewide price for each unit of the equipment.
• An agreement by the vendor that if it breaches
the upkeep part of the contract or goes into bankruptcy, it will permit the software to be turned over to the county for continuing use during the term of the contract and for review by the people who have a right to review the source code.

Requirements for Voting Systems Vendors. -- Effective with any upgrade or new voting system purchased beginning August 1, 2005, vendors of voting systems in
NC must escrow their relevant source code, keep the escrowed source code up to date and swear that it is the code used in operating voting systems, maintain an active office in NC, and notify the State Board of any known defect in a voting system used in NC. This section also provides that a willful violation of any of the requirements is a Class G felony and that substitution of software into a voting system without notifying the State Board is a Class I felony.

Other violations are punishable by civil penalties of up to $100,000.

Even though the state has mandated these steps in the RPF (Request for Proposal) process, Diebold has decided to contest them, and has received, via a temporary restraining order (TRO), extra time to prepare arguments and extend the time past the previous deadline to submit the RFP. Central to the Diebold objects are the requirements to post the non-performance bond, the code escrow, and the identification of all persons who are authors of the code. (see Diebold in Non-compliance with NC Election Laws). They also received a bonus in the TRO, that was extended to all vendors submitting proposals in response to the RFP, that these vendors would be held exempt from all civil and criminal penalties as outlin3ed in the applicable North Carolina law.

The Electronic Freedom Foundation filed a motionon Nov 16 seeking to have the temporary restraining order vacated, on the grounds that the restraining order is too broad, and that it directly contravenes the letter, intent and effect of the applicable North Carolina law. As noted above, one of the central tenets of the N.C. law was the requirement for code escrow. Because of the effects of the temporary restraining order, that effectivly voids all penalties of the NC legislation, at least one other vendor, who waqs not going to file a bid, because of the escrow requirement, may file a bid after all, if the courts hold that the penalties for not filing code escrow cannot be enforced. The TRO, as it now stands, would leave the state of North Carolina with no redress if the eventual bid winner were to default on any portion of the contract, such as supplying the voter-verifiable printed record or changing the code used in the voting terminals with new, uncertified versions.

This just points up the validity of the saying that what matters in an election may not be who *casts* the votes, but who *counts* the votes.



UPDATE -- On Monday (11/28/05) Diebold's request to be shielded from the legal penalties of the North Carolina law was rejected by Wake County Superior Court Judge Narley Cashwell.

From an AP story:

..But because no one has yet to accuse Diebold of breaking the law, Wake County Superior Court Judge Narley Cashwell declined to issue an injunction that would have protected the company from prosecution. Cashwell also declined to offer an interpretation of the law that would have allayed Diebold's concerns.

"We need to comply with the literal language and the statute," Cashwell said. "I don't think we have an issue here yet." ..

...The dispute centers on the state's requirement that suppliers place in escrow "all software that is relevant to functionality, setup, configuration, and operation of the voting system," as well as a list of programmers responsible for creating the software.

That's not possible for Diebold's machines, which use Microsoft Windows, Hanna [Doug Hanna, a Raleigh-based lawyer representing Diebold] said. The company does not have the right to provide Microsoft's code, he said, adding it would be impossible to provide the names of every programmer who worked on Windows....

Hanna is being both misleading and untruthful, here.

According to SB223,

Effective with any upgrade or new voting system purchased beginning August 1, 2005, vendors of voting systems in NC must escrow their relevant source code, keep the escrowed source code up to date and swear that it is the code used in operating voting systems

The langauage of the bill is quite clear, even toa non-lawyer. The code escrow/identification does not refer to Windows. It refers to the code that is used to run the "voting" and "counting" portion of the "voting system," not the underlying OS that the "voting system" is placed on top of.
-------------------------------
Links:

- EFF - Electronic Voting Machine Information Sheet Election Systems & Software — iVotronic
- General Accountability Office Report GAO-05-956: ELECTIONS
Federal Efforts to Improve Security and Reliability of Electronic Voting Systems Are Under Way, but Key Activities Need to Be Completed
- Analysis of an Electronic Voting System - IEEE Symposium on Security and Privacy 2004. IEEE Computer Society Press, May 2004
- Senate Bill 223: Public Confidence in Elections
- North Carolina Electronic Voting in the News -Miscounts and Crashes
- Diebold in Non-compliance with NC Election Laws
- 11/16/2005 EFF "Motion to Modify or Vacate Temporary Restraining Order"

- 11/28/2005 N.C. Judge Declines Protection for Diebold

----------------------------------------------------------------

**The first time I was really struck by this absurdity in the public arena was almost a decade ago, when the Congress was taking testimony from members of the U.S. banking industry about the (then new) fees being charged to customers who used an ATM machine from a "comptetitor's" network.

What raised my eyebrows were not the fees themselves. Although I still view the front-and-back fees as "double-dipping" for the ATM network owners [they get paid once with the "not our customer" fee and again by the bank that issued the debit/credit card]. And the fees by both the network owner and the issuing bank represent a respectable source of profit.

No, What caught my attention was the claim, by the banking industry, that they shouldn't have to give even a notification, on the ATM display screen, or on a
placard physically attached to the ATM itself, that a "foreign user" fee would be charged, and that the issuing bank might also charge an extra fee.

It is certainly absurd to try to claim that it would be "too expensive" to affix a sign to the front of an ATM itself. If the transaction volume traffic for a location is too low to make the placement of an ATM uneconomical the network won't put them there. ANd, as I recall, the members of the congressional committee also found it an absurd statement.

Equally absurd, but allowed to pass without comment by that committee, was the claim that it would be too expensive in programming time and terms of regular updates (if the fee amount were to change) to even put a disclaimer on the screen about the fees. On the face, it sounds reasonable, except when you reflect upon the fcat that the ATM owners continually update the screen displays every time their banking "products" such as mortgages, home equity loans and checking accounts are touoted, with constantly changing interest rates -- all of whch require much more frequent updates than the imputed fee disclaimer would require. (I don't know if such disclaimers are now required by banking regulations, or the banks thermselves have figured out that the bad customer relations outweighs the profit from the surprise or hidden fee - but every ATM in the US that I've seen in recent years has either the physical sign, an on-screen display or both)