Dark DAOs and the Complexity of Secret Voting

This is Part Six of the Enigma Solutions Series, examining real-world decentralized solutions that can be built with Enigma’s groundbreaking protocol

Over the past few months, Enigma has published a number of blog posts called the Solutions Series, focusing on the various real-world applications that can be built using their groundbreaking privacy protocol. One particular post focused on secret voting, and how the Enigma protocol allowed for truly private elections simply, without the complexities and security holes induced by commit-reveal voting schemes.

A few weeks ago, a blog post detailing a potential flaw in such secret voting schemes — and, for that matter, in any decentralized voting scheme — was described online. Today, rather than focusing on another of Enigma’s potential solutions, we shall be analyzing this specific flaw and how one might be able to protect against it. Welcome to the world of the Dark DAO.

What is the attack?

Before describing the attack itself, we should note the environment in which the attack takes place, as well as its goals

Attack environment:
The attack assumes the existence of four factors:

1. Code that can run on encrypted data in a malicious environment without revealing that data to its host. This is possible (to varying extents) through both MPC or TEE technologies.

2. The ability to commit to running a specific piece of code, and to attest that a certain piece of code is all that is running on a given machine. This requires TEE technology.

3. The ability to send in a vote given only a specific piece of information e.g. a voting key/private key, without any nonymizing information attached to the vote. This is standard in decentralized voting schemas.

4. One voting outcome is worth significantly less to any one voter than their stake is — i.e. the total effect of any given vote is less than the total value of the tokens. This is not policy anywhere, but should be expected — how many tokens are deciding their entire fates with every governance question?

Attack goals:

This attack aims to provide a way for some arbitrary bribing organization to control the votes of external parties for a single poll, no more and no less. Note that qualifier — it’s not enough for the briber to just buy the voting keys off of his intended targets, since in that case he can do anything he likes with their tokens (assuming the voting keys and private keys for tokens are linked, which is standard in most schemes) — and thus bribing is only as useful as token purchasing. For the attack to be dangerous, it must be significantly less risky (in terms of the future value of the voting tokens) for someone to sell a single vote to the briber than it would be to give up their tokens — then the incentives misalign themselves in the briber’s favor.

The attack itself:

Now that we’ve described the environment and goals, the attack itself follows relatively simply.

The briber sets up code to run on an SGX machine that does the following: When sent an encrypted private key for a given voter, it decrypts the key within the enclave, then uses that key to vote. If no other votes with that same private key are sent in until the election concludes, then the SGX machine sends some pre-known bribe to the voter in return (this delay is necessary because the user still holds their key, and could thus override the SGX vote). Now, before SGX/TEE technology, such an attack wasn’t really feasible — after all, if the briber knew the voting key, they could just use that key to move the tokens as they saw fit. However, with the new capabilities enabled by private computation, the briber can provably use the keys they collect for votes, and only votes.

In fact, SGX enables more than just single briberies — since the briber can do such a thing programmatically, they can use a slightly different bribery program. Rather than soliciting a specific user, it merely waits and collects any voting keys sent to it. If there aren’t enough keys sitting in its internals to win the vote, it does nothing. However, if it would win — then it springs into action, launching its votes and repaying its bribees. This system allows for fully autonomous election control, without any risk to the bribees and without the briber needing to target anyone explicitly — all they have to do is set up the contracts and watch them run. This is the power of Dark DAOs.

What is the defense?

Now that we’ve described the attack, we can proceed to analyze potential defenses against it. Note that the requirements for the attack to function were: code operating on encrypted data privately, the ability to attest to a specific piece of code’s being all that was run, no nonymizing information attached to a vote, and each vote being worth less than the voter’s overall stake. We shall cover these conditions, and the imperfect defenses they lead to, in reverse order.

1. The worth of votes: Obviously, if someone’s vote could potentially devalue their entire stake, no briber will be able to purchase votes from people for less than the price of their stake (assuming the risk of devaluement is high). However, exploiting this to secure votes against a dark DAO requires ensuring that any vote could make or break a currency — a risky, undesirable proposition.
2. Nonymizing information: if votes are tied to personal identity, bribers will not be able to automatically purchase them — however, this ruins the decentralized, anonymous nature of the voting schema.
3. Attestation that the code run reveals nothing about the data: At first glance, it might seem impossible to break this certainty given the security of SGX. However, there is a way to falsify this assumption — at the cost of decentralization in our hardware. Namely, consider the case where we require all voters to use SGX machines to store their keys. Additionally, require the SGX machines from which the vote is placed to verifiably pass their voting keys to their hosts. If the voter is using their own machine, this isn’t an issue — they already have the key. However, this prevents bribers from being able to verify that their use of voter keys is only for voting — since the vote itself will expose the voting key to the briber’s host. This solution solves the dark DAO problem — but requires all voters to have SGX hardware to vote.
4. The ability to run code on encrypted data without revealing it: we can break this assumption under similar constraints to 3, by requiring the code run on the data as part of voting to reveal it. This, again, requires all keys to be generated under SGX hardware.
   It’s clear that voting has become a promising and valuable primitive for the decentralized ecosystem, whether it comes into play for governance decisions at a protocol level, or granular TCR-style decision making. It’s also clear that voting can be a high-value target for attack. Trusted hardware like Intel SGX enable new vectors for vote manipulation. This is an emerging space, and we expect to see more new and creative applications of these tools.

Based on this analysis, we can ask a few questions of the community:

Is generating keys under SGX hardware a feasible response?
How can this be made more accessible — perhaps through a plurality of TEE solutions or creating compatibility with TEEs in mobile devices?
Are there potential transaction-level proofs to these attacks?
As Phil Daian notes in the piece that inspired this response, “coordination space of mechanisms in blockchains is large, and the environment hostile.” However, the importance of data privacy and private voting is very clear to us, and we’re excited to continue pushing research and tooling in this area.

Come discuss these open questions on the Enigma Developer Forum!

This Solutions article is a contribution from a member of the Enigma team. Thanks to Luke from Aragon, whose insight was very helpful in writing this piece.

Do you want to help Enigma find solutions for the challenges facing our decentralized future? You should join us.

Learn more about our project on our website and blog.

Join our developer community: [https://forum.enigma.co]

Want to build on our protocol? Check out our documentation to get started — or, if you’re a project or enterprise, submit your interest here.

Join the Enigma Team: [https://enigma.co/team]

Telegram: [https://t.me/EnigmaProject]

Reddit: [https://reddit.com/r/EnigmaProject]

Twitter: [https://twitter.com/enigmampc]

Discord: [https://discordapp.com/invite/SJK32GY]