Implementation of Electronic Voting System in Mobile Phones with
Android Operating System
1
Eliver Pérez Villegas,
2Gina Gallegos-García,
3Gualberto Aguilar Torres,
4Héctor Flores Gutiérrez
1, 4Universidad Politécnica de la Región Ribereña, Ciudad Miguel Alemán, Tamaulipas, México
2, 3
Instituto Politécnico Nacional, SEPI ESIME Culhuacán, Ciudad de México
ABSTRACT
The evolution of Information Technology (IT) has made possible the development of Electronic Voting Systems and nowadays with the wide-spread of mobile devices, the implementation of Mobile Electronic Voting Systems has been possible. This paper presents the implementation of an Electronic Voting System in mobile phones with Android Operating System. To guarantee the security of data transferred through insecure channels, a mix of symmetric and asymmetric primitives is used alongside with hash functions. The results show that the system can be used as a feasible tool to carry small scale elections since the performance results show acceptable times within a mobile environment.
Keywords: Android, cryptography, electronic voting systems, performance, stages.
1. INTRODUCTION
Since some years ago, different methods, such as the secret ballot method or the punch card systems have been held to carry on electoral processes, proving effective ways of casting votes. Since then and thanks to the fast evolution of Information Technology, electronic voting systems have emerged, which allow a voter to be part of an automated process that can only be possible through Electronic Voting Systems.
There are two kinds of electronic voting systems [1]: local and remote. The local electronic voting system identifies a voter authorizing him the use of a machine in a specific place. On the other hand, the remote electronic voting system does not need for a voter to be in a specific place as he can be in any public place where there is a network connection e.g. Internet.
Both of these systems are used around the world, where a variety of electoral processes take place. Among these kinds of electoral processes can be found the election of a principal, sub-principal, career leader and group leader, in which is possible there exist several problems that delay all the electoral process such as: a voter not being able to be in a specific place to cast a vote or capturing more votes than voters which do not allow issuing reliable results.
One of the most important problems that may delay an electoral process includes the voter availability. Mobile devices can be the solution as they provide the tools needed to carry a remote election without any geographic concerns.
In the mobile environment, nowadays, Android is one of the most popular Operating Systems found on smart
Dalvik Virtual Machine (DVM) [2]. The DVM is optimized for low processing power and low memory environment and uses special byte-code, hence native Java byte-code cannot directly be executed on Android systems.
Every Android application runs its own process environment, in comparison to most Linux or UNIX environments; Android does not provide any swap space. Hence, the amount of virtual memory is governed by the amount of physical memory available on the device [3].
Android can be found almost in any device, a variety of different smart phones are available, making this Operating System as interesting as it is. With all this mentioned, there is a lot to study about Android as it is composed of different mobile devices with notable different hardware architectures.
When developing Android applications they should be fully optimized in its performance since there can be deployed in devices with poor hardware, that with the use of a heavy application it can get the device to freeze or even making it over clock the internal CPU and burn.
In other words, performance is the main goal in an application development. Therefore, inside the voting environment, an Electronic Voting System divides in different entities which are usually: Register, Authentication, Voting and Counting. This way the workload is distributed in four different stages, which together make possible an Electronic Voting System.
In mobile devices the workload should be as small as possible to offer the best performance that can be reached
devices with Android Operating System. The results of this system show that the system can be used as a feasible tool to carry on small scale elections, such as a group leader since the performance results show acceptable times within a mobile environment.
The paper is organized as follows: Section 2 reviews the background. Section 3 presents proposed system and its stages are detailed. Section 4 shows the implementation of proposed system. Made Test are presented in Section 5. In Section 6results are given. In Section 7 conclusions are drawn and in Section 8future work is proposed. Finally, references are listed.
2. BACKGROUND
Electronic voting systems have been used since the 1960s, with the introduction in the market of punch card systems, followed much later by optical scanning systems, the direct-recording electronic (DRE) voting machine and the Internet [4].
Nowadays different Electronic Voting Systems have been proposed, for example, in 2005 [5] came up with the design and implementation of a secure electronic voting system developed in Java (SELES), which uses the Client-Server model. However, some disadvantages were detected. If the Java version installed in the mobile device is not the one required by SELES, it makes the downloading of applets impossible, hence the voter cannot cast his ballot because such applets cannot be seen on the mobile device. In 2009, Ahmad et al. [6] proved how encryption time consumed in a mobile environment using ECDH-256 and AES-128 was not accepted as it took so long. In other words, achieving high security level at a high computational cost is not the solution. The computational cost of a mobile device should be as small as possible since we have to consider its resource limitation just as Yin Qiu mentioned in [7], where it is said that a voting system should afford more expensive computation cost with computers due that they have more power, in comparison to mobile devices, to carry out large processes without affecting the system performance in large scale, which should be as fast as possible.
3. PROPOSED SYSTEM
The proposed electronic voting system defines four stages called: Register, Authentication, Voting and Counting. All of them are based on the Client-Server model and are illustrated in Figure 1:
• Register:
Is in charge of storing and providing access data for each participant, which after this stage can be either a voter or a candidate. Access data include a username and a password that is needed during the Authentication Stage to access the Voting Stage. An Administrative Authority is responsible for the correct functionality of this stage. • Authentication:
In this stage data introduced by a voter are manipulated in order to get access to the voting stage, if and only if they are verified. The Authentication Authority runs under the Android Environment.
• Voting:
The voter cast the vote of its elections and the Voting Authority encrypts the vote and sends it to the Counting Authority. This stage is accessed after the Authentication stage validates the voter.
• Counting:
In this stage the tally of all valid votes that were cast at the Voting stage is gotten. As in the Register stage, an Administrative Authority is responsible for the correct functionality of this stage, although, the Administrative Authority is limited and is not able to modify any content.
Fig 2: Diagram Database 3.1 Client-Server Model
The client/server model describes the relationship between two computer programs, in which one program, the client, makes a service request from another program, the server, which responds such request. The server uses MySQL and an Android device with the use of the required software can get access to allowed information hosted in it. Figure 2 shows the database diagram of data hosted on the server that would be available, although access to it is limited by using MySQL users with limited privileges. 3.2 Cryptography in Proposed System
The system makes use of a combination of cryptographic primitives which include symmetric and asymmetric key algorithms and hash functions that ensure information properties such as: privacy, fairness, receipt-freeness and robustness [8][9][10][11] that are met in the System.
With the use of symmetric and asymmetric primitives and hash functions, the system provides the following security properties:
• Privacy: Ensures the privacy of the vote from any coalition of the authorities, the content of the vote is maintained in secret and secured.
• Fairness: No one is available to know any partial tally before the counting stage. The results may only be available at the counting stage as the counting authority is the only one who can get access to decrypt the votes through the private key. • Receipt-Freeness: It is not possible for a voter to
prove the content of his vote through the receipt generated after voting.
3.2.1 Asymmetric Key Primitive
In order to encrypt and decrypt the votes that will be cast during the voting stage, RSA algorithm is used [12]. Its security is based on the difficulty of factoring large numbers. This asymmetric primitive has a pair of two keys, the public key and the private key. It involves three steps that are: key generation (which occurs at the Registration Stage), encryption (during the Voting Stage) and decryption (at the Counting Stage). The key pairs are generated based on two large prime numbers that must be kept in secret just as the private key. Any encrypted text with one key of the pair, can be decrypted with the other one. If encryption occurs with the public key then it must be decrypted using the private key and vice versa.
3.2.1.1 Blind Signature Primitive
To meet the privacy requirement and loose the connection between the voter and the vote, blind signature based on RSA comes into play. The content of a message is blinded first before it is signed in such way the signer does not now the original content of what he is signing. Blind signatures are typically employed in privacy-related protocols where the signer and message author are different parties [13]. A new key pair is generated aside from the one used in the encryption/decryption phase which occurs at the voting and counting stages.
Asymmetric Key Primitive is important in the systems role as it is responsible for providing the privacy needed. Therefore, it is implemented to grant the privacy, protect user’s elections and it doesn’t affect that much the devices performance once the encryption/decryption keys are loaded in the environment.
and decrypt data. Encryption converts data to an unintelligible form called cipher text; decrypting the cipher text converts such data back into its original form, called plaintext. The AES algorithm is capable of using cryptographic keys of 128, 192, and 256 bits to encrypt and decrypt messages in blocks of 128 bits [14].
AES-256 is implemented on the system to grant the security needed to keep safe the asymmetric cryptography keys that are being generated. The encryption/decryption and blind signature keys are stored in the Database with limited access; however, they are encrypted using AES-256 before being stored on the server. AES-256 uses 256-bits key size and its fast execution is outstanding.
3.2.3 Hash Primitive
Hash functions helped to meet the receipt-freeness requirement. Hash functions implemented on this system is SHA-256 which is able to transform an arbitrary set of data into a unique fixed length value called hash. SHA-256 is used to verify the user authenticity and to provide vote receipts so voters can verify their vote has been received and counted correctly. However, the voter is not able to prove the content of his vote. In other words, is easy to compute a hash value from a vote, as a voter receipt, but it is infeasible to get the original vote given its respective hash value. It means that even if a faulty authority get access to hash values like voter password or vote receipts, hash functions makes it impossible to get the original message with it.
3.3 Stages in Detail 3.3.1 Register
The Register Authority is the one that requires more computational cost due to it is the one that generates all the keys needed to encrypt and sign data in other stages, also in this stage is where registering voters, candidates and administrators is possible. This stage makes use of SHA-256 Hash Function to encrypt users’ passwords. Moreover, in this stage the two asymmetric key pairs are generated alongside an AES-256 key. One asymmetric key pair belongs to the encryption/decryption of the votes while the other key pair is used for blind signatures. After being built, both asymmetric key pairs are encrypted with the AES-256 key that was previously generated, to store and keep them in secret.
The Register Authority is in charge of storing the data for every single participant. Three kinds of participants are possible to be created which include the administrator, candidate, and the voters. An administrator is in charge of controlling the register and counting stages but access is denied for this particular user at the authentication and voting stages. The candidate is who the voters are choosing for a specific election. The voters can cast a vote only once per election and for a singular candidate. The vote is being
cast at the Voting stage after accessing through the Authentication stage.
Data stored for each participant include: full name, ID number, group, type of participant, username, and password. It is important to mention that although personal data of participants are stored, blind signature primitives eliminates all relations within the voter and the vote. It means that it does not matter that the system keeps personal data because the vote content is private and cannot be linked with the voter.
Every participant should identify with the administrator in charge to register and get his access data that is needed in both Authentication and Voting Stages to go through all the election process. When a user is added to the system, first it verifies for duplicate registries that use the same ID numbers or usernames/pseudonyms. If a duplicate file is found, then the problem must be solved in order to continue and register the participant, which can be solved by either entering another value in the box that requires it. Once all the input data have been verified and validated, and when the register of participant is asked for, the input password is transformed using the Secure Hash Algorithm SHA-256 and all data is transferred to the server and stored.
In case the participant registered is a candidate, the system should verify if there is an active election, otherwise, a new one must be started in order to register that candidate. When a new election is being started, both asymmetric key pairs are generated with a 2048-bits key size. Also a new key is generated for AES-256 using a salt factor and a passphrase that depends on a timestamp with millisecond precision, providing more efficiency at the building of the keys. Once that all the keys are generated the new election is started, private keys are encrypted and stored. Moreover, the new candidate is linked to the election that he belongs.
3.3.2 Authentication
Voters are asked to input their access data, which were registered during the Register stage to verify their eligibility in the election. The input username should be located on the records, if it is found, then the SHA-256 hash value of the input password is compared with the one linked with the username stored in the server. If values match, then the user is authentic. The existence of an active election is verified otherwise authentication is interrupted and cannot proceed to the Voting stage. If there is an active election then the system checks for the user type, if it is a candidate or an administrator trying to login to the system with their access data and not a voter, then access is denied for such particular user. If the voter has already cast a vote then access is denied meeting the unreusability and individual verifiability requirements by not allowing multiple votes from any voter, otherwise if that particular voter is not
authenticated in another device at that moment access to the voting stage is granted.
3.3.3 Voting
When a candidate is selected and the vote is cast then encryption occurs using the encryption asymmetric key and hash function SHA-256. The encryption asymmetric key is used in combination with the plain text. A blind factor is applied to blind the already encrypted vote then the voting authority signs the message for its later storage. The signed message plus a timestamp of the cast vote generate a receipt using the Secure Hash Algorithm SHA-256 that proves the participation of a particular voter in the election. 3.3.4 Counting
In the last stage the counting of all votes is made, every single cast vote is decrypted and verified using blind signature verification based on RSA. All votes that were cast should be validated and the final result must be the same as the sum of all votes validated.
No results of the tally can be shown before counting all votes. Once the votes are counted, the active election ends and results are shown. Votes remain in the system until they are manually deleted for a future tallying. In such way that no one results of the tally can be shown to anyone before counting all votes. It is important to mention, performance of the system in this stage depends on the number of votes that were cast in the voting stage.
3.4 Administration Area
An Administration authority has been included to check for the correct behavior of all the system. The Administrative authority have access to add, edit or delete groups; modify participants’ personal data, and in case it is needed, get access to elections history records. They can get the tallying of an election whose votes are still stored in the server, or permanently eliminate those votes even though the results history will remain. A log is kept to secure the system and prevent the bad use of faulty authorities. Even though administrative authorities have access to elections data, available data is limited. Moreover, they cannot see any content of votes stored on the server nor change the content of them.
4. IMPLEMENTATION
The complete functionality of the system and integration of all stages is shown in this Section. Android 2.2 Froyo is the minimum OS required to load this app on the mobile device.
4.1 Implementation
system. Both register and counting authorities afford more expensive computation cost at the expense of making as small as possible the workload on mobile devices, which implement the authentication and voting operations.
4.1.1 Bouncy Castle
To achieve the implementation of the system, symmetric, asymmetric primitives and hash functions are used with the help of the Bouncy Castle cryptographic provider [16], which is a vital element to supply free cryptographic libraries for Java.
4.1.2 Threads
The use of threads is a vital part of the Authentication and Voting stages. Threads execute operations in the background at the sight of no one and are reached with the use of Android services. Android services are classes without a User Interface (UI) that can be executed in the background. In the Authentication stage just after the log in of a user, a thread runs to execute a query to the Database and grab the information of the active candidates and the asymmetric keys which are still encrypted with AES.
The information is given to the Voting Authority which displays the candidates while another thread is active decrypting the keys for the later use.
Threads are very important in the systems performance due to the voter is not able to see that kind of operations, also as the execution occurs in the background the systems performance time is optimized, by the time the voter makes an election all the keys are already loaded and ready to make use of them.
If for any reason the voter closes the Android application another thread runs, logging out the user and deleting all the voting systems data from the mobile device. When the user opens the application, a new authentication will be required.
4.1.3 Android Intents and Activities
The Authentication and Voting stages are both made-up of a Graphic User Interface (GUI) or Activity [17] in the Android mobile device. Activities are the classes in Android which have a User Interface (UI) and are needed to make the screens to show the user applications.
On the other hand, Intents are used to transfer data through Android activities. In the system, intent is required to carry the correct voter data from the Authentication activity (packs all data in intent) all the way to the Voting activity (unpacks the data in the intent).
participated in the Authentication and Voting Stages: Xperia Play, Optimus 3D, Samsung Galaxy Ace and the Android emulator running on a Windows 7 computer were involved.
5.1 Registration Stage Test
The register stage is composed by a Graphic User Interface (GUI) and a set of fields and combo box to fill in all information of participants that are going to be registered. This information includes participants’ full name, ID number, group, user type, username/pseudonym and password.
In this stage a set of 3 candidates and more than 100 voters were created to test the functionality, the system performance was not affected with the creation of the users and population of the database records. Performance results of the Registration stage are available at section 4.6.
Figure 3 shows the functionality, when the register button is pressed after registering the first candidate. Creating the first candidate implies starting a new election, the new key pairs are generated and the hash value of the candidate’s password is stored in the server with the entire candidate’s personal information.
Fig 3: Register Stage Test. 5.2 Authentication Stage Test
The authentication stage is made-up of an activity inside the Android mobile device. In this activity the voter has to identify itself with his/her access data that were registered in the Register stage. Once the voter is validated the system can load the next task and continue with the process of the voting system.
In this stage 4 different devices participated at the same time to test the thread functionality, as MySQL is multi-thread it did not cause any problem with the authentication of four different users simultaneously.
While authenticating with two different devices, an error was detected, if the voter was logged in another device but had not yet cast his vote it was possible to log in again being able to cast more than one vote, catching the voter activity status once it logged in from any device solved the validation issue, not admitting any voter to log in from two or more devices at the same time.
Figure 4 shows the tests made with the authentication activity, a user is authenticating. All authentication process occurs in the background.
5.3 Voting Stage Test
The voting stage is another activity that runs on the Android mobile device; it cast the vote of a voter. A set of candidates linked with the election is displayed on the mobile screen and the user should be able to select one and choose to cast his vote.
Once the voter has been identified during the Authentication stage the Voting activity is loaded and some information is received for this stage to display, just as it can be appreciated in Figure 5. The figure illustrates a vote cast from a voter election; the vote is being encrypted and transferred. All the process was executed as a service.
The tests made at the Voting stage included four mobile devices with Android Operating System, the cast of four votes at the same time showing positive results, the votes were cast without affecting either the data sent or the systems performance.
MySQL being a multi-thread database system help in the whole operation, letting all the devices cast the votes simultaneously.
Fig 5: Voting Stage Test. 5.4 Counting Stage Test
A Graphic User Interface with the information of the candidates is displayed during the Counting stage. When the “Count” button is pressed, the election automatically ends. Votes’ signatures are verified and decryption occurs just before starting the count of the votes and displaying final results. Votes still remain stored for later tallying but that particular election cannot be modified any more.
In the Counting stage 99 votes were cast to prove that the system functionality was acceptable, it did throw possible results in performance issue. After counting the votes, the system did move the votes to a temporary table and votes for the election could not be cast any more. Figure 6 shows the results of an election using the counting stage.
Fig 6: Counting Stage Test.
6. RESULTS
The system was tested in a group leader election inside a university, to test the results and verify if it is feasible using the system in a mobile environment to carry this type of elections.
Mid and high range mobile phones with different Android Operating Systems versions were used to prove the feasibility of utilizing the electronic voting system in this kind of mobile devices showing acceptable results.
The system performance is based on leaving the least computational cost to the mobile devices to have the fastest execution time as possible. The use of cryptographic primitives to encrypt data makes it difficult to cheat in the process even if an administrative authority intends to do so, meeting robustness. In comparison with traditional electoral processes the mobile system is definitely faster and does not suffer of a lack of control like getting more votes than participants that are registered providing a more efficient voting method. Moreover, it has the great advantage that the vote can be cast from any place where the voter is located just by having access to a public network; the mobile system also provides privacy, fairness and robustness with the use of symmetric and asymmetric primitives, receipt-freeness is met with the use of hash functions, all of this while maintaining acceptable performance results, making it suitable for an election environment.
Table 1 shows the performance time (in milliseconds) of the Registration Stage in which it realizes activities such as creating a new election, which includes adding a new candidate. It is important to remark that in this action is where all cryptographic keys are generated. Also adding a new participant or editing an existing record execution time is listed on the table, due to all the previous action listed, adding a new election is the process that takes the longest and is going to be executed only once per election inside the Register Authority that should be linked
with the server. The mobile device does not participate in the Register Stage due to the computational cost that it may imply when asymmetric and symmetric keys are generated.
Table 2 shows the execution time of the Authentication Stage to start and authenticate a voter, validating all the data needed to grant access before entering the Voting Stage. Also execution time to gather candidate and cryptographic keys from de Database is listed on the table.
Table 3 presents run time of the Voting stage (in milliseconds) using four different devices (also used in the authentication stage): the Android emulator running on a Windows 7 computer, an Xperia Play, an Optimus 3D and a Samsung Galaxy Ace. The results of the Voting stage include gathering the information from the Database, encryption of votes and generation of vote’s receipts.
Finally, Table 4 has the information of execution time to start and execute the counting of an election, which include decryption and signature verification of votes, display of results and end of the active election.
As seen the performance results, the Register Stage is the one whose work is heavier. Starting a new election can be seen that is the process that takes the longest while the adding participants function is way smaller.
During the Authentication and Voting Stages it depends on the hardware of the mobile device working. The emulator has to start and work with the entire Android Operating System on the computer, making the workload heavier and providing a more poor performance compared to Android devices.
Inside the Voting Stage, performance time depends upon the mobile device but also on the key size used. As the
key size increments the performance decrements, but as shown on the results the system development was optimized in a way that the key size doesn’t makes a big impact in the systems’ performance.
At the Counting Stage the performance results shown were proved working with 99 votes that were cast. The system performance in this stage depends upon the number of votes, even though the difference is not too big. Obtaining the keys is the action that takes the longest during this stage.
Due to the results it can be remarked that the system is able to be used in a small scale election without any concerns of performance or security problems.
Table 1: Registration Execution Time
Activity Time (milliseconds)
Start 47 New Election 3986 New Participant 951 Edit record 487
Table 2: Authentication Execution Time
Activity Emulator Xperia
Play Optimus 3D Samsung Galaxy Ace Start 285 65 30 210 Authenticate 1560 437 497 567
Table 3: Voting Stage Execution Time
Activity Emulator Xperia Play Optimus 3D Samsung Galaxy Ace Start 285 65 30 210 Vote (512-bits) 1066 267 302 331 Vote (1024-bits) 1289 286 250 261
Table 4: Counting Execution Time
Activity Time (milliseconds)
Start 46
Count 1908
7. CONCLUSIONS
Data transferred over a network may be considered unsafe, more over a public network like the Internet. Nowadays, encryption of data being transferred over unsafe channels is a critical part of communication, anyone can intercept the messages sent over insecure channels, but with the help of cryptography, third party entities receive encrypted data before being decrypted to plain text by the receiving authority, this makes it impossible for them to know the content of the original message that was sent before being encrypted.
Proposed system makes use of different mechanism to provide the security needed meeting: privacy, fairness, receipt-freeness and robustness, and achieving the goal to provide elections in a small environment like a university such as choosing a group leader, presenting reliable options to modify the traditional election process. Generating new cryptographic keys per election makes the system even safer as the keys are only valid while the election is still active, this means that if the election ends and a new one is starting, an attacker must start crypto analysis processes all over again to obtain the keys and be able to infringe the system’s security. In comparison to those systems which the keys are defined as static inside the code and were not changed in a good time, proposed system provides dynamic keys for each election.
Even though the cryptographic primitives used may imply some high computation cost, the system’s performance prove reliable results with fast execution times (shown in Section 4), which proves that the system can be used as a feasible tool to carry on small elections with performance acceptable times within a mobile environment. Moreover, it does not suffer of a lack of control during executing different operations such as: deleting votes, overwriting them, among others, due to there is not an option to delete the votes while the election is still active meeting robustness because neither a voter nor a candidate is able to manipulate the votes already stored.
8. FUTURE WORK
election they may have access to. In addition to that it would be interesting to meet other cryptographic primitives and make comparison between them and the ones already implemented on the system, or use other cryptosystems that have been proved to be secure and their performance has been widely accepted, like Elliptic Curves Cryptography (ECC). In this way the runtime environment of each cryptosystem used can be compared. Moreover, it would be interesting to implement a biometric authentication stage to increase the security and granting another security level as it would be more difficult to bypass the systems authentication. Biometric authentication can provide more security to the mobile electronic voting system, making it harder for malicious to compromise the system.
REFERENCES
[1] D. JordiPuiggali, “Voto Electronico”, Scytl Secure Electronic Voting, pp. 9 – 33.
[2] Bornstein, D., “Dalvik VM Internals”, Google I/O Developer Conference, 2008
[3] Heger, D., “Quantifying IT Stability – 2nd Edition”, Instant Publisher, 2010
[4] Electronic Voting Systems, ACE Project – The Electoral Knowledge Network, [online] 2013, http://www.aceproject.org (Accessed: May 19, 2013) [5] García Zamora C, “Diseño y Desarrollo de un
Sistema para elecciones Electrónicas Seguras (SELES)”, Centro de Investigación y Estudios Avanzados del Instituto Politécnico Nacional Unidad Zacatenco, México D.F., 2005.
[6] T. Ahmad, J. Hu, S. Han, “An Efficient Mobile Voting System Security Scheme based on Elliptic Curve Cryptography”, Third International Conference on Network and System Security, pp. 474 - 479.,2009
[7] Y. Qiu, H. Zhu, “Somewhat Secure Mobile-Eletronic-voting Systems Based on the Cut-and-Choose Mechanism”, International Conference on Computational Intelligence and Security, pp. 446 - 450., 2009
[8] A. Fujioka, T. Okamoto, K. Ohta, “A practical secret voting scheme for large elections”, in Proc. AUSCRYPT’92, pp. 244-251.,1992
[9] A. Huszti, “A secure electronic voting scheme”, Faculty of Informatics, University of Debrecen, 2009.
[10] O. Baudron, P. Fouque, D. Pointcheval, J. Stern, and G. Poupard, “Practical multi-candidate election system”, in Proc. 20th
[13] D. Chaum, “Blind Signatures for Untraceable Payments”, In Proceedings of Crypto 82, pp. 199 - 203, Plenum Press, New York, 1983.
[14] Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197. Computer Security Division.National Institute of Standards and Technology.
[15] Eclipse – The Eclipse Foundation open source community website, Eclipse IDE, [online] 2013, http://www.eclipse.org (Accessed: March 29, 2013) [16] The Legion of the Bouncy Castle Java Cryptography
APIs, The Legion of the Bouncy Castle, [online] 2013, http://www.bouncycastle.org/ (Accessed: March 21, 2013)
ACM Symposium on Principles of Distributed Computing (PODC’01), pp. 274 – 283, New York, USA,2001.
[11] G. Gallegos-García, R. Gómez-Cárdenas, G. I. Duchen-Sanchez,“Identity based Threshold Cryptography and Blind Signatures for Electronic Voting”. WSEAS Transaction on Computers. Issue 1, Vol 9, pp: 62 – 71, January 2010.
[12] R.L. Rivest, A. Shamir, and L. Adleman, “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”, Communications of the ACM 21, pp. 120 – 126, 1978
[17] Activity | Android Developers, Android Developers,
[online] 2013,
http://developer.android.com/reference/android/app/ Activity.html(Accessed: May 21, 2013)
