December 22, 2024

Seals on NJ voting machines, October-December 2008

In my examination of New Jersey’s voting machines, I found that there were no tamper-indicating seals that prevented fiddling with the vote-counting software—just a plastic strap seal on the vote cartridge. And I was rather skeptical whether slapping seals on the machine would really secure the ROMs containing the software. I remembered Avi Rubin’s observations from a couple of years earlier, that I described in a previous post.

A bit of googling turned up this interesting 1996 article:


Vulnerability Assessment of Security Seals
Roger G. Johnston, Ph.D. and Anthony R.E. Garcia
Los Alamos National Laboratory

… We studied 94 different security seals, both passive and electronic, developed either commercially or by the United States Government. Most of these seals are in wide-spread use, including for critical applications. We learned how to defeat all 94 seals using rapid, inexpensive, low-tech methods.

In my expert report, I cited this scientific article to explain that seals would not be a panacea to solve the problems with the voting machine.

Soon after I delivered this report to the Court, the judge held a hearing in which she asked the defendants (the State of New Jersey) how they intended to secure these voting machines against tampering. A few weeks later, the State explained their new system: more seals.

For the November 2008 election, they slapped on three pieces of tape, a wire seal, and a “security screw cap”, in addition to the plastic strap seal that had already been in use. All these seals are in the general categories described by Johnston and Garcia as easy to defeat using “rapid, inexpensive, low-tech methods”.

Up to this point I knew in theory (by reading Avi Rubin and Roger Johnston) that tamper-indicating seals aren’t very secure, but I hadn’t really tried anything myself.

Here’s what is not so obvious: If you want to study how to lift and replace a seal without breaking it, or how to counterfeit a seal, you can’t practice on the actual voting machine (or other device) in the polling place! You need a few dozen samples of the seal, so that you can try different approaches, to see what works and what doesn’t. Then you need to practice these approaches over and over. So step 1 is to get a big bag of seals.

What I’ve discovered, by whipping out a credit card and trying it, is that the seal vendors are happy to sell you 100 seals, or 1000, or however many you need. They cost about 50 cents apiece, or more, depending on the seal. So I bought some seals. In addition, under Court order we got some samples from the State, but that wasn’t really necessary as all those seals are commercially available, as I found by a few minutes of googling.

The next step was to go down to my basement workshop and start experimenting. After about a day of thinking about the seals and trying things out, I cracked them all.

As I wrote in December 2008, all those seals are easily defeated.

  • The tamper-indicating tape can be lifted using a heat gun and a razor blade, then replaced with no indication of tampering.
  • The security screw cap can be removed using a screwdriver, then the
    serial-numbered top can be replaced (undamaged) onto a fresh (unnumbered) base.

  • The wire seal can be defeated using a #4 wood screw.
  • The plastic strap seal can be picked using a jeweler’s screwdriver.

For details and pictures, see “Seal Regime #2” in this paper.

Seals on NJ voting machines, 2004-2008

I have just released a new paper entitled Security seals on voting machines: a case study and here I’ll explain how I came to write it.

Like many computer scientists, I became interested in the technology of vote-counting after the technological failure of hanging chads and butterfly ballots in 2000. In 2004 I visited my local polling place to watch the procedures for closing the polls, and I noticed that ballot cartridges were sealed by plastic strap seals like this one:

plastic strap seal

The pollworkers are supposed to write down the serial numbers on the official precinct report, but (as I later found when Ed Felten obtained dozens of these reports through an open-records request), about 50% of the time they forget to do this:

In 2008 when (as the expert witness in a lawsuit) I examined the hardware and software of New Jersey’s voting machines, I found that there were no security seals present that would impede opening the circuit-board cover to replace the vote-counting software. The vote-cartridge seal looks like it would prevent the cover from being opened, but it doesn’t.

There was a place to put a seal on the circuit-board cover, through the hole labeled “DO NOT REMOVE”, but there was no seal there:

Somebody had removed a seal, probably a voting-machine repairman who had to open the cover to replace the batteries, and nobody bothered to install a new one.

The problem with paperless electronic voting machines is that if a crooked political operative has access to install fraudulent software, that software can switch votes from one candidate to another. So, in my report to the Court during the lawsuit, I wrote,


10.6. For a system of tamper-evident seals to provide effective protection, the seals must be consistently installed, they must be truly tamper-evident, and they must be consistently inspected. With respect to the Sequoia AVC Advantage, this means that all five of the
following would have to be true. But in fact, not a single one of these is true in practice, as I will explain.

  1. The seals would have to be routinely in place at all times when an attacker might wish to access the Z80 Program ROM; but they are not.
  2. The cartridge should not be removable without leaving evidence of tampering with
    the seal; but plastic seals can be quickly defeated, as I will explain.

  3. The panel covering the main circuit board should not be removable without removing the [vote-cartridge] seal; but in fact it is removable without disturbing the seal.
  4. If a seal with a different serial number is substituted, written records would have to reliably catch this substitution; but I have found major gaps in these records in New Jersey.
  5. Identical replacement seals (with duplicate serial numbers) should not exist; but the evidence shows that no serious attempt is made to avoid duplication.

Those five criteria are just common sense about what would be a required in any effective system for protecting something using tamper-indicating seals. What I found was that (1) the seals aren’t always there; (2) even if they were, you can remove the cartridge without visible evidence of tampering with the seal and (3) you can remove the circuit-board cover without even disturbing the plastic-strap seal; (4) even if that hadn’t been true, the seal-inspection records are quite lackadaisical and incomplete; and (5) even if that weren’t true, since the counties tend to re-use the same serial numbers, the attacker could just obtain fresh seals with the same number!

Since the time I wrote that, I’ve learned from the seal experts that there’s a lot more to a seal use protocol than these five observations. I’ll write about that in the near future.

But first, I’ll write about the State of New Jersey’s slapdash response to my first examination of their seals. Stay tuned.

Hacking the D.C. Internet Voting Pilot

The District of Columbia is conducting a pilot project to allow overseas and military voters to download and return absentee ballots over the Internet. Before opening the system to real voters, D.C. has been holding a test period in which they've invited the public to evaluate the system's security and usability.

This is exactly the kind of open, public testing that many of us in the e-voting security community — including me — have been encouraging vendors and municipalities to conduct. So I was glad to participate, even though the test was launched with only three days' notice. I assembled a team from the University of Michigan, including my PhD students, Eric Wustrow and Scott Wolchok, and Dawn Isabel, a member of the University of Michigan technical staff.

Within 36 hours of the system going live, our team had found and exploited a vulnerability that gave us almost total control of the server software, including the ability to change votes and reveal voters’ secret ballots. In this post, I’ll describe what we did, how we did it, and what it means for Internet voting.

D.C.'s pilot system

The D.C. system is built around an open source server-side application developed in partnership with the TrustTheVote project. Under the hood, it looks like a typical web application. It's written using the popular Ruby on Rails framework and runs on top of the Apache web server and MySQL database.

Absentee overseas voters receive a physical letter in the mail instructing them to visit a D.C. web site, http://www.dcboee.us/DVM/, and log in with a unique 16-character PIN. The system gives voters two options: they can download a PDF ballot and return it by mail, or they can download a PDF ballot, fill it out electronically, and then upload the completed ballot as a PDF file to the server. The server encrypts uploaded ballots and saves them in encrypted form, and, after the election, officials transfer them to a non-networked PC, where they decrypt and print them. The printed ballots are counted using the same procedures used for mail-in paper ballots.

A small vulnerability, big consequences

We found a vulnerability in the way the system processes uploaded ballots. We confirmed the problem using our own test installation of the web application, and found that we could gain the same access privileges as the server application program itself, including read and write access to the encrypted ballots and database.

The problem, which geeks classify as a “shell-injection vulnerability,” has to do with the ballot upload procedure. When a voter follows the instructions and uploads a completed ballot as a PDF file, the server saves it as a temporary file and encrypts it using a command-line tool called GnuPG. Internally, the server executes the command gpg with the name of this temporary file as a parameter: gpg […] /tmp/stream,28957,0.pdf.

We realized that although the server replaces the filename with an automatically generated name (“stream,28957,0” in this example), it keeps whatever file extension the voter provided. Instead of a file ending in “.pdf,” we could upload a file with a name that ended in almost any string we wanted, and this string would become part of the command the server executed. By formatting the string in a particular way, we could cause the server to execute commands on our behalf. For example, the filename “ballot.$(sleep 10)pdf” would cause the server to pause for ten seconds (executing the “sleep 10” command) before responding. In effect, this vulnerability allowed us to remotely log in to the server as a privileged user.

Our demonstration attacks

D.C. launched the public testbed server on Tuesday, September 28. On Wednesday afternoon, we began to exploit the problem we found to demonstrate a number of attacks:

  • We collected crucial secret data stored on the server, including the database username and password as well as the public key used to encrypt the ballots.
  • We modified all the ballots that had already been cast to contain write-in votes for candidates we selected. (Although the system encrypts voted ballots, we simply discarded the encrypted files and replaced them with different ones that we encrypted using the same key.) We also rigged the system to replace future votes in the same way.
  • We installed a back door that let us view any ballots that voters cast after our attack. This modification recorded the votes, in unencrypted form, together with the names of the voters who cast them, violating ballot secrecy.
  • To show that we had control of the server, we left a “calling card” on the system's confirmation screen, which voters see after voting. After 15 seconds, the page plays the University of Michigan fight song. Here's a demonstration.

Stealthiness wasn't our main objective, and our demonstration had a much greater footprint inside the system than a real attack would need. Nevertheless, we did not immediately announce what we had done, because we wanted to give the administrators an opportunity to exercise their intrusion detection and recovery processes — an essential part of any online voting system. Our attack remained active for two business days, until Friday afternoon, when D.C. officials took down the testbed server after several testers pointed out the fight song.

Based on this experience and other results from the public tests, the D.C. Board of Elections and Ethics has announced that they will not proceed with a live deployment of electronic ballot return at this time, though they plan to continue to develop the system. Voters will still be able to download and print ballots to return by mail, which seems a lot less risky.

D.C. officials brought the testbed server back up today (Tuesday) with the electronic ballot return mechanism disabled. The public test period will continue until Friday, October 8.

What this means for Internet voting

The specific vulnerability that we exploited is simple to fix, but it will be vastly more difficult to make the system secure. We've found a number of other problems in the system, and everything we've seen suggests that the design is brittle: one small mistake can completely compromise its security. I described above how a small error in file-extension handling left the system open to exploitation. If this particular problem had not existed, I'm confident that we would have found another way to attack the system.

None of this will come as a surprise to Internet security experts, who are familiar with the many kinds of attacks that major web sites suffer from on a daily basis. It may someday be possible to build a secure method for submitting ballots over the Internet, but in the meantime, such systems should be presumed to be vulnerable based on the limitations of today's security technology.

We plan to write more about the problems we found and their implications for Internet voting in a forthcoming paper.


Professor J. Alex Halderman is a computer scientist at the University of Michigan.

Indian E-Voting Researcher Freed After Seven Days in Police Custody

FLASH: 4:47 a.m. EDT August 28 — Indian e-voting researcher Hari Prasad was released on bail an hour ago, after seven days in police custody. Magistrate D. H. Sharma reportedly praised Hari and made strong comments against the police, saying Hari has done service to his country. Full post later today.

Update: Indian E-Voting Researcher Remains in Police Custody

Update: 8/28 Indian E-Voting Researcher Freed After Seven Days in Police Custody

In case you’re just tuning in, e-voting researcher Hari Prasad, with whom I coauthored a paper exposing serious flaws in India’s electronic voting machines (EVMs), was arrested Saturday morning at his home in Hyderabad. The arresting officers told him they were acting under “pressure [from] the top,” and demanded that he disclose the identity of the anonymous source who provided the voting machine that we studied. Since then, Hari has been held in custody by the Mumbai police and repeatedly questioned.

Recent Developments

There have several developments in Hari’s case since my last post.

On Sunday, about 28 hours after his arrest, Hari appeared before a magistrate in Mumbai and was formally charged for the first time. The officers who arrested him had not stated a specific charge, but they had told him he would be left alone if he would reveal the identity of the source who provided us the machine . Hari has not named the source, and the authorities are now alleging that he took the machine from the government’s warehouse himself.

Specifically, he was charged under Section 454 of the Indian Penal Code (“lurking house-trespass or house-breaking in order to commit [an] offence punishable with imprisonment”), Section 457 (“lurking house trespass or house-breaking by night in order to commit an offence punishable with imprisonment”) and Section 380 (“theft in [a] dwelling house”).

These charges are without merit. Hari has never denied having been in possession of a machine—we even held it up for a photograph to accompany our paper—but the police have offered no evidence whatsoever that Hari ever trespassed in a government warehouse, much less stole a voting machine or anything else from one.

As I have previously stated, Hari obtained access to the machine from a source who approached him earlier this year. We have every reason to believe that the source had lawful access to the machine and made it available for scientific study as a matter of conscience, out of concern over potential security problems.

At Sunday’s hearing, Hari was remanded in police custody until today, when he appeared again before a magistrate and requested bail on medical grounds. (He is reported to be suffering from breathing problems.) The court refused to entertain the bail request and instead granted a police request that Hari remain in custody. The next hearing is scheduled for Saturday, at which time Hari can again seek bail.

One positive development is that Hari’s legal team now includes Mahesh Jethmalani and his father, Ram Jethmalani. I am told they are among the most sought after defense lawyers in India.

Keeping Sight of the Facts

Hari’s arrest has provoked explosive debate in India, not only about the arrest’s apparent political motives, but also about much broader questions our study raised over the security and transparency of India’s voting system. In the midst of this emotionally charged debate, I think it would be helpful to reiterate what our study does and does not reveal.

What the study I coauthored with Hari Prasad shows is essentially two things:

First, far from being “tamperproof,” India’s EVMs are vulnerable to most of the same security problems as the paper ballots they replaced—including an electronic form of booth capturing. Any time during or after the election, dishonest election insiders or other criminals with physical access to the machines can alter the votes stored inside.

Second, unlike the old paper ballot boxes, the EVMs can be tampered with long before elections take place to cause fraudulent results in the future. In other words, a dishonest insider or other criminal could manipulate an EVM today and have it steal votes months or years from now. You can’t do that with a ballot box.

What our study doesn’t show is that any election has ever been stolen by tampering with EVMs. Today’s EVMs are susceptible to tampering, and such tampering has the potential to change results in national elections, but our study does not even attempt to show that any past election result is invalid. Nobody can reasonably claim, based solely on the results we’ve presented, that an election now settled should be overturned.

Now that we know that EVMs have these vulnerabilities, it’s time for the Election Commission of India to stop pretending that the machines used today are perfect, and start working with India’s academic and technical communities to create a voting system that is worthy of voters’ trust.