Smart Card Voting Demo

This demo was originally developed for the 2001 "ICT Kenniscongres" organized by the Dutch ministries EZ and OCenW.

The case study presented here is an implementation of a drastically simplified electronic voting protocol. In the near future, casting a vote in an election will no longer require a voter to visit a physical voting station. Instead, a vote can be cast from the voter's PC at home. The PC sends the vote information over the Internet to a central server (Fig.1) which keeps track of the election result.

Fig.1 The vote server GUI

Security goals

There are a number of potential problems against which the voting protocol should be protected. Only three problems are discussed here.

First, the vote information should remain a secret, this means that only the server should receive the vote information that is sent by the voter. This property is known as confidentiality. Obviously, the vote information can be encoded using public key cryptography before it is sent over the Internet.

Second, only registered voters should be allowed to cast their votes. The result of the voting process should reflect the choices of the registered voters, and the registered voters only. These properties are known as authentication and integrity. This also can be implemented using public key cryptography. Every registered voter receives a smart card by ordinary mail. The smart card cryptographically signs the vote before it is sent to the server.

Third, not even the voter's PC should be trusted. Or, put differently, the host application is not part of the trusted computing base. Think, for example, of a virus which infects the voter's PC prior to the election period. On election day the virus becomes active and may circumvent the cryptographic protections described above. The virus might, for instance, read the vote and send it to some third party, thus violating the confidentiality property. Worse yet, it might send a completely different vote to the smart card for signing. The server would accept the vote since it was signed by a legitimate smart card. This would violate the integrity of the election result.

A solution to this problem uses a personal vote list, on which the list of parties is permuted in a way that is unique for the voter's id. Each of the voter's choices is thus encoded, and the voter enters the vote code into the GUI, rather than the choice itself. A virus might intercept the vote code, and start a "vote thread" with a changed vote code, but it cannot intensionally change the outcome of the election. Moreover, if the vote codes are chosen from a large enough set of codes, it is extremely unlikely that it choses a vote code which is valid for the particular voter id. This simple idea is called the Voter-Side Virus-Protection Protocol (VSVPP). Of course, the server now needs to maintain a database relating voter ids to vote lists.

Note that many potential problems are not addressed in the above analysis. For example, denial of service attacks are ignored. Also, the server is completely trusted. The latter problem can perhaps be solved using a protocol which distributes trust over several servers.

The formal security protocol

The security protocol implemented in the voting case study involves three principals: The applet (A), the host application (H), and the server (S). For a complete security analysis perhaps the voter, the virus, and potential adversaries on the Internet should be considered as well. The figure below shows how the protocol works. First, A computes the signature s, based on the vote v and A's private key priv_A. Next, H encrypts the vote v and the signature s using a freshly generated session key, based on the server's public key pub_S, resulting in the message m. The message m is sent over the Internet to the server, which is able to decode it, since it has the private key priv_S and A's public key pub_A.

Fig.2 The different principals of the protocol

The diagram shows where the public keys pub_A, pub_S are needed. It should be assumed, however, (as is common) that all involved principals know all public keys. The trusted computer base includes the applet and the server, but not the host application.

The keys pub_A and priv_A are loaded only once onto the smart card during initialization. Once the keys are present, the applet can be used to sign packets. The packet v that gets sent to the applet for signing is composed as follows:

In total v contains 64 bytes. The applet first computes a 20 byte SHA message digest, and then encrypts it with its 128 byte (or 1024 bit) RSA private key priv_A to get the 128 byte signature s.

Rather than use pub_S to directly encrypt the vote information, first a session key des is generated. The session key des is wrapped, that is encrypted with, pub_S and sent to the server. Such a session key is normally used to help ensure non-repudiation. In this case, however, it is used because the message <v>_s gets too large to be encrypted by a 128 byte RSA key. The vote v and signature s are thus encrypted with des to obtain the message m which gets sent to the server.

The server S unwraps the session key des and decodes m to obtain v and s. The signature s is verified by decrypting s using pub_A, computing the SHA message digest of v and comparing the two results. In case they are equal, S updates the election result accordingly and sends an acknowledgment message back to H. Additionally, S sends the information it received over a "secure" feedback channel to the voter. In the implementation this channel is implemented by sending email or an SMS message (through the GSM network) to the voter.

In conventional security protocol notation the total protocol reads as follows:

Security protocols like this, once formalized, can be analysed using formal methods such as BAN logic. An interesting issue, not addressed here, is how to bridge the gap between the formal version of the security protocol and the actual implementation.

People who worked on this: Cees-Bart Breunesse, Bart Jacobs, Martijn Oostdijk. Some of the technology was patented.