I 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!

If 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?

Rick’s post reminded me of some thoughts on the same topic. Roughly speaking, identity can be broken into three categories. Say you go to a party and no one knows each other, you could reveal identity like this:

• Veronymous - you’re wearing a name tag
• Pseudonymous - you’re wearing a name tag with some made up name (e.g. Richard Bachman)
• Anonymous - you’re not wearing a name tag

People have a tendency to confuse veronymous with pseudonymous. A serial number on a ballot could be either, depending on how identity is protected.

A Diebold rep says to me “you can’t be putting a serial number on a ballot; it identifies you.”

I counter by saying the order ballots get stored in a DRE memory card can identify you too.

He replies “but they’re stored in random order.” Whoa now, don’t be taking the cryptographer’s lord’s name in vein. “Random” is a holy word.

People like to throw this word around, but this is a special word for people in the world of information security. So special in fact, that experts argue it doesn’t even exist. People often (erroneously) use it in the stead of “pseudo-random.” I won’t get into why this is (save it for another post), but…

In the end, ye who controls the entropy source knows the order the ballots get stored in memory. At which point you have pseudonymous identification (the “first” voter, the “second…”). If the poll worker was kind enough to provide you with an order that people signed in, you now have veronymous identification.

Not as anonymous as the average person might think. Yet they seem comfortable using it.

And at the same time carry on about serial numbers on ballots.

Well… all’s fair is fair: you can’t have it both ways. I argue that a ballot serial number is, at worst, equivalent to a DRE in terms of identifiability.

But in the end, there really is no way to be truly anonymous on a ballot. There will always be some fingerprint; human or electronic.

Privacy on ballots is tricky…Digital systems suffer from tempest attacks, and a well hidden camera, fingerprint scanner, or a modified optical scanner could all identify a voter . A voter with a cell phone camera can very convincingly sell their vote, regardless of the system. I imagine if I spent some time writing them all down, I could easily come up with dozens of ways to spy on voters or have them spy on themselves to determine how they voted, and almost all of them would be system independent and hard to detect or prevent. This situation is only going to get worse as technology gets smaller and cheaper.

People, particularly the hand counting crowd, also worry about having identifying marks on ballots. A lot of people confuse identifying with unique and mistakenly believe this means there should not be ballot id’s or similar writings on ballots. In reality, it really depends on how that unique mark is used, and if there’s no relationship made between mark and voter then it would not be an identifying mark.

One thing people may not realize is that there are a lot of things that could be considered identifying marks that they would not have thought of at first look. My favorite example must be write-ins, which, in the world of handwriting recognition, would be identifying. Even if you assume the recognition wasn’t good enough to count, you still might have voter’s identifying themselves with unique write-in candidates (e.g. themselves, or something a coercer tells them to put). So, the way write-ins are handled are important, and I think Ben has come up with a good way to handle write-ins in Punchscan (PS).

Another good identifying mark example is marking your choices in a unique way, perhaps by adding a little tail on the optical scan circle, or (in DRE VVPAT) waiting for the confirm printout and canceling with a certain ballot choice and then changing choices to match what you want to show you voted. I think the most interesting one is the “Italian Attack”, and that is, if there are enough races on the ballot, you could identify yourself by using the races as bits, and choose the race you want to show how you voted on (9 races could conceivably give you 8 bits, more if you had IRV or other election rules in place). This one is important because the regular marks are identifying so long as there’s no process to disassociate the races from each other (by cutting them up, I guess?, we effectively do something similar to that to prevent it in Punchscan).

Not permitting weird marks on ballots presents problems, as it makes it really easy to spoil ballots. All you need to do is find a vote you don’t like and add an illegal mark. So I caution people to take a deeper look into the system before proposing identifying mark rules, as the cure might be worse than the disease, in this case. In PS, we avoid this problem by only showing a reproduction that shows what marks were interpreted, this might be the way to go for more traditional systems.

That we won the VoComp grand prize has resulted in some attention from wired, the baltimore sun, ID trail, CBC radio and more recently slashdot.

• What are the details on the security flaw you found? Stefan Popoveniuc was looking through the Java source code to Pret a Voter, and found that they were using Java’s Random() and not SecureRandom() pseudo-random number generator. Strong pseudo-random number generation is essential for privacy protection in their system. NEVERTHELESS this was one line of code — easy enough to fix — and if you ask me, made way too big a deal of.
• Why does your (and similar) systems use random-looking numbers? Is your bankaccount PIN “1234?”
• What is the “chit” component? If you take a look at the video on our main site, you will see it. Basically, it’s a little paper copy of the (encrypted) ballot receipt printed in the bottom corner. The poll worker cuts it off and keeps it. It’s a “if the computer blows up, we can still have the election” mechanism. Don’t underestimate the psychological comfort of paper — we developed this for the University of Ottawa’s graduate students’ union at their request.
• Doesn’t the receipt allow vote selling? This indicates the reader hasn’t made it to the *middle* of our homepage.
• Which voting system did the judges use to decide the winner? 6 judges choosing 4 teams? That’s how Canada can still use a hand-counted ballot!
• More people need to know about OSS voting systems. Being OSS is not sufficient, because the software being open source isn’t what makes a voting system like this secure.  Think about it, if the software was open for review, does that mean that exact version is running on the DRE you’re using? In Punchscan we use cryptography, and we use it to prove the correctness of the results, not the correctness of the software version. For example, the polling place scanner never actually sees your (unencrypted) ballot. So it can’t spy on you. And if it decides to record your marks incorrectly, you have a means to prove it. So the nature of the software running at the polling place is irrelevant to proving integrity of results. This is a cryptographic voting system, not just an OSS system.
• Voting company X is evil. In case you didn’t notice, a business becomes successful doing what its customers want. Blaming corporate America is lazy. And if you no longer believe in the democratic process, then why are you reading this anyway? Otherwise remember, the people buying the voting machines ultimately answer to you, the voters. The voting company you blame, 10 years from now, might be the company that saves democracy by moving toward this new technology. If that’s the what its customers want.

We’re here to tell you that there’s an alternative to dropping your vote down a big black hole. It’s called independent verification. In our case, we’ve even developed, built, and used independent verification in a binding election. We call our system Punchscan.

If you want to help, you can begin by letting people know that there’s an alternative to the current state of affairs in voting.

[L-R, Ron Rivest, David Chaum, Stefan Popoveniuc, Aleks Essex, Rick Carback and John Groh]

I had the good fortune of having dinner with all of the other teams at various points throughout the competition. There was this little restaurant called “South Park” (yes, I’m serious) that David somehow kept convincing people to return to. It was this snobby gourmet place that, although had a burger on its menu (it’s America), insisted that it was accompanied with “pommes frites.” I’ve lived in Europe, I’ve been around the States, but I’ve never been asked how I want my burger cooked (and what’s more, have them actually hit the target). But the greatest part about those dinner was getting to chat one on one with our competitors. And what a treat it was. From fishing to DSLR’s, we were able to, if only for a moment, put voting aside and have a good time; as friends.

This is what I take away from the event. Long after prize money is sunk into student loans, I’ll remember those happy conversations. These people, our competitors, kept me awake at night for months worrying… is our work good enough? Did they lie awake thinking about us? I don’t know. But what I do know is that these teams poured their heart and soul into this competition. I respect them.

The judges had it worse in a lot of ways. I think they found themselves in sensory overload. And why not? Take it from me, practical voting systems design is very complicated. There are so many design decisions to make along the way. Communicating these decisions, and then justifying them? It’s too much for three days. These judges, all of whom are distinguished in the field of voting systems research found themselves in the middle of an information flood. We’ve had month of dedicated thought on the matter; long nights drawing on the chalkboard (yes, Jeremy Clark, our fourth Musketeer has one) thinking about the details.

I think my only regret from this conference was that the nitty gritty details at times distracted from the central message that we, and others like us, are trying to further: independent verification is the next step in the future of elections.