2

I recently asked a question regarding security obstacles of online voting via a web service, and one of the primary obstacles to doing this is the difficulty of proving that the program processing incoming vote data is the actual open source code shown to interested parties for verification of non malicious / unfair vote counting.

We can make the software for vote verification open source, but proving that the program actually running on the receiving end is code that should be used, running without malicious alteration seems like an interesting challenge.

So my question is: Is it fundamentally possible to provide proven (observably valid without doubt) processing information at the core of a security computing system so that expert observers / analyzers can know without doubt that specific, non-altered logic (the correct open source software) is being used to recieve, compute, and store information as promised?

More simply put, can we (fundamentally) somehow prove to people that we're performing the computational logic that we say we are? Prove to expert observers that we are receiving, processing, and storing data (for example, votes) via specificied logic, without the possibility for malicious influence?

Furthermore, if so, and this might be a difficult question, (fundamentally) can this be done in a way as to preserve the anonymity of the actual data being verified?

To be clear, such a feat might be an achievement of the utmost genius and involve writing new kernels, and and special OS - I'm not asking of the viability, I'm only asking whether it's fundamentally possible from an information security standpoint.

J.Todd
  • 1,310
  • 1
  • 11
  • 20
  • 1
    The technology involved in a ballot box is simply a few welding, a hinge, and a lock. It's quite simple to convince most lay people that a ballot box hadn't been tampered in a way that could affect the result of voting. OTOH, the technology in a computer is many orders of magnitude more complicated. The simplest CPU consists of hundreds of thousands of transistor. Even a computer security expert would have a hard time proving that a computer had not been tampered. – Lie Ryan Sep 21 '15 at 15:17
  • @LieRyan I agree. "It's quite simple to convince most lay people that a ballot box hadn't been tampered": There are still illusionist shows involving such simple boxes, but the prestidigitator still somehow manage to make the dove / rabbit / whatever appear or disappear thanks to some subtle tricks (sometimes even allowing the public to investigate the tools used). Such kind trickery is possible with the most trivial objects, so with a far more complex one such as a computer... – WhiteWinterWolf May 16 '17 at 19:30

2 Answers2

2

With existing hardware, no, it is fundamentally impossible to demonstrate that the code you run is indeed the code you should run and nothing else. This is easily seen with regards to confidentiality: imagine, for instance, that you run a vote-counting application; voters connect to it and send their vote. The "honest" application does not leak individual vote data, though it sees all votes and knows what each voter voted. However, from the outside, you see only the network packets that come and go, so you cannot tell whether some other part of the system is inspecting the RAM contents at the same time or not. In practice, a malicious system maintainer would run the application in a virtual machine and take VM snapshots whenever a new voter connects. By virtue of the VM emulating a "true" machine, this kind of malicious activity cannot be reliably dismissed.

Some things can still be done to try to obtain some guarantees that the code that runs is the expected one:

  • The hardware could be set up in a physically secured room, under audit, with access procedures that require at least two human operators, and video cameras recording the whole thing. This is commonly done for root certificate authorities: that kind of machine is on offline PC, kept in a cage in a secure room, and used occasionally (say, on a monthly basis) to issue a few certificates to intermediate CA, and to make new CRL. The whole process aims at ensuring that, indeed, the machine will do only what it is supposed to do; and this is all procedures, without special software.

  • For some operations, there are possible cryptographic protocols. For instance, for voting systems, one can use homomorphic encryption, allowing the central system to tally the votes without being given access to the actual vote contents. Since voters submit only encrypted votes, they must demonstrate that the contents are "valid" (they encrypted a 0 or a 1, but not another value): this is done with zero-knowledge proofs. Note the nuance here: the voter is not proving that he is using a specific, open-source code that encrypts his vote; but he proves that what he ultimately sends to the tally machine is indeed the encryption of a valid vote, regardless of how he actually computed it.

Tom Leek
  • 172,594
  • 29
  • 349
  • 481
1

Tom's post is a nice start on this. However, there's a more straight-forward approach I created years ago: a standard implementation on diverse pieces of hardware that check each other. I derived this because I realized the subversion problem actually boiled down to which manufacturers or reviewers you trust. The attack problem requires enemy to know what they're hitting. Diversity/obfuscation help there. So, assuming each person has a hardware or tools they trust, the solution naturally emerges of getting them all to compute the same result using the same data. The use of embedded boards and high-speed I/O makes the process both cheap and fast.

So, you start with a certified toolchain for code. I described how to build one here on HN:

https://news.ycombinator.com/item?id=10182752

Can also use Oberon System as a component because it's unencumbered, well-documented, flexible, easy-to-understand compiler, and portable. There's Scheme's like that, too, including VLISP variant that's mathematically verified down to x86, PPC, and ARM.

Anyway, the point is you have (a) mapping from HLL to binary, (b) OS interface w/ the same, (c) different, trusted hardware for each party, (d) each implemented interface + toolchain for it, (e) robust I/O parser + I/O mediation for hardware. These are combined with a switch that runs the software's steps in fixed chunks w/ occasional checks (eg hashes) on the results while shared machine for publishing pretty-prints and distributes them. Any of these parties can see a deviation and call it. With a decent voter protocol & I/O, this can scale up to about as many verifiers as your aggregation server can handle.

So, there's your answer. It's what I came up with for solving security of build systems that mutually-suspicious parties must trust. I assumed we'd eventually see hardware attacks from TLA's. The solution was diversity, obfuscation, easy bootstrapping, and easy verification that we're all on same page. Snowden and TAO catalog confirmed my predictions plus validated that and other methods of mine. This can be applied to most problems except for real-time or high-performance. However, there are real-time versions of each component in other projects. I just didn't work on them and can't say what integration would be like.

Nick P
  • 677
  • 4
  • 4
  • 1
    That sounds like a really viable solution... I'm interested to see what others say about this – J.Todd Sep 21 '15 at 16:49