Insufficient Signature Validation of the Election Public Key resulting in possible attacks against individual verifiability
We uncovered the following issue in the e-voting solution's source code after the Federal Chancellery's experts raised questions on how the control components ascertain the correctness and authenticity of the election public key. We want to thank the following experts for this observation:
- Thomas Edmund Haines (Australian National University)
- Vanessa Teague (Thinking Cybersecurity)
- Olivier Pereira (Université catholique Louvain)
Summary: The current implementation allows an adversary controlling the voting client, voting server, and one control component to perform an attack against individual verifiability. The adversary could make the control components accept an invalid election public key, yielding invalid votes after decryption. The honest control component checks that the trustworthy setup component signed the election public key. Unfortunately, the signature verification is insufficient and can be forged by a malicious control component.
Background: The system specification version 0.9.6 insufficiently described how the control components obtain the election public key. Therefore, we modified the sequence diagrams in the system specification version 0.9.7 to explain how the control components learn the election public key (they receive the election public key together with its signature).
During the configuration phase, the control components do not receive the election public key EL_{pk}
from the setup component. The setup component only sends the election public key to the voting server.
However, it signs the election public key using the administration board secret key AB_{sk}
.
During the voting phase, the Return Codes control components CCR require the election public key EL_{pk}
for verifying the zero-knowledge proofs.
The CCR must use the correct election public key, else individual verifiability can be broken, i.e., the attacker can show the valid Choice Return Codes, but the vote is invalid.
The CCR implementation performs two checks:
- The CCR checks that the administration board secret key signed the election public key.
- The CCR checks that the administration board public key was issued by a platform root CA.
Unfortunately, these checks are insufficient and allow the following attack scenario: Every CCR has signing keys that the platform root CA issued.
The key management works like this:
A malicious control component (working with a malicious voting server) could sign the fake election public key with the CCN signing keys and claim that the CCN CA is the corresponding Tenant CA.
The source code only checks that the "Admin Board"' root certificate is the trusted platform root CA. However, any control component could impersonate the admin board.
Resolution
We are currently discussing possible solutions with the experts and propose to prevent the attack in the following way:
- Add a check of the certificate subject (making sure that it is an admin board certificate and not a CCN certificate)
- Add a check that the Tenant CA issued the admin board certificate.
- Use the same admin board certificate in the voting phase as the one used in the configuration phase (certificate pinning).
These fixes allow the honest control component to check the authenticity of the election public key (and that it is linked to the correct election event).