MrPerfect72 skrev:For the voter, as I understand it, a small "calculator"/"micro computer" with a USB-connection that only communicates with encryption with the voting system.
A person might re-program the device if he/she gets hold of it so that it votes faulty and this can only be discovered by an engineer. However, any electric/computer-engineer should be able to check the code
Or why not both? Use WLAN when that connection works, otherwise 3G.
Sure, the hotspot host could potentially be sabotaged, but IMHO extremely unlikely compared to personal computer installations.
Same thing with access points in our homes. Furthermore, if WLAN fails (which is the only thing that could happen) then the device could switch to 3G. Really, this is a pseudo-problem.
MrPerfect72 skrev:Well at least one reason for choosing to use only ONE technology is obvious. Cost.
MrPerfect72 skrev:There is a USB-connection available on most connected computers and it is usually easy to access.
MrPerfect72 skrev:Well, for grandma on the countryside WLAN or 3G wont help much either, I guess.
You guess wrong.
According to PTS http://www.pts.se in 2005 85% of the population had 3G coverage (in Sweden that is).
In 2007 almost 8.9 million people were covered, which is about 95%.
USB sucks because trojans can block the device's access.
MrPerfect72's friend skrev:re: Voting technology discussion. I will put a bit of time into it but it will be limited ...
I tried registering on your forum but after 2 attempts it blocked me out. I don't think there was a problem either time except maybe reading the CAPCHA code which was quite difficult and error prone.
Briefly ... pH7.3's arguments about security of device appear flawed or at least lack depth of analysis or description.
The foundation of security, the executive auditing mechanism, needs to be extremely simple and open making it verifiable by a large number of engineers. This principle cannot be over-stated, it is paramount. This means that whatever hardware the trusted voting device uses must be very crude, hence the idea of a USB connected device. However one could make a device which contains two sections: 1) a trusted module and 2) some other more complex untrusted sub-system providing flexible communication such as USB, Wifi, 3G, 4G etc.
One principle which must not be broken is this ... the input (keypad) , output (screen) devices must be an integral part of the trusted module. One cannot rely on some sort of untrusted external I/O hardware/software such as provided by a phone manufacturer. Ideally if phones were all fitted with a standard communication port (such as USB ) the trusted voting device could be plugged into them and everything else. But current trends indicate it is unlikely all phone manufactures would provide such a port.
The argument about trojans being able to block data traffic is valid but fails to see the bigger picture ....
1) system security protocols will ensure vote data traffic cannot be altered without detection and also prevents a voter from being tricked into believing his/her vote was posted and counted if it was not. i.e. full end-to-end verfication and confirmation will be provided by the device.
Voters would need to be educated to check both ...
1) the trusted module's self test/audit verification code (which would be widely published, known and trusted) and
2) the vote registration verification/confirmation message which is sent back to the device when posting votes.
If a trojan was present (in the untrusted system) and blocked or corrupted the voting data packets, the vote confirmation message (2 above) would never occur. To avoid human error it might be useful to use a color display which continously displays a big RED "Vote NOT yet counted" message until the confirmation is received,at which time the display would change to a green "Your VOTE on issue xxxx registered as yyyy. Confirmation code zzzz" or whatever. (or perhaps a list of confirmation in the case of a vote on multiple issues in one post). It would be simpler and perhaps useful to limit the voting to a single vote per message. These details need to be worked out in the design requirements process.
If the voter is blocked by an infected untrusted communication pathway (certainly a possibility), the voter will be aware of this and able to plug their voting device into any number of available communication systems until a successful vote is posted. Because such blocking attempts would be futile and inaffective at altering voting behaviour i think we can assume such hacking modes to be unlikely, infrequent and irrelevant.
Before delving ino the specifics of port type, communication technology etc. used by the trusted voting device, we need to look at more relevant security considerations.
Rogue parties will typically attack any security system at it's weakest link. In this case, assuming a proper and well verified technical implementation, the weakest link will likely be in the human processes involved with registering and binding voting devices with eligible voters. Such a process would probably involve some sort of traditional paper based voter register with human auditors. I think this is the most practical (unless everyone is fitted with an RFID device which obviously has other insidious consequences and therefore not acceptable).
A problem is that some humans need to be trusted somewhere in this process. To thwart corruption of the human processes one could implement pretty good safeguards and procedures similar to those used in other high security systems such as banks. A common approach is to require many people together to open locks,. the idea being that it is much less likely that the whole team conspire and collaborate to subvert the system. This is not fool-proof but the technology can assist in the case of voter registration by binding and storing an administator (human) authorisation ID or signature to the device and it's registration data.
Let me explain ....
Let's say a government employee has the job of verifying the ID of a Swedish citizen and registering their voting module with the voting system. There are various ways this process could be corrupted and I think this is probably one of the weakest links in the proposed voting system - along with the process of issuing some sort of citizen ID document or device. As part of the registation process the government employee would need to electronically sign the registration data with another trusted ID device (such could be exactly the same device as the voting module but used slightly differently). This electronic signing would form the backbone of an audit trail which could trace and pinpoint any rogue voter registrations down to specific human individuals, administation functions, dates and times. The audit trail itself cannot prevent corruption but provides full transparancy all the way through the voting system. The risk of detection, exposure and severe punishment for deliberate wrong doing would hopefully be an effective deterent and keep the government processes honest and maintain integrity on the voting system. (Similar auditing processes could be implemented at every level of government to reduce corruption at all levels - but that is a much bigger subject!)
The secure identification of people becomes a necessity in the context of security and auditing of critical processes such as voting and voter registration. The trusted voting module could be made as a generic electronic ID and signing device but having some important differences to an RFID device:
1. an RFID works passively without requiring the consent of the person which it identifies, but a voting/ID device requires the acceptance and action by the human being identified.
# an RFID device links the identification event to a visible human, but a voting device can be used remotely and anonomously (anonomously to humans but with secure identification and secrecy within the voting process and data storage). The voter module could be used anonomously or not as required according to the choice of the person using it. i.e. according to the circumstances the person could submit data with a publicly available ID or not.
# because an RFID doesn't require the authorisation of the ID holder to transmit it's ID data, it doesn't have intrinsic protection against identity theft. With RFID, stealing a chip amounts to sealing an identity (except when bound to a photo passport or whatever) but a voting device identifies the person by something they possess (the device) and something they know (a secret password). This is called two factor authorisation. Biometric readers could also be used to thwart identity theft but not really required.
sorry, I've reached my time limit for today ....
MrPerfect72's friend skrev:Briefly ... pH7.3's arguments about security of device appear flawed or at least lack depth of analysis or description.
MrPerfect72's friend skrev:. However one could make a device which contains two sections: 1) a trusted module and 2) some other more complex untrusted sub-system providing flexible communication such as USB, Wifi, 3G, 4G etc.
MrPerfect72's friend skrev:1) system security protocols will ensure vote data traffic cannot be altered without detection
MrPerfect72's friend skrev:Voters would need to be educated...
MrPerfect72's friend skrev:Re: Trusted Voting Module - a couple of mistakes/typos, plus some more ..
last paragraph ...
With RFID, stealing a chip amounts to stealing an identity (except when bound to a passport, photo or whatever) but a voting device identifies the person by something they possess (the device) and something they know (a secret password). This is called two factor authentication. Biometrics (e.g. thumb reader) could also be added, giving 3 factor authentication, to thwart identity theft but probably not necessary or desirable. Unreliable biometric readers could cause voting problems.
An important outcome for any such voting system is that it wins the trust of the people. For the system to gain wide acceptance any mishap must be avoided. Even small anomolies could be used by direct democracy opponents for spreading distrust in DD. It is therefore advisable to implement such a voting system in a trial mode a long time before using it for anything like national voting. It could be used in small scale DD for a long as it takes for interested people to understand the principles, become familiar with it's operation, refine it as needed, and develop trust in the system.
In addition to developing the concepts for a trusted electronic voting system, I would also like to propose a system of DD which uses a form of proxy voting as we previously discussed.MrPerfect72 skrev:According to the people I spoke to, you would be able to put a video camera watching the person typing his/her code and then using the device and vote until the person discovers the deed.
A 3 factor authentication (requiring a voter's body part such as thumb) would avoid this possibility. But I think voter education and diligence (care taken while entering passwords) would be sufficient security. Significantly altering election results by this method is totally impractical and thus highly unlikely.MrPerfect72 skrev:A person might re-program the device if he/she gets hold of it so that it votes faulty and this can only be discovered by an engineer. However, any electric/computer-engineer should be able to check the code.
It would be extremely difficult for large numbers of rogue versions of voting modules to be produced without detection and this fact alone should be a strong deterrent against such activity. Anyone caught doing it or attempting to do it would hopefully face severe penalties.
How would rogue modules be detected?
An important part of the device is it's self integrity check function. Admittedly this is quite tricky to implement in a trusted and tamper-proof way. There could be some dummy voting servers which are used to test the integrity of your device. You could do some trial votes with those servers and verify that your votes were recorded as intended, indicating the device is working as expected. The voting communication protocol would be designed to make it virtually impossible for a hacked version of a device to appear to work properly on the test server but incorrectly on the real voting server. But this requirement needs some serious security analysis and design work!
Better still is for everyone to be encouraged to verify their actual vote was registered as intended by looking up their vote on the public server. Actually this vote confirmation function is mainly designed to build confidence in the system rather than catch out rogue modules.
Here is how it might work ...
Each voter can look up and confirm their vote using 2 unpredictable and secret codes:
1) the secret vote confirmation code (VCC) which their voting module displayed in their vote confirmation message.
together with
2) a shared secret chosen by the user (a password entered into the voting device prior to voting) for accessing the vote confirmation data.
The VCC would be stored in your voting module memory for retrieval as required. However the password could not be read but only entered or reset.
Server hackers would not be able to trick voters into believing their vote was registered correctly while subverting the system because they could not reliably predict what vote confirmation data to send to the user each time. Although the user's computer for this operation is untrusted and therefore not reliable, any such hacking scenario would be quickly detected by sufficient voters for alarm bells to start ringing rendering such hacking attempts ineffective and futile.
Also ... auditing and monitoring systems could be implemented which automatically post dummy votes and verify that those votes appear as posted. But this would over complicate things somewhat and perhaps introduce a loophole. More thought required on this.
Or more simply ... hackers wouldn't try this because it would be easily and quickly detected and this rendered futile. However it is feasible that hackers would do this if only to create mistrust in the voting system. Perhaps server redundancy and diversity would be used to reduce this effect and make it less attractive for server hackers.
Designers also need to consider denial-of-service (DOS) attacks against both vote posting servers and vote confirmation servers. Constant server monitoring and clever rapid response mechanisms would need to be in place to avoid significant voter frustration by DOS attacks.
Intrusion detection and honeypots could also be used to make it more risky for hackers and to provide triggers for self-healing and server recovery strategies.
A full implementation for reliable large scale voting would require expert security analysis, advanced network security engineering, auditing and monitoring, etc. But compared to the cost of traditional style elections, the engineering required for a reliable DD voting system should be easily affordable for national or state governments.
MrPerfect72 skrev:Cracking the encryption of the sent message will be impossible if it is encrypted hard enough and I think it is possible to get special permission to encrypt very hard for such a device considering its limited purpose.
Strong encryption technology is now freely available and not an issue at all.
Återgå till International section
Användare som besöker denna kategori: Inga registrerade användare och 2 gäster