This recent article about backdoors in hardware made me recall a thought that I’d had once for building a secure voting machine. In it, you do something like having a see-through touch panel built by vendor A, and all it knows is where the voter touched. It has no other inputs. You have a separate component for displaying candidates (which sits under the touch panel) and it’s mandated to take the input candidates and display them in randomly chosen locations on the screen. You have another component that receives information about the location of the touch and locations for the candidates, but the candidate information is encrypted so all it knows is which binary blob is associated with which rectangle that was touched. In the end, you keep building the system out so every part has an incomplete view, insufficient to be able to piece together the vote and thereby unable to modify that vote in a targeted fashion.
If those components are built by different vendors with competing interests and can even be the product of different vendors, having produced the component according to an open standard, then you’ve got a system that could be rife with backdoors and still secure from backdoors.
Extending this idea past a voting machine, it seems like this approach could be used generally with hardware design. You create a total design that isolates information and only exchanges it in encrypted forms with other components, to ensure that no one component can do anything malicious.
Is this an area of hardware development security that’s been investigated? Does it have a name?
But wouldn’t you have to bring it all together in the end? There must be a component that knows which candidate (not just which rectangular area on the screen) the voter tapped; otherwise you couldn’t count the vote for that candidate.
Anyway, I think the term for the basic idea is compartmentalization.
In the case of voting, there are cryptographic techniques (YouTube video | Wiki alternate) where the initial stage can output a private code and, in the end, you can verify that your private code was a component of the ultimate result. You can also triplicate the outputs, midway through the process, and put them through a second half that was assembled by different vendors with different components.
In the case of non-voting systems, you’d generally have to trust the final assembler. And, of course, the whole system would only be as secure as someone had properly done their design to ensure that all components are receiving insufficient data and that no two components from the same or allied vendors are connected together.
There’s also the issue that, with voting systems, it doesn’t just matter that the system is secure. It also matters that you can convince the general public that the system is secure. And the more complicated you make the system, the harder that is.
So how would your proposed system work if the power goes out?
We had the power go out in our polling place a few years ago during election day – but since we vote on paper ballots with pens & pencils, voters just continued to fill in their ballots by candlelight (it was in a church meeting room, plenty of candles were available) and put them in a cardboard box. When the power came back on, we just fed all the paper ballots thru the scanning counter.
Also, your system depends on voting machines. That makes it easy for partisan election officials to send lots of machines to precincts friendly to their political party (thus short lines) and fewer machines to the other party’s precincts (thus very long lines). We use paper ballots, have extra ones at each precinct, and have even more extras at headquarters, which can be delivered very quickly if we are close to running out. And wee can easily handle an unexpected large turnout – dozens of voters at once could sit with a pen and paper ballot to vote, wherever there is space. No long lines discouraging voters.
And then there is the cost. Our paper ballots cost less than a nickel to print, and we can easily afford to print many extras. The only expensive machine is the scanner/counter, and we can get by with only 1 for each precinct or pair of precincts. Whereas your system would require expensive machines. many of them at every precinct. Quite a higher cost.
And finally, recounts. It’s easy to recount our paper ballots – just take them and run them thru the counter again to verify the totals. Or just have human counters sort thru the paper ballots and count them in public. I’ve participated in this twice, while it took much effort & many people, the results were quite clear to everyone. How would a recount work on your electronic machines, and how would people trust that it is honest?
Having worked as an Election Judge for many years now, in the state that has the highest voter turnout in the country, I think you are trying to solve a problem that doesn’t hardly exist.
Most of the ‘vote fraud’ that actually happens is before Election Day. When they remove people from the voters roll under various pretexts, without notifying them, and then have pre-registration rules that prevent people from being able to vote. Here we have election-day registration, so those tricks don’t really work. That’s how you make elections more open & fair.
This bit would be fought tooth and nail by the political parties that like to pre-print sample ballots making it easy to show their faithful how to vote.
In general I would say that a lot of systems do this.
Anything that uses cryptography signing of data provides similar effect even if the data itself isn’t encrypted.
So you can create a data item, sign it, and send it to the recipient. They can use your public key to verify it was you that sent it, and the data is intact. They can send the data back to you signed by them, which lets you verify they got the data, and it was what you sent. The forward and backward encryption signing communication can be implemented by different people. It would require both entities to collude to effect fraud.
Security of the private keys used to sign the data are the critical components. Which is a whole problem in itself. But such signings can be used to provide provenance in a difficult to break manner.
The usual technique for secure systems is to have the design vetted by a separate group (or groups) to ensure the esign is clean. Separate the authority to update and to read, etc. Basically, just like accounting security, don’t give any one entity the keys to the kingdom.
This too ignores the database question. Getting the input is not difficult. The question is whether you can get it out and store it reliably. (The claim which cost Fox almost $700M was that the machines were switching vote tallies after they were entered.) I suppose the solution is to store the database simultaneously on two or more different units. But then, if they disagree the only thing you know for sure is that you don’t know what the real tally is.
The problem with bouncing screens is that some US jurisdictions have a massive number of people on a ballot, for a large number of positions. (This is what cause the infamous butterfly ballot and hanging chads in 2000) You don’t want to have a person required to wade through 20 or 30 screens to select the canidates they want. Plus, alphabetical order (or something similar) helps ensure the person can find what they are looking for - it’s a standing joke in computers, when you’re running the bus the guy looking over your shoulder can spot the text or link or whatever onscreen 5 times faster than you can. It’s easier if things are always in the right place. (The joke in Canada too is that Americans even elect their dogcatcher).
IMHO the simplest insurance is to print a paper ballot listing the voter’s choices. It can be simpler because it only lists the chosen candidates, not the whole ballot. It should be both machine-readable and human-readable. This ensures that a visual hand count can match a machine count, which proves the machine-read isn’t fudged. the voter can pick up and read their paper copy to check it before they submit it. The ballot’s machine code can include machine and approximate time - so you can’t identify voter, but can be sure it matches the number of votes in that, say, 5-minute window. That machine code also includes cypher checksum to ensure authenticity. It’s much harder to fudge paper, especially specially coded by the voting machine.
Paper works great in Canada, because for a federal or provincial election you only vote for 1 position. Simple to sort and count, and even recount by hand. When i worked the last federal elction, I counted the 300-odd ballots in my polling station myself, with party scrutineers watching. Most polling stations were done and reported results within the hour. Party scrutineers had the opportunity to dispute whether the marks were correct immediately on counting.
A lot of software and, specifically, networked software does. But the question was about hardware design and, specifically, to ignore the threat of outside actors and instead look inside at the components inside your own hardware. Are your own subcontractors the threat?
Traditionally, we view software as the scary thing, not that RAM module that I plugged into my motherboard. That’s not necessarily a safe assumption. And if we assume the RAM module to be nefarious then we should ask, “Does the RAM actually need to have all of its contents stored in clear-text?” If not, maybe its I/O should go through an encryption chip developed in-house and locally manufactured. Or, alternately, see if there’s a way to organize things so that every component can be from a nefarious vendor and yet, if everything is to spec, it can go to final assembly with not-a-thing being a concern.
Ideally, we should still be able to source cheap components from abroad and maintain low prices, without sacrificing security. Failing that, we’d still like to get as-close-as-possible to it.
You get the power working and then continue to vote. And if the power is out for so long that it starts to mess with the election timetable significantly, then maybe the outage gives you enough time to reconsider how you’ve been voting and what that’s meant for your local infrastructure.
You are free to start a GD topic if the topic intrigues you. But this is FQ and, for me, it’s merely a thought experiment that was used for illustrative purpose. I was not asking about voting machines.
I would say, though, that if it’s the specific engineering that interests you then that’s an engineering task - not a debate. It would involve sitting down and doing some real blood and sweat math and diagramming. I’m not interested in solving that problem for free and I’m not optimistic about the likelihood of it being taken up by the powers-that-be so spending the time on the engineering feels like a time sink, not product R&D. If someone feels otherwise, they’re free to DM me with a cash offer to consult.
The topic for debate, that I see, is whether you’d want to convert to an electronic system if one could be developed that was provably secure. But, I’d expect every post in that thread to be “You can’t do it! It’s impossible!” And you’d never actually get to the question being asked. Which then leads back to the engineering question that’s too large and finicky to solve for free. I’m not terribly interested.
There is a hot area of hardware security dealing with this kind of problem. The threat is that an unreliable fab could insert what is called a trojan (for Trojan horse) into hardware that will collect and transmit secure data or do other nefarious acts. The way to detect this is to apply a structural test to the chip designed to catch such things, and also measure power usage since the Trojan will use power. Or you can pop the top of the chip and compare the circuit with what you expect to see. There is a lot of effort put into making the chip as small as possible by sophisticated place and route tools, and any random blocks added post hoc should stand out like a sore Trojan.
No Trojans at chip level have ever been detected, and I doubt any will be for reasons I can go into if anyone wants. (I’m going to write a column about this soon.) There have been things like Trojans inserted on boards, which is much easier to do.