Electronic voting has been one of the most controversial topics due to the hardness of ensuring the correctness of the process when this is performed using possibly flawed hardware devices such as kiosks, laptops or mobile phones. Over the last decade we have witnessed a significant evolution of techniques enabling secure electronic voting in a trusted manner. The different solutions proposed to secure a remote electronic election might, indeed, be considered for other critical applications such as online banking transactions.
The approach that is receiving more attention lately is the one where the devices used by the voter are assumed to be corrupt. This way, the correctness of the election results, that usually depends on the servers from the electoral institution and voters’ devices, relies entirely on the hardness to solve a hard mathematical problem such as the Discrete Logarithm Problem (DLP) or the factorization problem.
Usually, the best way to achieve this level of security is by forcing the different entities involved in the electoral process to compute a Zero Knowledge Proof (ZKP) for each step of the voting protocol. A ZKP is a method by which a prover proves knowledge of a value x to a verifier, without providing any additional information apart from the fact that it knows x. These proofs are used to guarantee that all the information used in the protocol keeps the properties that makes the voting protocol secure. For instance, during the shuffle and re-encryption of the votes (i.e.l, the so-called mixing), the parties involved end up generating a ZKP of correctness of this process.
The main problem when dealing with a corrupted voting device is mostly related with the information the device is handling, which in this case is the voting option. More precisely, the problem of ensuring that a secret information is correct: privacy vs integrity. Given that the voting option would be chosen by the corrupted device, it would be easy for the attacker to compute also a valid ZKP because the proof only guarantees that it knows the encrypted value, but does not provide evidences on which option it is. Therefore, the problem cannot be addressed by using ZKPs only.
The solution provided by the voting community is the use of a second device with a list of codes associated with each voting option. Once the corrupted device sends the vote to the voting server, the device receives a code and shows it to the voter. The voter uses the list of codes to validate that the voting option sent by the corrupted device is correct and sends a secret code to confirm everything has been done properly. It is worth noticing that this protocol opens new challenges such as dealing with the list of codes generation and keeping the voter’s privacy, or securing the list of codes in the second device so an attacker cannot corrupt both.
In this presentation, we would like to shed some light on the fact of using the same idea in other use cases like a second factor correctness for critical transactions.
Our main idea is to design an air-gaped device (without any type of network connection) that should have three main capabilities:
• Given an initial key, it should be able to derive short-lived keys.
• Given a code, a short-lived key, and a timestamp, it should recover information of an action and its parameters.
• Given a code, a short-lived key, and a timestamp, it should generate a random looking code in a deterministic way.
