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 appendonly 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
Private
Key
Public
Key
What if Key Compromised?
 Maybe use some sort of forward secure
techniques
Public
Key
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
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

  → no tampering possible without detection
 / → can insert, but not remove, ballots at point of compromise
 → arbitrary tampering without detection



Evaluation: Privacy and Efficiency
Historyindependent?
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)
[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?