siv-org / siv

Secure Internet Voting protocol
https://siv.org
Other
12 stars 6 forks source link

Vote for this vulnerability, and I will send you 1$. #181

Open mspecter opened 1 month ago

mspecter commented 1 month ago

What’s the exploit?

Just as the title says, if you vote for this issue, I will send you 1$. That’s it, that’s the exploit.

When will I get the money?

After the election closes (at the time of writing, in 3 days), and this bug wins. I would rush though, it’s first-come-first-serve, up to the 5k offered by the competition.

How do I claim my 1$?

Drop me an email, text, or whatever with your authkey, encrypted ballot, verification number, and anything else that’s required to perform verification. I’ll verify that it’s on the public log, and, if this wins, I’ll send you your money in whatever way is good for you (cryptocurrency, venmo, whatever).

Easiest contact is internet_voting@groups.gatech.edu, but other contact methods are available via my profile if that’s better.

How do I know that you’ll send me the money?

You’ll be able to publicly call me a liar after the event. My identity is verified on keybase. And you'll be able to prove how you voted.

I’m a professor at Georgia Tech, where I study elections, systems security, and applied cryptography for a living. Some of my prior work on the subject is here and here.

SIV’s documentation argues for 30$, why is the reward only 1$?

What will you do with the rest of the cash?

After I recoup expenses, assuming I actually get the cash, I’ll donate the rest to the EFF, and publicly post receipts. If you don’t want your dollar, you can send me proof and I’ll donate that dollar to the EFF in your name.

But, doesn’t this violate the rules of the game?

Well, yes, and no. The organizers appear to not believe that this is a real attack. The point is to prove that it’s within the bounds of an election, and a very, very real threat.

Why won’t you report me to SIV? Won't I have to pay them money?

Because I don’t buy their threat model, and have no interest in giving them more money. I want to win!

Also, you don’t have to sign their contract — and even if you did, I wish them luck in trying to enforce it.

Why are you doing this?

The goal is to demonstrate that vote selling is a real problem, not one that can be shirked off as outside of the threat model.

It's commonly accepted that vote selling is a real world issue that electronic voting systems should be designed to overcome. Indeed, there are cryptographic voting systems that do provide some protections against this sort of attack (see, e.g., Helios). They’re still buggy, and this is an active research area (a really great place to start is Bernhard et al's SOK).

It is therefore unclear why this is out of scope for this system, or that the informally proposed approach actually works. I would encourage SIV to formalize their model, attempt to publish this in a peer-reviewed conference, and get more feedback there.

OK, but, in the real world, wouldn’t this just be illegal? What about the whole "honeypot" argument?

I doubt that Russia or other nation-states care much about US law, and they can easily verify themselves as being real, as I have above.

Further, we're both incentivized to keep this secret -- the attacker's goal is to rig the election, and the seller's goal is to get their vote sold. If I invalidated your vote, I'd only be hurting my own goals!

More advanced techniques would likely provide some anonymity to the seller; e.g. deliver rewards via a shielded transaction, and use some sort of SNARK/ZKP to verify the ballot and its contents without revealing much about the seller.

But, then why is mail in balloting not affected?

Remoteness, verifiability, and scalability are differentiating factors here.

Remoteness: In SIV's protocol, an attacker can easily verify that the ballot was valid, while being in a completely different location than the election. Case-in-point, I'm writing this from my office in Atlanta, whereas the in-person event is currently happening in Vegas.

Verifiability: I can cryptographically verify how you voted, if you provide me adequate information.

Scalability: I can do this verification operation really quickly, and without much effort.

Conversely, mail-in balloting attacks that are described by SIV are not scalable, not as verifiable, and not easily performed remotely. I would have to get the ballot, which might require physical access to the voter (to retrieve a blank ballot). I wouldn’t be able to verify that the voter didn’t later vote in-person at a polling station (which would supersede and “spoil” the mail-in ballot), or that they didn’t scribble a signature that wouldn’t be verifiable to the elections officials. And, finally, it would require me interacting with a ton of people to impact the election, putting myself at risk in the process.

What if SIV closes this issue?

Well, that would indicate that the attack is very, very real, wouldn’t it? In any case, the deal is still on, even if SIV decides to close this issue.

Edited slightly for clarity

dsernst commented 1 month ago

Thanks for the detailed write up. Zero interest from our end in closing or attempting to censor or anything. On the contrary, love to see the thoughtfulness and engagement. (you may or may not recall we have a few emails from years back hoping to pursue more rigorous analysis on this issue <3)

Just posting this as an initial quick reply but will still come back to dig deeper into everything you wrote. Thanks!

mspecter commented 1 month ago

I'm glad to see that it won't be closed!

One other nit: https://docs.siv.org/compare conflates coercion resistance and vote selling. These are actually two different things, and have different definitions in the literature (see the Bernhard SOK linked in my original comment).

Coercion resistance = I cannot collaborate with an attacker to prove the way I voted. E.g., an attacker sits with me while I'm voting to verify that I selected their options. Receipt freeness (Vote selling resistance) = I cannot prove the way I voted after the fact.

A system might actually be receipt free, and not coercion resistant. Consider a system that, when a user submits a vote, does not allow the user to re-vote or spoil the ballot, but also provides no receipt or method of verification. That system will be receipt free -- the voter has no way to prove after the fact that they cast a ballot in any particular way -- but not coercion resistant because an attacker watching them vote can confirm how they're voting.

arianabuilds commented 2 weeks ago

Thanks again for participating!

HACK SIV Competition Submission

DEF CON 2024, August 6-11 hack.siv.org

SIV Evaluation

Type: Protocol

In Favor:

Against:

Prize Allocation

Total: $857.67

Payment Status

Track process on https://github.com/siv-org/hack.siv.org/issues/11