Wear gloves about sums it up. Rubber gloves, which you burn when you're done. Interestingly, Robert Graham (a bona fide security expert) wrote that this is unfair, although if you read all the way to the end of his post you'll see that it pretty much is fair:
It's like fail-systems in industrial systems, where we are less concerned about whether the normal systems have an error, but much more concerned about whether the fail-safe system works. It's like how famously Otis is not the inventor of elevators, but the inventor of elevator brakes that will safely stop the car from plummeting to your death if the cable snaps.I'd suggest that there is a gross lack of security design standards in software engineering (especially compared with physical engineering). I've written about this for ten years and none of this has really changed:
What's lacking in election machines therefore is not good or bad software engineering, but the failure of anybody to create fail-safes in the design, fail-safes that will work regardless of how the software works.
So what's the system of the online mobile bank? We need to understand this to understand the risks of the different system components to get a good understanding of the overall risk.Now, at this point I need to say that I wrote this about online banking. In my experience, Banks have very, very good security, and a very, very good understanding of risk and how to manage it. That means that this is the absolute best theoretical case for online voting, and for the VOATZ app in particular. Let's break down the three risk areas above by what we know about VOATZ.
There's the web site itself (logo blurred out here to protect the guilty). My experience is that you'll find the best security in the Defense Department. Very close behind that is security at the major banks. I have made some snide comments in the past about online banking, but the problem isn't that they don't have cutting-edge technology, or skilled operations personnel, or processes and procedures that are backed by executive management. Someone's in charge of the system - you can ask the question who's the online security guy and get an answer. While there will always be the occasional security vulnerability in the web portal, the risk here is low.
There's the Internet, that sits between you and the web site. Security is lousy here, but the encryption used to scramble your data while it flies over Al Gore's Intarwebz is so good that the risk here is basically non-existent.
There's your phone, and your phone's browser. Technology is moving very, very fast here, which means that security is an after thought. You have many different vendors - one makes the phone, a different one makes the software, and a third one that sets everything up. For me, it's some company in China who makes the phone, and Apple who makes the software (OS X and Safari), and AT&T who sets things up.
So when it comes to your phone, you are the "online security guy". You need to configure the phone securely and make sure that things are working correctly. Not your bank - after all, it's your phone, not theirs.
So what's the risk of the overall banking system? Negligible risk in the banking web site and Internet transport, but indeterminate risk in your phone.
In an engineering sense, "indeterminate" is a Bad Thing, because you can't estimate costs and risks. It's more than just Ted has a bad feeling going on here, there are serious issues that you need to know before you know if the overall online mobile banking system has unacceptable risk
The risk of data transiting the Internet is no different. Yes, it's possible that the VOATZ app has screwed this up, but this is a pretty low risk. iOS apps, for example, get encryption services from the iOS operating system, so unless you think that Apple has screwed up the crypto, this is likely not bad.
The risk of the back end servers is real. Banks are good at this, so what do we know about how VOATZ measures up? What we know does not inspire confidence:
UK-based computer security bod Kevin Beaumont outlined on Monday a list of red flags that he spotted.
We're told the Voatz website needs patching: it is powered by an out-of-date version of the Apache web server on a box with an out-of-date SSH service and PHP installation. It also apparently exposes NTP, POP3, PHP3, and a 2009-era edition of Plesk to the internet. The site's database, hosted on Azure, has a remote administration panel exposed on port 8080 with no HTTPS protection, according to Beaumont.
This does not inspire confidence that Voatz can keep miscreants out of its servers, and prevent them from potentially meddling with election results.All these exposed services suggest a default installation of the web server without any follow up to lock it down. In short, it is indicative that the VOATZ server farm is administered by incompetents, which shouldn't give the good citizens of the Mountain State warm fuzzies.
Worst is the security of the VOATZ app itself. There are huge flashing red lights from what we know here:
Very little information is publicly available about the technical architecture behind the Voatz app. The company says it has done a security audit with three third-party security firms, but the results of that audit are not public. Sawhney says the audit contains proprietary and security information that can’t leak to the public. He invited any security researchers who want to see the audit to come to Boston and view it in Voatz’s secure room after signing an NDA.
This lack of transparency worries people who’ve been studying voting security for a long time. “In over a decade, multiple studies by the top experts in the field have concluded that internet voting cannot be made secure with current technology. VOATZ claims to have done something that is not doable with current technology, but WON'T TELL US HOW,” writes Stanford computer scientist and Verified Voting founder David Dill in an email to WIRED.
Voatz shared one white paper with WIRED, but it lacks the kind of information experts might expect—details on the system architecture, threat tests, how the system responds to specific attacks, verification from third parties. “In my opinion, anybody purporting to have securely and robustly applied blockchain technology to voting should have prepared a detailed analysis of how their system would respond to a long list of known threats that voting systems must respond to, and should have made their analysis public,” Carnegie Mellon computer scientist David Eckhardt wrote in an email.
Ideally, experts say, Voatz would have held a public testing period of its app before deploying it in a live election. Back in 2010, for example, Washington, DC, was developing an open-source system for online voting and invited the public to try to hack the system in a mock trial. Researchers from the University of Michigan were able to compromise the election server in 48 hours and change all the vote tallies, according to their report afterward. They also found evidence of foreign operatives already in the DC election server. This kind of testing is now considered best practice for any online voting implementation, according to Eckhardt. Voatz’s trials have been in real primaries.If at this point you're catching a whiff of snake oil, you're not the only one. And back to the XKCD: They say they've fixed it with something called "Blockchain".
So if you were one of the Bad Guys, what attack vectors might you investigate? Here off the top of my head are what you might consider:
- Look for App vulnerabilities that would allow using fake/forged biometrics. Even if the blockchain is secure, if you can feed bogus data into the front end you can potentially cast votes for someone.
- Look for App vulnerabilities that change the user's vote after it is cast but before it is entered into the blockchain.
- Look for server-side vulnerabilities that let you block the service (Denial Of Service). This would disrupt or prevent an election from being completed.
- Look for server-side vulnerabilities that would cause absurd vote tallies to be reported. This would reduce confidence in the electoral system ("Denial of Service via Resource Poisoning").
But the mother lode of hacks is where you take over the server and cause small changes to the tallies in a way that throws the election the way you want. This is not just a theoretical problem:
Nowhere was this more clear than when Georgia cybersecurity expert Logan Lamb accessed at least 15 counties’ election management databases from the central tabulator via the state Center for Election Systems’ public website, the order continued. The white hat hacker notified CES he was able to obtain private elector information and DRE passwords used by polling place supervisors, but the state took no action between August 2016 and February 2017.The judge in this case was rather tart in her ruling on this case.
NONE of these risks seem to have been addressed by VOATZ - no doubt because the entire company has perhaps a dozen employees and is running off of venture capital funding. Remember, this is just a quick list of attack vectors off the top of my head. This looks like it's an exceptionally target rich environment and so the list will certainly be much longer.
But back to Robert Graham's objection to the XKCD cartoon: what's important are not vulnerabilities, but failsafes. If you have paper ballots then you have a decent failsafe. That's not what you have here, and handwaving while muttering "blockchain" doesn't change that.
Online voting is a persistently bad idea, one that is only liked by people who are completely ignorant of the security issues, and yet one that seemingly will not go away. If you are suspicious that Stalin's dictum of it's not who cast the vote that matters, what's important is who counts the vote is in play here, you're not the only one.
Burn it with fire. Or bury it in the desert. Wear gloves.