Pusher as a single point of failure for observer communication

[dglittle]

Pusher appears to be used for all communication between “observers”

Assuming observers are intended to be remote from one another, there’s no way for them to verify that messages actually come from each other.

Pusher can therefore control all observers by lying to all of them individually via an active MITM attack, and therefore stop an election, decrypt the contents of a ballot, and de-anonymize voters.

[...]

The goal is not to cast aspersions on the vendor, but to point out that the system is fundamentally trusting them in a way that might not be safe in the case of nation-state level adversaries.

Originally posted by @mspecter in #195

[arianabuilds]

Entry Summary for HACK SIV @ DEF CON 2024

Thanks again for participating! This submission earned $22.68 from SIV and $24.57 from the Public Vote, for a total of $47.25.

Here's what we noted in our evaluation:

What's interesting about this submission

• Useful to point out single-points-of-failure

What takes away from it

• But the issue report isn't quite right: Pusher is only being used in MPC to poke each other to continue, not data transfer. Server is passing data around, websocket messages just trigger a new GET from server for the latest.
• Even if pusher utterly fails, can just manually refresh the page to progress the MPC.
• The described MITM attack is not possible from Pusher, but is in fact somewhat possible via a malicious SIV Server [even if Privacy Protector's are running clean local client code, re other submission about that]. BUT this is completely detectable by the MPC participants broadcasting their generated pubkey on another channel, like their own site or social media profile, which we encourage (only verbally currently, but would be good to have the UI also mention it, as commonly accepted good practice).

Issue to track getting paid: siv-org/hack.siv.org#11