November 27, 2024

Posts Comments

California review of the ES&S AutoMARK and M100

March 26, 2008 by

California’s Secretary of State has been busy. It appears that ES&S (manufacturers of the Ink-a-Vote voting system, used in Los Angeles, as well as the iVotronic systems that made news in Sarasota, Florida in 2006) submitted its latest and greatest “Unity 3.0.1.1” system for California certification. ES&S systems were also considered by Ohio’s study last year, which found a variety of security problems.

California already analyzed the Ink-a-Vote. This time, ES&S submitted their AutoMARK ballot marking device, which has generated some prior fame for being more accessible than other electronic voting solutions, as well has having generated some prior infamy for having gone through various hardware changes without being resubmitted for certification. ES&S also submitted its M100 precinct-based tabulation systems, which would work in conjunction with the AutoMARK devices. (Most voters would vote with pen on a bubble sheet. The AutoMARK presents a fancy computer interface but really does nothing more than mark the bubble sheet on behalf of the voter.) ES&S apparently did not submit its iVotronic systems.

The results? Certification denied.

Let’s start with the letter from the Secretary to the vendor and work our way down.

ES&S failed to submit “California Use Procedures” to address issues that they were notified about back in December as part of their conditional certification of an earlier version of the system. This can only be interpreted as vendor incompetence. Here’s a choice quote:

ES&S submitted what it stated were its revised, completed California Use Procedures on March 4th. Staff spent several days reviewing the document, which is several hundred pages in length. Staff found revisions expressly called for in the testing reports, but found that none of the changes promised two months earlier in Mr. Groh’ s letter of January 11, 2008, were included.

The accessibility report is very well done and should be required reading for anybody wanting to understand accessibility issues from a broad perspective. They found:

  • Physical access has some limitations.
  • There are some personal safety hazards.
  • Voters with severe manual dexterity impairments may not be able to independently remove the ballot from the AutoMARK and cast it.
  • The keypad controls present challenges for some voters.
  • It takes more time to vote with the audio interface.
  • The audio ballot navigation can be confusing.
  • Write-in difficulties frustrated some voters.
  • The voting accuracy was limited by write-in failures.
  • Many of the spoken instructions and prompts are inadequate.
  • The system lacks support for good public hygiene.
  • There were some reliability concerns.
  • The vendor’s pollworker training and materials need improvement.

Yet still, they note that “We are not aware of any public device that has more flexibility in accommodating the wide range of physical and dexterity abilities that voters may have. The key, as always, is whether pollworkers and voters will be able to identify and implement the optimal input system without better guidance or expert support. In fact, it may be that the more flexible a system is, the more difficult it is for novices to navigate through the necessary choices for configuring the access options in order to arrive at the best solution.” One of their most striking findings was how long it took test subjects to use the system. Audio-only voters needed an average of almost 18 minutes to use the machine on a simplified ballot (minimum 10 minutes; maximum 35 minutes). Write-in votes were exceptionally difficult. And, again, this is arguably one of the best voting systems available, at least from an accessibility perspective.

Okay, you were all waiting to learn more about the security problems. Let’s go. The “red team” exercise was performed by the Freeman Craft McGregor Group. It’s a bit skimpy and superficial. Nonetheless, they say:

  • You can swap out the PCMCIA memory cards in the precinct-based ballot tabulator (model M100), while in the precinct. This attack would be unlikely to be detected.
  • There’s no cryptography of any kind protecting the data written to the PCMCIA cards. If an attacker can learn the file format (which isn’t very hard to do), and can get physical access to the card while in transit or storage, then the attacker can trivially substitute alternative vote records.
  • The back-end “Election Reporting Manager” has a feature to add or remove votes from the vote totals. This would be visible in the audit logs, if anybody bothered to look at them, but these sorts of logs aren’t typically produced to the public. (Hart InterCivic has a very similar “Adjust Vote Totals” feature with similar vulnerabilities.)
  • The high speed central ballot tabulator (the M650) writes its results to a Zip disk, again with no cryptography or anything else to protect the data in transit.
  • The database in which audit records are kept has a password that can be “cracked” (we’re not told how). Once you’re into the database, you can create new accounts, delete old audit records, and otherwise cause arbitrary mayhem.
  • Generally speaking, a few minutes of physical access is all you need to compromise any of the back-end tools.
  • All of the physical key locks could be picked in “five seconds to one minute.” The wire and paper-sticker tamper-evidence seals could also be easily bypassed.

And then there’s the source code analysis, prepared by atsec (who normally make a living doing Common Criteria analyses). Again, the public report is less detailed than it can and should be (and we have no idea how much more is in the private report). Where should we begin?

The developer did not provide detailed build instructions that would explain how the system is constructed from the source code. Among the missing aspects were details about versions of compilers, build environment and preconditions, and ordering requirements.

This was one of our big annoyances when working on California’s original top-to-bottom review last summer. It’s fantastically helpful to be able to compile the program. You need to do that if you want to run various automated tools that might check for bugs. Likewise, there’s no substitute for being able to add debugging print statements and use other debugging techniques when you want to really understand how something works. Vendors should be required to provide not just source code but everything necessary to produce a working build of the software.

The M100 ballot counter is designed to load and dynamically execute binary files that are stored on the PCMCIA card containing the election definition (A.12) in cleartext without effective integrity protection (A.1).

Or, in other words, election officials must never, ever believe the results they get from electronic vote tabulation without doing a suitable random sample of the paper ballots, by hand, to make sure that the paper ballots are consistent with the electronic tallies. (Similarly fundamental vulnerabilities exist with other vendors’ precinct-based optical scanners.)

The M100 design documentation contains a specification of the data structure layout for information stored on the PCMCIA card. The reviewer compared the actual structures as defined in the source code to the documentation, and none of the actual structures matched the specification. Each one showed significant differences to or omissions from the specification.

I require the students in my sophomore-level software engineering class to keep their specs in synchrony with their code as their code evolves. If college sophomores can do it, you’d think professional programmers could do it as well.

The user’s guide for the Election Reporting Manager describes how a password is constructed from publicly-available data. This password cannot be changed, and anyone reading the documentation can use this information to deduce the password. This is not an effective authentication mechanism.

While this report doesn’t get into the ES&S iVotronic, the iVotronic version 8 systems had three character passwords, fixed from the factory. (They apparently fixed this in the version 9 software which is now already a few years old.) You’d think they would have gone around and fixed this issue elsewhere in their software, since it’s so fundamental.

A.4 “EDM iVotronic Password Scramble Key and Algorithm”: A hardcoded key is used to obfuscate passwords before storing them in a database. The scrambling algorithm is very weak and reversible, allowing an attacker with access to the scrambled password to retrieve the actual password. The iVotronic is supported by the Unity software but is not being used for California elections.

Well, okay, maybe they didn’t fix the iVotronic passwords, then, either. Other passwords throughout the system are similarly hard-coded and/or poorly stored. And, given that, you can trivially tamper with any and all of the audit logs in the system that might otherwise contain records of what damage you might have done.

In the area of cryptography and key management, multiple potential and actual vulnerabilities were identified, including inappropriate use of symmetric cryptography for authenticity checking (A.9) and several different very weak homebrewed ciphers (A.4, A.7, A.8, A.11). In addition, the code and comments indicated that a checksum algorithm that is suitable only for detecting accidental corruption is used inappropriately with the claimed intent of detecting malicious tampering (A.1).

We’ve seen similar ill-conceived mechanisms used by other vendors, so it’s similarly unsurprising to see it here. The number one lesson these vendors should take home is thou shalt not implement thine own cryptography, particularly when the stuff they’re doing is all pretty standard and could be pulled from places like the OpenSSL library support code. And even then, you have to know what you’re doing. As Aggelos Kiayias once quipped, don’t use cryptography; use a cryptographer.

The developers generally assume that input data will be supplied in the correct expected format. Many modules that process input data do not perform data validation such as range checks for input numbers or checking validity of internal cross references in interlinked data, leading to potentially exploitable vulnerabilities when those assumptions turn out to be incorrect.

They’re talking about buffer overflow vulnerabilities. This is one of the core techniques that an attacker might use to gain leverage. If an attacker compromises one solitary memory card on its way back to Election Central, then corrupt data on that might be able to attack the tabulation system, and thus effect the outcome of the entire election. This report doesn’t contain enough information for us to conclude whether ES&S’s Unity systems are vulnerable in this fashion, but these are exactly the kinds of poor development practices that enable viral attacks.

Finally, a few summary bullets jumped out at me:

  • The system design does not consistently use privilege separation, leading to large amounts of code being potentially security-critical due to having privileges to modify data.
  • Unhelpful or misleading comments in the code.
  • Subjectively, large amount of source code compared to the functionality implemented.

Okay, let’s get this straight. The code is bloated, the comments are garbage, and the system is broadly not engineered to restrict privileges. Put that all together, and you’re guaranteed a buggy, error-prone, security vulnerable program that must be incredibly painful to maintain and extend. This is the kind of issue that leads smart companies to start over from scratch (while simultaneously supporting the old version until the new version gets up to speed). Is ES&S or any other voting system vendor doing a from-scratch implementation in order to get it right? They’ll never get there any other way.

[Sidebar: I live in Texas. Texas’s Secretary of State, like California’s, is responsible for certifying voting equipment for use in the state. If you visit their web page and scroll to the bottom, you’ll see links for each of the vendors. There are three vendors who are presently certified to sell election equipment here: Hart InterCivic, ES&S and Premier (née Diebold). Nothing yet published on the Texas site post-dates the California or Ohio studies, but Texas’s examiners recently considered a new submission from Hart InterCivic. It will be very interesting to see whether they take any of the staggering security flaws in Hart’s system into consideration. If they do, it would be a big chance for Texas to catch up to the rest of the country. Incidentally, I have offered my services to be on Texas’s board of election examiners on several occasions. Thus far, they haven’t responded. The offer remains open.]

Filed Under: Uncategorized Tagged With:

Sequoia's Explanation, and Why It's Not the Whole Story

March 20, 2008 by

I wrote yesterday about discrepancies in the results reported by Sequoia AVC Advantage voting machines in New Jersey.

Sequoia issued a memo giving their explanation for what might have happened. Here’s the relevant part:

During a primary election, the “option switches” on the operator panel must be used to activate the voting machine. The operator panel has a total of 12 buttons numbered 1 through 12. Each party participating in the primary election is assigned one of the option switch buttons. The poll worker presses a party option switch button based on the voter authorization slip given to the voter after signing the poll book, and then the poll worker presses the green “Activate” button. This action causes that party’s contests to be activated on the ballot face inside the voting booth.

Let’s assume the Democrat party is assigned option switch 6 while the Republican Party is assigned options switch 12. If a Democrat voter arrives, the poll worker presses the “6” button followed by the green “Activate” button. The Democrat contests are activated and the voter votes the ballot. For a Republican voter, the poll worker presses the “12” button followed by the green “Activate” button, which then activates the Republican contests and the voter votes the ballot. This is the correct and proper method of machine activation when using option switches.

However, we have found that when a poll worker selects the lower of the two assigned selection codes, followed by pressing an unused selection code and then pressing the green “Activate” button, the higher numbered party on the operator panel has its contests activated instead while the selection code button for the original party stays active on the operator panel.

Using the above example with the Democrat Party as option switch 6 and the Republican Party as option switch 12, the poll worker presses button 6 for Democrat. The red light next to button number 6 lights up and the operator panel display will show DEM. The poll worker then presses any unused option switch. The red light stays lit next to option switch 6 and the display still says DEM. Now the poll worker presses the green “Activate” button. The red light stays lit next to button number 6, but the operator panel display now says REP and the ballot in the voting booth will activate the Republican party contests.

In each and every case where a machine displays the party turnout issue at the close of the polls, this is the situation that would have caused it, and it can be duplicated on any machine. In addition, for this situation to have occurred, the voter that was in the voting booth at the time of the poll workers action would have voted the opposite party ballot instead of telling the poll worker that the incorrect ballot was activated and the machine would not allow them to vote the party they intended. If they had informed the poll worker, they could have made the party selection change and the voter would have then voted the correct ballot style.

Several points are in order.

First, it’s obvious from this description, and from the fact that this happened on so many machines across the state, that even if Sequoia’s explanation is entirely correct, there was some kind of engineering error on Sequoia’s part that caused the machines to misbehave. Sequoia has tried to paint the anomalies as poll worker error, but that’s not plausible in light of Sequoia’s own explanation.

Consider the scenario described above: there is a moment when the red light next to the DEM button is lit, the operator panel displays DEM, then the poll worker presses the Activate button – and the Republican ballot is activated. No competent engineer would design a system to work that way.

No competent engineer would design this system to ever display REP in the operator panel while simultaneously lighting only the DEM light.

No competent engineer would design this system to ever activate the Republican ballot when the poll worker had pressed the DEM button but had not pressed the REP button.

Sequoia’s own explanation makes clear that they made an engineering error that caused the voting machine to behave incorrectly.

Second, this doesn’t look like fraud, only error. A malicious attacker who had access to a machine would have had much more powerful, and much less detectable, options at his disposal.

Third, Sequoia seems to avoid saying that what they describe is the only possible cause of such errors. Note the careful wording, “In each and every case where a machine displays [an error], this is the situation that would have caused it …” (emphasis added). They don’t say this “did” cause the errors; they say it “would have”. The sentence is either clumsy or artfully worded.

Fourth, Sequoia’s explanation involves a voter seeing the wrong party’s ballot being activated, and not complaining about it. Assuming (as press accounts say) that the problem happened about sixty times in New Jersey, one would expect that many voters noticed and complained. And one would expect that in at least one of those cases, a poll worker would have noticed that the operator panel was displaying REP and DEM at the same time. Yet there don’t seem to be reports of such behavior.

Fifth, Sequoia doesn’t characterize fully the cases where this problem might occur, so election officials don’t know, for example, which past elections might have been affected.

The bottom line is clear. An investigation is needed – an independent investigation, done by someone not chosen by Sequoia, not paid by Sequoia, and not reporting to Sequoia.

Filed Under: Uncategorized Tagged With: , ,

Evidence of New Jersey Election Discrepancies

March 19, 2008 by

Press reports on the recent New Jersey voting discrepancies have been a bit vague about the exact nature of the evidence that showed up on election day. What has the county clerks, and many citizens, so concerned? Today I want to show you some of the evidence.

The evidence is a “summary tape” printed by a Sequoia AVC Advantage voting machine in Hillside, New Jersey when the polls closed at the end of the presidential primary election. The tape is timestamped 8:02 PM, February 5, 2008.

The summary tape is printed by poll workers as part of the ordinary procedure for closing the polls. It is signed by several poll workers and sent to the county clerk along with other records of the election.

Let me show you closeups of two sections of the tape. (Here’s the full tape, in TIF format.)

Above you can see the vote totals on this machine for each candidate. On the Democratic side, the tally is Obama 182, Clinton 179. On the Republican side it’s Giuliani 1, Romney 13, McCain 40, Paul 3, Huckabee 4.

Above is the “Option Switch Totals” section, which shows the number of times each party’s ballot was activated: 362 Democratic and 60 Republican.

This doesn’t add up. The machine says the Republican ballot was activated 60 times; but it shows a total of 61 votes cast for Republican candidates. It says the Democratic ballot was activated 362 times; but it shows a total of 361 votes for Democratic candidates. (New Jersey has a closed primary, so voters can cast ballots only in their own registered party.)

What’s alarming here is not the size of the discrepancy but its nature. This is a single voting machine, disagreeing with itself about how many Republicans voted on it. Imagine your pocket calculator couldn’t make up its mind whether 1+13+40+3+4 was 60 or 61. You’d be pretty alarmed, and you wouldn’t trust your calculator until you were very sure it was fixed. Or you’d get a new calculator.

This wasn’t an isolated instance, either. In Union County alone, at least eight other AVC Advantage machines exhibited similar problems, as did dozens more machines in other counties.

Sequoia, the vendor, is trying to prevent any independent investigation of what happened.

Tomorrow: Sequoia’s story about how this happened, and why it’s inadequate.

UPDATE (March 20): We now have copies of nine anomalous tapes, including the one shown above. They’re on our New Jersey voting documents page.

Filed Under: Uncategorized Tagged With: , ,

Privacy: Beating the Commitment Problem

March 12, 2008 by

I wrote yesterday about a market failure relating to privacy, in which a startup company can’t convincingly commit to honoring its customers’ privacy later, after the company is successful. If companies can’t commit to honoring privacy, then customers won’t be willing to pay for privacy promises – and the market will undersupply privacy.

Today I want to consider how to attack this problem. What can be done to enable stronger privacy commitments?

I was skeptical of legal commitments because, even though a company might make a contractual promise to honor some privacy rules, customers won’t have the time or training to verify that the promise is enforceable and free of loopholes.

One way to attack this problem is to use standardized contracts. A trusted public organization might design a privacy contract that companies could sign. Then if a customer knew that a company had signed the standard contract, and if the customer trusted the organization that wrote the contract, the customer could be confident that the contract was strong.

But even if the contract is legally bulletproof, the company might still violate it. This risk is especially acute with a cash-strapped startup, and even more so if the startup might be located offshore. Many startups will have shallow pockets and little presence in the user’s locality, so they won’t be deterred much by potential breach-of-contract lawsuits. If the startup succeeds, it will eventually have enough at stake that it will have to keep the promises that its early self made. But if it fails or is on the ropes, it will be strongly tempted to try cheating.

How can we keep a startup from cheating? One approach is to raise the stakes by asking the startup to escrow money against the possibility of a violation – this requirement could be build into the contract.

Another approach is to have the actual data held by a third party with deeper pockets – the startup would provide the code that implements its service, but the code would run on equipment managed by the third party. Outsourcing of technical infrastructure is increasingly common already, so the only difference from existing practice would be to build a stronger wall between the data stored on the server and the company providing the code that implements the service.

From a technical standpoint, this wall might be very difficult to build, depending on what exactly the service is supposed to do. For some services the wall might turn out to be impossible to build – there are some gnarly technical issues here.

There’s no easy way out of the privacy commitment problem. But we can probably do more to attack it than we do today. Many people seem to have given up on privacy online, which is a real shame.

Filed Under: Uncategorized Tagged With: , ,

Privacy and the Commitment Problem

March 11, 2008 by

One of the challenges in understanding privacy is how to square what people say about privacy with what they actually do. People say they care deeply about privacy and resent unexpected commercial use of information about them; but they happily give that same information to companies likely to use and sell it. If people value their privacy so highly, why do they sell it for next to nothing?

To put it another way, people say they want more privacy than the market is producing. Why is this? One explanation is that actions speak louder than words, people don’t really want privacy very much (despite what they say), and the market is producing an efficient level of privacy. But there’s another possibility: perhaps a market failure is causing underproduction of privacy.

Why might this be? A recent Slate essay by Reihan Salam gives a clue. Salam talks about the quandry faced by companies like the financial-management site Wesabe. A new company building up its business wants to reassure customers that their information will be treated with the utmost case. But later, when the company is big, it will want to monetize the same customer information. Salam argues that these forces are in tension and few if any companies will be able to stick with their early promises to not be evil.

What customers want, of course, is not good intentions but a solid commitment from a company that it will stay privacy-friendly as it grows. The problem is that there’s no good way for a company to make such a commitment. In principle, a company could make an ironclad legal commitment, written into a contract with customers. But in practice customers will have a hard time deciphering such a contract and figuring out how much it actually protects them. Is the contract enforceable? Are there loopholes? The average customer won’t have a clue. He’ll do what he usually does with a long website contract: glance briefly at it, then shrug and click “Accept”.

An alternative to contracts is signaling. A company will say, repeatedly, that its intentions are pure. It will appoint the right people to its advisory board and send its executives to say the right things at the right conferences. It will take conspicuous, almost extravagant steps to be privacy-friendly. This is all fine as far as it goes, but these signals are a poor substitute for a real commitment. They aren’t too difficult to fake. And even if the signals are backed by the best of intentions, everything could change in an instant if the company is acquired – a new management team might not share the original team’s commitment to privacy. Indeed, if management’s passion for privacy is holding down revenue, such an acquisition will be especially likely.

There’s an obvious market failure here. If we postulate that at least some customers want to use web services that come with strong privacy commitments (and are willing to pay the appropriate premium for them), it’s hard to see how the market can provide what they want. Companies can signal a commitment to privacy, but those signals will be unreliable so customers won’t be willing to pay much for them – which will leave the companies with little incentive to actually protect privacy. The market will underproduce privacy.

How big a problem is this? It depends on how many customers would be willing to pay a premium for privacy – a premium big enough to replace the revenue from monetizing customer information. How many customers would be willing to pay this much? I don’t know. But I do know that people might care a lot about privacy, even if they’re not paying for privacy today.

Filed Under: Uncategorized Tagged With: , ,