
Researchers find trapdoor in SwissVote election system - tpc3
https://about.unimelb.edu.au/newsroom/news/2019/march/researchers-find-trapdoor-in-swissvote-election-system
======
harry8
Even if it were possible to design a provably correct, impossible to tamper
with, anonymous electronic voting system (which seems unlikely to me) it still
should NOT be used. Why?

Everyone understands paper in ballot boxes, and how they can be cheated, what
to look for. Everyone can assess an argument as to whether this happened based
on the evidence presented.

Basically nobody would understand what to even look for in cheating the
electronic system. It would be totally my expert says your expert is wrong and
so it is/isn't fraud. Having even the possibility of that argument for
electoral fraud is completely insane.

It doesn't just have to be fair, it has to be seen to be fair. Really it does.
We need to have reason to have faith in our democratic processes most
especially when the people you want to win, don't and the result surprises
you.

The sooner we get to "Any electronic voting must be used to mark a standard
paper ballot which becomes the entire source of truth." The better. Everything
else in electronic voting is dangerous, sinister and flat out evil. Oppose it.
Loudly. At every opportunity. Especially if you're known as someone who
understands computers on some level.

~~~
pbz
How about this? 1) you go to vote with your voting card 2) you get a paper
printout of your vote 3) the voting machine then broadcasts your vote (only
IDs) to N independent checkers; this makes your vote public but anonymous 4)
later you check the printout against your favorite online checker to make sure
it registered properly

To make all this work the paper and electronic trail is digitally signed with
something that's only on your voting card.

~~~
Rexxar
Doing this permit someone to force you to disclose your vote and force you to
vote what they want. The strength of traditional vote is that nobody can know
your vote and this is the more important feature of the voting system.

~~~
doubleunplussed
I was arguing about this with someone when they pointed out that in Australian
Senate elections, it's trivially easy to make your vote unique. There are many
candidates and you can order them however you like, so you can vote a
particular way among the candidates that are actually competitive, and then
order the rest of the candidates in some improbable way to make your vote
unique. Then when the database gets published later someone can verify that
you voted how you said you would.

So the Australian Senate is currently vulnerable to vote buying, for what it's
worth.

------
Trisell
Here is a thread[1] from one of the researchers. She spells out what they have
found. I think the most damning quote is.

“Do not let people minimize this issue. This isn't "some random hacker can
steal an election" this is "SwissPost can prove they didn't steal an election,
even if they did"

[1][https://twitter.com/sarahjamielewis/status/11053782573171916...](https://twitter.com/sarahjamielewis/status/1105378257317191680?s=21)

------
duxup
I really like the Minnesota system. You fill out a paper ballot. You load the
paper ballot that gets scanned and recorded and the paper ballot gets rolled
into a locked box that is attached to the machine.

Recounts and etc should be relatively easy to manage and leave a very good
paper trail tied to various machines and etc.

~~~
Teever
Why is any of this necessary? Why don't paper ballots suffice?

~~~
paulmd
Hand-counting is slow and inaccurate. As in, you regularly see swings of 1% or
more from hand-counts, and they typically take weeks.

Electronic tabulation of paper ballots is the best of both worlds. You get
results today, they're pretty accurate, and there's a paper trail if you want
to go back and argue later.

~~~
mnbvkhgvmj
The UK counts all their votes by hand. Overnight.

~~~
andrewla
Out of curiosity, what does a UK ballot look like? I found [1], is that
typical?

Part of the problem might be one of ballot design. A US ballot is typically
considerably more complicated than that. Here's one from New York [2]. There
will be many races; in a presidential election there will be president,
usually senator, representative, governor, state senator, local councilman,
and assorted other offices. At least in New York State, the candidates will be
presented by party, so a single candidate may be on the ballot multiple times.

Nobody is counting the US one by hand overnight; not without some pretty
comprehensive redesigns of the ballot.

[1] [https://www.gravesham.gov.uk/home/elections-and-
voting/guide...](https://www.gravesham.gov.uk/home/elections-and-voting/guide-
to-voting/what-a-ballot-paper-looks-like)

[2]
[http://www.otsegocounty.com/depts/boe/images/WO.jpg](http://www.otsegocounty.com/depts/boe/images/WO.jpg)

~~~
makomk
That's one of the simpler UK ballots. Some of our council elections allow us
to elect more than one candidate, and our mayoral and police and crime
commissioner elections uses the rather oddball supplementary vote system.

------
nathan_long
Speaking as someone who is forced to vote on a proprietary touchscreen system
with no paper trail, I _wish_ researchers were finding cryptographic problems
in my voting system.

~~~
komali2
I love those systems. In Texas my parents tried to press Betos name, and at
the "review results" screen, Cruz was selected. This was a well documented,
statewide problem.

Malice? User error? Ux idiocy? Who knows!

~~~
specialist
The touchscreens in New Mexico 2004 simply didn't record the votes of Spanish
language ballots. Kerry won the state but Bush received the electoral votes.

Fortunately, the NM courts agreed and prohibited the further use of the
touchscreens.

What blows my mind is how invalidating (decertifying) the touchscreens has to
be done in each state. I still can't fathom why the feds (eac.gov) can't just
pull rank and ban them.

~~~
ceejayoz
> I still can't fathom why the feds (eac.gov) can't just pull rank and ban
> them.

Article One, Section Four of the Constitution gives this power solely to the
State and Federal legislatures. The Executive branch (and it'd probably the
FEC, not the EAC) can't pull rank here unless Congress gives them the power
to.

~~~
specialist
And yet HAVA.

Which is it? Pick one.

~~~
ceejayoz
"unless Congress gives them the power to"

HAVA is an act of Congress. It does not, to my knowledge, allow the FEC to
confiscate voting machines. Maybe it should've been clearer - "no shitty
touchscreens!" \- but it wasn't.

~~~
specialist
HAVA ushered in the touchscreens.

Your concern trolling isn't even wrong. Please. Continue.

------
zaroth
It uses a trapdoor commitment function. It does not have a “trapdoor” or
“backdoor”.

The problem is not so much in the implementation of the function, but in the
generation of parameters required by the function. The machines need to follow
a particular scheme to generate the parameters of the function in order for
the commitment to be secure. Think, e.g. of ZCash, where if the initial
ceremony is not completed in a specific way and trusted, then the entire
system after that has specific weaknesses.

In this case, if the parameter generation is not done correctly, or if
randomness generated by clients is compromised, votes can be altered.

Now one of the issues is generating random group elements. Reading one of the
linked notices [1] it talks about best practices of generating a random group
element.

I don’t understand exactly all the terminology in the paper (even though it is
quite trivial) but it looks to me like it is talking about generating
effectively a _public_ key in an EC system.

One way to do it is to generate a random integer _r_ between 0..q-1, which is
effectively the private key, and then generate the corresponding public key by
doing _g^r mod p_.

The problem with this approach is that in the process the machine generating
the public key _knows the private key_. It could be thus saved or leaked.

Instead you can generate a public key directly. This requires randomly
selecting a value and checking it is valid (r/p=1), which is more expensive,
or alternatively select a random r in _Z_ and return r^2 mod p.

Finally, the generation process itself must be proveably fair and random (e.g.
some sort of blockchain ceremony) to be trusted.

Fundamentally the Swiss system does not specify a ceremony for trusting the
parameters used by its Pedersen commitment scheme, and therefore even if the
implementation is perfect it still is not secure.

Still reading...

[1] -
[https://s68aa858fd10b80a7.jimcontent.com/download/version/15...](https://s68aa858fd10b80a7.jimcontent.com/download/version/1552395686/module/7833161661/name/PIT1.pdf)

~~~
rocqua
If all that's needed is a public key without known private key (i.e. some
element Ga with a unknown) then a simple ceremony is possible.

Anyone who wants gets to submit a value H_i = G a_i. With a proof that H lies
in the correct subgroup.

Then the final value can bu the sum of all H_i s. The final private key would
be the sum of all a_i s. If even one of those private keys is unkown, the
final value is also unknown.

~~~
nullc
You don't need any such "ceremony" for this sort of protocol, no trusted setup
is required at all: you can use a hash function to select random group
elements.

All thats required is that that the dlog between the respective group elements
is unknown, they don't need special properties other than that.

This makes it unlike the trusted setup of things like zcash (as mentioned in
the grandparent post) which cannot be simply initialized randomly.

~~~
rocqua
I don't know anything about how elliptic curve points are represented in
memory, so I thought using a hash-function is difficult. If that's not the
case, then there is no problem. Using hashes as 'nothing up your sleeve'
numbers.

~~~
nullc
There are fairly straight forward options for this sort of thing... the
simplest of which is you hash onto the field and check if the result is on the
curve by applying the curve equation (which it will be with probability 1/2).
If it is, you are done, if not increment the hash input and repeat until done.

There are fancier ways to hash onto curves that can give nearly uniform points
in constant time, but they're curve specific... and for parameter generation
you don't need constant time.

------
eps
Original announcement [1] with its links intact, including one for the actual
paper with technical details [2] -

[1]
[https://about.unimelb.edu.au/newsroom/news/2019/march/resear...](https://about.unimelb.edu.au/newsroom/news/2019/march/researchers-
find-trapdoor-in-swissvote-election-system)

[2]
[https://people.eng.unimelb.edu.au/vjteague/SwissVote](https://people.eng.unimelb.edu.au/vjteague/SwissVote)

~~~
dang
We changed to that first one from
[https://techxplore.com/news/2019-03-trapdoor-swissvote-
elect...](https://techxplore.com/news/2019-03-trapdoor-swissvote-
election.html). Thanks!

------
seanwilson
Hmm, the algorithm used was formal proven secure:

[https://people.eng.unimelb.edu.au/vjteague/UniversalVerifiab...](https://people.eng.unimelb.edu.au/vjteague/UniversalVerifiabilitySwissPost.pdf)

> How can there be a trapdoor when the system has been formally proven secure?
> Any formal proof of correctness for any system makes some assumptions that
> become axioms in the formal proof. Scytl’s formal proof of security [Scy18]
> simply models the mixnet as sound, based on an informal interpretation of
> Bayer and Groth’s security proof. It does not model the proper generation of
> commitment parameters. We do not see any reason to believe there is an error
> in Scytl’s proof, but when the axioms are mistaken the conclusions are not
> valid. This does not mean that formal proofs are not valuable—at an absolute
> minimum, they clarify assumptions and explain the reasons for trust—but it
> does mean that they are not a substitute for broad and open public scrutiny.
> It is quite possible that there are errors in the implementations of other
> cryptographic primitives, that their details may not be modelled in the
> formal proofs, and that they may affect either privacy or verifiability.

There wasn't a better path to translate the proof into an implementation? How
was the algorithm translated into code (Java I think)?

------
Niksko
On a personal note, I'm glad to see the outcome of this bug bounty was as I
expected from the beginning: bugs, and pretty serious ones.

E-voting is a bad idea, and government attempting to implement it is an even
worse idea.

~~~
danra
E-voting over blockchain to the rescue! :0

~~~
tracker1
The issue at hand, is people are _REALLY_ sensitive to having their voting
record(s) tracked. If you know someone's key, you can track all their votes on
the blockchain.

If the blockchain isn't public, then it isn't trustable.

You can't have non-tracked + blockchain + trust.

------
sschueller
For any Swiss citizens in this thread, please consider this temporary ban on
evoting: [https://evoting-moratorium.wecollect.ch/](https://evoting-
moratorium.wecollect.ch/)

~~~
penagwin
Hehe, I like that to voice your opinion on evoting there's an online petition.

~~~
xorfish
It's not a petition. It is a popular initiative that will add an amendment to
our constitution if 100'000 people sign it and it passes a public vote.

------
archi42
In my crypto lecture we did automatic protocol verification using proverif.
Since here the implementation is at fault, and not the protocol, the next
thing seems to be a (proven) compiler from the (proven) protocol specification
to an implementation?

~~~
gdy
Are your lectures available online?

~~~
archi42
Hey, I just checked. The course is still offered, but the lecture notes are
only available from within the university network.

------
remcob
Title makes it sound like a bug is discovered. The 'trapdoor' is in the
protocol by design. A lot of zero knowledge proof protocols have an initial
setup phase in which values are created that need to be forgotten for the
system to be secure. These values are sometimes know as 'toxic waste'.

ZCash has a good write up on how this went in their zero-knowledge proof based
system:
[https://z.cash/technology/paramgen](https://z.cash/technology/paramgen)

The main criticism by the researchers seems to be that the process around this
setup was insufficient to demonstrate security.

~~~
ewillbefull
> The 'trapdoor' is in the protocol by design.

Only due to ignorance. It is well known that the bases of a Pedersen
commitment can and should be sampled randomly; a trusted setup is only
subverting the security of the primitive.

------
eli
If you're interested in voting systems and the challenges of election
administration, the National Academies of Science published a paper last year
that is approachable, relatively comprehensive and free to read:
[https://www.nap.edu/read/25120/chapter/1](https://www.nap.edu/read/25120/chapter/1)

It is a much harder problem than a lot of technologist think. And "just add
blockchain" is almost certainly the wrong move.

------
DoofusOfDeath
Is a trapdoor the same as a backdoor?

~~~
Y_Y
A trapdoor is something that's hard to invert:
[https://en.m.wikipedia.org/wiki/Trapdoor_function](https://en.m.wikipedia.org/wiki/Trapdoor_function)

A backdoor is a hidden access, like this.

Just a mistake in the article.

~~~
makomk
I don't think it's a mistake. I think this is actually a trapdoor in the
cryptographic sense of the term, and the security hole is the result of them
using a zero-knowledge proof scheme based on these kind of trapdoor functions
that relies on no-one having a copy of the trapdoor information, but
incorrectly letting the untrusted party choose the trapdoor function.

------
nullc
TLDR: E-voting system uses pedersen commitments, but doesn't provide any
evidence that the generators used are nothing-up-my-sleeve values.

To understand what a pedersen commitment is think "cryptographic hash" but
constructed so that you can 'add' hashes to get the hash of the added values.
Pedersen commitments require as system parameters multiple base points where,
for soundness, no one knows the discrete log any of them with respect to each
other. The normal way to accomplish this is to generate them all in a "nothing
up my sleeve" way by hashing some data.

In my work on confidential transactions (
[https://people.xiph.org/~greg/confidential_values.txt](https://people.xiph.org/~greg/confidential_values.txt)
) the base points I used were the standard secp256k1 generator, and a second
point constructed by hashing the standard generator with sha256.

If implementations of the SwissVote system were initialized in the say way
they could simply add the information about the hashed data to their audit
logs, even after the fact. If, instead, they picked the base points "randomly"
then they could not prove that past usage wasn't compromised.

I have often been frustrated by the lack of clarity in academic cryptographic
papers about the exact trust implications about initialization -- e.g. it
often takes a careful reading to tell if a paper requires a trusted setup, if
the values can just be chosen in a provably random way (and if so, will a
simple method suffice or is there a strong requirement on uniformity) ... but
pedersen commitments (even the vector versions) are really bread and butter
simple stuff. I would be worried that anyone who didn't know that choice of
the base points resulted in a trapdoor would be unlikely to spot actually
subtle implementation or algorithmic mistakes.

------
inved001
Here are some more details about this:

[https://e-voting.bfh.ch/publications/2019/](https://e-voting.bfh.ch/publications/2019/)

------
ignoranceprior
Relevant xkcd: [https://xkcd.com/2030/](https://xkcd.com/2030/)

~~~
kgwgk
Bad timing for the "aircraft safety" example...

