UNIVERSAL PASSWORD WAS ‘DIEBOLD’
(THEY’VE CHANGED THEIR NAME TO ‘PREMIER’, SO…) [VIDEO]http://www.wired.com/threatlevel/2009/03/diebold-admits/http://www.wired.com/threatlevel/2009/03/video-ca-hearin/
Diebold Acknowledging Audit Log Flaws / March 20, 2009
“Earlier this week Premier Elections Solutions (formerly Diebold Election Systems) admitted in a hearing that the audit logs on its tabulation software fail to record significant events that occur on the machines — such as when an error in the software deletes votes or when election officials intentionally delete ballots from the system. These, of course, are the most basic events that an audit log should record.”

ALSO HAS DELETE BUTTONhttp://www.wired.com/threatlevel/2009/03/ca-report-finds/
According to the California Sec.of State’s report: “The Clear buttons … allow inadvertent or malicious destruction of critical audit trail records in all Gems version 1.18.19 jurisdictions, risking the accuracy and integrity of elections conducted using this voting system. Five years after the company recognized the need to remove the Clear buttons from the GEMS audit log screens, not only Humboldt, San Luis Obispo and Santa Barbara Counties in California but jurisdictions in other parts of the country, including several counties in Texas and Florida, continue to use Gems version 1.18.19….”

Today Ohio Secretary of State Jennifer Brunner released the results of a comprehensive security review of the electronic voting systems used in her state. The study was similar in scope to the California top-to-bottom review conducted this summer (with which I was also involved), covering the systems used in Ohio. The project contracted several academic teams and others to examine the election procedures, equipment and source code used in that state, with the aim of identifying any problems that might render elections vulnerable to tampering under operational conditions.

The ten-week project examined in detail the touch-screen, optical scan, and election management technology from e-voting vendors ES&S, Hart InterCivic and Premier Election Systems (formerly Diebold). Project PI Patrick McDaniel (of Penn State) coordinated the academic teams and led the study of the Hart and Premier Systems (parts of which had already been reviewed in the California study). Giovanni Vigna (of WebWise Security and UCSB) led the team that did penetration testing of the ES&S system.

I led the University of Pennsylvania-based team, which examined the ES&S source code. This was particularly interesting, because, unlike Hart and Premier, the full ES&S source code suite hadn’t previously been studied by the academic security community, although ES&S products are used by voters in 43 US states and elsewhere around the world. The study represented a rather unique opportunity to contribute to our understanding of e-voting security in practice, both inside and outside Ohio.

My group — Adam Aviv, Pavol Cerny, Sandy Clark, Eric Cronin, Gaurav Shah, and Micah Sherr — worked full-time with the source code and sample voting machines in a secure room on the Penn campus, trying to find ways to defeat security mechanisms under various kinds of real-world conditions. (Our confidentiality agreement prevented us from saying anything about the project until today, which is why we may have seemed especially unsociable for the last few months.)

There were other parts to the study (called “Project EVEREST”) than just the source code analysis, and, of course, there is also the question of how to actually secure elections in practice given the problems we found. The Ohio Secretary of State’s web site has a nice summary of the review and of the Secretary’s recommendations.

Readers of this blog may recall that for the last two months I’ve been part of a security review of the electronic voting systems used in California. Researchers from around the country (42 of us in all) worked in teams that examined source code and documents and performed “red team” penetration tests of election systems made by Diebold Election Systems, Hart InterCivic and Sequoia Voting Systems.

The red team reports were released by the California Secretary of State last week, and have been the subject of much attention in the nationwide press (and much criticism from the voting machine vendors in whose systems vulnerabilities were found). But there was more to the study than the red team exercises.

Today the three reports from the source code analysis teams were released. Because I was participating in that part of the study, I’d been unable to comment on the review before today. (Actually, there’s still more to come. The documentation reviews haven’t been released yet, for some reason.) Our reports can now be downloaded from http://www.sos.ca.gov/elections/elections_vsr.htm .

The California study was, as far as I know, the most comprehensive independent security evaluation of electronic voting technologies ever conducted, covering products from three major vendors and investigating not only the voting machines themselves, but also the back-end systems that create ballots and tally votes. I believe our reports now constitute the most detailed published information available about how these systems work and the specific risks entailed by their use in elections.

My hats off to principal investigators Matt Bishop (of UC Davis) and David Wagner (of UC Berkeley) for their tireless skill in putting together and managing this complex, difficult — and I think terribly important — project. By law, California Secretary of State Debra Bowen must decide by tomorrow (August 3rd, 2007) whether the reviewed systems will continue to be certified for use throughout the state in next year’s elections, and, if so, whether to require special security procedures where they are deployed.

We found significant, deeply-rooted security weaknesses in all three vendors’ software. Our newly-released source code analyses address many of the supposed shortcomings of the red team studies, which have been (quite unfairly, I think) criticized as being “unrealistic”. It should now be clear that the red teams were successful not because they somehow “cheated,” but rather because the built-in security mechanisms they were up against simply don’t work properly. Reliably protecting these systems under operational conditions will likely be very hard. The problems we found in the code were far more pervasive, and much more easily exploitable, than I had ever imagined they would be.

Our reports speak for themselves (and they do a lot of speaking, I’m afraid, with over 300 pages released so far), so I won’t try to repeat what’s in them here. What follows are strictly my own thoughts about what we learned and how we did what we did. My group, which was based in Berkeley, looked at the source code of the Sequoia system. That system includes touch-screen and optical scan voting machines used at polling places and a back-end ballot preparation and vote tallying database at the elections headquarters. At over 800K lines of code, Sequoia’s was the largest of the three codebases reviewed, and ours was the largest team in the project (Arel Cordero, Sophie Engle, Chris Karlof, Naveen Sastry, Micah Sherr, Till Stegers and Ka-Ping Yee — a group of extraordinary talent and energy if ever there was one).

Reviewing that much code in less than two months was, to say the least, a huge undertaking. We spent our first week (while we were waiting for the code to arrive) setting up infrastructure, including a Trac Wiki on the internal network that proved invaluable for keeping everyone up to speed as we dug deeper and deeper into the system. By the end of the project, we were literally working around the clock. To protect the vendor’s proprietary software, our lab was in a small room on the UC Berkeley campus equipped with a lock not on the building master key, a monitored alarm, a safe in which we stored our disk drives when no one was there and an air-gapped isolated network of dedicated workstations. The ventilation in our small windowless room never quite worked, and whenever anyone had a cold we’d all eventually catch it. (Not that I’m complaining; the minor physical discomforts and long hours were tiny prices to pay for the opportunity to study the inner workings of something rarely exposed to outside scrutiny, and yet so central to our democracy.)

Because of the way the project was organized we didn’t have any actual voting machines at Berkeley, only source code. All the vendor hardware was in another secure room at the Secretary of State’s office in Sacramento and was intended primarily for use by the penetration test red teams. We ended up collaborating closely with the red team (based at UC Santa Barbara) that was working on our system (and who issued their own report).

So what can we learn from all this?
In spite of the short time and other sub-optimal conditions, the project found deeply-rooted security weaknesses in the software of all three voting systems reviewed. I was especially struck by the utter banality of most of the flaws we discovered. Exploitable vulnerabilities arose not so much from esoteric weaknesses that taxed our ingenuity, but rather from the garden-variety design and implementation blunders that plague any system not built with security as a central requirement. There was a pervasive lack of good security engineering across all three systems, and I’m at a loss to explain how any of them survived whatever process certified them as secure in the first place. Our hard work notwithstanding, unearthing exploitable deficiencies was surprisingly — and disturbingly — easy.

Much of the controversy around electronic voting concerns the possibility of hidden “backdoors” incorporated by a nefarious vendor. Properly obfuscated, such mischief would be almost impossible to detect. Yet our reports chronicle software weakened not by apparent malice but by a litany of elementary mistakes: static cryptographic keys, unsecured interfaces, poorly validated inputs, buffer overflows, and basic programming errors in security-critical modules. Deliberate backdoors in these systems, if any existed, would be largely superfluous.

Unfortunately, while finding many of the vulnerabilities may have been straightforward enough, fixing them won’t be. The root problems are architectural. All three reviewed products are, in effect, large-scale distributed systems that have many of their security-critical functions performed by equipment sent out into the field. In particular, the integrity of the vote tallies depends not only on the central computers at the county elections offices, but also on the voting machines (and software) at the polling places, removable media that pass through multiple hands, and complex human processes whose security implications may not be clear to the people who perform them. In other words, the designs of these systems expose generously wide “attack surfaces” to anyone who seeks to compromise them. And the defenses are dangerously fragile — almost any bug, anywhere, has potential security implications.

This means that strengthening these systems will involve more than repairing a few programming errors. They need to be re-engineered from the ground up. No code review can ever hope to identify every bug, and so we can never be sure that the last one has been fixed. A high assurance of security requires robust designs where we don’t need to find every bug, where the security doesn’t depend on the quixotic goal of creating perfect software everywhere. In the short term, election administrators will likely be looking for ways to salvage their equipment with beefed up physical security and procedural controls. That’s a natural response, but I wish I could be more optimistic about their chances for success. Without radical changes to the software and architecture, it’s not clear that a practical strategy that provides acceptable security even exists. There’s just not a lot to work with. I don’t envy the officials who need to run elections next year.

Electronic Vote Rigging in Kentucky
Eight Clay County, Kentucky election officials were charged last week with conspiring to alter ballots cast on electronic voting machines in several recent elections. The story was first reported on a local TV station and was featured on the election integrity site BradBlog. According to the indictment, the conspiracy allegedly included, among other things, altering ballots cast on the county’s ES&S iVotronic touchscreen voting machines.

So how could this have happened?
The iVotronic is a popular Direct Recording Electronic (DRE) voting machine. It displays the ballot on a computer screen and records voters’ choices in internal memory. Voting officials and machine manufacturers cite the user interface as a major selling point for DRE machines — it’s already familiar to voters used to navigating touchscreen ATMs, computerized gas pumps, and so on, and thus should avoid problems like the infamous “butterfly ballot”. Voters interact with the iVotronic primarily by touching the display screen itself. But there’s an important exception: above the display is an illuminated red button labeled “VOTE”. Pressing the VOTE button is supposed to be the final step of a voter’s session; it adds their selections to their candidates’ totals and resets the machine for the next voter.

The Kentucky officials are accused of taking advantage of a somewhat confusing aspect of the way the iVotronic interface was implemented. In particular, the behavior (as described in the indictment) of the version of the iVotronic used in Clay County apparently differs a bit from the behavior described in ES&S’s standard instruction sheet for voters. A flash-based iVotronic demo available from ES&S shows the same procedure, with the VOTE button as the last step. But evidently there’s another version of the iVotronic interface in which pressing the VOTE button is only the second to last step. In those machines, pressing VOTE invokes an extra “confirmation” screen. The vote is only actually finalized after a “confirm vote” box is touched on that screen. (A different flash demo that shows this behavior with the version of the iVotronic equipped with a printer is available from ES&S here). So the iVotronic VOTE button doesn’t necessarily work the way a voter who read the standard instructions might expect it to.

The indictment describes a conspiracy to exploit this ambiguity in the iVotronic user interface by having pollworkers systematically (and incorrectly) tell voters that pressing the VOTE button is the last step. When a misled voter would leave the machine with the extra “confirm vote” screen still displayed, a pollworker would quietly “correct” the not-yet-finalized ballot before casting it. It’s a pretty elegant attack, exploiting little more than a poorly designed, ambiguous user interface, printed instructions that conflict with actual machine behavior, and public unfamiliarity with equipment that most citizens use at most once or twice each year. And once done, it leaves behind little forensic evidence to expose the deed.

Current electronic voting systems have been widely — and justifiably — criticized for being insufficiently secure against vote tampering and other kinds of election fraud. I led the team at U. Penn that examined the ES&S iVotronic — the same machine used in Kentucky — as part of the Ohio EVEREST voting systems study in 2007. We found numerous exploitable security weaknesses in these machines, many of which would make it easy for a corrupt voter, pollworker, or election official to tamper with election results. Other studies have reached similarly grim conclusions about most of the other e-voting products used in the US and elsewhere. But these results, alarming as they are, also raise a perplexing question: if the technology is so vulnerable, why have there been so few (if any) substantiated cases of these systems being attacked and manipulated in actual elections?

A plausible explanation is simply that the bad guys haven’t yet caught up with the rich opportunities for mischief that these systems provide. It takes time for attackers to recognize and learn to exploit security weaknesses in new devices, and touchscreen voting machines have been in wide use for only a few years (most US counties purchased their current systems after 2002, with funding from the Help America Vote Act). For example, the computers connected to the Internet were for a long time largely vulnerable to network-based attack, but it took several years before viruses, worms, and botnets became serious threats in practice. In other words, new technologies sometimes enjoy an initial relatively crime-free “attack honeymoon” in which even very weak defenses seem to be sufficient. But eventually, the criminals arrive, and, once they climb the learning curve, the world becomes a much more hostile place very quickly.

We might ask, then, what the (alleged) Kentucky conspiracy tells us about the e-voting attack honeymoon. Are the bad guys catching up? On the one hand, we might be comforted by the relatively “low tech” nature of the attack — no software modifications, altered electronic records, or buffer overflow exploits were involved, even though the machines are, in fact, quite vulnerable to such things. But a close examination of the timeline in the indictment suggests that even these “simple” user interface exploits might well portend more technically sophisticated attacks sooner, rather than later.

Count 9 of the Kentucky indictment alleges that the Clay County officials first discovered and conspired to exploit the iVotronic “confirm screen” ambiguity around June 2004. But Kentucky didn’t get iVotronics until at the earliest late 2003; according to the state’s 2003 HAVA Compliance Plan, no Kentucky county used the machines as of mid-2003. That means that the officials involved in the conspiracy managed to discover and work out the operational details of the attack soon after first getting the machines, and were able to use it to alter votes in the next election.

Yes, the technique is low-tech, but it’s also very clever, and not at all obvious. The only way for them to have discovered it would have been to think hard and long about how the machines work, how voters would use them, and how they could subvert the process with the access they had. And that’s just what they did. They found the leverage they needed quickly, succeeding at using their discovery to steal real votes, and apparently went for several years without getting caught. It seems reasonable to suspect that if a user interface ambiguity couldn’t have been exploited, they would have looked for — and perhaps found — one of the many other exploitable weaknesses present in the ES&S system.

But that’s not the worst news in this story. Even more unsettling is the fact that none of the published security analyses of the iVotronic — including the one we did at Penn — had noticed the user interface weakness. The first people to have discovered this flaw, it seems, didn’t publish or report it. Instead, they kept it to themselves and used it to steal votes.

After years of problems with the state’s touch-screen voting system, Maryland has filed a claim to recover $8.5 million from the maker of the machines, Premier Election Solutions, Attorney General Douglas F. Gansler announced yesterday. The claim seeks costs the state incurred to correct security gaps in the voting system that were uncovered several years ago by independent investigations. The state has paid $90 million under a contract with Premier, formerly known as Diebold, since 2001. During that time, the two parties have had a sometimes-rocky relationship as hitches in the voting system surfaced. “Under basic contract law, this is money that should be paid by Diebold or its successor and not by the taxpayers,” Gansler said in an interview. “This is sort of the final chapter of the touch-screen machines that we’ve had issues with in Maryland since we’ve gotten them.”

Last year, Gov. Martin O’Malley and the General Assembly decided to eventually dump the touch-screen equipment and instead move toward buying new optical-scan machines, which read paper ballots filled in by voters with pencil or pen and allow for a manual recount. The new system is expected to cost about $20 million. Premier President Dave Byrd said in a statement that the state’s claim appears to be based on “inaccurate and unfounded assumptions.” He also said the 2008 election, in which Premier’s machines were used, was one of the “smoothest” in the state’s history, culminating what he called a “seven-year track record of success.” The “claim may be an attempt to retroactively change the rules of the contracts, but it does not change or reflect the actual record of successful performance,” Byrd said.

State officials contend, however, that the November election came off with few glitches precisely because they had spent so much money on upgrades and technical fixes. According to the claim, the state Board of Elections has implemented, largely at its own expense, measures to correct flaws uncovered by assessments ordered by former Gov. Robert L. Ehrlich Jr. and by the General Assembly. Premier and the state haven’t always been on the outs. After warnings about security vulnerabilities from three computer experts – Johns Hopkins University professor Avi Rubin and the two hired by the state – a voter advocacy group sued in 2004. The group alleged that the state should not have certified Premier’s machines for use in elections. The state defended Premier at the time, and won.

That history is not lost on Premier, which said its good relations with the state made the attorney general’s recent claim “all the more of a surprise,” according to the company’s written response. The company said its system satisfies contractual security requirements and that the state decided to incorporate additional measures based on the reports it commissioned. The company’s response relied in part on the state’s legal defense from four years ago that contended no system is perfect and pointed out that there had not been a single report of a security breach. Premier also said that it has provided additional services and materials beyond what was required under the contract at no additional charge.

Other problems have surfaced that aren’t addressed in the state’s claim. Diebold had to replace parts in voting machines used in the 2004 election because of glitches in the “motherboard,” the main circuit board, that could cause the machines to freeze. Then in the 2006 primary election, the state’s new “e-poll books,” electronic check-in terminals made by Diebold that are distinct from the touch-screen voting units, crashed repeatedly. “Voter confidence and the integrity of the process were undermined by the use of these machines,” Gansler said. “It took nearly 10 years for us to figure out we shouldn’t be using them, but during the course of that time we did everything we could to ensure reliability.” The claim now goes before a state procurement officer, whose decision on the matter could then be petitioned to the Maryland State Board of Contract Appeals. Until the dispute is settled, the state is withholding payment on $4 million in bills for services Premier provided for the 2008 elections.

Artifex Software, the company behind the open source Ghostscript PDF processing software, has filed a lawsuit against voting machine vendor Diebold and its subsidiary Premier Election Solutions. Artifex says that Diebold violated the GPL by incorporating Ghostscript into commercial electronic voting machine systems. Ghostscript, which was originally developed in the late 80s, is distributed for free under the GNU General Public License (GPL). This license permits developers to study, modify, use, and redistribute the software but requires that derivatives be made available under the same terms. Companies that want to use Ghostscript in closed-source proprietary software projects can avoid the copyleft requirement by purchasing a commercial license from Artifex. Among commercial Ghostscript users who have purchased licenses from Artifex are some of the biggest names in the printing and technology industries, including HP, IBM, Kodak, Siemens, SGI, and Xerox.

Evidence of Diebold’s Ghostscript use first emerged last year when electronic voting machine critic Jim March was conducting analysis of Pima County voting irregularities. He brought a technical question to the Ghostscript mailing list relating to his investigation and mentioned in passing that Diebold’s use of Ghostscript could potentially fall afoul of the GPL. This view was shared by Ghostscript developer Ralph Giles, who referred the matter to the Artifex business staff so that it could evaluate the legal implications. “Seems likely that they are not respecting our software license in this case. We do not consider bundling as an integrated component intended to work with other software as ‘mere aggregation’ under the GPL,” wrote Giles in a mailing list post. According to InformationWeek, Artifex is seeking over $150,000 in damages and is calling for the court to block usage of the equipment. Security researchers have uncovered numerous security vulnerabilities in voting machines produced by several major vendors, including Diebold. The voting machine company has faced several high-profile lawsuits in the past, including one filed by the state of California, where Diebold machines were subsequently banned over fraudulent claims.

“The National Institute of Standards and Technology (NIST) delivered an update on Monday to the United States’ electronic voting standards, adding more requirements to test systems for accuracy and reliability and additional rules to make paper audit trails easier to review. The draft revision, known as the Voluntary Voting System Guidelines (VVSG) version 1.1, adds more stringent recommendations for testing and auditing as well as requirements that election software and updates be digitally signed and improved ease-of-use for poll workers. The U.S. Election Assistance Commission (EAC) announced on Monday that the draft revision will be available for public comment for the next 120 days. “The guidelines announced today are designed to further improve the quality and efficiency of the testing conducted on voting systems,” John Wack, NIST voting team manager, said in a statement. “This enables improvements to be made sooner rather than later when the next full set of standards is finalized.”

Election systems have come under scrutiny following errors that have led to lost votes and software glitches that have shutdown machines on voting day. In 2007, an election system failure may have resulted in a loss for the Democratic challenger in a contest for one of Florida’s seats in the U.S. House of Representatives, when the configuration of the electronic ballot likely resulted in a large number of people in a Democratic-leaning county failing to vote. In midterm elections the prior year, many states took extra security precautions after researchers found that Diebold’s election systems contained a serious flaw.”

Jeff Moss, founder of the Black Hat and Defcon hacker and security conferences, was among 16 people sworn in on Friday to the Homeland Security Advisory Council. The HSAC members will provide recommendations and advice directly to Secretary of Homeland Security Janet Napolitano. Moss’ background as a computer hacker (aka “Dark Tangent”) and role as a luminary among young hackers who flock to Defcon in Las Vegas every summer might seem to make him an odd choice to swear allegiance to the government. (Although before running his computer conferences, Moss also worked in the information system security division at Ernst & Young.) I’d like to hear some of the banter as he rubs elbows with the likes of former CIA (Bill Webster) and FBI directors (Louis Freeh), Los Angeles County sheriff, Miami mayor, New York police commissioner, governors of Maryland and Georgia, former Colorado Sen. Gary Hart, and the president of the Navajo Nation.

In an interview late on Friday, Moss, who is 39, said he was surprised when he got the call and was asked to join the group.
“I know there is a newfound emphasis on cybersecurity and they’re looking to diversify the members and to have alternative viewpoints,” he said. “I think they needed a skeptical outsider’s view because that has been missing.” Asked if there was anything in particular he would advocate, Moss said: “There will be more cyber announcements in coming weeks and once that happens my role will become more clear. This meeting was focused on Southwest border protection… With things like Fastpass and Safe Flight, everything they are doing has some kind of technology component.”

Moss, who is genuinely humble, said he was “fantastically honored and excited to contribute” to the HSAC and not concerned with losing any street cred among what some would call his fan base. He did concede that his new position would give him an unfair advantage in Defcon’s “Spot The Fed” contest in which people win prizes for successfully outing undercover government agents. Security consultant Kevin Mitnick, who spent five years in prison on computer-related charges and was once the FBI’s most-wanted cybercriminal, praised Moss’ diplomacy, but said: “I’m surprised to see Jeff on the list. I would have expected (crypto/security guru and author) Bruce Schneier to be on the council.” Moss “is a great crowd pleaser” and “he’s just bad enough for them to say ‘we’re crossing the ranks,'” said journalist and threat analyst Adrian Lamo, who served two years of probation for breaking into computer networks. “But the reality is he’s as corporate as hiring someone out of Microsoft.”

In a surprise announcement, President Obama has named the nation’s first federal CIO [1]: Vivek Kundra, CTO of the District of Columbia. (He has yet to name the position he did promise he would create: the first national CTO.) So who is Kundra, and what might his appointment mean for the federal government’s direction for and spending on technology? As the federal CIO, he will oversee a $71 billion IT budget and manage technology interoperability among agencies. Kundra told a press conference that he will investigate how the government might improve its technology investments and make more information accessible to citizens through the Internet. He’s done both as D.C.’s CTO.

The District of Columbia has been a leader in smart deployment of technology for years, boasting a succession of strong CTOs. Under Suzanne Peck’s tenure, previous to Kundra’s, D.C. was among the first to use SOA to rationalize software development [2] efforts, to use XML to make government operational data open for mashups [3], and to deploy next-gen wireless technology for public safety [4] and other agency usage. Kundra became CTO in 2006 and quickly staked out his own innovation focus. As D.C.’s CTO, Kundra has emphazied what he calls a stock-market approach to IT project management and the adoption of consumer technologies in business. Both approaches come from the same epiphany he recalls having: The technology most users employ at work is kludgy compared to what they use in their daily routines, even though consumer technologies are often less expensive or even free. “For some weird reason I cannot understand, the way we organize ourselves at work is so much less agile than what we do in our personal lives,” Kundra told InfoWorld. “Why not use consumer technology at work?”

The IT “stock market”
As D.C.’s CTO, Kundra hired a team of analysts to track projects — in the style of a financial analyst — on a daily basis. Smaller projects get bundled into “funds” of related efforts. Pretty quickly, the successes and failures were obvious. For example, the analysts discovered that a three-year enterprise content management project had made little progress and was run by project managers who had four previous failures. “It was not going anywhere. So I decided to ‘sell’ the stock — I killed the project — and put that capital elsewhere,” Kundra recalls. In this case, he redirected the money to add mobile laptops to police cars. The stock metaphor made sense to more business-minded leaders at the district, but Kundra admits he had to really sell the concept to most employees and the 87 agency heads served by his team. “It was an education,” he notes drily. What really sold the concept was the result: lower cost due to fewer long-burning misfires.

The stock approach also supplanted the traditional project management mentality of creating specifications and periodically assessing progress against them subjectively. “I wanted a more data-driven model — after all, the data is the data. If you’re over budget for two or three quarters, you can’t avoid being exposed,” Kundra says. “People don’t make tough decisions easily, so you have to show them the data. [As government leaders,] it’s our duty to make sure they’re not failing,” he adds. Objective measurements make that assessment easier. For Kundra, the stock-market approach is really just a metaphor for a technique driven by ongoing analytics. “You can use a different metaphor if that works better in your industry,” he says. But essential to success is a “ruthless discipline” in your data collection, analysis, and consequent management decisions.

Freeing up resources for meaningful innovation
Kundra was not focused solely on weeding out bad “stocks.” He also used this approach to free up capital for innovative bets. For example, he’s initiated a project that combines YouTube with Wikipedia to increase government’s accountability to citizens. All requests for proposals (RFPs) for city contracts are posted on a Web site in a wiki, with all bids being available as PDF attachments. Attendee lists from public hearings are scanned and posted as well, as are videos of hearings and even RFP presentations. Also posted or linked are any district communications with the potential vendors on the RFPs. If this effort succeeds, “no one can say that there are deals done behind closed doors,” he says. “It’s tough in tight budgets to find the innovative path,” Kundra notes, which is why he was so focused on gaining stock-market-like efficiencies in weeding out wasteful projects and identifying strong ones. Thanks to the savings already established from this approach, he was able to set up an R&D lab to test new ideas. The two areas of Kundra’s fancy are new-generation mobile devices — “I believe the iPhone is the future [5] for integrated voice, data and video” — and Web 2.0 technologies [6], thus the experiments using wikis and YouTube.

“Humboldt County election director Carolyn Crnich discovered the missing ballots only because she happened to implement a new and innovative auditing system this year that was spearheaded by members of the public who helped her develop it. Humboldt County, which is a small county located in northern California near the Oregon border, implemented the Transparency Project, whereby every paper ballot (Humboldt uses only paper ballots) gets digitally scanned by a separate commercial scanner, not made by a voting machine company, so that the ballot images can then be posted on the internet for anyone to examine and conduct their own independent recounts. (See this post for more about how the Transparency Project works.)

It was through the Transparency Project that Crnich and Mitch Trachtenberg, a volunteer who helped design part of the project, discovered the problem with the Premier software on November 30th after they finished scanning all of the ballots through the Transparency Project’s commercial scanner two days before the county was required to certify its election results. After the county had already scanned and tabulated the 60,000+ ballots with the Premier voting system and created the official tally, the Transparency Project workers then spent 65 hours scanning the ballots into a Fujitsu scanner and creating digital images of each ballot. They discovered in doing so, that they had 216 more ballots recorded than the number of ballots that were counted by the Premier tabulation system.

Parke Bostrom, one of the Transparency Project volunteers, wrote in a blog post about the issue, “The audit log is not truly a ‘log’ in the classical computer program sense, but is rather a ‘re-imagining’ of what GEMS would like the audit log to be, based on whatever information GEMS happens to remember at the end of the vote counting process.”

“Under the Transparency Project, after the ballots are officially scanned and tabulated by the Premier system, they’re scanned a second time by a separate commercial scanner, not made by any voting machine company, so that the ballot images can then be posted on the internet for the public to examine and conduct independent recounts. Every ballot image is imprinted with a unique serial number as it’s scanned through the commercial scanner to verify its authenticity, and batches of ballot images are hashed to verify that they haven’t been altered before they’re posted online or saved to DVDs.

To make it easier for the public to tally the votes, Trachtenburg, an independent programmer who has launched a company called Trachtenberg Election Verification Software, wrote a program pro bono to allow anyone to sort through the Humboldt ballots by precinct or race. The sorting software, called Ballot Browser (image above right shows the software’s user interface), is an open source program written in Python to run on a Windows or Linux platform. The Humboldt version is running on Debian Linux Etch and uses a Fujitsu high-speed scanner also using Debian Linux.

Ballot Browser displays each ballot in a window and highlights the spot where it thinks the voter has made his choice. The display can be turned off to speed up scanning to 1,000 ballots an hour. Crnich said she got the idea for the project from Kevin Collins, who expressed concerns during a public meeting about the trustworthiness of proprietary voting systems. He wanted to know why it wasn’t possible for everyone to examine every ballot. “That was the seed,” Crnich told Threat Level.

But getting ballots into the hands of the public presented a problem. California’s election law says that once ballots are scanned and sealed in containers by poll workers after an election, they can’t be re-opened except to be recycled or destroyed or unless officials suspect there might be something wrong with the ballots. Crnich determined that the latter provided a possible loophole. Since there was already a strong public perception that there was something wrong with the ballots, she concluded that this was the permission she needed to make the ballots available for public perusal.

Trachtenberg said he came away from his first meeting with Crnich feeling very pleasantly surprised. “I just thought, ’she gets it, she gets it,’” he said. “I had contacted the previous election staff years ago complaining in particular that the [voting] system wouldn’t leave a paper audit trail. So I was really pleasantly surprised when I discovered that Carolyn was behind the idea of election transparency and wanted to get on board.”

Crnich convinced her board of supervisors to purchase an off-the-shelf Fujitsu high-speed scanner and the group launched the project in limited form during the June primary. Trachtenberg said before the launch they had trouble getting the scanner to work with their Linux scanning program, but contacted M. Allen Noah, administrator of the SANE Project (the open scanning protocol known as Scanner Access Now Easy that works with Linux), who advised them on how to make it work.

It took about five days to scan about 32,000 ballots cast in the primary election. The ballot scans amounted to about 8.2 GB of data and filled up 3 DVDs. They didn’t actually do a re-count of the ballots in June, however. They just did random spot checks to establish that their system worked. The number of ballots they scanned with their Fujitsu matched very closely the number they had scanned with the Premier system, with the exception of one or two ballots.

The November election, by contrast, was more complicated and took 65 hours to scan because the election involved 64,161 ballots that were double-sided. The volunteers were deputized before they started the project, and the chain-of-custody on the ballots was carefully controlled throughout the process. A county worker removed the ballots from secure storage, and the ballots were never left alone with one person at a time. The workers had to fill out forms carefully tracking the time the ballots left secure storage, the time at which they were unsealed from containers, and other steps.

Crnich said the partnership of technical experts with election staff turned out to be the perfect combination. “With my willingness to say yes let’s do what we can to make this a transparent and trusted election and with Mitch’s ability to develop the software in open source and make it available, it’s worked out I think to the advantage of voters in Humboldt County,” Crnich said. “[The point] was not to catch anybody or anything, it was just to make the information available to the public. Here it is. If you question our results, please look at it yourself.”

Once they’d finished scanning the November ballots, they knew immediately they had a problem because the number of ballots they scanned through the Fujitsu printer didn’t match the number of ballots that had been tabulated by the Premier system. They discovered that the Premier system had dropped a batch of 197 ballots from its tabulation software. The voting company has acknowledged that a problem with its software caused the system to drop the ballots and that the software has contained the error since 2004.

Trachtenberg said the problem they discovered underscored for him that proprietary voting systems and “secret counting” methods aren’t in the best interest of democracy. “Without any allegation of fraud, programmers make mistakes. And sometimes people like to hide their mistakes,” Trachtenberg said. “If it’s possible for people to do an independent count, they should be allowed, and we’re very fortunate in Humboldt that we had a registrar who not only allowed us to do an independent count but made it as easy as it could be. I think what you’ll find is a couple if years from now, this is going to be thought to be just common sense.”

The ballots from the November election haven’t been placed online yet because they’re still looking for a volunteer with sufficient bandwidth who is willing to host the data. In the meantime, members of the public can request DVD copies of the ballots by contacting the Humboldt County elections office. Here’s a video of Trachtenberg discussing how his open-source ballot software works.

BETTER LIVING THROUGH CHEMISTRYhttp://www.economist.com/science/tm/displaystory.cfm?story_id=12455414
“[One] approach to the idea of encrypted ballots is Scantegrity II, designed by David Chaum, a computer scientist and cryptographer who, among many other things, invented the idea of digital cash. Instead of putting a cross next to the candidate’s name, a voter fills in an oval-shaped space, known as a bubble, next to the name. So far, that is similar to one widely used American system. However, in the case of Scantegrity the voter uses not an ordinary pen but a special one whose “ink” reacts with a pattern of two chemicals that has been printed inside the bubble. One of these chemicals darkens the whole bubble, so that its position (and thus the candidate voted for) can be recorded by a standard optical-reader. The other becomes visible in a contrasting colour to reveal a previously invisible three-character code, derived from a pseudorandom number generator. Since the optical readers employed by this system do not have character-recognition software, this code cannot be read by the vote-counting machine. But it can be noted by the voter on a detachable receipt at the bottom of the ballot paper. He can then, if he wishes, check things are in order by entering the serial number of his ballot paper into a website set up for the election. He should see in return the letter code he noted. If the code does not match, something is awry, and an investigation can start.”

We’ve never quite understood why e-voting software shouldn’t be required to be public information. For the sake of actually allowing an open and transparent voting system, it’s hard to understand how any governing body would allow proprietary software to be used. There’s simply no way you can prove that the system is fair and transparent if the counting mechanism is totally hidden away. For years, the big e-voting firms have simply shrugged this off, but it looks like they’re at least open to discussing it. A trade group representing the big e-voting firms has put out a whitepaper discussing open source voting systems, where all they really do is show that they don’t actually understand much about open source technologies.

First, they claim that, even though they understand that “security through obscurity” isn’t effective, “there remains some underlying truths to the idea that software does maintain a level of security through the lack of available public knowledge of the inner workings of a software program.” Computer Science professor Dan Wallach does a nice job responding to that claim:

“Really? No. Disclosing the source code only results in a complete forfeiture of the software’s security if there was never any security there in the first place. If the product is well-engineered, then disclosing the software will cause no additional security problems. If the product is poorly-engineered, then the lack of disclosure only serves the purpose of delaying the inevitable. What we learned from the California Top-to-Bottom Review and the Ohio EVEREST study was that, indeed, these systems are unquestionably and unconscionably insecure. The authors of those reports (including yours truly) read the source code, which certainly made it easier to identify just how bad these systems were, but it’s fallacious to assume that a prospective attacker, lacking the source code and even lacking our reports, is somehow any less able to identify and exploit the flaws. The wide diversity of security flaws exploited on a regular basis in Microsoft Windows completely undercuts the ETC paper’s argument. The bad guys who build these attacks have no access to Windows’s source code, but they don’t need it. With common debugging tools (as well as customized attacking tools), they can tease apart the operation of the compiled, executable binary applications and engineer all sorts of malware. Voting systems, in this regard, are just like Microsoft Windows. We have to assume, since voting machines are widely dispersed around the country, that attackers will have the opportunity to tear them apart and extract the machine code. Therefore, it’s fair to argue that source disclosure, or the lack thereof, has no meaningful impact on the operational security of our electronic voting machines. They’re broken. They need to be repaired.”

The next oddity, is the claim that if a problem is found in open source software, then it won’t get fixed as quickly, because you have to wait for “the community” to fix it. That completely mistakes how open source software works. Again, Wallach points out how silly that is, noting that plenty of commercially-focused companies run open source projects, including maintaining and contributing code to the project. If these companies were to open source their code, there’s nothing stopping them from continuing to improve the security of the code. There’s no need to wait around… The paper has other problems as well, which Wallach discusses at the link above. To be honest, though, it’s quite telling that these firms don’t even seem to understand some of the basics of how open source software works.

Computer engineer Alan Dechert didn’t like what he saw during the controversial vote tallying in Florida in 2000’s presidential election. That was when he decided that there had to be a better way for U.S. citizens to safely and accurately cast their ballots. More than seven years later, Dechert is here at the LinuxWorld Conference & Expo, publicly displaying the open-source e-voting system he helped develop that fixes some of the problems that he and other critics found in the nation’s voting systems almost a decade ago. “I watched the 2000 election, and I was stunned that we didn’t know how to count ballots,” Dechert said.

In Florida, where paper punch-card ballots were used at the time in many counties, the nation watched in disbelief for weeks as the presidential election came down to the wire over punch cards that were analyzed individually and manually by voting officials. At issue was voter intent, as officials tried to decipher who voters had selected on the ballots, which often weren’t fully punched out by the machines that were supposed to mark the ballots. It took analysis of those ballots and a U.S. Supreme Court decision to finally decide the winner of that election, almost a month after the last polling place closed.

That December, Dechert co-founded the Granite Bay, Calif.-based Open Voting Consortium to try to help come up with a better way to vote in this country. “This was conceived as a pilot project for Sacramento County [Calif.] in December 2000,” he said. The idea was to create an electronic voting system that allows voters to make their candidate selections on a screen, then clearly print their ballots and have them scanned and tallied by reliable machines. By creating such a system, Dechert said, then “there’s no ambiguity about what the voter intended,” fixing one of the most glaring problems of the old punch-card systems and poorly designed ballot layouts. The system, which was set here at LinuxWorld for show attendees to view and vote in mock elections, runs on PCs loaded with Ubuntu Linux and the free, open source e-voting application created by the consortium.

For election officials, the system is a simple one that would allow voters to be sure of their choices before they leave the ballot-casting area, Dechert said. Officials could set up and create the ballot in any elections intuitively with a special software tool that would add candidate names, office titles and other relevant information without requiring major computing skills. The application runs on standard PC architecture and requires no specialized equipment. “They don’t have to do anything special,” Dechert said of local election officials who would use the system. “They don’t have to know anything special.”

By going to an open-source system, he said, the application’s code could be carefully and publicly analyzed for flaws and security issues, then could be fixed and made trustworthy for use. At least, that’s the position of open-source advocates who think they can build a better system than those created by proprietary vendors across the nation. “What we’re trying to advance is full public scrutiny, with many eyes on the code,” Dechert said.

The open-source system aims to address several concerns about traditional vendor-supplied e-voting systems in use across the U.S., he said, including the following:
* By being open source, the code can be checked at any time for flaws or problems by any qualified programmer or developer, making it more transparent and trustworthy.
* By using off-the-shelf PC hardware and printers and other peripherals, it’s much cheaper than custom, purpose-built e-voting consoles and equipment.
* It’s usable by handicapped voters and by voters who speak languages other than English.
* It contains a voter-verifiable and fully auditable paper record that can be preserved and is recountable.

“It could be used now,” Dechert said. Some local voting jurisdictions are in talks with the group now about looking further at the system, including local officials in at least one Maryland county, he said. For use in national elections, the system would have to be heavily analyzed and eventually certified as an election system, Dechert said. That process is part of the group’s future goals, he said.

Here in San Francisco, for the system in display on the show floor, mock voters entered a booth and stood in front of a computer screen that lay flat in front of them on a table. The voters then used a traditional computer mouse to make their selections on the one-screen ballot and then advanced the ballot selections with on-screen arrows. Voters could also choose to go back to check or change their selections. After completing the ballots, participants were asked to confirm their candidate or referendum-question selections several times, then were able to print their ballots on a printer also in the voting cubicle. Each voter then put the printed paper ballot in a manila folder and walked it over to a nearby election official, who electronically tallied and scanned it in front of the voter.

More than 300 people tried out the system yesterday. Project organizers set up a ballot with the three major party candidates in this year’s presidential election, as well as several referendum questions about e-voting and other topical public issues. Dick Turnquist, an IT manager at the Association of California Water Agencies in Sacramento, test-voted on the proposed system and said he liked what he experienced. “It certainly was easy enough to use. I probably would prefer it” to existing e-voting systems, Turnquist said. Greg Simonoff, an engineer at the California Department of Transportation, said he liked using the system but would prefer a touch-screen voting mechanism rather than a mouse-based system. Dechert said the mouse-based system is being used in the demonstration phase of the project to cut costs but would be replaced with a touch-screen system in production.

It’s commonly said that insanity is doing the same thing over and over again while expecting different results. Yet this is what we keep doing with electronic voting machines – find flaws and try again. It should therefore have been no surprise when, at the end of March, California’s secretary of state’s office of voting system technology assessment decertified older voting systems from Diebold’s Premier Election Solutions division. The reason: a security flaw that erased 197 votes in the Humboldt county precinct in last November’s presidential election.

Clearly, 197 votes would not have changed the national result. But the loss, which exceeds the error rate allowed under the Help America Vote Act of 2002, was only spotted because a local citizen group, the Humboldt County Election Transparency Project (humtp.com) monitored the vote using a ballot-imaging scanner to create an independent record. How many votes were lost elsewhere? Humboldt county used Diebold’s GEMS operating system version 1.18.19 to tally postal ballots scanned in batches, or “decks”. The omission of votes was a result of a flaw in the system, where, given particular circumstances, it deletes the first deck, named “Deck Zero”, without noting it in the system’s audit logs.

Voting slips
Diebold recommended decertification of its older version, which should force precincts to upgrade and eliminate the flaw. But the secretary of state’s report notes flaws in the audit logs that will be harder to erase: wrongly recorded entry dates and times, and silent deletions of audit logs. “It’s nothing new,” says Rebecca Mercuri, a security consultant who studied voting systems for her 1999 doctoral dissertation. “These are all security flaws that are well known in the industry. Why are they acting as if this is the first time they’ve heard this?” The audit log problems were documented in Bev Harris’s 2004 book, Black Box Voting. Mercuri explains that election software belongs to the class of problems known as “NP-complete”, that is, problems computers cannot solve in a known amount of time. How much time have you got to test that a given voting system will function perfectly under all possible circumstances? “What are people going to do about it?” she asks. “Say we fixed it when it’s theoretically not possible to fix these things at any real level?”

So, it’s not fair just to pick on Diebold. Last month, election officials in Clay county, Kentucky, were charged with conspiring to alter ballots cast on ES&S iVotronic election machines in recent elections. The key: interface design. In most cases, voters cast ballots by pressing a big red button labelled “VOTE”. But some versions of the system require touching a “confirm vote” box on the screen to complete the ballot. It is alleged officials hid this fact from voters and would then “correct” and confirm the ballot after the voter had left. The officials have pleaded not guilty. Matt Blaze, a security researcher at the University of Pennsylvania, writes in his blog that if this were a strategy, “it’s a pretty elegant attack, exploiting little more than a poorly designed, ambiguous user interface, printed instructions that conflict with actual machine behaviour, and public unfamiliarity with equipment that most citizens use at most once or twice each year. And once done, it leaves behind little forensic evidence to expose the deed.”

But Diebold’s current problems aren’t limited to voting machines. More startling was the discovery of malware designed to attack its ATMs. Graham Cluley, a senior technology consultant for the security company Sophos, says the company found a sample in its archives. “If [the malware] were planted on the version of Windows on those Diebold machines,” Cluley says, “you could actually steal information from the cards being used on the device, and hackers with a specially crafted card would get a receipt with people’s information.” Diebold sent out a customer warning in January and provided a software update. As in the Kentucky voting machine case, the attack on Diebold’s ATMs requires inside access. “We’re seeing more and more organised criminal gangs because of the money they can make,” says Cluley, pointing out how difficult it would be to spot a legitimate maintenance engineer who’s been bought off installing an extra patch off a USB stick in a back pocket.

Black box recorder
For consumers, the problem is that both ATMs and voting machines are black-box technologies. You can count your cash and keep the receipt; but if someone else withdrew the money you can’t prove it wasn’t you. “It’s the same with voting,” Mercuri says. “You have no way to prove or disprove how you voted.” At least with voting, citizen groups are motivated to push for greater transparency. Jason Kitcat, Green councillor for Brighton and Hove, organised volunteers to observe e-voting trials in the 2007 local government elections in England and Scotland on behalf of the Open Rights Group. “We saw the same audit log issues,” he says. “We know from a computer science point of view that making an audit log that can’t be changed is impossible. But it seems as if there’s a huge disconnect between people who are computer-science literate, and the people delivering the policy.”

Besides, politicians like making uncontroversial decisions. Who could fault them for trusting a company that makes ATMs worldwide? Again, it comes back to humans. “The folks who buy ATMs [bank managers] and voting machines [election officials] don’t really want to pay for a facility that will make it easier for people to challenge them,” says Ross Anderson, a professor of security engineering at Cambridge University. “In the long run, of course, this ends up costing them more: fraud can lead to challenges that are systemic rather than local. Nevertheless, the purchasers may be rational. Most of the bank managers who bought crap ATM systems in the 80s are retired now – they got away with it. With voting machines, some vendors have been discredited in some countries, but lots of money has still been made.” That is, from us – the taxpayer and the bank customer.