Can ROM checksum checker reliably defend against non-physical tampering/hacking of a voting machine?

Question

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 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.

Answer 1

There are a lot of assumptions in your description, and not all of them are valid.

Assuming physical security is a problem. Election officials have access to the machines, and presumably have the keys to the locked innards. Hidden physical tampering is always possible. Someone could hide a Raspberry Pi inside the cabinet that replaces the main machine, and it could respond in all the right ways. Even the election officials would not know the difference.

Assuming that there's safety in numbers is a huge problem. I can't find the source right now, but a while back I read a paper on Schneier's blog that an attacker doesn't have to corrupt an entire swing state, but only a few swing precincts within one or two swing districts within the state. Predicting which precincts to corrupt is entirely possible. Theoretically, the outcome of the entire presidential election could be altered by tampering with only a few dozen voting machines across the country.

Assuming there is "an" application to be checked is a problem. The machine has an operating system, a user interface, a ballot reader, a tally recorder, etc. The checksum would have to represent the entirety of the machine and all of its peripherals, not just a single program.

You're describing what is similar to the UEFI Secure Boot process. Microsoft, Intel, and others have had problems trying to get this to actually be an effective way to secure a machine (a Blackhat presentation showed ways around it.) Without a specific working implementation and years of analysis and attack, it's impossible to pronounce "X is secure"; even with a working implementation, I know of nobody that would stake their professional security reputation on such a pronouncement for voting machines.

Answer 2

John's answer already makes the following point in a very concise way, but I thought I'd expand on it a bit:

You've found a way to check that the software that's running on your voting machine matches the signature of the software on file at the federal election office. You do this by using an independent checker stored in ROM which checks a digital signature of the whole software state of the voting machine using public key cryptography.

Assuming that your voting machine is physically secure, the private key used to sign the software is secure, the public key cryptography used to create the signature is secure, all the hardware and the checker program itself is okay and so on, does this guarantee that the voting machine is okay?

No. The only thing is guarantees is that you know there is an exact binary copy of the software that's running on the e-voting machine at the time the check is made somewhere at the Federal election office. But you still don't know if this software is doing what it's supposed to do, and if it will still be doing what it's supposed to five seconds after the check is finished.

You don't know whether the software contains a clever piece of code that downloads malicious code from somewhere right after the check is complete, and purges the malicious parts before the next check is due. You don't know whether it performs a bit of magic on the final count, or ignores every tenth "wrong" vote, or does some other nefarious stuff. You still have to trust the people who wrote the software, the people who inspected the written software, the people who digitally signed the software and a whole lot of other people you don't even realize are involved.

Now ideally the software on a voting machine would consist of only a few hundred lines of very simple c code (basically, if this button is pressed, then increase a counter here, and print out this paper receipt here...) which could be checked independently by a single individual in an hour or two, but somehow I think that unlikely. Googling images of Diebold voting machines, I see screens with graphical usage instructions on them. That already requires many thousands of lines of code. Think code to load these graphical instructions from some kind of storage, which means I/O code, storage drivers, file format parsers, display drivers, graphical display routines etc. And that's just to display graphical instructions on a screen. All this code could contain malicious parts, and we haven't even touched the voting part yet. So John's paragraph about there not just being an "application" but a whole zoo of them, including a full-blown operating system, is very important. Who can verify the correctness of a whole operating system?

That's a pipe dream. A capable programmer responsible for writing software for the voting machine could always be bribed or blackmailed into adding malicious code in some dark corner of the system, and I'd assume chances of it being detected would be small. There'd have to be a huge amount of peer review; every single code change a programmer made to any part of the system would have to be checked independently, and then there'd have to be a system in place to make sure that the system that was signed at your Federal election office was actually the system that was reviewed.

This is a horribly complicated problem. For example, how can we be sure that the source code we see produces the compiled system that we'll sign? Can we trust the compiler that is used to compile the whole system? What happens if someone inserts code into the compiler which notices when the e-voting system is compiled and introduces malicious code into the compiled program that isn't there in the source?

So now you need to review every single change that's made to the compiler, too.

The compiler probably uses various code libraries and a large runtime. You need to review all the changes made to the runtime and the libraries the compiler uses, too. By the way, this also goes for all the libraries used by your e-voting machine code.

Verifying the digital signature of the software running on an e-voting machine is a very, very, very small part of making sure that the e-voting machine is okay.

Like Xiong Chiamiov in the comment to your question, I'd say this isn't the way to go. What you actually have to do is make sure that when a voter votes, he can find out later on that his vote influenced the final result in the right way. This would generally be very easy to do (give each voter a receipt, and publish the list of who voted how on a government webserver), but it gets really difficult because of the restrictions democratic voting places on us: We can't publish the list because we don't have it: Voter choices need to remain anonymous.

Answer 3

Another answer, following your update of the question.

If you knew the signed software didn't contain any malicious parts, then you'd only have to defend against bugs.

Lets assume that your ROM checker checked all software on the system, including all contents of RAM, repeatedly, lets say every ten minutes on average.

In that case, even if a bug allowed remote execution of code on the voting machine, the malicious remote-loaded code would only run ten minutes before being detected.

So the code would need to delete itself and restore the pristine state of the system before the next check, and remote code would need to reinfect the machine after the check was complete.

I don't think this is entirely impossible, but you could guard against it by making the check run at random short intervals, thus making it impossible for an attack to know when it had to restore the system state and at what time it was safe to reinfect the machine.

I'm seeing a problem with doing the checking though. Your system is only safe if the ROM checker checks RAM. So the checker would have to be smart enough to know which parts needed to stay static, and which parts of RAM were expected to change during normal operation.

For example, software pretty much always uses a stack for argument passing, storing return values and addresses etc. The ROM checker would have to exclude the stack, so this might be an area in which malicious code could hide. CPUs support non-executable stacks, but this would just make it impossible to RUN the code, not to store it.

The same goes for other data segments, for example those which store voting data. Parts of this memory could be used to store malicious code. Again, data segments can be protected from executing code, at least on Intel CPUs.

If, however, code execution in the dynamic, non-checked parts of RAM wasn't disabled, it would allow the malicious code to run continuously while remaining undetectable for the ROM checker.

I'm thinking about how the malicious code would make itself execute periodically or continously without touching any of the original code that was being checked by the ROM checker. Thats a really interesting problem, but one that I think could be solved as well. So the security of your system (ignoring the large number of assumptions needed to get here) really depended to a large part of how well you could lock down the non-checkable parts of RAM.