Usable Security

Just recently, the state of Wisconsin enacted a law that requires source code for voting machine software to be handed over to be held in escrow by the elections board.  Parties that successfully petition for a recount after an election can designate people to examine the source code, as long as they sign a confidentiality agreement.

This is a step in the right direction, but the bill should have gone further and made the source code available to the public for inspection.  In fact, the original version of the bill says exactly that:

5.84 (3) If a municipality uses an electronic voting system for voting at any election, the municipal clerk shall provide to any person, upon request, at the expense of the municipality, the coding for the software that the municipality uses to operate the system and to tally the votes cast.

If that had passed, it would truly have been one of the best things ever to happen in electronic voting, and a few excited announcements based on the above interpretation have appeared on blogs and news sites.  Unfortunately, the bill was amended to read:

(4) If a valid petition for a recount is filed under s.  9.01 in an election at which an electronic voting system was used to record and tally the votes cast, each party to the recount may designate one or more persons who are authorized to receive access to the software components that were used to record and tally the votes in the election.  The board shall grant access to the software components to each designated person if, before receiving access, the person enters into a written agreement with the board that obligates the person to exercise the highest degree of reasonable care to maintain the confidentially of all proprietary information to which the person is provided access, unless otherwise permitted in a contract entered into under sub.  (5).

(5) A county or municipality may contract with the vendor of an electronic voting system to permit a greater degree of access to software components used with the system than is required under sub.  (4).

You can read the entire history of Assembly Bill 627 at the Wisconsin legislature website.

In many ways, the requirement for publicly inspectable source code should be obvious when we’re talking about running a democracy that depends on these machines.  We can’t have confidence that votes will be counted correctly without examining and understanding how the machines work — and how they work is largely defined by the software they run.  Moreover, transparency is necessary for establishing public confidence in the integrity of the results, which is just as important as the actual correctness of the results themselves.  It’s not enough for the voting machine manufacturers to say their machines work correctly; and even to be honest and right when they say so — the nation’s citizens must believe this to be so in order for democracy to work.

Election turnouts have been low and declining in the United States for some time, which reflects a low and decreasing sense of personal empowerment in the political functioning of the country.  And with the introduction of electronic voting machines, public confidence in elections has been reduced even further by widespread reports of machine malfunctions, software bugs, irresponsible development practices, and the questionable political or criminal backgrounds of voting machine company directors and employees.  The United States is not facing an impending crisis of confidence in its fundamental mechanisms of democracy; it is smack in the middle of one.

On the other side of the transparency issue are the companies who have to sustain a profitable business making and selling these machines.  They don’t want their source code to be released to the public.  To succeed they have to compete — and how can a company maintain a competitive advantage if their competitors can just take and use their source code?  Security folks (and anyone concerned with the integrity of elections) want the source code to be publicly inspectable; voting machine vendors want the source code to be secret.  Their incentives are logical and diametrically opposed.

There is a reasonable compromise that can help resolve this problem.

What is needed is a separation of concerns.  Suppose that, instead of each machine running on its company’s own unique mishmash of purchased and custom-written proprietary software, all of them implement a common virtual machine specification.  Ballot programs would then run on top of the virtual machine (henceforth, VM stands for “virtual machine”, not “voting machine”).  This would be similar to Java’s model: the VM abstracts away the differences among hardware platforms, and takes care of low-level details so you can write Java programs at a higher level.  It makes guarantees for you so that certain kinds of errors can be avoided.

In the voting machine case, the VM would ensure some of the necessary security properties: that each voter can only vote once, that the voter’s privacy is protected, that the votes cannot be tampered with.  To some extent, the VM could even prevent programs that run on it from biasing the results.  For example, suppose that the Evil Party wants to write a program, to run on this VM, that will secretly switch votes over to the Evil Party.  But the VM only accepts instructions of the form “display candidate 5” or “count a vote for candidate 3”.  If the VM randomizes the numbering of the candidates each time, the program has no way to know which candidate corresponds to which number, so the program will have a hard time trying to bias the vote in favour of any particular candidate.

Suppose further that the law requires the source code for the VM to be made public.

Now, the people who prioritize security and transparency would be free to inspect the VM to make sure that it really enforces the level of fairness and security we need.  A community of concerned citizens, election officials, programmers, and security experts could work together to develop and evolve the specification and implementation of the VM in an open process.

At the same time, the companies that make voting machines would be free to continue competing on the physical design of their machines and the design of the ballots and ballot programs that will run on top of this VM.  In fact, the market could benefit from even greater competition, since there might spring up new companies that just write software for the VM and companies that just build hardware to implement the VM.  The software companies could write programs that run on a variety of different voting machines instead of just one, and the hardware companies could build machines that run a software made by a variety of companies instead of just one.

The standardization of a VM for voting machines would be a move towards the best of both worlds: better security and transparency where it matters most, and market competition that continues to propel the development of better voting machine designs.  It’s a big change, of course, and all changes require some effort and compromise on all sides.  I think it’s a good idea.

This entry was posted on Saturday, January 7, 2006 at 03:51 under General. You can leave a comment here or trackback from your own site. Use the comment feed to follow comments on this entry.