Type-Based Verification of Electronic Voting Systems

Transcription

1 saarland university computer science Saarland University Faculty of Natural Sciences and Technology I Department of Computer Science Master s Program in Computer Science Master s Thesis Type-Based Verification of Electronic Voting Systems submitted by Fabienne Sophie Eigner on Supervisor Advisor Reviewers Dr. Matteo Maffei Dr. Matteo Maffei Dr. Matteo Maffei Prof. Dr. Michael Backes

2

3 Statement in Lieu of an Oath I hereby confirm that I have written this thesis on my own and that I have not used any other media or materials than the ones referred to in this thesis. Saarbrücken, Declaration of Consent I agree to make both versions of my thesis (with a passing grade) accessible to the public by having them added to the library of the Computer Science Department. Saarbrücken, I

4

5 Abstract Remote Electronic Voting promises a lot of advantages: It is not only fast and very convenient to use, but it also features additional security properties that cannot be achieved with traditional voting, such as individual or universal verifiability. However, due to the sensitive and critical nature of voting protocols, it is crucial to formally guarantee their correctness with respect to certain intended security properties. In this thesis we will give definitions of inalterability, eligibility, and individual verifiability and use type-based verification to prove the first two properties exemplarily on the remote e-voting protocol Civitas, which we model in the Refined Concurrent Fixpoint Calculus (RCF). Since RCF implementations can be used to reason about executable F# or ML code, this work constitutes the first step toward the analysis of electronic voting implementations. III

6

7 Acknowledgments I would like to thank Dr. Matteo Maffei for offering me the opportunity to work with him on such an interesting topic. I am most grateful for his continuous support and encouragement throughout the development of this thesis. I would also like to express my gratitude to Prof. Dr. Michael Backes for agreeing to review the thesis. Last but not least, I would like to thank my family and friends for their support throughout my studies. They kept me sane in times of insanity and reminded me that there is more to life than work. V

8

9 Contents 1 Introduction Motivation Challenges of Modeling Civitas Contributions Outline Civitas Cryptographic Primitives Protocol Participants Phases of the Protocol RCF Syntax and Informal Semantics Type System Types Typing Environment and Entailment Subtyping and Kinding Typing Values and Expressions Security Properties Eligibility and Inalterability Individual Verifiability Model of Civitas Overview of the Model Participants Secure Multi-Party Computation Implementation of Symbolic Cryptography Dynamic Sealing Randomized Public Key Encryption with Re-Encryption Encryption with Distributed Decryption Encrypt-Then-Sign VII

10 CONTENTS Zero-Knowledge Proofs Ideal Functionality Overview of the Ideal Functionality The Ideal Part Remarks Conclusion and Future Work 45 VIII

11 1 Introduction 1.1 Motivation The design of cryptographic protocols is difficult and error-prone. Proving the security of such protocols manually is tedious and vulnerable to errors. There exist numerous attacks against existing cryptographic protocols, demonstrating the need for formal automated verification [9, 21, 27, 6, 11, 7]. This includes the formalization of intended security properties and the development of automated techniques for proving these properties. Security properties of cryptographic protocols such as authenticity properties or access control policies can be described by logic-based authorization policies [2]. This is a well established and very expressive framework that can be automatically and statically enforced using type systems. By enforcing an authorization policy on an abstract protocol specification or a concrete protocol implementation, a type system can provide a security proof for an unbounded number of protocol executions [13, 12, 5, 4]. This analysis has several advantages: It is modular, compositional, requires little human effort, and has very predictable termination behavior. In this thesis we will use type-based verification to reason about remote electronic voting schemes. Electronic voting is a growing field. Cryptographic protocols for electronic voting are large and usually use complex cryptographic primitives such as zero-knowledge proofs to preserve anonymity and other security properties. There are many different security properties of electronic voting schemes, e.g., individual and universal verifiability, eligibility, inalterability, nonreusability, receipt-freeness, or coercion-resistance. Many of these properties are 1

12 CHAPTER 1. INTRODUCTION not yet formally defined, or their definitions are not based on authorization policies. In 2007, Clarkson et al. [20] presented the remote electronic voting scheme Civitas which according to the authors is the first scheme of its kind that offers both universal verifiability and coercion-resistance. An automated proof of these properties is yet missing, so this work shall provide a first step in the automated analysis of Civitas by giving a faithful model of Civitas and proving eligibility and inalterability for the model. To model Civitas we use the Refined Concurrent Fixpoint Calculus with Union and Intersection Types RCF as presented by Backes et al. [4]. RCF is an extension of RCF [5]. The language is a lambda-calculus with primitives for concurrency. It allows refinement, union, and intersection types and can partially encode F# [5]. There exists a type system with a typechecker to prove authorization policy based properties on RCF code. While this not yet allows us to reason about the concrete Jif implementation of Civitas, the RCF protocol implementation is executable and much closer to an actual implementation than e.g., the applied pi-calculus. This constitutes a first step toward the automated analysis of implementations of electronic voting protocols. 1.2 Challenges of Modeling Civitas With this thesis we provide a first symbolic RCF implementation [4] of the remote electronic voting system Civitas [20]. There are several challenges one has to answer when modeling Civitas. Complexity. Civitas is a large cryptographic protocol. It involves several different participants and relies on many complex cryptographic primitives. Symbolic Library. Many symbolic libraries for cryptographic primitives are not yet defined in RCF, so it is necessary to provide faithful symbolic implementations of all cryptographic primitives that are used in the protocol. Security Properties. The goal of presenting a model of Civitas is to use this model to prove several security properties. Alas, most properties are either defined in an other setting 1 or not at all 2. Thus, we need to provide suitable definitions of these properties. Limitations of the Type System. As we discovered during the course of this thesis, straightforwardly proving security properties does require complicated logical deductions that are outside the scope of what the type system that we use 1 e.g., eligibility and inalterability 2 e.g., individual verifiability 2

13 1.3. CONTRIBUTIONS provides. Thus, one needs to use meta-reasoning of the form there exists some data from a trusted authority that corresponds to a certain value, hence this value fulfills a particular property. Since the participants of a protocol usually should not have access to trusted secret data, this requires the existence of a trusted ideal functionality that can access secret data and reason on it, without revealing any secrets. 1.3 Contributions We propose novel definitions of important security properties of electronic voting systems: We give a new definition of eligibility and inalterability based on authorization policies and the first formal definition of individual verifiability. Furthermore, we present a first faithful model of Civitas [20] in the typed calculus RCF [4] and prove eligibility and inalterability of the model using type-based verification. This automated verification uses the F5 type-checker [4], which relies on a type system with refinement, union, and intersection types. Additionally, we give a novel symbolic implementation of complex cryptographic primitives such as randomized public key encryption with re-encryption, public key encryption with distributed decryption, encrypt-then-sign operations, and polymorphic non-interactive zero-knowledge proofs, that can be used to model cryptographic protocols. The complete RCF implementation files of our model of Civitas are available at [10]. 1.4 Outline Section 2 gives a brief overview of the Civitas voting system [20] by Clarkson et al. while Section 3 briefly recaptures RCF as presented by Backes et al. in [4]. In Section 4 we present our new definitions of eligibility and inalterability of electronic voting systems, as well as a novel definition for individual verifiability. Section 5 shows our model of Civitas in RCF and our symbolic implementation of complex cryptographic primitives. Section 6 concludes the thesis and discusses future work. 3

14

15 2 Civitas In this section we will give a short overview of the Civitas system [20] as proposed by Clarkson, Chong, and Myers. It is a refinement of the cryptographic voting scheme by Juels, Catalano, and Jakobsson [17], suitable for remote voting and offering coercion-resistance as well as universal and individual verifiability. For further details on the protocol and its implementation we refer to [20]. 2.1 Cryptographic Primitives In addition to standard cryptographic primitives such as public key encryption, signature schemes, and hashes, Civitas uses some more complex primitives, which we will briefly present in this section. For example, the system requires encryption schemes which offer homomorphic encryption, random re-encryption, and distributed decryption. In such a scheme multiple parties generate a joint public encryption key for which each party holds a secret partial decryption key. In order to decrypt a message encrypted with the joint public key, all parties need to cooperate, no party can recover the plaintext on its own. Furthermore, there is the need for distributed plaintext equivalence tests (PET), where multiple key holders jointly check whether two ciphertexts contain the same plaintext without decrypting. Additionally, Civitas makes use of a number of non-interactive zero-knowledge proofs and a mix network. 5

16 CHAPTER 2. CIVITAS 2.2 Protocol Participants There are five different kinds of principals in Civitas: A supervisor, a registrar, registration tellers, and tabulation tellers, which together constitute the election authorities, and the voters. Additionally, there exists a publicly readable bulletin board and some ballot boxes. The protocol is designed to be resistant to the compromise of some of its participants. Supervisor. The supervisor is the administrator of the election. He is responsible for specifying the ballot design, appointing the tellers, as well as starting and stopping the election. Registrar. The registrar is responsible for authorizing eligible voters to participate in the election. Registration Tellers. The registration tellers jointly generate the credentials that are used by the voters to cast their votes. Tabulation Tellers. The tabulation tellers jointly tally the votes. Voters. Eligible voters can receive their credentials and cast their vote to one or more ballot boxes. 2.3 Phases of the Protocol Civitas is divided into four distinct phases: setup, registration, voting, and tallying. Setup Phase The supervisor sets up the election, starting by posting the ballot design on a fresh bulletin board. Afterwards, he selects the tellers and posts their public keys on the bulletin board. Then the registrar posts the electoral roll on the bulletin board. For each voter the roll contains a unique identifier and two public keys: the registration and the designation key, whose uses are described below. In the meantime, the tabulation tellers generate a joint public key for an encryption scheme with distributed decryption and publish it on the bulletin board. In the end, the registration tellers jointly generate credentials for each voter. These credentials are necessary so that during the voting phase a voter can prove 6

17 2.3. PHASES OF THE PROTOCOL that he is authorized to vote while remaining anonymous. For each voter every registration teller generates a unique private credential share and stores it. Additionally, the tellers encrypt the generated credential shares using the joint encryption key of the tabulation tellers and post these public credential shares on the bulletin board. The public credential of each voter is constructed by combining all of the respective public credential shares. Registration Phase In order to vote, each voter must first acquire his private credential. Thus, it is necessary for the voter to register with each tabulation teller. First, the tellers authenticate the voter using his registration key. Second, each teller sends the voter the respective private credential share and a designated verifier re-encryption proof (DVRP). This zero-knowledge proof uses the public designation key of the voter 1 and proves that the private credential share corresponds to a public credential share on the bulletin board. The voter then checks the validity of the received DVRPs and given the successfull verifictaion of these proofs constructs his private credential by combining all private credential shares. Voting Phase After receiving his private credential and the official beginning of the voting phase a voter can cast a ballot as follows. First, he encrypts both, his choice of a candidate and his private credential with the public key of the tabulation tellers. Furthermore, he provides two zero-knowledge proofs: One that proves the mutual knowledge of the vote and the credential, and a second one that proves that the vote is indeed a valid choice. The ballot then consists of the encrypted vote, the encrypted credential, and the two proofs. Second, he submits the ballot to one or several of the ballot boxes. Obviously, the more ballot boxes he sends the ballot to, the higher is the probability of reaching an honest one. Note that it is possible for a voter to cast several votes. Whether re-voting is allowed or whether all later ballots of a voter are eliminated during the tabulation phase depends on the design of the election. Tabulation Phase At the beginning of the tabulation phase, all ballot boxes commit to their content on the bulletin board. The supervisor signs these commitments, thereby defining the votes to be tabulated. The tabulation tellers then collectively tally the ballots as follows: 1 this is necessary to provide coercion-resistance, for more information we refer to [20] 7

18 CHAPTER 2. CIVITAS 1. Retrieve Votes and Credentials. The tabulation tellers retrieve the contents of the ballot boxes and check them against the respective commitments on the bulletin board. Furthermore, they retrieve the list of public credentials from the bulletin board. 2. Check Proofs. They check the zero-knowledge proofs contained in each ballot and remove all ballots with invalid proofs. 3. Eliminate Duplicates. Each ballot is checked against each other ballot by comparing the encrypted credentials contained in them using a PET. In order to do so, each tabulation teller needs to do a partial PET of the encrypted credentials using his own secret decryption key and post this partial result on the bulletin board. To compute the complete PET, these partial results need to be combined. Duplicates are then eliminated according to a fixed policy of the election setup. 4. Anonymize. The tellers anonymize both the list of remaining ballots and the list of public credentials using a mix network [8]: Each teller applies a random permutation and re-encryption to the lists. 5. Eliminate Unauthorized Votes. Ballots with an encrypted credential that does not correspond to one of the anonymized public credentials are eliminated by the tellers using PETs as in step (3). 6. Decrypt. The remaining encrypted votes (not credentials) are decrypted using partial decryption: Each tabulation teller partially decrypts the vote using his own secret decryption key and posts the partial result on the bulletin board. 7. Tally. The final tally can be publicly computed by combining the partially decrypted votes from the previous step. Additionally, for steps (3) to (6) all tabulation tellers post zero-knowledge proofs on the bulletin board to show the correctness of their computations. 8

19 3 RCF To model e-voting protocols we use the Refined Concurrent Fixpoint Calculus with union and intersection types (RCF ) [4], which we will present in the following section. It extends the Refined Concurrent FPC (RCF) [5] with intersection [22] and union types, as well as parametric polymorphism [15, 23], making it even more expressive. RCF is a simple programming language based on the λ- calculus. It is an extension of the Fixpoint Calculus (FPC) [16] with concurrency [1] and refinement types [14, 24, 28]. The calculus is expressive enough to encode a large fragment of F# [5]. The additional expressiveness of RCF enables the encoding of more complex primitives such as zero-knowledge proofs, which are crucial for electronic voting. We will give a short definition of the syntax and semantics of RCF, as well as a brief overview of its type system. For details we refer to [4, 5]. 3.1 Syntax and Informal Semantics We distinguish between values and expressions. The set of values consists of variables, the unit value, functions, pairs, and introduction forms for recursive and polymorphic types (cf. Table 3.1). Variables are used as place-holders for values, whereas names (which are generated at runtime) serve as channel identifiers. Expressions describe concurrent computations. These computations can either reduce to a value, diverge, or deadlock. This reduction relation is defined on computation states. Each state consists of three parts: Several expressions that are currently being evaluated in parallel, messages that were sent on channels but not yet received, and a global log, which contains the formulas that are 9

20 CHAPTER 3. RCF a, b, c name x, y, z variable M, N ::= value x variable () unit λx : T. A function (M, N) pair Λα. A polymorphic val. fold µα. T M recursive val. for α in T ; Ũ do M, where { α} free(m) intersection val. A, B ::= expression M value M N function application M T type instantiation if M = N as x then A else B equality check with type-cast let x = A in B let let (x, y) = M in A pair split unfold µα. T M use recursive value for α in T ; Ũ do A introduction of intersections case x = M : T U in A elimination of union types (νa T )A restriction A B fork a!m send M on channel a a? receive message from a assume C assumption of formula C assert C assertion of formula C Notation: Given a phrase of syntax φ, let φ{m/x} denote the substitution of each free occurrence of the variable x in φ with the value M. We use φ to denote the sequence φ 1,..., φ n for some n. Table 3.1: Syntax of RCF values and expressions assumed to be true 1. In the following we will show how expressions can be reduced. A value is irreducible, it cannot be reduced any further. The function application (λx:t. A) M reduces to A{M/x}, meaning each occurrence of x in A is replaced by M. Similarly, a type instantiation (Λα. A) T reduces to A{T/α}. The conditional if M = N as x then A else B can reduce to either A{M/x} (in case M is syntactically equal to N) or to B otherwise. Note that in the first case the variable x is equal to both M and N, and has type M N. This means that the conditional is a safe type-cast operator. If this type-cast is not needed the conditional can be used without as x. To reduce the introduction form for intersection types for α in T ; Ũ do A one needs to distinguish two cases: Assume that A reduces to a value M. If M does not contain α then the overall expression reduces to M, otherwise it returns the value for α in T ; Ũ do M. The elimination form for union types case x = M : T U in A reduces to A{M/x} The restriction (νa T )A is used to generate a globally fresh channel a. This channel a can only be used in A, where it can only convey values of type T. The expression A B is used to describe concurrency. It evaluates A and B in parallel, before returning the result of B (discarding the result of A). The expressions a!m and a? are used to describe communications via channels. The former expression outputs M on channel a, then reduces to the unit value (). The latter blocks until some message M is available on channel a, removes M from the channel, and then returns M. Both assume C and assert C are used to reason about logic formulas C. As its name proposes, the assumption assume C adds C to the global log, hereby assuming the formula to be true. The assertion assert C reduces to (). Depending on whether C is entailed by the multi-set S of formulas in the global 1 As the authorization logic we consider first-order logic with equality. 10

21 3.2. TYPE SYSTEM log or not, we say the assertion succeeds (in which case we write S = C) or we say that it fails. Definition 1 (Safety) A closed expression A is safe if and only if, in all evaluations of A, all assertions succeed. When reasoning about implementations of cryptographic protocols, we are interested in the safety of programs executed in parallel with an arbitrary attacker. This property is called robust safety. Definition 2 (Opponent and Robust Safety) A closed expression O is an opponent if and only if O contains no assertions and O only contains Un for the type annotations. A closed expression A is robustly safe if and only if the application O A is safe for all opponents O. 3.2 Type System This section briefly presents the type system for enforcing authorization policies on RCF code as defined in [4]. Our description will be in prose, more details and the complete set of typing rules can be found in [4]. We will start by giving a short summary of the existing types, before giving a few examples how the typing of judgments works. The type system relies on different kinds of typing judgments such as well-formed environment, entailment, subtyping, kinding, value typing, and expression typing Types The syntax of types can be found in Table 3.2, which we will briefly explain in the following. There exists a top type that is supertype of all the others (more information on subtyping can be found in Section and in [4]). A value that has both type T and type U can be given the intersection type T U. If we know that a value is of type T or of type U (but not necessarily which exactly) we give it the union type T U. Refinement types are used to associate logical formulas to messages. The refinement type {x : T C} is used to represent values M of type T for which the current typing environment entails the formula C{M/x}. In order to type functions λx : T. A, types of the form x : T U are used. This type describes a function which takes as input values of type T and returns values of type U, where U can depend on the input value x. A pair has a dependent type of the form x : T U, meaning the first component of the pair is of type T and the second component is of type U, which might depend on the value x of the first component. If U does not depend on x, the type might be abbreviated to T U. The sum type T + U describes values inl(m) where M is of type T and values inr(n) where N is of type U. The iso-recursive type 11

22 CHAPTER 3. RCF T, U, V ::= top type unit unit type T U intersection type T U union type {x : T C} refinement type x : T U dependent function type x : T U dependent pair type T + U disjoint sum type α type variable µα. T iso-recursive type α. T polymorphic type Notations: Let T U x : T U and T U x : T U, where in both cases x free(u). Let {C} denote {x : unit C} where x free(c). Table 3.2: Syntax of Types µα. T is the type of all values fold µα. T M such that M is of type T {µα. T/α}. The universal type α. T is used to describe polymorphism. It denotes values Λα. A such that A{T /α} is of type T {T /α} for all T. Additionally we use Un to describe the type of messages that are possibly known to an adversary (in [4] this coincides with type unit), and Private for the type of messages that are never revealed to the adversary. There exist encodings [4, 5] for these and other types such as Bool, List α, or Option α. It is also possible to express types for different cryptographic primitives using these basic types, e.g., SigKey(T ) or VerKey(T ) can be used to describe the signing and verification keys used to sign and verify messages. Note that the type system enforces that such a signing key can only be used to sign messages of type T Typing Environment and Entailment A typing environment E is a list of bindings for type variables (α), names (a T, denoting a channel a used for conveying values of type T ), and variables (x : T ). If no name or variable is bound more than once, and if all free names or variables have been bound in the environment E before appearing inside a type or formula in E, the typing environment E is well-formed, denoted by E. All the other typing judgments (e.g., expression typing) check the well-formedness of the environment they use. The close connection between formulas and types can be seen in the following judgment of the type system: E C states that the formula C is derivable from the typing environment E, meaning that C is logically entailed by the global formula log at execution time. For example, this is needed to typecheck assertions of the form assert C, which will only succeed if for the current typing environment E it holds that E C. Refinement types can be used to 12

23 3.2. TYPE SYSTEM convey such formulas. For instance, if the environment E contains a binding of the variable y to a refinement type {x : T C}, the formula C{y/x} is entailed in the system and hence it holds that E C{y/x}. The overall idea is to check each of the type bindings in E and to extract all formulas occurring within refinement types. For intersection types the union of the formulas occurring in the two types is taken, while for union types we consider the component-wise disjunction Subtyping and Kinding As mentioned in Section the type system considers a universal type Un (untrusted) for data that is possibly known to an attacker, which is crucial when reasoning about programs that interact with an adversary. For instance, we would use a Un to model an untrusted channel. Any data sent or received on that channel a would have type Un, since untrusted channels are considered to be controlled by the attacker. Nevertheless, in order to allow for more interesting types to be sent over an untrusted network, e.g., a value of type {x : Un Ok(x)} the type system defines a subtyping relation on types. This allows the usage of a term of a subtype in all contexts that require a term of a supertype. Subtyping is mostly used for comparisons between types and type Un. A value of type T, where T <: Un (meaning T is a subtype of Un), can be sent over an untrusted network. In this case the type T has kind public. Similarly, a value that was received from the untrusted network, therefore having type Un, can be used as a value of type U, given that Un <: U. In this case type U has kind tainted. Note that the type Private is neither public nor tainted. We will give some intuition for a few subtyping and kinding rules. For further details we refer to [4, 5]. Refinement Types. A refinement type of the form {x : T C} is a subtype of T. With the help of this rule logical formulas may be ignored whenever they are not needed. It is also the case that the type T is a subtype of {x : T C} if and only if x.c is entailed by the current typing environment. If T is public, so is the refinement type {x : T C}, since subtyping is transitive and hence {x : T C} <: T <: Un. Analogously, if T is tainted and additionally it holds that x.c, type {x : T C} is tainted. Function Types. A function T U is a subtype of T U if T is a subtype of T and U is a supertype of U. This means that function types are contravariant in their input and covariant in their output, so a function can be used in place of another one if the former accepts all the inputs and returns only a subset of the outputs of the latter. Hence, a function T U is public (i.e., a subtype of Un Un) if T is tainted (i.e., Un <: T ) and U is public (i.e., U <: Un) Analogously, if T is public and U is tainted, the function T U is tainted. 13

24 CHAPTER 3. RCF Union and Intersection Types. Since the rules for union and intersection types are dual, we will only give a few short examples of subtyping and kinding of intersection types. For example, the type T 1 T 2 is a subtype of U if T 1 or T 2 is a subtype of U. Additionally, it holds that if T a subtype of both U 1 and U 2, it is also a subtype of U 1 U 2. Intuitively, a value of type T 1 T 2 is of type T 1 and of type T 2. An intersection type T 1 T 2 is public if T 1 or T 2 is public, and it is tainted if both T 1 and T 2 are tainted Typing Values and Expressions The most interesting judgments of the type system are those to type values and expressions. The judgment E A : T (similar E M : T for values) states that the expression A can be reduced to a value of type T. In the following we will give a few examples of typing rules for expressions. The rules for most values and expressions such as function applications, pair splitting, let commands, and forks are rather standard and can be found in [5, 4]. Assumptions and Assertions. The assumption assume C has type { : unit C}, which means each well-formed formula can always be assumed. Type-checking assertions of the form assert C is harder. This only succeeds if the formula C is entailed by the current typing environment. On channels of type T only values of type T can be sent and re- Channels. ceived. Conditionals. Type-checking the conditional if M = N as x then A else B uses intersection types. If M is of type T 1 and N of type T 2, we will type-check A assuming x = M M = N and x to have type T 1 T 2. Type-checking B will assume M N, while not caring about the type of x. Note that in the case of disjoint types T 1 and T 2 (e.g., Un and Private) the comparison M = N will always fail (since values of different types can never be syntactically equal), hence the expression A will not be executed. In this case A is type-checked in an environment where false is added. Type-checking in an inconsistent environment always succeeds, so A will automatically type-check, and the success of typechecking the overall conditional only depends on B. Union Types. Type-checking case x = M : T 1 T 2 in A, where x takes the place of M in A, yields type U under the condition that A is of type U regardless of whether x is of type T 1 or whether x is of type T 2. This means that since it 14

25 3.2. TYPE SYSTEM is not known whether M is of type T 1 or T 2, A needs to type-check under each assumption individually. Intersection Types The expression for α in T ; Ũ do A has type T 1 T 2 if two conditions are fulfilled. First, A{ T / α} is of type T 1 and second, A{Ũ/ α} has type T 2. Hence, introducing an intersection type requires type-checking A twice, possibly with different type annotation in both cases. Intersection types are very useful when type-checking a function (cryptographic primitive) that should be available to both, honest and dishonest participants. For instance, the function implementing public-key encryption will have a type of the form (T Un) (Un Un). This allows honest users to encrypt messages of type T and dishonest users to encrypt messages of type Un, while yielding ciphertexts of type Un in both cases. 15

26

27 4 Security Properties There are many security properties that an e-voting protocol should possess: Eligibility [3], inalterability [3], individual and universal verifiability, coercionresistance [3, 18], and non-reusability [3] to mention but a few. In the following chapter we will use authorization policies to give new, handson definitions of eligibility and inalterability and propose a novel definition of individual verifiability, a property that has not been formally defined so far. In Section 5 we will then exemplarily show how eligibility and inalterability can be proven using these definitions. We consider a first-order logic with equality to be the authorization logic of the type system. We will annotate security-related protocol events with assumptions and assertions and introduce the authorization policy as an additional global assumption. If all assertions are entailed at run-time by the currently active assumptions, the desired property expressed by the authorization policy is enforced. 4.1 Eligibility and Inalterability Intuitively, eligibility guarantees that only eligible voters are able to vote and inalterability means that no one can change anyone else s vote. To show eligibility and inalterability we will annotate the model with the following assumptions and assertions. We assume that these assumptions and assertions are only used in the following context. 17

28 CHAPTER 4. SECURITY PROPERTIES During the registration phase the registration authorities will introduce the assumption assume ValidID(id) for each eligible voter that tries to register, where id is a unique identifier of the voter. During the voting phase the voter adds the assumption assume BeginVote(id, enccred, vote), where vote and enccred are his choice of candidate and his encrypted private credential respectively, and id his unique identifier. While checking the validity of the encrypted credentials contained in the ballots against the public credentials during the tabulation phase, the tabulation tellers introduce an assumption assume PlaintextEquiv(enccred, pubcred) for each encrypted credential enccred and public credential pubcred that are encryptions of the same private credential. Before publishing the final results of the vote, the tabulation tellers add the assertion assert VoteOK (pubcred, vote). As a global assumption the following authorization policy is added: assume ( id, vote, enccred, pubcred : ValidID(id) BeginVote(id, enccred, vote) PlaintextEquiv(enccred, pubcred) VoteOK (pubcred, vote)) Definition 3 (Eligibility and Inalterability) An electronic voting protocol that is annotated in the above defined manner guarantees eligibility and inalterability if it is robustly safe (see Def 2), meaning all assertions (and in particular all assertions of the form assert VoteOK (pubcred, vote)) succeed. It is clear that an assertion of the form assert VoteOK (pubcred, vote) can only be entailed according to the above defined authorization policy, if there exists an identifier id, an encrypted credential enccred, and the respective assumptions assume ValidID(id), 18

29 4.2. INDIVIDUAL VERIFIABILITY and assume BeginVote(id, enccred, vote), assume PlaintextEquiv(enccred, pubcred). This implies that all counted votes indeed stem from an eligible voter who tried to vote for candidate vote using his own private credential. This covers our intuitive definition of eligibility and inalterability. Note that this definition depends on the concrete voting system and its model and can be adapted or simplified as needed. Instead of using the different encrypted credentials in BeginVote and VoteOK, depending on the protocol one could also use just the public credential, a private credential, or some other form of identifier, which in some cases might allow the removal of the PlaintextEquiv assumption. We also do not pose any restrictions on the kind of identifier that is to be used, it could be the name of a voter, his credential, or some other uniquely identifiable data of which both the registration authorities and the voter have knowledge. 4.2 Individual Verifiability Informally, individual verifiability means that after the final results of the election have been published, each voter can verify that his vote has been included correctly in the final tally. We will define this similarly to the previous properties by annotating the model with the following fresh assumptions and assertions: As in the previous definitions of eligibility and inalterability given in Section 4.1 the voter adds the assumption assume BeginVote(id, enccred, vote) during the voting process, where id is his unique identifier, vote his choice of candidate, and enccred his encrypted private credential. When publishing the final results of the vote, the tabulation tellers add the assumption assume EndVote(enccred, vote) for each ballot (consisting of the encryption of the vote and the encrypted public credential enccred) that should be included in the final tally. After the results have been published, each voter checks the results on the bulletin vote and introduces the assertion assert VoteCounted(enccred, vote). 19

30 CHAPTER 4. SECURITY PROPERTIES As a global assumption the following authorization policy is added: assume ( id, vote, enccred : BeginVote(id, enccred, vote) EndVote(enccred, vote) VoteCounted(enccred, vote)) Definition 4 (Individual Verifiability) Such an annotated electronic voting system guarantees individual verifiability if it is robustly safe (see Def 2). In particular, this means that all assertions of the form are entailed at runtime. assert VoteCounted(enccred, vote) Such an assertion assert VoteCounted(enccred, vote) can only be entailed according to the given authorization policy, if there exist corresponding assumptions assume BeginVote(id, enccred, vote) and assume EndVote(enccred, vote). This is only the case if the voter that tries to assert VoteCounted(enccred, vote) did indeed vote for the candidate vote using the encrypted credential enccred and the tabulation tellers included this vote in the final tally, which corresponds to the intuitive definition of individual verifiability. Note that the assumptions and assertions used for eligibility, inalterability, and individual verifiability do not conflict, so it is possible to prove all three properties on the same model at the same time. 20

31 5 Model of Civitas In the following section we will present a first faithful model of Civitas in RCF, including all necessary assumptions and assertions to prove eligibility and inalterability. We have successfully implemented and type-checked the RCF code, and hence shown eligibility and inalterability for our model of Civitas (with respect to Def 3). For the sake of simplicity our RCF implementation is based on a slightly simplified version of the protocol, but it uses several novel ideas and implements new complex cryptographic primitives that can be employed for future work, e.g., to extend the model of Civitas, or to model other electronic voting schemes. We will give a short overview of our model and the most important design decisions in Section 5.1, before explaining the novel RCF implementations of several important cryptographic primitives that we developed in the context of this thesis in Section Overview of the Model Participants For the scope of this thesis, the model contains the bulletin board, one registration teller, several voters, one ballot box, and two tabulation tellers. The number of participants could be easily extended, e.g., the same ideas that we employ in our model can be used to increase the number of tabulation tellers from two to arbitrarily many. So far, we assume all participants to be honest. Modeling dishonest participants would be interesting future work, but goes beyond the 21

32 CHAPTER 5. MODEL OF CIVITAS scope of this thesis. The different phases of a run of the model implementation are consistent with those of the real protocol, with the exemption of the mix networks employed during the tabulation phase. We leave the modeling of this cryptographic primitive as future work. Additionally, we use a secure multiparty computation to model the tallying of the votes: Instead of performing the necessary steps to tally a ballot themselves, the tabulation tellers call an ideal functionality that collects the (secret) inputs from the tellers and does the desired computations for them. For an observer it is indistinguishable whether the steps have been performed by the tabulation tellers with or without the help of such an ideal functionality. This is a standard approach in modeling an ideal protocol that is equivalent to the real one. We will explain our reasoning behind the need for such a secure multi-party computation in Section once we have given a short overview of the most important participants of our model. All of the participants are implemented as functions that are then instantiated and executed in parallel in the main implementation file that acts like the supervisor and registrar would. The tabulation tellers share a joint public encryption key for encryption with distributed decryption (called ektt c ) that is used to encrypt credentials, and one that is used to encrypt votes, which we will call ektt v. 22 Registration Teller. The registration teller produces a credential and corresponding DVRP for each voter. Additionally, he adds the assumption assume ValidID(cred). He encrypts the credential with ektt c and signs this public credential before sending it to the bulletin board. He finishes by returning the private credential and DVRP. Voters. Each voter is instantiated with his private credential cred and the DVRP. This simulates the credential exchange over a secure private channel. He checks that the DVRP is valid and votes for the candidate vote of his choice as follows: First, he introduces the assumption assume BeginVote(cred, vote). Afterwards, the voter encrypts his vote with ektt v and his private credential cred with ektt c and produces two zero-knowledge proofs to show his knowledge of a valid credential and the validity of his vote. He sends the tuple of both encryptions and zero-knowledge proofs to the ballot box. Tabulation Tellers. After the ballot box has committed to its content it sends the ballots to the tabulation tellers. The tabulation tellers recover the public credentials and the commitments from the bulletin board, and call the ideal functionality. They send all the necessary inputs to the ideal

33 5.1. OVERVIEW OF THE MODEL functionality, such as the ballots, public credentials, commitments, and in particular all of their secret decryption and signing keys. Ideal Functionality. The ideal functionality performs the intrinsic calculations of tallying the ballots. Before finally counting a ballot containing the choice of candidate vote and the encryption of the credential cred, the ideal functionality checks the validity of the ballot and additionally asserts assert VoteOK (cred, vote). More details will be given in Section 5.3. The bulletin board and ballot box are modeled in a straightforward way, storing all inputs in a list and outputting them on demand (or in the case of the ballot box at the end of the election). Authorization Policy. Note that the predicates we use in the assumptions and assertions to prove eligibility and inalterabilty deviate a little from those given in Section 4.1. These simplifications make the proof easier in this example but still express the desired properties. Since each private credential cred is unique, we can use it as a unique identifier in ValidID(cred). For reasons that we will explain in the following Section 5.1.2, the ideal functionality will decrypt the public credentials, hence giving it access to the corresponding private credential cred. Thus, there is no need for us to include the encrypted credential in the BeginVote predicate or the public credential in the VoteOK predicate, since we can now immediately connect both events using the private credential cred. Hence, we use the simplified assumptions assume BeginVote(cred, vote) and assume VoteOK (cred, vote) instead. Since there is no longer the need for a predicate that states that the encrypted credential from a ballot and a public credential from the bulletin board are encryptions of the same plaintext, we can adjust our authorization policy to look as follows: assume ( cred, vote : ValidID(cred) BeginVote(cred, vote) VoteOK (cred, vote)) 23

34 CHAPTER 5. MODEL OF CIVITAS Secure Multi-Party Computation We will now explain why we chose a secure multi-party computation for the tabulation of the votes. It seems a bit counter-intuitive to use an ideal functionality for tabulation, in particular because the library of cryptographic primitives that we provide in Section 5.2 is sufficient to let the tabulation tellers compute the results in a distributed manner without external help. The sole purpose of replacing these computations by an ideal functionality is to prove eligibility and inalterability of the model, since it is not possible to assert VoteOK (cred, vote) for votes vote and private credentials cred without it. Let us assume for a moment that there is no ideal functionality but only the tabulation tellers. In this case, those two would need to assert VoteOK (cred, vote). This assertion will only succeed if the assumptions assume ValidID(cred) and assume BeginVote(cred, vote) have been made before, so that the authorization policy can be applied. We are faced with the following problem: It is the registration teller who assumes ValidID(cred) and the voter who assumes BeginVote(cred, vote), but both assumptions need to be known to the tabulation tellers. Thus, we need to transport the assumptions to the them. This can only be achieved by encoding them in a refinement type that is an input to the tabulation tellers. Transmitting ValidID. Looking at the protocol, it is obvious that the only input the tabulation tellers get from the registration teller are the signed public credentials that the registration teller posts on the bulletin board. Hence, it is necessary to convey the assumption ValidID(cred) in the corresponding public credential. An intuitive way to encode the assumption ValidID(cred) in a refinement type would be to give the private credential cred the refinement type {c : Private ValidID(c)}. The joint encryption key of the tabulation tellers ektt c would then necessarily have type 1 EncKeyD {c : Private ValidID(c)}, T r so that an honest party can only encrypt credentials that have this particular refinement type. However, this means that the tabulation tellers would need to decrypt the public credential in order to retrieve the assumption from the refinement type. Yet this is something the (possibly dishonest) tabulation tellers are not allowed to do in Civitas. For this reason, we use a trusted ideal functionality 1 EncKeyD α, β is the type of joint public encryption keys for encryption with distributed decryption that can be used to encrypt messages of type α with randomness of type β. Further information can be found in Section

35 5.1. OVERVIEW OF THE MODEL which will decrypt the public credential in order to prove the assertion assert VoteOK (cred, vote) without ever revealing the private credential to anyone. This is also the reason why it is sufficient to use the private credential in the above mentioned authorization policy instead of the public one: The ideal functionality has access to it anyway. A further complication lies in the fact that since the encryption key ektt c is public, it is also available to the adversary, who can in turn also use it to encrypt messages of type Un. This means, that when the ideal functionality tries to decrypt a public credential the resulting credential cred will have type {c : Private ValidID(c)} Un, so it is unclear whether the predicate ValidID(cred) holds or not. We will solve this problem by using the following additional information: All public credentials are signed by the registration teller (which we assume to be honest). For this reason we will define a cryptographic primitive encrypt-then-sign which encrypts and signs a message of type T as one would expect, but has the additional advantage that if decrypting and checking a ciphertext with a respective signature succeeds, the decrypted message will always be of type T and not type T Un. We present this primitive in Section Transmitting BeginVote. The same problem arises for transmitting BeginVote(cred, vote) from the voter who assumes this predicate to the tabulation tellers (or the ideal functionality respectively). Again let us assume for a moment that there is no secure multi-party computation. Intuitively, we would like to give vote the respective refinement type carrying the assumption. Then the tabulation tellers could recover this predicate by decrypting the encrypted vote 2 sent by the voter. Yet, we are faced with the same complication as before: Since ektt v is public it can also be used by an attacker to encrypt messages of type Un. Hence, the tellers cannot be sure that the vote they retrieves by decrypting the encrypted vote is of the desired refinement type or has type Un. Unfortunately, we cannot use the same solution as in the previous example: Using encrypt-then-sign to encrypt the vote would mean that the voter would reveal his identity (by signing), and thus anonymity would not be preserved. Therefore, we need to encode the predicate in one of the zero-knowledge proofs 2 encrypted with the joint encryption key ektt v 25