Secure E-voting
The US government's income is several trillion dollars; it's expenditure is several trillion dollars more. Some computer somewhere knows knows exactly how much the income is, and exactly how the expenditure is, and knows for certain which one is larger: whether the government is in surplus or deficit. Actually that's not strictly true, because accountants have a variety definitions of the financial terms and politicians have lots of tricks to make things appear they way they want without actually being the way the want, and as result as the numbers can be vague. However absolutely none of the uncertainty in the numbers results from a technical inability to store the numbers in a computer and keep them adequately secure.
So why can't we do it with votes? The answer is, of course, we can. There is technically no reason why we should not be able to vote using a PC and the Internet, with as much security and confidence as we do for our financial lives.
Here's a technical outline of one way it could be done.
Firstly you will need some software to run on your PC. This is going to act as an “agent” for you, just like your browser or e-mail software acts as your agent. You acquire this software from someone you trust because your 'agent' can screw you. For example, you buy Quicken to mange your money and make bill payments and so forth. You must realize that if Quicken can send money from your bank account to your Utility company to pay your electricity bill, then the software can also send money from your bank account to the programmer who wrote the software. But you trust that Quicken wont do that.
So you start e-voting by acquiring software from someone you trust. From Microsoft, from Intuit, from the Open Software Foundation, from the Democratic Party Website, or from fbi.gov. Or whatever. There will be many different implementations of software because they all use the “e-voting interface standard” just like all the browsers use the same “HTML standard”. There will be an Open Source implementation and several proprietary implementations and so forth.
Your e-voting software talks to e-voting servers just like your email agent talks to email servers. The e-voting servers implement open interface protocols just like all the stuff that flows over the Internet. There are three distinct types of e-voting server (Registration, Distribution, and Counting), although often they will occur together (just like email uses “send” servers (STMP) and “receive” servers (eg POP3). Anyone can implement an e-voting server – just like anyone can implement an STMP or POP3, and they can do it by programming their own, but usually would do it by installing someone else's program. May be Linux distributions and Windows 2012 will come with e-voting servers you can install if you want, just like they come with STMP and DNS servers, today.
In order to work properly E-voting servers have to talk to each other – just like DNS servers do. DNS servers act together as an enormous distributed database that knows how to translate a domain name (such as 'www.google.com') into an IP address that is needed to get information to go to that domain. E-voting servers act together as an enormous distributed database that knows 'how many voters voted for which candidate'. The DNS server network contains a single "authoritive" copy of their data and many other copies, cached for performance reasons. E-voting servers will contain many "authorative" copies of the voting data, in order to prevent fraud and give confidence in the result.
But, of course, votes are secret. You don't want anybody, let alone everybody, knowing who you voted for.
However, in the current system somebody does. Or at least somebody has enough information to figure it out if they were so inclined. You identify yourself – when you register to vote and when you go to vote – and a ballot form is prepared for you, and it indirectly identifies you. This process is necessary to prevent voting fraud; to limit voting to qualified voters and to limit voters to voting once. An equivalent mechanism – with the same risks of disclosure – would be required for e-voting.
E-voting registration servers must be provided by a government authority to perform the voter registration function. It would be the same county and state government authorities with which you register today. Using your agent software you would register with an appropriate authorities e-server. You would provide the same personal information that you provide today. The result of the e-registration would be an e-voting key, that would be stored by your agent software. The e-voting server with which you registers has sufficient information to determine how you voted by matching the key to the personal data you gave them. This is exactly the same risk as the current system.
Technically the e-voting key is part of a protection and authentication mechanism in the same way as secure websites (https, SSL) protected your data, which is the same way as the Military and the spy services protect their data. The authentication of the data uses a trust tree, like SSL certificates, but one that starts with a single point – the Federal Government. It means that anyone can look at some data and know that it is authentic. The e-voting key includes a private-public key pair that is unique to the voter. This can be used (in combination with the SSL-trust tree) so that anyone can know for certain that some data was created by the individual that owns that particular e-voting key (or rather the software working as the trusted agent for that person.).
When a voter decides to vote, using his e-voting agent software, his vote is encapsulated in an authenticated packet that identifies who the vote is for. That packet is sent to at least one, but probably several, e-voting distribution servers. The e-voting distribution servers send the vote to the network of e-voting counting servers so that after an interval of time all e-voting counters will have seen the vote. (It could minutes, or may be hours, for the vote to flow to all e-voting servers.) Any e-voting server can validate the vote: it can read who the vote is for and who placed the vote (in the sense of a reference back to the registering authority, but not the real identity of the person), and it can be sure that the vote was placed by that individual. Therefore each e-voting server can count votes and determine the result.
Each e-voting server must support a query interface. This includes the simple query “How many votes were placed for each candidate”. It also includes more detailed queries that are based on differentiation of the voters according to demographics such as Zip code, gender, race, age. These demographics would be limited to those considered acceptable to report and publish, and would be included in the registration data. (The 'vote packet' could include the demographics or it could be retrieved from the registration database by a remote query. That's a design detail.).
In addition, the voter can include a 'tag' in the vote packet. This an arbitrary string that the voter chooses to represent himself. It could be his name. It could be long string that has no meaning to anyone except the voter. E-voting server queries can be made that include conditions on the tag.
For example, an e-voting server can be queried for the number of votes for candidate X by white male voters in zip code 12345 with tags containing 'abcdefgh'.
Why does this deliver security? Mainly because it is incredible hard to fake the results of an election when anybody can have the raw data and lots of indepedent people are counting the same results. If someone messes with the results produced by one voting server then it's going to the only one with a different result and obviously faked.
Confidence at an individual voter level will be provided by feedback through the agent software. After the user instructs it to place its a vote, the software will issue queries against various e-voting counting servers to verify that the vote was placed. The software could provide various ways of querying for the vote – for example by attaching a GUID (a unique string nobody else is likely to use) to the tag and then querying by for tags including the GUID.
One potential security threat is that the system lies for some queries and not for others. It lies for important quires (the overall election result) but tells the truth for verifiable queries (like when Joe asks how Joe voted). For example when Joe asks a query that includes Joe's vote, the system returns a query that honestly reports Joe vote, but when that system delivers the result of the election it counts Joe's vote dishonestly (applying his vote to the fraudulently favored candidate instead.). However, even with just a single system, it would be effectively impossible to maintain the fiction over a significant number of queries. Any query that Joe could make could also be made by his friend Bill, and the query result should be the same, so it is easy for a skeptic to verify that the system is always giving the same answers. A suitable collection of queries can be created (more likely by a newspaper or a university or the ACLU or the FBI – some body that considers it worth a moderate effort to discover fraud) that add up to a verification of the entire electorate, while including subsets that are independently verifiable. For example a 100 research workers agree to put the same long random string in their tags for their votes and disclose to each other how they voted. Then they issue a set of queries that, taken together, add up to the complete electorate, but with some individual queries that they know must be consistent with the 100 known votes and their tags. An overly simple example of this is that the system can't lie about the result of an election is if it forced to tell the truth about both how many men voted for each candidate, and how many women voted for each candidate, because the sum of the sub-queries would be inconsistent with the reported result. When the system is forced to respond to many different complex questions, fraud must show up as inconsistencies. The only way to produce consistent results is if they are all true.
Whether or not my outline is completely technically accurate, the main point is that technology is readily available to use the Internet for voting, and be as secure as those things (with large dollar values) that we already trust to those same technologies, and we could have a great deal more confidence in the result than we have today.
I have no doubt that an e-voting system would be attacked just as e-banking is attacked. We will have identity-theft voting and vote-phishing-websites. The ultimate protection for e-voting is the same as the ultimate protection for e-banking: visibility. You can see your vote, just as you can see a transaction on your bank statement. And if it ain't right, you can fix it. OK, it may be a hassle to get your bank to fix a mistake, and even more to fix the havoc from identity theft, but it is fixable. The same would be true of an e-vote.
See also: Technology Primer for e-voting