POSSIBLE THREATS - copied from cothority e-voting

[ineiti]

Some issues I found while working on the cothority e-voting, and which need to be made sure that are not present in d-voting:

• Blocks created by shuffle and decrypt are signed with a useless signature cothority#2510
• Leader requests for shuffle and decrypt are not trustworthy cothority#2509
• evoting: hashMap creates wrong hash cothority#2508
• User authentication is flawed cothority#2507

[nkcr]

Blocks created by shuffle and decrypt are signed with a useless signature #2510

The election information, which is stored on-chain and therefore signed by a quorum of nodes, contains the roster. We therefore have a signature that is uniq per-election and contains the roster. A re-use on the same chain is excluded thanks to the properties of the blockchain, which makes every signature unique by including the block's hash.

Leader requests for shuffle and decrypt are not trustworthy #2509

The authentication process is simpler than in Cothority. It is not performed on-chain. Nodes delegate the authentication/authorization process to a third party via a shared secret key. Nodes only check the validity of the message based on the shared secret. Note that this is a big shortcut, as it brings a single point of failure, but that's a tradeoff we were willing to accept. Decentralized authentication is a topic on its own.

evoting: hashMap creates wrong hash #2508

The handling of transactions and blocks (where signatures are needed) is not done by d-voting itself, but the underlying blockchain: Dela. So if there is any concern on this point it would happen in Dela, not d-voting.
But in any case, knowing the pitfall with maps, none of d-voting nor Dela uses this data structure (we learnt it the hard way...). Instead we maintain parallel lists if needed, as in Sufragia for instance, wich keeps encrypted ballots linked to user IDs with two parallel lists.

User authentication is flawed #2507

Again, the authentication process is simpler here. Users authenticate via Tequilla, and the session is kept by the Webbackend, which is trusted by the blockchain nodes via a shared secret and forward requests from users. However, we require that the connection between the Webbackend and the blockchain nodes is encrypted with TLS, otherwise we are not safe against replay-attack.

In summary, while there may still have undiscovered vulnerabilities in d-voting, we are not concerned by the aforementioned issues. For more details about the security you can refer to our last security audit report.

[ineiti]

Thanks a lot for your comments. I'm currently out of the office until mid-August, but if you have some time afterwards, I would very much like you to walk me through how the authentication of the user works, and how the transactions are stored in Dela. I tried to follow the code, but didn't take enough time yet. So help there would be appreciated!

[ineiti]

Reading through these once again, I'm happy to see that #2508 to #2510 are not a problem.

I'll discuss with Pierluca #2507 - I'm still not sure I understand your attack model and whom you trust for what part.

[nkcr]

I would be happy to chat about that, I'm always looking for opportunities to pass by Sat' 😄

[ineiti]

That's an offer! However, Sat is closed until 30th of August :( Anything free in the week of 4th of September?

[PascalinDe]

@ineiti can this ticket be closed?