[HN Gopher] Detailed audit of Voatz' voting app confirms securit...
___________________________________________________________________
Detailed audit of Voatz' voting app confirms security flaws
Author : rbanffy
Score : 143 points
Date : 2020-03-20 17:54 UTC (5 hours ago)
(HTM) web link (www.govtech.com)
(TXT) w3m dump (www.govtech.com)
| zyxzevn wrote:
| I wish it could be safe, but real electronic voting fraud may be
| far more common in practice:
|
| https://www.youtube.com/watch?v=zsNXnAv131g Computer Programmer
| testifies that Tom Feeney (Speaker of the Houe of Florida at the
| time, currently US Representative representing MY district )
| tried to pay him to rig election vote counts.
|
| Usually they can be detected when exit polls differ from the
| voting results. But that seems common nowadays. So that is why I
| think that voting fraud may be common.
|
| But back to the whistleblower.. How many have accepted the money?
| And how many of them are able do some underhand programming?
| Sometimes just to leave small security holes.
|
| I don't think that MIT can detect them that easily. For a long
| time we did not even know the NSA encryption was compromised by
| NSA themselves.
| aazaa wrote:
| The biggest problem with Voatz is that it's selling silicon snake
| oil to people who can't evaluate claims.
|
| It starts with the premise that somehow Blockchain does something
| magical. That is enables special security.
|
| Claims like this are a load of crap.
|
| What Bitcoin did, and what hucksters like Voatz are trying to
| cash in on, was to make it provably difficult to write a public
| record. In doing so, Bitcoin created provable digital scarcity
| (subject to certain well-known assumptions) for the first time in
| human history.
|
| Voatz picks out the cryptographic part as if it were somehow
| separable from the proof of work part. The two are not separable.
| Voatz, and the fools who are using it, have much bigger problems
| than "improper use of cryptographic algorithms."
| fastball wrote:
| I mean, the crypto part that isn't PoW is mostly just PKC,
| which actually does make sense for voting.
| ben_w wrote:
| Wait, is this the origin of https://xkcd.com/2030/ ?
| darawk wrote:
| Should we change the link to point directly to ToB's blog post?
|
| https://blog.trailofbits.com/2020/03/13/our-full-report-on-t...
|
| It seems a lot more information rich.
| mspecter wrote:
| Oh, hi.
|
| I'm Mike Specter, lead author on the MIT report [1], and have
| been involved in other voting-related research projects [2,3].
|
| LMK if you all have any questions!
|
| 1. https://internetpolicy.mit.edu/wp-
| content/uploads/2020/02/Se...
|
| 2. http://people.csail.mit.edu/rivest/pubs/PSNR20.pdf
|
| 3.
| https://www.belfercenter.org/sites/default/files/files/publi...
| munk-a wrote:
| Within the article this statement was made
|
| > Trail of Bits engineers said Voatz' code was written
| intelligibly and free of many common security foibles, but
| added "it is clear that the Voatz codebase is the product of
| years of fast-paced development." The summary goes on to list
| several technical flaws, such as a lack of test coverage and
| documentation, infrastructure provisioned manually without the
| aid of infrastructure-as-code tools, vestigial features that
| have yet to be deleted, and nonstandard cryptographic
| protocols.
|
| That honestly sounds pretty good in terms of software quality,
| adding additional tests for proofs and ramping up ops are both
| addressable problems - especially if handled by a government
| sponsored team. But...
|
| How confident are you that we could reach a well engineered and
| proofed electronic voting platform that also adheres to
| theoretical rules around vote security?
|
| And which component of that, adherence to theoretical
| requirements and perfected development practices, do you see as
| a larger hurdle to overcome going forward?
| mspecter wrote:
| > How confident are you that we could reach a well engineered
| and proofed electronic voting platform that also adheres to
| theoretical rules around vote security?
|
| I don't think we can with the current commodity devices /
| ecosystem, even assuming that voting system software is well-
| written. Keeping electronic-only systems secure from nation-
| state level adversaries is hard.
| micimize wrote:
| I understand that current solutions to electronic voting are
| unsatisfactory, but I am fairly baffled by:
|
| > It remains unclear if any electronic-only mobile or Internet
| voting system can practically overcome the stringent security
| requirements on election systems
|
| Like, we can adequately secure banking software. With proper
| considerations and processes for the problem domain (i.e. user
| follow up / validation, alerts on suspicious vote changes) I
| don't see why securely implementing electronic voting is
| considered near-impossible, and has so few advocates.
| roywiggins wrote:
| Many bank transactions can be reversed, and the ones that
| can't can be covered by insurance or self-insurance. You
| can't _practically speaking_ reverse a tainted election.
|
| Anyway, I'll let Tom Scott take it:
| https://www.youtube.com/watch?v=LkH2r-sNjQs
| rodgerd wrote:
| > Like, we can adequately secure banking software.
|
| We really can't. Banking is riddled with fraud, and I say
| that as someone who works in banking and has designed online
| banking software. Even with continually ratcheting up
| security in banking software, use of MFA, encouraging
| customers to more-secure platforms (Android/iOS), fraud
| detection (various approaches on the back ends, edge, etc),
| fraud through online applications is many orders of magnitude
| higher than fraud in traditional voting systems.
|
| It doesn't matter so much in banking because we can (and do)
| give customers their money back. We can't fix a broken
| election.
|
| And that's before we get into the way online voting
| completely fucks election practises around vote buying,
| coercion, etc.
|
| I wish people who think they understand computers and are
| clever would actually make the effort to learn something
| about either domain before saying stuff like this. It's very
| disappointing.
| mspecter wrote:
| To put this in short-hand: "We bank online, we buy all sorts
| of stuff online, why not vote?"
|
| The biggest reason is that banking and other financial
| transactions have a very different threat model from voting.
|
| In particular, voting requires a _secret ballot_. In addition
| to preventing an adversary from learning how you voted, a
| secret ballot requires you to be unable to prove how you
| voted, to prevent vote selling and coercion.
|
| So, unlike financial transactions, how you do validation /
| remediation of failures is very unclear. Ben Adida has a blog
| post with further thoughts here
| (https://benlog.com/2007/03/02/on-voting-banking-and-bad-
| anal...).
| micimize wrote:
| Hmm, I hadn't fully grokked the facet of the problem
| domain. I guess you could give users a spoofing mode, that
| allowed them to fake any ballot / action. Or possibly, if
| there was a window of time in which they could change their
| ballot freely.
|
| Maybe making such features both secure and accessible would
| be nearly impossible though.
| insomniasexx wrote:
| We can't secure banking, there are just a lot of undo
| processes, holds, and internal processes and cross-comms that
| make it so people don't lose all their money all at once and
| potential losses can generally be reversed, insured, bailed
| out, covered by someone else, or balanced out / hedged
| against. Even with that, fraud is rampant and heists worth
| billions do still occur digitally[1]. And these are financial
| systems that evolve constantly over centuries at this point.
| And the attackers still win sometimes.
|
| The biggest thing the measures do is significantly decrease
| the known ROI on a target. For example, a credit card can be
| cancelled. Even if the bank doesn't notice and the person
| doesn't notice and you do get 100k off it, the fact attackers
| _don 't know that_ still reduces the value of the stolen
| credit card and therefore the incentive to steal them.
| Further the gain of 100k by an attacker may be split amongst
| cardholder, card issued, insurance, merchants, etc. so no one
| person actually loses 100k. These things all matter when
| building and securing new systems.
|
| If you look at the cryptocurrency space in general, you can
| see what happens when you replace a credit card or swift with
| transactions that are similtaneously immutable, very
| valuable, and easily anonymous enough. The monetary value on
| anyone's Coinbase account, let alone all the Coinbase
| accounts, is so high that we've seen attacks[2] usually
| reserved for nation-state actors and by actual nation state
| actors[3], including sophisticated + targetted zero-days and
| bgp hijacks and all sorts of fun stuff. Not to mention the
| very high density of attacks that require lower effort and
| talent like sim swaps, phishing, spear-phishing,
| impersonation, typosquatting, on and on.
|
| Regardless, if the potential gains to hack a bank are level
| 1, and crypto exchanges or private keys are a 10, then voting
| is 1,000,000.
|
| The zero-sum nature of winning an election coupled with the
| potential gains from doing so are so large and so
| unfathomable that we have to assume that the lengths people
| will go to are unfathomably more than everything else we've
| ever tried to secure. Bc if you can gaurentee a win for a
| candidate or choose the candidate or change the candidate,
| you can do anything. You can own anything. You can control
| anything. You can make any amount of money. The limit is only
| your talents, abilities, moral compass, and appetite for
| risk.
|
| To protect against a huge number of attackers, including
| nation state ones with essentially unlimited resources and
| the incentive to use those unlimited resources is...it's
| never been done. Again, back to Coinbase, they secure their
| crypto with...wait for it...paper. Generated and printed
| using randomly chosen, single-time, fully-airgapped machines.
| In a random location. In a Faraday cage.[4] That's how you
| secure billions when you don't have an undo button. With
| paper. While not even trusting the electricity flowing thru
| the cable.
|
| As we saw in the 2016 election, Brexit, and lesser know
| elections across the globe, it takes _very_ little to secure
| a win. With the right data (which is even more accessible
| today than it was in 2016) you only need to manipulate
| relatively small amount of voters. I 'm too lazy to look it
| up but the numbers were insane when you looked at who was
| targeted by VoteLeave and Trump's campaign. They may have
| served 40m ads but it was only to like 40k people.
|
| _And that wasn 't hacking anything._ And those were huge-
| scale elections. And we still don't know who gained what from
| their outcomes, just that a lot of people spent a decent
| amount of money and a huge amount of effort to do so. And it
| wasn't selfless.
|
| Small towns make gains more obvious. If small town mayor
| decides who gets the contract for building the new 10M town
| hall and if you can build it for 5M, you have 4.9M to spend
| on winning that contract. (Well 5M - resources to rig
| election - gain required for you to take the risk and put in
| the effort.) And, given the size of government contracts and
| their ongoing nature, the financial gains alone are massive.
| Military contractors: trillions and trillions.[5]
|
| Even securing a single contract early on can ensure your
| success down the line. Maximus handles tons of Los Angeles
| welfare programs and now all sorts of programs around the
| globe. They have for 40+ years. They have billions in annual
| revenues from doing so. E.g. "In September 2012, the Illinois
| Department of Healthcare and Family Services awarded Maximus
| Health Services a two-year, $76.8 million contract to help
| the state with its Medicaid program. That same month, Maximus
| announced a $23.5 million contract with the State of
| Oklahoma."[6] Most of these contracts are decided not by the
| president but a random group of 5-7 officials at a meeting no
| one knows about where there is no competition and no real
| discussion.
|
| Again, these are just a few very, very, very simple
| incentives people have to manipulate votes. Again, go look at
| 2016 Trump election or Brexit in depth to understand truly
| what is currently known about the number of people and the
| lengths they went to to get an election won. Without hacking.
| Check back in 40 years after more details emerge. We just
| don't even know yet.
|
| The reason I have zero faith in any tech being successful in
| the nearish term with regards to voting is not that I think
| programmers suck or that politics is corrupt. It's that it's
| truly unprecedented on an incentives level and risk level.
| And, it's not just that the risk and potential loss for
| society or potential gain for attackers is so huge, it's also
| that we don't even know what it is, and even if we did, we
| wouldn't be able to comprehend it. How do you secure that
| when that's what you're up against?
|
| The scope of what we _do know_ about banking fraud, crypto
| fraud, and paper voting fraud is so great and we are always
| one step behind attacks and mitigate risk in millions of
| little ways because we can 't fully reduce it. But you can't
| hedge against election fraud. There's no insurance. There's
| no undo button. There's no time travel.
|
| And that means that, very unlike financial services, the
| amount you have to spend to secure an app of this nature is
| actually one resource more than the attackers are willing to
| spend to get their way in an election. Or one resource less
| than the amount lost if an attacker wins. But what even is
| the value of people, our future, our literal lives? Society,
| war, money, peace, contracts, the fed, interest rates, all
| the markets, all the debt, n95 masks, new buildings, old
| buildings, corruption, legitimacy? We can't know which of
| these attackers are going after therefore you have to protect
| against all. And there literally isn't enough resources in
| the world for that.
|
| Zooming back down to simple: there isn't enough money to even
| secure an app for a single small town that has a single
| contract for $10M and will never have another contract and
| there is, impossibly, no other possible gain for rigging the
| election. I mean, there literally is enough money. But why
| spend $1M or $2M or $5M on that app? Why even spend a dollar?
| Why do so when it doesn't actually reduce all the other risks
| of election manipulation and corruption that are currently in
| practice while adding a whole new variety of known and
| unknown attack surfaces and exacerbates existing ones? You
| wouldn't. Period.
|
| Why would a company try to build an app knowing this? Well,
| either they're optimistic and altruistic as fuck and don't
| know it. Or, second, they are taking advantage of you. Or,
| third and most terrifying, is the act of building a voting
| app itself is actually the way to rig the election.
|
| Voatz, without a shadow of a doubt, is not the first. Perhaps
| the second. But the third? When you consider the timing of
| Voatz' fundraise, who they raised money from, the goddamn
| timing, the fact they didn't die when it was discovered they
| were using old ass php and plesk in 2018, and the fact the
| app is actually still this fucking completely worthless and
| insecure and hasn't improved, well, I can't say that it's
| _not_ an attempt to rig an election but it 's def not the US
| who's doing the rigging. They would go to far greater
| lengths.[7]
|
| ---
|
| 1: https://en.wikipedia.org/wiki/Bangladesh_Bank_robbery or
| great podcast on it for audio lovers
| https://www.stitcher.com/podcast/mugshot-podcast/mugshot
|
| 2: "Responding to Firefox 0-days in the wild" by Philip
| Martin https://link.medium.com/x8tNj2rc14
|
| 3: https://blog.chainalysis.com/reports/cryptocurrency-
| exchange...
|
| 4: https://www.wired.com/story/coinbase-physical-vault-to-
| secur...
|
| 5: https://247wallst.com/special-
| report/2019/02/21/20-companies...
|
| 6: https://en.wikipedia.org/wiki/Maximus_Inc.
|
| 7: https://archive.nytimes.com/www.nytimes.com/interactive/20
| 13...
| dmix wrote:
| The article mentions:
|
| > The clients do not interact with the blockchain directly, so
| there is no blockchain verification code in the client.
|
| So if all client requests are routed through the same
| centralized API endpoint before hitting the blockchain, nor
| validated after the fact, whats the point of the blockchain?
| Just some public "ledger" of what the server ultimately sends
| out?
|
| Ideally, at a minimum, you would be given a token for your vote
| which you can then follow up and see it on the ledger. Even if
| you don't get to wait for 'confirmation', it's still a public
| signal that something is not right.
| mspecter wrote:
| That's a wonderful question.
|
| The honest answer is that I have no idea. In the version we
| reverse engineered, there's no proof of inclusion of any of
| the data in the blockchain in the client, and the receipt
| system was via a PDF. The vote selections (ballot?) are also
| never signed by the client.
|
| It's also worth noting that, according to the ToB article,
| the backend blockchain is a permissioned hyperledger
| instance, which runs PBFT[1] rather than proof of work. PBFT
| is controllable with roughly 1/3 of the network, 100% of
| which has been controlled by the company.
|
| [1]http://pmg.csail.mit.edu/papers/osdi99.pdf
| the_snooze wrote:
| Is there any technical/security benefit at all to private
| blockchains? Or even more generously, lightly-mined public
| blockchains? It seems that in either of those scenarios,
| you lose the decentralized validation and consensus brought
| about by a bunch of people incentivized to compete with one
| another to burn electricity.
| nordsieck wrote:
| > Is there any technical/security benefit at all to
| private blockchains?
|
| It really depends on what you want out of your
| blockchain.
|
| For example, the backend of git is essentially a
| blockchain. It's extremely useful, even for a solo
| developer.
| mspecter wrote:
| To push this further, I was working on a research paper
| with Ron Rivest, Neha Narula (head of MIT's decentralized
| currency initiative), and Sunoo Park (a wonderful applied
| cryptographer) on whether blockchains _in general_ could
| be helpful in casting and tallying.
|
| We're skeptical.
|
| See: http://people.csail.mit.edu/rivest/pubs/PSNR20.pdf
| eyegor wrote:
| But if everyone used a public blockchain, with proof of
| work + user-level signatures for each vote cast, wouldn't
| it be far more auditable than any current system?
| Ignoring implementation details, reaching a point where
| anyone could have a way to audit that their vote was
| counted (correctly) seems very useful. Using this sort of
| model, it theoretically wouldn't matter who completes the
| proof of work as long as the results are audited.
| [deleted]
| smacktoward wrote:
| _> whats the point of the blockchain?_
|
| My bet would be: marketing. Blockchain is hot, blockchain is
| sexy -- at least among people who aren't really technically
| inclined. (The technically inclined passed over the
| blockchain hype curve several years ago.)
|
| There are tons of blockchain projects out there whose only
| real use for the blockchain is to be able to slap "now with
| blockchain!" on the sales materials.
| save_ferris wrote:
| > The summary goes on to list several technical flaws, such as a
| lack of test coverage and documentation, infrastructure
| provisioned manually without the aid of infrastructure-as-code
| tools, vestigial features that have yet to be deleted, and
| nonstandard cryptographic protocols.
|
| I'm not a security engineer, so what's the benefit of using a
| nonstandard cryptographic protocol? That decision makes no sense
| to me.
| jimbob45 wrote:
| I'm not sure that infra-as-code belongs on that list.
| geofft wrote:
| IMO it's a security problem in practice - it means that you
| have a lot of organizational resistance to doing things like
| regular software updates, because you end up with this one
| server that's been hand-crafted that people are too scared to
| touch. Or, analogously, if you want to introduce some new
| sort of authentication/auditing/etc. protocol to the system,
| people will worry that they won't be able to find every use
| of the old thing and won't make the new thing mandatory. It
| also means that it's a lot harder to test changes, because
| you don't know what you need to set up to get a full test/QA
| environment going.
|
| It's not a vulnerability in itself, but the fear/stop energy
| created by artisanal small-batch infrastructure is a good way
| to set yourself up for vulnerabilities being exploitable.
| (See, for instance, Equifax being hacked by a two-month-old
| Struts vulnerability - you can theoretically argue that
| Equifax is a big company and should carefully audit their
| dependencies, but a much more practical argument is that
| Equifax should have been ready to patch within days, at most,
| of the vulnerability being announced.)
|
| The actual ToB report identifies another reason which I
| didn't think of:
|
| > _Ensure that all backend infrastructure is re-provisioned
| between elections and not shared between elections /clients.
| Each server should also receive its own unique SSL
| certificate and credentials. Use infrastructure-as-code tools
| like Ansible and Terraform to automate and manage
| provisioning._
|
| Apparently there are two concrete problems:
|
| 1. All Voatz backend servers share a single wildcard
| certificate, and they think that automated provisioning would
| reduce the incentive to do things like this.
|
| 2. Every Voatz election uses a custom iOS/Android app
| delivered via TestFlight / Google Play Beta, because of some
| design choices in the protocol related to having a single
| shared backend (S3, MongoDB, etc.). They think that if there
| were infrastructure-as-code for the shared backends, it'd be
| easier to provision one instance per election and easier to
| make the client change to use a single client for each
| election, blocking potential attacks on the page that links
| you to the sideloaded app.
| nijave wrote:
| It also enhances auditability since you can keep a record
| of all changes in code and run the tooling to see if
| resources are changing outside of how they were configured.
| Without those tools, you'd have to develop your own to
| meaningful ensure infrastructure is setup correctly (it's
| not practical to hand inspect hundreds or thousands of
| small components)
| [deleted]
| eyegor wrote:
| There's benefit when working in low-security environments. A
| custom crypto model will make your process harder to understand
| by a reverse engineer. This adds some security by obscurity,
| but almost certainly weakens actual security.
|
| Let's say you just want to store and restore data on a user's
| computer, but want it to be difficult to read by an outside
| program. In this scenario, using an established algorithm makes
| it easier to decipher your encoding, and by nature if the
| encryption and decryption happens on the user's machine then
| you have to store the public and private keys on the user's
| system. There's no other way to accomplish this task if offline
| is a requirement. So in this case, obscurity has value in
| deterring reverse engineers.
| jerf wrote:
| "I'm not a security engineer, so what's the benefit of using a
| nonstandard cryptographic protocol?"
|
| Broadly speaking, the benefit is that if you have a keyhole
| view of the crypto world, you can google this and stackoverflow
| that online and get something that to your eyes appears simpler
| than using correct crypto, because correct crypto worries about
| keys, and revocation, and the keys are in a weird mix of
| formats, and certificates are complicated and have all these
| features you don't seem to need, and support for them is more
| mixed and less widely available than you'd like. Your simpler
| crypto seems to work, and it might be "faster", and it was
| easier to bash together one function that "uses" AES directly
| and puts out a stream that "looks encrypted" than it is to
| worry about all the things it takes to use crypto correctly.
|
| None of that is sarcastic; especially if you don't stumble upon
| libnacl or some other library designed to be easy to use while
| still being correct, using crypto correctly is actually a good
| deal harder than misusing a couple of primitives to get
| something that superficially works. I mean, again no sarcasm,
| you can figure out how to bash something together with AES256
| primitives faster than you can even figure out how to run a
| too-simple-for-your-needs Certificate Authority, which even if
| you do Google up the right scripts is still annoyingly
| difficult in my experience. And that's only a single element of
| what you may need to do for your app to be secure.
|
| In terms of any other sort of advantage, there basically isn't
| one. It's the above advantage that is why we keep seeing home-
| grown crypto all the time.
|
| Now, getting your use of the crypto primitives _correct_ is
| much harder than getting your use of existing solid libraries
| correct. Unfortunately, misused crypto doesn 't usually crash
| or segfault or fail visibly; it still produces binary gibberish
| visually indistinguishably from the binary gibberish solid
| libraries will produce. It just turns out to be low-quality
| gibberish that won't secure you or your users. But no
| segfaults, crashes, errors, warnings, etc.
| spatley wrote:
| The only reason to use nonstandard crypto is that you think you
| are smarter than the entire crypto industry. ProTip: you are
| never smarter than the entire crypto industry.
| bnonhacker wrote:
| Fully agree. That's the primary issue associated with
| bringing a piece of critical civic infrastructure, such as
| voting, into the digital domain. Who builds, maintains and
| secures the tech? Certainly not the government. The govt only
| acts as a collective entity to support and promote strong
| tech-driven markets (it should at least in theory). I do hope
| that more individuals in the crypto industry get involved
| politically because of their technical wherewithal.
| kache_ wrote:
| You forgot the other reason: backdoors
| orthecreedence wrote:
| > The clients do not interact with the blockchain directly, so
| there is no blockchain verification code in the client.
|
| Fun. So, why even use a blockchain? Why not at least have light-
| clients with merkle verification? Does Fabric not have support
| for light clients (I haven't looked at it in a while)?
| JshWright wrote:
| "Why even use a blockchain" is the first question that should
| be asked of any company that advertises they use one. Most of
| the time it's also the last question you'll need to ask...
| roywiggins wrote:
| For marketing.
| cies wrote:
| Have my vote printed to a roll of paper, like a cashier's counter
| roll. Make sure that it shows through an opening in the case, so
| I can verify, and then rolls further (beyond the opening) so I
| cannot see it anymore. This is a way to store the votes "write
| only". The rolls are both human readable and machine readable
| (OCR is nothing new).
|
| The only problem with this compared to voting forms is that form
| fall into the bin unordered, so it is harder to link a vote to a
| person.
|
| Just an idea.
|
| I would not trust ANY system that stores my vote on a re-writable
| storage medium. I know there are some crypto/blockchain tricks
| that may help, but that's so hard to audit for lay people that I
| prefer the paper roll any day.
| henrikschroder wrote:
| > The only problem with this compared to voting forms is that
| form fall into the bin unordered, so it is harder to link a
| vote to a person.
|
| Uh, that's a _good_ thing, you don 't want to be able to link a
| vote to a person at all!
| lippel82 wrote:
| That's why he said it was a problem.
| henrikschroder wrote:
| Ah, I misunderstood what he was saying! I read it the other
| way around. Thanks!
| r00fus wrote:
| Can someone confirm to me why we need voting "apps" or why voting
| needs to be electronic at all?
|
| Vote in person by pen & paper or vote via mail remotely.
| Tabulation also should be done locally and in-person with
| representatives of all parties present.
|
| Anything else seems ... like a way to more easily steal
| elections.
| pbhjpbhj wrote:
| It would be great, IMO, if electronic voting was cracked so
| that voting could be made cheaper and thus be used for more
| direct democracy.
| charonn0 wrote:
| Cheaper for us means cheaper for attackers too. Sometimes
| inconvenience and inefficiency are features.
| crooked-v wrote:
| I live in Oregon where everything is vote-by-mail, and on the
| whole it works great. Each ballot is basically a generic
| survey-style scantron form and dead simple to fill out (fill in
| the circle next to your choice, or next to the blank line and
| write in a candidate), as of this year no postage is required
| so the only cost to the voter is a pen or pencil, and voters
| without a mailing address can register to pick up a ballot at
| the county elections office and can then drop off that ballot
| at any post office or in one of the drop boxes at libraries and
| public squares.
|
| It also has overwhelming bipartisan support (>75% among both
| Democrats and Republicans) and results in turnout well above
| most of the country (63% in 2018 midterms compared to 49% for
| the US as a whole).
| hombre_fatal wrote:
| Well, consider how many people just aren't going to be bothered
| to ever register and vote which is the majority of my friends.
| The amount of effort plays directly into the "meh, not like my
| vote matters anyways" mindset.
|
| "Oh well, they don't deserve to vote then" might sound good to
| you, but only if you tend to agree with what people currently
| vote for.
| jonwachob91 wrote:
| Page 1 of the report:
|
| >>> "While the introduction of Internet voting in the U.S. is
| relatively new, the history surrounding electronic only voting
| is not. In the wake of counting errors, recount discrepancies,
| and uninterpretable ballots wreaking havoc during the 2000 U.S.
| Presidential race, Congress passed the Help America Vote Act
| (HAVA) [49], a bill targeted toward helping states move away
| from outdated and problematic punchard-based systems."
| r00fus wrote:
| HAVA was a disaster and resulted in all sorts of problems
| with what should be a basic printout + pen solution.
|
| Other countries do that, and all attempts to "automate" or
| improve the UI of voting introduce all sorts of problems.
| NikolaeVarius wrote:
| >> The promises of mobile voting are attractive--better
| accessibility for differently abled people, streamlined
| absentee voting, and speed and convenience for all voters. If a
| mobile platform could guarantee secure voting, it would
| revolutionize the process. It's a fantastic goal--but there's
| still work to do.
| r00fus wrote:
| This is still relevant: https://xkcd.com/2030
| sandov wrote:
| > If a mobile platform could guarantee secure voting, it
| would revolutionize the process.
|
| They'd have to give each voter some sort of voting device
| with a screen, buttons and wireless connectivity, and make
| sure that the voter doesn't lose it so that it can be reused
| for the next election, or buy these devices each election.
| Too much trouble.
| henrikschroder wrote:
| > If a mobile platform could guarantee secure voting
|
| First, that's a mighty big if, and second, it's not enough!
|
| Voting is a process where unlike online banking or online
| shopping there is no way for a human to go in and fix errors,
| there's no way to audit a vote and go "Oh, Bob meant to vote
| for A and Cindy meant to vote for B, so the machine did it
| wrong". It's not enough that an electronic voting system is
| correct, every single voter has to be able to trust the
| system, and for that it needs to be simple to understand.
|
| You can't look at the electrons inside a silicon chip to
| determine they're doing the right thing. But with pen and
| paper and envelopes and urns and observers and counters, you
| _can_ determine that the system is doing the right thing.
| Involving lots and lots of citizens in the voting system is
| not a bad thing, quite the opposite! You _want_ as many eyes
| as possible on the entire process to ensure there 's nothing
| shady going on, that there's no mistakes.
|
| But if all the votes go into a black box that spits out the
| results, all of that goes away, all of that trust, all of
| that ability to verify that the results are correct.
| aneutron wrote:
| So I'm halfway through the report, it's a very beautiful
| document, great work from the team that wrote, and if I
| understood correctly, a VOTING application:
|
| - Uses ad-hoc cryptography as the main cryptography
|
| - Does not use the recommended security facilities on the target
| platforms (iOS and Android)
|
| - Is deployed manually, with hardcoded secrets (AWS account with
| name "admin" had its credentials hardcoded in a scala file named
| "AmazonOtpUtility.scala")
|
| - Has provably de-anonimizablity as a property (All is needed is
| apparently access to the databases, and might I remind you of the
| Twitter / UAE/Saudi Arabia recent story)
|
| - (And this is the biggest, most annoying thing) Is not end-to-
| end verifiable.
|
| - The actual threat model is almost childish, as showed by the
| testing team.
|
| I do apologize for the wording in the following paragraphs, but
| this a fucking dumpster fire of a project for a voting platform.
|
| Who the fuck authorized this to go forward as a voting platform
| for any state in the United States ? Who the fuck is selling this
| as a "secure" platform ? Can they sleep well at night ? When will
| the government intervene and stop people from compromising
| democracy with stunts like these ?
| gok wrote:
| Electronic voting is difficult because it's politically
| undesirable to many people who benefit from dead tree voting, not
| for any technical reason. So yeah, of course people claiming to
| solve a political problem with technical buzzwords are almost
| certainly selling snake oil.
| charonn0 wrote:
| > it's politically undesirable to many people who benefit from
| dead tree voting
|
| Who supposedly benefits?
| roywiggins wrote:
| My personal audit went like this: "It's called Voatz, with a _Z_.
| "
| mandelbrotwurst wrote:
| It's got what plants crave!
| tprynn wrote:
| Copying comment from previous thread:
|
| Systemic issues:
|
| * Creds scattered throughout source code, including DB / AWS
| creds, "fixed" by removing but still present in git history
|
| * Numerous crypto vulns: nonces / AES-ECB
|
| * What's even the point of blockchain, it just makes everything
| worse
|
| Selected quotes:
|
| "Trail of Bits was only provided a backend for live testing on
| the second-to-last scheduled day of the assessment"
|
| "The system is unusually complex, with an order-of-magnitude more
| custom code than similar mobile voting systems we have assessed."
|
| "Voatz's voting processes are error prone and manual, relying on
| manual verification of voter identity and long-term storage of
| this identity on Voatz's premises"
|
| "E2E-V systems allow voters to cast encrypted ballots such that
| ballot counts are verifiable to anyone, but individual voters'
| preferences are not revealed. ... Voatz is not E2E-V."
|
| "Storing voting data on a blockchain maintains an auditable
| record to prevent fraud, but this comes at the expense of both
| privacy and increased attack surface. Clients do not connect
| directly to the blockchain themselves, and are therefore unable
| to independently verify that their votes were properly recorded.
| Anyone with administrative access to the Voatz backend servers
| will have enough information to fully reconstruct the entire
| election, deanonymize votes, deny votes, alter votes, and
| invalidate audit trails."
___________________________________________________________________
(page generated 2020-03-20 23:00 UTC)