An Object-Oriented Framework for Digital Voting

An Object-Oriented Framework for Digital Voting Patricia Dousseau Cabral Graduate Program in Computer Science Federal University of Santa Catarina UFSC Florianópolis, Brazil dousseau@inf.ufsc.br Ricardo Pereira e Silva Department of Informatics and Statistics Federal University of Santa Catarina UFSC Florianópolis, Brazil ricardo@inf.ufsc.br Roberto Silvino da Cunha Labsoft Federal University of Santa Catarina UFSC Florianópolis, Brazil rsc@inf.ufsc.br Abstract Voting is a mechanism widely used in decision making and are commonly employed by governments and businesses. The confidence in the voting process is fundamental to the credibility of the result. Increasingly polls are conducted over the internet due to its practicality and ease of use. But this practice brings new challenges, such as denial of service, confidence in the system, and coercion of voters. Several online voting systems have been proposed, but implementing and evaluating them is a difficult and complex task. To facilitate the development and evaluation of these systems, as well as the idealization of new digital voting protocols, we developed an object-oriented framework. With it you can extend systems and protocols in an easier way, allowing focus on the most important points of development. Digital voting, object-oriented framework, voting protocols, voting systems I.INTRODUCTION In recent years new vonting alternatives have emerged, such as online elections. It brings benefits such as a faster and more efficient tally, making it easier to cast the vote, eliminating the need of commuting to the polling station, possibility of process verification and reducing costs. But new threats can emerge, such as ease of coercion of voters and new opportunities for fraud. To reduce these risks, there are several safety requirements that the system must meet [1]: - Accuracy: ensure that only valid ballots will be counted in the tally and cannot be changed or duplicated. - Uniqueness: ensuring that only authorized voters participate in the voting, only voting once. - Privacy: not allowing to link the vote to the voter (anonymity), not allowing knowing the option selected by the voter (non-coercion) and all ballots must be kept secret until the end of the tally (impartiality) - Verifiability: there are two types of verifiability: individual, that allows the voter to verify that their vote was correctly determined; and universal, which shows that all the votes were counted correctly. There is an inherent difficulty in meeting all these requirements since some tend to be self-exclusionary, such as the difficulty in proving that the vote of the voter was properly counted while not revealing their voting option. Or difficulty in allowing only authorized voters to cast a ballot without associating the vote with the voter. Several voting protocols have been proposed in literature trying to satisfy the requirements mentioned above. Besides the difficulty of designing new protocols, there is the difficulty of implementing a complete system that uses it to be able to validate and analyze the proposed protocol. To facilitate this process, we developed an object-oriented framework for systems and digital voting protocols to simplify the deployment and management of online voting. II. COMPARATIVE STUDY Several of the proposed protocols which are developed for specific situations did not meet all the requirements that make an election safe. This is due to the difficulty in meeting all requirements. An example is the Helios voting system [2], which is suitable for elections where voting should be secret, but where coercion is not a major threat. In this line of work we can cite polls for clubs, software communities and student communities. The system described by Chuan-Kun Wu and Ramesh Sankaranarayana [3] is suitable for coercion free elections, because the system surpasses this threat by allowing the voter to vote several times. Making it harder to force the voter to choose a particular option, since they can change it later. There are several proposed protocols and voting systems, as can be seen in [2] [7][8] [9] [10].Protocols structures are well formed and usually small changes in its logic can compromise system security. It is not an easy task to change a part of the protocol or extend it without considering the impact across its logic. Thus, typically they are not configurable, and neither the systems that use them, since they are dependent. So we have systems that are inflexible and difficult to reuse if you want to change their operating logic. A.Voting primitives According to Jörg Helbach and Jörg Schwenk [6] voting systems use different technologies for its implementation, the most used are: Homomorphic encryption: allows the sum of the votes and decryption of encrypted result as follows E(x1) + E(x2) = E(x1 + x2) where x1 and x2 are ballots. By way of this technique is not necessary to decipher each vote individually, making it more difficult to associate the voter and their vote, making it easier to proof that all

ballots were counted correctly, and all ballots received were counted. Mixnet: shuffles the order of arrival of the ballots guaranteeing anonymity of the voters, making it impossible to determine the order of voting. Blind signature: allows signing documents without knowing their contents. This is useful in validating ballots so that the system can validate it without knowing the choice of the voter. Bulletin Board: works like a mural of information, allowing sensitive data to be safely released. It can be used to publish the election results, because it ensures that only authorized entities publish information, and ensures that the data has not been changed or deleted. [11] Asymmetric encryption: allows encryption and signatures of the contents in a secure way. To facilitate the use of asymmetric cryptography, a repository of keys and digital certificates are used, which are both implemented in the framework. Symmetric encryption: allows secure encryption of content, using only one key instead of two. Hash: generates unique identifiers making it easy to identify objects and analyzing if changes were made. In the developed framework these technologies were considered as different primitives that will be used in the protocol. You can insert and remove the primitives from the structure of the framework in specific places without major impacts. B. Motivation Given the fact there is a large number of proposed protocols and the difficulty to validate them, since a new system is required to be built whenever you want to validate a specific change, an object-oriented framework for protocols is a good idea. Nevertheless, there are not many documented proposals. David Lundin [4] proposes a digital voting system based on components that can be interchanged and audited, so that you can add and remove components without impacting other parts of the system. Such a system ends up being difficult to use, since it is necessary to create a new component every time you want to change something, being necessary to follow all the conventions of the component during its creation. Stefan Popoveniuc and Poorvi L. Vora [5] propose a framework for voting systems using mixnet and paper ballots. They analyzed four systems whose front-end and back-end can be interchanged. Such a system is restricted to voting using paper ballots and mixnet, additionally in being completely necessary to build the back-end and front-end when you want something different. The proposed object-oriented framework is more flexible than similar proposals, it allows you to implement specific changes rather than being required to build a component or a front / back end. Moreover, it is modularized and can make changes with little impact on other parts of the framework with a high code reuse, since most of the structure of the voting process is implemented in the framework, and reused every time a new voting system is developed. This is ideal for testing and evaluating new protocols and systems, since minor codes need to be written. C.Vulnerabilities Although there are several proposed protocols for digital voting that meet all or some of the requirements mentioned, none is used in a large scale election with high criticality [3]. The reason is that there are several difficulties in making a voting system reliable. According Chuan-Kun Wu and Ramesh Sankaranarayana [3] there are several aspects that make digital voting so complex and vulnerable: reliability in software, reliability on the internet, reliability of database system, confidentiality of electronic votes, detection of double voting, vote buying and internet terrorist attacks. It is necessary that the authors of protocols and digital voting systems adhere to the above challenges, so that the system can be as reliable as possible. With the framework it is possible to reduce the development cycles and tests, and the maturation of the software becomes more reliable. III. FRAMEWORK For the development of the object-oriented framework was considered the aspects that must be taken into account when envisioning the digital voting system: their vulnerabilities, technologies, potential threats to its integrity and the entire management of an election. Its structure consists of modules that interact with each other. One module is responsible for cryptographic primitives, another for the management of ballots and voting options, authentication, creating protocols, managing users and for managing elections (Figure 3). A.Functionalities A digital voting system should provide basic functionalities. Whereas there are in the system administrator, voter, register agent and auditor profiles, we can list the following roles associated with the use cases of Figure 1 and 2. Administrator: The system administrator is responsible for registering elections and all information about it, such as voting date, title, voting options, etc. These steps are different use cases, since it can be performed at different times. Voter: have the power to obtain a ballot, cast a ballot, verify that their ballot was counted correctly and check the result. Receiving the ballot and casting the ballot are parts of the voting process that are divided into two stages because they necessarily do not happen together. Checking if the ballot was properly audited takes place in the final stage of the voting which depends on the protocol. Auditor: the system has two types of auditing. The configuration auditing and result auditing. Every election may or may not enable them, leaving it to the system administrator. If at least one is enabled, it is necessary that at least one auditor is registered in the election. The configuration auditing concerns the data analysis of the election, that is, if all the information registered by the administrator is correct: election title, voting date, voting options, etc. The election can only be made public after the approval of all auditors. Since the result

auditing concerns the analysis of the ballot counting and other evidences that the election may issue depending on the protocol, such as evidence that the mixnet shuffle was done correctly. Only after this analysis is that the result can be revealed. If the auditing is rejected by some problem, the election should be canceled because it proves that there was some fault or fraud during the process. Figure 1. Administrator and register agent use cases Register agent: Responsible for the registration of voters in a particular election. This function can also be assigned to the administrator, eliminating this role. Besides the specific use cases for each role, they all have the ability to log into the system and list all elections that they are related. protocol [8] was chosen because it requires three subsystems, validator, pollster and tallier. The Seas protocol [9] is based on the Sensus protocol, with minor modifications intended to eliminate the possibility of authorities voting in the place of voters who abstained from voting. It was an issue found in the Sensus protocol. Finally, the protocol proposed by Ray [10] makes use of three authorities, a ballot distributor, a certifying authority and a voter compiler. From the domain analysis, it is concluded that it is possible to split a vote in four steps: Initialization: optional step, performed if there is need for some protocol initialization, such as the inclusion of previous blank ballots in the ballot box or mixnet creation servers. Obtaining a ballot: a step where the voter gets a ballot, and optionally performs the auditing. It is usually anticipated by the authentication process of voting, with some exceptions, as can be seen in [2], where the voter authenticates just in time to cast the ballot, allowing anyone to get a ballot and perform the auditing. Casting a ballot: it is the act of voting. A step after the voter selects their voting option, and then send their ballot to the system. Some protocols require that the voter authenticate themselves in this step, for example, Helios [2]. Tally: a step started after the end of voting, where all votes are counted and the results are announced. This step can also contain the results of the auditing conducted by the auditors of the election. All these steps may employ some common mechanisms, such as authentication, use of ballots, user profiles, etc. A common factor was the use of ballots containing the voting options and the definition of roles a user can assume in the system, normally being voters, administrators, register agents, auditors and fiscals. Another key aspect is the role of the authorities. Some systems, such as Helios, use only a controlling authority, which manages the entire voting process: voter authentication, receiving the votes, counting and publishing the results. Figure 2. Voter and auditor use cases B.Development methodology The domain analysis to develop the framework started with the identification of similarities between different voting protocols described in the literature. For this, we selected the following protocols [2] [7] [8] [9] [10]. These choices have some characteristics relevant to voting systems and constitute a sample of the relevant field of voting protocols. In the case of Helios [2] it has both individual and universal verification. This allows the voter to verify that his vote was correctly casted and also allows the analysis of the vote count. In the case of Three-Ballot-based protocol [7], it was chosen because it makes use of three ballots for voting and three ballot boxes, and the most common is to use only one. Sensus Figure 3. Framework modules While others, such as [10] distributes the intelligence of the system between three authorities: one to identify the voter and to issue the ballot, another to verify that the ballot was cast and ensure that each voter submits only one ballot and the last for counting the votes and revealing the results.

C. Framework structure The framework consists of four modules, each responsible for managing an aspect of the voting system, as shown in Figure 3. This division reduces the risk of errors in other modules of the system when performing any change in the framework. 1)Screen Contains the screens that will be used by system users and a layer between the core system and screens. This middle layer is responsible for identifying which methods are available for each system profile, and it is through it that the screens will have access to features implemented. 2)Core The system core is the main part of the framework. It manages the operation of the system. It is also responsible for the election, ballot boxes, disputes, voting options, user authentication and the management of user roles and ballots. 3)Protocols Responsible for various implementations of the protocols that will be used by the elections. They are the heart of the election, being responsible, in large part, by the security of the electoral process. The protocol defines the structure of the ballot and how they will be obtained, how the votes will be counted, how the ballots will be casted, and which cryptographic operations the system will perform during the voting, among other things. You can extend the framework by adding new protocols. 4)Primitives The framework contains several primitives already implemented, and others can be easily added to the system. They will help you compose a new protocol, and key points of its implementation. Often primitive structures are quite complex and its functioning is quite critical. If they do not work properly, the protocol will not work. An example of this is the mixnet, which requires several distributed servers working in a coordinated way. You can extend the framework by adding new primitives. D.Electoral System Behavior There are key stages in the electoral process, such as the period that is allowed to vote and the voting stage where the votes will be counted. A poll consists of 13 states, which can be better visualized in Figure 4. This state machines is included in the framework structure. To launch a poll it is first necessary to register it in the system, an action which is defined in the registered state and that is usually the responsibility of the election administrator. While the election is being registered, it will be available only to the administrator and it is not possible to any other profile to view it. After completion of this step, there are two options: waiting for configuration auditing or not. If it is not awaiting auditing, it can be published immediately, changing to the state published and becoming viewable to all profiles related to that election. In case it is awaiting auditing, after the registration completion the election will be available to the auditors registered in that election in order to check whether the registered data is correct. If all auditors approve its settings, it immediately goes to the state published. If at least one auditor reject its settings, then it should return to the state registered and once again become editable and corrected by the administrator, to then go back to the state waiting configuration auditing, and become noneditable again. These first steps concern the election registration and analysis of its configuration by persons registered in the system. This ensures that the information registered is correct when it is disclosed to the users. When the election goes to the state published, it becomes visible to the voters of that election, so they can check its information such as election title, the election date and other important information. It remains in this state until the start of the voting period, automatically changing to the started state. In this new state the election can receive the votes of the voters, i.e., when the election really starts allowing the voters to get their ballots, to select their voting options and to send the ballot to the ballot box. When the voting period ends, the election goes automatically into state finished, which makes impossible for voters to vote. Figure 4. Election state machine When the election is finished, it is necessary to count the votes, an operation that is performed at the request of the administrator, then changing into the state counted. From this state there are two possibilities depending on whether the election allows result auditing or not. If it does not allow, the administrator can publish your result straightaway, making it available to all users. If the election allows auditing of its result, it goes to the state waiting configuration auditing and remains there until all auditors have examined the proofs issued during the voting phase that prove that the operations have been performed correctly. This step is important to ensure that it did not occured any failures or frauds during the

electoral process, being dependent on the protocol implemented. For example, a protocol that uses network mixture can provide evidence that the shuffle of the ballots took place correctly. If all auditors validate the integrity of the proofs, the results can be published. If at least one auditor rejects them, this indicates that there may have been some error or fraud during the voting, the result will not be published and the election will be terminated. E.Core behavior Besides the logic of the electoral process, there are other mechanisms in the system that work to make the framework flexible and reliable. These mechanisms are within the core package, as well as the election. 1)Authentication Because there are multiple profiles, each has its own defined field of action, which is extremely important to know which events each user is allowed to run. Authentication can be done in different ways and at different times of the voting process. For example, the voter can authenticate himself by using a login and a password, via a valid certificate, a token or by a unique identifier which has been informed to the user. This authentication can also take place at different stages: when the user enters the system, the time they request a ballot or the time they cast a ballot. In the case of the framework it was implemented an authentication by login and password, but is flexible to use other authentication mechanisms. 2)User management The election process can contain different types of users, each with different requirements and obligations. The most common are voters, administrators, auditors, fiscals and register agents who are responsible for registering voters. This is useful to delegate responsibilities and restrict the field of activity of users. You can, for example, create ballot box fiscals, which will shared a key to decipher the ballots. Thus, only when all fiscals act in a shared way, the tally can be initiated. More profiles and its responsibilities can also be added easily. 3)Ballot management Ballots facilitate the voting process, because it contains the disputes and their voting options, and also the options selected by the voter. You can perform various operations with a ballot, such as blinding for blind signature, encryption, signing, storage, etc. The ballot must be a structure flexible enough to allow its use in different ways to meet the needs of each protocol. Hence structure of the ballot is not always trivial, depending on how the disputes and its options are organized and which individual information can be added. To facilitate its creation, a ballot is created and others are copied from the original ballot. If any additional voter data has to be added, like a ballot identifier, it is inserted after the copy. 4)Disputes and voting options The disputes relate to matters which are voted in the election, and which voting options are available for each subject. It was determined that there are two types of disputes, candidates and plebiscite. The framework allows the creation of new types of disputes and voting options without much impact on the rest of the system. Disputes like plebiscites are open questions with simple answers. Another kind of dispute are candidate ones, that requires a complex structure normally required for candidates. For example, the relationship between candidate, party, coalition and slate. 5)Ballot box The ballot box is responsible for maintaining the ballots of a specific election, so only those authorized can retrieve them in the same way as physical ballots. They are kept encrypted by the ballot box, to prevent others from reading without permission. IV. DISCUSSIONS ON EXPERIMENTS RESULTS This section describes the implementation of three protocols, showing what was needed to modify and what was possible to reuse, as well as other aspects of the use of the framework for the creation of digital voting protocols and graphical part of the system. A.Protocols and primitives Three protocols have been implemented using the framework. A simplistic protocol, a protocol that makes use of blind signatures, and a protocol that makes use of mixnet [1]. If the developer wants to change some aspect of the system, they should override the responsible class and implement it following the structure of that class. Below is an example of protocols developed and what classes were necessary to create or override. 1)Simplistic protocol For the implementation of the simplistic protocol it was necessary to override only the Protocol class and two of its methods. From 306 classes in the system, only one was overridden and 2 of its 25 methods were overridden and no new methods were created. Practically all the necessary infrastructure to implement the simplistic protocol is already developed. There is already all the basic structure of a digital voting system, including the administration, voting and presentation results screens. 2)Protocol with blind signature The protocol that makes use of blind signature requires more interaction with the voting system, since it is necessary to blind and unblind the ballot on the user machine. For this it was necessary to implement an applet that perform these operations reliably. To implement the protocol with blind signatures, it was necessary to override the Protocol class and two of its methods, besides being necessary to create three more. It was also necessary to create an applet to blind the voter ballot before sending it to the system to sign. In this case it was necessary to create a different interface with the voter, which was able to perform certain cryptographic operations on the users machine before sending it to the authority in order to increase confidence in the whole process. The reuse in this case remains quite high. From 306 classes in the system, only one was overridden, with 4 of its 25 methods overridden and three new ones were created. Besides, it was necessary to create a new class with three new methods. 3)Protocol with mixnet

The protocol that uses mixnet was implemented so that the network servers were distributed between multiple machines. Before the start of the election, it was necessary to create the mixnet and start the servers. These actions were not required in other protocols. It was also necessary to encrypt the votes with the system key before sending them to the mixnet. To implement the protocol with mixnet it was needed to override the protocol class and two of its methods. There was no need to create new classes or methods. B.System screens The screens are important channels of communication between users and the system. The framework contains the implementation of the main screens that will be used in the voting systems developed, and will allows developers to implement their own when necessary. One of the main screens of the system is the election registration screen used by the administrator. It contains all necessary fields to complete registration for a full election, separated into different stages, as can be seen in Figure 5. protocols implemented, but they may be unnecessary if the protocol requires the voter to download the ballot, check his voting option, and then upload his ballot in the system. Apart from these, there is also a results screen that shows the result of the election and the winner option of each dispute, as shown in Figure 8. Figure 7. Voting confirmation screen There is also an auditing screen, seen in Figure 9, which allows auditors to examine all configurations of the election and issue its opinion. This screen is used when the election is marked as requiring auditing. Every election is liable to have these options selected, which would require the entire process of settings election analysis conducted by the auditors and only then have its information disclosed to the voters. Figure 5. First screen of election registration In the first step, the administrator registers the basic information of an election. After that, you can register disputes, administrators (if there are others besides him), auditors and voters. After entering all the data, it is necessary to view and confirm the inserted information. Figure 8. Election result screen Figure 6. Screen where the voter selects its options Another screen is the one that allows the voter to choose his voting options, as can be seen in Figure 6 and 7. All disputes are presented on the same screen, with their respective options. After the voter has select among the given options, a screen asking to confirm the vote will be shown, and only then, the vote will be counted. These screens were used in the three Besides, there are several others ones used during the electoral process, such as display screens and screens for users and roles registration, etc. All the screens mentioned above were used in the implementation of the three protocols described. C.Core In all protocols implemented it was not necessary to modify the core of the framework, although this does not impossibility its alteration if necessary. For example, if it is desirable to implement another type of dispute that does not fit in the categories defined in the framework or to implement a different

ballot that is not available. The framework is flexible in this regard, being able to implement new protocols easily, but not preventing changes in its structure if necessary. important to have a mechanism that facilitates ideation and development of new systems. The framework was able to show its usefulness through the implementation of three protocols, facilitating the development and evaluation of new systems, and presenting a high degree of reuse. This allows the developer to focus on the most important aspects of development, since the whole structure of a voting system is implemented in the framework. With respect to similar proposals, it proved to be more flexible, more comprehensive and greater reuse. REFERENCES D.Results Figure 9. Auditing screen Through the implementation of the three protocols, it was possible to verify the feasibility of the framework to support the development of electoral systems, as well as to permit a considerable reuse in the development. The three protocols implemented showed a reuse greater than 90%. This does not mean that any new voting system will have an equivalent reuse, but in any case the framework provides the infrastructure needed and allows the definition of new protocols and cryptographic primitives through the specialization of its classes. V.CONCLUSION Because of the importance of digital voting systems and the difficulty in implementing them and evaluate them, it is [1]R. Samarone, Protocolos Criptográficos para Votação Digital, Unpublished master's thesis for mater's degree, Universidade Federal de Santa Catarina, Florianópolis, Brazil, 2002 [2]B. Adida, Helios: web-based open-audit voting, Proceedings of the 17th conference on Security symposium (SS'08). USENIX Association, Berkeley, CA, USA, 2008, pp. 335-348. [3]C. K. Wu, R. Sankaranarayana, "Internet voting: concerns and solutions," Cyber Worlds, 2002. Proceedings. First International Symposium on Cyber Worlds, 2002, pp. 261 266 [4]D. Lundin, Component Based Electronic Voting Systems, In Towards Trustworthy Elections, David Chaum, Markus Jakobsson, Ronald L. Rivest, Peter A. Ryan, and Josh Benaloh (Eds.). Springer-Verlag, Berlin, Heidelberg pp. 260-273. 2010 [5]S. Popoveniuc, P. Vora, "A framework for secure electronic voting", In IAVoSS Workshop On Trustworthy Elections, 2008 [6]J. Helbach, J. Schwenk "Secure internet voting with code sheets," In Proceedings of the 1st international conference on E-voting and identity (VOTE-ID'07), Ammar Alkassar and Melanie Volkamer (Eds.). Springer- Verlag, Berlin, Heidelberg, 2007, pp. 166-177.+ [7]A.O. Santin, R.G. Costa, C.A Maziero, "A Three-Ballot-Based Secure Electronic Voting System," Security & Privacy, IEEE, vol.6, no.3, May-June 2008, pp.14-21, [8]L.F. Cranor, R.K. Cytron, "Sensus: a security-conscious electronic polling system for the Internet," System Sciences, 1997, Proceedings of the Thirtieth Hawaii International Conference on System Sciences - HICSS '97, 7-10 Jan 1997, pp.561-570 vol.3 [9]F. Baiardi, A. Falleni, R. Granchi, F. Martinelli, M. Petrocchi, A. Vaccarelli, "SEAS: A Secure E-Voting Applet System," Lecture Notes in Computer Science pp. 318-329, January 2004 [10]I. Ray, I. Ray, N. Narasimhamurthi, "An Anonymous Electronic Voting Protocol for Voting Over The Internet," In Proceedings of the Third International Workshop on Advanced Issues of E-Commerce and Web-Based Information Systems (WECWIS '01) (WECWIS '01). IEEE Computer Society, Washington, DC, USA, pp. 188-. 2001 [11]J. Heather, D. Lundin, The Append-Only Web Bulletin Board. Guildford, Surrey, UK, University of Surrey, 2008.