Bilkent University
Department of Computer Engineering
Senior Design Project
SmartVote: Electronic Voting System for Smartphones
Final Report
Ahmet Eren Başak, Atalay Mert Ileri, Cem Orhan
Supervisor: Can Alkan
Jury Members: Uğur Doğrusöz and Ibrahim Körpeoğlu
Final Report
April 30, 2014
This report is submitted to the Department of Computer Engineering of Bilkent University in partial
fulfillment of the requirements of the Senior Design Project course CS492.
İçindekiler
Table Of Figures ....................................................................................................................................... 3
1.
Introduction ..................................................................................................................................... 4
2.
Final Architecture and Design ......................................................................................................... 4
2.1.
Overview.................................................................................................................................. 4
2.2.
Subsystem Decomposition ...................................................................................................... 5
2.2.1.
Model .............................................................................................................................. 5
2.2.2.
View ................................................................................................................................. 7
2.2.3.
Controller......................................................................................................................... 9
2.3.
Object Model ......................................................................................................................... 12
2.4.
Hardware/Software Mapping ............................................................................................... 14
2.5.
Persistent Data Management................................................................................................ 15
3.
Final Status .................................................................................................................................... 16
4.
Impact of Engineering Solutions.................................................................................................... 16
4.1.
Global Impacts ....................................................................................................................... 16
4.2.
Economic Impacts.................................................................................................................. 17
4.3.
Environmental Impacts ......................................................................................................... 17
4.4.
Social Impacts ........................................................................................................................ 17
5.
Contemporary Issues ..................................................................................................................... 18
6.
New Tools and Techniques Used................................................................................................... 19
7.
Software/Hardware System .......................................................................................................... 19
8.
User's Manual ................................................................................................................................ 19
9.
8.1.
Client...................................................................................................................................... 19
8.2.
Server..................................................................................................................................... 21
References ..................................................................................................................................... 22
2
Table Of Figures
Figure 1: Subsystem Decomposition ....................................................................................................... 5
Figure 2: Model Subsystem ..................................................................................................................... 6
Figure 3: View Subsystem........................................................................................................................ 8
Figure 4: Controller Subsystem ............................................................................................................. 10
Figure 5: Tasks subsubsystem ............................................................................................................... 11
Figure 6: Complete Object Diagram ...................................................................................................... 13
Figure 7: Deployment Diagram ............................................................................................................. 15
3
1. Introduction
SmartVote application enables a virtual referendum environment, so that every voter can vote with
smartphones, instead of going a referendum cabin and waiting for queues. In modern democracy,
what is controlling the country is the opinion of the masses and their rightfully elected
representatives. For granting those issues, the two main component of a democratic regime is
elections and referendums. Masses vote for elections for their representatives periodically (unless
there is state of emergency) and vote for proposed laws in referendums. Today, those issues are
done by going to voting cabin, voting papers and stamps; and the votes count by people one-by-one.
Our application aims to remove the manual issues in the whole referendum process by enabling the
referendums on virtual environments, in our case voters can vote by their smartphones, and
centralized software that leads throughout the process. All the authentications which are done
manually before will be virtualized; the authentication of voters, getting an approved vote right,
casting a vote, calculating the results, privacy of votes and guarantee of the correctness in
referendum will all be done virtualized.
SmartVote application is a core system which includes the cryptographic protocols, main control flow
of data, and a custom designed database. Since every platform that runs with democracy
(governments, non-governmental organizations …etc.) uses different types of authentication in terms
of its members (unique citizenship number for Republic of Turkey, unique student id for Bilkent…etc.)
we decided to implement a core application which contains the generic requirements. By doing so,
we will easily modify our application for different platforms by adding appropriate modules. We
decided to implement modules for Bilkent University referendums in order to demonstrate our
application.
In this report, we will explain the final architecture and design, final status of the report, the impact
of the solutions, contemporary issues on electronic voting, new tools and techniques that we used,
SW/HW system and we will provide a user's manual for using the mobile side and installation issues
on the server side.
2. Final Architecture and Design
2.1.
Overview
In this section, the final architecture of SmartVote Voting System will be explained from the
perspective of subsystem decomposition, object modeling, hardware-software mapping and
persistent data management.
4
2.2.
Subsystem Decomposition
The client application of SmartVote is decomposed into three subsystems, following the Model View
Controller design pattern [Figure 1]. The view subsystem is responsible for representation of the data
to the user, receiving user input and delivers the data to the controller subsystem. Model subsystem
represents the data concerned in SmartVote. Controller subsystem manages the program flow, data
flow between view and model, handles communications and asynchronous calculations.
Figure 1: Subsystem Decomposition
2.2.1. Model
Model subsystem represents the domain data of SmartVote. Referendums, referendum options,
groups, users and invitations are modeled in individual classes in an object oriented fashion[Figure
2]. Additionally, temporary objects used for storing and transfering data in a structural way, such as
LoginInfo and Statistics exist in this subsystem. The DataManager class is the facade of the subsystem
so that Model subsystem provides its services through a DataManager object.
5
Figure 2: Model Subsystem
6
2.2.2. View
View subsystem consists of individual Activity classes for each screen of the application as well as
graphical user interface parts[Figure 3]. Individual Activity classes are extended from the abstract
SmartVoteActivity class, which is based on Android's Activity class and provides a general interface
for other SmartVote activities. ProgressActivity interface is used as a contract for activities that
require some network traffic for representing data. The fascade of this subsystem is GUIController
class, which controls data flow between the controller subclass and individual activities.
7
Figure 3: View Subsystem
8
2.2.3. Controller
Controller subsystem consists of individual manager classes that are responsible for network
communications, program flow, cryptology and authentication. Additionally, the exception classes
that represent unsuccessful communications with the server are included in this subsystem. [Figure
4]
Controller subsystem contains a subsubsystem called tasks. Tasks subsystem consist of classes that
are responsible for handling individual asynchronous network communication tasks and updating
user interface according to the state of the communication.[Figure 5]
9
Figure 4: Controller Subsystem
10
Figure 5: Tasks subsubsystem
11
2.3.
Object Model
The object model represented in [Figure 6] consists of the three subsystems described in the paper in
previous sections with classes that form the subsystems and associations between them.
12
Figure 6: Complete Object Diagram
13
2.4.
Hardware/Software Mapping
Our project is technically a client-server application, so it has Android app on client side, and server
applications that are used for cryptographic functions, database and administrative applications are
on server side.
On client side, we have an Android smartphone that has our application is installed. This application
has its own subsystems that are explained in the previous section, and interacts with the server side
when necessary.
On server side, we have a main server that has responsible for taking care the database and web
server application, and we have mixer servers, counter servers and an authority server for
cryptographic functions. Authentication provider is wherever the users are registered (e.g. STARS in
Bilkent case), and admin server is for administrative issues on application. Mixers, counters and key
server must be installed on different servers, and there should be at least three servers for each of
them for the sake of the application. In ideal world, our application needs many mixers and counters
for mixing and counting the encrypted votes.
A detailed explanation on nodes can be found below:
Android Smartphones, which will contain the Android voting application of the project which allows
users to vote, see voting results and do group operations.
Web Servers, which will hold the web voting application of the project so that the users will be able
to connect to these servers from their web browsers and use the web application to vote, see voting
results and do group related operations.
Administration Server, which will hold the Admin components of the project and be used by the
system administrator in order to manage system settings.
Authentication Server, which will contain the authentication provider component so that user
identity information will be served to the project from this node in order to authenticate the users.
Database Server, which will hold the main database of the project containing the group information
and encrypted votes.
Mixers, which will contain the mixer component of the project. Mixers will be used to mix the votes
in the Database Server and their number can be determined at any time. Note that each mixer will
mix the order of votes from start to finish and this implies that large number of mixers would provide
better privacy.
14
Counters, which will contain the counter component of the project. Counters will be used to count
the votes stored in the Database Server and mixed by the mixers. The counting process can be
parallelized which means as the number of counter nodes increase, the counting process will become
faster.
Key Administrator, which will contain the Key Administration module. Key Administrator will hold
and provide necessary encryption keys and certificates to mixers, counters, database manager and
the authentication provider.
Figure 7: Deployment Diagram
2.5.
Persistent Data Management
Our application needs to use persistent data, so we implement a database server. In this database
server, we keep referendum information, both open and closed. We use MySQL for database
purposes, and a C program checks the database for referendums to close referendums which are
expired by the time constraint which is entered when the referendum has opened.
15
3. Final Status
Front end development: We completed 90% of the front end issues.
Backend development: We completed 70% of the back end issues.
Integration: Our application integrity is 20% completed.
Tests: At this point, we have done 50% of the test phase.
User Interface improvisations: For this task, we achieved 20% completeness rate.
4. Impact of Engineering Solutions
4.1.
Global Impacts
SmartVote project will change the way of elections. Currently, elections are done in a manual
fashion, hence voters need to go to a voting cabin and then put their vote to a chest. After voting
process is finished, the people that are responsible for controlling that specific chest of the voting
district start to count the votes. Every vote opens one by one, and results are written to a paper.
Then, all that papers are summed up for the voting district, which determines the result.
The cryptographic functions of our application work the same way. Throughout the voting process
encrypted votes are collected, after that they are mixed in mixing server. When mixing is completed,
counting process starts; then the results are served to users. Like the real-life elections, a referendum
in our application has a time constraint that is determined by the user at the opening process of the
referendum. And again, like the real-life elections, one cannot link a vote to its voter, hence the
privacy of voters is guaranteed without sacrificing the robustness and accurate computation.
Whole world is digitizing nowadays, we have internet of things concept that connects devices
through internet, social media and things like those are gaining more and more importance through
the time. Besides these facts, democracy and representation of citizens do not lose any importance
and in reverse, those concepts are also gaining importance while the people of earth realizing their
importance. Combining these two facts, our application promises a new, good and improved future
for the masses.
Referendums and elections are things that cannot be occurred so frequently, because of stability and
economic issues. But with our application, voters and governments are communicated in such a way
that direct democracy can be applicable. We are providing a platform that opinions of masses can
easily be accessed so that whole country will be a more democratic place. And since our platform is
16
scalable to different type of communities, from the little municipalities to the whole country, every
square meter of the country will be joining to this expanded democratic system.
Not only the country, but also small groups and communities can use our application with the power
of grouping feature in our project. This little referendums and elections between these communities
improve the democratic behavior and the belief in democracy. With the people are more caring in
this aspect, we will live in a more civilized society; hence this project has the power of making the
world a better place.
One temporary problem can be the internet accesses and smartphone usage in world, but
eventually, since they are increasing very fast, we can utilize our application with accessing every
person in the society/country. SmartVote promises the future for masses in terms of democracy.
4.2.
Economic Impacts
SmartVote comes with its improvements in economy. The simplest impact is the waste of papers and
human power in manual elections are removed by our application. In manual elections and
referendums, voting papers are used for casting a vote, and human source is used for counting the
votes as well as verifying the voter as a legitimate voter. SmartVote removes all of these wastes;
therefore we both save papers and trees, human power and their cost for the government. Hence,
SmartVote promises a significant improvement in terms of removing the referendum costs.
SmartVote needs online servers to be able to operate, so server cost can be counted as main cost of
our project, besides this, the Android app will be free to download, no cost is applied to citizens.
4.3.
Environmental Impacts
Doing elections/referendums electronically has two important benefits for the environment. First of
all usage of voting papers are removed from the picture, hence we are saving the nature in this
aspect. The second benefit is the rising care to nature by citizens nowadays, and our application
provides what is needed to people to be able to change things by their opinion. So referendums can
be done for nature and people related issues, hence people can find a place to say their words to
save the nature.
4.4.
Social Impacts
Main social impact of the project is that it improves the democratic behavior starting from small
masses to bigger ones by applying it to daily life of people. With a referendum application on their
mobile devices, people can ask opinions of each other more frequently; this leads people to care
each other more through the time. Starting from a little community, by the time passes, in the bigger
17
picture all citizens will be more democratic, since the democracy is not a once in four year thing
anymore. In overall picture, our application will bring the democracy to people’s hands.
5. Contemporary Issues
Voting techniques are divided into three different approaches: paper-based electronic voting system,
direct-recording electronic (DRE) voting system, public network DRE voting system[1]. Paper-based
system is the old-fashioned way with the paper ballots that voters go in a voting cabin, use their
paper ballots to cast their vote and put the vote in a closed manner to a chest. After voting process is
finished, votes are counted and results announced. Besides the well-known standard voting, Ronald
Rivest from MIT has developed a different voting method which he calls “The Three Ballot Voting
System”[2].
DRE voting system is one level more technological than this method, since it uses kiosk like special
voting machines, users again go to the cabin and cast their vote via this machine[1]. This system is
currently used in the world like the paper-based one[3]. There are researches on this type of voting
for improvement, one of them is Bingo Voting[4].
What we want to achieve with this project is the third one, which uses public network to transmit
ballots. There are available applications developed for this purpose, one of them is Helios Voting[5],
another one is called “Adder” system[6]. Both systems are trying to achieve what we are trying to do.
There is a debate going on about the electronic voting issues, people seems that they have not made
up their mind about electronic voting. There are arguments in against and in favor of electronic
voting. One of the against sites has this words on it: “We, the people, should reject electronic voting
and pretend to use ballot papers publicly hand-counted, because this is the only way we can verify
that results are fair and square.”[7] Besides that, Stanford University has a website that contains
both arguments in against and in favor[8].
Hence we can say that there is no clear public opinion about electronic voting, but this point has no
effect on developing such systems. People are trying to find good, secure and efficient ways of
electronic voting, because it seems that may be we will not but probably our children will use such
systems by the expanding use of smartphones and internet.
18
6. New Tools and Techniques Used
For our client side application, we used Android SDK, to develop, test and build our application.
Android SDK has the necessary libraries and development tools for our purpose. We used Eclipse IDE
with ADT (Android Development Tools) bundle as our development environment for client side code.
For the server side application, we used PHP and C as programming languages. Database server, web
server and administrative server is written with PHP; as mixer, counter and key authority is written
with C programming language. Database is established with MySQL.
We used Amazon EC2 cloud services for creating and using servers for our server side applications.
We create separate Ubuntu machines for mixer, counter, authority and main server. And with
Amazon’s easy-to-use cloud services, we created what we wanted as we wanted and configured the
servers according to our needs.
For server side programming, we used two special libraries for C code; we use libgcrypt for
implementing the cryptographic functions, and gnutls library for implementing secure
communication between servers.
7. Software/Hardware System
Our project is working on Android based mobile devices in terms of client side. Hence, we need
mobile devices which have Android OS installed on it, and our client application downloaded and
installed. To run the server side, one needs at least one server for each mixer and counter, a server
for key authority, one server for database and web client (which is the main server).
The preferred OS for the servers is Ubuntu 12.04 LTS, we installed that distro to our cloud servers.
8. User's Manual
8.1.
Client
For client side of the application, there are various options that a user can use.
At the first run, the Welcome Screen will greet the user. The next screen is the authorization screen,
which requires the user to log in with the Stars id and password. After authentication is provided, the
user is redirected to the main menu.
Main Menu: The main menu shows some navigation options as well as usage statistics about the user
and the program in general. From the main menu, the user can navigate to the list of referendums,
19
list of groups the user has involved, the list of received invitations, the about page. Besides, the user
can log out and leave the program.
Referendums: See the list of all referendums, open and closed, available to the user. The referendum
list screen shows the list of referendum in two tabs: open referendums and closed referendums.
Open referendums are open for voting and tapping on an open referendum will navigate the user to
the voting screen while closed referendums are not available for new votes and tapping on a closed
referendum will navigate user to the results screen of that referendum.
Vote to the available referendums: The voting screen shows the referendum name, referendum
question and possible options. When the user presses one of the buttons, a dialog appears asking
user to confirm the voting choice. If the user confirms, the vote is sent and user is returned to the
referendum list screen.
See the results of finished referendums: The referendum results screen shows the referendum name,
referendum question and information about the voting results including the vote counts,
percentages, the winning option and a graphical representation of these data.
See the groups of the user: The groups screen lists the groups the user has joined. User can tap on a
group to navigate to the group screen or can navigate to group creation screen to create a
unrestricted group.
Open a group: In the group creation screen, the user can create an unrestricted group by entering
the group name and tapping the “Create” button or go back to groups screen. After the group is
created, the user will be redirected to the group screen of the created group.
Group: The group screen shows the group name, number of members and number of open and
closed referendums. Besides, this screen shows some buttons may or may not be visible to the user
depending on the user and group statuses. Referendums button redirects the user to the list of
referendums of this group. This button is visible to all users who is a member of the group. Open
Referendum button redirects the user to the referendum creation screen. This button is visible if the
group is an unrestricted group or the user is the moderator of the group. Invite User button redirects
the user to the new invitation screen. This button is visible if the group is an unrestricted group or
the group is a dynamic restricted group and the user is the moderator. Leave Group button allows
user to leave the group and it is visible if the group is an unrestricted or dynamic restricted group and
the user is not the moderator. Disband Group button allows user to remove the group from the
system and this button is visible if the group is an unrestricted group and the user is the moderator
of this group.
20
Create referendum: The referendum creation screen is a form which requests the user to enter the
referendum name, referendum question and the options for the referendum, options for a
referendum can be entered by “Add Option” button.
Invite user: Invite user screen simply consists of a text field to enter the id of the to be invited user
and the invite button. When the user taps on the “Invite” button, an invitation to the user with the
entered ID will be sent.
Accept invitation: From the main menu, the user can navigate to the invitations screen. This screen
shows the current invitations of the user has been received. The user can accept or reject these
group invitations.
Credentials: The about screen just shows the information about the project, developers and other
relevant data.
8.2.
Server
System needs different servers for each of the following: mixer, counter, key authority, main server.
There can be more than one mixer and counter servers (in an ideal world, there should be). After
servers are created physically or on cloud, system needs linux installed on top of the server. Main
server needs MySQL, and since it will serve as the client handler, appropriate port configurations
must be done (http port, ssh port…etc.); mixer, counter and key authority C codes must be compiled
with linking with gcrypt and gnutls libraries, hence libraries must be ready to use in servers.
Certificates must be handed or generated (depends on the purpose) beforehand for the TLS
communication between servers. After these adjustments are done, servers are ready to use.
Authentication of the users are done from a third party (STARS system for Bilkent case).
Before starting a referendum, all the mixers and counters must be online and written to the mixer
and counter files of authority.
21
9. References
[1] Wikipedia, the free encyclopedia – Electronic Voting
http://en.wikipedia.org/wiki/Electronic_voting
[2] Ronald Rivest. The ThreeBallot Voting System. Available at:
http://people.csail.mit.edu/rivest/Rivest-TheThreeBallotVotingSystem.pdf
[3] Wikipedia, the free encyclopedia – Electronic Voting Examples
http://en.wikipedia.org/wiki/Electronic_voting_examples
[4] Jens-Matthias Bohli , Jörn Müller-Quade and Stefan Röhrich Bingo. Voting: Secure and coercionfree voting using a trusted random number generator. Available at:
http://eprint.iacr.org/2007/162.pdf
[5] Helios Voting. https://vote.heliosvoting.org/
[6] Aggelos Kiayias, Michael Korman and David Walluck. An Internet Voting System Supporting User
Privacy. Available at: http://mkorman.org/acsac.pdf
[7] Electronic Vote and Democracy http://www.electronic-vote.org/
[8] Electronic Voting – Introduction http://cs.stanford.edu/people/eroberts/cs201/projects/200607/electronic-voting/index.html
22