UPDATE: just to be clear, the assumption here is that any attack is external to the machine's vendor, and therefore, the software written for it by the vendor does exactly what it's supposed to do barring adequately explained by stupidity bugs. There are no clever trojans in the code, there is no attack vector in the compiler used by the vendor. The question's context is defending against an attack by a 3rd party on a perfectly valid functioning machine.

You can also assume you can trust the checksum signatures on the federal website - why that is the case is irrelevant, but heck, it's as simple as having interns from every party of interest sitting there all election day with printout of original checksum and verifying that the website still matches the printout.

UPDATE: just to be clear, the assumptions here are:

• Any attack is external to the machine's vendor, and therefore, the software written for it by the vendor does exactly what it's supposed to do barring adequately explained by stupidity bugs.

  There are no clever trojans in the code, there is no attack vector in the compiler used by the vendor. The question's context is defending against an attack by a 3rd party on a perfectly valid functioning machine.

  Reasons: because the context in which I asked the question was 3rd party attacks in real life (and not baked in trojans). Also, because otherwise, the question becomes trivial to answer and uninteresting. Of course you can suborn the vendor with enough resources, duh.

• You can also assume you can trust the checksum signatures on the federal website - why that is the case is irrelevant, but heck, it's as simple as having interns from every party of interest sitting there all election day with printout of original checksum and verifying that the website still matches the printout.

• There were objections raised to assumption that physical security through "obscurity" (or sheer volume) is effective-enough because there are only very few swing precincts. This is actually a valid assumption to make.

  Reason: in practical US politics, given the polling margin of error (witness 2016 elections), knowing what the swing states/precincts would be is near impossible. Never mind that in wider-change elections like 2008 or 2016 or 1992, the amount of machines you need to tamper with to actually affect the outcome of electoral college (instead of slightly shift its vote margin) requires TONS of states/precincts to change. 2000 election with Florida's specific precincts was an outlier, not a rule - and even in that election, predicting that Florida would be a swing state with those specific precincts was not easy.

Every time there are elections in USA, questions of the security vulnerabilities and hacking/tampering with voting machines are raised (I'm sure that it's not US-only phenomenon, either).

Obviously, preventing hardware level hacks is a whole different kettle of fish, but if we assume that the machine is physically secure - if for no other reason, because there are just so many, all over entire USA, so it's nearly impossible to tamper with meaningful enough amount even only counting swing states), would the following approach be a reasonably reliable way to prevent non-physical tampering/hacking of a voting machine?

1. Have a real ROM (non-writeable) storing the checking code

2. Checking code verifies that the voting machine software is valid (presumably, by computing checksum, and verifying the checksum against known valid values - for example, stored on a website of Federal election office).

   • Use public key encryption for ensuring that the check-sums retrieved are indeed sourced correctly (using federal election office's public key).

3. If checksum fails, use separate hardware NOT controlled by the rest of the electronics in voting machine, to at least signal malfunction, or even lock out voting functionality.

Since the checking code is 100% in ROM, it would require physical access to the machine to mess with (and if it's sufficiently well protected, e.g. within a welded compartment, would be extra hard to screw with).

Every time there are elections in USA, questions of the security vulnerabilities and hacking/tampering with voting machines are raised (I'm sure that it's not US-only phenomenon, either).

Obviously, preventing hardware level hacks is a whole different kettle of fish, but if we assume that the machine is physically secure - if for no other reason, because there are just so many, all over entire USA, so it's nearly impossible to tamper with meaningful enough amount even only counting swing states), would the following approach be a reasonably reliable way to prevent non-physical tampering/hacking of a voting machine?

1. Have a real ROM (non-writeable) storing the checking code

2. Checking code verifies that the voting machine software is valid (presumably, by computing checksum, and verifying the checksum against known valid values - for example, stored on a website of Federal election office).

   • Use public key encryption for ensuring that the check-sums retrieved are indeed sourced correctly (using federal election office's public key).

3. If checksum fails, use separate hardware NOT controlled by the rest of the electronics in voting machine, to at least signal malfunction, or even lock out voting functionality.

Since the checking code is 100% in ROM, it would require physical access to the machine to mess with (and if it's sufficiently well protected, e.g. within a welded compartment, would be extra hard to screw with).

UPDATE: just to be clear, the assumption here is that any attack is external to the machine's vendor, and therefore, the software written for it by the vendor does exactly what it's supposed to do barring adequately explained by stupidity bugs. There are no clever trojans in the code, there is no attack vector in the compiler used by the vendor. The question's context is defending against an attack by a 3rd party on a perfectly valid functioning machine.

You can also assume you can trust the checksum signatures on the federal website - why that is the case is irrelevant, but heck, it's as simple as having interns from every party of interest sitting there all election day with printout of original checksum and verifying that the website still matches the printout.