A while back I visited the Black Box Voting online forum trying to elicit collaboration with what I saw as a shared goal of our respective projects: voter verifiability of election results. They weren’t interested. I don’t think it was the ends that was the problem as much as the means. BBV attempts to address with paper that which Punchscan attempts to address with paper and some cryptography. Although I understand what they find attractive about the old-school approach (being a practitioner of hand counting myself) I just don’t agree with any totalistic views in connection with computers being wholly bad for voting.

Today I received an email announcing a new BBV investigative report, which I took a read through and pulled out this:

When you introduce computers into the voting process this forces the citizens - who own the government - to trust government insiders to tell the truth about election results. [...] Citizens can see paper ballots counted in public at the polling place, but we can’t see what goes on inside a computer.

• Sentence one: Disagree - Punchscan proves (or disproves) election results to voters… independent of government insiders (whomever they’re supposed to be).
• Sentence two: Agree. We can’t see what happens inside, but we voters can see and control what comes in and out. And that forms the basis for an information based solution.

One of the requirements of an E2E system is no single trustee is able to decrypt ballots, in the exact same way that no one returning officer may have unobserved custody of a ballot box. Same idea. What you’re doing is distributing trust across several people or groups. There’s a physical solution obviously: chain of custody and observers. There are also ways to distribute trust across an information system. Simply put: everyone gets a key, and you can only run your election correctly with all the keys.

We proposed and implemented an open-source verifiable trust distribution system where everybody gets a copy of the software, and everyone checks everyone else’s copy matches theirs. It uses passwords and USB keys. We demoed this at VoComp.

For the record, Punchscan doesn’t really use that much cryptography and the entire system can actually be explained without any crypto at all. But for all the bellyaching that frequently accompanies the mention of the word, it really does buy you something: integrity of election results. The government insiders can’t change the outcome.

Punchscan is built on the use of digital bit commitments. That’s just a fancy way of saying: I write my wife a love letter, put it in an envelope, lick it, seal it, give it to her, and tell her to open it on Valentine’s day. Then when she reads it, she knows I really was capable of saying those “3 words” on more days than one.
But hey, obviously this is way too hard for the “average person” to understand… so just forget about it. (Note to self: Hash “I LOVE YOU” and email to Anna).

If it wasn’t a 10 hour drive from Ottawa to D.C., you can bet I would’ve been sitting right next to Rick at yesterday’s ITIF press conference.

Despite what all the pundits have been saying, for better or worse, and indeed my own thoughts on the details of the report, I can say overall I was pleased with it. Of course I would’ve preferred Punchscan to have been directly named, but ultimately it is the conclusion that I feel matters most:

• Congress and the states should allow the use of fully electronic ballots, not restrict electronic voting systems to those that create paper ballots.
• Congress and the states should require that future voting machines have verifiable audit trails, not require machines with verifiable paper audit trails.
• Congress should provide funding for the U.S. Election Assistance Commission to issue grants for developing secure cryptographic voting protocols and for pilot testing of new voting technology.

Of the first two: well said. The third item, which I support in principle, has been a slight matter of contention (which I will explain in a future post). The long and short of it being that the EAC removed all mention of E2E in its 2007 draft of the Voluntary Voting System Guidelines! That setback coupled with talk about HR811, combined with the sentiments of the anti-tech lobby on the matter have led to a woebegone week.

So it was nice to hear another voting source saying “paper’s not the only way.” Don’t get me wrong, this “19th century” technology is still used to great affect in many democracies including my own. But the engineer in me says “for goodness sakes, match the solution to the environment.” I could argue with people until I was blue in the face over the sanctity of paper, and believe me I have.

Science and politics make strange bedfellows. At least our research hasn’t become politicized like climatology, where researchers in some instances loose their grants when their findings don’t align with the popular position on global warming. You don’t need to be in the pocket of Big Oil to disagree with Al Gore. Likewise I don’t need to be in the pocket of Microsoft to appreciate the ITIF’s recommendations (although it’d sure be nice!).

In the end, the US will either expand its thinking beyond the confines of paper, or sink into a pathology that surrounds itself with Canada’s biggest export. I win either way, I suppose

Having just finished reading it, I am intrigued by the report, disagreeing with parts, surprised by others, and in agreement on many points.

The Event

I did end up heading down to D.C. to attend the event. Unfortunately, it took me 2 and a half hours as opposed to the usual hour and 15. I left early, so I only arrived a half hour late, and caught the tail end of the talk and the discussion afterwards. The end of the discussion was unexpectedly civil, so it seems like the talk went over well.

From what I could tell, there were people from the EAC, OVS, TrueVoteMD, the AFB and the Library of Congress. I am sure there were other individuals from prominent groups there as well, the room was pretty full. In particular, I was hoping folks from EPIC and the EFF would be present. My advisor, Alan Sherman, showed up and when Punchscan came up in the discussion he pointed me out as one of the developers.

Unfortunately, the room cleared out quickly, and I did not get to talk to very many people. I was particularly interested to hear from the TrueVoteMD rep, who I sat next too but left as soon as the discussion ended before I could introduce myself. I did talk to one of the EAC commissioners, Rosemary Rodriguez. I also talked with David Webber, of OVS. He, the speaker, Alan, and myself shared interesting conversation over lunch. This made the trip worthwhile.

The Paper

As I said, the paper was intriguing, and I was really all over the place on my thoughts/opinions. Overall, I think it has the right intent but it has a perspective that a lot of people (particularly activists) are not going to like. At it’s core, the document promotes universally verifiable end-to-end cryptographic technologies, but i’m not sure if that message is going to get through given the title and first half of the report. I will start by pointing out the surprising bits, then what I like, and end with what I dislike about the paper.

What Surprised Me

On Page 9, it opposes a federal open source code mandate but supports use of open source by the states, and it specifically quotes “security through obscurity” as the reason:

Although Congress should not mandate the disclosure of proprietary source code, states and counties would be wise to show preference to voting system manufacturers that publicly release the source code of their products for review. “Security through obscurity” has long been derided as an ineffective safeguard against attackers. The security of the voting machine should not depend on the confidentiality of the machine source code. Voting systems with publicly released source code will undergo greater scrutiny and testing by security researchers than those that are only tested in government-approved laboratories. Furthermore, voters will have a higher level of confidence in elections conducted on these machines given their greater degree of transparency.

The author provides existing alternatives to paper audit trails: the audio ballot, IV machine, and single-input-dual-output. Granted, I am not fond of any of these methods, but it does show that he has done his homework. You can find them on Page 10.

There are examples of fraud w/ a paper trail. He talked about the LBJ voting fraud scandal, and the switch to lever machines. Most people never do this when they talk about paper trails, just saying that they are bad, but he justifies it:

The integrity of a paper ballot still depends on physical security controls. Historically, failed security controls have led to modified, spoiled, and stolen ballots, as well as to stuffed ballot boxes.

What I Liked

I really liked that he spent a few pages explaining many of the cryptographic primitives that are used by E2E voting systems. These primitives are difficult to comprehend and I think he did a decent job in explaining them. You can find them in Box 1 and 2 on pages 12 and 13. I also liked that he talked about some example systems (VoteHere and Scratch&Vote).

He provided an excellent explanation of the core problem in securing elections on Page 9, one which I have not seen before:

The real problem with the current generation of DRE voting machines is not that they use computers, but that the integrity of the election depends on maintaining a secure chain-of-custody of the voting machines and the ballots. This problem is not unique to DRE voting machines, because the integrity of the election in a paper ballot system is similarly dependent on a secure chain-of-custody. In either voting system, a ballot can be compromised only if malicious actors are able to insert themselves into the voting process by, for instance, stuffing a ballot box or changing the code in a DRE voting machine.

He excellently characterized the difference between VVPAT and similar methods from those of E2E (which he terms local verifiability and universal verifiability):

Unlike local verifiability, universal verifiability allows voters to be completely confident in the validity of the final election results.

And also this quote:

Ultimately, voters want to know that their vote was included in the final tally. Paper audit trails do not provide this assurance.

I think the core premise of the paper was well thought out. It doesn’t seem to me that he’s discounting paper trails so much as saying that thinking they are going to solve all our problems is misguided, and pointing out that E2E, or universally verifiable systems as he calls him, are a good alternative. The caveat to this is that the beginning is set up to solely be an attack on paper trails. I have a feeling that many individuals will not bother reading the whole paper.

Dislikes

The paper does not make a concerted effort to differentiate between current DREs and the E2E approach, and I think that is very confusing. E2E is an entirely different approach to the way the software is built, and it feels a bit dirty to equate it with DREs. In fact, the article discounts many of the issues with DREs. When talking about the Top-to-Bottom review in CA, he says the following:

While the report serves as a valuable tool to evaluate and improve the security of these machines, the so-called “attacks” detailed in the report are inconsequential. While these attacks may work in the lab, most of these attacks are unrealistic in real-world election conditions. As the authors admit early on in the report, they made no assumptions about the “compensating controls or procedural mitigation measures that vendors, the Secretary of State, or individual counties may have adopted.” Moreover, the authors acknowledge that the “testers did not evaluate the likelihood of any attack being feasible.”

The quotes he raises are true, but as i’ve said before, it was better that they did it that way. You have to use that report, and take a look at your procedures to see if you are really protecting yourself or not. Having looked at many, many reports on this stuff, there’s quite a few problems with DREs out there where I don’t think you could employ effective procedures to protect yourself. I strongly disagree with the author on this point. That said, he does talk about parallel testing, but my understanding is that very few states use it effectively.

On a minor note, the paper makes the argument that people trust computers to do lots of important things. I would have liked to of seen a section talking about how voting machines should go through more extensive testing, similar to what those other important things go through.

The other thing I strongly disliked was how the paper attacked the opposition to DREs. The paper starts off by calling the whole group technophobic, and thats not true. The sad thing is that many people who disagree are going to do the same thing — wondering who’s pocket ITIF is in and other similar attacks. In my eyes when people do that, they lose credibility. What is important is what they have to say, not their affiliation, funding, or where they are from.

Lastly, and this is obvious: I dislike that he didn’t talk about our system.
Any-who, I encourage you all to read the report and make your own decision. I’ve already seen some disappointing commentary from Computer World which basically misses the point. There is a piece from ars technica that harps on how the paper attacks the opposition. It also makes this bizarre assertion that paper trail has different vulnerabilities than an all paper system, and seems to mistake the receipts provided by E2E systems as a paper trail. Lastly, and this is surprising, Ed Felten and crew have commented on the article, and they also appear to miss the point.

Over the last week, the big discussion in our neck of the woods has been about the HR811 bill, and if the requirement for a conventional paper audit trail would make Punchscan uncertifiable. Now the discussion is beginning to ask if the bill will be amended to also allow for this new breed of audit trail, such as what Punchscan offers.

We’ve recently been made aware of the Information Technology and Innovation Foundation which is hosting a press conference for a report they are releasing next week about the security of paper trails, which was brought to our attention by articles appearing on slashdot and bradblog. The conference, called “ITIF Forum: Stop the Presses – How Paper Trails Fail to Secure e-Voting”, has this excerpt from their announcement:

In the report, ITIF advocates that the debate over voting technology should move beyond paper audit trails to a discussion of how new technology can dramatically improve the ease and accuracy of voting. The report discusses new innovations in voting machines that offer “end-to-end verifiability” and explains the cryptography behind these systems. ITIF concludes that Congress should adopt language similar to S. 730 (Sen. Dodd, D-CT) and H.R. 2360 (Rep. Ehlers, R-MI) which does not mandate paper audit trails, but still requires a verifiable audit trail.

The comment from bradblog is in stark contrast in interpreting the nature of the technology being presented in this report:

The Information Technology and Innovation Foundation correctly argues that paper trails don’t ensure accurate e-voting totals. We agree with that argument. However, rather than use that argument in a move to ban non-transparent DRE voting machines, this group makes that argument and then argues that more non-transparent, unverifiable technology should be used along with the DREs. They want more unproven technology that costs more money and further removes the voters’ ability to have a say in the election process.

Given that the ITIF report will discuss voting systems with E2E (i.e. End-to-end cryptographic independent verification) , and given that Punchscan is one of the premier examples thereof, we assume the bradblog post author from VotersUnite.org is speaking, in part, about us. It would seem that this individual is not familiar with the notion of E2E and its focus on transparency and independently verifiable technology.

We invite this organization to learn more about non-paper trail verification methods, and to reexamine their byword: “an electronic ballot is secret from the voter who cast it.” That’s only true when voters can’t independently audit it.

On another note, lets be clear that Punchscan does use a paper ballot, but voters take home what is left of it (which does not show how they voted). This gives them the (previously impossible) ability to check the official, always public, digitally available record that their ballot was included, correctly, in the final tally.

As for the ITIF’s announcement, we don’t really know who they are or what they are about, but the event looks interesting and Rick (who is from baltimore) is mulling over the drive down to D.C. see what this is all about.

In light of the Washington Post opinion piece generating the most recent bout of discussion with respect to HR811, Punchscan has again found itself being commented on in the public arena. Without touching on the topic of discussion itself: legality of paper receipts in the new bill, I’d like the set the record straight on some other points.

• Punchscan is not a team of researchers from the University of Maryland. There is one member (Rick) from the University of Maryland, Baltimore County (there is a distinction). We also hail from George Washington University (Stefan), University of Ottawa (Me, Aleks) and University of Waterloo (Jeremy).

I read a recent post from the blogosphere that I think contains a few misconceptions about Punchscan that I’d like to address.

One half of the ballot can be discarded, and the other half of the ballot (not a receipt) scanned to verify your vote.

The ballot half that is kept is the receipt. It is not scanned to verify the vote, it’s scanned to record the marks.

The first problem I see with this are that it is a cumbersome verification process

There are two verification steps:

1. Looking up your receipt and checking to see if what you hold in your hand is what was used in the tally. This only needs to be undertaken by even a fraction of voters and still be effective.
2. An (open source) audit application that can be run to check the security of the system. You download an election data file, run the program, click one button, and it tells you if everything was verified or not. This can be undertaken by an even smaller number of voters and still be effective.

In my opinion, going to a website and typing in a serial number and then comparing the screen to your receipt, or a few mouse clicks of a program on behalf of a few voters is not particularly demanding, especially when it’s giving you serious assurance about the integrity of the election.

However if that’s people’s idea of cumbersome, but they don’t want to go back to hand counting paper ballots, because that’s cumbersome too, but they don’t want to stick with the DRE machines because of integrity concerns then what?

Although the system contemplates your being able to verify your ballot from your home PC, this creates additional issues of vote security (IP accounts can be tracked, and may identify individual voters)

Not so. Because the ballot receipts do not contain the actual vote, voters are at their liberty to keep, discard or give away their receipts. You may post your receipt on mySpace, or give it to a democracy advocacy group to check for you. That means an IP address looking at a particular receipt is no indication of ownership.

I’m back from vacation — it was a good time. I had some thoughts about software assurance and it’s role in voting, and I thought of this analogy.

Suppose we have two bridges, built by the vendor BridgeTec. Both have the same general design — they look the same, and they use the same materials. Bridge A was built first and B was built shortly after. Some time later, the state in which bridge A was built asks some engineers to do a study. The study finds significant structural defects in the bridge and closes it down until BridgeTec fixes the problems.

BridgeTec admits to the problems but says that it’s not been shown that these problems will manifest themselves in the real world, and that bridge B is fine because “it’s a different bridge”.

Who in their right might would believe that?

Yet, thats the gist of what Diebold, Sequoia, and Hart InterCivic are saying.

To me, the very notion that “it’s different” can be used as an excuse and *anyone* can think that it is valid is confusing to me. Likewise, the idea that problems won’t manifest themselves due to procedures in the real world are almost as equally confusing — you could only really make that claim after you know what the procedures are and have justified why they will protect you.

They really should “prove” to you that it’s secure, and they could do that with assurance building activities as they are talked about in an often cited paper by Brian Snow titled “We Need Assurance!”. Right now people are operating on the principle that “it hasn’t been proven otherwise”, and that’s just flawed on so many levels. Instead we should be operating on the principle “show me why”.

While there are lots of definitions of Software Assurance, I prefer NISTs: “the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures to help achieve:

• Trustworthiness - No exploitable vulnerabilities exist, either of malicious or unintentional origin, and
• Predictable Execution - Justifiable confidence that software, when executed, functions as intended.”

Maybe the school of thought is that, indeed, they have shown it is secure by passing certification requirements. However, as Rubin has noted, the certification process isn’t really set up properly. The fact that 3 vendors have been shown to suffer from the most basic security problems only goes to show how badly the process is broken.

What we are doing, and what they really should have been doing all along, is to try to build security into the system from the beginning. Unfortunately, the cost cutting nature of the industry would never allow such a thing back then, but now we can see that they are paying for it now.

I want to echo Aleks’ post, and mention my gratitude to Ben Adida for his excellent summary of EVT. Unfortunately, between FEV 2007 and thesis writing, I don’t think anyone from Punchscan could work EVT to into our schedules.

At the end of his post, Ben makes a good point,

I remain a little bit disheartened by the continuing gap between the crypto and applied security crowds. The crypto folks (me included) need to do a better job pitching this stuff, especially now that there’s an opening to improve the technology in places like California.

We have at least three interest groups that strongly oppose electronic voting machines. As pointed out, there is the software security crowd. There is the the crypto crowd, of which we are a part. And there is the black box voting crowd, who oppose essentially any role for technology. As voting is a political problem, it requires a political solution, and good politics always involves coalition building between groups who don’t always agree on everything, but can at least agree on the specific issue at hand.

I’m not exactly sure how to bridge the gap. However I will say that from Punchscan’s perspective, we need all three. Punchscan is fundamentally a cryptographic system, and through cryptography we are able to eliminate trusted computing at the polling places. But we still need trusted computing for tallying to protect privacy. And so there is a role for software security experts. We also need voters to check their receipts, and this can be augmented with voting advocacy groups, like BBV, collecting copies of receipts at the polling place exits and diligently checking them.