Secure Online Voting System with Anonymous Message Broadcasting

Danial Aghajarian
Department of Computer Science Georgia State University Atlanta, Georgia 30303 Email: danial.aghajarian@gmail.com

Evrim Guler
Department of Computer Science Georgia State University Atlanta, Georgia 30303 Email: evrimguler@gmail.com Secure communication: Message broadcasts between users will be encrypted to ensure privacy of communication. User authentication: A zero-knowledge proof based on [1] system will be used to authenticate users without revealing to potential eavesdroppers any information that might compromise the system. Although much has been written about zero knowledge proofs, and the best of our knowledge, few products have actual implementations that depend on this class of authentication mechanisms, and none use them as effective authentication techniques for widespread dynamic communication protocols in [1], [2], [3]. There are three components to the system: 1. An Authentication Server veries the identity of all parties in the system. Authentication is the process of validating that an entity actually is who it claims to be. An entity is not only a user, but other components of the 5MBS system. 2. A Chat Server accepts messages from all clients and distributes them to all the other participating clients. It is the central message distribution point, and will encrypt all messages to guarantee privacy. 3. A Client is a user who wishes to participate in a message exchange with other authenticated users. A user interacts with a client by typing messages to be displayed on other users screens, and by reading messages typed by other participating users. The c1ient program authenticates itself to the authentication server before the user is allowed to join the system. We will present detailed state-machines for the behaviour of each of the components of the system later in this document, but the steps involved can be summarized below: 1. The chat server and the authentication server authenticate each other. 2. Users authenticate themselves to the authentication server and obtain from it a session key. The session key is used to encrypt some of the trafc to and from the user. Immediately after this key has been obtained, users obtain from the chat server a broadcast key that will be used to decrypt broadcast messages. 3. The chat server listens on your well known port for connections. Connections will come from either users or the authentication server.

AbstractAn election is an excellent example of a scenario where security and condentiality of data between parties is critical. The voters must be securely provided with a list of candidates to select from, their selection of a candidate must be securely recorded and their choice kept condential. It is also necessary for the list of voters and candidates to be kept secure, as well as the nal results of the election. This project aims to provide a sample implementation of a secure voting system concatenated with anonymous message broadcasting in which all of the prerequisites mentioned above are met. Through the use of Public-Private Key Cryptography and Symmetric Key Cryptography for all of the data in the sample implementation provided with this document is kept both secure and condential. Cryptography becomes one of the important things in the development of electronic voting system. The voting system using internet network technology aims to reduce considerable calculation time as well as necessary human resources. Securing lines of communication between voting machines and servers is needed to communicate securely. The identity of the voters, which is used for authentication voting process is stored in the server memory. Every identity card which contains unique conrmation number will be authenticated in Central Legitimization Agency server. Card identity is hashed with RSA and encrypted with session key to assure that the integrity of data is not changed by others. Session key is distributed from CLA to voting machines which are encrypted with asymmetric RSA algorithm. Secure online voting system with anonymous message broadcasting faces a typical quandary in their requirement for communications that are at once secure and private. While the messages broadcast between authorized clients and between servers must be authentic and non repudiable, they must also ensure the clients anonymity. In this project report, we propose a secure voting system with message broadcasting for the secure and anonymous propagation of clients and server broadcast messages. A hybrid key infrastructure approach is put forth which combines the use of a shared network authorization key for devices that require anonymity and Public Key Infrastructure (PKI) for devices that do not.

I.

I NTRODUCTION

In this paper, we describe the design and implementation of a secure online voting system with anonymous secure message broadcasting. It is a secure, multiparty voting and chat program that ensures privacy in voting system and communication relied on shared secret and public keys. The system was built as a study of the course project in order to implement secure voting system combined with message broadcasting. The design of our system addresses the following issues:

4. The chat server learns about new users when the authentication server noties it of valid users. The chat server adds the new user to an internal database of registered users, and remembers the users session key. 5. When a user connects, the chat server veries that the incoming message has been encrypted using the correct session key for that user. 6. The chat server broadcasts the message to all registered users, encrypting it with a global broadcast key. It is encrypted with one broadcast key, rather than each individual users key, to speed up distributing a message. 7. Any anomaly in the communication between the chat server and the client results in the revocation of the session key for the client, the generation of a new broadcast key by the chat server and the redistribution of the key to the remaining clients. This could occur if the client does not acknowledge the receipt of a message. The chat server will assume that the client has died, and will remove that client from its database of registered users. The client will have to re-authenticate itself with the authentication server. 8. The authentication server continues to accept connections from new clients and authenticate them. Computerized voting will never be used for general elections unless there is a protocol that both maintains individual privacy and prevents cheating. The ideal protocol must at least meet these six requirements: Only authorized voters can vote. No one can vote more than once. No one can determine for whom anyone else voted. No one can duplicate anyone elses vote. No one can change anyone elses vote without being discovered. Every voter can make sure that his vote has been taken into account in the nal tabulation.

Each voter sends his vote in to the CTF. The CTF decrypts the votes, tabulates them, and makes the results public. This protocol is rife with problems. The CTF has no idea where the votes are from as in [4], so it does not even know if the votes are coming from eligible voters. It has no idea if eligible voters are voting more than once. On the plus side, no one can change anyone elses vote; but no one would bother trying to modify someone elses vote when it is far easier to vote repeatedly for the result of your choice. Another simple protocol could be: Each voter signs his vote with his private key. Each voter encrypts his signed vote with the CTFs public key. Each voter sends his vote to a CTF. The CTF decrypts the votes, checks the signatures, tabulates the votes, and makes the results public. This protocol satises properties one and two: Only authorized voters can vote and no one can vote more than oncethe CTF would record votes received in step (3). Each vote is signed with the voters private key, so the CTF knows who voted, who did not, and how often each voter voted. If a vote comes in that is not signed by an eligible voter, or if a second vote comes in signed by a voter who has already voted, the facility ignores it. No one can change anyone elses vote either, even if they intercept it in step (3), because of the digital signature. The problem with this protocol is that the signature is attached to the vote; the CTF knows who voted for whom. Encrypting the votes with the CTFs public key prevents anyone from eavesdropping on the protocol and guring out who voted for whom, but you have to trust the CTF completely. Its analogous to having an election judge staring over your shoulder in the voting booth. More complicated voting scheme takes advantage of blind digital signature scheme which is a method that signer, sign something which he/she could not have access to its content. (Here vote) In this protocol, we need to somehow dissociate the vote from the voter, while still maintaining authentication. The blind signature protocol does just that: Each voter generates a message containing a valid vote. Each voter individually blinds this message and sends it with to the CTF. The CTF checks its database to make sure the voter has not submitted his blinded votes for signature previously. Then it signs the message and sends it back to the voter, storing the name of the voter in its database. The voter unblinds the message. The voter chooses one of the votes (ah, democracy) and encrypts it with the CTFs public key. The voter encrypts his vote with the CTFs public key sends his vote in.

Additionally, some voting schemes may have the following requirement: Everyone knows who voted and who did not.

In this part we provide a secure implementation of voting system using a fully secure protocol. The rest of this report is organized as follows: Section II will represent related information to our mechanism, Section III gives the details of algorithms and methods which we used in our programming project, Section IV shows how to implement the project, and Section V will nalize our project report with a short summary. II. BACKGROUND AND R ELATED WORK

There are several ways to implement secure election systems. The simplest protocol consists of following steps: Each voter encrypts his vote with the public key of a Central Tabulating Facility (CTF).

The CTF decrypts the votes, checks the signatures, checks its database for a duplicate identication number, saves the serial number, and tabulates the votes. It publishes the results of the election, along with every serial number and its associated vote. A malicious voter, call him Trudy, cannot cheat this system. The blind signature protocol ensures that his votes are unique. If he tries to send in the same vote twice, the CTF will notice the duplicate serial number in step (7) and throw out the second vote. If he tries to get multiple votes signed in step (2), the CTF will discover this in step (3). Trudy cannot generate his own votes because he does not know the facilitys private key. He cant intercept and change other peoples votes for the same reason. A malicious CTF cannot gure out how individuals voted. Because the blind signature protocol prevents the facility from seeing the serial numbers on the votes before they are cast, the CTF cannot link the blinded vote it signed with the vote eventually cast. Publishing a list of serial numbers and their associated votes allows voters to conrm that their vote was tabulated correctly. There are still problems. If step (6) is not anonymous and the CTF can record who sent in which vote, then it can gure out who voted for whom. However, if it receives votes in a locked ballot box and then tabulates them later, it cannot. Also, while the CTF may not be able to link votes to individuals, it can generate a large number of signed, valid votes and cheat by submitting that itself. And if Alice discovers that the CTF changed her vote, she has no way to prove it. One secure nal solution is to divide the CTF in two. Neither party would have the power to cheat on its own.The following protocol explained in [5] uses a Central Legitimization Agency (CLA) to certify voters and a separate CTF to count votes: Each voter sends a message to the CLA asking for a validation number. The CLA sends the voter back a random validation number. The CLA maintains a list of validation numbers. The CLA also keeps a list of the validation numbers recipients, in case someone tries to vote twice. The CLA sends the list of validation numbers to the CTF. Each voter chooses a random identication number. He creates a message with that number, the validation number he received from the CLA, and his vote. He sends this message to the CTF. The CTF checks the validation number against the list it received from the CLA. If the validation number is there, the CTF crosses it off (to prevent someone from voting twice). The CTF adds the identication number to the list of people who voted for a particular candidate and adds one to the tally. After all votes have been received, the CTF publishes the outcome, as well as the lists of identication numbers and for whom their owners voted. Like the previous protocol, each voter can look at the lists of identication numbers and nd his own. This gives him proof that his vote was counted. Of course, all messages

passing among the parties in the protocol should be encrypted and signed to prevent someone from impersonating someone else or intercepting transmissions. The CTF cannot modify votes because each voter will look for his identication string. If a voter doesnt nd his identication string, or nds his identication string in a tally other than the one he voted for, he will immediately know there was foul play. The CTF cannot stuff the ballot box because it is being watched by the CLA. The CLA knows how many voters have been certied and their validation numbers, and will detect any modications. Trudy, who is not an eligible voter, can try to cheat by guessing a valid validation number. This threat can be minimized by making the number of possible validation numbers much larger than the number of actual validation numbers: 100-digit numbers for a million voters, for example. Of course, the validation numbers must be generated randomly. Despite this, the CLA is still a trusted authority in some respects. It can certify ineligible voters. It can certify eligible voters multiple times. This risk could be minimized by having the CLA publish a list of certied voters (but not their validation numbers). If the number of voters on this list is less than the number of votes tabulated, then something is awry. However, if more voters were certied than votes tabulated, it probably means that some certied people did not bother voting. Many people who are registered to vote do not bother to cast ballots. This protocol is vulnerable to collusion between the CLA and the CTF. If the two of them got together, they could correlate databases and gure out who voted for whom. Various means of anonymizing network trafc have been proposed in the literature and may be categorized as infrastructure-based, cryptography-based or protocol-based. Infrastructure-based Anonymity: Specialized network servers known as anonymizers are used to hide a senders identity from potential eavesdroppers, for example in the onion routing protocol introduced by [6] and in the Crowds web transaction anonymizer scheme proposed by [7]. [8] adapts the anonymizer concept to the domain of pervasive computing by introducing common mix zones in which users change pseudonyms, so that observers cannot match a user identity departing the zone to its identity upon entry. Spatio-temporal cloaking and its related concept, kanonymity, are suggested by [9], as well as [10], to provide a means to protect a users identity from Location-Based Service (LBS) providers. By aggregating the requests bound for a given LBS provider until one user is indistinguishable from k 1 other users, either with respect to physical location or the timing of the request, an anonymity server can protect a users precise identity and location. However, the inherent necessity for all messages to be routed through middleware make infrastructure-based anonymity measures infeasible for vehicular networks, given the requirement for low latency and scalability, as well as the need for precise vehicle locations to be available for many applications. Cryptography-based Anonymity: One mechanism for rendering PKI anonymous is outlined by [11]. It allows a Certicate Authority (CA) to issue multiple

anonymous certicates based on an original one, so that any message signed with an anonymous certicate can be traced back to the original certicate owner by the CA. The additional certicates act as pseudonyms for the owner and can be changed periodically to retain anonymity. However, as with any alias, they can become trackable over time unless frequently changed, and an algorithm for managing suitable switching intervals is lacking, as are the means for certicate revocation. Group signatures, on the other hand, were pioneered by [12] to allow a message to be signed by any member of a predened group with the members private key, while allowing a recipient to verify the signature with a shared group public key. In this manner, no recipient or eavesdropper can know which private key was used to generate the signature, except for a group manager who can open a signature if necessary to trace it to the original signing private key. Unfortunately, some group member revocation schemes, such as the one advanced by [13], require generating signatures of proportional size to the number of group members. In a vehicular network encompassing millions of vehicles, this is unscalable. Others, such as the scheme suggested by [14], require a group manager to reissue and disseminate new group certicates to the remaining members for every revocation. [15]s scheme using a xed signature size requires every remaining group member to calculate a new private key and group public key based on the exhaustive list of revoked members each time a member is revoked. The means for such a list to be effectively disseminated to remaining group members, in a reliable and scalable fashion, is not explored and represents an important obstacle to the success of such a list-based revocation scheme. Overall, group signatures appear to be better suited to smaller, more manageable groups than vehicular networks. Protocol-based Anonymity: A number of PKI-based protocols have been suggested for introducing anonymity in Vehicular Ad Hoc Networks (VANETs). In [16], the authors suggest that each vehicle be equipped with a set of pre-loaded certicates and that the vehicle periodically switch to a new one in order to maintain anonymity. However, it is unclear how rogue device repudiation and revocation could be successfully implemented. In the event that a rogue device is identied and directed to destroy its compromised certicate, mechanisms must be put in place to ensure compliance. Another pitfall in this approach concerns its scalability. Sufcient numbers of certicates must be issued for each vehicle to maintain anonymity over a signicant period of time. As a result, the size of the certicate database to be searched by a CA in order to match a compromised certicate to its owners identity is daunting. In [17], the authors propose a dynamic key distribution system where vehicles periodically request new certicates from a CA, but this places an additional load on the CA in addition to the network. In [18], the authors outline a scheme where vehicles are organized into groups, and only group leaders broadcast messages while the remaining members maintain silence in order to promote anonymity. However, given the high volume of messages required for vehicle safety applications, silent periods are not suitable for broadcast messages. In our implementation, we used the rst protocol which is infrastructured-based anonymity to hide user/client information from eavesdroppers.

III.

A LGORITHMS AND M ETHODS

In this section, we explain which algorithms we used in our programming project. As mentioned in the following sections for creating secure system, we used RSA asymmetric, Rijndael symetric keys encryption methods, and hash function to generate random numbers. Further, we will explain how to use our secure voting and message broadcasting protocols in this section. 1) RSA Algorithm: The RSA cryptosystem is the most widely-used public key cryptography algorithm in the world. It can be used to encrypt a message without the need to exchange a secret key separately. The RSA algorithm can be used for both public key encryption and digital signatures. Its security is based on the difculty of factoring large integers. Party A can send an encrypted message to party B without any prior exchange of secret keys. A just uses Bs public key to encrypt the message and B decrypts it using the private key, which only he knows. RSA can also be used to sign a message, so A can sign a message using their private key and B can verify it using As public key. RSA algorithm is consisting of 5 parts which are key generation, encryption, decryption, digital signing, signature verication. Key Generation Algorithm: This is the original algorithm. In the algorithm, n is known as the modulus, e is known as the public exponent or encryption exponent or just the exponent, d is known as the secret exponent or decryption exponent. Generate two large random primes, p and q , of approximately equal size such that their product n = pq is of the required bit length, e.g. 1024 bits. Compute n = pq and (phi) = (p 1)(q 1). Choose an integer e, 1 < e < phi, such that gcd(e, phi) = 1. Compute the secret exponent d, 1 < d < phi, such that ed1(modphi). The public key is (n, e) and the private key (d, p, q ). Keep all the values d, p, q and secret. We prefer sometimes to write the private key as (n, d) because you need the value of n when using d. Other times we might write the key pair as ((N, e), d).

Encryption: Sender A does the following: Obtains the recipient Bs public key (n, e). Represents the plaintext message as a positive integer m, 1 < m < n Computes the ciphertext c = memodn. Sends the ciphertext c to B.

Decryption:

Recipient B does the following: Uses his private key (n, d) to compute m = cdmodn. Extracts the plaintext from the message representative m.

Digital Signing: Sender A does the following: Creates a message digest of the information to be sent. Represents this digest as an integer m between 1 and n-1. Uses her private key (n, d) to compute the signature s = mdmodn. Sends this signature s to the recipient, B.

focus of the analysis was on the ciphers security, but the choice of Rijndael was based on its simple algorithm and implementation characteristics. There were several candidate algorithms but Rijndael was selected because based on the analyses and also we used RSA encyrption method in the other section of our programming project, it had the best combination of security, performance, efciency, ease of implementation and exibility. With an iterated block cipher, the different transformations operate in sequence on intermediate cipher results (states). The design of Rijndael is based on easily understandable mathematical concepts including nite eld mathematics and linear algebra for matrix manipulation. Key and Block Size: A prime feature of Rijndael is its ability to operate on varying sizes of keys and data blocks. It provides extra exibility in that both the key size and the block size may be 128, 192, or 256 bits. Since Rijndael species three key sizes, this means that there are approximately 3.4x1038 possible 128-bit keys which we used in the project, 6.2x1057 possible 192-bit keys and 1.1x1077 possible 256-bit keys. To compare, DES keys are only 56 bits long, which means there are approximately 7.2x1016 possible DES keys. Therefore, there are on the order of 1021 times more AES 128-bit keys than DES 56-bit keys. The Sub key and the Key Schedule: The sub keys are derived from the cipher key using the Rijndael key schedule. The cipher key is expanded to create an expanded key and the sub key is created by deriving a round key by round key. The required round key length is equal to the data block length multiplied by the number of rounds plus 1. Therefore, the round keys are taken from the expanded key. To maintain a secure system, the expanded key is always derived from the cipher key. This method ensures that the expanded key is never directly specied, which would open Rijndael up to several cryptanalytic attacks against its key generation methods. Recall that the security of this system depends entirely on the secrecy of the key, as the design of the algorithm itself is public and contains no secrecy. Whole Byte operations: There are several mathematical preliminaries that dene the addition and multiplication operations within a nite eld and with matrices. When performing nite mathematics, the bytes are treated as polynomials rather than numbers, which can allow different and occasionally allows for more simple implementations. Encyphering with Rijndael: The Rijndael cipher is an interactive block cipher. It therefore consists of a sequence of transformations to encipher or decipher the data. Rijndael encryption and decryption begin and end with a step to mix subkeys with the data block. This extra step is done as a protection against cryptanalysis. To encipher a block of data in Rijndael, you must rst perform an Add Round Key step (XORing a subkey with the block) by itself, then the regular transformation rounds, and then a nal round with the Mix Column step omitted. The cipher itself is dened by the following steps:

Signature Verication: Recipient B does the following: Uses sender As public key (n, e) to compute integer v = semodn. Extracts the message digest from this integer. Independently computes the message digest of the information that has been signed. If both message digests are identical, the signature is valid.

2) Rijndael Algorithm: Rijndael is the block cipher algorithm recently chosen by the National Institute of Science and Technology (NIST) as the Advanced Encryption Standard (AES). It is supported by the Data Encryption Standard (DES). NIST selected Rijndael as the standard symmetric key encryption algorithm to be used to encrypt sensitive (unclassied) American federal information. The choice was based on a careful and comprehensive analysis of the security and efciency characteristics of Rijndaels algorithm. Rijndael is an iterated block cipher. Therefore, the encryption or decryption of a block of data is accomplished by the iteration (a round) of a specic transformation (a round function). This section provides the details of the Rijndael functions. Rijndael also denes a method to generate a series of subkeys from the original key. The generated subkeys are used as input with the round function. Rijndael was developed by Belgian cryptographers Joan Daemen of Proton World International and Vincent Rijmen of Kathlieke Universiteit Leuven. The algorithm that they developed was designed as an easily understandable mathematical structure that can be broken down into simple components. Daemen and Rijmen write in their proposal to AES that Rijndael was designed based on the following three criteria: Resistance against all known attacks, Speed and code compactness on a wide range of platforms, Design simplicity

Rijndael was evaluated based on its security, its cost and its algorithm and implementation characteristics. The primary

1) 2) 3)

an initial Round Key addition N r 1 Rounds a nal round.

Where Nr is the number of rounds that must be performed. Nr depends on the length of the data block (N b) and the length of the key (N k ). Not counting an extra round performed at the end of encipherment, the number of rounds in Rijndael is: 9 if both the block and the key are 128 bits long, 11 if either the block or the key is 192 bits long, and neither of them is longer than that, and 13 if either the block or the key is 256 bits long. The pseudocode of Rijndael encryption method is in the following: KeyExpansion(CipherKey, ExpandedKey); ... Rijndael(State, ExpandedKey) { AddRoundKey(State, ExpandedKey[0]); for(i=1; i<Nr; i++) Round(State, ExpandedKey[i]); FinalRound(State, ExpandedKey[Nr]); } ... Round(State, RoundKey) { ByteSub(State); ShiftRow(State); MixColumn(State); AddRoundKey(State, RoundKey); } ... FinalRound(State, RoundKey) { ByteSub(State); ShiftRow(State); /*no MixColumn*/ AddRoundKey(State, RoundKey); }. The round transformation is broken into layers. These layers are the linear mixing layer, which provides high diffusion over multiple rounds. The non-linear layer which are basically applications of the Rijndael S-box. And the key addition layer which is simply an exclusive or of the round key and the intermediate state. Each layer is designed to have its own well-dened function which increases resistance to linear and differential cryptanalysis. These layers are accomplished by four transformation steps. The Byte Sub step is a non-linear byte substitution. The Shift Row transformation is a cyclic shift. This is followed by the MixColumn step in which the columns of the State are considered as polynomials over a nite eld and are modulo multiplied with a xed polynomial. Finally, the Add Round Key step is performed. The Byte Sub step is a non-linear byte substitution that operates on each of the state bytes independently, where a state is an intermediate cipher result. The operation of this step is accomplished with a substitution table (S-box). ByteSub

returns a word in which each byte from the incoming state are mapped by the S-box to corresponding bytes. The Rijndael Sbox is simple, invertible and composed of two transformations. First, the multiplicative inverse of the data is taken in nite eld space and then an afne transformation is applied. Diffusion is dened as the minimum number of active Sboxes in a linear or differential characteristic. Diffusion is important because within block cipher cryptanalysis, almost all the attacks have a complexity that depends on the number of active S-boxes. The cryptanalytic complexity also is affected by the input/output correlation of the individual S-boxes. Linear diffusion layer results in provable lower bounds on the number of active S-boxes. They have provable lower bounds for the nonlinear order, the difference to linear functions and the resistance to linear and differential cryptanalysis. The Shift Row step ensures that the different bytes of each row do not only interact with the corresponding byte in other rows. The rows of the State are cyclically shifted with different offsets. Row 0 is not shifted, Row 1 is shifted over C1 bytes, row 2 over C2 bytes and row 3 over C3 bytes. The shift offsets C1, C2 and C3 depend on the block length Nb. The Mix Column step is where the different bytes interact with each other. It causes every byte in a column to affect every other byte. The state is viewed as polynomials and the transformation consists of matrix multiplication of the state with a multiplication polynomial over a nite eld. The mix column transformation step is the only place in Rijndaels round transformation that the columns are mixed. This step works with the Shift Row step to ensure that all parts of the block impinge on each other. 3) Hash Function: Hash functions are primarily used to generate xed-length output data that acts as a shortened reference to the original data as shown in Algorithm below: Generate Hash Number(String ClientName) { hash = 0; foreach (char c in ClientName) { hash = c+(hash<<6)+(hash<<16)-hash; } return hash; }. In our programming project, we used hash function to generate clients anonymous identication number by communication server. This is useful when the output data is too cumbersome to use in its entirety. One practical use is a data structure called a hash table where the data is stored associatively. Searching for a persons name in a list is slow, but the hashed value can be used to store a reference to the original data and retrieve constant time (barring collisions). Another use is in cryptography, the science of encoding and safeguarding data. It is easy to generate hash values from input data and easy to verify that the data matches the hash, but hard to fake a hash value to hide malicious data. This is the principle behind the Pretty Good Privacy algorithm for data validation.

Hash functions are also used to accelerate table lookup or data comparison tasks such as nding items in a database, detecting duplicated or similar records in a large le, nding similar stretches in DNA sequences, and so on. A hash function should be referentially transparent (stable), i.e., if called twice on input that is equal (for example, strings that consist of the same sequence of characters), it should give the same result. There is a construct in many programming languages that allows the user to override equality and hash functions for an object: if two objects are equal, their hash codes must be the same. This is crucial to nding an element in a hash table quickly, because two of the same element would both hash to the same slot. Hash functions are destructive, akin to lossy compression, as the original data is lost when hashed. 4) Voting Protocol: The protocol used for voting part of this project can be shown in Figure 1. In this protocol there are some parties in this protocol: Authorizer: This party, denes the authorized voters, signed their votes and generally causes only authorized voters be able to vote. Counter: This party, mainly, received votes from authorized voters and counts the result. Public: public means set of all people participating or not participating in the voting. Voter: person who is going to vote. The protocol consists of following steps: Every voter chooses a vote and signs it by his private key. Then he/she encrypts his/her vote using public key of authorizer and sends the message to him (#1). In this step we have a two way authentication. Authorizer makes sure that voter is valid and also he has not voted before. Then signs his electronic ballot. Authorizer also generates conrmation number and sings it. Finally authorizer sends signed vote and signed conrmation number to the voter. The authorizer sends this conrmation number to counter too letting counter knows authorized people to vote. This communication between Counter and Authorizer is also secured using two-ways authentications. Now voter has a valid vote. Later on, he can decide vote or not to vote. But he can vote at most once. For voting, he rst has to unblind his vote and then sends it to counter. The message he sends is including signed unblended message as well as signed conrmation number. The message must be encrypted using counter public key. It is worth mentioning that here we have one-way authentication and counter should not know identity of voter. After receiving a vote, counter check its conrmation number and if it is valid and also has not voted before, he accepts the vote and generate a serial number for vote and signs a message including this serial number and vote and sends it back to voter. Later voter can keep track of his vote using this signed message and also can claim about any change in his vote. Finally, Authorizer announces publicly number of authorized voter to prevent Counter from counting extra ballots.
Fig. 1. The scheme of Voting Protocol

Also the Counter announces list of (serial numbers, votes) with result of election. So every voter can easily nd his serial number and make sure that his vote is counted correctly. This protocol satises all six requirements that we talk about them in the introduction. The only way to cheat in this mechanism is collusion between Counter and Authorizer. Using both conrmation numbers which are in the hands of Authorizer and serial numbers which only Counter knows them, one can simply disclose for whom every one voted. In this secure protocol, the voter is the only one who knows both serial number and conrmation number. Finally, by choosing Authorizer and Counter facilities from two completely independent parties, we can make this protocol completely secure and even usable in real scenarios. 5) Messaging Protocol: Clients and servers exchange messages in a request-response messaging pattern. As shown in Figure 2, the client sends a request, and the server returns a response in order to establish a connection between authorized client and server. To communicate, the computers must have a common language, and they must follow rules so that both the client and the server know what to expect. The language and rules of communication are dened in a communications protocol. All client-server protocols operate in the application layer. In this communication protocol, authorized client sends a connection request to the chat server, then if it has a authorization ID, the chat server will create a anonymous ID for the client, and send it back to client. After getting anonymous ID of the client from the chat server, the client can send a message to broadcast this message to all authorized clients connected to the chat server. Before sending the message, client is encrypting the message using Rijndael algorithm. When the chat server is getting this message from the authorized client, it is immediately sending this message message to all authorized clients with anonymous ID of sender of message in the servers database. Whether a computer is a client, a server, or both, it can serve multiple functions. For example, a single computer can run web server and le server software at the same time

Secure Message Design

Client Connect H(ID) R (M) Communication Server

The content of the message should be blinded to the signature; the signer of the blind signature should not see the content of the message. Unforgettability: Only the signer can give a valid signature for the associated message. Untraceability: The signer of the blind signature is unable to link the message-signature pair even when the signature has been revealed to the public. David Chaum was rst scholar to propose the concept of the blind signature scheme in 1982 as in [19]. The blind signature scheme is a method, which guarantees the anonymity of the participants. A short illustration of blind signature is described in the following [19]: Blinding: The requester blinds the message m,with a random number b. This results in blind(m, b). Signing: The signer signs this message, resulting sign((blind(m, b), r), where r is signers private key. Unblinding: The requester then unblinds the message using b, results in unblind(sign(blind(m, b), r), b). Signature Verication: Anyone can use the signers public key to verify whether the signature is authentic or not. This concept is widely used in electronic voting systems, thats why we used this protocol in our ballot mechanism to ensure system security. IV. I MPLEMENTATION in

R(M)|H(ID) Clients

Fig. 2.

Messaging Protocol Between Client and Chat Server

to serve different data to clients making different kinds of requests. Client software can also communicate with server software on the same computer. Communication between servers, such as to synchronize data, is sometimes called interserver or server-to-server communication. The chat server and client transfer information between each other through the computer network using a communication protocol. When a chat server process is started, it will publish at least one network name that distinguishes it in the network. The server starts to listen to the network using the given network name. The network name consists of a communication protocol and a server name. To establish a connection from a client to a server they both have to be able to use the same communication protocol such as TCP/IP protocol which will explain in Section IV. The client has to know the network name of the server and often also the location of the server in the network. The client process uses the network name to specify which server it will connect to. 6) Blind Signature: The concept of blind signature was introduced by David Chaum in 1982 as in [19]. Blind signatures are the basic tools in digital cash payment systems and electronic voting systems. For instance, in digital cash payment systems, using a blind signature scheme a requester can obtain from a bank a digital coin, that is a token properly signed by the bank. The goal of blind signature scheme is to enable a requester to obtain a signature from a signer such that the signer does not learn information about the message it signed and the requester cannot obtain more than one valid signature after one interaction with the signer as mentioned in [20]. The blind signature schemes must meet the following requirements, namely, correctness, blindness, unforgettability and untraceability [12], [19], [20]: Correctness: The correctness of the signature of a message signed through the signature scheme can be checked by anyone using signers public key. Blindness:

In this section,we are illustrating our system in detail how to implement secure online voting system with anonymous message broadcasting. To create this scheme, we used clientserver based communication using TCP/IP protocol as shown in Figure 3. TCP/IP connections work in a manner similar to a telephone call where someone has to initiate the connection by dialing the phone. At the other end of the connection, someone has to be listening for calls and then pick up the line when a call comes in. In TCP/IP communications, the IP Address is analogous to a telephone number and the port number would be analogous to a particular extension once the call has been answered. The Client in a TCP/IP connection is the computer or device that dials the phone and the Server is the computer that is listening for calls to come in. In other words, the Client needs to know the IP Address of whatever Server it wants to connect to and it also needs to know the port number that it wants to send and receive data through after a connection has been established. The Server only has to listen for connections and either accept them or reject them when they are initiated by a client. For the server and client side socket programming is in the following lines:

Server

Socket()

Client
Bind()

Socket()

Listen()

Connect()

Connection Establish Data Transfer Data Transfer

Accept()

Read()

Write()

Write()

Read()

Close()

Close()

tlsClient.Start(); // The while loop will check for true in this before checking for connections ServRunning = true; // Start the new tread that hosts the listener thrListener = new Thread(KeepListening); thrListener.Start(); KeepListening() // While the server is running while (ServRunning == true) // Accept a pending connection tcpClient = tlsClient.AcceptTcpClient(); // Create a new instance of Connection Connection newConnection = new Connection(tcpClient); Once a connection through a TCP/IP port has been established between a TCP/IP client and a TCP/IP server, data can be sent in either direction exactly the same way that data is sent through any other type of port on a PC (serial, parallel, etc.). The only difference is that the data is sent across your network. The connection between a Client and a Server remains open until either the client or the server terminates the connection (i.e. hangs up the phone). One extremely nice benet of the TCP/IP protocol is that the low level drivers that implement the sending and receiving of data perform error checking on all data so you are guaranteed that there will be no errors in any data that you send or receive. For real implementation, our platform specications are: Programming Language: C# .NET Editor: Microsoft Visual Studio .NET 2011 Application Type: Windows Application Framework: .NET Framework 4.0 CPU: 2.4 GHz 64-bit Quad-Core Memory: 8 GB RAM Memory & 80 GB Hard-Drive

Fig. 3.

Socket Programming Protocol

Client Side Code Block: InitializeConnection() // Parse the IP address from the TextBox into an IPAddress object ipAddr = IPAddress.Parse(txtIp.Text); // Start a new TCP connections to the chat server tcpServer = new TcpClient(); tcpServer.Connect(ipAddr, 1986); // Send the desired username to the server swSender = new StreamWriter(tcpServer.GetStream()); swSender.WriteLine(ClientName); swSender.Flush(); // Start the thread for receiving messages and further communication thrMessaging = new Thread(new ThreadStart(ReceiveMessages)); thrMessaging.Start(); ReceiveMessages() // Receive the response from the server srReceiver = new StreamReader(tcpServer.GetStream()); string ConResponse = srReceiver.ReadLine(); // Closes a current connection CloseConnection(string Reason) swSender.Close(); srReceiver.Close(); tcpServer.Close(); // Sends the message typed in to the server SendMessage(string message) if (message.Length = 1) swSender.WriteLine(message); swSender.Flush(); Server Side Code Block: StartListening() // Get the IP of the rst network device IPAddress ipaLocal = ipAddress; // Create the TCP listener object using the IP of the server and the specied port tlsClient = new TcpListener(ipaLocal, 1986); // Start the TCP listener and listen for connections

Voting Implementation: The implementation in the voting part, consists of three program: Authorizer server/client: This is a server program which acts as authorizer to dene and validate authorized voters. Counter server: This is a server that both authorizer and voter can connect. Voter client: This is client program that user can use to get authorization, cast vote or even sending anonymous messages to other clients. In the following three sections we will describe general properties of these programs. Voter client: GUI was designed for this program as shown in Figure 4. As we mentioned before, using this program, voter can do three things: Getting authorization: connecting to Authorizer server and sending blinded vote, and if he is authorized, receives a signed electronic ballot to vote.

First user must set some credentials including his private key, and authorizer public key. (set your key and set server public key buttons). Before using system, voter also needs to set IP addresses of both authorizer and counter servers. Now, user can get information about current election. This information includes election name and valid choices that user can have to vote. By pressing Update election, user can achieve election information. From authorizing frame, user can make a choice and sends the request to authorizer. If his request is valid, then he would be able to save his electronic ballot for further use. After getting authorization from the Authorization server as shown in Figure 5, any time before end of election, user can upload his electronic ballot and cast his electronic vote to counter server using upload vote and cast vote buttons respectively. After casting successfully, voter will receive a serial number which later using that can keep track of his ballot and make sure that his vote is counted correctly. Authorizer server/client: Communication in this program is including two parts that we will describe separately. Authorizer/client: In this part, Authorizer acts as a server and clients can connect to get authorized. As we mentioned in the client program, if they are authorized, they will receive a signed valid electronic valid including their vote and a conrmation number signed by authorizer. We can dene authorized voter in this program by adding their public RSA key to the list. (add a voter). Also before starting authorization process, administrator of this system must set authorizer RSA private key as well as IP address of counter server. Then by pressing start authorizing button, process can be started. Authorizer/counter: After authorizing a voter, the authorizer has to send his conrmation number to counter. For this communication, counter acts as a server and authorizer would be client. So after each user authorization process, authorizer connects to counter and then sends his conrmation number to counter. The main reason we named authorizer program a server/client program is that this program uses both mechanism. Counter server: This program includes two server parts. First between voter and counter and second is between authorizer and counter. In both communication, counter acts as a server. The private key of counter server is hard coded in the program and there is no interface to choose it dynamically. Administrator of system only needs to set public key of authorizer to make communication between counter and authorizer secure (using server public key). In this program there is a frame for dening new election (new voting denition). Administrator can dene a name for election. After that he/she can add valid choices to the election. It is worth mentioning that after clicking update election by user in the client program, this information will be sent to client and user can make a choice and vote. After dening new election by clicking start voting, the election process will be started. Now electronic ballots can be

Fig. 4.

GUI of Client program

Fig. 5.

GUI of Authorizer server

submitted and counted if they are valid. Any time during the election, administrator can click update list button and see the result of election as in Figure 6. Client for Message Broadcasting: On startup, the client must obtain from the authentication server a session key that will be used to encrypt outgoing communication with the chat server and counter server. The client does this by connecting to the authentication servers well known host and port, proving its identity using a zero knowledge proof, and obtaining the session key using the RSA asymmetric key protocol. Immediately after obtaining a session key from the authentication server, and before doing anything else, the client must send encrypted message which consists of its request to connect the chat server that must be used to decrypt all incoming broadcast messages. Once these two keys have been obtained, the client can send and receive messages. To broadcast a message the client must connect to the chat servers well known host and port and transmit a message encrypted with the symmetric key generating by Rijndael Algorithm as mentioned in Section III. To receive a message, the client accepts a connection from the server and receive a message encrypted with the symmetric key. Periodically, the client will send to the chat server a keep-

Fig. 6.

GUI of Counter server Fig. 7. GUI of the Chat Server

alive message that will contain a zero-length message. To see why the keep-alive message is necessary, consider the case where the client successfully obtains the keys described above and listens without ever transmitting information (i.e. the client is passive). Assume also that the communication link between the chat server and the client is lost shortly thereafter, and for a period long enough for the chat server to try to send it some message. The chat server will assume that the client has gone away and delete it from its database of active clients in hash tables. Now assume that the communication link is restored shortly after the client has been deleted. If the keep-alive message is not sent then the client would never discover that it has been deleted from the database. Figure 8 shows the clients state diagram, and the following pseudo code gives a general idea of the internal structure of the actual implementation; Initialize Client Get an authorization ID from the authentication server Send a request to Chat Server in order to communicate and broadcast messages Receive an anonymous ID generated by hash function in Chat Server Send clients message to Chat server in order to broadcast all connected clients with anonymous ID

Chat Server
Message Broadcast Client Authorization Message Broadcast

Client
Client Authentication

Client
Client Authentication

Authentication Server
Fig. 8. Logic design of Client-Chat Server

The chat server maintains a database of clients which have connected. This database contains the clients anonymous ID generated by the hash function and IP address/port. It is assumed that this database is secure (i.e. no entries can be inserted by any other process other than the chat server). In addition to the clients connection to the Chat Server, counter server is connected to the Chat server to broadcast each voting in order to notify each connected clients to the Chat Server. After getting voting information from the Counter Server, the administrator of Chat Server automatically transmits the voting information to all connected clients in the hash table. V. C ONCLUSION AND F UTURE W ORK

Chat Server: As well as receiving and sending information (just like a client as shown in Figure 7), a server has to keep track of who is connected to it. It is also useful to be able to broadcast messages, that is send them to every client currently connected (for example, a message indicating the server is about to be taken down for maintenance). The Chat server accepts incoming c1ient connections and broadcasts data to clients for display. Each client communicates with the server by encrypting its data with a session key. This key is obtained by the client from the authentication server all startup.

The goal of our project was to determine the feasibility of implementing a number of cryptographic algorithms. We chose a secure communication system to broadcast the authorized clients messages as a test implementation. We aimed to design a secure online voting system with anonymous message broadcasting that would allow secure voting and communication, and use this to determine how feasible it is to build reliable, real-world cryptographic systems. In this project report, we introduced the secure online voting system with anonymous message broadcasting application which is including authorized clients given by Authorization server and voting system counted by Counter server. We

described a hybrid key infrastructure combining public key infrastructure (PKI) for trusted clients and a shared network authorization key for devices requiring anonymity. The nonrepudiation property provided from private key encryption protocol was retained for anonymous clients with the inclusion in the message of a unique sender identier encrypted for access by the revoking authority and anonymous for other devices. We implemented the project using three servers which are authorization server that is giving conrmation number looking at private and public key encryption mechanism, counter server that is counting all clients ballot and broadcasting every ballots to other clients, and communication server that is broadcasting every message coming from authorized clients to other authorized members with senders anonymous identication numbers. We established that every authorized clients can cast their ballots to counter server which updates every ballot times its counting list and broadcasts every ballots. After client authorization, the client can send its message to other authorized members in the system. In the communication server, after getting a request from an authorized client, the server is assigning it with an anonymous identication number to be secured broadcasting. We described every details in communication section in the paper. R EFERENCES
[1] [2] A. Fiat and A. Shamir, How to Prove Yourself: Practical Solutions to Identication and Signature Problems, 1986. C. H. Lim and P. J. Lee, A key recovery attack on discrete log-based schemes using a prime order subgroup. Springer-Verlag, 1997, pp. 249263. O. Goldreich, S. Micali, and A. Wigderson, Proofs that yield nothing but their validity or all languages in np have zero-knowledge proof systems, J. ACM, vol. 38, no. 3, pp. 690728, Jul. 1991. H. Kikuchi, J. Akiyama, G. Nakamura, and H. Gobioff, Stochastic voting protocol to protect voters privacy, in Proceedings of the 1999 IEEE Workshop on Internet Applications, ser. WIAPP 99. Washington, DC, USA: IEEE Computer Society, 1999, pp. 103. W. Stallings, Cryptography and network security, 3rd ed. Prentice Hall, 1999. P. Syverson, D. Goldschlag, and M. Reed, Anonymous connections and onion routing, in Security and Privacy, 1997. Proceedings., 1997 IEEE Symposium on, 1997, pp. 4454. M. K. Reiter and A. D. Rubin, Anonymous web transactions with crowds, Commun. ACM, vol. 42, no. 2, pp. 3248, Feb. 1999. A. Beresford and F. Stajano, Location privacy in pervasive computing, Pervasive Computing, IEEE, vol. 2, no. 1, pp. 4655, 2003. M. Gruteser and D. Grunwald, Anonymous usage of location-based services through spatial and temporal cloaking, in Proceedings of the 1st International Conference on Mobile Systems, Applications and Services, ser. MobiSys 03. New York, NY, USA: ACM, 2003, pp. 3142. B. Gedik and L. Liu, Location privacy in mobile systems: A personalized anonymization model, in Distributed Computing Systems, 2005. ICDCS 2005. Proceedings. 25th IEEE International Conference on, 2005, pp. 620629. N. Zhang, Q. Shi, and M. Merabti, Anonymous public-key certicates for anonymous and fair document exchange, Communications, IEE Proceedings-, vol. 147, no. 6, pp. 345350, 2000. D. Chaum and E. Heyst, Group signatures, in Advances in Cryptology EUROCRYPT 91, ser. Lecture Notes in Computer Science, D. Davies, Ed. Springer Berlin Heidelberg, 1991, vol. 547, pp. 257265.

[13]

[14] [15]

[16]

[17] [18]

[19]

[20]

E. Bresson and J. Stern, Efcient revocation in group signatures, in Public Key Cryptography, ser. Lecture Notes in Computer Science, K. Kim, Ed. Springer Berlin Heidelberg, 2001, vol. 1992, pp. 190206. G. Ateniese, D. Song, and G. Tsudik, Quasi-efcient revocation of group signatures, Cryptology ePrint Archive, Report 2001/101, 2001. D. Boneh, X. Boyen, and H. Shacham, Short group signatures, in Advances in Cryptology CRYPTO 2004, ser. Lecture Notes in Computer Science, M. Franklin, Ed. Springer Berlin Heidelberg, 2004, vol. 3152, pp. 4155. M. Raya and J.-P. Hubaux, The security of vehicular ad hoc networks, in Proceedings of the 3rd ACM Workshop on Security of Ad Hoc and Sensor Networks, ser. SASN 05. New York, NY, USA: ACM, 2005, pp. 1121. B. Parno and A. Perrig, Challenges in securing vehicular networks, 2005. K. Sampigethaya, L. Huang, M. Li, R. Poovendran, K. Matsuura, and K. Sezaki, Caravan: Providing location privacy for vanet, in in Embedded Security in Cars (ESCAR, 2005. D. Chaum, Blind signatures for untraceable payments, in Advances in Cryptology, D. Chaum, R. Rivest, and A. Sherman, Eds. Springer US, 1983, pp. 199203. D. Chaum, A. Fiat, and M. Naor, Untraceable electronic cash, in Proceedings on Advances in Cryptology, ser. CRYPTO 88. New York, NY, USA: Springer-Verlag New York, Inc., 1990, pp. 319327. [Online]. Available: http://dl.acm.org/citation.cfm?id=88314.88969

[3]

[4]

[5] [6]

[7] [8] [9]

[10]

[11]

[12]