DETAILS - HOW THIS SYSTEM WORKS
​

Procedural Changes
The Accountable Democracy System permits voting well in advance of election day (determined by the state) through several means including phone apps, government facilities, and personal computers. When such voting occurs, the voter can optionally print a copy of their ballot. The voter then has 72 hours to change their mind and cancel their vote, in which case  they can vote again before election day.  After 72 hours their vote is frozen.

The voter is notified that they voted. Notification is by any combination of of 4 ways; 1) phone call, 2) text, 3) email, and/or 4) postal mail. Such notification does not include any ballot information.

Throughout the course of the election, any time after the notice of voting, before, during or after election day the voter can go online to view their ballot and 
optionally print another receipt.  Printed receipts do ​

not identify the time and date in which the voting occurred (important), but they do identify the application used to vote.

All vote tabulation is done by two cloud-based servers (on separate cloud facilities) in conjunction with state voter registration data bases. The software for performing this tabulation is publicly available and COMPLETELY UNHACKABLE without detection.  Furthermore, unique methods are used to insure that only the unmodified publicly available software is in use. Voting applications continuously display hash totals of the software in use.

Additionally, software is provided that major accounting firms can use to verify that elections are being conducted securely, accurately, and using only the publicly viewable programs.
​

Technical Details
Ballot records are assigned a sequential number as a part of their structure which may be used to subsequently access them. Ballot records are frozen after 72 hours from their time of creation. As frozen ballots accumulate, they are batched. Ballot number lists (batches) are stored in a batch file (table). Batch size may be established during system setup. Ballot data is not encrypted. However, EACH BALLOT AND EACH BATCH IS ISSUED A 256 BYTE SHA HASH VALUE. The batch hash value pertains to all of the ballot data in the batch.
 
Batch Record Content:

• ballot number
• ballot number
• ballot number
• …
• hash total of ballot data
• batch number

 
The ballot data itself is kept unencrypted. Votes for competing candidates are expressed via an alphabetic  candidate identification system. For example if four people are running for a particular office they will 

be identified internally as A, B, C and D.  There will be one candidate identifier per open office. If more 
than one open office of the same type is being selected, or if a priority ​voting scheme is used, the ballot will contain one candidate identifier position per selection or priority position. 
​​
BATCHES ARE GROUPED (listed) in batch group records which are stored in a batch group file, and each batch group is issued a sequential number and a hash value that pertains to all the batch record hashes (not ballot data) in the group. There are two types of group records, 1) records that pertain to batches, and 2) records that pertain to groups. Batch group records are assigned level numbers so that groups can be grouped hierarchically. The first level is level 1 which lists batch records. Level 2 and above list records in the level just below them.

In summary, we have a State managed voter registration file (with an accompanying voter number translation file – see Voter Identity Protection below), an unfrozen ballot file, a frozen ballot file, a batch file, a batch group file, and a deleted ballot file.

 Security
 All Accountable Democracy software runs concurrently on two dedicated servers (typically provided by competing cloud services) and the engine includes its own operating system. (Initially this is a scaled down Linux or BSD type of OS.) During bootup it sets all unused memory to zero and upon completion of bootup it establishes a hash value of the OS and another hash value of its own executables.
 
Periodically it recalculates and compares these executable hash values to those established at bootup to assure that nothing has changed. It also periodically revalidates (checks) all ballot and batch file (table) hash values. The memory allocation routines used by the software zero out memory when relinquishing it.

The software also, on demand, recalculates the hash value of all executables that process ballot, batch and group records and provides them to client and government applications through the APIs. All source code in such executables is publicly available for inspection and independent compilation for hash verification purposes. Also, the source and object programs for calculating the hash values are provided to the public.
 
It is expected that during elections the low order 8 characters of these critical hash totals will be published in the media and/or made available on the State web site, and these values will be dynamically obtained from the engine and displayed on client user interfaces during elections.
 
The second server runs in slave mode and essentially duplicates all ballot accounting processes performed by the main server other than officially recording unfrozen and deleted ballots. The main server forwards a copy of all ballots to the second server at the time they are frozen. The second server can also accept input from client applications for verification purposes. When this happens, it will temporarily save that data until the corresponding frozen ballots are received 
from the main server. Periodically, the uppermost ​
group hash values produced by the two servers are ​

 compared to assure both are functioning alike. An optional third server can be attached to the configuration as a backup, for greater security and to identify the correct ballot information in the event of a discrepancy between the main and second servers.
 
In the event the main server is compromised or disabled, a change of roles can take place by 1) placing the main server in a bi-directional forward-only mode or rerouting the network traffic to and from the second server, and 2) switching the second server to stand alone main server backup mode. 
​
 External Inspection
Several of the ancillary functions of the main server are not provided in backup mode, but it does include all ballot accumulation and group record processing, voter notification, and voter inquiry support.

Upon request from the election authority, a complete audit of the ballot files will be performed by having the election authority send a list of all (encrypted) secret 
numbers of voters who have voted to the A D System. The A D System then will find and track all ballots associated with the list. Any missing or excess ballots will then be reported. 

At random intervals an inspector program is uploaded from an Accountable Democracy server which uses a dynamic algorithm to modify its own hash after startup. It doesn't know what its own hash will be, but the Accountable Democracy internal server does. The inspector audits the environment and reports its own post startup hash along with its findings.

​A note for hackers.. It is possible for a simulator to emulate such a process but not to predict the precise functioning of the inspector (and therefore know how to defeat it) which will be changed from time to time. Also the inspection door is open at all times. The timing of inspections is determined by the external server. Additionally, during an election we will be periodically offloading a copy of the ballot file for external backup purposes. ​

---

---

Voter Identity Protection
On the state server there is a file that stores public voter numbers, asymmetrically encrypted secret voter numbers, and voter's separately asymmetrically encrypted passwords. The key for decrypting the secret numbers stored on the state server and the key for re-encrypting the secret numbers for storage in ballots are stored on a separate Accountable Democracy server and are only accessible to the Accountable Democracy engine. The key for decrypting the voter's password is discarded. The voter can choose whether or not they can change their password without knowledge of their current password.  This setting will effectively block unauthorized interrogation by a state. 

A second asymmetric decryption key, which can decrypt the secret voter numbers stored in ballots, is not stored on any Accountable Democracy Engine servers. 

It is stored only on an external Accountable Democracy server. This key is not needed for the normal functioning of the system or for performing audits. So even if a person obtained the secret voter number file (located in state facilities), and its decryption key, the person could not use it to identify a voter associated with a particular ballot. 

Obtaining access to a path from a ballot to a voter would be formidable because the secret numbers are separately encrypted, one in the ballot and one in the (state) translation file. And in the event a person were to do so, it would still not enable the undetected alteration of a frozen ballot. ​​​