Californians for Electoral Reform PO Box 128, Sacramento, CA 95812 510-527-8025 www.fairvoteca.org 31 July 2003 Secretary of State Kevin Shelley Attn: Touch Screen Report 1500 11th Street Sacramento, CA 95814 FAX: 916-653-9675 Email: TaskForceComments@ss.ca.gov Dear Secretary of State Shelley: Californians for Electoral Reform (CfER) is a state-wide non-partisan membership organization that does educational and advocacy work around instant runoff voting (IRV), proportional representation (PR) systems, and semi-PR systems. We were founded in 1993 under the name of Northern Californians for Proportional Representation, and currently have about 300 members. Our members have been instrumental in every campaign in California to enact legislation related to either PR or IRV. We are writing to you to comment on the Report of the Ad Hoc Touch Screen Task Force ("Report"). Summary CfER believes that a voter-verified audit trail is a necessary component of any voting system. (See Attachment A for our resolution on this issue.) We note that, except for direct recording electronic voting machines (DREs, including touch screens), all voting equipment in California (punch cards, optical scan equipment) provides this voter-verified audit trail; it is the punch card or the optical scan sheet itself. Moving to equipment that does not include a voter- verified audit trail is a step backwards in the security of voting system technology. We do like what DREs have to offer, as they provide a superior user interface for ranked-choice electoral systems such as IRV and the choice voting form of PR. They also provide a superior user interface for cumulative voting. But we do have reservations concerning DREs without a voter-verified audit trail, because they create the opportunity for large-scale fraud, and because there is no recovery from certain classes of machine errors. We also recognize that any jurisdiction that uses DREs must also provide a paper-based solution for the mailed-in absentee ballots, and that modern optical-scan equipment can provide that solution. As stated previously, the optical scan sheet is the voter-verified audit trail for such equipment. Finally, we recognize that DREs have the potential for providing a step forward in accessibility for people with disabilities, especially vision-impaired voters. We believe that, in the long term, there is no fundamental conflict between providing a system that is secure and providing a system that is accessible. However, in the short term, there may be such a conflict, and we believe that prudence dictates that a short-term solution that is at least as accessible and as secure as current non-DRE systems must be chosen over one that may be more accessible but is less secure. The remainder of this letter provides relevant background information on the author, discusses some of the major problems of the Report, and points out some minor problems with the Report. The Author's Background As this letter is partly informed by my personal experience, it would be in order for me to relate my background. In addition to my volunteer position as the President of Californians for Electoral Reform, my day job is as a software engineer for a well-known computer company. Part of my job is dealing with customer escalations due to unexpected hardware failures, and developing software to help diagnose and ameliorate those failures. In the course of my job I have seen hardware fail in ways unanticipated by the hardware designers, sometimes leading to what we in the industry call silent data corruption; that is, the undesired alteration of data in persistent storage that is not detected by the mechanisms that are supposed to detect and prevent such undesired alteration. There is a saying engineers have, known as Murphy's Law, that whatever can go wrong, will go wrong. I know from experience that it frequently does. I am also active in the California Democratic Party, serving on the State Central Committee since 1986 and the State Executive Board since 1993. I only mention my party affiliation and activity because a member of the Ad Hoc Touch Screen Task Force has accused me of being used as a dupe of the Republican Party in an alleged effort to suppress the (presumably) Democratic votes of people with disabilities and others. While I find such a charge laughable, I think it important to acknowledge its existence. In any event, the issue of voting security is one that transcends party lines. Major Problems with the Report The Report (or at least the majority viewpoint in the Report) suffers from three major problems: It understates the security threat that non-voter-verified electronic voting equipment presents, it ignores serious problems with parallel monitoring, and it overstates the problems with printing technology. 1. The Understated Threat The major threat that non-voter-verified electronic voting equipment presents is of an insider attack; that is, a machine that is designed to behave perfectly except when being used in an actual election, when it "shaves" votes from one party's candidates and gives them to another. Attachment B, "How to design a fraudulent DRE," describes such a machine in detail; the main point is that such a machine can only be detected by careful parallel monitoring conducted on election day that simulates actual voting patterns. I'll discuss this more below, but first let's consider whether a reasonable person should take this threat seriously. A reasonable person would have to acknowledge that some politicians sometimes do resort to extra-legal means, including vote fraud, in an attempt to ensure their election. Although it didn't involve voter fraud, perhaps the most famous example is the June 17, 1972 break-in at the Watergate Hotel on behalf of the Nixon re-election campaign. Another example that does involve voter fraud is the 1997 primary mayoral election in Miami, Florida. In that case, the court found "a massive, well-conceived and well- orchestrated absentee ballot voter fraud scheme". (Demos, "Securing the Vote: An analysis of election fraud," http://www.demos-usa.org/demos/pubs/Securing_The_Vote.pdf, pages 39 and 40.) A reasonable person would next consider the recent corporate scandals involving, among others, Enron, Worldcom, and Arthur Andersen, and conclude that sometimes persons in power at corporations engage in dishonest, if not criminal, acts in the pursuit of financial or other gain. A reasonable person would also consider the cases of Robert Hanssen and Aldrich Ames, and conclude that sometimes people who pass the best background checks the FBI and CIA have to offer become dishonest and commit crimes, even of a magnitude that threatens national security. A reasonable person would finally recognize that computer programmers are not immune from the same temptations as others, and have been known to modify software in pursuit of financial or other gain. (See, for example, M. E. Kabay, "Salami Fraud," Network World Security Newsletter, 24 July 2002, http://www.nwfusion.com/newsletters/sec/2002/01467137.html, attached as Attachment C.) A reasonable person would thus be forced to conclude that the possibility of a DRE vendor producing nearly undetectable fraudulent machines, whether deliberately or due to a rogue programmer, is not something to be dismissed lightly. She would also conclude that a voter-verified audit trail would defuse this threat. Additionally, a reasonable person would recognize that anomalous results have been reported with both DREs and optical scan equipment, and the presence of a voter-verified audit trail has allowed the errors with optical scan counting equipment to be corrected. The anomalous results with DREs have just been hand-waved away, creating voter uncertainty in the accuracy of the results. (See, for example, http://www.notablesoftware.com/Papers/CACM1102.html) Had the DREs had a voter-verified paper trail, the uncertainty would not exist. 2. The Problem with Parallel Monitoring The Report suggests that Parallel Monitoring ("random onsite sampling ... of a specific number of machines on Election Day to confirm that each system in operation is registering votes accurately" (Report, page 34)) can be used to detect a fraudulent machine. There are two problems with this approach. First, the administrative burden of conducting Parallel Monitoring is quite heavy. The times when the most ballots have to be entered (lunch time, evening rush) are just those times when election department employees are likely to be called upon to resolve issues in the polling places. Secondly, while the Report suggests that "questionable systems [should be taken] out of service" when Parallel Monitoring discovers a discrepancy, by then it will be too late. As described in Attachment B, if a machine is closed before the election day is over, it will report honest results, thwarting that aspect of Parallel Monitoring. And if the machine isn't closed until the end of election day, then if a discrepancy is discovered it will be too late to do anything about it. There will be no way to prove that the machines not in the Parallel Monitoring pool have similar problems, and absent such proof the courts will most likely be reluctant to order a new election. 3. The Overstated Problems with Printers The opponents of a voter-verified paper audit trail (VVPAT), both in the Report and elsewhere, overstate the problems with printers. Opponents claim that printers are heavy, that jams are problematic, that paper is not accessible to vision-impaired voters, and that a bilingual VVPAT presents secrecy issues. We will deal with each of these in turn. The claim that printers are heavy takes a myopic view of printing technology, probably produced from experience with inexpensive sheet-fed home printers. Anyone who has ever returned a car to an airport car rental return lot has seen the lightweight hand-held printers used to produce the rental receipt. There is no reason similar printing technology could not be used to produce a VVPAT. The same myopia produces the concern about paper jams. Cash registers print receipts on a paper roll, automatically cut when finished, that rarely jams. And if it does jam, it is easily cleared by a relatively unskilled worker. The accessibility issue can be addressed by including a bar-code on the VVPAT, that phonetically encodes the printed information. A hand-held bar-code scanner (manufactured by a vendor different from the one that made the DRE) can be used to "read" the ballot back to the voter. (That the bar-code accurately reflects the printed information can be verified as part of the one-percent manual recount check.) Finally, the secrecy issue around bilingual VVPATs is easily solved by printing all the VVPATs bilingually; if the voter is English speaking, then the machine randomly picks a second language to use so that there are too many ballots containing each language for any particular ballot to be traced back to a small group of minority language speakers. Minor Problems with the Report My feedback would not be complete if I did not point out to you two minor problems I noticed when reading the report. (1) On page six, the third bullet, there appears to be a word missing from between "equipment" and "recognize". From the context, I would imagine that the missing word should be either "should" or "must". (2) On page 36, the first sentence in the first paragraph contains the phrase "before they are not hired". The word "not" should probably be deleted. Conclusion In conclusion, CfER strongly recommends that DREs not be deployed without a voter-verified audit trail. Ideally such an audit trail would be accessible to the disabled community on first deployment, but if not, then public confidence in our voting systems requires that security be implemented first, and accessibility second. I appreciate the opportunity to provide this feedback to you. Sincerely, Stephen A. Chessin, President 1426 Lloyd Way Mountain View, CA 94040 (650)-786-6200 (work) (650)-962-8412 (home) steve.chessin@alum.mit.edu Attachments: A. Resolution on voting equipment features B. How to design a fraudulent DRE C. "Salami Fraud" (http://www.nwfusion.com/newsletters/sec/2002/01467137.html) Attachment A Californians for Electoral Reform PO Box 128, Sacramento, CA 95812 510-527-8025 www.fairvoteca.org RESOLUTION ON VOTING EQUIPMENT FEATURES WHEREAS efficient full-representation or majority-rule voting methods require voters to express themselves more fully (for example, by ranking candidates), which is not possible with the antiquated voting equipment widely used in California; and WHEREAS scrutiny of voting equipment has generated security concerns, especially among devices that directly record votes, such as touch screens, lever machines, and pushbutton devices; and WHEREAS all voting equipment is vulnerable to fraud, and no security measure is perfect, but an independent audit is very effective; and WHEREAS a direct-recording device that produces an independent, voter-verified audit (such as a paper copy retained in a ballot box after voter inspection) affords an unsurpassed combination of security, efficiency, accuracy, flexibility, and ease of use; THEREFORE BE IT RESOLVED that Californians for Electoral Reform advocates purchase or upgrade of voting equipment to allow for straightforward ranking of candidates, rapid tallies, and a voter-verified audit by all California counties as necessary to meet these criteria; and BE IT FURTHER RESOLVED that Californians for Electoral Reform advocates the adoption of these criteria by the Secretary of State for certification of new equipment. Adopted by Californians for Electoral Reform, 1 June 2003. Attachment B Californians for Electoral Reform PO Box 128, Sacramento, CA 95812 510-527-8025 www.fairvoteca.org How to design a fraudulent DRE 31 July 2003 NOTE: The perspective (and voice) is that of a hypothetical DRE vendor employee who has access to the source code of the machines, and whether motivated by bribery, blackmail, or ideology, decides to modify the source code so that the machines will pass all reasonable certification tests and still be able to rig elections. I only care about rigging the elections for President, Governor, US Senate, and Congress (House of Representatives), so those will be the only ones I'll affect. I also only care about the general election, not the primary. Since I don't know who will be running in any given race, I will use the party affiliation of the candidates in determining which votes to alter. Since I don't want the fraud to be obvious, I will take, say, on average ten percent of the votes for party X and give it to party Y. I will display to the voter what they selected, but I will record it internally the way I want. This will only affect close races (55/45 and closer), but then that's the point. To give an election to one party in a district (or state) that's safe for the other would arouse suspicion. Shifting 10% of the votes should be sufficient. (I can also take more votes from the minor parties - no one will notice.) Since the source code will be shown to the testing authorities, I will create my "logic bomb" using the techniques described by Unix co-inventor Ken Thompson in his 1984 ACM Turing Award lecture so that the logic bomb doesn't show up in the source code. (See http://www.acm.org/classics/sep95 for the description.) Since I need to be honest when the elections officials and testing authorities run the logic and accuracy tests, I won't actually alter the ballots as they are cast, but wait until the machine is "closed". If the machine is being closed at a reasonable closing time (say, between 8pm and 8:30pm), and it was opened at a reasonable opening time (say, between 6am and 7:30am), and it's the first Tuesday after the first Monday in November in an even year, then I will go back over all the stored ballots and rewrite ten percent of the votes given to the "wrong" party. If it's not election day, or it's outside normal election times, or the machine is being opened way late or closed way early, I'll assume that this isn't a real election and I won't change any votes. I will use a random-number generator, seeded by the machine-readable serial number, to decide which, and what percentage, of the "wrong" ballots to change. The reason for this will become clear further on. Since the testing people may try to fool me by changing the date and time, I'll fool them instead. The real- time-clock (RTC) chip is set at the factory using a manufacturing interface, not through the screen. The testing authorities and the elections officials don't have access to the manufacturing interface, so they have to use the screen when they want to change the date or time. When they do so, instead of changing what's in the RTC, I'll just store the difference in a memory location, and take that into consideration when displaying the time. For example, if it's noon on Monday, November 1st, 2004, and they set the date to 8am Tuesday, November 2nd, I'll put "20 hours" into the offset location, and add it to the RTC value whenever I need to display it. My logic bomb will only trigger if the RTC says it's really election day and the offset value is zero (or close to zero; maybe I'll let them change the time by a few minutes.) Just to make sure, before I alter any votes, I'll make sure they haven't been cast in the typical logic-and- accuracy-test pattern of one vote for each of the first selections, two votes for each of the second selections, and so on. I'll also check for the "typical" voting pattern of a few voters in the morning, a lunch-time surge, scattered voting in the afternoon, and an evening rush, and only alter the votes if I'm reasonably confident that this is a real election and not an artificial test. About the only way they can detect that I've rigged the machine is by setting aside some machines on election day and casting ballots on them throughout the day using a pre-arranged script. The script will have to include when to cast each ballot as well as how, since it has to mimic an actual polling place. If they find a discrepancy, they'll have to decide if it's the machine, or if they made a mistake in following the script. If they test multiple machines with the identical script, my use of a random-number generator will result in different machines behaving in different ways, further confusing the testers. And if they do decide it is the machine, what are they going to do? The polls are closed! Are they going to order a new election? Not likely! They'll probably order more tests, and on additional machines, and since the election will be over when those tests are run, all the machines will work perfectly. Of course, if there's a voter-verified audit trail, then I'm out of luck. I can't print out the altered votes, because the voter would notice. And if I print out the true votes, but record internally the altered votes, then the one-percent manual recount will spot the discrepancy. My opportunity for committing large- scale voter fraud would be eliminated. Attachment C http://www.nwfusion.com/newsletters/sec/2002/01467137.html This story appeared on Network World Fusion at http://www.nwfusion.com/newsletters/sec/2002/01467137.html Salami fraud By M. E. Kabay Network World Security Newsletter, 07/24/02 One type of computer crime that gets mentioned in introductory courses or in conversations among security experts is the salami fraud. In the salami technique, criminals steal money or resources a bit at a time. Two different etymologies are circulating about the origins of this term. One school of security specialists claim that it refers to slicing the data thinly, like a salami. Others argue that it means building up a significant object or amount from tiny scraps, like a salami. The classic story about a salami attack is the old "collect-the-roundoff" trick. In this scam, a programmer modifies arithmetic routines, such as interest computations. Typically, the calculations are carried out to several decimal places beyond the customary two or three kept for financial records. For example, when currency is in dollars, the roundoff goes up to the nearest penny about half the time and down the rest of the time. If a programmer arranges to collect these fractions of pennies in a separate account, a sizable fund can grow with no warning to the financial institution. More daring salamis slice off larger amounts. The security literature includes case studies in which an embezzler removed 20 cents to 30 cents from hundreds of accounts two or three times a year. These thefts were not discovered or reported; most victims wouldn't bother finding the reasons for such small discrepancies. Other salamis have used bank service charges, increasing the cost of a check by 5 cents, for example. In another scam, two programmers made their payroll program increase the federal withholding amounts by a few cents per pay period for hundreds of fellow employees. The excess payments were credited to the programmers' withholding accounts instead of to the victims' accounts. At income-tax time the following year, the thieves received fat refunds from the Internal Revenue Service. In January 1993, four executives of a rental-car franchise in Florida were charged with defrauding at least 47,000 customers using a salami technique. The federal grand jury in Fort Lauderdale claimed that the defendants modified a computer billing program to add five extra gallons to the actual gas tank capacity of their vehicles. From 1988 through 1991, every customer who returned a car without topping it off ended up paying inflated rates for an inflated total of gasoline. The thefts ranged from $2 to $15 per customer - rather thick slices of salami but nonetheless difficult for the victims to detect. Peter G. Neumann wrote in RISKS 18.75 that in January 1997, "Willis Robinson, 22, of Libertytown, Maryland, was sentenced to 10 years in prison (six of which were suspended) for having reprogrammed his Taco Bell drive-up-window cash register - causing it to ring up each $2.99 item internally as a 1-cent item, so that he could pocket $2.98 each time. He amassed $3,600 before he was caught. Another correspondent adds that management assumed the error was hardware or software and only caught the perpetrator when he bragged about his crime to co-workers." In Los Angeles in October 1998, the district attorneys charged four men with fraud for allegedly installing computer chips in gasoline pumps that cheated consumers by overstating the amounts pumped. The problem came to light when an increasing number of consumers charged that they had been sold more gasoline than the capacity of their gas tanks. However, the fraud was difficult to prove initially because the perpetrators programmed the chips to deliver exactly the right amount of gasoline when asked for five- and 10-gallon amounts - precisely the amounts typically used by inspectors. Unfortunately, salami attacks are designed to be difficult to detect. The only hope is that random audits, especially of financial data, will pick up a pattern of discrepancies and lead to discovery. As any accountant will warn, even a tiny error must be tracked down, since it may indicate a much larger problem. For example, Cliff Stoll's famous adventures tracking down spies in the Internet began with an unexplained 75-cent discrepancy between two different resource accounting systems on Unix computers at the Keck Observatory of the Lawrence Berkeley Laboratories. Stoll's determination to understand how the problem could have occurred revealed an unknown user; the investigation led to the discovery that resource-accounting records were being modified to remove evidence of system use. The rest of the story is told in Stoll's book, "The Cuckoo's Egg" (1989, Pocket Books: Simon & Schuster, New York. ISBN 0-671-72688-9). If more of us paid attention to anomalies, we'd be in better shape to fight the salami rogues. Computer systems are deterministic machines - at least where application programs are concerned. Any error has a cause. Looking for the causes of discrepancies will seriously hamper the perpetrators of salami attacks. From a systems development standpoint, such scams reinforce the critical importance of sound quality assurance throughout the software development life cycle. Moral: Don't ignore what appear to be errors in computer-based financial or other accounting systems.http://www.nwfusion.com/newsletters/sec/2002/01467137.html http://www.nwfusion.com/cgi-bin/mailto/x.cgi Related Links Users wary of ID mgmt. complexity Network World, 07/22/02 Security vendor remakes itself Network World, 07/22/02 All contents copyright 1995-2002 Network World, Inc. http://www.nwfusion.com