Scantegrity II in EVT 2008 July 11, 2008
Posted by Richard Carback in : Concepts in E2E, Privacy, Security, Voting Events , add a commentWe will be presenting Scantegrity II at the 2008 USENIX/ACCURATE Electronic Voting Technology Workshop. Here’s the abstract of our paper:
Scantegrity II: End-to-End Verifiability for Optical Scan Election Systems using Invisible Ink Confirmation Codes
by David Chaum, Richard Carback, Jeremy Clark, Aleksander Essex, Stefan Popoveniuc, Ronald L. Rivest, Peter Y. A. Ryan, Emily Shen, and Alan T. Sherman
We introduce Scantegrity II, a practical enhancement for optical scan voting systems that achieves increased election integrity through the novel use of confirmation codes
printed on ballots in invisible ink. Voters mark ballots just as in conventional optical scan but using a special pen that develops the invisible ink. Verifiability of election integrity is end-to-end, allowing voters to check that their votes are correctly included (without revealing their votes) and allowing anyone to check that the tally is computed correctly from the included votes. Unlike in the original Scantegrity, dispute resolution neither relies on paper chits nor requires election officials to recover particular ballot forms. Scantegrity II works with either precinct-based or central scan systems. The basic system has been implemented in open-source Java with off-the-shelf printing equipment and has been tested in a small election.An enhancement to Scantegrity II keeps ballot identification and other unique information that is revealed to the voter in the booth from being learned by persons other than the voter. This modification achieves privacy that is essentially equivalent to that of ordinary paper ballot systems, allowing manual counting and recounting of ballots.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Ed Felten on Fox News February 18, 2008
Posted by Richard Carback in : Security , add a commentEd Felten is part of the freedom to tinker blog and is a professor at Princeton. He and His students (also shown on the video) did a report on the Diebold (now Premier) Accuvote TS machines.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
NYTimes OpEd: A Paper Trail for Voting Machines January 7, 2008
Posted by Richard Carback and in : Security , 1 comment so farThe New York times has an interesting opinion editorial on voting that talks about Rivest and Smith’s Twin protocol. The author, William Poundstone, has a new book on elections coming out that might be worth reading. He was also recently interviewed by Mother Jones.
There seemed to be some misconceptions in the comments that Twin is/is not an “electronic system”. It’s a protocol, and an implementation of it would likely be mixed. The piece outlines the most obvious implementation: it would use a website for ballots, and requires a “ballot randomizer” that will give you a
copy of someone else’s ballot. I also found this claim from the article to be interesting:
Yet another opportunity for fraud, perhaps more likely than outright vote buying, would be created if voters were given paper records of their own ballots. Many voters would ditch their receipts in the first trash can they see. Then, crooked election workers could retrieve the discarded receipts and change the corresponding electronic votes, confident that there would be no evidence of their fraud.
I think this was meant to be a jab at Punchscan and other receipt-based systems, but It should be noted that the same opportunity exists for fraud in Twin, you just have to game the ballot randomizer. You deal with the problem by giving copies of the receipts to any observers who want a copy.
At least one commenter asked about its relationship to Punchscan. One difference is that in Punchscan, the receipt never indicates who you voted for, but one commenter noted that in the other system:
Ballot images are secret for good reason:
It is easy to buy or coerce votes if ballots can be recognized by combinations of downballot contests, patterns of zig-zag oval filling, or “stray” marks.
See scantegrity.org for a real solution.
I also add that, if you write down your serial number and call it in before it is posted you can pretty convincingly sell your vote. The crypto can really help in the confidentiality department, but it also helps with integrity, because, unless you’ve broken the cryptography, you can’t know what data to
change until after the results are posted (also note that, even if you break the crypto, you can’t rig the counting process, you can only change the publicized data that is entered into the counting process). At that point, observers have already downloaded all the ballot data and there’s many people who could catch you changing the data.
Smith also has responses to comments on the article.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Telephone Integrity November 21, 2007
Posted by Aleks Essex and Richard Carback in : Security, Voting Goals , add a commentIn trying to categorize integrity in voting systems, its become clear to me that a parallel exists between many other human-technology interactions. Consider the things that have to go right when you want to call someone on the phone:
Dialed as Intended - Given a phone number, you can figure out how to press the buttons to dial it.
Signaled as Dialed - The telephone unit must emit DTMF tones (or pulses) consistent with the buttons you pressed.
Routed as Signaled - The telephone network must correctly route your call based on the signal it received.
Putting it together your call is Routed as Intended.
Obviously the integrity chain is easy for the caller to validate, when the correct person picks up the phone at the other end. But what about when its not? I often phone my sister in the arctic and have to try several times to get through. I could’ve accidentally dialed the wrong number (i.e. not dialed as intended). I could’ve pressed the button quickly and the DTMF tone was not registered (i.e. not signaled as dialed). Or, as often appears to usually be the case, the call is not routed as signaled. The call, being routed through satellite, is often subject to reliability issues, and even bad weather (it IS the arctic!).
Obviously telephone integrity is not currently the focus of much research. But taking these ideas and applying them to electronic voting is.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Shooting Dice November 19, 2007
Posted by Jeremy Clark and Richard Carback in : Security , 3 commentsInside Elections has an interesting post on the dice that were used to randomly select precincts for manual recount. In a Punchscan election, there is a lot more dice rolling. We need random choices of ballots to audit and sides of the tally to reveal.
Dice have their shortcomings. First, to convince yourself a die is not loaded requires a lot of rolling and statistical number crunching. Second, its fine if you are in the room to witness the rolling of the dice, but the process does disenfranchise everyone who is not.
For these reasons, Punchscan uses stock data to generate random numbers. Getting something random out of the data is a bit tricky (although, unfortunately for investors, not tricky enough) but it results in a random selection that anyone with a newspaper or the internet can check. For more details, see this paper.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Cast as Intended: Feeling vs. Accuracy August 7, 2007
Posted by Aleks Essex in : Privacy, Security, VoComp , add a commentOur colleague Ben Adida offers an interesting recap in his blog of this week’s EVT conference in Boston.
VoComp judge and voting systems researcher Josh Beneloah presented a ballot casting protocol and touched on the issue of usability; the ability to cast a vote the way you intend to. Ben explains Josh “mentioned VoComp to point out that there seems to be a dilemma between verification and usability: can we make it look identical to a DRE?”
This brings up an excellent point, because a point we tried to make at VoComp was that usability includes two aspects;
- accuracy
- feel goodness
and more importantly that one does not necessarily imply the other. But I think people have got it in their heads that something that feels easy to use makes it more accurate. But it doesn’t require much conscious thought to push a button. So what if a DRE is less accurate even if people think it’s easy to use? Isn’t accuracy the more important attribute? Somehow I doubt people feel that way.
Kinda like the 80’s architectural trend of putting little shutters on windows - it doesn’t really do what it’s supposed to, but who cares if it looks cool?
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Random Memorandum
Posted by Aleks Essex in : Privacy, Security, VoComp , 1 comment so farI mentioned in a recent post that in talking to a Diebold rep at last month’s VoComp he stated to me that their voting machines store ballots in memory in random order. I had indicated my skepticism to him at the time.
Now I read that in fact the Diebold AccuVote-TSX actually does “record votes in the order in which they are cast, and (it) records the time that each vote is cast.”
I will give the gentleman the benefit of the doubt that he was misinformed.
Alternatively in a cryptographic voting system such as Punchscan, the thing that records your vote only ever sees an encrypted version. So it doesn’t matter if they get stored in order.
UPDATE: Looks like we weren’t the only ones they were telling that lie too.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
In Quotes August 2, 2007
Posted by Jeremy Clark in : Security , 4 commentsWhile this was written during the last cycle of discovered exploits in electronic voting machines, John Allen Paulos hit the nail on the head,
Elections and electronic voting machines invite consideration of the following thought experiment. You go to your local voting station, walk into the booth, pull the curtain, and see a well-dressed man standing inside with a little note pad. He asks whom you’re voting for, appears to record what you say in his note pad, tells you he’ll add your vote to his running total, thanks you, and asks you to send the next voter into the booth. Whatever objections you have to this voting scenario should be reserved for the more familiar one involving Diebold and other voting machines.
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
The Misguided Criticism of CA’s Red Team Results July 31, 2007
Posted by Richard Carback in : Security , 2 commentsI was sent a story from the Sacramento Bee which effectively tries to discredit the results of the red team study I talked about in a previous post:
Voting technology manufacturers portrayed the study as unfair and unreasonable because they said it was conducted without Election Day security measures. They specifically took issue with the fact that the state gave Bishop’s team access cards with secret codes that are typically kept secure by elections officials.
“This was not a security-risk evaluation but an unrealistic worst-case scenario evaluation limited to malicious tests, studies and analysis performed in a laboratory environment by computer security experts with unfettered access to the machines and software over several weeks,” said Steven Bennett, California sales executive for Sequoia. “This is not a real-world scenario.”
This is a load of FUD (Fear, Uncertainty, and Doubt) without much backing, so lets tackle the issues one by one:
Election Day Security Measures — According to the overview of the reports each of the 58 counties each have their own security procedures. In reality, what they did was the most useful, because you can look at all the problems they found, match them up with a certain counties procedures, and find out if you are safe or not.
Instead, what the critics would rather them do would have simply let the critics discredit them another way. If they had done 1 or 2 of the counties or made up their own models, the critics could say “Well, it doesn’t apply to the other 50 or so counties”. The critics would also be able to play the D.A.R.E. game, where, when there’s a known issue in a certain set of procedures, you say “well, next time the procedures will be different”. The **best** way to do this sort of testing is outside the scope of procedures, because then you get the most bang for the buck, and you can build procedures around your infrastructure to help protect you.
Security cards and access codes — This appears to be misleading. It looks like they gave them smart cards, but a majority of the problems that were found don’t even use them, just look at page 9 of the overview: election management system problems, problems w/ the operating system, static security keys — none of these appear to require a smart card — although they mention that the cards themselves were also easy to forge.. oops. I can’t imagine it would be very hard to get a hold of one of these cards or create one of your own.
Access to machines — This is deliberately confusing the amount of time it took to find flaws with the amount of time it would take to exploit them. Finding a flaw is sometimes tedious, but exploiting one can take seconds or minutes. Plus, the machines are stored in a backroom for months at a time, it couldn’t be too hard to borrow one for a few weeks to find some flaws, or steal the source from a vendor and find it that way..
Worst case scenario — Maybe this is obvious, but shouldn’t that be what we are looking at? In any case, from the overview:
The results presented in this study should be seen as a “lower bound”; all team members felt that they lacked sufficient time to conduct a thorough examination, and
consequently may have missed other serious vulnerabilities
That doesn’t sound very “worst-case” to me. It sounds like they had a limited amount of time on the order of weeks, and could have probably found much more if they could have examined the systems in depth.
To summarize, trying to discredit these guys by saying this “is not a real world scenario” shows a fundamental lack of understanding what they were trying to do. I’ve just scratched the surface here, and I wish I had more time to get into it, but I don’t so I hope this gets the point across.
Good news! that video is available!
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.
Thoughts on CA’s “Top to bottom” review July 30, 2007
Posted by Richard Carback in : Security , 1 comment so farIf you didn’t already know, California’s Secretary of State Debra Bowen sanctioned tests of all of the certified systems being used in the state. They just posted the results a few days ago, and received some press about it from the NY Times and SF Chronicle.
The results of the red team tests are scary but not very surprising. It has been evident for years now that vendors on the whole build voting systems and then add-on security features, and as anyone who’s taken a class in computer security knows — that’s just not the way you do things. It was good to hear that Matt Bishop lead the red teams, he’s written several
books, and is probably one of the best you could get to do such testing.
There was a hearing about it all today, but I haven’t been able to access it. It appears to be a bandwidth issue (haven’t these people heard of youtube?!), so hopefully it will be viewable soon.
In both of the press articles there appears to be this notion that the problems they found are somehow less valid because in the real world people wouldn’t have access to the same resources, or some procedure would protect the machines. The most egregious of those statements came from the SF Chronicle article:
Letting the hackers have the source codes, operating manuals and unlimited access to the voting machines “is like giving a burglar the keys to your house,” said Steve Weir, clerk-recorder of Contra Costa County and head of the state Association of Clerks and Election Officials.
Actually, it would be more like giving the burglar the lock, it’s manual, and other schematics, and asking them to pick it. Anyone in their right mind would conclude that if the burglar couldn’t pick it, then it must be pretty secure if the burglar was fairly good at picking locks (although, this doesn’t guarantee it couldn’t be picked).
We are actually talking about two different premises: “Our attackers won’t know enough to do it”, and “Procedures will protect us”. The first is a variant of security through obscurity, and most people would say its a bad idea. I think that it is a particularly dangerous notion in the voting world because it is, by its very nature, an adversarial environment. This isn’t the CIA or NSA where most people have been vetted to be “on your side” with background checks and lie detector tests, particularly those in sensitive positions (and even then, these guys are watched carefully). In voting the vast majority of your workforce is volunteer, and what isn’t is a mixture democrats, republicans, and others who are by no definition a fully cooperative group. This doesn’t even consider the leanings of the vendors.
The bottom line is that the attacks you need to look out for shouldn’t just be from the outside looking in. The security through obscurity is particularly weak in this environment because who has the information is well known.
The other argument of “procedures will protect us” is also not so great because it depends on who’s following the procedures. In order for them to work, you need to be very explicit about starting fresh, what happens during the whole process, and how you end. Then, you need to define how oversight is done: is the person being recorded the whole time? Is there a person from another party watching? As you can imagine, this is a tedious process, and it is only as strong as its weakest link — what happens when the watchers cooperate with the watched, or when they aren’t watching?
As I said, the red team results weren’t surprising, but the accessibility report was pretty astonishing. From the report:
Although each of the tested voting systems included some
accessibility accommodations, none met the accessibility requirements of current
law and none performed satisfactorily in test voting by persons with a range of
disabilities and alternate language needs.
Isn’t the accessibility what the DREs were supposed to help with in the first place?
The content of posts to the Punchscan blog belong to the author and do not necessarily reflect the thoughts, feelings, or opinions of the Punchscan voting project.