e_to_the_pi_i_plus_1 t1_itqseft wrote
Reply to comment by PaulSnow in I am the co-author behind ACM’s TechBrief on Election Security: Risk-limiting Audits. Ask me anything about election security! by TheOfficialACM
Part of the issue is that elections are managed by municipalities. States have different rules and inside of states many counties have their own rules.
For a long time, hiding source code was thought to improve security. Voting machines are expected to last 10-20 years so it takes time to move to more modern notions of what makes something "secure."
dratsablive t1_itr5jh4 wrote
Not just time, but the motivation and funds to change.
PaulSnow t1_itrgzm2 wrote
Open source hardware and software is the only way to rid ourselves of accusations that are made about voting machines like we saw in 2020.
And it isn't an entirely baseless fear. We do know software is often compromised, and we even know hardware is often compromised.
The most secure software in the world is open source, and the best way to build forward with secure voting software with rich features is to ensure everyone can develop on a common base.
borktron t1_itslz64 wrote
While I'm generally in favor of well-understood and battle tested open-source hw/sw, it's not really a panacea. How do you know the build of the open-source software hasn't been tampered with? How do you know that the physical machines actually in use conform to the open-source specs and haven't been tampered with?
Of course, you can mitigate some of those risks by allowing stakeholders to inspect, verify hashes of builds, etc. But that's a lot of human-factor stuff on top that you're absolutely relying on.
So even in an open-source hw/sw world, RLAs are still critical.
TheUnweeber t1_itsw9xz wrote
Although open source isn't a panacea, couple it with trustless ledgers, and the more parties distrust each other, the more nodes they (and nonpartisans) will run. ..and that's nearly a panacea.
PaulSnow t1_itudneq wrote
This is exactly the point. Fewer truly independent code bases, increased distribution of knowledge of the code, more tools deployed for automated verification/validation of the code, etc.
Proprietary code usually ends up devolving to the point most of it is treated like a black box. This is because knowledge of the internal code is restricted. And then over time the institutional knowledge is lost as people quit the effort (nobody is immortal).
At least with open source, knowledge can be distributed over larger bodies of people, and more experts can exist for the entire ecosystem to leverage. For applications where no "secret code" or "secret sauce" is required and in fact is nothing but a danger, Open Source is the solution.
PaulSnow t1_ittge4u wrote
I am a big fan of RLAs. Basically we ran the election in 2020 in a way very few statistical tests could be run to compute a confidence level on the ballots.
However, software builds can be hashed and signed, and open source hardware can refuse to load unsigned builds. But how to evaluate the signature? This is where small cryptographic proofs from blockchains provide a distributed ledger.
The hardware and the software can be reviewed by everyone earning money in the voting game, and when disputes arise, there is no excuse to demand access to the voting machines because everyone has access by definition.
Open Source solves both pragmatic transparency issues, and political ones.
billy_teats t1_its8mb6 wrote
Go be fair, open source software is increasingly becoming compromised. Some of the modern attacks would not stand against election systems, like someone taking over an old domain that didn’t get paid for so they can get someone’s custom email so they can reset the password to an account that owns a repo. Or someone making a pull request with a bug fix and also oh ya here’s a little call out to a C2 server.
PaulSnow t1_ittguvh wrote
Not really. A tiny inactive project can run all those risks,sure. But voting software to be used in the US is going to be a big, active project. And many interest groups will be willing to pay for reviews of the source.
Every change sticks out like a sore thumb; hiding an exploit in a bug fix is more of a movie plot than a reality. Automated testing and source analysis will pick up any call out of the software with no human intervention.
Natanael_L t1_ittyuja wrote
The issue remains proving the hardware runs that software and that software only. No extra chips, no modified chips, not even tweaking semiconductor doping, and no exploits against the secure boot mechanism.
Even game consoles and the iPhone and sometimes HSM's fail at this.
PaulSnow t1_itucs77 wrote
If the hardware is modified, this can be detected. And deploying the hardware should be done with the consideration that the voting machines themselves are hostile. So keeping hardware off networks, using fixed communication channels, blockchain tech (which prevents processes from accepting data that isn't properly registered, does not go through fixed processes), etc. remains critical.
Proving security is impossible, but pragmatically it is possible. The unique requirements of voting software make it far easier to secure than any device that requires networking to be functional.
The most secure voting system is one that doesn't allow voting at all, preventing any exploit to capture or corrupt ballots. Since that isn't an option, we do the best we can. Which can be very good. None of the exploits discovered to date lack some process to address them.
Natanael_L t1_itufvgn wrote
In practice it's the paper copies that's the best security measure. It really isn't feasible to audit the hardware in full at scale.
PaulSnow t1_itwczyd wrote
Have we forgotten Florida already?
Natanael_L t1_itwew4c wrote
Do you think every voting machine in Florida can be xrayed?
PaulSnow t1_itydl6t wrote
Not sure what xraying voting machines is supposed to do.
Natanael_L t1_ityfenv wrote
How to you think hardware tampering is discovered?
PaulSnow t1_itziv5a wrote
Through testing, architecture, and audited manufacturing.
Auditable manufacturing processes at every level.
Altering chips requires massive changes in workflow and processes.
Certification of manufactures (Not having your hardware manufactured in suspect countries like china).
Hardware design that separates keys and security from general computing. Embedded hardware testing and verification.
Hardware can be architected to be self checking, such that changes or alterations do not produce the same timing and values as the proper hardware.
https://www.securityweek.com/closer-look-intels-hardware-enabled-threat-detection-push
I can't find any reference for detecting hardware modifications with x-rays.
Natanael_L t1_itzm4n5 wrote
Did you not look at the link I provided above?
PaulSnow t1_iu0g3ko wrote
I don't remember a link to talking about x-rays, and a review of the history didn't reveal a link from you I didn't read.
So what am I looking for?
Natanael_L t1_iu0m81m wrote
https://www.reddit.com/r/IAmA/comments/yd7qp6/i_am_the_coauthor_behind_acms_techbrief_on/ittyuja/
https://www.infona.pl/resource/bwmeta1.element.springer-147a2312-2fe6-3a08-9954-a904e950f9bb
> Instead of adding additional circuitry to the target design, we insert our hardware Trojans by changing the dopant polarity of existing transistors. Since the modified circuit appears legitimate on all wiring layers (including all metal and polysilicon), our family of Trojans is resistant to most detection techniques, including fine-grain optical inspection and checking against “golden chips”.
PaulSnow t1_iu23xnr wrote
Your first link is just your post, and it doesn't mention x-raying anything.
The second mentions optical inspection and checking against "golden chips" isn't x-ray, and there is no reference to x-raying hardware here in the abstract. And I don't have a subscription to read the paper.
Natanael_L t1_iu2a0dm wrote
https://spectrum.ieee.org/chip-x-ray
And optical inspection is common - and less capable in detecting attacks like manipulated silicon doping
PaulSnow t1_iu2kxqj wrote
The article does not say they can detect doping. Their test was a flaw in a interconnect layer.
But great. You would do a statistical examination of batches of chips. Done. Their process is destructive.
billy_teats t1_ituh1hz wrote
>>Hiding an exploit in a bug fix is a movie plot
Well this is taught up wrong
PaulSnow t1_itvxdnw wrote
The kind of exploit you describe (making a call out over the network hidden in a bug fix) is in fact very unlikely. This is pretty easy to find in code that is reviewed and tested as with most Open Source projects.
Especially applications like voting applications that have no networking functions.
TheUnweeber t1_itsvzfu wrote
..and, what about trustless ledgers? This is probably the safest direction to be heading.
Viewing a single comment thread. View all comments