Work team G Avramidis Presenter C Manolopoulos P

Work team: G. Avramidis (Presenter), C. Manolopoulos, P. Nakou, A. Panagiotaki, D. Sofotassios, P. Spirakis, Y. Stamatiou (Presenter) and A. Tatakis Collaborative work between Research and Academic Computer Technology Institute (RACTI) and EXPERTNET SA, Greece Supported by the General Secretariat of Research and Technology of Greece, 3 rd Community Support Framework, Operational Program of Western Greece ΠΝΥΚΑproject Bregenz August 6, 2008 ,

Pnyka was the meeting place of the world's first ever democratic legislature, the Athenian ekklesia (assembly), and the flat stone platform is the bema, the "stepping stone" or speakers' platform. It is located less than one kilometre west of the Acropolis and 1. 6 km south-west of the centre of modern Athens. Bregenz August 6, 2008 ,

Presentation Structure n n n n Overview Design Principles Voting Protocol System Architecture Implementation Tools System Evaluation Publications Bregenz August 6, 2008 , 3

Overview (1/4) Voting requirements n n n n Democracy Accuracy Secrecy Receipt Freeness Uncoercibility Fairness Atomic & Universal Verifiability Robustness Bregenz August 6, 2008 , 4

Overview (2/4) Meeting the requirements (1/2) n A robust cryptographic protocol, (W. Smith 2005): n n n Threshold cryptography El Gamal Homomorphic encryption/decryption Homomorphic tallying of votes Designated Verifier Zero Knowledge Proofs of vote validity Digital Signatures Trust engineering approach: n n n “Layers of Trust” Architecture UML-based design Formal and semi-formal risk management Bregenz August 6, 2008 , 5

Overview (3/4) Meeting the requirements (2/2) n Robust and publicly verifiable implementation: n n n Open Source tools Secure VPN connections Fault tolerance Extensive data logging/auditing System evaluation: n n n Theoretical (open network of M/M/1 queues) model describing large scale national elections Simulation of the model to assess the overall system performance Mock-up polling, with the participation of members of the Technical Chamber of Greece Bregenz August 6, 2008 , 6

Overview (4/4) Τhe System n n n A scalable, internet based e-voting system Two basic versions, designed to facilitate voting processes of various degrees of importance and scale Appropriate for different e-voting scenarios: n n n Polls Petitions Referenda General elections Secure, built-in support for all the stages of a voting process: n n n Creation of election catalogue Authentication/Registration of voters using a PKI Submission of votes using homomorphic encryption (El Gamal) Tallying of votes using the homomorphic property Distributed, cross verification of results / Publishing Bregenz August 6, 2008 , 7

Presentation Structure n Overview n Design Principles n n n Voting Protocol System Architecture Implementation Tools System Evaluation Publications Bregenz August 6, 2008 , 8

Design Principles(1/26) Our Goal ü Propose and apply a “trust preserving” approach for handling the increasingly difficult complexity issues of building e. Voting systems and, in general, trust-critical e. Government applications ü Design and implementation a secure and of efficiente. Votingplatformwitha focus on trust establishment Bregenz August 6, 2008 , 9

Design Principles(2/26) Our Approach ü Decomposition of the e. Voting process into layers containing basic trust components Facilitate the management of trust in each component ü Concrete notion of trust components should be taken into consideration by designers of security critical applications in general Bregenz August 6, 2008 , 10

Design Principles(3/26) The trust - centered approach Bregenz August 6, 2008 , 11

Design Principles(4/26) “Layers of Trust” Architecture Bregenz August 6, 2008 , 12

Design Principles(5/26) “Layers of Trust” Architecture ü Scientific Soundness: Crypto-based justification of all components (e. g. cryptographically secure random number generators, homomorphic functions) Bregenz August 6, 2008 , 13

Design Principles(6/26) Cryptographic Primitives n n n n One-way Functions Probabilistic Encryption Digital Signatures Secret Sharing Threshold Encryption Zero Knowledge Proofs Homomorphic Functions El Gamal Cryptosystem Bregenz August 6, 2008 , 14

Design Principles(7/26) One-Way Functions n A function f: D R is called one-way if: n n n Computing f(x) is “easy” Computing f-1(y) for almost all the images is “hard” E. g. (under the DL assumption) n n Prime p and a generator g of f(x) = gx (mod p) Bregenz August 6, 2008 , Zp * 15

Design Principles(8/26) Probabilistic Encryption n n Probabilistic encryption maps every M to many C randomly Cryptanalysists can’t tell whether C = Epublic(M) Bregenz August 6, 2008 , 16

Design Principles(9/26) Digital Signatures n n We focus on electronic signatures that use public-key cryptography E. g. (Based on RSA) n A key generation algorithm n n A signing algorithm n n Same as decryption of M ZN* by C=D(M)=Md mod N. A verification algorithm n n n Same as in RSA encryption Same as encryption of C ZN* by M=E(C)=Ce mod N. Can be calculated and verified by anyone Concept of Blind Signatures … Bregenz August 6, 2008 , 17

Design Principles(10/26) Secret Sharing Based on the next problem - assuming that there are N players, how can a dealer share a secret in a way that any group of t (< N) or more players could recreate the secret, but any group of less then t players will not be able to do so. Such scheme is called (t, N) - threshold secret sharing scheme Bregenz August 6, 2008 , 18

Design Principles(11/26) Threshold Encryption n In threshold encryption we have N authorities, and we want to encrypt a message in a way that any t or more authorities could decrypt it. Again, any group of less then t authorities will not be able to do so No trusted dealer Solutions are similar to Shamir’s scheme Bregenz August 6, 2008 , 19

Design Principles(12/26) Zero-knowledge Proofs n n n Interactive protocols between two players, Prover and Verifier, in which the prover proves to the verifier, with high probability, that some statement is true Does not leak any information besides the veracity of this statement In the case of honest verifier ZKP, we can modify the protocol to non-interactive Bregenz August 6, 2008 , 20

Design Principles(13/26) ZKP Example: Equality of logarithms n n Let g 1, g 2 generators of Zq*. The Prover claims that logg 1 v = logg 2 w (=x) for publicly known v, w, g 1, g 2. n n n P chooses random z [1. . q] and sends a=g 1 z, b=g 2 z. V selects random c [1. . q] and sends it. P sends r = (z+cx). V verifies that g 1 r=avc and g 2 r=bwc Can be turned into non-interactive n C = Hash(a, b, v, w). Bregenz August 6, 2008 , 21

Design Principles(14/26) Homomorphic functions A mechanism for destroying the relationship between voter and his vote – based on homomorphic functions (i. e. El Gamal encryption!) Based on the computational difficulty in inverting these functions Efficient parallelization: Votes are never decrypted by they are added, homomorphically, in their encrypted form! The vote outcome is in encrypted form too and needs to be decrypted (this is not hard since the number of voters is usually small and a brute force inversion suffices – also use of Pollard Ρho, Baby-step-giant-step etc. ) Bregenz August 6, 2008 , 22

Design Principles(15/26) El Gamal Cryptosystem n n Probabilistic, homomorphic public-key encryption scheme over a multiplicative group of prime order A key generation algorithm n n Publicly choose two large primes q’ and q such that q | q’-1 , i. e. , q’ = qk+1 for some integer k. We also fix a generator g’ of F*q’. The cyclic group G we work with is the one generated by g = (g’)k and has order (q’-1)/k = q. Private key G. Public key = gx x y Bregenz August 6, 2008 , 23

Design Principles(16/26) “Layers of Trust” Architecture ü Implementation Soundness: Formal methodology for the verification of the implementation Bregenz August 6, 2008 , 24

Design Principles (17/26) Risk Analysis and Management – The Coras Methodology n n Methodology for risk analysis Customised language for threat and risk modelling (UML based) + extended documentation (diagrams, tables) Provides detailed guidelines for each step Proposes different tools and techniques for each step + software tool to integrate tools and document results http: //coras. sourceforge. net/ Bregenz August 6, 2008 , 25

Design Principles (18/26) Risk Analysis and Management – Step 1: Context Identification Example of Time Sequence Diagram (Decryption and Calculation of Result) Bregenz August 6, 2008 , 26

Design Principles (19/26) Risk Analysis and Management – Step 2: Risk Identification Fault Tree Diagram (ITEM Toolkit S/W) Bregenz August 6, 2008 , 27

Design Principles (20/26) Risk Analysis and Management – Step 3: Risk Analysis Qualitative assessment of Consequences using FMEA ID Function/ Entity Failure Mode Effects Local Consequen ces Config file is not properly updated by system administrator. Access to config file/database is not possible Connection to database is not possible Voting process may not begin System wide 1 Generate. El. Ga Size parameter mal. Parameters is not available (size) in system config file The public parameters may not be created System initialization is not possible 2 Publish(el. Ga Bulletin Board mal. Parameters is not updated ) with the public parameters Keyholder s may not produce keys System initialization is not possible Bregenz August 6, 2008 , Causes Voting process may not begin 28

Design Principles (21/26) “Layers of Trust” Architecture ü Internal Operational Soundness: High availability and fault tolerance (self-auditing, self-checking, self-recovery from malfunction) Bregenz August 6, 2008 , 29

Design Principles (22/26) Internal Operation Soundness ü One of the most important issues in an e. Voting application is the ability to self-check its internal operation and give warnings when needed. ü Self-checking reduces human intervention and increases the responsibility of the system in case of a non-normal operation. ü Self-checking approaches include: Intrusion Detection Systems, hardware-based software bootloaders for secure start-up (embedded systems) Bregenz August 6, 2008 , 30

Design Principles (23/26) “Layers of Trust” Architecture ü Externally Visible Operational Soundness: Impossible for someone to interfere with the system from the outside (quickly detectable) Bregenz August 6, 2008 , 31

Design Principles (24/26) Externally Visible Operational Soundess It should be possible to detect erratic behavior or ascertain that everything is as expected: Detect some frequently e. Voting system failures and attacks as fast as possible Possible failures and attacks: Failure of a random number generator ü System database damage ü Forging votes ü “Bogus” voting servers ü Bregenz August 6, 2008 , 32

Design Principles (25/26) “Layers of Trust” Architecture ü Convincing the Public: Crucial for the success of the e. Voting system (details available to the public, organize campaigns etc. ) Bregenz August 6, 2008 , 33

Design Principles (26/26) Convincing the public Reassure the public that all measures have been taken in order to produce an error-free, secure and useful application n n Increasing awareness Continual evaluation and accreditation Independence of evaluators Open challenges Bregenz August 6, 2008 , n n Extensive logging and auditing of system activities Contingency planning Regulation and laws Reputation and past experience 34

Presentation Structure n Overview Design Principles n Voting Protocol n n n System Architecture Implementation Tools System Evaluation Publications Bregenz August 6, 2008 , 35

Voting Protocol (1/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 36

Voting Protocol (2/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 37

Voting Protocol (3/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 38

Voting Protocol (4/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 39

Voting Protocol (5/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 40

Voting Protocol (6/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 41

Voting Protocol (7/9) The core steps of the protocol (W. Smith, 2005) Bregenz August 6, 2008 , 42

Voting Protocol (8/9) What the protocol does not support n n Range-voting and write-in votes are not supported – supports 0/1, additive, 1 -out-of-k elections Invisible abstention is not directly supported – anybody can see if a voter has voted by looking at the bulleting board (possible solution: introduce a “dummy” candidate) The protocol does not examine whether the voter is entitled to vote or not The employment of a single EA creates a single-point-offailure, allowing the possibility for Do. S or EA corruption attacks Bregenz August 6, 2008 , 43

Voting Protocol (9/9) Extensions of the protocol n n Multiple Local EAs and Central EA for robustness, efficiency (for large -scale elections) and cross-checking of voting results – avoidance of a single-point-of-failure The recognition of legal voters through a PKI supported election catalogue (only legal voters can vote and if a voter is legal, the voter is not prevented from voting – amplifies the support of the Democracy and Fairness principle) Vote timestamping with the use of Network Time Protocol (NTP) System-oriented defenses, for instance, high-availability or intrusion detection (these also amplify the support of the Democracy and Fairness principles on a systemic, rather than on a protocol level) Bregenz August 6, 2008 , 44

Presentation Structure n Overview Design Principles Voting Protocol n System Architecture n n n Implementation Tools System Evaluation Publications Bregenz August 6, 2008 , 45

System Architecture (1/2) Network Architecture n n n One Central Election Authority Multiple Local Election Authorities communicate over VPN Voters vote to Local EAs, through HTTPS The whole process is monitored by external Verifiers External Parties who may want to (illegally) influence the voting process Bregenz August 6, 2008 , Client 1 Verifiers Client 2 HTTPS Over Internet Client 3 Local EA 1 Client n 2 VPN Over Internet Client 1 Central EΑ Client 2 HTTPS Over Internet Local EAk Client k n Adversaries & Coercers 46

System Architecture (2/2) EA Architecture Verification block Auditors Registration block Registrar Loggers System Core block Bulletin Board Voting Server Manager Keyholders Tallier Administration block System Administrators Bregenz August 6, 2008 , 47

Presentation Structure n Overview Design Principles Voting Protocol System Architecture n Implementation Tools n n n System Evaluation Publications Bregenz August 6, 2008 , 48

Implementation Tools (1/19) Software and Tools n n n n Ubuntu Server Bouncy Castle Java crypto Library Java / Net. Beans Apache/Apache Tomcat Postgre. SQL Open. CA Open. VPN Helena IDS Bregenz August 6, 2008 , n n n Heartbeat Slony-I Network Time Protocol Hardware RNG SG 100 for seeding ATMEL’s ATMega 8 microcontroller for secure bootstrapping of parameters and startup code 49

Implementation Tools (2/19) Ubuntu Server n Ubuntu Server 8. 04. 1 Very Large User base, easy support. n Easy to administrate n n The system can (in theory) be set up in every modern Linux distribution Bregenz August 6, 2008 , 50

Implementation Tools (3/19) Bouncy Castle n n n Bouncy Castle is a collection of API used in cryptography. It includes APIs for both C# and Java It has an easy to use Java API We created our own crypto library, based on Bouncy Castle ver 1. 39 We used Elliptic Curve Cryptography (ECC) to implement El Gamal Encryption Scheme We plan to use ECC for other cryptographic modules of the protocol Bregenz August 6, 2008 , 51

Implementation Tools (4/19) Java Implementation n n n The main core of the system was implemented in Java 5. 0 Bouncy Castle based library Java Servlets Netbeans v 6. 1 HTML Apache Tomcat v 6. 0. 16 Bregenz August 6, 2008 , 52

Implementation Tools (5/19) Apache / Apache Tomcat n Apache (ver 2. 2. 8 -1) n n Hosts the Open. CA Web Interface Responsible for SSL Communication with voters (mod_ssl) Does not allow unauthorized clients to connect Hands over requests for the voting interface to Tomcat Server (mod_jk) Bregenz August 6, 2008 , n Apache 6. 0. 16) n n Tomcat (ver Hosts the voting and administration interfaces Compiles java code of the servlets Handles the database requests contained in the servlets Built-in load balancing 53

Implementation Tools (6/19) Database System n n n Postgre. SQL ver. 8. 3 Decentralized design Central EA holds all the data necessary for the voting process to proceed Each Local EA has a database with the same tables as the Central EA Each Local EA’s database only holds data specific to itself (List of voters, votes, local results) The central database of the system holds the union of all the data stored in the Local EAs, plus some extra voting parameters for the voting process Bregenz August 6, 2008 , 54

Implementation Tools (7/19) Voter Authentication – User Name and Password n n Every eligible voter of the system has a username and a password assigned to him/her by the system The voter must use his/her credentials to access the voting interface Bregenz August 6, 2008 , 55

Implementation Tools (8/19) Voter Authentication – Open. CA n n Access to the voting interface is restricted only to certified browsers The certificates are issued by the Central Certificate Authority, implemented by Open. CA Voters must use Open. CA’s web interface to obtain a certificate for their browser Open. CA is also used to issue all certificates used by the system (Open. VPN, Apache SSL Certificate, User Authentication) Bregenz August 6, 2008 , 56

Implementation Tools (9/19) Open. CA Advantages and Disadvantages þ Tree-like structure for the Certification and Registration Authorities, allowing maximum scalability of the system þ Easy to use Web Interface ý The system administrator must manually approve or disapprove every certificate request Bregenz August 6, 2008 , 57

Implementation Tools (10/19) Open. VPN n n VPN Connection between Local EAs and Central EA Open. VPN Server on Central EA, accessible over the Internet Connection to the VPN requires a certificate SSL Encryption Bregenz August 6, 2008 , 58

Implementation Tools (11/19) Intrusion Detection System: HELENA n n n Developed by RACTI Constantly gathers and analyzes incoming and outgoing traffic from a target network (the network with the central EAs in our case) Local computer agent Master console agent “Not-used” request database Threshold values – updates: target network is modeled with a directed graph with connections (vertices: computers + ports, edges: connection requests) Bregenz August 6, 2008 , 59

Implementation Tools (12/19) Heartbeat Overview n n n Clusters of Computing Systems ensure availability even in case of failure Heart. Beat monitors the health of the nodes If Node 1 fails, then Heartbeat activates Node 2 n Node 2 serves the clients requests Bregenz August 6, 2008 , 60

Implementation Tools (13/19) Database Synchronization n n For the two servers’ DBs to be in sync, we use a Data Base Replication Scheme Slony-I is a "master to multiple slaves" replication system supporting cascading and failover Bregenz August 6, 2008 , 61

Implementation Tools (14/19) High Availability Application Example n n n Heartbeat monitors the health of the two servers of the cluster. Slony-I is used to replicate data between the DBs of the two nodes When a failure is detected in one node, the other takes over Database of backup node is kept up-to-date with Slony-I The votingprocesscan go on without a problem Bregenz August 6, 2008 , 62

Implementation Tools (15/19) Asynchronous Database Replication n Data from Local EAs are transferred to Central EA Slony-I creates “clusters”, consisting of Local EAs and Central EA Asynchronous Between EAs Bregenz August 6, 2008 , Transfer 63

Implementation Tools (16/19) Network Time Protocol (NTP) n n n Timing is essential for the voting process to proceed (time stamping of the votes, opening and closing of the election process) All components taking part in the election process must share the same time An NTP server exists in the system, and every component sets its time using the NTP protocol Bregenz August 6, 2008 , 64

Implementation Tools (17/19) MCUs with protected memory n n Secure storage of keys, voting parameters and bootstrapping code Secure code authentication applications execution and of external Low cost and easy to develop solution (as opposed to TPM based ones) that easily fits legacy hardware and software New version of code and new keys can be dispatched over any insecure communication means in encrypted form – decryption takes place within the MCU Bregenz August 6, 2008 , 65

Implementation Tools (18/19) Hardware RNG SG 100 n n Hardware Random Number Generator Connects to the Serial Port Uses semi-conductor noise Used for seeding the Pseudo Random Generator Bregenz August 6, 2008 , 66

Implementation Tools(19/19) Vulnerability Assessment n Several Vulnerability Scanners were used to assess the security of the servers: n n Nessus Nikto Nmap No significant discovered Bregenz August 6, 2008 , security holes were 67

Presentation Structure n Overview Design Principles Voting Protocol System Architecture Implementation Tools n System Evaluation n Publications n n Bregenz August 6, 2008 , 68

System Evaluation (1/8) Performance aspects – System Simulation n n Network architecture: Directed Acyclic Graph (DAG) Traffic: open network of M/M/1 queues (Poisson distributed arrival rate – exponentially distributed service rate – one server – unlimited queue size) Voters’ arrival behavior: Weibull distributed with a peak around noon Simulation tool: CSIM 19 (C and C++) simulation library Bregenz August 6, 2008 , 69

System Evaluation (2/8) Performance aspects – System Simulation Shifted Weibull distribution with parameters α = 2. 5, b = 5 and t 0 = 8 Time interval λsi [8: 00, 10: 00) 0. 11 [8: 00, 10: 00) 5. 67 [10: 00, 12: 00) 0. 20 [10: 00, 12: 00) 10. 32 [12: 00, 14: 00) 0. 13 [12: 00, 14: 00) 6. 70 [14: 00, 16: 00) 0. 039 [14: 00, 16: 00) 2 [16: 00, 18: 00) 0. 005 [16: 00, 18: 00) 0. 26 [18: 00, 20: 00) Bregenz August 6, 2008 , si (incoming vote rate) 0. 0005 [18: 00, 20: 00) 0. 026 70

System Evaluation (3/8) Performance aspects – System Simulation Bregenz August 6, 2008 , 71

System Evaluation (4/8) Technical Chamber of Greece Mock Up Poll The system used in the mock-up poll Bregenz August 6, 2008 , 72

System Evaluation (5/8) Mock-up Poll Characteristics n Voting Process: Opinion Polling n Eligible Voters: 201 members of the Technical Chamber of Greece n Two Stages n Registration – Certificate Issue (3 -5/12/07) n Vote Submission (6/12/07) n Evaluation of the process by the voters (using questionnaires) n Continuous support (help-desk) Bregenz August 6, 2008 , 73

System Evaluation (6/8) System Operation Step 1: Definition of Voting Paramenets Bregenz August 6, 2008 , Step 2: Certificate Requests 74

System Evaluation (7/8) System Operation Step 3: Voter Login Bregenz August 6, 2008 , Step 4: Electronic Vote Submission 75

System Evaluation (8/8) System Operation Step 3: Vote Announcement in the Bulletin Board Bregenz August 6, 2008 , Step 4: Vote Tallying and Result Announcement 76

Summary ü General, trust-centered, layered approach towards trust building in e. Voting and, generally, e. Government applications ü Based on a design process that incorporates risk analysis/management methodologies for security critical systems (e. g. CORAS) ü Scalability, due to the distributed system architecture ü Large scale simulation results to evaluate the architecture’s efficiency as a function of the voter population size ü A mock-up poll for the members of the Western Greece sector of the Technical Chamber – useful feedback, that was incorporated in the current version of the e. Voting platform Bregenz August 6, 2008 , 77

Presentation Structure n Overview Design Principles Voting Protocol System Architecture Implementation Tools System Evaluation n Publications n n n Bregenz August 6, 2008 , 78

Publications 1. A Trust-Centered Approach for Building e. Voting Systems, 6 th Int. Conf. on Electronic Government September, Regensburg, Germany (EGOV 2007), 3 -7 2. Experiences and Benefits from the Application of a Formal Risk Assessment Framework in the e. Voting Domain, 7 th Int. Conf. on Electronic Government (EGOV 2008), 1 -4 September 2008, Turin, Italy 3. Τhe Design, Implementation and Εvaluation of an Internet-based e. Voting System, invited paper on 12 th Panhellenic Conference of Informatics, 28 -30 August 2008, Samos, Greece 4. A ‘step-wise refinement’ approach for enhancing e. Voting acceptance, submitted 5. Performance Analysis of Distributed, Large-scale e. Voting Systems, to be submitted Bregenz August 6, 2008 , 79

Bregenz August 6, 2008 , 80