Cryptographic Methods for Storing Ballots on a Voting Machine

John BethencourtCarnegie Mellon University

Brent WatersSRI International

Dan BonehStanford University

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

Idea:Let’s Try to Address That too!

We’ll sign to prevent replacement

PublicKey

PrivateKey

What if Key Compromised?

Maybe use some sort of forward secure techniques

PublicKey

Append-Only Signatures

Need special signaturesValidates a set of messagesNo private keySignature for one set can be used to sign

new set after adding somethingMust be hard to sign subset of X with

signature on X

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}

Append-Only Signatures

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

Pairing based scheme similar to aggregate signature scheme of Boneh et al. 2003

HHAOS: Efficient Scheme

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 votesHow, 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

Removable memory

(electronic ballots)

Internal memory (signature)

Public key

Crypto VSM

PROM

VSM

A secure ---- ---- B swapped / written secure secure C swapped / written compromised secure / D swapped / written ---- replaced

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.

History-independent?

Subliminal-free? Space for K ballots from universe of N

PROM with random placement table [1]

YES NO O(K)

PROM with copyover lists [1]

YES YES O(K2)

PROM with new construction [2]

YES YES O(K polylog(N))

Our scheme YES YES after rerandomization

O(K)

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?