>>: Good morning, everyone, and welcome. There are a lot of important issues
about voting that have come about in recent years, we've seen, although maybe
come about -- maybe it's not right to suggest they're new, but a lot of interesting
technology issues, certainly come to the forefront.
We have a lot of people in this area who have done some interesting work on
voting, and a few visitors also. It was actually Sidney Comora's [phonetic] idea,
the co-organizer of this workshop, who thought as long as we have all these
people around, it would be really nice to get people together to talk about ideas
and introduce some of the main points the people who may not have seen them
in the past.
So he and I spent some time and put things together. I think we've got an
exciting list of speakers in workshop this morning. We'll have morning set up as
more of a formal, sort of structured background set of talks to give people a little
bit of an introduction to the area and then the afternoon is going to be more
free-flowing, talking about some current work some ideas, the ideas that it's more
flexible and more of an exchange.
To start off and give us a little bit of is the background of what's happening, I'm
very pleased that we have Paul Miller, who is the voting systems manager for the
state of Washington, who is going to tell us -- give us some grounding, I guess,
about what it's really like out there in the world, and how things work. Some of
the issues facing the public sector and some of the problems.
Paul, in addition, has worked as a member of the technical guidelines
development committee of the election assistance commission. Have I got that
right?
>> Paul Miller: Um-hmm.
>>: Which is doing a lot of work now on trying to advance new requirements,
new ideas into the landscape of voting systems. And he's going to tell us a little
bit about some of what's going on. So welcome. Thank you, Paul.
>> Paul Miller: Sure. Well, I first of all, I was voting systems manager, probably
the last time Josh and I worked together. My title now is actually senior, which
means I'm old. Senior election technology analyst. And my -- and I, in addition
to working for the Secretary of State for the past ten years, before May, 2000, I
was working for King County elections as their elections director, assistant
director in charge of data processing.
So I've had a lot of experience, both at the local level in terms of putting voting
systems together and getting them fielded, and then at the state level, looking at
the systems and deciding which ones should be certified and which ones
shouldn't be.
And so to sort of give you a quick background, you know in terms of Washington
and voting systems, they -- we have four different voting systems that are in use
in the state of Washington. It was originally three different vendors and now it's
kind of all up in the air. We have with a used to be Global, then Diebold, then
Premiere, and now ES&S with the DOJ suit requiring them to divest themselves
of much of what they acquired from premiere, it's unclear the system King County
belongs to. They're the only system -- county in the state that has that particular
system.
And then we've got about 12 ES&S systems, which also are fill in the oval. We
have about Sequoia systems, which are the connect the arrow system. And we
have Hart, which is a digital scan, fill in a box, have it scan the entire image gets
scanned and stored and processed. And we have about 21 counties that are
Hart counties.
I originally understood Josh to be asking me to talk with you about why election
officials don't like end-to-end voting, which just to prove that you guys are a lot
smarter than I am, after thinking long and hard about that, I thought I don't really
want to do that and called Josh and he clarified that that's not what he was
asking me to do. He was asking me more to talk about what the real world
problems are as opposed to that we encounter as election officials and probably
in the process I'm giving you the perspective that we tend to approach these
issues from, which may well be a very different perspective than you're
approaching these issues from. And again from my, at least I can speak for
myself. From my perspective, having worked in this area for 20 years, the
challenges to ensuring the accuracy of election start primarily with human error.
Either human error on part of the voter or human error on part of election staff.
So one of the challenges is to build systems and create processes and an overall
system that reduces that amount of error while also preserving the values that we
have in our society about voting, which is to protect the privacy of the ballot and
to ensure that one person, one vote. And ensure a way that, you know -- and
one of the things that I think that we're adding in terms of being able to ensure
public trust in the system is ensuring that all systems can be auditable.
So that's number one. Number two, I think, is probably the human ballot
interface issues. That there are a lot of problems that occur in that area that
create inaccuracies. And then I would probably put machine failures way down
at the bottom and I make the comment that I think that a lot of things that get
reported in the press as being machine failures and computer failures are, in fact,
human errors and human and procedural processes that weren't followed
correctly.
Thought I'd talk quickly about a couple, a few national issues that I've -- my
perspective on them and then I'd get down to Washington state specific, because
that's what I know. And Washington state, we're a little bit unique in that we and
Oregon are the two states that virtually everyone votes by mail. We have almost
no polling places, which means we also have almost no DREs and some of those
kind of issues which other states are dealing with.
But at a national level, and as an infrastructure level issue, I think one of the big
issues that we're dealing with is sort of the market size that we're dealing with
and the funding sources that we're dealing with. As we were discussing last
night, the market is small. It's not a market that a lot of companies want to get
into, number one. And number two, it's not a market that's particularly a
profitable one. I believe it was Forbes magazine had an article that I really
thought nailed it on the head and it referred to voting system salesmen as that
type of salesman who works out of the trunk of their car. I think that's not
completely accurate picture, but it can -- it really conveyed the idea that up until
2000, at least, voting systems were on a 40-year cycle. They were the IBM
punch card machines, and they were the lever machines. And those things had
been around forever. And jurisdictions did not intend to replace them until they
wore out, broke down.
And they were remarkably sturdy and hardy technologies. So one of the sea
changes I think that's happened that hasn't really been fully worked out in our
country yet is that after HAVA, we have moved dramatically to increase the
amount of the personal computer type of technology that's being used, the life
cycle on that is usually intended to be three or four years. It's going to be in the
elections industry, I think, at least ten years, and that ten years is coming up
sometime in 2012, 2013 and I don't know what jurisdictions are going to do at
that point. Because the funding priorities tend to put election equipment down
below the sewers and pothole fixes.
And so some counties have already begun to start replacing their equipment and
get upgrades and that sort of stuff. That's been encouraging that there's been
money for that. But my experience has been that to get, really to get the funding
that an elections department needs, something has to go drastically wrong in an
election, and then we throw money at it, and then, and often without laying the
kind of groundwork that really needed to be laid to throw the money at it. And
then it's expected to last another 10 or 20 or 30 years.
And one of the -- the other aspect of this is is that election officials are actually
very resourceful in trying to make the technology that they have work, and it may
require them a lot more work, a lot more staff than it ought to. The operation may
be more expensive than it ought to be. But they make it work. And as long as it
works, people don't see a need to change it.
Recruitment of poll workers. In a state like Oregon and Washington, we don't
have a problem with recruitment of poll workers. We don't have any polling
places. But nationwide, that is a big problem, trying to find people who are willing
to work for 13 hours a day for minimum wage. What you get are people who are
not working, and your best people that you can get are people who consider it a
civic responsibility, are willing to work 13 hours and be yelled at all day, and they
tend to be retired and elderly.
Some of the human interface issues, you're all familiar with the butterfly ballot.
You may also be familiar with Sarasota county and the issues that came about in
that Congressional race, where there are so many under votes on DRE
machines than they were in any other methods of voting.
From my perspective, it was pretty obvious when I saw how the ballot was laid
out and portrayed on the screen as opposed to how it was laid out and portrayed
on paper. And on the screen, it was pretty obvious why the human eye would
skip over that contest to go to the next contest.
But when the culprit is considered to be -- so the interface is an issue, if we
understand it, we can solve it. If the machine is a problem, we can understand
that and solve that. But when the thing is that it's some diabolical computer
program that is doing this, we can't get to the problem and solve the problem.
And so part of getting public trust is making sure that, I believe, that our systems
all have some means of accountability, which is my, as a member of the TGDC, I
supported Ron rye vest's proposal for software independence. Not because I like
the term software independence, it was more a matter, I thought this brought in
an assures of a way of auditing our results and being able to say if there's a
question in a low -- about our outcomes that we can show whether or not the
outcomes we produced were accurate outcomes.
So take a minute to talk about Washington in particular. As I indicated earlier, we
are vote by mail, except for one county and that's Pierce County. We have 39
counties with approximately 300 -- 3.5 million registered voters. And we -- they
range from about, oh, 1,500 registered voters in a couple of our very small
eastern counties, to King County, which is about 1.2 million registered voters and
about the 13th largest voting jurisdiction in the country.
Combined with Pierce and Snohomish, which are both Puget Sound counties,
that counts for over half of our registered voters in the state of Washington.
Which means that 99% of the ballots that we count are paper ballots. And
there's two principal means of processing paper ballots. One is that, is what we
call optical scan and the other is what we call digital scan. In the optical scan
world, what the machine is looking for is for a mark that is adequately bold -- and
how do you define what is adequately bold is an issue. But a mark that is
adequately bold at a certain horizontal and vertical intersection.
And if it's there, if they see it, it's added to the vote. And if it's not, then it's not.
With the digital scan, the 21 Hart counties, what they're actually doing is taking
and actually using off the shelf type of copy machines, Fujitsus and Rijoh, and
that kind of equipment to scan the entire ballot and then the software is able to
process that, the ballot in terms of being able to determine who voted and for
what candidate, what contest.
Since we're a voter intense state, the challenge for us is that when we receive a
ballot, that that ballot be marked in a way that the machine can actually read it.
Now, I think it's probably pretty obvious, it would be pretty obvious to all of you,
because a smart bunch of people, that if somebody circles the name and doesn't
fill in the response area, the machine is not going to see that as a vote.
If they use -- what might not be quite so obvious is if they use the wrong kind of
ink or use pencil instead of ink, or vice versa, depending upon which technology
you're using, the scanner's not going to pick it up. And so we have preinspection
after sort of the identifying aspect of the packet has been separated from the
ballot packet, we unseal the ballot end and pull out the ballot and take a look at it
and the staffs that are there are trained to recognize what will read in the optical
scan reader and what won't. And what won't, they have to duplicate to another
ballot. So that's the process there.
What kind of impact does that have? Well, one, what I've illustrated is that within
a vote by mail environment, we have less control over the utensil that the voter is
using to mark their ballot.
What we also don't have in that environment are means of providing immediate
feedback to the voter. At the polling place, if you're using a DRE, the DRE
immediately gives you feedback as to what it thinks your touch meant. And if it
doesn't respond the way you think it should have, you try again or you try
something else, you try not to put your finger and drag your finger down the
screen or touch your screen with your palm of your hand or do some of the other
kinds of things. And sometimes there calibration issues. So if you actually mark
the candidate below or just a little bit below where you think you should be
touching or above, you'll find that it finally will accept your vote the way you
intended.
There are some real machine/human interface issues in DREs that need to be
dealt with, that need to be better than what they are. But it isn't, I don't believe at
all, any diabolical type of issues. Ironically, because a voter has that immediate
feedback and they immediately see that the feedback is wrong, interpret that as
diabolical. Whereas, interestingly enough, in a state like New York, which still
has lever machines, we've got people fighting against having DREs who want to
keep lever machines, where it is very well documented that the lever machines
have a lot of problems but you don't know it, because you don't get the feedback.
So the human interface on the DRE needs to be dealt with and improved and we
need a means of being able to audit that process so that we can establish that, in
fact, that that voter had the opportunity to see how the machine interpreted their
touches and that their touches were counted in the way that the machine
understood their touch.
We have -- so with -- and on top of that, in terms of the difference between
absentee balloting and poll balloting, is that we have a signature requirement that
we have to be able to match their signature against the signature on their original
registration form. Which means that a certain number of people whose
signatures get -- who change over a period of time wind up getting their
signatures rejected.
We have a process to try to contact them, get them in, get their signature
updated so that we can get their ballot counted, but we still probably have
somewhere in the range of one percent, maybe two, who get rejected on that
kind of basis.
>>: Thumb print fix that problem?
>> Paul Miller: A thumb print has the potential for fixing that problem, I think,
yeah. And we've been talking about that may be the technology of the future as
far as how we would do this authentication process.
As we discussed last night at our dinner, we also have a bit less control over the
voting environment, which opens up the potential for other issues like coercion,
which in the years that we have been using that in this state and in Oregon, we
haven't gotten any reports of that. But it may be a very difficult issue to get to.
Another issue that is difficult for us is the concept of -- is disability -- access for
people with disabilities. We're required to have one DRE at the county site for
people with disability issues. It presents problems for people with disabilities to
get to this one location in the county. We are working with ways of getting the
equipment to them so that they can vote.
We also looked at ways, including this past fall, where Franklin County, when
they sent out their absentee ballots, also made an online ballot available where, if
you typed in the ballot code, which is not anything unique identifying them.
Simply what style of ballot. Type it in, they were able to vote online and print that
out and send it back. Helps people who have difficulty -- it's easier for them to
hear something than it is for them to see it. It's going to help them.
>>: [inaudible] rather than downloading voting locally and printing so no
information leaks out?
>> Paul Miller: I believe that's the -- that's the way that worked. But even in that,
loading down the app, it was important to us that you couldn't -- that the system
couldn't identify who was doing the voting. That the only thing that they needed
to provide was -- and how am I doing on time, Josh?
>>: You're fine.
>> Paul Miller: That the only thing they needed to provide was what style ballot
they were going to vote, and so they went through, clicked their thing. They were
also able to click and get the voter pamphlet statement of the candidates and the
picture and all of that kind of stuff. And if they had the equipment on their
computer that would read them to it, jaws, it would read it to them and so forth.
Not a perfect solution, though. You still have to be able to see well enough to
make a signature on the oath. You still have to be able to fold that ballot up and
insert it into an envelope and then insert that envelope into another envelope and
send it back.
Audits and recounts. I think in terms of our work in that area, one of the things
I'm proud of is Washington state's rules on recounts, which is that if the apparent
winner and the apparent loser are less than 0.5% different, there's an automatic
state-funded -- or, you know, county funded, government-funded recount. And if
that difference is less than 0.25%, or a quarter of a percent, it is automatically
hand recounted. And those hand recounts are done in units, basic -- the precinct
units so that after the humans do their count, we can compare that with the
machine count, and very often we'll find that we pick up errors in that process like
a ballot from another precinct got into this batch of precinct ballots. Or they didn't
pick up that one of the ballots was an overvote so they counted it for one of the
candidates or they just flat out miscounted it.
So we can send it back, have another team count it, and try to make that process
as accurate as we can make it. It is -- human counting is not a very accurate
process, I can tell you, based on my experience with that.
The terms of the audits, we provide that a four percent audit on the DRE
equipment that's used. Means that four percent of the equipment that's used,
they have to pull the tape and count that against the results that they got.
Now, in our state again, the only use that it's used for is for disability access. In
many counties, nobody votes on it. Pierce County, because they have so many
polling places, still have so many polling places, probably has the highest
numbers of those currently.
And then we also provide what used to be parties could call for a count of three
percent -- I shouldn't say -- of three precincts at random that they picked. We
would hand recount and match that against the computer count. That's been
increased to six batches. And here's the reason why. The ballots come back -when we have polling places, the ballots come back grouped by precincts or
grouped by a polling place. It makes it easier to sort out the ballots.
But when they're coming in daily, they're coming in just as they come in the mail
and so you may have a batch, and that batch may contain 50 different precincts
from all over the county. So what we ->>: [inaudible].
>> Paul Miller: I'm sorry?
>>: With different ballot styles?
>> Paul Miller: With different ballot styles, yes.
>>: [inaudible] post office do the sorting so each precinct has a mailbox?
>> Paul Miller: Yeah. And there are -- some levels of sorting that are done. I
think right now, King County is sorting into ledge districts so that at least they're
grouped by ledge districts.
But actually, if I understand some of the theory behind audits, having a
distribution rather than having a concentrated precinct is a smaller groups of -that is more widely distributed is actually better auditing technique. And so the
auditing the batches -- and I can use some help here. You guys are a lot smarter
than me, but that's sort of my understanding of some of the theory behind
auditing.
So in conclusion, I would make this comment. That I would argue that what we
have found in our experience is that despite all of these issues that I've raised, is
that the process is remarkably accurate. And I would argue it based on our
experience with the hand, automatic hand recounts, where the difference is
0.25%.
That we have never seen an election outcome change. I'm not saying the results
don't change. The raw numbers don't change. But the election outcome change,
except when the original difference between the candidates was minisculely
small. And, of course, we had exactly the perfect illustration in this state in 2004
of that.
The original machine recount between Rossi and Gregoire was 50 votes, as I
recall, in favor of Rossi, and it wound up after the hand recount to be about 122
revotes in favor of Gregoire. Out of 2.9 million votes cast, that's something like a
46-ten thousandths of a point difference. So that in 99.9% of our contests, the
process is accurate enough to come up with the right candidate in the end.
But when you get into an election like that one, you have got -- you have entered
into where we have not been able to compress the margin of error small enough
yet. And that margin of error, as suggested in my opening, human error both on
the part of voters and election staff, design interfaces between the user and
either the paper ballot they're using or the DRE equipment that they're using, and
then finally, in some actually what my experience over 20 years is some pretty -is relatively rare machine failure type of issues. And usually, when the machine
error -- there's a machine error failure, it's identifiable and correctible before it's
certified.
So thank you very much for letting me have the time to talk with you.
[applause]
>>: We'll take a question or two, if -- I guess I'll start off by asking, is there
anything is that you think the research community can do that will make your life
easier or make it -- make the system work more trustworthy somehow?
>> Paul Miller: I'm not sure if this fits with the -- couple things I would respond to
you on that question. One is helping us understand better how we can get an
audit that is a good audit, but that it's also a doable audit.
And there's some push -- and you have to understand too that there is some
push-back from the elections community in part because we have these recounts
and they seem to suggest that our -- that the process is pretty accurate. And in
Washington, we have these recounts, we probably have two or three of these
mandatory hand counts every year, and half a dozen or more of the machine
recounts every year. So over the years, we've had a lot of testing, a lot of
opportunity to review.
The other, and I'm not sure that this fits into your area, but I've been pushing for
common data formats, and I actually have a paper that I can make available to
anybody who's interested that I presented to NIST last October. For the
elections community, what I think it means partially is this. What we have in the
marketplace right now is that if a county purchased vendor X's equipment in
order to do central count and they purchased that 15 years ago or 20 years ago,
that's their vendor. Now they've got to add DREs on to it, they've got to add poll
site counters on to it. Where are they going to go? Well, who can develop
market the equipment that's going to talk to their tabulation system that can get
the ballot layout from their ballot layout system and talk to their tabulation
system. It's going to be the vendor they purchased their equipment from 15
years ago.
So we're requiring these companies to get into areas that aren't their strengths
and we're tying companies down to products that the only reason that they
purchased it is because it was what they could afford based upon the vendor that
they've been using for the past 15, 20 years.
So if we can get in some kind of a common data format where the inputs into
devices is defined and the outputs from those devices is defined, think we can
create a better marketplace. And we have some specific issues coming up now
where we are trying to do more for our UIC HAVA voters where mail doesn't work
well. They don't -- when you are in Iraq or Afghanistan, it's hard to get the ballot
to you, and then it's hard to get the ballot back from you.
And so we're looking at ways of at least delivering the ballot electronically. But
we need some vendors to be able to work with the ballot layout systems so they
know what ballots to send so that the person can get the ballot printed out, mark
it up, send it back and we cut off at least one end of the transit time.
Common data format.
>>: Thanks. Thanks again, Paul.
[applause]
>>: In the interest of time, because I know Sanjit has to run, I'll skip the whole
explanation of why we're fortunate enough to have him here today. Long story.
Ask me later. But anyway, Sanjit is on the faculty of U.C. Berkeley and does
work in formal verification, models testing and has done some work on voting
machines and he's going to give us a brief summary of it now.
>> Sanjit Seshia: Thank you. Thank you for inviting me here. I'm scheduled to
give a talk next door at 11:00. So this is going to be a very truncated version of
that talk. 10 or 15 minutes. So I apologize in advance if it's too rushed or not
clear.
But this is basically on work that David Wagner and I and our students did, which
was published at CCS last year so the paper is on our website and I can send
the slide to anyone who is interested.
Okay. So as the title suggests, this is about formally verifying and testing a
voting machine. So I want to start with the disclaimer. This talk is mainly about
verification and not about, you know, not about all the issues dealing with
security. Verification is one issue, but it's not everything. For instance, we don't
talk about securing the voting machine against tampering, for instance. So
correctness, proving correctness of the voting machine design is necessary for
security, but I understand that it's not sufficient.
So also this work is I think a very small first step. What we wanted to do was
explore what we can do in the design stage to make verification and testing
easier. And so we designed a voting machine from scratch in hardware using
very [indiscernible] synthesizing into an FPG.
So what we tried to do was create a DRE. All of you are familiar with this so I'll
just go through it very quickly. So the setup for this talk is we want to verify the
correct operation of a single voter session. So a voter session is a sequence of
contests for president, Senator, et cetera. Each contest is a choice of picking L
out of K options.
And at the end, so you can navigate back and forth between these contests. But
at the end, you cast and that irrevocably casts your vote, your choices or all
contests.
So our contribution is that we show that you can combine formal verification with
manual testing by a panel of human voters to prove correctness of the voting
machine.
And in this context, we're interested in proving correctness not just of the code,
but also of the interface, of the human computer interface. And so we
implemented a simplified DRE in hardware and we used techniques, verification
techniques like model checking and satisfy ability, solving [indiscernible]
improving. And one of the things we do is we show you can use a small
polynomial number of tests by humans to augment the results of formal
verification.
So very briefly I'll talk about why we have this combinations of formal verification
and testing, I'll have a couple of toy examples, and then I'll just state the main
results and conclude.
So let's look at testing. If you want to prove a correctness of design by testing,
you need exhaustive testing but in many cases you can't even do exhaustive
testing because the test sequences have to be infinite. So as this quote by
Dikstra illustrates, testing is usually a way of finding bugs but not proving
correctness.
Formal verification, of course, can prove correctness, but it requires a formal
specification. You have to precisely define the requirements. So some
properties of the voting machine you can precisely design. Like if the reset signal
is set to one, then clears the selection state for all contests. But what about
voters' expectations? How do you formalize something like this, if the voter
presses what they think is the button next to the name Alice and then sees the
Alice highlighted, then the voter thinks that, okay, the machine has recorded my
vote for Alice, right? And so how do you actually -- you can't really formalize that.
And so that's the challenge. It's hard to use formal methods for something like
that.
So to summarize this very quickly, formal methods can prove the correctness of
the DRE, the code. But you can't formalize voters' expectations. On the other
hand, testing by humans, if you have a representative panel of human voters,
then you can argue that you've tested the interface, but then testing is not
sufficient to prove correctness. So that's why we try to use both.
So the approach is for precise properties that you can formally verify, we'll do just
that.
For voters' expectations, we'll use testing by a representative panel.
And this combination, as we show and prove in the paper, makes testing sound.
And from my viewpoint, as a person who does formal verification, the cool thing
was you can use formal verification to exponentially reduce the number of tests
you need. And I'll say a bit more about this at the end.
So what's the challenge for testing? I think the problem that, the reason why you
can't do exhaustive testing is that you require infinitely many input traces. Input
trace is a sequence of button presses that you would give to a human voter and
ask them to test out.
So here's an example, okay. So this is a sequence, each element of the
sequence is separated by commas. So the sequence means initially that you
have the empty set, which means that no candidate is selected. Then you have
Alice, which says that the voter selected Alice. Then again you have empty set,
which means the voter deselected Alice. Then the voter selects Bob, then goes
back to the empty set.
So what that means is that the voter's toggling between Alice and Bob. And the
voter can do this, in theory, infinitely many times, okay?
And so how do we know that there isn't some logic in the voting machine that,
after a thousand such toggles, will trigger some erroneous behavior, right? And
so that's why if you don't know anything else about the design of the voting
machine, you can't tell how long you have to test it.
So before I talk about how we use formal verification to address that problem, let
me tell you about what we mean by correctness. This is a notion that's come in
the formal verification community called trace equivalence. The idea is you have
at the bottom there, the implementation, that's the hardware FPGA based design
that we did. Then you have the model, the mental model that the human voter
has in mind.
And we want to show that the execution of the voting machine, the real
execution, which I'll show down here, will match of the execution in the voter's
mind. And so the approach is, let's say, initially the voting machine, the
implementation starts in contest number one, okay. So that's what that is,
contest number. And in contest number one, you have no candidate selected.
So then the voting machine display looks like this, where there are two options
and neither of them is highlighted, which shows that, you know, no candidates
are selected. And the human looks at that and says, okay, from this, I
understand -- from the screen, I understand that I'm in contest one and there are
no selections.
Then let's say the voter presses Alice, and then ideally the implementation must
record this, that in contest one Alice has been selected. The implementation
must output the display which highlights the button for Alice. And then the voter
look at that and gets feedback and says okay, now the machine is in contest one,
and my selection of Alice has been highlighted. Right.
And so here you have a trace of what's happening inside the machine, and up
there, you have a trace of what's happening in the voter's mind, and what we
want is those two should be equivalent. That's what trace equivalence is.
So to give you a toy example, let's see how an interaction like this might happen.
So let's say the voter look at the screen and sees that nothing is highlighted,
right. So inside the machine, you have the empty set, no selections made. And
that's what the voter understands. Then the voter presses button one, thinking
that they're voting for Alice. The machine should record in internally Alice, should
highlight that. And that's what the voter sees. And now the voter keeps track of
the fact that now according to the voter, the machine has record the vote for
Alice. And then you want to check that what the voter has in mind is, indeed,
what's inside the machine, right.
And so the approach we take to do that is for every unique screen, we have a
way -- we ensure that you can press cast from that screen. You get, let's say,
some record. Maybe on paper and then the voter compares what he or she has
in her mind to what's on paper and that's how they do this equality check down
there.
Okay. So now let me tell you how we use formal verification to make testing
easier. So the first thing that we proved formally on the code is that the machine,
voting machine transition function is a deterministic function of only those inputs
that it should be of.
For instance, the selection state is only a function of the current -- the selection
state at the previous Stein point, the button that was pressed, and the contest
number and nothing else. Right? And so that's what we mean by proving the
DRE's deterministic.
The second thing we prove is that the output should be unambiguous. That is,
each unique output screen represents a unique internal state. From just looking
at the output screen, the voter should be able to tell what the contest number is
and what the selection state is. And that corresponds to proving that the cord -the output function, that the cord that computes the output function is a one to
one function of the selection state and the contest number.
And finally, we need to verify that the cast vote record accurately records the
selection state at the very end. And so all of these things are properties that we
can prove on the code using a combination of model checking and satisfy ability
solving.
So now, given those properties that we prove, we have then come up with a set
of coverage metrics for tests. So we say that if you give a sequence of tests that
satisfy these coverage metrics, then we have a theorem that you then get trace
equivalence. So here are the three coverage metrics. The first is initial state
coverage, which means that the machine starts in valid state. The machine in
the initial contest, before any selections are made, if you press cast right there,
then you get back a record which shows that nothing was -- there were no
candidates selected in any contest.
The second has to do with transition coverage. So every contest is a state
machine. You know, you're in some state and then you press a button and you
go to the next state. And what we want to do is we want to cover all the
transitions for the state machine for every contest. Okay. So that's what these
two bullets are describing.
And then finally, we have something called output screen coverage, which
means that for every unique output screen, we check that the voter has an
opportunity to check that their view of the state of the voting machine for that
output screen is, indeed, what is recorded, right. So you see an output screen,
there's some internal selection [indiscernible] contest number. There is
something in the voter's mind and we want to match that up.
Okay. So now what I showed you first was just interaction of a voter with the
machine for one contest. But if you have even two contests, so say in contest
one, you're selecting between Alice and Bob, A and B. In contest two, you have
to select between eve and Mallory, E and M. Then you already have this
blow-up in the space of the number of options that there are, right.
So here, for instance, the voter selected Alice and then went to the next contest,
which is what that label means and in the select contest they selected eve and
went up there. So that's what that part means. But they could have select the
Bob and gone down here or they could have selected Mallory from that state. So
there's an exponential blow-up as the number of contests increases.
So if we were naive about testing, we would have to test every part through this
state machine.
So to solve that problem, what we do is again we use formal verification, but this
time, we prove that the logic for one contest cannot influence the outcome in
another contest. This is independence property.
And so if you can then prove independence of different contests, it's sufficient to
test each contest separately. So all you have to do is to test contest I, you just
navigate, press next, next, next, next, go to contest I, and then test the transitions
in contest I. And this is what I meant by talking about an exponential reduction
number of tests. Instead of having to test every part in the picture that you had in
the previous slide, now we only have to test the transitions within each contest.
Okay. So conceptually, this is what the DRE looks like. You have a state
machine for every contest. You have to cover the transitions within each box, but
not parts across the boxes.
So in the interest of time, I'll wind up. So there are six major properties that we
need to formally verify. And these are also in the paper. And given that, then we
have a theorem, which is also proven in the paper, which says that if the DRE
satisfies these six properties, then if we have a test suite that satisfies our
coverage criteria and if it passes, then it means the DRE is correct. And if the
DRE is correct, then the test will pass.
Okay. And so now, if you have an election with N contests and K choices in
each contest and you're picking one out of K in each contest, then our approach
requires K times N tests. Whereas otherwise you'd have to consider all possible
combinations, which would work out to be K to the N.
Okay. So there are lots of limitations and assumptions that we make. I think the
previous talk mentioned, you know, support for people with disabilities and this is
something, of course, that this does not handle at all. We assume that the
compile of use from vary log to silicon is trusted and so we make all these
assumptions. And so as I said before, it's a first step. But from the viewpoint of
verification, I think it's a very interesting exploration in the use of formal
verification and its combination with testing.
Okay. So I will stop here. Thank you very much.
>>: Questions?
>> Sanjit Seshia: Yes?
>>: Corresponds between what's displayed in candidate and the database?
>> Sanjit Seshia: Yes. So the correspondence that we check is that the display
is a one-to-one function of the contest number and the state of the selections that
have been made. And so --
>>: [inaudible].
>> Sanjit Seshia: So if you just, if you reorder them.
>>: [inaudible].
>> Sanjit Seshia: Yeah, so I should mention that this is -- so okay. So I think we
assume that, so there's some election definition file which specifies how the
candidate name should appear and the translation from that election definition
file to the screen is correct. Which I think is what you're alluding to. Right. And
so that ->>: [inaudible].
>> Sanjit Seshia: That is right. So I think we could attempt to apply formal
techniques to it, if that were an automatic translation. Yes?
>>: A standard question is, do all the work to formally verify the software. How
do I as a voter or election official know that that's the actual software that's
running on the DRE at the time the voting takes place?
>> Sanjit Seshia: That's one of the issues we don't handle in this work, like I
said, right. So you have to have some other mechanism of ensuring that what
you've verified has not been tampered with and it's running on election day. So,
you know, that's one of the things that we -- that should be done but we don't
address in our work. Thanks very much.
>>: Thank you. Thank you for your flexibility.
>> David Molnar: Pleasure to be here. So Josh asked me to talk about attacks
on voting systems, and so what I did is I went through the literature and I picked
out four attacks which I think are illustrative of different issues that come up with
today's voting systems. This is not an exhaustive list by any means, but I will
explain why I picked each of these in turn.
So the first attack I'm going to talk about dates all the way back to, Yoshi, your
original paper with Avi and Dan and everyone, and Adam. This is, of course, sort
of a critique of the software that was used in the original Diebold DRE. As we all
know, there are many, many problems with this software. The one I want to
mention today is the use of the encryption.
So this is a case where the developers knew they needed some kind of
checksum and some kind of confidentiality properties for vote records that were
on the DRE. Unfortunately, the cryptography they chose was poor. So they
started off using 56 bit DES which perhaps at the time they define the would be
defensible. But they defined an ASCii constant key that's constant for all
machines. For authentication, they said we know we need some kind of
authentication check so we'll use a 16 bit CRC. As the paper notes, Doug Jones
mentions some of these issues in the 1997 report, but they were still present in
2004.
Then for extra credit, there's a linear congruential generator with a comment in
the source code saying oh, yes, as per applied cryptography, 1996. So this was
a vulnerability where the designers had some notion of what they really needed
to do, and then they went to a textbook and completely misunderstood how to do
it.
The next thing I want to talk about is the Harry Hursti attack. This is different. It's
not a DRE. This is an optical scan system. As we heard about already today,
you have these scans, they go into a machine and out come some total. We'll
take a look at the total. If it looks right, we'll accept it. If it doesn't look like or it's
too close, maybe we'll hand count it.
The question in this attack is what is the initial state of the memory on the
machine. So if you have two yes votes and six no votes and you scan them all
and the machine starts off with initial state of yes zero and no zero, you should
get an outcome of yes of two and no of six.
What Hursti noticed in this attack, which was kind of interesting, is that you could
have negative votes on the original machine memory card. And then if you could
slip a memory card with this negative number into this stack of cards used to
initialize the machines, the initialization check that election officials did at that
time was simply to print out what's called a zero tape, which would then say
okay, let's sum up the yes and nos and make sure they sum to zero and print the
results.
If you add five votes to yes and subtract five votes to no, you get something that
sums to zero. And that, of course, completely changes the results.
The problem here, as you already talked about, was that even if you hand audit
this, unless you hand audit the original tape, you might say oh, well, it was just,
you know, the original memory contents, you might say, oh, well maybe it's just
human error or maybe it just got recounted wrong. You may or may not notice
that this is a problem in the machine.
Then the third attack is something that came up in the California top to bottom
review. So we're progressing through time here. The original attack I mentioned
is from 2004. The attack at Hursti discovered was in 2005. This is from 2007.
So this is a Sequoia [indiscernible] electronic with voter verified paper audit trail.
So you walk up to the machine and it turns out that this particular machine will
honor autorun.inf, which is a mechanism in windows for automatically installing
software. And it turns out a standard USB stick could be used to install arbitrary
software on the machine after the machine had been deployed.
So this gets to the question of how do I know the machine is running the software
that I verified in the lab?
Okay, but fine, it's got a verified voter paper audit trail. This shouldn't really hurt
us, except it turns out the procedures of this particular machine in the California
do hurt us in the following way.
The attack goes as follows. You're the voter. You walk up to the machine, you
cast your vote. The machine prints the receipt on the VV pad and you see it, you
say everything's fine and you leave. But then the machine prints voided as if you
had decided to void this vote and then go back and recast.
So there is fleeing voter procedure which gets triggered in this case, where it
looks like the voter went to the machine, entered his or her vote and then just left
the building. And the election official apparently, according to the report, is
allowed to come in and finalize the vote of the fleeing voter.
The malicious software can change this vote and because of the privacy concern
over the election official not being able to see the vote of the voter, there's no
way for the official to tell whether the VD pat that gets finally printed and
committed to the log is the thing the voter actually meant to put out.
So the problem here is even though we have an audit mechanism, the
mechanism interacts badly with a procedure that was put in place to protect voter
privacy and malicious software that can be introduced post hoc can take
advantage of this mismatch in order to create an audit trail that looks perfectly
reasonable but, in fact, is not what the voter intended.
And then the final attack, this is allegedly discovered by some election officials in
Kentucky, I say allegedly, because they're under indictment right now. And so
this description goes credit to Matt Blaze for photo and blog post describing this
attack.
This is a picture of an iVotronic machine. It has a big button at the top that says
vote. I would think, many people would think if you push that button, it casts your
ballot. So here you go, push the button. Actually, it goes to confirmation screen.
So you push the button and it doesn't actually cast. It says okay, are you sure
you want to cast? And you have to push another button on the terminal itself to
actually cast your vote.
>>: A yes button next to the vote button.
>> David Molnar: There apparently is a yes button next to the screen. Here is
the attack. Step zero, become an election judge. As we heard, people are dying
for election help. Step number one, tell people that when you push the big red
button, that's all you need to do, and you can leave. Pay no attention to the big
yes button that appears on the screen.
Many of them will believe you. Step two, sneak over to the voting machine after
they leave, see if they believed you. If they did believe you, you can just push
the back button and change the vote to the correct value. Step four is profit.
So these officials in Clay County, Kentucky, are alleged to have sold elections by
doing this. And what was interesting about the report so far is that they appeared
to have discovered this property as early as they got the first machines. And this
isn't a property that was missed by researchers who actually looked at this.
So if I had to boil these all down into sort of one sentence as to what went wrong
in each case. I would say in 2004, again, this is not the only problem with the
Diebold DRE by any means, but one of the problems was we had the textbook
crypto problem. You had people who knew they needed something, they went to
the textbook and they got it wrong.
In 2005, we had an insufficient initial state check that there's the procedures
people had at the time. They thought they were checking that the machine had a
clean initial state, that it didn't have any votes left over from previous contests in
its memory, but the check they used didn't take into account this devious ability to
put in negative numbers. And you could argue as well that the ability to have
negative votes is a bug, not a feature in a voting machine.
In 2007, the problem here is that the fleeing voter protocol interacts badly with
the ability to add software to the machine after it's tested and certified. And that
fleeing voter protocol ends up interacting badly with the audit trail.
Finally, in 2009, the fact that you have the bad user interface where the vote
button doesn't do what you think it does, combined with the fact that people
training voters are corrupt, leads to this attack.
So the thing that I found when looking at these attacks and other attacks like
them is what are the commonalities. Ideally, we'll see commonalities between
vulnerabilities that would allow us to target the kind of proposals that we all love
and say look, here's a class of attacks we can get rid of.
For instance, we want to have vulnerabilities that fall into the category of software
security because then we can say if we don't have to trust our software, we don't
have to worry about those. Well, these are not all software security problems.
We might say okay maybe the problem is direct recording electronic. If we went
to something where we had recounts or we had an audit trail, we would be able
to get rid of many of our problems. They're not all direct recording electronic
problems.
While human error is a big deal in all these cases, especially the last one, they
aren't all human error problems, because the first issue of cryptography is
something no human could ever determine just by looking at the machine.
Finally, they weren't all discovered by trained researchers. The iVotronic attack
was discovered by election officials who immediately decided to use it for
personal gain. And Matt blaze points out in his blog entry this is something that
had been looked at, a system that had been looked at by trained professional
security researchers and then totally missed this particular problem.
So the question I have, and I would like to sort of pose to everyone here, since
we're going to be talking about new ideas for voting systems, what do
vulnerabilities like this have in common? They don't have to have everything in
common. There's no silver bullet. But when we're proposing new systems, what
are some of the key things that we need to think about when evaluating or
designing new systems?
So with that in mind, I thought I might spend the last little bit of time sort of asking
people if they had thoughts on this, and then we could, you know, put that into
the slides for use later.
>>: [inaudible].
>> David Molnar: Sorry?
>>: Are you also like Sanjit giving another talk?
>> David Molnar: No, I'm not. This is like more of a record thing. So Ben, I'll
pick on you first. What do you think?
>>: Fair enough, fair enough. I think the first thing it means, that this is a
particularly hard problem.
>> David Molnar: Okay.
>>: Kind of an easy one, but human is one we forget. I think that verifying
elections, verifying -- auditing an election in the face of voter privacy
requirements is particularly hard.
>> David Molnar: Yes.
>>: I actually do have a comment. I mean, it's mostly made by your last one.
This is, for somebody like me, you know, who is a very technical person who
looks at these things, I look, my immediate reaction is to dismiss this as human
engineering, right, you know.
But, you know, let's see, I don't want to sound quite so cynical. I think it's
important and I think it needs to be solved. Here's what's missing is nobody yet,
to my knowledge, has ever put down a firm model of what constitutes a fully
operable human being, right? And until you do that we never are going to know
how to solve this problem. The thing is, that issue has been a matter of shifting
sand for as long as I know. And, you know, I mean, I think that intuitively, we all
agree that there is a human being who eventually devolves close enough to
incapable that we are going to have to accept that we cannot deal with those
people, right.
And I don't want to say that we should set that bar really high, but somewhere,
somehow, people are going to have to say those people cannot be expected in
all cases to interact what we would intuit to be correct and just accept it. And say
okay, but our system is good enough to meet 99.99% of the population's
capabilities. When you get there, then you can say maybe you've dealt with the
human engineering problem.
>>: I believe [indiscernible] regular cycle of testing on user, selectively naive
users, known as virgins. Don't know why you have to get new ones, for obvious
reasons.
>>: That's good, and that's important. But my point is that elections are so
political and you run into these problems of people all of a sudden pointing
fingers after the fact, you're never going to have a situation where you feel you've
solved the problem until you decide what is, what is the minimum bar for naivete,
right? I mean, you can't simply say, well, I've designed the system here. Then
go get a stupider voter, you know, who isn't able to interact with the system.
>> David Molnar: Adam has something he wants to say. Adam.
>>: I'd like to object a little bit to your assertion that the voters are stupid.
>>: I tried my best to make it a short cut. They're not stupid.
>>: These systems are complex, and I think part of the problem is the lack of
consistency between what we ask people to do.
>>: Look, I don't think you heard what I said. I agree, and I'm not saying that all
voters are stupid. I'm not trying to characterize people at all. That's not the
point. But the point is that there is some minimum level of capability that we are
going to agree that we're going to address, okay? Beyond that, you can't hope
to, right?
I mean, no, I'm not asking that these systems be designed for computer science
Ph.D.s. That's not the point, right. And they should be designed for as broad a
spectrum of society as we possibly can, okay. Absolutely. And if you can define
that and put boundaries around that broad spectrum of society and show that a
system doesn't meet the requirements of that broad spectrum of society, then I
will say that system has failed, that's fine, okay. But put some boundaries around
what that spectrum is. My dog is very smart. Does it have to meet his
requirements, right? That's my point.
>>: David Molnar: Any other comments or things people want to put up here for
later?
>>: I'm going to throw out something ambitious. I guess I have a sense of this
sort of ad hoc approach that we've taken in the past doesn't -- hasn't proved to
work particularly well, and maybe we need new paradigms. That sort of the
self-serving entry for verifiable paradigms as a completely different approach that
can solve a lot of these problems.
>> David Molnar: Any other comments. This is something I hope we'll be able to
use later on, which is why I put it up here. Yes, Ron?
>>: I don't think we find the search for commonalities. These are very
complicated, many different aspects and dimensions. [inaudible]. Part of human
protocol approaches [inaudible]. Try to take very different things, find
commonalities.
>> David Molnar: Okay. Great. Thank you. All right. Well thank you very
much, guys.