UConn VoTeR center report: Diebold AV-OS is vulnerable to serious attacks

A powerful new report was released yesterday about the Diebold AccuVote Optical Scan voting terminal (AV-OS). This is a thorough and independent security analysis of the machines that will be used in Connecticut to count votes on November 7. It is based on hands-on experimentation with the system, and is thus more like the Princeton study of the Accuvote TS than my team's earlier source code analysis. Like the Princeton team, the UConn researchers had no access to any internal documentation from the vendor, no source code, or any other information that would have given them an advantage over a random attacker who happened to get access to the machine. Everything they needed to know to perform the attacks was done by reverse engineering the system and observing its behavior. The evaluation was done as part of an evaluation on behalf of the state of Connecticut. They should be commended for not only allowing, but for requesting this study. The report published on their web site explains the attacks in enough detail to be convincing, but some low level details are reserved for another copy of the paper that is only available from the authors by request.

The authors show that "even if the memory card is sealed and pre-election testing is performed, one can carry out a devastating array of attacks against an election using only off-the-shelf equipment and without having ever to access the card physically or opening the AV-OS system box." The attacks presented in the paper include manipulating the count so that no votes for a particular candidate are counted, swapping votes for two candidates, and reporting the results incorrectly based on biases that are triggered under certain conditions.

The attacks in this paper are cleverly designed to make a compromised machine appear to work correctly when the system's audit reports are evaluated or when the machine is subjected to pre-election testing. Besides manipulation of the voting machine totals and reports, the authors explain how any voter can vote an arbitrary number of times using (get this), Post-it notes, if the voter is left unattended.

The attacks are possible because of serious security vulnerabilities that could have been prevented with proper security design. For example, if a serial cable is connected to the AV-OS, an attacker with a laptop can easily obtain a dump of the memory card contents. The dump is obtained in cleartext because the system performs no authentication of any computer that is connected on that port. The dump can be very useful for an attacker, for example, to reconstruct the password and audit records associated with the memory card. The communication between the voting machine and the GEMS tabulation system is unencrypted and unauthenticated. Instead, they use a CRC as a checksum. In our 2003 report, we identified this as a weakness in the Diebold Accuvote TS because CRCs are easily broken. The authors of the new report show how to spoof the GEMS server to the AV-OS, which forms the basis of many of their attacks.

The authors also validate some of the attacks presented earlier by Harri Hursti. They report that the executable code on the memory cards (!!) can be changed so that the counter values change.

Reading this report was a hair raising experience for me. Diebold has clearly not learned any of the lessons from our 2003 report, and it is startling to see that their optical scan ballot counter is as vulnerable to tampering, vote rigging, and incorrect tabulation as the DRE. The big difference, of course, is that optical scanners can be audited. Ballots counted by hand can be compared to the totals of the AV-OS, and machines tabulating incorrectly can be identified. This report highlights the dangers of trusting any component of a voting system that is software based, and the importance of widespread random audits. With optical scan technologies, we can have a secure election even if the systems cheat, due to the opportunity to audit and perform recounts. With DREs, we are left with whatever results the machines compute.

I strongly urge everyone to read this new report out of UConn.

A preview of Florida 2006

There is a story in today's Miami Herald about glitches in the voting machines during early voting. You can only imagine what Election Day will be like if these problems were encountered with a relatively small number of voters at the polls. While most of my comments about e-voting have to do with security threats that are invisible, I am also discouraged by the widespread technical problems that are not just noticeable, but screaming for attention.

Quoting from the article,

"He touched the screen for gubernatorial candidate Jim Davis, a Democrat, but the review screen repeatedly registered the Republican, Charlie Crist. That's exactly the kind of problem that sends conspiracy theorists into high gear -- especially in South Florida, where a history of problems at the polls have made voters particularly skittish."

The article contains other specific examples of the voting machines getting the wrong information on the summary screen. Who knows if the votes that are recorded correspond to the actual choices or to the summary screen. The fact that they don't match is enough reason to conclude that this is an unacceptable way to vote.

Our EAC chairman stated, as I quoted in my previous blog entry, "The bottom line is that our nation's voting equipment, election results and election officials can and should be trusted." I don't see how such a statement can be made in light of the problems with the equipment that early voters in Florida are reporting.

I'm often wondering what it will take to get rid of electronic voting in this country. I used to think that it might take a computer glitch or malicious hacker to cause a ridiculous result, but now I'm thinking that maybe these machines will just fail so miserably that the public will not tolerate them.

A response to EAC Chairman op-ed

In an opinion piece yesterday, EAC chairman Paul DeGregorio argues that academics who are criticizing electronic voting machines are running experiments "in the sterile environment of a laboratory" and that the "hype over hacking [can] discourage voters from participating in elections." He also states that the academic, computer scientists who demonstrate that we can "hack a voting machine" with "unlimited time and resources" are proving nothing. I believe that these comments are aimed more at Ed Felten than at me, but I feel compelled to respond, or at least, to blog about this here.

In my book, Brave New Ballot, I use an analogy about the way the FDA tests drugs to demonstrate how broken the voting system testing process is. This comment by Mr. DeGregorio brings that analogy to mind again. Say that a drug is released to the public and that several well regarded doctors test the drug in their labs and determine that for some reason, this drug is dangerous. Can you imagine someone in the government reacting to that by encouraging people to use the drug and stating that these academic scientists are testing the drug in an unrealistic setting?

But, by responding that way, in a sense, I'm taking the bait because Mr. DeGregorio has actually mischaracterized our position with respect to electronic voting. His op-ed article is based on the flawed assumption that we oppose DRE voting machines because they can be hacked in the lab. While I believe that these machines are indeed vulnerable to undetectable viruses, and while I believe that the demonstrations put forward at Princeton are realistic and frightening, the truth is that focusing a debate on that question is a distraction from our real reasons for opposing these voting machines.

These machines are software based. They require trust in the people who wrote the software. They require that the software be free of bugs, and they provide no means for auditing or checking the vote count. The system is the least transparent voting apparatus I can imagine. Why should we use voting systems that require trust in the manufacturer, trust in their software, and trust that there will never be physical access to the machines by an attacker when there are simple, and available voting technologies (e.g. machine or hand marked paper ballots with precinct optical scan and random audits) that do not require that level of trust?

Paul DeGregorio states in his article:

"The bottom line is that our nation's voting equipment, election results and election officials can and should be trusted. Election officials ... deserve constructive criticism and solutions, not baseless attacks and unfounded accusations about the equipment they use. Attacking their integrity and the system in broad strokes is even less productive."

I have not seen any reason to trust our nation's voting equipment. Trusting it just because an election official says we should is not good enough for me. I want to trust a system because I don't believe it can be compromised, not because someone implies that not trusting it is not patriotic.

This time, Internet voting is being deployed

In 2004, I served on an external peer review panel member for SERVE. Working with David Jefferson, Barbara Simons, and David Wagner, who were also on the panel, we published a report entitled A Security Analysis of the Secure Electronic Registration and Voting Experiment (SERVE). This report led to the cancellation of that risky project.

Well, the Federal Voting Assistance Program (FVAP) is at it again, this time in the form of the Interim Voting Assistance System (IVAS), which is being deployed for this election. I reunited with my co-authors of the SERVE report to publish a new report titled Internet Voting Revisited: Security and Identity Theft Risks of the DoD’s Interim Voting Assistance System. At the end of the report, we summarize the risks of the new system, and I'll repeat them here:

1. Tool One exposes soldiers to risks of identity theft. Sending personally identifiable information via unencrypted email is considered poor practice. No bank would ask their customers to send SSNs over unencrypted email, yet Tool One does exactthat. This problem is exacerbated by potential phishing attacks.
   
2. Returning voted ballots by email or fax creates an opportunity for hackers, foreign governments, or other parties to tamper with those ballots while they are in transit. FVAP's system does not include any meaningful protection against the risk of ballot modification.
   
3. Ballots returned by email or fax may be handled by the DoD in some cases. Those overseas voters using the system sign a waiver of their right to a secret ballot. However, it is one thing for a voter's ballot to be sent directly to their local election official; it is another for a soldier's ballot to be sent to and handled by the DoD – who is, after all, the soldier's employer.
   

Diebold voting machine malfunctions during chief judge retraining

Maryland is providing additional training to chief judges for the November 7 election. Here is an excerpt from an email I received yesterday from one of the two chief judges from my precinct during the primary, and who will serve as chief judge again in the general election (posting this with her permission).

"I wish you could have been with [us] on Saturday when we 'retrained'. There was a Diebold representative there demonstrating the machine and guess what. It malfunctioned! Nothing too bad though. She was trying to cancel the ballot and the machine said it had been inactive and started to shut down."

I think this is worrisome, and I believe that what happened here is that in the chief judge retraining, they carried out scenarios that are not the most expected ones during an election. While the testing that is conducted on the machines during certification and as part of logic and accuracy testing probably covers most of the likely, expected cases, I doubt that something like canceling a ballot in administrator mode gets much test coverage. I think we'll see problems on election day with voting system features that are on the fringes. In Computer Science, boundary conditions are notorious for containing unexpected bugs, and it's scary to think that these can result in the voting machines malfunctioning and shutting down.

This is one of the reasons that I'm nervous about the e-poll books as well as the voting machines. The state says that the e-poll books were tested after the recent bug fixes, but there is no way that any amount of testing can simulate the stress on the system that a real election with hundreds of busy precincts will put on the system. Whenever there is an unusual case, then the system will be running in a state and executing code that was probably not subjected to testing. I don't think that the state elections administrators understand this. It is a bad idea to deploy a buggy system that is patched so close to an actual election. Even if the paper check-in cards are provided as a backup, there will be no way to switch to them if the e-poll books fail during the day because it would take hours to figure out who already voted.

Man of the Year

It started last Thursday. Somebody asked me if I have seen the movie Man of the Year yet. He suggested that I see it right away. On Friday four people asked me if I had seen it yet. They all suggested that I not wait to see it. So, last night, Ann and I got a babysitter and went to the movies for the first time in a couple of years.

Wow.

*** Spoiler alert ***
If you don't want to know what happens in Man of the Year, go see the movie before you read the rest of this.
*** Spoiler alert ***

In the movie, the United States has adopted an electronic touch screen voting system with no paper trail. The manufacturer is a large company whose name begins with a 'D', in this case the name is Delacroy. As the presidential election approaches, a software engineer named Eleanor Green at Delacroy discovers a glitch in the system that might cause an incorrect outcome in the Presidential election. Indeed, an independent candidate, a comedian played by Robin Williams who is only on the ballot in a handful of states, ends up winning the election due to the glitch.

Eleanor Green figures out the cause of the bug in the voting machine. It has to do with the alphabetical ordering of the double letters in the candidates names. The candidates are named Dobbs, Kellogg and Mils. BB comes before GG which comes before LL. While I found the basic premise believable, I think they would have been more convincing, from a technical perspective if the bug had been based on the length of the names. A candidate with a really long name accidentally wins the election because the name overflowed the buffer that held the candidate name in the program. Of course, I'm sure that detail would have been over the head of most viewers.

What I really like about the way this movie portrays the e-voting issue is that it is an unintentional bug in the system that causes the wrong result. In fact, the bug in the Delacroy system is one where it is likely that all manner of testing the machine would not uncover the problem. Unless the testing was done with candidates who had double letters in their names, the problem would remain hidden. When debating with supporters of DREs, I've often been asked how one could rig the voting machines in advance if the candidates names are not known at the time that the software is written. And, while I have an answer to that (described in my book), this movie gives a realistic scenario that also answers the question. An unintentional bug in the system could throw the election in an arbitrary way, while still passing all of the logic and accuracy tests. I've seen enough software bugs to believe this is possible.

For some reason, the reviews of this movie that I found on the Net are negative, but I think it is a must see for anybody interesting in the electronic voting issue.

Another Diebold source code leak

This week, three disks containing Diebold source code, that appear to have come from Wyle Labs and Ciber Inc, the independent testing authorities that certify voting machines for federal qualificaiton, were delivered anonymously to a former Maryland state delegate. The story was covered this morning in the Washington Post and the Baltimore Sun. I was asked by a reporter to inspect the disks to verify their contents, and I enlisted Adam Stubblefield and my Ph.D. student Sam Small, and together we examined them.

The disks contained source code for the BallotStation software, which is the software on the voting machine, and what was labeled as GEMS, which is the back end tabulation system. The GEMS disks were password protected, and while I'm certain we could have cracked them, we chose not to. The BallotStation source code was not protected at all. It was the 2004 version, which is newer than the source code we analyzed in 2003, and appears to be slightly later than the version analyzed by the Princeton team. I would love the opportunity to perform a similar analysis on this code, but yesterday, we were only given the opportunity to inspect to the code to determine whether it was genuine. As a condition to inspecting the disks, we agreed not to make copies or to perform any other activity with the software. An analysis of this source code would answer many questions that I've been asked about whether Diebold fixed the problems we encountered in our previous analysis. Of course, I don't believe that all of the problems we found back then are even fixable, but some of them are.

I've been getting calls all day asking exactly what the significance is of the new software leak. I'm not really sure. If the software leaked out of Diebold, then they obviously have not learned any lessons about securing their proprietary information. If, as I suspect (due to the labels on the disks), the software leaked out of the testing labs, then that is a serious problem that has to be addressed. Don't get me wrong - I think that voting system software should be available to the public, but that is a different issue from whether or not testing labs are competent at protecting things that they are trusted with and that they believe they are supposed to protect.

Dealing with failure

An important sub-area of Computer Science is fault tolerance. In a nutshell, fault tolerance is the ability of a system to continue to function in spite of a failure of one or more of its components. A system that can continue to work even if many parts fail in unexpected ways is said to be more fault tolerant than one that does not.

It seems to me that one of the unheralded problems with the Diebold system, and with DREs in general is that it is extremely fault in-tolerant. Consider a few simple examples from the September 12 Maryland primary:

• In Prince George's County memory cards were accidentally left in the voting machines, causing votes not to be counted initially, and at the very least losing track of the chain of custody of those votes.
  
• In Montgomery county, and in at least one precinct in Baltimore county, smartcards were not delivered to the precincts, causing long lines and people leaving the polls without voting
  
• The removal and reinsertion of a memory card in a Montgomery County precinct caused the voting machine not to tally votes on the memory card. The votes had to be recovered by Diebold off the internal flash memory in the machines, once again losing track of the chain of custody of those votes.
  
• A dead power jack in my own precinct almost caused all the voting machines to run out of power and fail

DREs are highly vulnerable to power outages, software bugs, poll worker errors, hardware failures, and the list goes on. It is very difficult to anticipate how/when the system will experience a small failure, and the system is not fault tolerant, as previous experience has shown.

The reason that I advocate paper ballots is that while a paper based system is not going to be perfect, it will be much more fault tolerant than a fully automated DRE-based system. And on Election Day, we only have one chance to get it right. We need fault tolerance.

A "security feature" from Diebold

The following is an excerpt from an email I received from a gentleman named Walter Mancuso who was a Republican Chief Judge in the September 12 primary in Montgomery County, Maryland.

Approximately a week after the primary I received a telephone call from the Montgomery County Board of Elections inquiring as to why one of the eight touch screen voting machines that we used on election day had recorded no votes, even though 55 voters were logged onto the machine. Neither I nor the Democratic chief judge had any explanation. The person at the [Board of Elections (B of E)] told me that they would investigate, talk to Diebold, and get back to me. After a week I called the Board and asked what they had discovered. I was told that at 6:50 AM (prior to opening the polls) that particular touch screen machine had been rebooted, and the memory card had been removed and reinserted into the machine. I was told that removing the memory card activated a security feature of the touch screen unit, and thus nothing was recorded on the memory card. By the way, no error message was displayed to indicate that that machine had been tampered with and thus should not be used. When we accumulated the votes on the zero machine after the polls closed, that particular machine reported than no voters had used the machine during the election. Thus, prior to talking to Diebold we assumed that the 55 votes were lost.

Walter goes on to explain the the board of elections used the hard drive of the voting machine to recover the 55 missing votes.

So, according to this, there is a security feature that causes a machine with a memory card that is ejected and then reinserted to not record any votes on that memory card. I don't understand what security threat this is designed to counter. Even if a rogue memory card is inserted, how does not recording votes on that card protect anything? Furthermore, this introduces a new risk. A malicious poll worker (i.e. a malicious person who decides to become a poll worker to disrupt the election) could insert and remove each memory card at the precinct during setup. If you believe the message from Walter Mancuso, that would cause none of the votes in that precinct to be recorded anywhere except on the hard drives of the voting machines. But, these votes could only be recovered after the election by the Board of Elections in conjunction with Diebold, as Walter explained later in this message:

However Diebold had good news for us. That good news was that each touch screen unit contained a hard drive, so the B of E, with the help of Diebold was able to recover the “missing” votes from the hard drive.

I worry about the chain of custody of these votes. The chief judges and the other judges have no way to monitor or audit these votes before they are produced and counted by the board of elections, working with the vendor.

NYC book signing 10/4 7 pm

For those of you in New York, I'll be leading a discussion about e-voting and signing copies of BRAVE NEW BALLOT at the McNally Robinson bookstore in New York City at 50 Prince St (between Lafayette and Mulberry) on October 4, 2006. That's this Wednesday evening at 7 pm.

Michigan 5-0; Ravens 4-0

While this blog has been devoted almost entirely to e-voting, I'm going to take a quick break with this post because my favorite football teams are off to an incredible start. Michigan is 5-0, ranked 6th, and appears to be headed for an incredible showdown with Ohio State. I think it is reasonably likely that Michigan and Ohio State will both be undefeated and ranked 2 and 1 respectively when they play.

Meanwhile, the Baltimore Ravens are 4-0 after two unbelievable endings in their last two games. Those two games were pretty painful to watch, but the Ravens somehow pulled them out, due in no small part to their new quarterback, Steve McNair. I still prefer college ball, but when the local NFL team is 4-0 after some pretty frustrating seasons, you gotta love it.

Go Blue!!!
Go Ravens!!!