The Virus Did It

I attended Crypto in Santa Barbara this past week, and I was talking to a colleague of mine from another university. He had served as an expert witness in an interesting case involving a man who had been accused of having illegal pornographic images on his computer. His defense was that his computer had been infected with a malware virus and that "the virus did it." This may seem a little far fetched. However, my friend is a top security expert, and he had disassembled and reverse engineered the virus code, and he showed that indeed the virus was designed to download pornographic images from the Web.

The "virus did it" defense is likely to become more popular as increasingly nefarious online activity is uncovered. In a society where you are innocent until proven guilty, the possibility that a virus performed a malicious action from someone's computer, and that the person was not aware of this, may be enough to provide plausible deniability of almost anything.

Consider the implications of this for electronic voting machines. While the Princeton team showed how a malicious virus could copy itself to infect a precinct full of voting machines, and whereas the California top to bottom review team showed how even a single infected voting machine or memory card can compromise a back end tabulating system, in light of "the virus did it" phenomenon, the attacker's job in disrupting an election is even simpler. All an attacker has to do is leave evidence that casts suspicion that there may have been a virus. If an election audit reveals signs of a possible virus, the results are thrown into doubt, and a losing candidate has a legitimate claim that a virus may have tampered with the results.

The evidence of a possible virus can be created anytime prior to the audit, even after the election is complete. In a computerized system such as a paperless DRE, it is much easier to concoct false evidence that raises suspicion than it is in a paper ballot or end to end cryptographic system.

To visualize how scary this could be, let's take the example of Sarasota County, Florida in the 2006 election. Congressional District 13 was an extremely close race with the strange anomaly that an abnormally high number of undervotes were found in an important race. Several studies and audits were conducted, but the reason for the problem has never been conclusively determined. Now, imagine if an audit had turned up virus code on some of the voting machines. Even if no virus had ever executed or propagated, the mere existence of such code would have created chaos. Taking this idea a step further, imagine if such evidence were found in the Virginia Senate race in 2006. This extremely close race singlehandedly determined the party majority in the Senate.

When defending the use of DREs, vendors and some election officials argue that it would be very difficult to tamper with a voting machine in an undetectable way to change the outcome of the election. While I disagree with this statement, the truth is that it grossly overestimates the job of the attacker. All an attacker has to do is to create the impression that something went very wrong. The losing candidate will do the rest.

If in a future election we begin to suspect that "the virus did it," things are going to get very ugly.

Why nobody wants to buy Diebold Election Systems

In an Associated Press story today, Diebold confirms that they tried and failed to sell their voting technologies business. Given the recent reports in California and Florida, I imagine it will be even harder for them now. I think people, even within Diebold, are coming to the realization that DREs are the wrong model for voting systems. There are several reasons for this.

1. DREs are too complex. There are typically 50,000+ lines of code in a DRE, much of that involves user interface and audio capability, and providing the DRE interface and user experience is not worth the hit in complexity.
   
   
2. DREs serve as a bottleneck on election day. DREs are expensive, and so it is unlikely that precincts will have more than they need. Since voters typically spend several minutes voting, and I've observed as a poll worker that quite a few voters take more than 10 minutes, the potential for long lines is tremendous. Once a backlog of voters is created, it only gets worse, as the effect propagates much like the airline systems gets backed up in a positive feedback loop of delays once some flights are late.
   
   
3. DREs are non-transparent. The public justifiably does not trust them. They cannot be independently audited, despite the vendor's insincere claims to the contrary. Even DREs with a VVPAT cannot be properly audited because they just don't work as we would hope. Voters often do not check the paper. The paper rolls used by most vendors do not lend themselves to easy recounts, and the retrofitting of DREs with VVPAT has led to awkward and sometimes ill defined procedures, especially when a voter disputes the printout.
   
   
4. Finally, a much better model for voting systems exists, namely, paper ballots with optical scan precinct counting and ballot marking machines for disability access.
   

So, it is no surprise that Diebold can't sell their voting business. They'd be as likely to sell 8 track players instead of ipods.

Secretary Bowen's clever insight

On Monday, our NSF ACCURATE center held its second annual EVT conference. It was a smashing success with packed attendance and great papers. Today, we held our Principal Investigator (PI) meeting consisting of the PIs, graduate students and some of our advisors. To all of our amazement, Debra Bowen, the Secretary of State of California, who is on our advisory board, showed up for both days. This is particularly incredible given that last Friday she created a firestorm by decertifying most of the electronic voting machines in her state after the top to bottom review that she ordered showed tremendous flaws in the machines.

Secretary Bowen was an active participant in both our workshop and our PI meeting. Today on a panel of our advisors, she said something that really struck a chord with me. It was a simple comment, but it showed great insight into the computer software process as well as the election system certification process. Bowen's observation was that the certification process is not well suited to software. Most election officials defer to staffers or to academics such as us about technical issues, but Secretary Bowen sounded as much like a computer scientists as a state official this afternoon. She rattled off technical terms that she was completely comfortable with and made arguments based on a level of understanding of technology that I have never seen from a non-computer scientist. It is no wonder that she was able to put together the team led by David Wagner and Matt Bishop to study the machines and to appreciate their findings.

Back to Bowen's comment about software not being suitable for the way election equipment is certified. It is right on the mark. The current certification process may have been appropriate when a 900 lb lever voting machine was deployed. The machine could be tested every which way, and if it met the criteria, it could be certified because it was not likely to change. But software is different. The software lifecycle is dynamic. As an example, look at the way Apple distributes releases of the iPhone software. The first release was 1.0.0. Two minor version numbers. When the first serious flaw was discovered, they issued a patch and called it version 1.0.1. Apple knew that there would be many minor and some major releases because that is the nature of software. It's how the entire software industry operates.

So, you cannot certify an electronic voting machine the way you certify a lever machine. Once the voting machine goes through a lengthy and expensive certification process, any change to the software requires that it be certified all over again. What if a vulnerability is discovered a week before an election? What about a month before the election, or a week after it passes certification? Now the point is that we absolutely expect that vulnerabilities will be discovered all the time. That would be the case even if the vendors had a clue about security. Microsoft, which arguably has some of the best security specialists, processes and development techniques issues security patches all the time.

Software is designed to be upgraded, and patch management systems are the norm. A certification system that requires freezing a version in stone is doomed to failure because of the inherent nature of software. Since we cannot change the nature of software, the certification process for voting machines needs to be radically revamped. The dependence on software needs to be eliminated.

California source code study results

The source code team reports for the California Top to Bottom review of Diebold, Hart and Sequoia's voting systems are now online. These reports are comprehensive and detailed and should mark the end of the use of these voting machines in public elections. From the executive summaries:

Diebold
Our analysis shows that the technological controls in the Diebold software do not provide sufficient security to guarantee a trustworthy election. The software contains serious design flaws that have led directly to specific vulnerabilities that attackers could exploit to affect election outcomes.

Hart
Many of these attacks can be mounted in a manner that makes them extremely hard to detect and correct. We expect that many of them could be carried out in the field by a single individual, without extensive effort, and without long-term access to the equipment.

Sequoia
We found significant security weaknesses throughout the Sequoia system. The nature of these weaknesses raises serious questions as to whether the Sequoia software can be relied upon to protect the integrity of elections. Every software mechanism for transmitting election results and every software mechanism for updating software lacks reliable measures to detect or prevent tampering.

I am most familiar with the Diebold system, and one thing that stands out is how every time there is another study of the Diebold code, more security problems come to light. Here are a few issues that this report identified:

The audit log does not adequately detect malicious tampering.

Buffer overflows in unchecked string operations allow arbitrary code execution.

Integer overflows in the vote counters are unchecked.

Multiple buffer overflows in .ins file handling allow arbitrary code execution on startup.

Setting a jumper on the motherboard enables a bootloader menu that allows the user to extract
or tamper with the contents of the internal flash memory.

Keys used to secure smart cards and election data are not adequately protected.

The machine does not adequately protect the supervisor PIN. (This same problem was identified in this week's Florida report)

Votes can be swapped or neutralized by modifying the defined candidate voting coordinates
stored on the memory card.

OpenSSL is not initialized with adequate entropy

...

And the list goes on. Dozens of such vulnerabilities are identified; I just picked a few at random from the list. This is the code that Diebold produced after they claimed to have fixed the vulnerabilities we found in 2003 and that Ed Felten's group identified last year. The backend GEMS system has its own serious problems as well. It is clear that they are simply not qualified to build these kinds of machines.

As I read the three new reports, I could not help but marvel at the fact that so many places in the US are using these machines. When it comes to perscription medications, we perform extensive tests before drugs hit the market. When it comes to aviation, planes are held to standards and tested before people fly on them. But, it seems that the voting machines we are using are even more poorly designed and poorly implemented than I had realized.

The more these machines are studied, the worse they look.