SOCA (2012) 6:249–266DOI 10.1007/s11761-012-0108-0

ORIGINAL RESEARCH PAPER

A service-oriented architecture for robust e-voting

Richard Cooke · Rachid Anane

Received: 21 September 2011 / Revised: 27 April 2012 / Accepted: 30 April 2012 / Published online: 5 June 2012© Springer-Verlag London Limited 2012

Abstract Of all the requirements for e-voting systems,robustness is the one that has received the least attention. Thispaper is concerned with addressing this issue. It is arguedthat a two-level consideration of robustness can facilitatethe design of e-voting systems and enhance their resilience.An approach is proposed which requires, as a first step, anexplicit awareness of robustness at protocol level and robust-ness at system level. The second step involves the identifica-tion of appropriate technologies and their integration into anarchitecture where the two forms of robustness are addressed.The approach is illustrated by the design and implementa-tion of a service-oriented architecture for robust e-voting,based on the FOO92 protocol. The service-oriented architec-ture provided the framework for the integration of selectedtechnologies such as blind signatures, encryption and onionrouting. In addition to the just-in-time composition of thee-voting system, it supports the distribution of tasks and state.The system conforms to most e-voting requirements.

Keywords Robustness · Web services composition ·JIT approach · Blind signatures · FOO92 protocol ·Onion routing

R. CookeSchool of Computer Science, University of Birmingham,Birmingham, Englande-mail: r.cooke@cs.bham.ac.uk

R. Anane (B)Faculty of Engineering and Computing,Coventry University, Coventry, Englande-mail: r.anane@coventry.ac.uk

1 Introduction

The viability of e-voting systems is often assessed by theirconformance to agreed and stated requirements. Thisfundamental constraint is driving the investigation intorequirements and verification [1]. The present consensus onthe identification of desirable e-voting properties has set-tled on four main criteria: integrity, privacy, verifiability androbustness.

In the fulfilment of these requirements, two distinct lev-els of concern are identified, a protocol level and a systemlevel. The protocol level is concerned with the deploymentand the behaviour of the protocol as an application for con-ducting elections; the system level relates to the underlyingnetwork, the implementation of the servers and their interac-tion. This dichotomy is a reminder that remote voting systemsare essentially applications supported by distributed systems.

Integrity and verifiability are issues that relate primarily tothe protocol level. Privacy, on the other hand, is meaningful atprotocol level, but its full satisfaction, especially anonymity,may require an awareness of the characteristics of the under-lying distributed system. Although secrecy can be achievedby cryptographic and therefore mathematical methods only,anonymity requires the marshalling of distributed technolo-gies such as mix nets [2,3], onion routing [4] or Web serv-ers [5]. Anonymity is an issue that straddles different levels,a characteristic that it shares with the management of denialof service (DOS).

At protocol level an e-voting system is expected to con-form to, at least, the integrity and the privacy requirements.It also assumes at distributed system level resilience whensubjected to malicious attacks or when faults occur. It isevident that the soundness of the underlying distributed sys-tem determines the utility of an e-voting system. This factqualifies robustness as a property that spans both levels of

123

250 SOCA (2012) 6:249–266

concern. Robustness may be defined generically as theability of a system to deal effectively with unexpected inputor behaviour, large volumes of data and to continue provid-ing a service in conformance with stated requirements. Inpublished research on e-voting systems, robustness is oftenconfined to the protocol level, while issues that pertain todistributed system level are seldom explored.

This paper is concerned with the presentation of anapproach that promotes a more focused view of robustnessin e-voting systems, and a selective application of distributedsystems technologies in the development of robust systems.It is argued that this two-pronged strategy can successfullyaddress robustness issues at protocol level and at systemlevel.

The contribution of this paper lies in the explicit differen-tiation between two forms of robustness and the integrationof various technologies into an appropriate architecture toaddress this issue. The approach is illustrated by the designand implementation of a service-oriented architecture forrobust e-voting (SOREV), based on the FOO92 protocol [6].It is characterised by dynamic composition of Web services,the distribution of state and tasks, and onion routing.

The remainder of the paper is organised as follows. Sec-tion 2 identifies the main requirements of e-voting systems.Section 3 presents a particular perspective on robustness ine-voting systems. Section 4 gives an outline of the behaviourof the proposed system, and Sect. 5 details the implementa-tion of the corresponding service-oriented architecture. Sec-tion 6 offers an evaluation of the approach and of the system,in context with other e-voting systems. Section 7 puts for-ward some pointers for further work, and Sect. 8 concludesthe paper.

2 e-Voting

With the increasing interest in the deployment of e-votingsystems and the potentially significant impact they can haveon the political, economic and social domains, conformanceto specific requirements has become a critical test. At the coreof voting systems lies the need for compliance with the dem-ocratic process by ensuring its viability through four stagesperformed by specific election authorities:

• The registration of eligible voters (Administrator).• The validation of potential voters (Validator).• The collection of the votes (Collector).• The tallying or counting of the votes (Counter).

The voting process is conducted within specific constraints.A secure electronic voting scheme must meet the followingtheoretical requirements [7]:

• Only eligible voters are able to vote.• No voter is permitted to vote more than once.• No one should be able to determine the value of anyone

else’s vote.• No one can duplicate a vote.• No one can alter another person’s vote without being

detected.• Voters can verify that their votes have been counted.

2.1 Advantages of e-voting

The exponents of e-voting often put forward a number ofreasons for promoting its wider deployment. They contendthat it has a number of benefits:

Participation: Electronic voting has the potential to appealto a wider section of the population. An Internet-based sys-tem will enhance convenience and flexibility. Voters will beable to cast their vote anytime and anywhere.

Efficiency and accuracy: e-Voting promises to improve theaccuracy of the voting process at various stages. Comput-erisation and network technology, it is argued, will improveefficiency in processing votes and will lead to quicker results.

Transparency: An e-voting system will lead to greater open-ness to public scrutiny and greater accountability. The scru-tiny should apply to the source code by experts as well asverifiability of votes by voters. This demand for opennessshould not be achieved at the expense of security.

2.2 e-Voting properties

The formulation of e-voting requirements has led to a refine-ment of criteria and has become an important research areain its own right [8,9]. The most important e-voting propertiescan be grouped as follows:

• Integrity: This is concerned with the property that thedifferent agencies that process votes do not alter them orcorrupt them, and intruders do not interfere with the vot-ing process. It also refers to the ability of eligible votersto vote and to vote only once. More specifically, integrityimplies that a vote is cast as intended, recorded as castand counted as recorded. Integrity entails honest behav-iour and collusion resistance.

• Privacy: This criterion is aimed at ensuring that votes arecast anonymously, namely that it is not possible to asso-ciate a vote with the corresponding voter (untraceability)and that the vote is secret. Another aspect of privacy con-cerns the inability of voters to demonstrate that they havevoted in a particular way and their ability to withstandcoercive measures (coercion resistance).

• Verifiability: This refers to the openness of the systemto formal and practical scrutiny and is related to integrity.

123

SOCA (2012) 6:249–266 251

It should be possible for voters to check that their voteswere correctly recorded (individual verifiability) and thatall the votes were processed and counted correctly (uni-versal verifiability). It is believed that with enhanced ver-ifiability, voters will have more confidence in the conductof remote elections and in their results.

• Robustness: This is defined as the resilience of the sys-tem when cheating behaviour is detected, partial compo-nent or system malfunction occurs or when it is subjectedto external malicious attacks. The system should operateas expected in abnormal conditions or in a hostile envi-ronment.

In e-voting research, the focus has been mostly on the con-formance to integrity, privacy and verifiability. Despite itscrucial importance, robustness is seldom addressed explic-itly. Either it is implicit or it refers to issues that pertain toundifferentiated levels of concern. Since most e-voting sys-tems are deployed as distributed systems, robustness is boundto involve many facets across different levels.

In the Prêt à Voter system, for example, robustness is con-cerned with the resilience in the face of random faults, as wellas deliberate attempts to disrupt the election, such as denialof service [10]. It is seen as an indication of the ability ofthe implementation of the protocol to deal with unexpectedinput, faults or cheating by an election authority.

This perspective on robustness is quite broad. It coversissues that refer specifically to the e-voting application, suchas cheating, and those that may arise in the underlying distrib-uted system such as faults and denial of service. It is evidentthat there is a semantic difference in behaviour between anelection authority that attempts to cheat and the faulty serverthat implements it.

2.3 e-Voting protocols

In most e-voting systems the design of protocols is driven bytwo major concerns, which identify two main virtual spaces:

1. Ensuring that if the voter is known the vote is not known;2. Ensuring that if the vote is known the voter is not known.

It is this complete dissociation between a vote and the voterwho cast it, namely anonymity or untraceability, which lendscredibility to an e-voting system. e-Voting systems can beclassified according to the way they implement it. Three mainschemes exist to support it:

• Schemes based on homomorphic encryption reduce a bal-lot to a number and ensure that all the voter choices arekept secret [11]. This has the advantage that the vote canbe performed without decrypting any of the ballots. It is,however, computationally expensive.

• Schemes that generate mixes (mix nets) permute differ-ent entities to hide the correspondence between input andoutput items, and ensure that an item is only processedonce [2]. The connection between voters and ballots isdifficult to establish.

• Schemes based on blind signatures [6,12] allow an agencyto sign a message without knowing its contents. Schemesbased on blind signatures present a number of advantages.They are more flexible and can accommodate various bal-lot formats. Moreover, their relatively small communica-tion and computational complexity make them suitablefor large-scale elections.

3 Robustness

A distinction between an application and the system thatserves it is useful for a clear identification of the issues relatedto robustness. This consideration suggests an appreciation ofrobustness at two different levels. It promotes an awarenessof issues at protocol level such as integrity and privacy andthose that pertain to the distributed system, such as resilienceand scalability. It is also helpful in identifying more refinedrequirements and promoting appropriate configurations. Thegeneric definition of robustness can be refined to capture thedistinctive features of robustness at the two levels:

Robustness at protocol level is defined as the capability ofthe application to ensure that the privacy, integrity and ver-ifiability of the e-voting process are preserved, when facedwith incorrect procedures or malicious behaviour and attacks.Robustness at this level is seen as an overarching concept thathelps evaluate the ability of a system to conform to e-votingrequirements. All agencies contribute to the voting processto satisfy stated requirements; measures are in place to dis-courage and hinder cheating behaviour, and no agency orgroup of agencies can attempt to thwart the democratic pro-cess without being detected.

An additional component of robustness at protocol levelis recoverability. It is defined as the capability of the e-vot-ing application to recover from malfunctions by restoring thestate of the voting process and by resuming successfully itsoperations [13].

Robustness at system level is defined as the capabilityof the distributed system to support the functions of thee-voting application when faced with component failure orabnormal behaviour. The system should deal effectively withunexpected input or volume of data and detect and recoverfrom malicious attacks. It should continue to provide a ser-vice in conformance with stated requirements. Robustnessat this level is a prerequisite for robustness at protocol level.For example, insecure servers or channels cannot ensure theprivacy of the voter or the secrecy of the vote.

123

252 SOCA (2012) 6:249–266

Although robustness of e-voting systems at system levelcan be expressed in terms of many properties [14], resilience,scalability, flexibility and cost are deemed particularly rele-vant:

Resilience: the capability of a system to mitigate the impactof abnormal conditions and failures on its behaviour.

Scalability: the capability of a system to accommodategrowth and to deal effectively and adaptively with fluctu-ations in load.

Flexibility: capability of a system to operate in different plat-forms and environments and to support interoperability anda variety of configurations.

Cost: an evaluation of the resources used in the system, themode of interaction of the components and the implied pro-cessing involved in its operation. Implementing a robust sys-tem may be expensive because of the replication of resourcesand heavy communication load required.

3.1 Robustness in e-voting systems

The range of robustness issues that arise in e-voting can beoutlined by reviewing the properties of some e-voting sys-tems. Sensus [5] presents the issue of robustness under the‘democracy’ criterion, but provides limited support for it. InSensus, it is assumed that communication occurs over anon-ymous channels. The issue of robustness is not consideredexplicitly, and robustness at system level is not addressed.SEAS [15] is presented as an improvement to Sensus in pre-venting the Validator from voting on behalf of eligible vot-ers who abstain. It implicitly enhances the robustness of thee-voting system at protocol level.

REVS was designed with robustness as a key propertyof the system and considers robustness at two levels [16].REVS deals with robustness at system level by replicatingservers, maintaining state information and ensuring ‘resum-ability’ in case of interruption. At protocol level, the systemis evaluated against the integrity criterion. The provision ofmany servers that contribute to a quorum policy is consideredan impediment to collusion. REVS makes use of redundantinformation and servers to improve robustness.

In Prêt à Voter, robustness is considered implicitly as theability of the system to cope with, for example, the cheatingbehaviour of the mix servers. This is achieved by the removalof a cheating mix server and its simulation by a quorum Qof other mix servers [10]. Other aspects of robustness areconsidered as part of the practical implementation at systemlevel. There is, however, no explicit distinction between thedifferent levels of robustness.

The design of Civitas [17] is motivated by the need toachieve full conformance to e-voting requirements, espe-cially coercion resistance. Robustness is addressed explicitly

and is expressed in terms of trust, namely the ability of a legit-imate voter to cast a vote without coercion and to have thevote cast as intended, recorded as cast and counted as cast.The focus is on robustness at protocol level; issues that relateto the underlying distributed system are identified as limita-tions for further work. Helios [18] does not address robust-ness explicitly at any level and relies on extensive auditingand verification to detect malicious behaviour and ensureconformance to integrity. Implicitly, the focus is at the pro-tocol level.

This brief review reveals that most of these systemsaddress robustness mainly at protocol level, either implic-itly or explicitly as in Civitas. REVS appears as one of theexceptions where robustness is considered at two levels with-out an explicit differentiation. It can be argued, however, thatthe design of some of these systems may be motivated bytransparency considerations.

3.2 Robustness in distributed systems

The rationale for considering robustness at two levels stemsfrom the realisation that the ability of an e-voting applicationto deal with unexpected situations depends on the flexibil-ity of the underlying distributed system and on the choiceof technology. The selection of a client–server or P2P archi-tecture, the inclusion of stateful or stateless servers, the reli-ance on Web services or distributed object middleware areall implementation decisions that affect the robustness of thedistributed systems, and by implication that of the applicationitself. Client–server architectures may be easy to implement,but the server may be a single point of failure; P2P systemsoffer more flexibility and resilience, but critical interactionsrequire a trustworthy environment; Web services may be sim-pler and easier to integrate but require verbose and inefficientencoding; stateful servers offer more convenience but requirethe active maintenance of a consistent state. Most signifi-cantly, however, networks and servers can be subjected todenial of service (DOS) attacks [19]. Typically, these attacksinvolve either swamping the network with garbage messagesor overloading a server with computationally intensive anduseless requests. In both cases, the aim is to prevent the sys-tem from performing its role effectively.

Various methods have been proposed for enhancing therobustness of a distributed system: distribution of tasks andstate, replication of resources and servers, provision of flex-ible routes and inclusion of stateless protocols and servers.

4 An e-voting system

The proposed approach is illustrated by the design and imple-mentation of an electronic voting system. It will be usedas a vehicle for exploring the issue of robustness and in

123

SOCA (2012) 6:249–266 253

particular the impact of selected technologies and architec-ture on robustness at the two levels. The proposed approachis based on two premises: (1) a sound implementation of ane-voting application requires the sound implementation ofthe underlying distributed system and (2) a holistic designand implementation approach that addresses both levelssimultaneously offer more resilience and lead to better inte-gration.

The scope of the investigation of robustness will be con-fined to certain specific issues. At system level, the mainconcern will be denial of service and faulty servers. At pro-tocol level, the focus will be on integrity issues such as cheat-ing and collusion, and privacy issues such as anonymity andsecrecy. In the design of the e-voting system, it is assumedthat the registration of voters is done before the election andthat voters obtain their codes and aliases through out-of-bandauthentication. It is also assumed that the voter’s machine isreliable and trustworthy and that votes are cast as intended.In line with the rationale that underpins the design of theHelios system, coercion resistance is not considered a criti-cal issue because of the context and the limited scope of thedeployment of the system.

4.1 FOO92 protocol

An implementation of the FOO92 protocol is used as the basisfor a case study of the impact of engineering solutions on therobustness of an e-voting system. Thanks to its flexibility, itsefficiency and its conformance to most e-voting criteria, theFOO92 protocol has formed the basis for many voting proto-cols and has been the subject of various enhancements. It hasalso a high degree of compatibility with manual systems [20].The FOO92 protocol has the advantage of simplicity, offersa clear separation between concerns and can accommodateflexible implementations at distributed system level. The pro-tocol is based on blind signatures [12] and models the votingprocess as follows:

1. Voter retrieves ballot from Administrator.2. Voter completes the ballot and blinds it.3. Voter constructs a message containing the ballot and his

identity and encrypts it with the Validator’s public key.4. Voter sends the message to Validator.5. Validator decrypts the message, validates Voter and signs

the ballot.6. Validator returns the blinded ballot to Voter.7. Voter unblinds the ballot and encrypts it with Counter’s

public key.8. Voter forwards the ballot to Counter over an anonymous

channel, through Collector.9. Counter checks for Validator’s signature on the ballot,

decrypts it and increments the corresponding count.

The development of the system involves essentially map-ping the election authorities to specific servers, providingsupport for validation and authentication through access tothe electoral roll, setting up anonymous channels and record-ing votes. The design of the system should also cater for therequirements of robustness at two levels.

4.2 The voting process

The system architecture that supports the voting process isshown in Fig. 1. It incorporates all the servers and their modesof interaction.

The processing of the vote information identifies three dis-tinct virtual spaces in the diagram: validation where the voteris known but the vote is not known; transmission of the votewhere the voter is not known and the vote is not known; andrecording of the vote where the voter is not known and thevote is known.

Validation: the voter is known and the vote is not known.This phase is concerned with the authentication of the voterby the Administrator and the retrieval of election details andidentification information (Step 1, 2). A vote with a personalrandom number (RN) and election details is blinded and sentto the Validator (Step 3). With blind signatures, the Validatorsigns the message sent by the voter without being able toread its content [17]. The validation of the voter through itsalias VT1 involves checking its credentials against the elec-toral roll (e-roll nodes) (Steps 4, 5) and determining whetherthey have already been validated (Steps 6, 7). If the voter iseligible, the blinded vote is signed and returned to the voterby the Validator (Step 8). The Validator requires an acknowl-edgment from the voter in order to prevent multiple requestsfor validation from the same voter.

Transmission: the voter is not known and the vote is notknown. On successful validation, the voter unblinds the mes-sage signed by the Validator and encrypts it with the publickey of the Counter (V = {{choice, electionId, RN} val−priv}

count−pub). It then transmits the message to the Counter viaa chain of routing nodes (Steps 9, 10, 11, 12) and the Col-lector (V, {{col}N3−pub, N3}N2−pub, N2}N1−pub). The chainacts as an anonymous channel. On receipt of the message,the Collector extracts the packaged ballot, checks its validityand forwards it to the Counter (Step 13).

Recording: the voter is not known and the vote is known.The Counter checks the ballot for validation by the Validator,extracts the vote and adds it to the appropriate tally. The voteis also recorded in the database against the personal randomnumber of the Voter.

4.3 Secure and anonymous processing

The notation used in Fig. 1 includes the application of asym-metric encryption to the messages. In the exchange of these

123

254 SOCA (2012) 6:249–266

Fig. 1 e-Voting process and architecture

messages, secure and anonymous transmission is achievedby a number of techniques. Firstly, by the generation of arandom number by the voter as a unique identification token,RN, which facilitates individual verifiability and preventsmultiple votes by one voter. Secondly, by blinding signaturesand symmetric encryption, which assure the anonymity andsecrecy of the vote. This is illustrated by the message sent tothe Validator by the Voter ({{choice, electionId, RN}blinded,

VT1, electionId, voter-pub}val−pub). Thirdly, by the asym-metric encryption where messages are encrypted byusing the public key of a server (Counter) or signed by aserver (Validator) with its private key ({{{choice, electionId,RN}blinded}val−priv}voter−pub). And finally, by the onion rout-ing itinerary which is generated randomly and transmittedto the voter with the election details. It is designed to sup-port anonymous communication. In the proposed system,

123

SOCA (2012) 6:249–266 255

a Tor-like circuit [21,22] is built by the Administratorrandomly from a set of available nodes ({{{col}N3−pub,N3}N2−pub, N2}N1−pub) and passed to the voter. Ni con-tains the address of node, Ni, and its public key, Ni-pub.Although three nodes are used in this example, the length ofthe circuit is variable. The innermost node of the circuit isthe Collector (Col), and it is encrypted with the public keyof N3, the node that precedes it ({col}N3−pub). At the nextlayer, the encrypted innermost nodes are encrypted with thepublic key of N2, which precedes N3 ({{col}N3−pub, N3}

N2−pub). The first node on the path, N1, corresponds to theouter layer; all the inner nodes, which are its successors, areencrypted with its public key ({{{col}N3−pub, N3}N2−pub,N2} N1−pub). During transmission only the successor nodeis known to its predecessor. Hence, only routing node N1on the outer layer is known to the voter. The voter con-structs a message that includes the vote and the path andencrypts it with the public key of N1, ({V, {{{col}N3−pub,N3}N2−pub, N2}N1−pub } N1−pub). When N1 receives themessage, it decrypts it, firstly to access the vote V, and sec-ondly to retrieve the encrypted route to determine the nextnode in the network ({{{col}N3−pub, N3} N2−pub}, N2). N1then constructs a message with the vote V and the rest ofthe route and encrypts it with the public of its successor,N2 ({V,{{col}N3−pub, N3}N2−pub}N2−pub). The procedure ofencryption and decryption is repeated at each node until themessage reaches the Collector (col). Each server contributesto the monitoring of the voting process by logging and sign-ing explicitly its transactions and authenticating messageswhere appropriate. Unauthenticated messages are discardedin order to minimise the overload on the network and on theCounter.

5 A service-oriented architecture

The selection of a service-oriented architecture was a keydecision in the fulfilment of the e-voting requirements. Oneattractive feature of this application is the ability to createaggregate services through dynamic composition.

5.1 Web services

As ‘self-contained and self-describing applications’ Web ser-vices offer a number of advantages. Their adherence to well-established standards for Web service description (WSDL),serialisation of messages (SOAP) and Web service indexation(UDDI) underpin their ubiquity and their interoperability.They enable heterogeneous applications to communicate andto be integrated through composition into modular Web ser-vices. In addition, they can be deployed over standard Inter-net technologies and take advantage of the Web infrastructureand protocols [23].

Although the partial statelessness of SOAP/HTTP is oftenseen as a drawback in many applications, the intermittentconnections of Web services and the regular flushing of statethat they initiate make them very suitable for an e-votingapplication. The absence of state makes them more resilientto failure.

5.2 Architecture

The service-oriented architecture that implements the FOO92protocol identifies the different stages of the voting processand specifies the roles of the agencies and the entities in thee-voting system. It also represents an instance of the com-position of the system from key services. These include thefollowing:

• Administrator Service provides a user interface for spec-ifying the election, coordinates the agencies used in anelection, serves the Voter Client to the voter and publishesthe results when an election ends.

• Electoral roll nodes hold voter information. The alias ofeach voter is mapped to one of the three nodes by a hashfunction.

• Validator Service receives the blinded ballot from theVoter Client, using the alias provided by the voter, andchecks whether the voter exists and whether he or shehas not been validated.

• Collector Service receives the validated ballot from theVoter Client, signs and forwards the ballot to the Counter.

• Counter Service receives the ballot from the Collector,checks the collector signature, extracts and records thepersonal random number (RN) and the vote, and adds thevote to the tally.

• Routing Node receives a ballot either directly from a VoterClient or via a routing node, decrypts the routing path anddetermines the following node in the path.

• Voter Client is an applet used for casting a vote.

The Administrator service

The Administrator is the most important service in the sys-tem. It is the trusted election authority that initiates andcoordinates elections. Conceptually, it includes seven keycomponents (Fig. 2):

• Administrator User Interface: The Administratorprovides a Web-based user interface (UI) for the Elec-tion Official to view the status of agencies, specify elec-tions, view the agencies in use by an election, monitor theelection and view the results.

123

256 SOCA (2012) 6:249–266

Fig. 2 Administrator service

• Voter Client Access Service: This component provides aninterface for the Voter Client to interact with the Admin-istrator service and obtain the list of the candidates and ofthe agencies for validating and submitting the completedballot.

• Public User Interface: The voter UI provides a simpleWeb application to access all the public functions of thesystem. This includes access to the Voter Client applet,checking whether their vote has been recorded and howit was recorded, and viewing the results of an election.

• Check Voter Status Service: This provides an interfacefor the Validator service to check whether a voter exists,whether the voter has voted and to mark the voter as votedif applicable.

• Agency Monitoring Service: This monitors the status ofthe agencies in the system. If an agency is in use for anelection and becomes unavailable, this component selectsanother suitable one and allocates it to the election (Fig. 3).

• Election Coordination Service: This monitors the list ofelections in the system and starts and ends them as appro-priate.

• Persistence Layer: The persistence layer contains a set ofentities which represent the database model. Details ofelections, election results, electoral rolls, log messagesand agencies used are stored in the database.

5.3 Web service generation and composition

Web services are implemented using the JAX-WS frame-work which generates a Web service stub for a service and

publishes its WSDL file. This WSDL file is used by applica-tions that consume the Web service to create clients.

The composition process is controlled by the Adminis-trator. At the start of the election, the Administrator selectsa Validator, a Collector and a Counter at random from theagencies that are online and are not used by another elec-tion. Once selected, these agencies are notified and given theelection id and the details of the relevant nodes in the system.For example, once the Administrator has built the networkof e-roll nodes, it will inform the Validator of the location ofthe electoral roll nodes and their public keys:

<dhtUpdate><agency id = “0” pubKey = “1ed$f43fv3s”>

http://eroll5.vote.council.gov.uk</agency>

<agency id = “1” pubKey = “3d34v3shbdf”>http://eroll8.vote.council.gov.uk</agency>

<agency id = “2” pubKey = “03DX3tfxzy6”>http://eroll4.vote.council.gov.uk</agency>

<agency id = “3” pubKey = “f36hbtgb88r”>http://eroll0.vote.council.gov.uk</agency>

</dhtUpdate>

Figure 4 presents an outline of the methods that contributeto the composition process. The Collector and the Counterare given the details of the public key of the Validator so theycan check that the ballot validation signature is correct. Theprocess for composing the electoral roll agencies is similar,except that the Administrator will attempt to compose theelectoral roll agencies as requested by the election official.

A key feature of the system is its just-in-time (JIT) con-figurability. The JIT strategy is implemented by the dynamic

123

SOCA (2012) 6:249–266 257

Fig. 3 Server availability

composition of the servers and by the dynamic provision ofrouting paths.

5.4 Cryptography

The secure socket layer (SSL) was deemed unsuitable forsecuring communication as it only provides point to pointsecurity. Specific cryptography functions had to be imple-mented. These include methods for key generation, key stor-age, encrypting XML elements, decrypting XML elements,signing XML elements and verifying the signatures added toXML elements.

A hybrid cryptosystem was used for efficiently and securelysending messages between the agencies. Each message isencrypted using a freshly generated symmetric AES-128 key,which is used to encrypt the message content. This plain keyis then encrypted using the RSA-2048 public key of the recip-ient and forwarded along with the message. When it receivesthe message, the recipient decrypts the encrypted symmetrickey with its private key, so that it can decrypt and access thecontent of the message. Public keys are distributed to agen-cies when they are set up as X.509 certificates stored in thekey store. A version of an encrypted XML message is shownbelow:

<encrypted-message><sym-key>

esf234tr4g4t23fgg5y6</sym-key>

<encrypted-content>f4wrt3rt5egbdbdfbvt5Y2r3vevsf435gd

</encrypted-content></encrypted-message>

5.5 Implementation

Java was chosen as the programming language for the imple-mentation of the system because of its suitability for Webdevelopment and the availability of libraries for Web ser-vices and cryptography. All the application logic was writtenin EJBs with Glass Fish 3.0 as the application container. EJBsprovide many transparent services such as transactions, secu-rity, and pooling and thread safety.

Data management was supported by the design and imple-mentation of a MySQL relational database. The Java Persis-tence API was used to implement Object Relation mappingbetween Java objects and the relational database tables.

6 Evaluation

The evaluation is concerned with the conformance of SOREVto e-voting requirements, and with the level of robustness itprovides at protocol level and at system level. The role ofsome architectural elements in enhancing robustness is alsoconsidered.

6.1 Robustness at protocol level

This form of robustness is assessed in terms of integrity, pri-vacy, verifiability and recoverability.

Integrity

The Administrator performs a number of critical functionsunder the fundamental assumption that it is trusted. Other

123

258 SOCA (2012) 6:249–266

Fig. 4 Composition methods

agencies, however, need to be monitored and their behav-iour constrained. Some potential cases of misbehaviour areconsidered below.

It would be difficult for a Validator to vote on behalf of avoter who abstained. The use of aliases [24] and the distribu-tion of the electoral roll across many nodes are designed toprevent the Validator from identifying the voters who abstain.Although it can always create a new identifier, the alias willnot be cleared by the Administrator and will therefore lead to

discrepancies in the tally of the votes. The provision of mul-tiple Validators would reinforce this security constraint. Asfor the Collector, without collusion, it cannot forge or modifyvotes since they must be signed by the Validator. It can, how-ever, drop votes, but this can be detected through verifiabilityand tallying. A Counter may be able to add spurious votes, butthis can also be detected since the Administrator is keepingtrack of the total number of validated voters, which shouldbe greater than or equal to the tally of the votes produced

123

SOCA (2012) 6:249–266 259

Fig. 5 Server logs

by the Counter. Modification of votes by the Counter is hin-dered by verification by voters. The recording of the randomnumber (RN) in the Counter allows for votes to be computedaccurately and to prevent multiple votes by voters. With thestorage of the personal random number and its correspond-ing vote, the replaying of messages is made idempotent andvoters are not able to cast two votes.

Besides potential individual misbehaviour, collusionbetween agencies is another cause for concern. The tran-sient configurations that the JIT approach generates can be anobstacle to the collusion between servers. The use of onionrouting ensures that votes arrive to the Collector from dif-ferent routes. Although it is possible for a routing node toreplace a vote by another one, this can only be done with thecollusion of the Validator. This will eventually be detectedby voters. Votes are only accepted by the Counter if they aresent and signed by the Collector. The injection of spuriousvotes by entities outside the e-voting system is made difficultby the dynamic generation of the network and therefore itslack of predictability. While existing measures can deter ille-gal practices, they are ineffective against wholesale collusionbetween the election authorities.

The integrity of the system is also enhanced by the logsof server transactions and the monitoring of server activityby the Administrator and the voter (Fig. 5). The combinationof server monitoring and voter verification can help detectmalicious behaviour by servers and voters. It is difficult for

a server to drop, add or modify votes without being detected.Thanks to the dynamic nature of the network, it is possible toreplace a server if it is faulty or is dishonest. All these designfeatures contribute to robustness.

Privacy

The system provides support for the anonymity of the votersand the secrecy of the vote through a combination of asym-metric encryption and blinding schemes. Privacy require-ments and anonymity in particular are also supported byarchitectural features such as onion routing and dynamicrouting allocation. The onion routing approach was consid-ered more suitable than mix nets [3] due to its impact at thetwo levels. Mix nets are concerned mainly with untraceabil-ity and operate at protocol level.

An additional feature of this implementation of onion rout-ing is that the public keys of the routing nodes do not haveto be published, since the chain is created by the Adminis-trator. A node knows only the address and the public key ofits successor. Privacy is also ensured by enforcing one-waycommunications, especially in the last two virtual spaces ofthe voting process. Privacy is further supported by the gen-eration of a random number by the voter and its inclusionwith the ballot rather than the reliance on the transmission ofa receipt by the Counter.

123

260 SOCA (2012) 6:249–266

Coercion resistance

There is a potential conflict between coercion resistance andindividual verifiability in e-voting schemes. The ability ofvoters to check that their vote was recorded accurately maymake them vulnerable to coercion. It has been argued that insome voting contexts, coercion resistance may not be a funda-mental requirement [18]. This is relevant to student electionsand online specialist communities such as ACM and IEEE.Helios is a system where the viability of a system does notdepend on coercion resistance; the focus is instead on verifi-ability. This characteristic is common to many implementa-tions of the FOO92 protocol such as Sensus [5], SEAS [15]and REVS [16].

The focus of the proposed system was deliberately onthe processing of votes and their recording in a robust man-ner. It is therefore assumed that the vote is cast as intendedwithout support for coercion resistance. It is worth men-tioning, however, that in some situations coercion resistancemay be an important aspect of robustness at protocol level.Civitas implements coercion resistance with the use of fakecredentials [17]. Recent elections have confirmed the criticalimportance of interfacing, one aspect of e-voting to whichsome researchers had already drawn attention [25].

Verifiability

Individual verifiability and universal verifiability aresupported by the accurate recording of the votes and theirsubsequent publishing without compromising privacy. Whileindividual verifiability can be performed immediately after avote is cast, for the sake of fairness, universal verifiability isonly possible after the end of the election. Verifiability canbe conducted by the stakeholders in general and the voter inparticular by using their personal random number (Fig. 6).

Through verifiability and auditing, voters can contributesignificantly to the robustness of the system at protocol level.This approach is strongly advocated in Helios. Should vot-

ers challenge the accuracy of their recorded vote, they wouldhave to produce the ballot and the random number signed bythe Validator.

Recoverability

The provision for recoverability and its implementation mayrequire the maintenance of state in different servers and atdifferent stages of the voting process. This requirement maynot conform to the proposed approach, which is characterisedby minimal statefulness in order to safeguard privacy.

In SOREV recoverability is not supported explicitly.Instead, a pre-emptive approach is adopted which preservesthe integrity and the privacy of the system. Regular and reli-able backup is performed on servers that record votes. Thestate that DHT-based servers hold can be reconstructed with-out loss of information since it is read-only. Recoverabilityis facilitated by the dynamic allocation of servers if failuresoccur.

Recoverability is made possible by the facility that votershave, through verifiability, to check the status of their votes.They can resend their ballot if it has not been recorded.

6.2 Robustness at system level

Robustness at system level will be considered in terms ofresilience, scalability, flexibility and cost. More emphasiswill be put on resilience as it is the most critical componentof robustness.

Resilience

Voter intervention in an e-voting system may be a source ofinsecurity. Voters are not trusted because of their autonomyand the arbitrary and unsupervised nature of their interven-tion. The impact of malicious attacks is mitigated by thedynamic generation of the routing path, the absence of obvi-ous patterns in the composition of the system, the verification

Fig. 6 Individual verifiability

123

SOCA (2012) 6:249–266 261

Fig. 7 Server availability

process and the use of aliases. Furthermore, only legitimatevoters are given a path to the servers, and each voter is givenaccess to the first routing node only.

Denial of service attacks can take different forms, andmany countermeasures were proposed to deal with theseattacks at different levels. In some systems, filters on the net-work are used for detecting and blocking DOS attacks [26].At operating system (OS) level, protocols can be configuredto deter DOS attacks. DOS attacks rely on the knowledgeof the architecture of the networks and of the servers. Theresilience of the proposed system is underpinned by thisassumption. For its defence against DOS attacks, the pro-posed system relies primarily on the just-in-time (JIT) com-position, its flexible configuration with onion routing, as wellas the limited knowledge of the network structure and of theservers by the different election authorities and by the voter.This can be an impediment to mapping out the network struc-ture and mounting concerted DOS attacks. This task is sup-ported by the active monitoring of the servers. The abilityto replace defective or rogues servers by new ones can alsolimit the impact of the DOS attacks (Fig. 7).

The dynamic composition of the servers and the provisionof dynamic routes can be considered as ‘temporal distribu-tion’ when opposed to the ‘spatial distribution’ promoted byREVS and Prêt à Voter. Different routes can be active at thesame time. The JIT approach enhances reliability as onlyworking and available servers are selected; in addition, themonitoring process helps with the detection of faulty serversand their replacement if required. Furthermore, at a lowerlevel, the chain of routing nodes can be constructed adap-tively in such a way as to minimise network congestion andto overcome network partitions.

In the proposed system, no state is maintained on the inter-mediate servers, such as the Validator, routing nodes andthe Collector. The distributed electoral rolls (e-rolls) holdthe list of aliases of voters, which is read-only and can berestored without loss of information. The Administrator andthe Counter maintain the state that underpins the functional-

ity and the viability of the system. Strong backup is requiredin the case of these stateful servers.

Scalability and flexibility

Scalability is primarily catered for by the dynamic configura-tion of the system. Large volumes of traffic can be managedby redirecting messages adaptively through appropriate pathsto servers in order to distribute load, avoid congestion andincrease throughput. This function is more effective whencombined with server monitoring.

Enhancement of the distributed system can be achieved bythe dynamic inclusion of new servers. For example, a num-ber of validators, collectors and counters can be integrateddynamically to improve processing or to replace defectiveservers. Scalability is also implicit in the distribution of stateacross a set of peers.

Flexibility is manifest at different stages of the lifetime ofthe system. At initiation, the dynamic composition of the sys-tem allows for various configurations to be deployed. In theprocessing of the votes, the ability to dynamically generatethe routing path and the selection of servers to suit environ-mental conditions is another facet of the flexibility of thesystem. This also extends to recovery from failure.

The architectural and technological features that sustainthe resilience of the system are also key factors in the supportfor scalability and flexibility. This follows from the adoptionof Web services as a versatile technology. With their affinityfor interoperability, they combine seamlessly client–serverand P2P models and guide the configuration of the looselycoupled system.

Cost

The expectation of an acceptable level of resilience and theprovision for scalability and flexibility in e-voting systems

123

262 SOCA (2012) 6:249–266

depend on the resources invested in the system and on theircost. The performance of the system can be affected, forexample, by the large number of servers that must be main-tained and by the creation and distribution of public keys.Some systems opt for a minimal set of servers [15], while oth-ers attempt to satisfy e-voting requirements through multipleand redundant servers [16,10]. In some cases, the robustnessof a system depends on the replication of mix nets and onthe use of a quorum policy [27], which incurs yet higherperformance costs.

In SOREV the overheads are mainly associated with theavailability of multiple servers and the processing of the rout-ing path. The ‘validation virtual space’ is the context of inten-sive two-way interserver communications, while the ‘trans-mission space’ is marked by heavy encryption and decryp-tion.

6.3 Architectural impact

This section offers a brief assessment of the impact of thevarious architectural features on robustness at protocol leveland at system level.

Virtual spaces

Although most e-voting systems operate implicitly withinonly two virtual spaces, three distinct phases are identifiedin this system: validation, transmission and recording. Whiletransmission and recording are relatively secure, validationinvolves many servers and two-way communications. Thelevel of activity and the patterns of behaviour it supports mayexpose the servers to malicious attacks. The distribution ofstate and tasks and the random selection of the servers forma significant part of the measures against potential attacks.

Clear identification of roles of the servers and active moni-toring of server behaviour are features that help pre-empt sin-gle points of failure and deter collusion. The use of aliasesand the dynamic generation of the routing path contribute tovoter privacy and to the security of the distributed system.

A service-oriented architecture

The adoption of Web services allows for a considerable over-lap between resilience, scalability and flexibility. This is alsoenhanced by the stateless nature of the combination of theHTTP and SOAP protocols and their support for ephemeralstate information. One significant feature against denial ofservice attacks is the limited awareness that the servers haveof each other. Additionally, one-way messages can hinderthe identification of the source of a message through trafficanalysis.

As composition is initiated by the Administrator andinvolves a number of trusted Web services that possess secu-rity capabilities and are subject to security constraints, it canbe stated that the composition process is inherently secu-rity conscious [28]. Moreover, the resilience of the system isenhanced by the loosely coupled configuration of Web ser-vices.

Architectural components

The merits of the architectural and technological featuresof the system have been outlined in the previous sections.A more focused assessment of their impact on robustness atthe two levels is given in Table 1. The elements of interestinclude the service-oriented architecture, JIT composition,e-roll nodes, onion routing and one-way communication. Thetable identifies the core components of robustness that wereaffected. At protocol level, it is the integrity and privacy,whereas at system level, it is mainly resilience, scalabilityand flexibility. Both integrity and privacy are supported bystrong encryption.

6.4 Comparative evaluation

A comparative evaluation with other, albeit older, implemen-tations of the FOO92 protocol will shed some light on the dif-ferent forms of robustness and its distinctive features. Unlikemore recent implementations of e-voting schemes which aremainly concerned with protocol level, systems such as Sen-sus and REVS have the merit of presenting concrete imple-mentations that implicitly or explicitly address robustness atsystem level as well.

At protocol level, the comparative evaluation (Table 2)indicates that no system satisfies fully the criterion of recov-erability. In many respects Sensus is weaker than REVS and

Table 1 Architectural impact

Protocol level System level

Service-oriented architecture Integrity Resilience

Scalability

Flexibility

e-Roll node Integrity Resilience

Privacy Scalability

Onion routing Integrity Resilience

Privacy Scalability

Flexibility

One-way communication Privacy Resilience

Scalability

123

SOCA (2012) 6:249–266 263

Table 2 Protocol level comparison

Sensus REVS SOREV

Integrity Potential cheating by Validator(resolved in SEAS)

Collusion resistance throughquorum policy

Collusion resistance throughdistribution of tasks

Potential collusion between servers Votes cannot be forged becauseof quorum policy

Can be sensitive to DOS attacksbecause of maintenance ofstate at different stages

Indirect access to e-roll datawith the use of aliases

Use of transaction logsMost operations are idempotent

Privacy Strong encryption of ballot(secret vote)

Two undifferentiated virtualstates

Anonymity not guaranteed(assumed)

Two virtual spacesCommunications signed and

encryptedReceipt-free systemUnique identification of ballotCoercion resistance notsupported

Strong encryption of ballotThree virtual spacesSigned transactionsReceipt-free systemUse of random UUID (RN) for

personal verificationCoercion resistance notsupported

Receipt-based (two-way communication)Coercion resistance not supported

Verifiability Individual verifiability supported Individual verifiability supported Individual verifiability supportedUniversal verifiability not supported Universal verifiability supported Universal verifiability supported

Recoverability Not addressed explicitly Not addressed explicitly Not addressed explicitlyInaccurate votes can be

detected by voterPre-emptive approach to

cheating and failure throughreplication of servers andquorum policy

Pre-emptive approach to deterand minimise effect ofmalicious behaviour

SOREV. In addition to the lack of universal verifiability,its support for integrity is restricted and anonymity is notguaranteed. REVS and SOREV present similar capabilitiesbut differ in the way they implement integrity. REVS reliesmainly on an explicit quorum policy while SOREV combinesaliases, distributed state, intermediate servers and dynamicrouting to achieve integrity.

At system level (Table 3), both REVS and SOREV havebenefited from the experience of Sensus and satisfy most ofthe e-voting requirements; they display a number of advancedfeatures. Sensus was, however, designed with minimalresources and with multi-function servers; as a result, itsoverheads are lower.

Although REVS and SOREV are close in many ways,the fundamental difference between them lies in the waythey deal with resilience. REVS opts for the redundant rep-lication of servers with alternative routing to support a quo-rum policy. Moreover, the need to facilitate ‘resumability’requires the maintenance of state across the whole system.SOREV, on the other hand, favours the dynamic allocationand configuration of servers and the dynamic route genera-tion. To some extent, the ‘spatial distribution’ of resourcesin REVS is equivalent to their ‘temporal distribution’ in SO-REV. This difference has implications for scalability, flexi-bility and cost. Although both provide equivalent support forscalability, SOREV offers more flexibility at system levelthan REVS and makes full use of its resources, a feature thathelps minimise cost.

In REVS the cost is mainly due to the overheads of the quo-rum policy; in SOREV it is the route generation that requiresheavy processing. It can be concluded from the two tablesthat REVS performs better at protocol level, whereas SOREVsatisfies better the system level criteria.

This comparison may present Sensus in a relatively poorlight. However, the system has the merit of being one the firstrealistic implementations of the FOO92 protocol. It servedas a model for many e-voting schemes. Some of its limita-tions are mainly due to the restricted number of servers. Incontrast to previous systems, some recent e-voting systemssuch as Civitas, Prêt à voter and Helios appear to be moreconcerned with the protocol level and with a stronger form ofverification. Despite their concern with integrity and privacy,with the exception of Civitas, coercion resistance is still notsupported in many e-voting systems.

6.5 Contribution

The review of e-voting systems has highlighted an over-whelming concern with protocol design and conformanceto e-voting requirements. In most of these systems, robust-ness at system level is not dealt with explicitly. It is oftenassumed that techniques for addressing robustness can besubsequently grafted onto the system.

The main contribution of this work lies in the explicitapproach to robustness in e-voting systems. This involvedfirstly a distinction between two types of robustness and

123

264 SOCA (2012) 6:249–266

Table 3 System level comparison

Sensus REVS SOREV

Resilience Existence of anonymous channelassumed but not implemented

Server can act as single point offailure

Achieved through distributedloosely-coupled servers

Replication of servers to ensureresilience to DOS attacks

Alternative servers/paths can beused

Anonymous channel supportedthrough onion routing

Dynamic route generationOne-way communication in the

last two virtual spacesSystem monitoringDynamic replacement of faulty servers

Scalability Static set of serversSystem can however be augmented

manually by additional servers

Scope for expansion in thereplication of servers

Supported by parallel selectionand operation of servers

Many elections can be run atthe same time

Supported by JIT dynamicconfiguration of servers androuting path

Facilitated by Web ServicesDistribution of state and tasksSupport for multiple simultaneous elections

Flexibility Static configurationTightly coupled systemsFlexibility of ballot formatUnix-based system

Static configuration involving anumber of servers

Flexible replication of serversRMI over SSL communication

(need for Java Virtual Machine)

Dynamic Web Servicescomposition

Dynamic route generationFlexible configurationLoosely coupled systemsDynamic reallocation of servers

after failure or cheating

Cost Three types of serversStateful serversMinimal number of messagesEfficient use of resources and

processing

Five types of serversReplication of serversQuorum policyStateful client and servers

(resumability)Heavy communication between

servers at all levelsUse of multiple servers

performing the same taskHeavy asymmetric encryption

Six types of serversDynamic allocation and

processing of routing pathMultiple e-roll serversTwo-way messages in the first

virtual space (validation)One-way messages in the

transmission and recordingvirtual spaces

Use of open source technologyHeavy asymmetric encryption

secondly the design of a service-oriented architecture whichintegrates appropriate technologies in order to address thetwo forms of robustness simultaneously.

The design of the underlying distributed system wasguided by a number of concepts [8]:

• distributed trust concepts, separation of concern and pro-cessing to prevent collusion;

• restriction of access to state information to deter cheating;• distribution of e-roll state, use of aliases and unique iden-

tifiers to enhance the privacy of voters;• establishment of stateless servers to enhance reliability

and recovery;• dynamic assignment of routes and servers to counter mali-

cious behaviour and facilitate system efficiency.

Although the focus of the work is robustness, the proposedarchitecture provides full support for the e-voting process andsatisfies all the e-voting requirements with the exception of

coercion resistance. The identification of three virtual spacesplayed a significant part in achieving this conformance.

7 Further work

The proposed approach to the development of e-voting sys-tems offers scope for improvement and extension. Areas forfurther work are sketched below.

7.1 Enhancement with BPEL

The Web Services composition process is ad hoc. A more dis-ciplined approach can be supported by enabling WS-BPELto preside over the management of Web services. WS-BPELoffers better transaction handling and can be used to orches-trate a set of web services to perform a specific task.

WS-BPEL could be used to formalise the description ofthe interactions between the different Web services in thesystem. In addition to starting and ending an election, this

123

SOCA (2012) 6:249–266 265

would facilitate the process of monitoring the behaviour ofagencies in the system. If a change of status was found, theexception handlers would be called accordingly.

7.2 Server replication

The Administrator performs many functions and holds infor-mation critical to the whole process. This centralisation canbe detrimental to the integrity of the system. A more robustand secure approach would involve the generation of thecodes and aliases by a separate election authority followedby their distribution to different servers. This would preventthe Administrator from, for example, fabricating false iden-tities and voting on their behalf or colluding with other agen-cies.

Similarly, a single Counter is vulnerable to attacks andmay be a single point of failure. It is possible to improvethe resilience of the system by specifying different Coun-ters through the Collector or a set of Collectors. The finaltally would be gathered from all the Counters. Alternatively,two counters could be provided that receive similar messagesfrom the Collector. This scheme ensures resilience, verifica-tion and accuracy through mirroring. This would, however,incur some performance overheads.

7.3 Onion routing

Onion routing has the advantage of promoting decentralisa-tion and distribution. This method of communication couldbe generalised to the exchange of messages between serv-ers. It can present a more effective defence against denialof service attacks and collusion, since the routing nodes arearbitrarily selected. Servers need not be aware of the sourceof a message as long as the signature is valid. The introduc-tion of further redundancy into the system may be costly andmay affect adversely its reliability.

7.4 Mobility

Many are advocating the use of mobile devices in e-votingsystems [29]. It is argued that the ability of voters to votefrom their mobile devices would lead to greater flexibility andwould encourage greater participation in elections. Althoughthis enhancement would meet the mobility requirement, theintroduction of mobile devices raises a number of issues.Mobile networks are notoriously difficult to manage; the adhoc and intermittent interventions of mobile devices poseserious issues of authentication and security. It is, however,the current limitations of these devices that could be the mainobstacle to their integration into e-voting systems [30]. Inaddition to computational and memory constraints, batteryrestrictions can lead to discontinuity in processing and lossof votes.

8 Conclusion

In this paper the implementation of the FOO92 protocol wasused as a vehicle for presenting a perspective on robustness ine-voting systems. It is characterised by a distinction betweenrobustness at protocol level and robustness at system level,and the identification of technologies and their integrationinto a service-oriented architecture in order to address thetwo forms of robustness simultaneously. With its emphasison the distribution of state, the decentralisation of tasks, theJIT routing configuration, the use of aliases and the activemonitoring of server activity, the proposed approach aims atpromoting the design of robust e-voting systems. This is sup-ported by the implementation of the servers as Web Servicesand their dynamic composition. This perspective on robust-ness offers scope for wider decentralisation, scalability andflexibility and invites a more integrated and holistic approachto the development of e-voting systems. It contributes ulti-mately to the satisfaction of most e-voting requirements.

References

1. Kremer S, Ryan MD, Smyth B (2010) Election verifiability inelectronic voting protocols. In: Proceedings of the fifteenth Euro-pean symposium on research in computer security (ESORICS’10).LNCS, Springer, vol 6345, pp 389–404

2. Chaum D (1981) Untraceable electronic mail, return addresses,and digital pseudonyms. Commun ACM 24(2):84–88

3. Sampigethaya K, Poovendran R (2006) A survey on mix networksand their secure applications. Proc IEEE 94(12):2142–2181

4. Syverson PF, Goldschlag DM, Reed MG (1997) Anonymousconnections and onion routing. IEEE symposium on security andprivacy, IEEE, pp 44–54

5. Cranor L, Cytron RK (1997) Sensus: a security-conscious elec-tronic polling system for the internet. In: Proceedings of HICSS’97,IEEE, pp 561–570

6. Fujioko A, Okamoto T, Ohta T (1992) A practical secret votingscheme for large-scale elections. In: Proceedings of advances incryptology, AUSCRYPT’92, Springer, pp 244–260

7. Volkamer M, Grimm R (2010) Determine the resilience of eval-uated internet voting systems. In: First international workshopon requirements engineering for e-voting systems (RE-VOTE),Atlanta, USA, pp 47–54

8. Weldemariam K, Volkamer M, Villafiorita A (2011) “e-voting:what we learned, where we are going to”. In: Proceedings of thesixth international workshop on frontiers in availability, reliabilityand security, (FARES 2011), Vienna, Austria

9. Schneier B (1996) Applied Cryptography. Wiley, New York10. Ryan PYA, Bismark D, Heather J, Schneider S, Zhe X (2009) The

Prêt à voter verifiable election system. IEEE Trans Inf Forens SecurSpec Issue Electron Voting 4(4):662–673

11. Benaloh J, Fischer M (1985) A robust and reliable cryptograph-ically secure election scheme. In: Proceedings of the 16th IEEEsymposium on the foundations of computer science, Los Angeles,USA, pp 372–382

12. Chaum D (1983) Blind signatures. In: Proceedings of Crypto 8213. Ansari N, Sakarindr P, Haghani E, Zhang C, Jain AK, Shi YQ

(2008) Evaluating electronic voting systems equipped with voter-verified paper records. IEEE Secur Priv, pp 30–39

123

266 SOCA (2012) 6:249–266

14. Jackson S (2007) A multidisciplinary framework for resilience todisasters and disruptions. J Integr Des Process Sci 11:2

15. Baiardi F, Falleni A, Granchi R, Martinelli F, Petrocchi M,Vaccarelli A (2005) SEAS, a secure e-voting protocol: design andimplementation. Comput Secur pp 642–652

16. Joaquim R, Z′uquete A, Ferreira P (2003) REVS—a robust elec-tronic voting system. IADIS Int J WWW/Internet 1:2

17. Clarkson MR, Chong S, Myers AC (2008) Civitas: toward asecure voting system. IEEE Symposium on Security and Privacy,Oakland, USA, pp 54–368

18. Adida B (2008) Helios: web-based open-audit voting. In: Proceed-ings of the 17th USENIX security symposium (Security ’08), SanJose, USA, July–August 2008

19. Carl G, Kesidis G, Brooks RR, Rai S (2006) Denial-of-serviceattack-detection techniques. IEEE Internet Comput 10(1):82–89

20. Tsekmezoglou E, Illiadis J (2005) A critical view of voting tech-nology. Electron J E-Commer Tools Appl 1:4

21. Dingledine R, Mathewson N, Syverson P (2004) Tor: the second-generation onion router. In: Proceedings of the 13th USENIX secu-rity symposium

22. Camenisch J, Lysyanskaya A (2005) A formal treatment of onionrouting. In: Proceedings of CRYPTO’2005, Lecture Notes in Com-puter Science, vol 3621, pp 169–187

23. Curbera F, Duftler M, Khalaf R, Nagy W, Mukhi N, Weerawar-ana S (2002) Unravelling the web services web—an introductionto SOAP, WSDL, and UDDI. IEEE Internet Comput 3:4

24. Langer L, Schmidt A, Buchmann J, Volkamer M (2010) A taxon-omy refining the security for electronic voting: analysing helios as aproof of concept. In: 2010 International conference on availability,reliability and security, Krakow, Poland

25. Rivest R, Electronic Voting, http://theory.lcs.mit.edu/~rivest/Rivest-ElectronicVoting.pdf

26. Abdelsayed S, Glimsholt D, Leckie C, Ryan S, Shami S (2003) Anefficient filter for denial-of-service bandwidth attacks. In: IEEEglobal telecommunications conference, (GLOBECOM ’03), vol 3,pp 353–357

27. Jakobsson M, Juels A, Rivest RL (2002) Making mix nets robustfor electronic voting by randomized partial checking. USENIXSecurity Symposium, pp 339–353

28. Carminati B, Ferrari E, Hung PCK (2006) Security conscious webservice composition. In: 2006 IEEE international conference onweb services (ICWS 2006), Chicago, USA, pp 489–496

29. Campanelli S, Falleni A, Martinelli F, Petrocchi M, Vaccarelli A(2008) A mobile implementation and formal verification of ane-voting system. In: Proceedings of Internet and Web Applicationsand Services, (ICIW’08), pp 476–481

30. Ashraf K, Anane R, Bordbar B (2012) File management in a mobileDHT-based P2P environment. In: The 26th IEEE internationalconference on advanced information networking and applications(AINA-2012), Fukuoka, Japan, pp 415–422

123