End-To-End Verifiable Proof of Votes Cast in Elections

Abstract

Systems and methods for providing an end-to-end verifiable proof of votes cast in elections are provided. An example method includes generating an authentication address associated with a voting ballot and generating a cast permission address associated with a cast permission record; storing the authentication address, the voting ballot, the cast permission address, and the cast permission record to a secure data storage; receiving a user input and providing a user interface featuring the voting ballot and enabling the voter to submit a cast vote record (CVR); generating a CVR address, generating a receipt for voting and a receipt address; generating a result record including a final result associated with the CVR and a CVR result address associated with the result record; and storing the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to the secure data storage.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority of U.S. Provisional Patent Application No. 63/226,697 filed on Jul. 28, 2021, entitled “End-To-End Verifiable Proof of Votes Cast in Elections,” which is incorporated herein by reference in its entirety for all purposes.

TECHNICAL FIELD

The present disclosure relates generally to data processing and, more particularly, to systems and methods for providing end-to-end verifiable proof of votes cast in elections.

BACKGROUND

Public elections in the United States consist primarily of poll station in-person voting either on paper ballots or on highly controlled and monitored electronic machines. Vote-by-mail paper ballot voting has not been widely adopted except in a few states prior to the 2020 election. Overseas voters covered by the Uniformed and Overseas Citizens Absentee Voting Act (UOCAVA) vote primarily on paper even if some portions of the process are done electronically. These methods have been highly refined for security, accessibility, and privacy concerns over time but, in most cases, designing for one group of requirements often means sacrificing another group of requirements, or at best, settling for less than ideal solutions in some areas to accommodate other areas. For example, paper ballots offer high verifiability and accuracy, especially in post-election audits, but can be difficult to use for certain voter populations as well as having high costs associated with delivery and return in non-poll station applications done at scale. Often times security of these paper systems relies on physical security or on process procedures that work well but focus primarily on tamper prevention principles and cannot provide direct ballot-by-ballot verifiability to individual voters. None of these systems offers voter verifiability from beginning to end of the voting process, from ballot marking and casting to tabulation.

Starting as early as the late 90s, many ideas have circulated regarding using the Internet for voting, with goals of providing increased convenience and access to voters, as well as potentially reducing administrative costs to jurisdictions. Ross Perot's Reform Party might have been the first US political party to employ online voting, in 1996. However, voting over public networks has not been a viable option in the United States due to security concerns, privacy concerns, and a general lack of verifiability from the voters' perspective, the election officials' perspective, and from outside observers interested in confirming the integrity of any given election. There was some experimentation in remote electronic voting in the early 2000s through about 2014 but those efforts rarely led to use in public elections and never at wide scale. However, recent years have seen a boom of election vendors experimenting with public network voting, but the sentiment of such efforts has been met with justifiable skepticism after numerous systems and implementations have been found to contain serious or critical flaws in technology and/or implementation details. For example, the lowaReportApp from Shadow Inc., used in the 2020 Democratic caucus, suffered from technical issues, causing high-visibility delays in reporting results. In 2018, the West Virginia midterm election used the mobile voting application Voatz, in which researchers later discovered security vulnerabilities.

Thus, the challenge of voting via public networks is combining the necessary security and vote verifiability with the need to keep individual voter selections private.

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

According to an example embodiment, a system for providing an end-to-end verifiable proof of votes cast in elections is provided. The system may include a voting device, a secure data storage, and, optionally, a security device. The security device may be configured to generate an authentication address associated with a voting ballot. The security device may be further configured to generate a cast permission address associated with a cast permission record indicative of whether a voter is eligible to cast a vote on the voting ballot. The security device may be further configured to store the authentication address, the voting ballot, the cast permission address, and the cast permission record to the secure data storage.

The voting device may be configured to receive user input including a token generated by the security device. Based on the token, the voting device may provide a user interface featuring the voting ballot and enabling the voter to submit a cast vote record (CVR). The voting device may be configured to generate a CVR address based on the cast permission address. The voting device may be further configured to generate a receipt for voting and a receipt address associated with the receipt. The receipt address may be generated based on the CVR address. The voting device may be configured to generate a result record including a final result associated with the CVR and a CVR result address associated with the result record. The CVR result address may be generated based on the receipt address. The voting device may be configured to store the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to the secure data storage.

Additional objects, advantages, and novel features will be set forth in part in the detailed description section of this disclosure, which follows, and in part will become apparent to those skilled in the art upon examination of this specification and the accompanying drawings or may be learned by production or operation of the example embodiments. The objects and advantages of the concepts may be realized and attained by means of the methodologies, instrumentalities, and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements.

FIG. 1 is a block diagram of certificate distribution in an election system, according to some example embodiments.

FIG. 2 is a high-level block diagram showing data flow in an election system, according to some example embodiments.

FIG. 3 is a high-level block diagram showing data storage in an election system, according to an example embodiment.

FIG. 4 is a block diagram showing address hierarchy, according to an example embodiment.

FIG. 5 is a block diagram showing a process of generation of a receipt code of casting a vote, according to an example embodiment.

FIG. 6 is a block diagram showing a process of post-election receipt verification, according to an example embodiment.

FIG. 7 is a flow chart showing a method for attributing user behavior from multiple technical telemetry sources, according to an example embodiment.

FIG. 8 illustrates user interfaces of the mobile voting application, according to an example embodiment.

FIG. 9 shows a computing system that can be used to implement a system and a method for providing an end-to-end verifiable proof of votes cast in elections, according to an example embodiment.

DETAILED DESCRIPTION

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments, which are also referred to herein as “examples,” are described in enough detail to enable those skilled in the art to practice the present subject matter. The embodiments can be combined, other embodiments can be utilized, or structural, logical, and electrical changes can be made without departing from the scope of what is claimed. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope is defined by the appended claims and their equivalents.

The present disclosure is directed to providing end-to-end verifiable proof of votes cast in elections, also referred to as election systems. Voting systems dependent solely on paper are particularly difficult to verify end-to-end, especially in remote voting, with respect to providing verifiability to individual voters. As discussed in their handout on verifiable voting, Benaloh, Rivest, and others recognize this challenge with regard to ballot transport and storage. Moreover, verifiably secure transport and storage of paper records is particularly challenging for remote voting, whether in a supervised or unsupervised polling place. The solution then is to attempt to supplement, or in some cases replace, the paper process with a digital process or digital data that can be verified cryptographically in all stages of an election.

Benaloh, Rivest, and others provide the following description for the most basic definition of End-to-end verifiability (E2EV) systems. The E2EV system is a collection of techniques for replicating, and in some ways exceeding, the standards of evidence provided by an ideal, observed, polling place. The E2EV system is characterized by “Cast as Intended,” meaning that voters make their selections and, at the time of vote casting, can get convincing evidence that their encrypted votes accurately reflect their choices. The E2EV system is further characterized by “Recorded as Cast,” meaning that voters or their designates can check that their encrypted votes have been correctly included by finding exactly the encrypted value they cast on a public list of encrypted cast votes. The E2EV system is further characterized by “Tallied as Recorded,” meaning that any member of the public can check that all the published encrypted votes are correctly included in the tally without knowing how any individual voted.

The challenge of voting on public networks is combining the necessary security and vote verifiability to voters with the need to maintain individual voter privacy with regard to specific selections/votes. Many non-voting-related electronic systems can use public networks because privacy of the end user is permitted to be tied directly to the data being transferred and secured on either end. Additionally, as in banking online, corrections after the fact can be made to transactions should errors or interference be discovered at some later point. These principles do not apply to online voting and, therefore, systems must attempt to provide data security and verifiability in real-time to voters, election officials, and outside observers, but without revealing the actual vote contents of any given voter until such a point that the voter cannot be definitively tied to the vote data.

Because of the privacy requirements, keeping data verifiable and secure throughout the process is a constant challenge for all voting systems but particularly difficult for online voting systems. This is true because paper systems can rely heavily on process and physical security, especially during the vote submission and storage activities, that remote electronic systems cannot leverage. Any online voting system would therefore need to maintain a higher level of voter verifiability, especially after vote submission, than any paper-based system relying on process and physical security of ballots. This added need for verifiability all the way through vote aggregation and tabulation creates the greatest conflict with privacy requirements.

The system and method of the present disclosure attempt to solve the problem of data verifiability while maintaining voter privacy. This is achieved through a combination of a custom hardware device and specific software operations to create the cryptographic root of trust for the system and a series of intermediate certificates used to verify data as it is passed between components of the system including a voting device. This root of trust branches out to all other components such that all data transfers can be verified as authentic to the system and unaltered at any point. Voter anonymity is retained by keeping voter records only within an air-gapped security device, inaccessible to all users except when used to run specific elections operations. Combined with a Hierarchical Deterministic Address Protocol (HDAP) for storing CVRs, voters, administrators, and observers have multiple methods for data integrity and accuracy verification/validation. The system and method of the present disclosure provide solutions for security, data integrity, vote verifiability, and maintaining voter anonymity.

The system and method of the present disclosure use a variety of well-established hardware and software cryptographic technologies already used within the elections industry and in some cases outside the industry. The system combines existing well vetted technologies in novel and unique ways that solve the problems specifically around data security and end-to-end verifiability without compromising voter privacy. Included is a cryptographic hardware chip designed specifically for securing keys and sensitive data, cryptographic conventions such as Elliptic Curve Digital Signature Algorithm (ECDSA) with SHA-256 for signing and encrypting data with industry standard ciphers, standard certificate chain of trust processes, and the use of blockchain as the ballot box ledger. Multiple redundant and complementary cryptographic means are used, so even if future research discovers vulnerabilities in any of the technologies used, the other pieces may help mitigate issues until replacement solutions can be found for compromised pieces.

The system for providing an end-to-end verifiable proof of votes cast in elections is an E2EV mobile voting system that does not require centralized voting or paper ballots. Using a combination of security certificates, blockchain, and other cryptographic technologies, the system creates a robust E2E solution that is verifiable and secure over public networks, allowing voters to use their own smart phones or computers to vote remotely. By controlling the data, it is not necessary to control the hardware used by the voters.

The typical E2EV definition described previously involves three key ‘proofs’ with regard to vote verification.

Cast as Intended Proof—classified as an individual verifiability where voters can verify their vote is cast into the system in the same state or manner as they marked their ballot.

Recorded as Cast Proof—classified as both individual and universal verifiability for the purposes of the system for providing end-to-end verifiable proofs of votes cast in elections because both the voter and general observers can verify the authenticity and integrity of each vote stored within the system.

Tallied as Recorded—classified as universal verifiability because all observers of the system can verify that all valid stored votes are included in the final count/tabulation results.

Each of these proofs are explored below as to their relation to individual and aggregated votes. To this end, a description of the network construction and data transfers are required to better understand how the system itself can trust all pieces of data being passed between components.

FIG. 1 is a block diagram of certificate distribution 100 in an election system (also referred to as a system for providing an end-to-end verifiable proof of votes cast in elections, or a system), according to some example embodiments. A security device 120 used in the certificate distribution is a critical component in creating a secure election while still being able to maintain privacy of the voters. The security device 120 maintains the root of trust for the election as well as being the only place in the system that keeps a tie between identifiable voter information and the data used to secure all voter transactions within the system. The security device 120 is a purpose-built air-gapped hardware device owned and maintained by an administering jurisdiction but provisioned by the developers of the system at the time of assembly such that it can be verified to be a trusted device when delivered to the administering jurisdiction.

An Election Management System (EMS) 140 is used to create and maintain election definitions, election infrastructure settings, the voter list, and ballot data. The EMS 140 is responsible for verifying the health of the election network once deployed. As such, the EMS 140 connects to every piece of the system (except for voting devices) via networks and/or manual data transfers.

The system may further have an election registry server shown as election registry 150. The election registry 150 may contain election identifier (ID) information and other election-specific information, including supported languages, and is the access point for the data secure storage.

The system leverages blockchain technology to store the election voter list in the secure data storage 160 (also referred to herein as a public ledger or a blockchain) for the purpose of voter authentication and ballot data used to deliver the proper ballot style to each authenticated voter, and the system collects votes from the voter, serving as the digital ballot box. All live election data is located within the public ledger and is reviewable at all times by election admins, voters, and outside observers. Operation can be spread amongst many trustees to spread the trust.

A mobile voting application 130 runs on voter owned and controlled mobile devices. The mobile voting application 130 is used to initiate the voter authentication process, receive the properly assigned ballot, mark the ballot by the voter, and return the encrypted marked ballot and associated cryptographic receipt.

The voter token distribution service uses a token of a voter as an essential piece to creating the authentication of the voter within the system without compromising their identity when tied to a returned ballot. The token creation and distribution can be done by the administering jurisdiction or outsourced depending on scalable needs and security concerns.

A certificate chain may be created as follows. One of core elements of the system is the security device 120. The security device 120 is provisioned at manufacturing time with a signed root certificate (shown as a root certificate 110) from the private key stored securely at facilities of the developer of the system. The root certificate 110 becomes a common base certificate for all system components including the mobile voting application 130 delivered to voting devices. Intermediate certificates 170, created when the security device 120 is provisioned, are used to reduce the risk involved with having the root certificate sign data directly. The certificate chain may further include end-entry certificates 180.

The system may establish a chain of trust that relies only on one element of social trust, which may be the handling of the root certificate 110 and the provisioning of the security device 120. This security device 120 may become the “Root of Trust” for any given election body.

FIG. 2 is a high-level block diagram showing data flow 200 in an election system, according to some example embodiments. The system can delegate trust to the security device 120, which, in turn, delegates trust to various election components. In most cases throughout the system, trust is established by verifying that the source of the data or system has a certificate signed by the same security device 120. The exception is the mobile voting application 130, in which case the participant may confirm that it can trust the system or data by examining the chain of trust and confirming that the root of trust is a trusted source (the system). It can then trust the source's identity and use the provided public key to verify the signature proving authenticity.

The data flow 200 in FIG. 2 is provided by a fully provisioned and operating election network. Not all communication paths described are being used simultaneously but rather are used differently during pre-election, live election, and post-election activities. FIG. 2 shows the connections between components and distinguishes between networked traffic and manual data transfers.

To create the network depicted in FIG. 2, the components must be provisioned in a specific order. Provisioning this way allows each component to share certificates with one another such that data transfers between components can be verified as authentic and that the integrity of the data has not been compromised. Some provisioning is done once in the lifetime of the component while other provisioning is done on an election by election basis.

To establish data verification, data within the system is stored and transported in such a way that the origin of the data can be traced and the contents cannot be tampered with. Data is verified by confirming that it is signed by a trusted source. Using various keys and certificates provisioned per previous discussion, the end-to-end data verification can be established. Trust can be verified by following back the entire chain to the root certificate in the security device 120.

Data within the system may be transported by non-networked means as well as across public networks. Multiple methods of verification can be used for all operations such that a single participant or component, if compromised, cannot damage the integrity of the system.

Part of the security and verification of the system is that no data can go between components without being checked for authenticity and integrity once all components are provisioned. While this does not completely prevent nefarious activity due to the fact that many components have ownership/maintenance responsibilities spread among a variety of possible trustees, it does mean that all components would need to be compromised together in order for disruptions to data authenticity or integrity to occur. It should be determined in real time if a component starts malfunctioning or if dependent on a human factor, such as a quorum of users required to initiate particularly sensitive data transformation steps, would be caught in an after the fact audit of all component keys/certs and logs.

An election administrator 205 can be associated with an EMS workstation 105. Data from the EMS workstation 105 may be received by the EMS 140, which further provides the data to the election registry 150. A quorum of users 215 may be associated with security device 120. The security device 120 may provide data (such as a token package 280) to a token issuer 220. The token issuer 220 may generate a quick response (QR) code 225 and provide the QR code 225 to a voting device 230 associated with a voter 235. The voting device 230 may have a mobile voting application 130 running on the voting device 230. Election settings/language pack 295 may be communicated between the election registry 150 and the voting device 230. Data transfers 275 may be provided between the EMS 140 and the security device 120. The EMS workstation 105, the security device 120, and the voting device 230 may be in communication with a secure data storage 160. The security device 120 may provide Blockchain settings data 255 to the secure data storage 160. The voting device 230 may further be in communication with the election registry 150. The EMS 140 may also access a voter list/EMS data 240. Blockchain data updates 285 may be communicated between the secure data storage 160 and the EMS workstation 105. Authentication and ballot data transfer 290 may be provided between the secure data storage 160 and the voting device 230.

In FIG. 2, communication paths 250 show non-network data transfer, communication paths 260 show a user-entered data input, and communication paths 270 show networked data transfer during pre-election, live election, and post-election phases.

FIG. 3 is a high-level block diagram showing data storage 300 in an election system, according to an example embodiment. A root certificate 110 may include a root public key 305 and a root private key 310. The root private key 310 may be provided to a security device 120. The security device 120 may have a security device public key 315 and a security device private key 320. The security device 120 may provide the security device private key 320 to an EMS 140. The EMS 140 may have an EMS public key 325 and an EMS private key 330 and may store the security device public key 315. The EMS 140 may provide the EMS private key 330 to the security device 120.

The security device 120 may further provide the security device public key 315 to a secure data storage (public ledger) 160. The secure data storage 160 may store a public key 335, a private key 340, the security device public key 315, and the EMS public key 325.

The EMS 140 may further communicate with the election registry 150. The election registry 150 may store the security device public key 315 and the EMS public key 325.

The election registry 150 and the secure data storage 160 may be in communication with the mobile voting application 130. The mobile voting application 130 may store the root public key 305 and the security device public key 315.

FIG. 4 is a block diagram showing address hierarchy 400, according to an example embodiment. The voting system relies on a multi-factor authentication where the voter recreates the correct private keys in order to verify their identity by signing transactions. To this end, the security device uses some information known to the voter along with a random token to generate a master key as shown in FIG. 4. The private key is discarded, the token is delivered to the voter, and the public key is used to pre-populate the public ledger with the cast permission and authentication records. The voter uses the token and known information to recreate the key(s) within the mobile voting application needed to sign the transactions. No private key is ever stored on any device or server.

End-to-End Verifiable Proofs. In the description above, the focus has been on establishing the election network and verifying the authenticity and integrity of data transfers between components. While an essential piece to establishing the integrity of the election, on its own these steps do not constitute end-to-end verifiability. To complete this process, three proofs must exist. Due to the architecture described below for handling CVRs, the three proofs (Cast as Intended, Recorded as Cast, and Tallied as Recorded) are somewhat overlapping. As such, a review of the basic structure is provided with proof explanations following.

Vote Submission and Storage Architecture. The CVR collection and subsequent validations require two aspects. The first aspect is a voter receipt. The voter receipt contains data that fully encapsulates the ballot choices as well as some user defined data. It can be verified against the CVR and is recognizable to the voter. The receipt is generated on the voting device during the marking process and delivered to the voter at the time of ballot submission. This same receipt is created and stored as a child address (as described below) of the cast vote record within the public ledger. The second aspect is hierarchical deterministic addressing protocol (HDAP). The system uses hierarchical deterministic key generation to create a protocol for storing election data on a blockchain network. The protocol may provide predetermined locations for election records such as CVRs and associated receipts. The addresses can be traversed from parent to child, but not from child to parent. In this manner, a receipt holder can verify the receipt they have in hand cryptographically matches the receipt derived from a CVR stored within the public ledger without needing to actually access the CVR.

The HDAP can be used as follows. The HDAP uses hierarchical deterministic key generation based off of BIP3217 to layout a structure for storing election data in a way that supports end to end verification, including Cast as Intended proof, while maintaining the privacy of the voters. Hierarchical deterministic key generation provides the ability to derive child public key addresses from an extended public key of the parent and child private keys from the extended parent private key. Deriving private keys from public keys is not possible and deriving parents from children is not possible. The mobile voting application can provide the ability for the voter to create a parent private key. This parent key can extend child public keys, which then serve as addresses for storing the CVR and associated receipts. The address structure supports the following address types:

Authentication Address—Pre-loaded records in the public ledger for each voter that map to a ballot style. By presenting the system with proof of ownership of the private key, a voter can be authenticated and delivered a ballot. Poll book check-in transactions can also be posted against this address if the system is configured to do so.

Cast Permission Address—Pre-loaded in the public ledger for each voter who is allowed to submit a cast vote record. This address is a parent for all CVRs for a single voter in an election. This record is separate from the authentication address in order to support post-election reconciliation with other voting methods without any chance of exposing a user's votes.

CVR Address—CVR addresses are children of the cast permission address and store the cast vote records.

Receipt Address— A receipt address is a child of the CVR.

CVR Result Address— A CVR result address is a child of the receipt address that can store a document that provides details concerning the final result of the CVR.

Spoiled—Initiated by the voter if they choose to retract their vote, either to vote again via the mobile voting application or by other means. A spoiled vote cannot be counted in the results but the receipt and data verification can still be processed.

Accepted—The receipt and data verification passed and the CVR is included in the final vote count.

Withdrawn—The vote is withdrawn by the system during reconciliation because a ballot for this voter was cast by alternate means such as mail or a polling place.

Rejected—The receipt or data verification failed. This state should merit a full review of the voting system as it should not be possible under normal circumstances.

Creating addresses. As mentioned above, one of the types of data created for the system is authentication data 405, stored in the secure data storage (public ledger) 160 in the form of a public key 335 tied to a ballot style. This public key 335 was first created by the security device 120 from the data provided by the EMS 140, such as a voter credentials detail, a random bit of data generated by the system and later output as the voter token, and the associated ballot style for that voter. On the security device 120, a key for each voter is created and may be called the ‘master key’ 410 in the diagram shown in FIG. 4. From the master key 410, two child keys/addresses are created: the Cast Permission 415 and the Authentication Record 420, both of which come with an associated ballot style ID. In the case of the Authentication Record 420, the ballot style ID serves to deliver the correct ballot to the voter, and in the Cast Permission 415, the ballot style ID serves to validate the expected ballot style, which is returned and stored as the CVR 425. The master key 410 is never removed from the security device and the private key part of the master key 410 is destroyed and never stored. Only the public key remains in the security device 120 for the purpose of vote reconciliation to be discussed later.

The public ledger is populated with the list of cast permission 415 and authentication record 420 public keys/addresses.

Authenticating and Casting a Vote. The mobile voting application uses the same seed data (predetermined voter credentials and random token data provided in the form of the QR code delivered to the voter separately) and key generation library as the security device did to ‘recreate’ the same master key and all associated children. For authentication, the mobile voting application sends an authentication request transaction to the public ledger signed by the private authentication record key. If the public ledger can verify a corresponding public authentication record successfully, it may return the ballot associated with the attached ballot style ID. This authentication transaction stored in the public ledger contains no voter identifiable information but can later be returned to the security device, which still contains the public master key, for the purposes of producing a list of voters who have voted in the election.

In a very similar manner as authentication, casting a vote from the mobile voting application uses the same master key but this time uses the cast permission child to create a CVR address and associated receipt address. The CVR and associated receipt address and data are sent as a transaction to the public ledger signed by the cast permission private key. The public ledger confirms said transaction is a valid request by comparing the signature against its list of public cast permissions keys/addresses. If one matches, the public ledger validates two bits of data: that the associated ballot style is as expected and that another CVR 425 and receipt combo have not already been collected and stored. If a CVR 425 is already present (as determined in receipt 430) for that specific Cast Permission 415, it may return a response to ask the voter to ‘Spoil’ 435 the previous submission. Spoiling involves the application creating another child address from the previous receipt address to indicate the intention to not count that CVR 425. The CVR 425 never leaves the public ledger but the additional spoil address in the hierarchy can be used later to remove that collected CVR 425 from tally operations. The frequency and number of spoils allowed can be configured to meet jurisdiction rules/regulations/preferences. Accepted step 440 means that the receipt 430 and data verification passed and the CVR 425 is included in the final vote count.

FIG. 5 is a block diagram 500 showing a process of generation of a receipt code of casting a vote, according to an example embodiment. The receipt may have the following data elements:

Address—This is where the receipt data is stored and can be looked up from any device.

User Defined Code 505—A code or password that can be defined by a user. The system may generate a random code for the user but also allows the user to regenerate a new code or type in a fully custom code if they choose.

CVR Digest 535—Full SHA-256 525 digest of the contest selections 510, user defined code 505, and optional entropy 515.

Receipt Code 540—Truncated version of the CVR digest 535 to allow for easier recognition by a human.

The CVR digest 535 and receipt code 540 may be generated by creating a digest and truncated digest 530 from the relevant data.

The receipt is offered to the voter for storage/printing through the voting device at the time of creation prior to submission to the public ledger. However, to increase coercion resistance, the saved/printed form of this receipt may have details encrypted by prompting the user for a user generated password/pin with a salt 520. The printed version of the receipt may have distinctly different data displayed when compared to the digitally stored copy of the receipt.

Voter Validation. It is important that a technically sophisticated user (qualified voter) can recreate the CVR Digest 535 on their own to validate the accuracy of the receipt. In order to facilitate this, the mobile voting application allows a user to see a detailed view that lists all of the choice data used to generate the receipt code 540 as well as an explanation on the digest generation. With this data, the user can use any tool they wish (such as an online SHA-256 525 tool) to recreate the digest and confirm the receipt digest is correct. Less technically inclined voters (general voters) can still get peace of mind by observing that their receipt code 540 changes in a deterministic manner as they vote because the receipt code 540 may be displayed on all ballot marking and review pages of the mobile voting application and change in real time as they alter selections or change the User Defined Code 505.

After submitting the vote, all voters can confirm that the correct receipt with all described data above is stored in the public ledger and matches the receipt generated on their device from the same CVR 425 data prior to submission. Voters may not be directly reviewing the submitted CVR 425, only comparing the stored/saved/printed receipt copy in hand to the digitally stored copy in the public ledger.

Due to the encryption of the data on the voter's saved/printed receipt, the voter may need to use an open source tool to enter the details known only by them (password/pin) and the data on the hardcopy receipt to successfully reverse the receipt address and the user defined code on the actual receipt stored in the public ledger. Once these details are decrypted, a voter can use them to verify that the public ledger contains the same receipt as they have in hand.

FIG. 6 is a block diagram showing a process 600 of post-election receipt verification, according to an example embodiment. After the election is complete and the CVRs 425 are decrypted, the receipts 605 are verified by the election administrator by recreating the CVR 425 digest and comparing it to the stored receipt 605. Once the verification is complete, a record may be stored marking the CVR 425 verified/accepted. Any CVRs 425 found generating receipts 605 that do not match saved receipts 605 may be flagged and steps can be taken to address the improperly collected data, including invalidating the election if deemed necessary.

The E2EV verification may be performed as follows. The Cast as Intended Proof uses multiple steps from the process listed above.

At the first step, a voter creates and saves/stores the receipt 605 and receipt code 540 generated by the mobile voting application on their own voting device.

At the second step, the voter can at any time post a submission request to see the copy of said receipt 605 in the public ledger by using the address provided on their receipt and/or recreating/using the Cast Permission 415 key to sign a request for all CVR 425 history.

These methods could also return any spoil activity to any associated CVR 425 as the Spoil 610 address is a child of the Receipt 605 address and a user can also validate down the chain.

At the third step, because the voter only has a Receipt code 540, they cannot be assured that the copy of the Receipt 605 address in the public ledger truly reflects their choices, at least not until the final step is taken post-election.

At the fourth step, when the CVR 425 is decrypted, the CVR 425 digest can be generated to recreate the Receipt code 540; only at that time would a voter be assured the Cast as Intended Verification was complete because: a) the receipt 605 stored in the public ledger matches the receipt in hand; and b) the receipt 605 stored in the public ledger matches the CVR 425 digest stored in the public ledger. If these two conditions exist, a voter knows the CVR 425 in the public ledger is their intended CVR 425.

The Recorded as Cast Proof overlaps significantly with the Cast as Intended based on the methodology described above. Basically the same steps apply but as follows.

At the first step, the CVR 425 is decrypted and a digest is generated. At the second step, the receipt is recreated from above digest and compared against stored receipt; if a) receipts 605 match and no spoil child is present, then CVR 425 is deemed valid/Accepted 615; and b) receipts do not match, then CVR 425 is deemed invalid. At this point, it is unknown if the CVR 425 or receipt 605 is incorrect. If an investigation can determine ‘why’ a discrepancy exists, steps can be taken to: i) invalidate an individual CVR 425 (in a case where a single instance root cause can be determined) and child address of Rejected added; or ii) invalidate entire election because no root cause can be determined or systematic tampering/failure cannot be ruled out.

At the third step, if all CVRs 425 are deemed valid, each is populated with an Accepted child address, which serves as part of the following Tallied as Recorded Proof.

When using the security device with additional data (a list of voters who voted in other methods such as Vote by Mail (VBM), in-person, and so forth), the security device can also create a child address for receipts tied to CVRs 425 of voters who voted in other methods. This child could be in the Withdrawn status, thus removing the CVR 425 from final tally calculations. Assuming there is more than one voter with a Withdrawn status per ballot style, privacy is not compromised as the security device internal operations can handle the ties between voter ID and status at the Master Key 410 level and only output a list of Receipt 605 addresses that need additional Withdrawn child addresses attached.

Tallied as Recorded Verification Steps. Assuming both of the previous verifications show errors, the Tallied as Recorded Verification is possible through a variety of methods. Because the CVRs 425 are at this point stored in clear text, the tally aspect can be verified, reverified, and checked by as many parties/groups/individuals as have ability to count votes. The only caveats that exist are:

A) All tallying parties have access to all CVRs 425 with Accepted child addresses.

B) Voters can use their Cast as Intended proven receipt to verify that same receipt address also has an associated Accepted child address (anyone with the receipt can traverse down the chain to see Accepted address but not up the chain to see CVR 425 results).

C) All tallying parties have access to tally rules maintained in the public ledger as well as an election setting for the purposes of determining the counting rules for each contest.

Unlike other E2EV systems that keep CVR 425 data encrypted, which then requires mathematical proofs for the correctness of vote counting, the system of the present disclosure ends with unencrypted CVRs 425 that can be treated similarly to traditional paper ballot for tallying, reporting, auditing, and recounts. Assuming the previous two proofs are successfully validated, a jurisdiction can release the CVR 425 data the same way ballot images and CVR 425 data may be released in traditional paper systems.

A main advantage of the system is that it ultimately leaves the cast vote record used for tabulation purposes in a human readable and auditable format without compromising voter privacy. The use of an HDAP allows verification by different entities to occur cryptographically without necessarily giving up all the information to reveal identity. The system is highly dependent on a purpose built hardware security device to manage much of the key generation and privacy maintaining functions, but doing so allows the rest of the system to be fully publicly visible and auditable during all stages of the election cycle.

Areas that are important pieces to consider if applying this system to a real life implementation scenario include (in no particular order):

A) The detection and prevention of malware on end user (voter) devices.

B) Details on physical security and process security controls for the security device, the public ledger network, the registry, and the EMS.

C) Details on the Token Distribution methods and related security concerns. Paper token delivery has a different set of security concerns than an electronic delivery to the voter.

D) How to encourage/ensure enough voters follow through with the full Cast as Intended Verification of their receipts against Accepted receipts such that to create a statistically significant confidence interval in the accuracy and integrity of the election that meets industry standards. Theoretically, every voter can follow through but realistically many will not and, if no voters validate their receipts against Accepted CVRs, then we cannot be sure as election administrators or observers that the Proof of Cast as Intended holds true. There is no current mechanism proposed for encouraging participation or even what levels of participation are needed. This question is of high importance to solve next.

FIG. 7 is a flow chart of a method 700 for providing an end-to-end verifiable proof of votes cast in elections, according to some example embodiments. The method 700 may commence in block 705 with generating, by a security device, an authentication address associated with a voting ballot. The method 700 further includes generating, in block 710, by the security device, a cast permission address associated with a cast permission record indicative of whether a voter is eligible to cast a vote on the voting ballot. The method 700 continues with storing, in block 715, by the security device, the authentication address, the voting ballot, the cast permission address, and the cast permission record to a secure data storage. The method 700 further includes receiving, in block 720, by a voting device, a user input including a token generated by the security device. The method 700 continues with providing, in block 725, by the voting device and based on the token, a user interface featuring the voting ballot and enabling the voter to submit a CVR.

The method 700 further includes generating, in block 730, by the voting device and based on the cast permission address, a CVR address associated with the CVR. The method 700 continues with generating, in block 735, by the voting device, a receipt for voting and a receipt address associated with the receipt for voting. The receipt address is generated based on the CVR address. The method 700 further includes generating, in block 740, by the voting device, a result record including a final result associated with the CVR and a CVR result address associated with the result record. The CVR result address is generated based on the receipt address. The method 700 continues with storing, in block 745, by the voting device, the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to the secure data storage.

The secure data storage may be configured to store the voting ballot at the authentication address, the cast permission record at the cast permission address, the CVR at the CVR address, the receipt for voting at the receipt address, and the result record at the CVR result address.

At least one of the authentication address, the cast permission address, the CVR address, the receipt address, and the CVR result address may include a public key of an asymmetric cryptographic scheme.

The security device may be further configured to generate the authentication address and the cast permission address based on a public key of a master asymmetric cryptographic scheme.

The security device may be further configured to receive the public key and a private key of the master asymmetric cryptographic scheme, delete the private key, and store the public key.

In an example embodiment, the method 700 may further include, prior to providing the user interface, generating, by the voting device and based partially on the token, an authentication request including the authentication address. The voting device may send the authentication request to the secure data storage. The secure data storage may be configured to send, to the voting device, the voting ballot corresponding to the authentication address.

In an example embodiment, the method 700 may further include receiving, by the voting device, a user defined code. Upon receiving the user defined code, the voting device may generate, based on the user defined code and the CVR, a hash code of the CVR and a truncated version of the hash code. The receipt for voting includes the receipt address, the user defined code, the hash code of the CVR, and the truncated version of the hash code.

The security device may be further configured to receive the CVR and the receipt for voting and generate, based on the CVR and the user defined code in the receipt for voting, a further hash code. The security device may compare the further hash code to the hash code in the receipt for voting to verify the CVR.

The voting device may display the hash code while the voter is casting the vote. The voting device may change the hash code in real time in response to an indication that the voter has altered one of a selection in the CVR and the user defined code. In an example embodiment, the token includes a QR code.

FIG. 8 illustrates user interfaces of the mobile voting application, according to an example embodiment. The user interface 800 illustrates generation of a voter code. The user interface 810 shows marking a ballot by a voter and updating a receipt code in real-time as the voter marks the ballot. The user interface 820 illustrates an intuitive explanation of the receipt code and ability to change the voter code. The user interface 830 illustrates the receipt code.

FIG. 9 illustrates an exemplary computing system 900 that can be used to implement embodiments described herein. The computing system 900 can be implemented in the contexts of the EMS workstation 105, the root certificate 110, the security device 120, the voting device 230, the mobile voting application 130, the EMS 140, the Election Registry 150, the token issuer 220, and the secure data storage (public ledger) 160. The exemplary computing system 900 of FIG. 9 may include one or more processors 910 and memory 920. Memory 920 may store, in part, instructions and data for execution by the one or more processors 910. Memory 920 can store the executable code when the exemplary computing system 900 is in operation. The exemplary computing system 900 of FIG. 9 may further include a mass storage 930, portable storage 940, one or more output devices 950, one or more input devices 960, a network interface 970, and one or more peripheral devices 980.

The components shown in FIG. 9 are depicted as being connected via a single bus 990. The components may be connected through one or more data transport means. The one or more processors 910 and memory 920 may be connected via a local microprocessor bus, and the mass storage 930, one or more peripheral devices 980, portable storage 940, and network interface 970 may be connected via one or more input/output buses.

Mass storage 930, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by a magnetic disk or an optical disk drive, which in turn may be used by one or more processors 910. Mass storage 930 can store the system software for implementing embodiments described herein for purposes of loading that software into memory 920.

Portable storage 940 may operate in conjunction with a portable non-volatile storage medium, such as a compact disk (CD) or digital video disc (DVD), to input and output data and code to and from the computing system 900 of FIG. 9. The system software for implementing embodiments described herein may be stored on such a portable medium and input to the computing system 900 via the portable storage 940.

One or more input devices 960 provide a portion of a user interface. The one or more input devices 960 may include an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, a stylus, or cursor direction keys. Additionally, the computing system 900 as shown in FIG. 9 includes one or more output devices 950. Suitable one or more output devices 950 include speakers, printers, network interfaces, and monitors.

Network interface 970 can be utilized to communicate with external devices, external computing devices, servers, and networked systems via one or more communications networks such as one or more wired, wireless, or optical networks including, for example, the Internet, intranet, LAN, WAN, cellular phone networks (e.g., Global System for Mobile communications network, packet switching communications network, circuit switching communications network), Bluetooth radio, and an IEEE 802.11-based radio frequency network, among others. Network interface 970 may be a network interface card, such as an Ethernet card, optical transceiver, radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include Bluetooth®, 3G, 4G, and WiFi® radios in mobile computing devices, as well as a USB.

One or more peripheral devices 980 may include any type of computer support device to add additional functionality to the computing system. The one or more peripheral devices 980 may include a modem or a router.

The components contained in the exemplary computing system 900 of FIG. 9 are those typically found in computing systems that may be suitable for use with embodiments described herein and are intended to represent a broad category of such computer components that are well known in the art. Thus, the exemplary computing system 900 of FIG. 9 can be a personal computer, handheld computing device, telephone, mobile computing device, workstation, server, minicomputer, mainframe computer, or any other computing device. The computer can also include different bus configurations, networked platforms, multi-processor platforms, and so forth. Various operating systems (OS) can be used including UNIX, Linux, Windows, Macintosh OS, Palm OS, and other suitable operating systems.

Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium). The instructions may be retrieved and executed by the processor. Some examples of storage media are memory devices, tapes, disks, and the like. The instructions are operational when executed by the processor to direct the processor to operate in accord with the example embodiments. Those skilled in the art are familiar with instructions, processor(s), and storage media.

It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the example embodiments. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a central processing unit (CPU) for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as RAM. Transmission media include coaxial cables, copper wire, and fiber optics, among others, including the wires that include one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency and infrared data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-read-only memory (ROM) disk, DVD, any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASHEPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.

Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.

Thus, systems and methods for providing end-to-end verifiable proof of votes cast in elections are described. Although embodiments have been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes can be made to these exemplary embodiments without departing from the broader spirit and scope of the present application. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A system for providing an end-to-end verifiable proof of votes cast in elections, the system comprising:

a voting device configured to: receive a user input including a token generated by a security device; provide, based on the token, a user interface featuring a voting ballot and enabling a voter to submit a cast vote record (CVR); generate, based on a cast permission address, a CVR address associated with the CVR; generate a receipt for voting and a receipt address associated with the receipt for voting, the receipt address being generated based on the CVR address; generate a result record including a final result associated with the CVR and a CVR result address associated with the result record, the CVR result address being generated based on the receipt address; and store the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to a secure data storage; and

the secure data storage in communication with the voting device, the secure data storage being configured to store the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record.

2. The system of claim 1, further comprising:

the security device configured to: generate an authentication address associated with the voting ballot; generate the cast permission address associated with a cast permission record indicative of the voter being eligible to cast a vote on the voting ballot; and store the authentication address, the voting ballot, the cast permission address, and the cast permission record to a secure data storage.

3. The system of claim 2, wherein the secure data storage is configured to store:

the voting ballot at the authentication address;

the cast permission record at the cast permission address;

the CVR at the CVR address;

the receipt for voting at the receipt address; and

the result record at the CVR result address.

4. The system of claim 2, wherein at least one of the authentication address, the cast permission address, the CVR address, the receipt address, and the CVR result address include a public key of an asymmetric cryptographic scheme.

5. The system of claim 2, wherein the security device is configured to generate the authentication address and the cast permission address based on a public key of a master asymmetric cryptographic scheme.

6. The system of claim 5, wherein the security device is configured to:

receive the public key and a private key of the master asymmetric cryptographic scheme;

delete the private key; and

store the public key.

7. The system of claim 2, wherein the voting device is configured to, prior to providing the user interface:

generate, based partially on the token, an authentication request including the authentication address; and

send the authentication request to the secure data storage, wherein the secure data storage is configured to send, to the voting device, the voting ballot corresponding to the authentication address.

8. The system of claim 2, wherein the voting device is configured to:

receive a user defined code; and

generate, based on the user defined code and the CVR, a hash code of the CVR and a truncated version of the hash code; and

wherein the receipt for voting includes the receipt address, the user defined code, the hash code of the CVR, and the truncated version of the hash code.

9. The system of claim 8, wherein the security device is configured to:

receive the CVR and the receipt for voting;

generate, based on the CVR and the user defined code in the receipt for voting, a further hash code; and

compare the further hash code to the hash code in the receipt for voting to verify the CVR.

10. The system of claim 8, wherein the voting device is configured to:

display the hash code while the voter is casting the vote; and

change the hash code in real time in response to an indication that the voter has altered one of a selection in the CVR and the user defined code.

11. The system of claim 7, wherein the token includes a quick response code.

12. A method for providing an end-to-end verifiable proof of votes cast in elections, the method comprising:

receiving, by a voting device, a user input including a token generated by a security device;

providing, by the voting device and based on the token, a user interface featuring a voting ballot and enabling a voter to submit a cast vote record (CVR);

generating, by the voting device and based on a cast permission address, a CVR address associated with the CVR;

generating, by the voting device, a receipt for voting and a receipt address associated with the receipt for voting, the receipt address being generated based on the CVR address;

generating, by the voting device, a result record including a final result associated with the CVR and a CVR result address associated with the result record, the CVR result address being generated based on the receipt address; and

storing, by the voting device, the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to a secure data storage.

13. The method of claim 12, further comprising:

generating, by the security device, an authentication address associated with the voting ballot;

generating, by the security device, the cast permission address associated with a cast permission record indicative of the voter being eligible to cast a vote on the voting ballot;

storing, by the security device, the authentication address, the voting ballot, the cast permission address, and the cast permission record to the secure data storage.

14. The method of claim 13, wherein the secure data storage is configured to store:

the voting ballot at the authentication address;

the cast permission record at the cast permission address;

the CVR at the CVR address;

the receipt for voting at the receipt address; and

the result record at the CVR result address.

15. The method of claim 13, wherein at least one of the authentication address, the cast permission address, the CVR address, the receipt address, and the CVR result address include a public key of an asymmetric cryptographic scheme.

16. The method of claim 13, wherein the security device is configured to:

generate the authentication address and the cast permission address based on a public key of a master asymmetric cryptographic scheme;

receive the public key and a private key of the master asymmetric cryptographic scheme;

delete the private key; and

store the public key.

17. The method of claim 13, further comprising, prior to providing the user interface:

generating, by the voting device and based partially on the token, an authentication request including the authentication address; and

sending, by the voting device, the authentication request to the secure data storage, wherein the secure data storage is configured to send, to the voting device, the voting ballot corresponding to the authentication address.

18. The method of claim 13, further comprising:

receiving, by the voting device, a user defined code; and

generating, by the voting device and based on the user defined code and the CVR, a hash code of the CVR and a truncated version of the hash code; and

wherein the receipt for voting includes the receipt address, the user defined code, the hash code of the CVR, and the truncated version of the hash code.

19. The method of claim 18, wherein the security device is configured to:

receive the CVR and the receipt for voting;

generate, based on the CVR and the user defined code in the receipt for voting, a further hash code; and

compare the further hash code to the hash code in the receipt for voting to verify the CVR.

20. A system for providing an end-to-end verifiable proof of votes cast in elections, the system comprising:

a voting device configured to: receive a user input including a token generated by a security device; provide, based on the token, a user interface featuring a voting ballot and enabling a voter to submit a cast vote record (CVR); generate, based on a cast permission address, a CVR address associated with the CVR; generate a receipt for voting and a receipt address associated with the receipt for voting, the receipt address being generated based on the CVR address; generate a result record including a final result associated with the CVR and a CVR result address associated with the result record, the CVR result address being generated based on the receipt address; and store the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record to a secure data storage;

the secure data storage in communication with the voting device, the secure data storage being configured to store the receipt address, the receipt for voting, the CVR address, the CVR, the CVR result address, and the result record; and

the security device configured to: generate an authentication address associated with the voting ballot; generate the cast permission address associated with a cast permission record indicative of the voter being eligible to cast a vote on the voting ballot; and store the authentication address, the voting ballot, the cast permission address, and the cast permission record to a secure data storage.