Cryptographic Methods for Storing Ballots on a Voting Machine

Cryptographic Methods for Storing Ballots on a Voting Machine John Bethencourt Carnegie Mellon University Dan Boneh Stanford University Brent Waters SRI International

Outline • Background • DRE voting machines • Desired properties • Previous work • History-hiding append-only signatures • Intuition • Simple construction • Efficient construction • Secure vote storage • Architecture • Evaluation and comparisons

Current DRE Voting Machines • Who knows what happens to your vote ? ? ?

Are Current Machines Really Vulnerable? • You all know the answer • Code and hardware should be open to inspection • Companies claim they are proprietary secrets! • Let’s assume original software benign • Still, many vulnerabilities / blunders identified • Malicious code in machine could alter votes undetected • Easy to insert code with physical access to memory • Latest: easy to get physical access to memory card …

How to Open a Voting Machine • Locked door over memory card • Essentially all use same key! • Picture of key on website • Someone tried making a key from this • Just used a manual file • Didn’t have a machine to test it • Sent it to someone who had a Diebold AccuVote-TS

Securing Voting Machines • OK, so machines horribly vulnerable • How can we do better? • Two main lines of research • Idea #1: cryptographic voting protocols of Chaum and others (completely untrusted machines) • Idea #2: just try to make machines more trustworthy • Idea #2: big problem, many aspects • Software verification • Hardware verification • Social aspects of procedures • This project: securing vote storage mechanism

Desired Properties for Vote Storage • Durable • Should be robust to system failures • Tamper-evident • Want to detect changes to stored ballots after they are recorded • History-independent • Stored votes must not reveal ordering • Subliminal-free • Malicious implementation or user must not be able to hide ordering in data structures somehow

Previous Work:Write-Once Storage on PROM’s • Tamper-evidence … but swapping possible

Private Key Public Key Idea:Let’s Try to Address That too! • We’ll sign to prevent replacement

Public Key What if Key Compromised? • Maybe use some sort of forward secure techniques

Append-Only Signatures • Need special signatures • Validates a set of messages • No private key • Signature for one set can be used to sign new set after adding something • Must be hard to sign subset of X with signature on X

Append-Only Signatures • Generate signature on the empty set • Given a signature for some set X, generate a signature on X U {m} • Check if ¾ is a valid signature on the set {m1, m2, … mn}

Properties • Correctness • After a sequence of Appends, signature should Verify on appropriate set • Append-only • While easy to sign a superset of X given a signature on X, should be hard to sign subset of X • Also need history-hiding for voter privacy • Signature must not reveal order messages added • Otherwise vote buying, coercion • Tension with append-only property • In particular, forward secure signatures can’t be used

History-Hiding Append-Only Signatures • HHAOS can be built from any signature scheme • Simple construction for up to N messages • KeyGen: make N public/private key pairs, store as initial signature • Append: pick a random unused key pair, sign with the private key, then delete that private key • Weaknesses • Inefficient: O(N) space regardless of how many you have signed so far • Not subliminal-free due to random selection of key pair

HHAOS: Efficient Scheme • Pairing based scheme similar to aggregate signature scheme of Boneh et al. 2003

HHAOS: Efficient Scheme • Result of series of Appends:

HHAOS: Efficient Scheme • Set finalization • Extension that “closes signature” • No further appends possible after finalization • Can be added to any HHAOS scheme • Verify must return false if “finalize” || k in signature and |M| not k

HHAOS: Efficient Scheme • Properties • Correct • Append-only (under CDH in ROM) • History-hiding (actually history-independent) • But still not subliminal-free

HHAOS: Efficient Scheme • But we can do untrusted rerandomize • Honest implementation: subliminal channels wiped • Malicious implementation: subliminal channels may remain, but cannot change validity of signature • Can do multiple times: if at least one honest, we’re OK

Architecture • OK, back to storing votes • How, specifically, do we use this thing? • HHAOS scheme forms heart of Cryptographic Vote Storage Module (CVSM) • Stores ballots on removable flash memory • Stores signature in internal memory

Architecture

Operation • Initialization • Done at polling place or staging facility • CVSM stores initial signature • Outputs public key • Public key fingerprint communicated to tabulation facility • Voting • Each time ballot recorded on removable memory, signature updated • Old signature deleted • Canvassing / tabulation • At end of polling, Finalize run on signature • Signature copied to removable memory with ballots • Signature rerandomized at another machine • Taken to canvassing facility, rerandomized again • Signature checked against public key and votes counted

Evaluation: Integrity •  → no tampering possible without detection • /→ can insert, but not remove, ballots at point of compromise •  → arbitrary tampering without detection

Evaluation: Privacy and Efficiency [1] Tamper-evident, history-independent, subliminal-free data structures on PROM storage. D. Molnar, T. Kohno, N. Sastry, D. Wagner, 2006. [2] Draft in submission. T. Moran, M. Naor, G. Segev, 2007.

Summary • Pro’s • Replaced secure tracking of physical PROM with secure communication of public key • Public key fingerprint can be replicated and made public ahead of time • Efficient O(K) storage • Removed need for disposable memories • Maintained history-independence, robustness • Con’s • Untrusted rerandomize needed for subliminal-freedom • Slightly more difficult to understand • Slightly more code to be verified

Questions?

Cryptographic Methods for Storing Ballots on a Voting Machine