Universidad Politécnica de la Región Ribereña, Ciudad Miguel Alemán, Tamaulipas, México
Instituto Politécnico Nacional, SEPI ESIME Culhuacán, Ciudad de México
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.
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
: 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.
Dalvik Virtual Machine (DVM) . 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 .
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
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.
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 other words, performance is the main goal in an
application development. Therefore, inside the voting
environment, an Electronic Voting System divides in
which are usually:
Authentication, Voting and Counting. This way the
workload is distributed in four different stages, which
together make possible an Electronic Voting System.
In the mobile environment, nowadays, Android is
one of the most popular Operating Systems found on smart
In mobile devices the workload should be as small
as possible to offer the best performance that can be reached
without affecting the systems’ security.
Android systems utilize their own Virtual Machine
(VM), a modified Java Virtual Machine (JVM) known as
With the aforementioned, this paper presents the
implementation of an Electronic Voting System in mobile
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.
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 .
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.
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.
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.
Nowadays different Electronic Voting Systems
have been proposed, for example, in 2005  came up with
the design and implementation of a secure electronic voting
system developed in Java (SELES), which uses the ClientServer 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.  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
, 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
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.
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:
Fig 1: Proposed System’s Scheme
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, receiptfreeness and robustness  that are met in the
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.
Robustness: The system is capable of tolerating
faulty authorities. Cryptography primitives used
makes it impossible to cheat.
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 .
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.
184.108.40.206 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 . 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.
3.2.2 Symmetric Key Primitive
The Advanced Encryption Standard (AES) is an
approved cryptographic algorithm that is used to protect
information. It is asymmetric block cipher that can encrypt
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 .
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
3.3 Stages in Detail
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 SHA256 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
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
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
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.
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.
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.
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.
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.
The Register and Counting stage are both
developed on Java just as the Authentication and Voting
stages that were also developed on Java but to work on the
mobile devices with Android Operating System. Eclipse
IDE  was used to simulate all the electronic voting
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 , which is a vital element to supply free
cryptographic libraries for Java.
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 
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).
More than 100 voters and 3 candidates were used
for the entire voting process. Four different mobile devices
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
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
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
MySQL being a multi-thread database system help
in the whole operation, letting all the devices cast the votes
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
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, receiptfreeness 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 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
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
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
Table 2: Authentication Execution Time
Table 3: Voting Stage Execution Time
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
Possible Future work may involve handling more
than one election at the same time due to this
implementation of the system is capable of running just one
election at a time, therefore there is the option of modifying
the code so that more than one election can be handled
simultaneously, giving the participants access to which ever
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.
A. Fujioka, T. Okamoto, K. Ohta, “A practical secret
voting scheme for large elections”, in Proc.
AUSCRYPT’92, pp. 244-251.,1992
A. Huszti, “A secure electronic voting scheme”,
Faculty of Informatics, University of Debrecen,
O. Baudron, P. Fouque, D. Pointcheval, J. Stern, and
G. Poupard, “Practical multi-candidate election
system”, in Proc. 20th ACM Symposium on
Principles of Distributed Computing (PODC’01), pp.
274 – 283, New York, USA,2001.
G. Gallegos-García, R. Gómez-Cárdenas, G. I.
Cryptography and Blind Signatures for Electronic
Voting”. WSEAS Transaction on Computers. Issue
1, Vol 9, pp: 62 – 71, January 2010.
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
D. Chaum, “Blind Signatures for Untraceable
Payments”, In Proceedings of Crypto 82, pp. 199 203, Plenum Press, New York, 1983.
Advanced Encryption Standard (AES), Federal
Information Processing Standards Publication 197.
Computer Security Division.National Institute of
Standards and Technology.
Eclipse – The Eclipse Foundation open source
community website, Eclipse IDE, [online] 2013,
http://www.eclipse.org (Accessed: March 29, 2013)
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)
D. JordiPuiggali, “Voto Electronico”, Scytl
Electronic Voting, pp. 9 – 33.
Bornstein, D., “Dalvik VM Internals”, Google I/O
Developer Conference, 2008
Heger, D., “Quantifying IT Stability – 2nd Edition”,
Instant Publisher, 2010
Electronic Voting Systems, ACE Project – The
Electoral Knowledge Network, [online] 2013,
http://www.aceproject.org (Accessed: May 19, 2013)
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.
T. Ahmad, J. Hu, S. Han, “An Efficient Mobile
Voting System Security Scheme based on Elliptic
Conference on Network and System Security, pp.
474 - 479.,2009
Y. Qiu, H. Zhu, “Somewhat Secure MobileEletronic-voting Systems Based on the Cut-andChoose Mechanism”, International Conference on
Computational Intelligence and Security, pp. 446 450., 2009