An Electronic Voting Protocol (revisited)

Slides:



Advertisements
Similar presentations
Security attacks. - confidentiality: only authorized parties have read access to information - integrity: only authorized parties have write access to.
Advertisements

Analysis of an Internet Voting Protocol Dale Neal Garrett Smith.
Last Class: The Problem BobAlice Eve Private Message Eavesdropping.
1 Chapter 7-2 Signature Schemes. 2 Outline [1] Introduction [2] Security Requirements for Signature Schemes [3] The ElGamal Signature Scheme [4] Variants.
Spring 2000CS 4611 Security Outline Encryption Algorithms Authentication Protocols Message Integrity Protocols Key Distribution Firewalls.
Requirements for a Secure Voting System  Only authorized voters can vote  No one can vote more than once  No one can determine for whom anyone else.
A Pairing-Based Blind Signature
ThreeBallot, VAV, and Twin Ronald L. Rivest – MIT CSAIL Warren D. Smith - CRV Talk at EVT’07 (Boston) August 6, 2007 Ballot Box Ballot Mixer Receipt G.
ETen E-Poll ID – Strasbourg COE meeting November, 2006 Slide 1 E-TEN E-POLL Project Electronic Polling System for Remote Operation Strasbourg.
Digital Signatures and Hash Functions. Digital Signatures.
Lect. 18: Cryptographic Protocols. 2 1.Cryptographic Protocols 2.Special Signatures 3.Secret Sharing and Threshold Cryptography 4.Zero-knowledge Proofs.
Mar 19, 2002Mårten Trolin1 This lecture On the assignment Certificates and key management SSL/TLS –Introduction –Phases –Commands.
ECOMMERCE TECHNOLOGY FALL 2003 COPYRIGHT © 2003 MICHAEL I. SHAMOS Cryptography.
Cryptography1 CPSC 3730 Cryptography Chapter 10 Key Management.
Key Management public-key encryption helps address key distribution problems have two aspects of this: –distribution of public keys –use of public-key.
Receipt-freeness and coercion-resistance: formal definitions and fault attacks Stéphanie Delaune / Steve Kremer / Mark D. Ryan.
EEC 693/793 Special Topics in Electrical Engineering Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering.
ITIS 6200/8200. time-stamping services Difficult to verify the creation date and accurate contents of a digital file Required properties of time-stamping.
Anonymity and Security in Public Internet Forums Ho-fung LEUNG Senior Member, IEEE Dept. of Computer Science & Engineering The Chinese University of Hong.
CMSC 414 Computer and Network Security Lecture 19 Jonathan Katz.
EEC 688/788 Secure and Dependable Computing Lecture 7 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
Optimistic Synchronous Multi-Party Contract Signing N. Asokan, Baum-Waidner, M. Schunter, M. Waidner Presented By Uday Nayak Advisor: Chris Lynch.
03 December 2003 Public Key Infrastructure and Authentication Mark Norman DCOCE Oxford University Computing Services.
Homework #5 Solutions Brian A. LaMacchia Portions © , Brian A. LaMacchia. This material is provided without.
Long-term Archive Service Requirements draft-ietf-ltans-reqs-00.txt.
Digital Signature Xiaoyan Guo/ Xiaohang Luo/
Controller of Certifying Authorities PKI Technology - Role of CCA Assistant Controller (Technology) Controller of Certifying Authorities Ministry of Communications.
Secure Systems Research Group - FAU Patterns for Digital Signature using hashing Presented by Keiko Hashizume.
CS5204 – Fall Cryptographic Security Presenter: Hamid Al-Hamadi October 13, 2009.
Cryptology Digital Signatures and Digital Certificates Prof. David Singer Dept. of Mathematics Case Western Reserve University.
On the Anonymity of Anonymity Systems Andrei Serjantov (anonymous)
Digital Cash By Gaurav Shetty. Agenda Introduction. Introduction. Working. Working. Desired Properties. Desired Properties. Protocols for Digital Cash.
Part Two Network Security Applications Chapter 4 Key Distribution and User Authentication.
Enhancing Security with S/MIME Chuck Connell,
KYUSHUUNIVERSITYKYUSHUUNIVERSITY SAKURAILABORATORYSAKURAILABORATORY Sakurai Lab. Kyushu University Dr-course HER, Yong-Sork E-voting VS. E-auction.
AQA Computing A2 © Nelson Thornes 2009 Section Unit 3 Section 6.4: Internet Security Digital Signatures and Certificates.
Hash Functions A hash function H accepts a variable-length block of data M as input and produces a fixed-size hash value h = H(M) Principal object is.
Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms David Chaum CACM Vol. 24 No. 2 February 1981 Presented by: Adam Lee 1/24/2006 David.
Chapter 4: Intermediate Protocols
Network Security Lecture 26 Presented by: Dr. Munam Ali Shah.
Cryptography, Authentication and Digital Signatures
Digital Signatures A primer 1. Why public key cryptography? With secret key algorithms Number of key pairs to be generated is extremely large If there.
SECURITY MANAGEMENT Key Management in the case of public-key cryptosystems, we assumed that a sender of a message had the public key of the receiver at.
6. Esoteric Protocols secure elections and multi-party computation Kim Hyoung-Shick.
Based on Schneier Chapter 5: Advanced Protocols Dulal C. Kar.
Proof-Carrying Code & Proof-Carrying Authentication Stuart Pickard CSCI 297 June 2, 2005.
Chapter 6:Esoteric Protocols Dulal C Kar. Secure Elections Ideal voting protocol has at least following six properties 1.Only authorized voters can vote.
Evoting using collaborative clustering Justin Gray Osama Khaleel Joey LaConte Frank Watson.
The TAOS Authentication System: Reasoning Formally About Security Brad Karp UCL Computer Science CS GZ03 / M th November, 2008.
Lecture 16: Security CDK4: Chapter 7 CDK5: Chapter 11 TvS: Chapter 9.
Digital Signatures, Message Digest and Authentication Week-9.
6 June Lecture 2 1 TU Dresden - Ws on Proof Theory and Computation Formal Methods for Security Protocols Catuscia Palamidessi Penn State University,
31.1 Chapter 31 Network Security Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
DIGITAL SIGNATURE.
1 Chapter 10: Key Management in Public key cryptosystems Fourth Edition by William Stallings Lecture slides by Lawrie Brown (Modified by Prof. M. Singhal,
Network Security Continued. Digital Signature You want to sign a document. Three conditions. – 1. The receiver can verify the identity of the sender.
Electronic Voting R. Newman. Topics Defining anonymity Need for anonymity Defining privacy Threats to anonymity and privacy Mechanisms to provide anonymity.
Private key
Secure Remote Electronic Voting CSE-681 Fall 2006 David Foster and Laura Stapleton Laura StapletonLaura Stapleton.
Lecture 11 Overview. Digital Signature Properties CS 450/650 Lecture 11: Digital Signatures 2 Unforgeable: Only the signer can produce his/her signature.
Lecture 9 Overview. Digital Signature Properties CS 450/650 Lecture 9: Digital Signatures 2 Unforgeable: Only the signer can produce his/her signature.
Fall 2006CS 395: Computer Security1 Key Management.
Prof. Reuven Aviv, Nov 2013 Public Key Infrastructure1 Prof. Reuven Aviv Tel Hai Academic College Department of Computer Science Public Key Infrastructure.
Firewalls and Tunneling Firewalls –Acts as a barrier against unwanted network traffic –Blocks many communication channels –Can change the design space.
Cryptography and Network Security Chapter 14 Fifth Edition by William Stallings Lecture slides by Lawrie Brown.
ThreeBallot, VAV, and Twin
Homework #5 Solutions Brian A. LaMacchia
eVoting System Proposal
Digital Signatures Network Security.
Presentation transcript:

An Electronic Voting Protocol (revisited) Paul Valiant extending work by Dale Neal & Garrett Smith

Source Paper “An Anonymous Electronic Voting Protocol for Voting Over the Internet”, Indrajit Ray, Indrakshi Ray, Natarajan Narasimhamurthi

The Problem We want a protocol for voting over the internet that has all the salient features of voting in person These properties can be grouped under the categories Accuracy, Democracy, Privacy, and No Unauthorized Proxy

Desirable Properties Accuracy Democracy A cast vote cannot be altered An invalid vote is not counted Each voter can verify that his/her vote is counted Democracy Only an eligible voter can participate Each voter can cast only one vote

Desirable Properties (II) Privacy A ballot cannot be linked back to the voter who cast it (No vote buying) A voter cannot prove to someone else what his/her vote is No Unauthorized Proxy If a voter decides not to cast his/her ballot, no party can take advantage of this and cast a forged ballot

Desirable Properties (III) In principle, if some property of the election is compromised, some authority should be able to detect and prove it. At worst, some consortium of people should be able to prove it without compromising their own privacy One breach of this occurs in a protocol violation; I may have a hard time proving to someone that a server is ignoring me without giving up some privacy.

Assumptions Any two parties can arrange a secure communication channel Additionally, a voter can send secure, anonymous messages (votes) to a server Certain systems that do not interact with voters in the voting process are secure The voter registry that knows the names of all registered voters is secure

The Protocol Ballot distribution: BD → V: {y,sigBD{h(y)}}V, sigBD{h(voter certificate)} y is the ballot number h is a one-way permutation 2. Generating a voter mark: m=h(y) 3. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V,voter certificate, sigBD{h(voter certificate)}}CA CA →V: {sigCA{m*{r}CA}}V 4. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},h(vote, sigCA{m})}VC Public FTP site → VC: {{vote, sigCA{m}},h(vote, sigCA{m})}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 5. Vote counting: every message received by the authorities is made public. Votes are tallied and verified

The Revised Protocol (I) Ballot distribution: BD → V: {y,sigBD{h(y)}}V, sigBD{h(voter certificate)} y is the ballot number h is a one-way permutation 2. Generating a voter mark: m=h(y) 3. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V,voter certificate, sigBD{h(voter certificate)}}CA CA →V: {sigCA{m*{r}CA}}V 4. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},h(vote, sigCA{m})}VC Public FTP site → VC: {{vote, sigCA{m}},h(vote, sigCA{m})}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 5. Vote counting: every message received by the authorities is made public. Votes are tallied and verified To the extent that we can verify a y-m pair, we can identify people’s votes. This should not happen. Clarification: Suppose that given y, an authority could construct m. This would violate privacy. An alternative interpretation is that m is produced (from y) by some method known only to the voter. Here the voter could be expected to demonstrate that he produced m. We propose instead that the voter picks a random y, then uses h to generate m. He can prove that he generated m by exhibiting y (no one else can invert the permutation). This construction has the desired property that no one knows the origin of m until the voter chooses to reveal it. We note that from the perspective of a protocol, the above outlined procedure appears as if the voter just choose a random m, as in the next slide.

The Revised Protocol (II) Ballot distribution: BD → V: {y,sigBD{h(y)}}V, sigBD{h(voter certificate)} y is the ballot number h is a one-way permutation 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V,voter certificate, sigBD{h(voter certificate)}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},h(vote, sigCA{m})}VC Public FTP site → VC: {{vote, sigCA{m}},h(vote, sigCA{m})}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified Let m be random. y is now useless

The Revised Protocol (III) Ballot distribution: BD → V:sigBD{h(voter certificate)} h is a one-way permutation 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V, voter certificate, sigBD{h(voter certificate)}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},h(vote, sigCA{m})}VC Public FTP site → VC: {{vote, sigCA{m}},h(vote, sigCA{m})}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified The voter certificate identifies the voter as eligible for the election. It is signed by the Registration authority. Note: Here we make a best effort to clarify something that is vaguely specified in the paper.

The Revised Protocol (IV) Ballot distribution: BD → V:sigBD{h(sigR{V})} h is a one-way permutation 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V, sigR{V}R, sigBD{h(sigR{V})}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},h(vote, sigCA{m})}VC Public FTP site → VC: {{vote, sigCA{m}},h(vote, sigCA{m})}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified The function h(x) does not add any protection if the parties already know x Clarification: We mean specifically that for any run of the protocol with the above marked functions h, there is a corresponding run of the protocol without it, because all the involved parties can both apply h, or “invert” it when they already know the inverted value.

The Revised Protocol (V) Ballot distribution: BD → V:sigBD{sigR{V}} 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V, sigR{V}, sigBD{sigR{V}}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},vote, sigCA{m}}VC Public FTP site → VC: {{vote, sigCA{m}},vote, sigCA{m}}VC VC →Public FTP site: sigVC{h(vote, sigCA{m})} Public FTP site → V: sigVC{h(vote, sigCA{m})} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified The votes will be made publicly available after the election, so h does not protect the voter here. Clarification: Specifically, both VC and V already know vote, sigCA{m} at this point, so hashing these values adds no security. Further, after the election vote, sigCA{m} will be made public, so hashing this value hides nothing.

The Revised Protocol (VI) The additional signature of the Ballot Distributor does not add any protection, since we do not trust him. 1. Ballot distribution: BD → V:sigBD{sigR{V}} 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V, sigR{V}, sigBD{sigR{V}}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}},vote, sigCA{m}}VC Public FTP site → VC: {{vote, sigCA{m}},vote, sigCA{m}}VC VC →Public FTP site: sigVC{vote, sigCA{m}} Public FTP site → V: sigVC{vote, sigCA{m}} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified We eliminate some redundancy here too Clarification: The signature of BD on the voter certificate proves only that the BD knows the voter is registered. We assume that the registration authority (R) has already ensured this. Further down, we eliminate parts of messages that are already included in the message, and clearly add no value.

The Revised Protocol (VII) 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: {m*{r}CA,sigV{m*{r}CA}}CA, {V, sigR{V}, sigR{V}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}}}VC Public FTP site → VC: {{vote, sigCA{m}}}VC VC →Public FTP site: sigVC{vote, sigCA{m}} Public FTP site → V: sigVC{vote, sigCA{m}} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified We eliminate some redundancy here too Clarification: The above marked information is redundant, in that it can easily be reproduced from information in the same message.

The Revised Protocol (VIII) 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: {sigV{m*{r}CA}}CA, {sigR{V}}CA CA →V: {sigCA{m*{r}CA}}V 3. Vote Casting: V →Public FTP site: {{vote, sigCA{m}}}VC Public FTP site → VC: {{vote, sigCA{m}}}VC VC →Public FTP site: sigVC{vote, sigCA{m}} Public FTP site → V: sigVC{vote, sigCA{m}} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified Our authors seem to have forgotten that we’re talking on a secure channel. Also, why are they trusting a “Public FTP” server? Clarification: Encrypting a message with a publicly available key does not authenticate the sender. Sending these messages over a secure channel makes the encryption superfluous since secrecy is already assumed. Also, the role of the FTP servers and their assumed security properties are barely mentioned in the paper. We presume the authors intended using a secure anonymous channel.

The Revised Protocol (IX) 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: sigV{m*{r}CA}, sigR{V} CA →V: sigCA{m*{r}CA} 3. Vote Casting: V →VC: vote, sigCA{m} VC →V: sigVC{vote, sigCA{m}} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified This signature does not act as proof of anything but the fact that CA knows the voter’s mark anon anon Clarification: If the VC is not trustworthy, he can “drop” the vote before giving a receipt. (This is a reasonable action to model.) Thus in the worst case situation, this message is not part of the protocol anyway. However, all the security of the protocol (modulo dropped votes) remains because the VC publishes vote, sigCA{m} after the election, presumably signed.

The Revised Protocol (X) 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: sigV{m*{r}CA}, sigR{V} CA →V: sigCA{m*{r}CA} 3. Vote Casting: V →VC: vote, sigCA{m} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified This is some very garbled notation for a blind signature – it relies on the assumption that multiplication commutes with encoding/decoding, which is unwieldy. anon Clarification: We are just trying to guess what our authors intended

The Revised Protocol (XI) 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: sigV{blind_requestVCA(m)}, sigR{V} CA →V: blind_sigVCA(m) 3. Vote Casting: V →VC: vote, sigCA{m} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified anon A blind signature request can be thought of as a sealed envelope with a letter and some carbon paper inside. You (and only you) sign it on the outside, your signature appears on the inside, and you do not know what you’ve signed. Only the submitter of the envelope can open it to reveal your signature.

The Revised Protocol intuitively You get your registration 1. Ballot distribution: BD → V:sigR{V} 2. Voter Certification: V →CA: sigV{blind_requestVCA(m)}, sigR{V} CA →V: blind_sigVCA(m) 3. Vote Casting: V →VC: vote, sigCA{m} 4. Vote counting: every message received by the authorities is made public. Votes are tallied and verified You send an identifiable request for certification, along with your registration, to prove valid ID. The certificate is signed. You anonymously submit your vote and certificate. anon

Murφ formulation Our Murφ formulation is a slightly expanded form of the one presented last class. We fixed some inconsistencies, such as the ability of a voter to forge his registration. We expanded the model to allow all three authorities to cheat (previously the CA could not) We added the invariant “a fraudulent vote can be detected by the voters.”

Fraud Detection by Voters There are two types of fraud detection available to voters but not the authorities. The people who did not vote can open their voter certification to reveal the mark m that is absent from the reported votes. Revealing m costs them nothing, since they did not use the certificate. The people who did vote, but whose votes were ignored can do likewise. However, if someone has a list of the original votes, he can figure out how the disenfranchised would have voted.

Expected Results In order to have a painless election, the active participation of the voters in the verification process should only be required in drastic circumstances. According to the paper, this is necessary only when all three authorities cheat. Otherwise, an independent observer with access to the publicly available facts should be able to detect the fraud

Murφ Results When the certification authority is honest any fraud is detectable by an independent observer. When the vote counter is honest, a fraud can still be perpetrated, even with an honest ballot distributor!

Fraud! With the cooperation of the CA, a dishonest voter obtains a signed mark, which he then votes with. Meanwhile, an unsuspecting voter completes the protocol up until the registration stage, but does not vote. The CA publishes his/her submitted registration info, pretending that the fraudulent voter is associated with it.

With Voter Verification However, Murφ confirms that the voters can still detect fraud in these cases.

Thoughts This whole analysis rests on the assumption that the agents follow a reasonable version of the protocol. Instead, what if the vote counter changed everyone’s vote to “Bush”? Would a receipt help? No, because the vote counter could forge whatever receipt he wants, and still change your vote.

Thoughts (II) What about selling your vote? Can you prove a link between your voter mark and what you submitted to the CA? Yes! Because you are the (only) one who can open the blinded signature form you sent to the CA.