billy_teats t1_its8mb6 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
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.
Viewing a single comment thread. View all comments