SPECIFICATIONS OF A MOBILE ELECTRONIC VOTING SYSTEM AND A MOBILE AGENT PLATFORM

K. Saleh, C. El-Morr, A. Mourtada and Y. Morad

American University of Sharjah P.O. Box 26666, Sharjah, United Arab Emirates

ABSTRACT

This paper provides the specification of a mobile electronic voting system (MEVS) using Mobile UML [1]. We also introduce a new platform for the management of mobile agents that supports security and fault tolerance. The platform is used to develop the MEVS. Using the platforms APIs, other mobile applications can be efficiently developed and deployed on the internet.
KEYWORDS

Fault-tolerant mobile platform, Mobile electronic voting, Mobile platform, Mobile UML.

1. INTRODUCTION
A mobile agent is a software component that is able to move across computer systems at which it can execute the code it carries [3]. Typical applications of mobile agents include electronic commerce [4, 5], network management, computer games [6], and collaborative processing applications among others. Furthermore, a family of computer applications in electronic government can be suitably carried out using a combination of mobile and stationary agents, reducing network traffic by allowing the least number of interactions across platforms. An example of such application is electronic voting. Mobile agents are created by a distributed application at a computer site and launched to another site using an underlying mobile agent platform. An instance of the platform running at the remote site can receive the mobile agent and dispatch it to the distributed application running at that site. There are already some existing platforms like Aglets, Concordia, and Odyssey [6]. However, none of these platforms take care of two important aspects needed in mobile applications, that is, security and fault-tolerance, in addition, these platforms are not interoperable. Those aspects are of greater importance and relevance in applications requiring a higher degree of privacy, authenticity and reliability such as electronic voting. In mobile electronic voting, voters will be able to securely publish their votes on their computers, and a mobile vote collector agent in coordination with a stationary vote manager would visit each of the voters site and collect their encrypted and authentic published vote. In this work, we report on our experience in: 1) developing a prototype platform for mobile agents, and 2) developing the MEVS that uses the developed platform. Our platform considers the guidelines described by the Foundation for Intelligent Physical Agents (FIPA) that allows the interoperability between agents running on different agent platforms [2]. Our platform specifications provide the application developer with an application programming interface (API) that allows the launching of mobile agents with two optional features, security and fault-tolerance. Using our API, new mobile applications can then be efficiently developed and deployed on the internet. The rest of the paper is organized as follows. Section 2 describes briefly the functionality of the mobile agent platform. Section 3 describes the MEVS that uses the mobile platform. This application is specified using Mobile Unified Modeling Language (M-UML). Finally, we conclude the paper and discuss some future extensions to this work.

281

IADIS International Conference e-Society 2003

2. MOBILE PLATFORM SPECIFICATION

This section describes the Mobile Agent Platform (MAP), its sub-modules, and its upper and lower interfaces. Two types of applications will be executing on the top of the MAP layer, namely, user applications like games, and management applications. Mobile Agent Applications (MAA) are responsible for requesting the creation and managing the participation of mobile agents involved in the mobile application. Platform Management Applications (PMA) are programs responsible for the overall supervision control and administration of the mobile platform. The MAP layer consists of several modules: the Agent Management System (AMS), the Agent Registry (ARg), the Agents Repository (ARp), the Security module and the Fault Tolerance module. This layer design conforms to the design recommended by the Foundation for Intelligent Physical Agents (FIPA) platform specification. Figure 1 shows the MAP layer and its lower and upper interfaces, in addition to the intra-layer interfaces. In this paper, we refer to MAPs upper layer interface as the Application Programming Interface (API). Figure 2 shows the structuring of the AMS within the MAP. The functionalities of each of the MAP interfaces are described and their input and output specifications are listed. A complete M-UML specification and design of the platform is provided in [8].
Mobile Agent Application Platform Management Application

Agent Platform (AP)

Agent Registry (Reg)

Agent Management System (AMS)

Agent Repository RMI based Transport Network System

RMI based Transport Network System

Agent Platform (AP)

Figure 1. The MAP, its sub-modules and its upper and lower interfaces.

FaultTolerance

Agent Management System

Security

Encryption Digital Signature

AMS Basic Functionality

Figure 2. Structure of the AMS.

3. MOBILE ELECTRONIC VOTING

In this section, we first provide a brief informal description of mobile electronic voting system (MEVS) that uses the MAP specified in Section 2. Then, we specify the MEVS using M-UML.

282

SPECIFICATIONS OF A MOBILE ELECTRONIC VOTING SYSTEM AND A MOBILE AGENT PLATFORM

3.1 Brief description

MEVS consists of several interacting agents, the Vote Collector, the Vote Manager, the Vote Authority, the Candidate, and the Voters. The Vote Authority (VA) is responsible for registering candidates for elections and commissioning Vote Managers. The Vote Collector (VC) is a mobile agent mandated by a stationary Vote Manager (VM) agent to collect votes from stationary voting agents (VOs). Because of its hierarchical tree-structure, the system can be easily expanded to have more VMs and more VCs dealing with one VM. Prior to the election, voters will have to register themselves with the VA, and those interested candidates would also register themselves with the VA. The lists of candidates and voters are sent by the VA to the VMs, which in turn send them to their registered voters via their assigned VCs. Once the candidate list is received by a VO, the VO will instantiate its stationary agent with a voting choice. On election time, Each VC will visit the VOs on its list and get their votes, and once done, they return back to their base station reporting to the VM the votes collected from the available voters. The VM will then dispatch the results of the votes to the VA. Finally, the VA informs the VMs and the voters of the official results. The messages that are exchanged and carried over the network during the progress of this voting procedure are both encrypted and carry a digital signature. Only the VA is able to decrypt and authenticate the votes received from the VMs.

3.2 M-UML specifications

In this section, we will describe the basic specifications of the MEVS using M-UML. Due to the limited space, we will only provide the use case, sequence and statechart diagrams.

3.2.1 Use case diagrams

In the following, we show three basic use case diagrams needed for the registration, vote collection and termination of the voting process. Four use cases are used to support the voter and candidate registration (Figure 3). Voters and candidates have to register themselves with the Voting Administrator (VA). The Vote Administrator (VA) will initiate the voting process by sending the voters and candidates lists to the Voting Managers (VMs) which in turn send them to their respective Vote Collectors (VCs) (Figure 4). Finally, the use case diagram in Figure 5 shows the vote collection and reporting process, in which the VC collects votes from voters (VOs), then forward the votes to the VM which in turn forwards it to the VA. The VA verifies the votes and deliver the results to the VMs, voters and candidates. These diagrams show only the VC as the only mobile actor in the electronic voting model.
Voter & Candidate Registration
Register

VO Deregister

VA Withdraw Candidacy

VA : VO :

Voting Administrator Voter

Present Candidacy Candidate

Figure 3. Use case diagram for voter and candidate registration.

283

IADIS International Conference e-Society 2003

Voting Starting

Deliver VotersList

VM Deliver CandidatesList VA

VA : VM: VC :

Voting Administrator Voting Manager Vote Collector

Deliver SelectedVotersList VC

Figure 4. Use case diagram for the voting.

Votes Collection & Termination
M
Voting VM VO

Deliver Votes

VA VM: VA : VO : VC : Voting Manager Voting Administrator Voter Vote Collector

Deliver AllVotes VC

Deliver Results

Figure 5. Use case diagram for vote collection and termination.

3.2.2 Sequence diagrams

Figure 6 shows a sequence diagram describing an optimistic scenario in which all the phases of initiating the voting process, and vote collection and termination are involved. Additional non-functional requirements are provided by the MAP and are to some extent applicationindependent. In the following, we show one sequence diagram related to the application fault-tolerance. Figure 7 shows the behavior of the VC when a voters platform is unreachable (i.e., is down). Finally figure 8 shows the behavior of the VM when a VC is lost.

284

SPECIFICATIONS OF A MOBILE ELECTRONIC VOTING SYSTEM AND A MOBILE AGENT PLATFORM

VA CandidateList

VM

VC

VO i

VO i+1

VO i+2

VO m

CandidateList VotersList SelectedVotersList

<<vote collected>>: UpdateLocation

M Voting M M R Voting M M <<vote collected>>: UpdateLocation R M Voting M <<vote collected>>: UpdateLocation M M M M M M <<agent return>>: finshedCollecting M M

Voting

....

deliverVotes <<all VCs back>>: deliverAllVotes

Optimistic Scenario

Figure 6. Sequence diagram for an optimistic scenario for the voting process.

3.2.3. Statechart diagrams

In the following, we show three statechart diagrams in Figures 9-12, describing the behavior of each of the agents involved in the voting, namely, the VA, VC, VO and VM.
VA CandidateList CandidateList VotersList SelectedVotersList VM VC VO i VO i+1 VO i+2 VO i+3 VO m

<<vote collected>>: UpdateLocation

deliverVotes

M Voting M R M Voting M M <<vote collected>>: UpdateLocation R M Voting M Voting M Voting M M Voting M M <<vote collected>>: UpdateLocation M M M M M M <<agent return>>: FinishedCollecting M

Voting

....

<<all VCs back>>: deliverAllVotes

Figure 7. Voters platform is down.

285

IADIS International Conference e-Society 2003

VA CandidateList

VM

VC

VO i

VO i+1

VO i+2

VO m

CandidateList VotersList SelectedVotersList

M M Voting M R <<vote collected>>: UpdateLocation M Voting M Voting M Voting M <<timeout>>: RelaunchVotingAgent M M R <<vote collected>>: UpdateLocation M M <<vote collected>>: UpdateLocation M M M M <<agent return>>: FinishedCollecting M
deliverVotes <<all VCs back>>: deliverAllVotes

Voting

. ...

<<timeout>> : When the VM doesn't receive an UpdateLocation message it assumes the agent lost, so it issues a relaunch for the voting Agent from the last platform that sent the Update Message Location.

Figure 8. VC agent is lost

<<voting started>> / VMi.DeliverVotersList, Vmi.DeliverCandidateList VO.Deregister / VO.RemoveVoter VO.Register / VO.RegistrationConfirm Candidate.PresentCandidacy / Candidate.CandidacyConfirm Candidate.WithdrawCandidacy / Candidate.RemoveCandidate Vmi.DeliverAllVotes / Vmi.DeliverResults,VO.DeliverResults

Ready

Figure 9. VAs statechart.

VOi.Vote [more on List] / VOi+1.Voting VM.deliverCandidateList , VM.deliverSelectedVotersList / VOi.Voting

M M
. Idle . . Getting Votes .

M M
[finish list] / VM.deliverVotes

[Vcount=>3] / VOi+1.Voting

VOi.Vote / VOi+1.Voting

[VOi down] / Vcount++,VOi.Voting

M M
. Waiting for voter .

[Vcount<3] / Vcount++,VOi.Voting

Figure 10. VCs statechart.

286

SPECIFICATIONS OF A MOBILE ELECTRONIC VOTING SYSTEM AND A MOBILE AGENT PLATFORM

VA.VotingResults VA.RegistrationConfirm /VA.Registration

Ready

VC.Voting

/ VC.Vote

M
Voting

Figure 11. VOs statechart.

VA.CandidateList , VA.VotersLists / VC.deliverCandidateList,VC.deliverSelectedVotersList VCcount++, VCi.deliverVotes

Idle

. [VCs all back] / VA.deliverAllVotes

. Wait for Vote Collectors .

Figure 12. VMs statechart.

4. CONCLUSION AND FUTURE WORK

In this paper, we have described the specification and architecture of a mobile agent platform for launching and controlling mobile agents created by mobile agent-based software applications. We have then described using M-UML a mobile agent-based electronic voting application that takes advantage of the mobile platform. Various fault-tolerance and security issues are delegated to the platform itself, therefore relieving the application designer from accommodating these features in the application design itself. This approach allows for the easy development and deployment of mobile applications. In the future, we plan to experiment with different application categories, such as mobile games and mobile e-commerce, in which more agent mobility is present. This will allow us to examine the robustness of our platform under various application scenarios.

ACKNOWLEDGEMENT
We would like to acknowledge support of this work by a grant from the American University of Sharjah.

REFERENCES
[1] [2] [3] [4] [5] Saleh K. and El Morr C., Mobile-UML: An extension to UML for specifying mobile agent-based software, submitted. FIPA, 2002, Agent Management Specification, www.fipa.org/specs. Garcia S., 1998, Design Issues in Mobile Agent Systems, MA, Addison-Wesley. Kiniry J. and Zimmerman D., 1997, Hands-on look at Java mobile agents, IEEE Internet Computing, July, pp. 21-30. Chavez A., Maes P., 1996, Kasbah: An agent marketplace for buying and selling goods, Proceedings of the First International Conference on the Practical Application of Intelligent Agents and Multi-Agent Technology, UK. [6] Saleh K. et al., 2003, Specifications for a mobile agent platform and a mobile game application, Second International Conference on the Application and Development of Computer Games (ADCOG2003), Hong Kong, China. [7] Lange D. and Oshima Y., 1998, Programming and Deploying Java Mobile Agents with Aglets, Addison-Wesley. [8] Saleh K. et al., Specification and design of a fault-tolerant and secure mobile agent platform, submitted.

287