This demo software needs work in several areas before it can be considered ready for prime time.
In production it is essential that all web traffic be encrypted with SSL/TLS. The server used for this demo is TLS-capable, though with a certificate signed by the UCLA Mathematics Department Certificate Authority, not traceable to commercial trust vendors whose certificates are distributed with major web browsers. See the
Backup is a major problem. The instructions suggest that the voter
should put the backup media and/or the written password for the private key
in his safe deposit box. It is hopelessly naïve to expect that the
masses
have safe deposit boxes, and a more universal way of saving
sensitive data needs to be thought of.
In several places the voter proves his identity by signing his Registration Certificate and sending in both the certificate and the signature file. To create the signature he needs to use his private key, i.e. he needs to know its password, which (supposedly) only the actual voter knows. A weakness is that he can create the signature once, and it will be valid and stealable forever after. We need a real challenge-response protocol to prove that the actual submitting user is the voter. I shied away from that for the demo because of the extra complication of making the voter save yet another file, but it's going to have to be done.
The demo software calls SQLite directly (through a wrapper function). It should use ODBC exclusively, interfacing that way to the chosen database engine, since a distributed backend is going to be required for production.
The Registration Table has slots for one name credential and one address credential per voter. In reality it should be possible to provide several of each, and so they would need to be in separate tables.
The Ballot Ticket needs a field indicating what precinct the voter is in, so the ballots can be grouped and counted per precinct.
Generally the ballot varies by precinct, e.g. according to the Congressional district, and the software needs to be extended to provide this feature.
A lot of operations are repeated in multiple files. These need to be
extracted into one or more include files. The one functions.incl
was stolen from another project and retains quite a number of functions
specific to its origin; these need to be cleaned out.
No attempt has been made to support old Macintosh operating systems, i.e. before MacOS-X. For production, some accomodation needs to be made for older Macs.
While this author would love to see voters who run Microsoft® Windows® exposed to the wonders of the UNIX world, I wonder how much customer resistance we're going to see when we tell them to install Cygwin. Some kind of fancy Active-X Control would be a lot easier for the users to swallow, even as it opens them up to a Trojan Horse from a fake software download site.