J. Alex Halderman, a University of Michigan computer security professor, hosts his research papers on voting systems, HTTPS, and encryption.
HN links his papers on HTTPS interception, Let's Encrypt, and voting machine security, and commenters cite his work as a credible security reference.
Sure, apt is secure. However, I don't think that's what's being discussed. If I remember correctly, the researchers were complaining about how Linux ISOs were downloaded, not packages. (The writer of the rebuttal seems to be confusing these, which is, again, concerning.) To quote their paper:
> Despite procedural safeguards, an attacker who strikes early enough can introduce malicious code into the counting server by using a chain of infections that parallels the configuration process. During pre-election setup, workers use a development machine, which is configured before setup begins, to burn Debian Linux installation ISOs to DVDs. These DVDs are later used to configure all election servers. If the machine used to burn them is compromised—say, by a dishonest insider, an APT-style attack on the development facility, or a supply-chain attack—the attacker can leverage this access to compromise election results.
> We experimented with a form of this attack to successfully
change results in our mock election setup. We first created
a modified Debian ISO containing vote-stealing malware
intended to execute on the counting server. The tainted
ISO is repackaged with padding to ensure that it is identical in size to the original. In a real attack, this malicious ISO could be delivered by malware running on the DVD burning computer, by poisoning the mirror it is retrieved from, or by a network-based man-in-the-middle.
> During the setup process, election workers check the SHA-256…
From your description I am missing one important idea that you should communicate clearly: you, we and nobody else currently wants to have online voting - what we want to have, are tools that enable transparency and gathering of information, also discussions and preparation of decisions, but the final decision is something you do NOT want to do online.
See this talk from 31C3:
http://media.ccc.de/browse/congress/2014/31c3_-_6344_-_en_-_saal_1_-_201412281400_-_security_analysis_of_estonia_s_internet_voting_system_-_j_alex_halderman.html
If you still believe that online voting is doable and a great thing, please contact Mr. Halderman and talk to him or read about his work: https://jhalderm.com/
Also I recommend to do some research what the german pirate party is using regarding democracy tools - they have a lot of experience not only coding such tools, but also with real life usage.
A good start could be https://liqd.net/en/
here you can find the adhocracy platform:
https://github.com/liqd/adhocracy/
which seems to be in a much better developed state than what I see on democracyOS - but maybe there are many things not visible right now to me, so sorry for this criticism.
Adhocracy is currently in use by several organizations and they have lots of real life experience, especially with user adaption.
An interesting application of adhocracy is https://offenekommune.de/
Another interesting tool for organizing (really big) meetings: http://openslides.org/en/
and of course…
Here's a 2012 paper from a team at the University of Michigan detailing a "mock election" gone wrong:
Title. Attacking the Washington, D.C. Internet Voting System
Abstract. In 2010, Washington, D.C. developed an Internet voting pilot project that was intended to allow overseas absentee voters to cast their ballots using a website. Prior to deploying the system in the general election, the District held a unique public trial: a mock election during which anyone was invited to test the system or attempt to compromise its security. This paper describes our experience participating in this trial. Within 48 hours of the system going live, we had gained near-complete control of the election server. We successfully changed every vote and revealed almost every secret ballot. Election officials did not detect our intrusion for nearly two business days—and might have remained unaware for far longer had we not deliberately left a prominent clue. This case study—the first (to our knowledge) to analyze the security of a government Internet voting system from the perspective of an attacker in a realistic pre-election deployment—attempts to illuminate the practical challenges of securing online voting as practiced today by a growing number of jurisdictions.
https://jhalderm.com/pub/papers/dcvoting-fc12.pdf
> I don't think that's the correct interpretation of this document. A better title would be "Most TLS Proxies Considered Harmful", not TLS interception as a whole.
This is the usual reaction to this I see everywhere. It doesn't match with reality. Read the complete paper by Halderman et al [1].
It says pretty clearly that all existing products lower the security in one way or another: "Our grading scale focuses on the security of the TLS handshake and does not account for the additional HTTPS validation checks present in many browsers, such as HSTS, HPKP, OneCRL/CRLSets, certificate transparency validation, and OCSP must-staple. None of the products we tested supported these features."
TLS Interception that doesn't degrade security is a myth that exists only in some parallel world fantasy. It's also not very surprising. Browser vendors have extremely qualified security teams that are involved in many ways in the development of stronger TLS protections. Nothing like that can be said about any of the vendors of interception products.
[1] https://jhalderm.com/pub/papers/interception-ndss17.pdf
There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes.
https://jhalderm.com/pub/papers/interception-ndss17.pdf
How do you fix this when you're naught but a humble employee? Well, a friend of mine worked at a fairly large tech company where a salesguy for these boxes had convinced the CTO they had to have them. Every tech-person "on the floor" hated the idea, so before the boxes were installed they conspired on their free time to write some scripts that ran lots of legitimate HTTPS traffic, effectively DDOSing the boxes and bringing the company's internet to a crawl for the day, like Google would take ten seconds to open. Then obviously everyone (including the non-tech people) started calling the IT helpdesk complaining that the internet was broken. MITM box salesguy then had to come up with a revised solution, costing 20x more than his first offer, and that was the end of that.
If you already are suffering under MITM boxes, a similar strategy with a slow ramp-up in traffic might work.
Electronic voting machines used in Indian elections are custom built for the purpose, and cost about $100.
https://en.wikipedia.org/wiki/Indian_voting_machines
All it has is N buttons, accumulators to store presses of each button in non-volatile memory, and a seven-segment LED display to indicate status (ready-to-vote, vote cast, etc.). Vote counting is done offline by connecting to a controller. No wifi or any other remote-access capability.
All that really needs to be done to create a paper trail is to add a printer.
Not implying that they're completely secure, but any breach at least needs physical access to the box. And physical security of the machines is on the same level as those provided for traditional ballot boxes.
Edit 1: The balloting unit does not even have a 7-segment display - just individual LEDs next to their buttons to provide feedback that the button has been pressed.
Edit 2: More details on the internals of the EVM: https://jhalderm.com/pub/papers/evm-ccs10.pdf