Dear fellow practitioners,

after following the "eVote Security Wars" for several years now I feel that we have little progress to show. After years of bitter fighting between academia, activists and eVote machine vendors constructive debate is still far off, the fronts have hardened and conflicts are fought out in court. The commercial viability of selling eVote machines is being reduced steadily by ever more restrictive certification requirements, and the increasingly difficult market is forcing a massive wave of consolidation of vendors.

Instead of having academics and activists fighting a global jihad against an oligopoly of vendors in the courts, why not divide responsibilities? Why not let vendors build feature-rich products, and let the academic security community take care of securing them? This paper is a practical proposal, including an "old" modular system architecture, that could foster the kind of dialog that has been near-absent in recent years.

Looking forward to your comments!

PETER WOLF
----------
Thanks again for sharing this paper Ingo!

At first glance I agree that FROGs offer a solution for several issues with current voting machines. But when taking a closer look, I believe some problems will not go away that easily:

* Even though some complexities can be moved to the vote-entry module, the vote-casting module will still remain quite 'fat': it still needs a user interface to display the votes with at least an accept/reject function, multi-language and accessibility features, a counting module, a tally display, printing or transmission function, possibly a sealing/encryption function for the FROG and votes. They also need to be physically robust as voters still interact with the casting module directly. So not really a simple machine any more.
* I sense there could be a problem with a human and machine readable format, especially if the vote-casting module has no information about the election and therefore cannot distinguish between valid and invalid votes: What may look like valid to a human reader may still be invalid in the machine count or final tabulation, e.g. when there are small spelling variants, smudges or other variations on the FROG.
* If a paper FROG is used, many practical issues of ballot scanners will probably still occur: mechanical components that fail, paper jams, poll workers that feel they need to help voters handling the scanner - and infringe voter privacy in the process.
* One general problem of voter verifiable audit trails - voters not checking their receipt - will also remain unchanged.

 
INGO BOLTZ
----------
Thanks for these comments, Peter.

I do actually disagree with the statement that the casting module would still need functionality similar in type to the vote generator module. It doesn't, which is precisely the beauty of the approach.

From a security perspective, anything a (voting)machine displays to you can never be fully trusted. Display is managed by software, software can be manipulated to show one thing and do another. So "verifying" a vote through a display and an "accept/reject" button is not true verification. To be 100% secure, you have to take the machine out of the equation.

Manual voter verification does that. The voter reads clear text information on a printed piece of paper. There is no way I can manipulate the reader to see something else than what is on the paper. In the FROG architecture, that verification step is what secures all the vote generator module did.

The casting module, however, can never be secured by manual voter verification, because its function is precisely to transform a human-readable FROG into a machine readable vote record. To get the benefits of machine counting (speed, elimination of human error in counting) we must sacrifice direct human observation of what happens in the machine. We can't directly observe the electrons inside, we must rely on proxy methods to assure ourselves that the machine does what its programmers say it does. One key proxy method is auditing the source code to make sure it contains no malignant code, "lock it down" so that it cannot be altered after the audit and we ensure the audited code, and only the audited code, is actually on the casting module on election day.

Displays and accept/reject buttons on the casting module would be "feel-good measures", giving the voter the illusion of "security-by-observation-and-confirmation" but in reality, any such displays can be manipulated and adding them makes the casting module less secure, because they increase the amount of source code that the auditors need to look at, and therefore increase the probability that they may overlook malignant code. Less code = more security.

So, in a consequently implemented casting module there are no displays and accept/reject buttons. The casting module reads the FROG and adds the votes. No voter confirmation; the only interaction the voter has with the casting module is inserting the FROG. Security comes from auditing and locking down the casting module's software itself.

As in any computerized voting system, the voter needs the help of a "trusted computer expert" to assure that the system does not "cheat" (if we don't accept that, we can't have electronic voting). The difference is what chances that expert has to succeed in guaranteeing that the system doesn't "cheat".

When auditing a monolithic (non-FROG) systems, huge amounts of source code generated by a non-trusted party (vendor) must be reviewed by independent auditors. Finding tiny bits of (potentially camouflaged) malignant code in hundreds of thousands of lines of source code is very, very difficult, and often vendors make it harder by trying to limit access to the source code. Voters cannot place all that much trust in the effectiveness if these audits because the chance that auditors will find irregularities are slim.

In contrast, auditing the source code of a FROG casting module means reviewing only a few thousand lines, so there is much less chance of overlooking errors or irregularities. Moreover, this source code would have been created by a public foundation that (in contrast to a commercial vendor) has no commercial interest in hiding errors, and since it is published as open source, full access for any auditor to chose any method of auditing is guaranteed. The more open the software, the more people review it, the more errors get found and fixed, the more "successful" the foundation will be. The combination of these two factors, motivation and capacity to find and eliminate errors, will make the casting module more robust and secure.

Voter errors / invalid votes:

As for for over- and undervoting etc: Since the vote generator module will not allow invalid ballots to be printed, the casting module does not need to check for that. Spelling variants (e.g. write-in candidates) will pretty much be "trash-in trash-out" but that will always be the case in any system and they need to be manually reviewed during counting.

Of course, the ballot must be generated "clean enough" to not introduce errors during that process, e.g. smudgy printing that the casting module can't read. But the casting module does not need a user interface to warn voters against wrongly filled-in ballots; the generator module already took care of that.

The precision and robustness of the physical generation of the FROG is a key challenge of the proposed system; then again, the same holds true of any other non DRE, voter verified system. Likewise, robustness against jams during introduction and reading of the FROG is important; just as with current precinct scanning systems. See below.

Accessibility:

That is a valid objection. Take the blind, for example. If you are consequent with the "voter verifies FROG independently" principle, then you'd have to include braille onto the frog and into the casting module (since computer-generated audio is not really independent of the system). This has both cost and security implications.

Having the generator module generate braille on the FROG would complicate its generation and format for millions of voters to serve a small minority. But from the generator module's side this is simply a question of whether you want to spend the money on minorities being able to vote independently in precinct, but its not a question of security. The software to handle the braille is "before" the voter verification and hence is not very security sensitive.

However, having to incorporate a capacity to read braille into the casting module (because the casting module must read the same thing the voter "saw") would significantly increase the amount of source code of that module, making auditing and securing it more difficult. Its a trade-off.

Perhaps a separate system for the blind and severely handicapped is a better option.

Tallying/counting:

True. If we aim for precinct counting, that will be needed. But the source code needed for adding up a few tables should not be terribly complex and easy to audit, no?

Printing/transmission:

True. Needed.

Encryption:

The FROG itself must not be encrypted, or the voter will not be able to read it without help. Whether the vote records created from the FROGs by the casting module and stored electronically need to be encrypted depends perhaps on the process used. If we count in precinct under observer vigilance, print out and distribute copies of precinct totals, then communicate them via other channels for final (e.g. national) tally, we may do without encryption. If we transmit the records directly from the casting module electronically, we will need encryption. Again, depends on the process. Encryption source code does add complexity to the casting module and makes it harder to audit, but assuming we integrate standard and published algorithms having errors or malignant code in such libraries is less probable and easier verified.

Physical Robustness:

Absolutely, any machine "handled" by the voter must be physically robust. The foundation designing the casting module would have to spend solid effort on things like FROG feeder/reading mechanism, jam-resistance, speed, etc. Good industrial design is not easy and the computer scientists and security experts who will make up the bulk of the foundation should probably seek help with that from industrial designers, as well as having a rigorous user testing system in place.

Voters skipping verification:

True. If voters do skip the step of verifying their FROG, they essentially waive their rights to a secure system. On the one hand, I believe we can expect a certain degree of cooperation of the voters. Its THEIR election, too. Without their participation, a secure system will never be possible.

On the other hand, even if only a small percentage of voters do verify their FROG (say 20% to be very pessimistic; I think ACCURATE's Joe Hall's numbers were higher than that for VVPT verification in the US) -- a 20% sample is still very large and statistically relevant. Most post-election manual recount samples are much smaller than that. Systematic system malfunction should be discovered even with low verification rates.

So much my 2c. :)

Lets keep talking!

PETER WOLF
----------
Some of my remarks refer to the initial CALTEC/MIT FROG which was electronic rather than paper based. I agree there is no need to deal with things like encryption or sealing for a paper FROG.

 

So let's say the new FROG concept we are discussing here is exclusively based on directly human readable, probably paper based media. In this case, you rightly write "The true engineering challenge thus lies in designing [...] a FROG that is easily human readable yet suited to be read automatically with a very low error rate by the casting module.".

This is where my issue with the human and computer readable format comes in. I'd think it is very hard to find a format that is equally well readable for both. So if the vote generator is not tightly secured, it could potentially - by mistake or on purpose - produce a FROG with small variations (spelling, smudges, marks, ...) that still looks OK to the human eye, but is invalid or wrongly interpreted by the vote casting module. And if the vote casting module provides no feedback about how it interprets what it reads, nobody would detect that, except by a manual recount similar to PCOS or VVPAT recounts.

As far as complexity is concerned, I would expect a ballot reader for paper FROGs to be more complicated than a PCOS system for technically relatively simple OMR ballots.

Having said that, I still find the concept very interesting. And if something is a true engineering challenge that certainly does not mean it's impossible. Maybe triggering a mandatory manual recount/investigation in case of a high rate of invalid ballots can be part of a solution.

INGO BOLTZ
----------
I think even COTS printer technology (think simple laser printers) are today at a level of precision that should make it possible to avoid smudges during printing. I mean, we are not accepting if our office printer produces anything less than crisp, sharp documents, so why would we not have the same quality standard from a generator module's printer?

As for mark recognition vs character recognition (OMR vs OCR): I believe that OCR actually has a lower error rate than OMR, especially when using a simple form of ICR (Intelligent Character Recognition) in which the candidate/party name produced by the OCR is compared with the finite possibilities from the actual ballot.

But using OCR has another big advantage over OMR for the FROG: We would want the FROG to be simple and concise, so we would want it to contain only the names candidates and parties selected by the voter. With OCR, such a simple list is possible. After all, the FROG does not need to look like a ballot; the actual ballot with all the candidate/party options lives electronically on the generator module. The printout can be reduced to just a short list of the CHOSEN options.
If we want the casting module to use OMR, the FROG must look more like a regular ballot, including all the options the voter did not choose, and printing marks next to the ones the voter selected. That way, the FROG becomes needlessly large, maybe stretching over several pages, with the scanning problems that may bring.
 
No, better use a simple list of chosen candidates and parties, in a OCR friendly, big Latin font (also good for people with myopia) and keep it to just one page. Easier to handle, easier to scan, easier to store, and with COTS OCR precision.

As for spelling errors: They would either have no come from an already faultily programmed ballot, or from a write-in candidate. Ballots would most likely be reviewed for such errors before shipping the machines to the field, so such errors would be caught. If not, they affect all machines with that candidate the same way, so voter intent will still be clear. As for write-in candidates, the generator module would have the voter type them in, they would be printed on the Frog in an OCR-friendly font, and the casting module's OCR would interpret them.

If a write-in candidate is spelled wrongly by the voter, well, they have to be manually reviewed anyway, and to a human it will be clear that "Mark Mayers" is probably the same as "Marc Meyers". Just as in standard paper elections.

Considering that the casting module need no UI at all, and OCR/ICR algorithms are available COTS and need not be much more complex than OMR algorithms, the casting module should be simpler than a standard OMR scanner. And since we can avoid multi-page ballot scanning scenarios, as well as the smudgy/wrongly placed/wrongly filled in OMR "bubbles" both simpler and more precise.

PETER WOLF
----------
So we are slowly narrowing in on how a real FROG could look like. I still kept things like a 2D barcode shaped as a party logo as a possibility till now. But let's go for a more reasonable option and say its printed text and OCR.

My main concern is still the combination of an untrusted generator module and a trusted casting module that does not provide feedback and possibly is not even configured for a specific election.

If I can control the generator and want to steal votes for candidate 'INGO' and print that name as a CAPTCHA I will probably be caught. But I could print FROGs containing more subtle variations like 'lNG0', 'I N G O', 'I.NG.O.' (replace dots with artificial smudges), slightly overlap a few characters, reduce the contrast, distort, scale, change font of the printout. On a more complex ballot I could even switch candidates between contests or manipulate contest codes in a similar way. Most of these FROGs will still look good for a human reader, but how will the casting module interpret them? Some votes like that will surely be invalid, but as the casting module provides no feedback nobody will ever know.

The problem with barcodes on FROGs is that they are not human verifiable. NEDAP in the Netherlands has developed a new voting computer which is modular and gets close to being froggy (see http://www.election-systems.eu/) but (and that is a BIG "but") while the voter choice is printed in clear text on a paper FROG, it is ALSO printed in a 2D barcode, and the casting module does read THAT BARCODE, not the clear text. So the casting module reads the thing the voter COULD NOT VERIFY and ignores the thing the voter DID verify - the clear text. This "little oversight" destroys the security strong point of the FROG architecture.

When I talked to NEDAPs people they were astonished at my remark and claimed they could not follow the argument. And that from a vendor who has been in the eVote market for over 30 years...

---------------

Regarding the danger of taking over the untrusted generator module:

Assuming the most likely case that the FROG only contains candidate names or parties that I voted for, in clear text. What would the attack scenarios look like if I can secretly take over the generator module:

Attack A: Voter selects "Candidate SMITH" on screen, but the system prints "Candidate JONES" instead on the paper Frog.

--This is so obvious that any voter who cares to verify the ballot would actually notice it and complain. The FROG would not be inserted into the casting module, the voter gets to try again. If the machine does the same thing again, the machine gets locked away for forensic audit post election, and we either replace it, or move to paper ballots.

Only on a very long ballot, where a lazy voter only verifies the main contests and skips the minor ones that he/she doesn't care much about, could this realistically be overlooked by a large enough number of people to have an impact on the election outcome, and even then it is likely to BE NOTICED by a large enough number of voters to cause an investigation into the machines. Low impact on election outcome, high risk to be caught = not a probable attack.

Attack B (the smudge attack):

--This would be an attack trying to exploit OCR weaknesses. I suspect that voters would complain about "smudgy" printed FROGS, and most likely the poll workers would try to replace the printer, suspecting "low toner" or whatever. After all, everybody has dealt with that in their office work.
 
But lets assume the variations are subtle enough to look "ok" to the voters and poll workers, yet bad enough to throw off the OCR of the scanner. Say the OCR reads ING9 instead of INGO. It would compare that outcome to the candidate list that it has stored, and would not find it there. It would not automatically be discarded as invalid, but rather stored it in a separate table called "ambiguous" (similar to the table that contains the names of write-in candidates, which are also not on the ballot and hence the casting module will not find them when comparing the OCR result to the candidate list).

When printing the final results, the casting module would produce a report with all the ambiguous readings it got. Poll workers would review that list, and try to determine voter intent, manually adding clear cases to the tally. It would be obvious to poll workers that ING9 is meant to be INGO so these votes would not be lost even if the OCR fiddles. If there are hundreds of ambiguous readings, the machine is investigated. It is unlikely that a large number of cases occur in which the FROG looked "just fine" to the voter yet the OCR reads something completely different that can't be attributed to an existing candidate.

An attack of this sort would be essentially a "hassle attack" aiming to disrupt the elections (similar to DDOS attacks on Internet voting) but I can't really see how it could be used to steal votes. Candidate names would have to be extremely similar for an OCR error to "switch" a vote from one registered candidate to another. Like "Robert Jones" running against "Robert James" for president. How likely is that? And even in the case, the swap would be random depending on the smudges, and not predictable. So, not a likely attack in my opinion either.

It seems to me that by chosing an OCR based system, we are not achieving one of the main goals of the FROG concept: a ballot casting module that can be better secured because it is simpler than existing voting machines.

The system we are discussing by now has all elements of OMR based PCOS machines. Maybe we can save the user interface, but that does not simplify much as PCOS systems often do not use it for more than saying 'Thanks for your vote'. Additionally we now need a component for analyzing and adjudicating invalid ballots, because OCR has more possibilities for ambiguous ballots.

So now I see two options for continuing our discussion: we can compare PCOS with the OMR FROG system or, maybe better, we can look for alternative FROGs.

One thought: maybe there is an added value in something like the NEDAP 2D barcode + text solution? One could build an idependent, simple device for random audits: a scanner that shows what is encoded by the barcode (to allow an auditor comparing barcode and text) and that, after scanning all paper receipts, prints a count for comparison with the official results.