I recently reviewed the French requirements for (electronic) voting machines. Amongst the 114 requirements, two of them seem a bit difficult to satisfy simultaneously:

Requirement 65: If a voting machine should be stoped during a vote, no indication of the choice made by the voter should be visible.


Requirement 69: If a voting machine should be stoped during a vote, it should be possible to recover vote information by vote pool members without any modification, while still following requirement 65.

Thus those two requirements simultaneously request that votes should be recovered in case of crashes but at the same time it should not be possible to read them!

In the following I propose a design to fulfil those two requirements. The main idea of this design is to have two separate kind of machines:

  1. the voting machines themselves, used in the voting booth,
  2. and a centralised controller, used to initialise voting machines, read final votes and when needed re-initialise a voting machine.

Moreover, within voting machines, the recorded votes are stored in a writeable and removable media (like a Flash memory) but they are encrypted. The encryption material should be kept in volatile memory, i.e. in RAM, so that in case of power failure it is lost, making impossible to read the recorded votes on the writeable media. When the voting machine (or a new voting machine) is restarted after a failure, the encryption material is reloaded from the centralised controller, allowing to store new votes next to the previous ones. At the end of the voting period, the votes are read and tallied by the central controller, which has access to the encryption material.

More specifically, here is how a typical vote would be done:

  1. The centralised controller is started and it generates the encryption/decryption material for each voting machine;
  2. Each voting machine is connected to the centralised controller and receives the encryption/decryption material, that is stored in RAM;
  3. The voting machines are then put in their voting booth and set into voting mode (i.e. they accept and store votes);
  4. After also being put in voting mode, the centralised controller can no longer generate new encryption/decryption material;
  5. When each vote on a voting machine is made, it is encrypted and stored on the flash memory of the machine;
  6. If a voting machine crashes, it is connected to the centralised controller and the encryption/decryption material is reloaded, so the voting machine can continue to store votes after the previous one;
  7. At the end of the voting period, all the Flash memories of voting machines are removed and put into the centralised controller. The centralised controller decrypts the votes (it has the encryption/decryption material) and tallies the votes.

As encryption procedure, one could use a One Time Pad but, as there are in practice difficult to generate correctly, we could use instead a stream cipher to generate a "random" stream that would be XORed with the information to store, like AES in counter mode. In the latter case, only the encryption/decryption key would be transferred from the centralised controller to the voting machine and stored in RAM.

The requirement 69 also mandates that vote information should be recovered without any modification. This could be easily done by adding a cryptographic signature on the whole set of recorded votes on the removable media, using as signing key the same material as encryption/decryption material.

The main advantage of this design is its simplicity. If a One Time Pad is used in a voting machines, there is no need to use complex cryptographic code in the voting machines. A simple XOR operation can be used. And even if an AES block is used, it is relatively simple to use. The complex generation of random numbers needed for the generation of encryption/decryption material is only done in the centralised controller.

Another advantage is that votes stored on the removable media can be re-read in case a re-counting is needed, provided that the encryption/decryption material of the centralised controller is securely stored somewhere at the end of the voting period.

One weak point of this approach is during the transfer of the encryption/decryption material from the centralised controller to the voting machines, where the encryption/decryption material could be intercepted by an attacker. A solution would be to authorise this transfer only after proper authentication of a voting authority, limiting the ability to intercept it.

What do you think of this design? Do you see any major weak point or security defect?