Smyth & Cortier defense and customizability feature

As a solution to Smyth and Cortier’s attack to reveal votes, we propose an overkill measure of hiding the encrypted ballots and disabling the ballot verification feature. While disabling the attack, this is an egregious compromise to Helios’ key open-audit verification feature. However, in the process of experimenting with the degree of overkill, we found interesting implications in the confidentiality and integrity of Helios. This led us to develop a new customizability feature to Helios.

Smyth & Cortier defense

To completely remove Helios’ open-audit feature is not only difficult, as it requires large changes to the code, but also unnecessary for our demonstration purposes. To disable the Smyth and Cortier attack, it suffices to hide the encrypted ballots from the public.

A voter's encrypted ballot is shown in the vote’s cast-vote page. An example is shown in the image below. When the ‘details’ link is clicked, the encrypted ballot is revealed.

The cast-vote page can be accessed in two ways. One is in the Voters and Ballot Tracking Center page (in the image below), which can be accessed from the election. The Ballot Tracking Center (BTC) contains a table of all voters’ name or alias, their Smart Ballot Tracker, which is a “fingerprint” of the encrypted ballot, and their encrypted ballot, which can be accessed through the ‘view’ link. The other way to access the cast-vote page is through a link sent to the voter’s emails after a vote is casted.

To completely hide encrypted ballots, we can simply disable the ‘details’ link in the cast-vote page. This can be done by commenting out line 16 in helios/templates/castvote.html. We do not need to make changes to the BTC, although the Smart Ballot Trackers are now redundant. This is our baseline defense to the attack.

We further derived a few extension defenses. Recall the two different ways to access the cast-vote page, one through the BTC and one through voters’ emails. The BTC is available to the public while voters’ emails are private. This naturally leads to a convenient separation between the public and voters’ themselves. That is, we can disable the public’s access to the cast-voter page while maintaining the voters’ access. The result of this is that only voters themselves can access their own encrypted ballot. In turn, Helios’ verifiability feature is not completely removed, but restricted to voters only. This is our first extension defense. It negates the Smyth and Cortier attack as encrypted ballots can not be accessed without coercing a target voter or hacking their email.

The implementation is to remove the link to the cast-vote page in the BTC along with the Smart Ballot Tracker fingerprint, since the fingerprint can be used to derive the cast-vote page html address. This can be done by editing line 154 in helios/templates/voters_list.html. An implementation is shown in fig. 3

The second extension defense is to hide encrypted ballots but only when the election is open. This defense also preserves Helios’ open-audit feature to some extent: anyone can verify any votes, but only after the election is closed. The practicality of this defense is less apparent compared to the previous extension defense. While the Smyth and Cortier attack is impossible during the election, verifiability of the election after it closes may be less helpful to the integrity of the election. Implementation of this defense can be done by using the election.voting_has_stoppped boolean in Helios’ django model.

Implications

We quickly found some patterns. The baseline method to completely hide encrypted ballots was the “most overkill” measure, while the two extension defenses preserved encrypted ballots in different ways. The second extension defense was straightforward in that it added a dimension of time to the defense. But the first extension defense of restricting verifiability to voters was far more interesting. In fact, it ties directly to two properties of electronic voting systems introduced by Smyth and Cortier:

Individual verifiability: A voter can check that her own ballot is published on the election’s bulletin board.

Universal verifiability: Anyone can check that all the votes in the election outcome correspond to ballots published on the election’s bulletin board.

Helios’ open-audit feature corresponds exactly to universal verifiability, although in their research they used the term “true verifiability”. Our first extension defense happens to satisfy the criteria of individual verifiability. Along with the baseline defense, Helios’ open-audit feature and our measure of restricting verifiability to voters form a scale of verifiability where the varying factor is “who can audit which votes”. A visualization is shown below.

However, the varying factors on this scale are not just verifiability. Our baseline defense disables the verifiability feature, but also completely hides encrypted ballots, in turn guaranteeing full ballot secrecy. So, in the opposing direction of verifiability is ballot secrecy. Indeed, the two are in conflict, which is even acknowledged by the Helios contributors : “In cryptographic voting protocols, there is an inevitable compromise: unconditional integrity, or unconditional privacy” (Adida, 2008, p.336). In this case integrity corresponds to verifiability and privacy to ballot secrecy. Helios’ approach is to guarantee unconditional integrity by ensuring full transparency of the election and tallying process, since anyone can verify any vote. On the other hand, our baseline defense, by not revealing any encrypted ballots, would provide unconditional privacy, or--using the terms of our threat model--confidentiality. Thus, we can construct an updated scale, as shown below.

Currently there are only three discrete values on our scale, but more options are possible. For example, between universal verifiability and individual verifiability, there may be a midpoint feature of allowing voters to verify any votes.

Customizability feature

Since we already have all three values on our scale readily implemented, we went a step further to combine them to a customizability feature such that when creating an election, the administrator can choose a point on the scale. That is, one can decide whether their election has universal verifiability, individual verifiability, or no verifiability; our scale of verifiability and ballot secrecy is thus one parameter of the customizability feature. We added another parameter of before and after the election closes, taken from our second extension defense. Thus, our customizability feature is shown in (1a) with parameters underlined. As a comparison, (1b) summarizes Helios’ open-audit feature.

(1a)

• Before the election closes, anyone can audit votes belonging to [ANYONE/THEMSELVES/NOONE].
• After the election closes, anyone can audit votes belonging to [ANYONE/THEMSELVES/NOONE].

(1b) Anyone can verify any voters’ votes at any time.

Since the baseline and extension defenses were already implemented, the remaining work was to convert the defenses into parameters in a Helios’ election. To do this we added two fields to Helios’ Django form and Django model; details about the modifications are on our github. The updated create-election form is shown below.

It is worth noting that we initially considered two versions of the customizability feature. The first is the one described before, granting users full customizability of the parameters. The other one being to offer to users only a few combinations of the parameters. The reasoning is that some combinations are less meaningful than others, such as allowing anyone to audit before the election closes but allowing no one to audit after the election closes. We ultimately decided on the full customizability version for two reasons. The first being our trust to the user: people that create elections are likely to be familiar with concepts like verifiability and ballot secrecy, so we trust that they will not make meaningless or silly decisions. The second is that, even if users are not familiar with election security, full customizability exposes the user to potentially too much information and forces them to modify all the parameters; then, the user is more likely to learn the advantages and disadvantages of each option and familiarize themselves with integrity and privacy.

Future work

Our initial planning of the customizability feature had an additional parameter that differentiated between admin and non-admin permissions. However, we encountered problems when implementing this parameter. The Helios Django parameter field that checks whether the user is an administrator is admin_p. Admin_p functions correctly in templates/voters_list.html but not in templates/castvote.html. We do not know the reason behind this so we have not been able to implement this feature, although it still appears in the create-election form as disabled features.

A conceptual point of future work is expanding the scale of verifiability and ballot secrecy. Currently we have three points on the scale, universal verifiability, individual verifiability, and no verifiability. Additional points can easily be conceptualized and implemented. For example, the administrator can restrict audit permission to a specific group of people. This might be useful in school or corporate elections.

Accessibility Improvements

For any voting system to be considered fair and functional, it must be usable by every member of the voting body. In many elections, this could mean any individual of a responsible age, including those who are elderly, disabled, uneducated or unfamiliar with the technology being employed. In most cases, voters should be able to perform this function without requiring training or prolonged instruction, so systems should be self-explanatory and easy to understand.

While EVMs have the potential for high levels of accessibility, they can also be uniquely difficult if not well implemented. A 2003 study conducted in Maryland examined accessibility of one of the state’s EVMs (Bederson et al, 2003). It found that around 1 in 10 voters had significant concerns when using the system, ranging from readability issues to difficulty navigating their electronic ballot.

The 1.0 version of Helios performed even more poorly in this regard, with some studies showing that up to half of voters using the software were unable to complete the voting process (Karayumak et al., 2011). Issues such as overly-technical language and misleading error messages were main factors. While Helios 2.0 addresses many of the faults of its predecessor, it still demonstrates room for improvement.

To identify key issues with the Helios 2.0 software, we conducted an informal survey of 16 Carleton students. We created an election for testing purposes and sent a link simultaneously to all participants. The only instructions provided were network requirements (some students would need to use a VPN to connect), an encouragement to find and use the audit feature, an encouragement to view the bulletin board, and an invitation to send any feedback to the admin email account. We reached out to all students who didn’t initially send feedback and ultimately received all 16 responses.

We combined this research with two other pieces of research. The first was a cognitive walkthrough of Helios’ voting procedure based on previous studies (Karayumak), and the second was a study of a similar EVM being tested for the same kind of usability concerns (Bederson). By synthesizing the finding of these two sources with our own work, we identified a number of key issues to address.

1. The 'Audit' feature was difficult to locate and understand. It also confused voters about whether their vote had been successfully cast.
2. The button to log in was difficult to find, and as a result, many users were not asked to log in until they tried to submit their ballot. This also confused voters about the status of their vote.
3. Many parts of the process, such as encryption, are not self-explanatory and leave voters confused and lacking confidence in the system.
4. The process of filling out a ballot is difficult, with inconsistent navigation buttons and strange checkbox behavior.
5. The process suffered from using inconsistent language throughout, which lead to general confusion and lack of trust

While many other issues were identified, these were the ones that presented the most serious problems without requiring major overhauls.

The first of these was to update the audit feature to make it easier to use and understand. Previously, Helios displayed the option to audit off to the side as an ‘optional’ feature, and only provided a (brief) explanation after the link is clicked. We moved the audit button down to appear alongside “Submit this Vote” and provided explanatory text for each choice, which further clarifies that picking one option exempts the user from using the other, and specifies that after auditing, a new ballot will need to be cast. Additionally, the word “verify” was substituted for “audit” where applicable, both here and on the audit page.

Logging in is also a difficult process for some users. Helios divides its content pane into both a header and footer, with the login button and indicator exclusively found in the footer. We updated this by moving the login button and indicator into the header, in the upper right corner to correspond with current web standards. The message tells the user they need to either log in now using the button in the top right, or log when prompted during ballot submission.

To clarify when and how logging in must be performed, a message now displays above the “Vote in this election” button if the user it not yet logged in.

The arrangement and language used in the ballot-completion step was updated to be more clear and consistent, and a message was included informing voters how to change their selections. The "Next" button (shown here in red) now always appears in the same spot, the option to "Proceed" is now "Encrypt Ballot for Submission" and only is visible on the last question.

Future work

While these fixes address some of the major issues, there are a number that our team was aware of but could not address to due time or technical limitations. Among these include:

• Time zone display flexibility
• Better checkboxes in the ballot submission process
• Clearer indications of what step in the process the user is currently in
• A warning for users about to submit a blank ballot
• An indicator on the main page telling users if their vote appears on the bulletin board
• Better feedback to election creator when adding questions to the ballot
• Better functionality for the "Help" button (currently just drafts an email to the election creator)
• More explanation, especially for the smart-ballot tracker and bulletin board
• Further language cleanup

Further work on this project should seek to make these changes and further examine how these changes have affected the usability of the software.