John McAfee's 'Unhackable' Bitfi Wallet Got Hacked -- Again (techcrunch.com)

Earlier this month, computer programmer John McAfee released "the world's first un-hackable storage for cryptocurrency & digital assets" -- a $120 device, called the Bitfi wallet, that McAfee claimed contained no software or storage. McAfee was so sure of its security that it launched with a bug bounty inviting researchers to try and hack the wallet in return for a $250,000 award. Lo and behold, a researcher by the name of Andrew Tierney managed to hack the wallet, but Bitfi declined to pay out, arguing that the hack was outside the scope of the bounty. TechCrunch is now reporting that Tierney has managed to hack the Bitfi wallet again. An anonymous reader shares the report: Security researchers have now developed a second attack, which they say can obtain all the stored funds from an unmodified Bitfi wallet. The Android-powered $120 wallet relies on a user-generated secret phrase and a "salt" value -- like a phone number -- to cryptographically scramble the secret phrase. The idea is that the two unique values ensure that your funds remain secure. But the researchers say that the secret phrase and salt can be extracted, allowing private keys to be generated and the funds stolen. Using this "cold boot attack," it's possible to steal funds even when a Bitfi wallet is switched off. Within an hour of the researchers posting the video, Bitfi said in a tweeted statement that it has "hired an experienced security manager, who is confirming vulnerabilities that have been identified by researchers."

Comments

Ha Ha /Nelson

[OzPeter]

What more can you say?

Re: Ha Ha /Nelson

[Desler]

How much meth had he taken before making that proclamation?

Talk is cheap. Almost as cheap as lying.

[Jogar the Barbarian]

What's the point of advertising bounties if you don't honor them?

Re:Talk is cheap. Almost as cheap as lying.

[bickerdyke]

What's the point of advertising bounties if you don't honor them?

Keeping the money. Which makes much more sense if we're talking about your money....

Re:Talk is cheap. Almost as cheap as lying.

[Duds]

Especially as you'll need that money to pay off all the users who sue you after they're hacked.

Re:Talk is cheap. Almost as cheap as lying.

[Desler]

McAfee probably spent the money on bath salts and couldn't pay out.

Re:Talk is cheap. Almost as cheap as lying.

[Anonymous Coward]

Sounds like it's time for a class action lawsuit by the people who bought this device.

Both of them!

No software and no storage?

[bickerdyke]

No software and no storage?

How is it supposed to store and encrypt anything?

Is that the same McAfee who got stuck on some bad drugs a while ago and was in the news for some statements of similar sanity?

Re:No software and no storage?

[Anonymous Coward]

yep, it's the same McAfee that was wanted for questioning by Belize law enforcement about the murder of his neighbor a few years ago. He fled the country claiming the Belize government was setting him up. He's also been accused of committing rape while in Belize, and just last year he fired several shots at the walls and floor of his residence while his wife was there because he thought the Belize government agents were there to kill him.

The guy is a dangerous drugged out loon.

Re:No software and no storage?

[bluefoxlucid]

Yes. It's the kind of confused ideal you get out of a lunatic with a large ego.

I've been working on electronic voting machines and high-integrity elections. Do you know what that takes? You publish the image ahead of time; you image the machines at poll open while people observe, and then let them copy the read-only media to verify no tampering; you generate vote count statistics on the machines before copying the votes off to send them up to the board, ensuring we can all verify that the ballots observed are the ballots reported.

That narrows the window of attack to the time between poll-open and poll-close. As long as you have public observers during that time, nobody can tamper with the machines. You have non-repudiation of the software, the machine's initial state, and the ballots as cast.

If you have no public observers, then bought-off election staff can enter the machines when nobody's around and modify the vote counts or the software loaded.

I'm building on a model of using EVMs to encode ballot sheets onto smart cards, then take the smart card to an electronic ballot box which displays the ballots and allows you to cast them.

The touch interface exposes approximately zero attack surface. You're putting boxes in order (ranked votes) or checking boxes. Besides that, separating the ballot box ties the entire attack surface to clicking "Accept" or "Reject" and to reading the data on the smart card.

The ballot box itself has to deal with the smart card.

That's tricky. On one hand, I can definitely validate input data and protect from smart card attacks: there will be no hacking by using a tampered smart card. On the other, someone could load a smart card with forged data and just stuff votes--which the vote count display overhead is supposed to prevent (one person goes in, count increases several times), but then what? Election judge comes in and voids the prior X ballots cast? We now have a method to edit votes during the election?

We could have each EVM create a Curve25519 key pair and put the certificate onto a smart card, which we then copy into the ballot box. Once we confirm all machines are set up, that's it: no more keys added, no more EVMs can send votes. The small strip of data on the smart card has a cryptographic signature.

Now: is your Ed25519 signature verification library vulnerable to attack by giving a bad encrypted signature?

Fortunately, we can audit these code paths heavily. They're small. They can perform strong validation. It's possible to guarantee you can't hack the ballot box by tampering with a smart card because only the EVMs have the encryption keys generated that morning (on the EVMs themselves) to sign the smart cards.

So long as you don't have a wireless chip (bluetooth/wifi), don't plug it into any kind of network, and don't let anyone physically tamper with the machine during voting, it's unhackable.

You have to remove the attacker to make it unhackable. If someone can attack it, you have no way to guarantee they can't successfully attack it.

Why do you think I worry about the signature verification code path? That's the single uncontrolled attack vector. The defense there is to "make sure that 30 lines of code is correct". Cringe.

People with incredible hubris declare they have made an unhackable Network server or keychain device; then they get swarmed by gremlins prying into every seam they can find.

Re:No software and no storage?

[Anonymous Coward]

It uses a special cryptographic bath salt to generate totally insane random numbers

Re:No software and no storage?

[Immerman]

How about ""hired an experienced security manager, who is confirming vulnerabilities..."

If you're trying to make the world's first unhackable device, how exactly is such a person not already a primary member of your team?

Re:No software and no storage?

[iserlohn]

Not only that, they seem to be missing the basics of PR. How hard is it to phase it as - "We have hired an external security expert to independently verify the reported vulnerabilities" ?

Re:No software and no storage?

[dissy]

Not only that, they seem to be missing the basics of PR. How hard is it to phase it as - "We have hired an external security expert to independently verify the reported vulnerabilities" ?

Apparently about as hard as saying they will pay the bug bounty as promised.

Not that I would suggest anyone carry out this (probably illegal) action, but it would be pretty hilarious if this story ended instead with:
"TechCrunch is now reporting that the researcher has managed to hack the Bitfi wallet again, this time extracting the exact amount of the bug bounty from McAfee's own funds"

Re:No software and no storage?

[Immerman]

What if the your smart card is corrupted in such a manner as to exploit a flaw in your data-reading routines to corrupt the software itself? That's a notoriously vulnerable attack surface right there - we're *still* finding new ways to compromise data loading routines for common formats that are decades old, though you could hopefully simplify the format to . Heck, the smart-card formatting itself could be corrupted, attacking through the OS instead of the voting software. (Though I find it unconscionable that any voting machine would incorporate the huge attack surface of an OS in the first place)

> which the vote count display overhead is supposed to prevent, but then what?
Then you know you have a problem. Just because an acceptable solution isn't readily apparent is no reason to avoid exposing the fact that your system has been compromised. If you want a high-integrity anything, the first responsibility is to do everything you can to ensure that any tampering is revealed. Dealing with it suitably is whole second problem.

Though - here's a possibility: the oversight officials have to push a "commit" button periodically to commit the last N temporarily recorded votes to the permanent record - or a cancel button to invalidate them. So long as that's done while the last N voters are still physically present they can recast their votes while the perpetrator is being arrested. They just need to stick around until they've confirmed their vote is committed.

Really though - why are you trying to do electronic voting at all? What _exactly_ is the point? As far as I can tell it's just a way to radically weaken an important civil institution in order to add some high-tech glitz. Paper ballots are unhackable, easy to use (unless designed deceptively - and that's easy to prevent by requiring them to, for example, be approved by a jury), and there are some extremely clever designs out there that manage to incorporate anonymity, verifiable end-to-end confirmation receipts, and the inability to prove to anyone else how you voted. Heck, mail out ballots beforehand and let people just drop them off for validation and eventual counting - they can take all the time they need, and voting proceeds quickly at the polling pace since all most people need to do is feed it through the validation scanner.

It's *far* easier to secure a physical ballot box, and doesn't take that long to count - especially since the volunteer pool for vote counters is directly proportional to the number of voters - just give everyone a 1% chance of being flagged for vote-counting duty and you could get the votes counted in a few minutes. Ideally votes should be counted at the polling place, immediately after the polls close. Or possibly even in several shifts throughout the day - every hour or two a new ballot box is put out and the old one gets counted - that should still be anonymous enough, and it would be easy to pull randomly flagged people out of line for a half-hour stint in the vote-tallying room next door - let them skip the waiting line for voting so that there's no serious added burden on people so selected. Use a tallying scanner too if you like for added integrity - each bundle of ballots gets counted, tallied by both computer and drafted volunteers, and if the tallies don't all agree, they get re tallied until it does. Heck, tally by computer at the beginning AND end of the process to make sure nothing got modified or misplaced (and potentially later recounted) before the bundle is sealed and labeled with its final tallies, never to be opened again except in case of recount.

Just like that we've solved almost all the existing problems with paper ballots - they're verified as valid when cast (heck, add a digital scale and your wall-count display to ensure nobody casts multiple ballots). You've done the tallying before ballots ever leave the polling place, and can report them to the central counting authority without them ever being unsupervised. Counting is completed shortly after the polls close, and you've not once trusted a computer without verifying its working properly.

Re:No software and no storage?

[NicknameUnavailable]

If you write electronic voting machine software you're a traitor, no if's and's or but's.

Re:No software and no storage?

[bluefoxlucid]

What if the your smart card is corrupted in such a manner as to exploit a flaw in your data-reading routines to corrupt the software itself?

Not feasible. Either the driver would fail to read or the software would receive data which fails to validate. Computers aren't physical things: you don't rust a pipe to break through, but rather feed it something that triggers bad logic in a wholly-functional subroutine.

we're *still* finding new ways to compromise data loading routines for common formats that are decades old, though you could hopefully simplify the format to

Rigid validation. Many data formats are incredibly-complex, and a simplistic and predictable format would be used for ballot data.

the smart-card formatting itself could be corrupted, attacking through the OS instead of the voting software.

Smart cards have a sort of protocol where you get raw data. It's not a 2GB SD card with a file system; it holds a few kB at best. That passes directly through without being processed by the OS; and if there are packet length specifiers and the like, you can follow the code path in the driver and ensure you have predicted the length of each data packet, allocated a buffer that size, and only copy that many bytes.

Though I find it unconscionable that any voting machine would incorporate the huge attack surface of an OS in the first place

You'd have to. An OS handles inputs and outputs, along with process scheduling. If you didn't use an OS, you'd have to write a lot of extremely-complex stuff from scratch to control the system. You're then introducing the same kind of attack surface, but with less vetting, thus more risk.

Just because an acceptable solution isn't readily apparent is no reason to avoid exposing the fact that your system has been compromised

Whenever you take an action to intervene--if you step in and un-stuff ballots when someone sneaks extra smart cards in--you have a chance to pull some sleight-of-hand and tamper with votes. Prevention preserves integrity.

here's a possibility: the oversight officials have to push a "commit" button periodically to commit the last N temporarily recorded votes to the permanent record - or a cancel button to invalidate them.

Creates bottlenecks and people who leave won't necessarily know their votes were confirmed. You're opening for official intervention, which opens up for tampering.

why are you trying to do electronic voting at all? What _exactly_ is the point?

Reduces the number of attack points and allows us to retain election integrity.

Paper ballots are unhackable,

Paper ballots are routinely altered, thrown out, lost, found, manufactured, and otherwise tampered. Thousands of votes go uncounted or appear somewhere along the way all the time. Election judges get to decide if a ballot is valid based on if it has a smudge, scratch, stray mark, or anything else.

It's *far* easier to secure a physical ballot box, and doesn't take that long to count - especially since the volunteer pool for vote counters is directly proportional to the number of voters

A pool from which you can find a few volunteers, maneuver them into the counting, and have them manipulate the error rate. It's done all the time.

Just like that we've solved almost all the existing problems with paper ballots

Not at all. We have undervote and overvote problems, spoiled ballots, manipulation of the ballots, and of course the complexities introduced by ranked systems which resist tactical manipulation (and can be hard to follow during the count, thus allowing for further manipulation of the vote).

you've not once trusted a computer without verifying its wo

Re:No software and no storage?

[dheltzel]

Andrew Tierney should be thankful John didn't just shoot him . . . (yet) If he wants to meet someplace dark and private to pay out the bounty, I recommend Andrew not go alone. McAfee is a scary guy even in the light.

Re:No software and no storage?

[davidwr]

If you write electronic voting machine software you're a traitor, no if's and's or but's.

I see where you are coming from but I disagree.

* There are elections that are not secret ballot, such as votes in Congress which are almost always done either electronically or by voice vote.
* There are elections that are almost entirely done by proxy, such as stockholder elections.
* There are electronic voting systems that are nothing more than a computer-assisted counter of a paper ballot.
* In theory (and hopefully in practice) there are electronic voting systems that are nothing more than a print-on-demand ballot-printer for a paper ballot or a computer-assisted vote-marker of a paper ballot.

The combination of the last two easily falls into the category of "electronic voting machines/systems" but because the actual ballot is seen and cast by the voter and is inherently audit-able, it is no more or less "hack-able" than a pure paper-ballot system would be. In fact, it may be less vulnerable because to "hack" it you would need to hack both the counting machines and the humans that audited the count, which may be harder than hacking a human-vote-counter and a human auditor and all the people supervising the count and audit.

Re:No software and no storage?

[F.Ultra]

Basically the single problem that electronic voting solves is the performance of the vote calculations which is completely moot since in most elections the results will not kick in for several weeks or months and is then valid for 4 whole years so there exists no real reason to get a result "now".

Re:No software and no storage?

[lengel]

What problem is electronic voting solving that paper ballots have not solved?

This has been described above a few times. The problems are obvious because they have been exploited throughout history. The simplest one is if the vote talliers favor one candidate, when they see a ballot that votes for the other candidate they invalidate it by surreptitiously adding a mark somewhere and then that ballot has to be thrown out. Electronic voting is trying to make the talliers unbiased and have no way to invalidate ballots.

This is just one example of a problem it is trying to solve.

Re:No software and no storage?

[NicknameUnavailable]

Computers can be hacked, all computers are insecure given enough time (or secret knowledge, or collusion on the part of vendors,) using them for elections is irredeemable in the eyes of any sane person.

Re:No software and no storage?

[davidwr]

Computers can be hacked, all computers are insecure given enough time (or secret knowledge, or collusion on the part of vendors,) using them for elections is irredeemable in the eyes of any sane person.

So can people-based systems. Think bribery, blackmail, having a partisan spy in the process, etc. By having both computers and humans doing the vote-counting in parallel - using computers to count paper ballots to provide "instant results" with human auditing in the days that follow - it's harder to hack the vote count. If the computer is accurate but the people are cheating, the discrepancy will be noticed. If the computer is hacked but the people are honest and accurate, the discrepancy will be noticed. If both are compromised but by opposing parties, the discrepancy will be noticed.

As far as pre-vote things like maintaining the voter rolls, printing ballots, etc. those have been mechanized or computerized for decades. There is no turning back that clock. However, frequent, regular, and "deep" audits of all steps can help make sure most problems are detected before election day and those that can't be detected until election day - such as "print on demand" ballots - are caught before votes are cast.

Re:No software and no storage?

[NicknameUnavailable]

People are more satisfying to punish when caught. If there's a hack on a computer not only may you never find the culprit, but the manufacturer, developers, etc have enough leniency to not go immediately to prison for life, which is wrong.

Re:No software and no storage?

[bluefoxlucid]

There are elections that are not secret ballot

EVMs must not expose who cast what ballot.

In theory (and hopefully in practice) there are electronic voting systems that are nothing more than a print-on-demand ballot-printer for a paper ballot or a computer-assisted vote-marker of a paper ballot.

Paper ballots create a route for spoofing. Print-on-demand paper ballots imply easy ballot forgery.

because the actual ballot is seen and cast by the voter and is inherently audit-able, it is no more or less "hack-able" than a pure paper-ballot system would be

Paper ballots are lost, found, altered, and simply ignored all the time. They're ripe for electoral fraud; the trick is they're generally ripe for fraud by the election staff, not the voters. Paper ballots are made with all kinds of security against forgery so the voter can't sneak in counterfeit ballots to stuff ballot boxes.

You can make an electronic voting system that's far more secure (and provably secure) than paper ballots, but it requires adherence to protocol. Deviation from proper handling protocol destroys integrity. With paper ballots, you can't even count them without undiscoverable sleight-of-hand risk: once you've manipulated the count, nobody will ever discover it. Proper electronic voting protocol can make tampering discoverable 100% of the time, and never hideable.

Re:No software and no storage?

[bluefoxlucid]

or secret knowledge, or collusion on the part of vendors

I've removed the possibility of collusion. That's the problem I'm actually attacking.

Computers can be hacked, all computers are insecure

Hacking requires attack surface. That means you need to accept complex, user-controlled input. Wireless and wired networks immediately create an uncontrolled source of attack surface, and so are impossible to secure.

The required surface exposure is actually fully-auditable in reasonable human time. The biggest part is access: a voter has to be identified to a voting machine to vote. You can use an EVM to cast votes to a smart card and then cast the smart card ballot to an electronic ballot box. The election staff initialize the smart card to identify the voter to the EVM; the EVM signs and encrypts the data it places on the smart card to cast to the EBB. EVM and ballot box generate their key pairs at poll open and you exchange them via smart card as part of the opening process, so this is done in an observably non-tampered environment.

That means a voter can't copy, view, or alter a ballot card (because the EBB is tracking who voted, but not which ballot they cast, so you'd need to break the encryption). Your EBB's decryption and signature verification implementations need to reject any invalid input and handle all input correctly (small and complex code base: auditable). Your EVM needs to accept a Voter ID, polling center ID, and ballot ID (extremely-small, simple: auditable).

This opens an obvious weak point: manufacturing ballot cards to allow voting at the EVM.

To avoid that, you need to use a signature device like a FIDO U2F or smart card with Ed25519 code built in. These devices generate their own key pairs on themselves. At poll open, you have to associate them with an EVM, and then transfer that key to each EVM in turn. Each election staffer then can use their device to sign any ballot card they activate, giving it one-time voting use for one voter.

The only way through this is to chain an attack first compromising the signature verification code on the EVM, then injecting code to manufacture bad signatures that won't verify on the EBB, plus include code to inject into the EBB to tamper with votes and display false votes.

The data operations in Ed25519 signature verification operate on fixed-length fields. There is no copying of strings; there is only mathematical operation on bytes in a declared-length byte stream.

So you can do things like %LEN your offsets "just in case" your code somehow tries to write to buffer[out_of_bounds_index]. If you somehow read extraneous data when verifying the signature, you'll get a signature mismatch (unless someone has magically figured out how to break SHA256 and Ed25519). More to the point, however, this is a few hundred lines of direct, step-by-step arithmetic mostly made up of small arithmetic functions: there are few operations concerning buffers, and they're all auditable for correctness.

You either reduce the attack surface to something a few hundred instructions wide, or you don't have security.

Re:No software and no storage?

[bluefoxlucid]

if you say it's not feasible for carefully crafted data to invoke unintended behavior in the data-reading routines and take control of the software, then you have no business even attempting to building such a product.

Let's see.

if (dataFile.Length < GuidSize*3) throw InvalidDataException();
Guid pollingLocation = new Guid(dataFile.PopBytes(GuidSize));
if (pollingLocation != this.PollingLocation) throw new LocationAuthorizationException();
Guid voter = new Guid(dataFile.PopBytes(GuidSize));
if (this.Election.Voters.Contains(voter)) throw new AlreadyVotedException();
// Get empty BallotSheet containing correct races. Throws an exception if invalid ballot sheet.
BallotSheet ballotSheet = this.Election.CreateBallotSheet(new Guid(dataFile,PopBytes(GuidSize));
while (dataFile.Length >= GuidSize*2 + 1) {
// Get the Ballot for race with a given GUID
Ballot b = BallotSheet.GetBallot(new Race(new Guid(dataFile.PopBytes(GuidSize)));
if (b is null) throw new InvalidRaceOnBallotSheetException();
while (dataFile.Length >= GuidSize + 1) {
Candidacy c = b.GetCandidate(new Guid(dataFile.PopBytes(GuidSize)));
// Get the next 8 bits as the vote
int value = dataFile.PopBytes(1).ToInt();
// if Candidate is 0, this ballot is done
if (c.Id.Equals(new Guid(0))) break;
Vote v = new Vote(c, v);
// This throws an exception if the candidate is not in the Race, already has a ranking, etc.
// Casts directly to the Ballot on the BallotSheet.
b.Cast(v);
}
}
// Must be a complete, non-truncated file
if (dataFile.Length != 0) throw new InvalidDataException();

So that's way crude and you wouldn't do it that way if you were sane; however, let's examine the attributes.

First: it checks how many bytes are available to pop from the stream before popping them. It also checks that an expected available valid chunk of data follows.

Second, it throws an exception if an incorrect polling location, ballot sheet, etc. are encountered. You load the ballot sheet or you catch an exception that says something strange has happened.

Third, if the data file isn't terminated by valid data, it throws an exception.

Now you've loaded blunt data (it's not interpreted: it's just the file stream) into this dataFile object, so no processing happened and literally any data will load into that without causing a program error. You have this rigid set of things which must be internally (to the data file format) and externally (to the expectations of the voting system for what is valid data) consistent.

Take control of the software through a specially-crafted data file.

Yes, this is crude and allows some funky things (like gaps in ranks for ranked voting). Production code would do some sanity checking about that, after loading the objects into memory safely. You'll get a valid ballot out no matter what you throw at it, so long as it validates the above checks; you won't hijack the program flow.

Your argument is essentially "a super-cool hacker could even hack Hello World!", to which I say that's only believable if Hello World were written in Perl.

Process scheduling? What the hell sort of bloated attack-friendly voting system are you trying to create? It's a voting machine - single-threaded single-tasking is completely sufficient for the job. A voting machine only needs to read setup data, display very simple data, recognize very simple inputs, do a bit of tallying, and output the results - again onto a raw device.

It has to handle software interrupts, display systems, storage routines, and the like. You also have to have a way to write this complex, graphical software in a manner which is human-maintainable and as little prone to software flaws as possible--and we all know software alwa

Re:No software and no storage?

[bluefoxlucid]

If the computer is accurate but the people are cheating, the discrepancy will be noticed. If the computer is hacked but the people are honest and accurate, the discrepancy will be noticed.

How do you tell who is cheating? Did you introduce fake paper ballots, or did the computer drop some ballots? Did you manage to "lose" some ballots, or did the computer? Did the computer record votes but not print ballots for them so that people would discard those votes as computer error/tampering when they were real votes?

You might notice the discrepancy, but how will you correct the errors?

Paper ballot verification is security theater. Language is weird: an electronic paper trail is stronger than a paper paper trail; somebody decided "paper" means "audit". The fun comes when the human auditing in the days that follow leads to amended precinct reports and nobody questions it.

Re:No software and no storage?

[Immerman]

Yes - while I'm not going to do an in-depth analysis of your sample code, a simple enough format, and a rigorous enough auditing of the code, should make it possible to approach 100% confidence that it's not a potential attack vector.

It has to handle software interrupts, display systems, storage routines, and the like. You also have to have a way to write this complex, graphical software in a manner which is human-maintainable and as little prone to software flaws as possible--and we all know software always has flaws.

Why? You're thinking like a Windows programmer whose grown accustomed to writing code for general-purpose OS. What do you need interrupts for that couldn't be handled with polling? Your system/software storage can be EEPROM, or similarly configured flash, easily accessed via mapping into memory space (many embedded systems do it that way). Your input is trivial - a few buttons or maybe a touch-screen, easy to poll for "current input state", which is all you really need since you're sitting completely idle waiting for an input. And what is this complex, graphical software you're talking about? You're recording ballots, not simulating physics or playing video games. And graphical? You're planning to include photos of the candidates? Otherwise you're just talking text in boxes - easily done with "graphical" text characters. Even with photos you're talking drawing graphical boxes and some crude bitmap loading and blitting for photos and text characters.

It's also why I suggested a two-stage recording process - ballots get tallied, but not committed without official approval. The only votes that can be tampered with are those currently in a "pending" status - and there's no reason they should remain there for more than a few moments - the only purpose is to make sure only one vote is cast, rather than an armful.

This is security theater.

No, it's insurance against ballot stuffing. Without that, if someone manages to post even one extra vote (slips in an extra SD card or whatever), how do you invalidate those votes? Once the ballot is in the box you can't extract it - unless you're storing them as a nice orderly list so that anyone recording voters entering the booth can tell exactly how everybody voted - and there are a lot of good reasons to prefer a secret vote.

We don't need electronic voting to make the system easy to invisibly compromise - we just need a standardized compromise-resistant processes that's easy to publicly verify

Yeah, we've spent a hundred years working on that. It doesn't work.

No, we really haven't. As proved by the fact that we're still dealing with utter lackadaisical chaos around elections, and everyone thinks that's okay. And what makes you think you can make the requisite handling of electronic voting systems by techno-incompentents is going to do any better?

read-only SD card

Do they make those? I've never heard of such a thing - certainly the write protection tab on a normal SD card is only a suggestion that the controlling device is free to ignore. But okay, sure, theoretically you could build a card that is electrically incapable of being written to when locked.

The "few unsupervised moments" you need are between poll open and poll close; and the "vulnerable point" is a long and complex process of entering the ballot box itself, rebooting onto alternate media, switching back to the original media, changing the system image, and bringing the system back to up-and-running. It's maybe a few minutes of downtime if you're heavily prepared. You can, of course, rig the ballot box to display visual and auditory alarm when entered; and if it's logging a heartbeat to the log collector, you'll have to enter the log collector and deploy fake heartbeat events and somehow try to keep those in sync with one-way communicatio

Re:No software and no storage?

[bluefoxlucid]

Why? You're thinking like a Windows programmer whose grown accustomed to writing code for general-purpose OS. What do you need interrupts for that couldn't be handled with polling?

Well the touch-screen device, keyboard, or whathave you raise interrupts when there is data. You can't poll everything, you know.

Your system/software storage can be EEPROM, or similarly configured flash, easily accessed via mapping into memory space (many embedded systems do it that way).

Oh, yes, and we can swap the EEPROM chip out before and after the election so nobody knows we used a tampered system.

And what is this complex, graphical software you're talking about? You're recording ballots, not simulating physics or playing video games. And graphical? You're planning to include photos of the candidates?

You're drawing buttons and inputs on-screen. It's actually not a trivial process.

And, yes, you have photos of the candidates, along with clips of their voice. It's necessary for impaired voters: we allow the illiterate, the deaf, and the blind to vote.

No, it's insurance against ballot stuffing. Without that, if someone manages to post even one extra vote (slips in an extra SD card or whatever), how do you invalidate those votes?

That's a good question. This is also a question not addressed today with paper: once the ballot is cast, it cannot be found. We have a way to invalidate the immediate prior ballot, but not go two steps back.

There is, of course, this requirement:

Protect the secrecy of the vote such that the system cannot reveal any information about how a particular voter voted, except as otherwise required by individual state law

And what makes you think you can make the requisite handling of electronic voting systems by techno-incompentents is going to do any better?

Well despite the fact that a lot of folks--you, for example--think computers are mystical and not-computers are simple, you can actually make everything simple and direct. By contrast, as you yourself acknowledge, people still can't figure out paper ballot security--which of course is several pages of procedures requiring understanding of complex concepts like zero-information proofs.

Do they make those? I've never heard of such a thing - certainly the write protection tab on a normal SD card is only a suggestion that the controlling device is free to ignore.

The write-protection tab can disable writing to the card by the host device. It's an... okay method, and no your computer can't simply ignore it: writing simply doesn't work.

You could make such a device by putting an eFuse on the write line of the NAND array and burning it if power is applied while write protect is set. No matter what you do after that, it is electrically-impossible to raise the write line and thus to alter the contents of NAND. Needless to say I want one.

No, all you need is one unsupervised moment, when you bring down the fresh safely-booted voting kiosk and reboot it with your compromised kiosk software, allowing you to silently bias all future votes.

Won't work. The EVM and the ballot box are separate; the ballot box displays votes as read from the ballot card, so you have to actually alter the ballot box. The EVMs establish trust and accept encryption keys for the EBB on start, but not afterwards, so you have to carry out this long 10-15 minute process to get everything set up again. Election staff also have a trust with the EVMs so people can actually vote, which means everybody involved in running the election at that location needs to get involved with replacing all of this.

It's simple, but it takes some time.

Or a few moments alone with the ballot-box storage when you plug it into your

Re:No software and no storage?

[Immerman]

So don't use a device that raises interrupts - do away with the USB bus and access the hardware directly, lots of devices do that. Or limit yourself to an extremely bare-bones interrupt handler - think DOS as the operating system, not Windows. If your total OS is more than a few tens of KB you've added a massive amount of unnecessary vulnerabilities.

Seems like you agree there's a ballot-stuffing risk, so how do you address it? I gave you one example that would be very effective and minimally cumbersome, which you don't like. So what's your solution?

>and no your computer can't simply ignore it: writing simply doesn't work.
Everything I've read says that the restriction is enforced at the driver level for almost all SD card readers - which means a compromised driver or purpose-modified SD card reader will let you ignore it. It *could* be enforced at the card level - but would make the card more expensive, so (almost?) nobody does so - much like including write protect switches on USB flash drives I suppose. Purpose built hardware for elections? I'd love to see it - but suspect most municipalities would opt for the cheaper route.

Re:No software and no storage?

[bluefoxlucid]

Seems like you agree there's a ballot-stuffing risk, so how do you address it? I gave you one example that would be very effective and minimally cumbersome, which you don't like. So what's your solution?

The only way to control ballot stuffing is public observation. Paper ballots allow collusion to evade this.

In an electronic system, you can use a handling chain of HMACs and digital signatures. That means the election judge has to put a card into the electronic ballot box during initial configuration after imaging, and carry the card to each voting machine to do the same, then back to the EBB. A card for each of the election staff also must be inserted into each EVM at imaging, that one being the type that contains an encryption routine for digital signatures.

Election staff would insert their card into a voter roll machine, and insert a blank ballot card (a smart card that only stores a few KB of data and doesn't do anything fancy) into the same machine. They select the voter, and it puts the voter ID, location ID, and ballot ID on the card. This information is first sent to the smart card for digital signing, then encrypted (with the EVM's keys), then HMAC'd (using the smart card).

The whole thing looks pretty boring: insert card, click name, remove card, take card to voting station. Magic is happening behind the scenes.

HMAC is an SHA256 or SHA512 with a secret key for fast verification of authenticity (only election staff can HMAC and sign). Passing that, the EVM will decrypt and interpret the information. The EVM presents the correct ballot if the Location ID matches the current location configured (and yeah, it has to decrypt first, so the wrong machines can't even read it); it lets you vote; and then it writes Voter ID and votes to the ballot card.

Of course the EVM would write more than that. A random salt value, the voter ID, the ballot ID, the location ID, the votes, and a digital signature, encrypted for the EBB to read (you can't copy and reveal your card), and HMAC authenticated so the EBB can skip decryption if someone spoofs a card. EBB validates your Voter ID hasn't already voted, records a vote, and wipes the card.

Ballot salt is for logging. You need a one-way serial output from the EVM and EBB to write logs to a separate collector. The EVM would log Voter ID and salted hash of the ballot (which doesn't reveal ballot contents because it's basically a random number); EBB would log Voter ID and compute the same salted hash for what it pulled off the card; and then the EBB would store, retrieve, display, and log Voter ID and the computed salted hash for the retrieved ballot. These three hashes should be the same; if not, the EBB can self-detect an error.

In any case, you can't alter the card (it's encrypted, signed, and HMAC), duplicate it (VoterID is logged so we know you've voted), or read it (it's encrypted). As with paper ballots, the election staff can pick up a bunch of ballots off the desk if nobody is in the polling center and begin filling them out; they can't pass a bunch of blank ballots to someone outside before polling begins because each blank ballot must be brought to a single visible desk and operated upon in view of the public.

I've juggled a few black swan defenses in case you find a way to covertly create initialized ballot cards.

Everything I've read says that the restriction is enforced at the driver level for almost all SD card readers

Damn, you're right. I thought it was enforced at the IO level.

Purpose-built hardware is more viable than you'd think. With 2,160 polling places, EVM/EBB image, and candidate data load image, you need 4,320 cards for just Maryland. The customization is a write-protect switch that breaks the write line, leaving it grounded out--the extra production cost is zero, and you have some up-front R&D. If your driver misbehaves when told the FS is RO, that's your own problem.

An order that size is a trivial customization. You'd end up with the bulk discount saving you more than the customization cost.

By the by, the EVMs are under $200 per voting station with UPS and lexan cases and all; states pay $3,500+ these days.

He's a proper cunt

[volodymyrbiryuk]

But that's what you get form most of the "bounty programs" these days. They have no honor.

Re: He's a proper cunt

[Nidi62]

Or maybe it didn't fit with the types of hacks allowed. Guessing someone's password does not expose a vulnerability in the device.

According to the article, you have to hack a certain version that cost $10 more (because they have $10 worth of cryptocoins on them). McAfee is, however, refusing to send out this version and then claiming no one is meeting the terms of the bounty because they are hacking the regular version and not the bounty version. Even though apparently the regular version is getting hacked up worse than a group of drunk teenagers in a cheesy 80's horror movie.

Re:He's a proper cunt

[gweihir]

Honor is exactly the problem. Not the only place where that can be observed, though. For a bug-bounty program to be successful, you need to be generous with the payouts. You need to recognize, applaud and reward the people that hand in things, even if they are not quite in scope. It is still far cheaper than paying real security experts to do an in-dept evaluation. But if you give the impression that it is questionable whether you will pay at all, people will just go elsewhere and the whole thing becomes marketing BS. Being cheap here is very, very expensive.

Experienced Security Manager Wanted...

[Anonymous Coward]

How can you do a project like this without an experienced security manager on the team. This statement to me is a huge red flag about how they develop product.

Re:Experienced Security Manager Wanted...

[phishybongwaters]

Simple, you are John "insane in the membrane" Mcafee. This guy is so full of shit I can smell it from here, and also the scent of blow and jizz wafting off of a few trans hookers

Never say unhackable.

[jellomizer]

If it is designed for a computer (a man made machine) to read the data and decrypt the data to be shown and used then there is a way to hack it. The best we can get is having it secure enough, to make mass production of the hack impossible or just expensive and performing such hack being a time consuming process.

Re:Never say unhackable.

[dohzer]

"Unhackable" = A Challenge.

Re:Never say unhackable.

[sergioag]

Unhackable, unsinkable, etc. It seems like we never learn our lesson...

Re:Never say unhackable.

[jellomizer]

Or just baseless bragging.

Back in college someone wrote code and said that no one could break into it. I just stared at the screen thinking on what to try, the program just died on its own.

Re:Never say unhackable.

[jellomizer]

It probably still is cheaper to mine cryptocurrency or scam people out of them then to hack it.

So only now they're hiring an experienced sec guy

[devslash0]

...but not having one on board didn't stop them from calling their device unhackable.

Unhackable, sure...

[theM_xl]

How did the old truism go again? As soon as the hacker has access to the hardware, you've LOST.

Re: Unhackable, sure...

[David_Hart]

Except this isn't true. There is hardware that self destructs if you try to physically tamper with it. It is mostly accurate, but not in every case*. * No pun intended

Except that there is no such thing as tamper proof short of the device being a one-off version, which doesn't bode well for backups, etc. For example, if you have a "tamper proof" box but it is mass produced (which everything is today) then someone, with enough time, effort, and money, can find a way around the "tamper proof" mechanism. Then all they need is physical access...

Re: Unhackable, sure...

[David_Hart]

OK. Great. Now go back and read the OP. The claim wasn't that a select few very determined people *might* succeed. It was that as soon as *any* hacker gains access you have *immediately* lost. It helps if you read the posts and think a bit before replying.

I see that you mis-understood my post. My post wasn't at all about the reward. I agree that the researcher should have received the reward.

My post was only about refuting the assertion that a self-destruct device would thwart a determined attacker with physical access to a device.

Re:So only now they're hiring an experienced sec g

[OzPeter]

...but not having one on board didn't stop them from calling their device unhackable.

You do know who was making the claims don't you? He doesn't exactly have a stellar relationship with the truth.

Watch out

[Nidi62]

All I'm saying is, Tierney needs to make sure that McAfee doesn't move in next door. We all know how that turns out.

If McAffee still hyping things?

[QuietLagoon]

Who in the world took him seriously?

Re:If McAffee still hyping things?

[Desler]

People who bought into ICO scams.

This is a physical device

[edtice1559]

If you walk around with a physical crypto-wallet, somebody is going to forcibly take it from you and worry about getting to the contents later. It doesn't really matter whether it is "hackable" or not because once somebody steals the wallet, you don't have the crypto-currency anymore. Even if it were "unhackable" (probably a laughable statement), it's like walking around with a locked briefcase full of cash. Everybody can see you have it if you get robbed, you're out the money, even if the perpetrator never manages to open the briefcase.

Re:And $10 more...

[Nidi62]

...is what's keeping the researcher from obtaining it?

No, they won't send them out to anybody even when people order/request them.

Re: How it work?

[DontBeAMoran]

Ah, so it runs on magnets.

Re:So only now they're hiring an experienced sec g

[Desler]

He also doesn't have a stellar relationship with neighbors.

unsure, but Nitrokey storage?

[Herve5]

I don't own a bitcoin wallet so that says it all regarding my competence, but what about buying -for about the same price- one of these open-source hardware, open-source software keys that the German Nitrokey build, originally for storing cryptography signature but now they embark Gbytes of encrypted storage on various internal volumes, one of them hidden with even plausible deniability?
H.

BotFi

[Anonymous Coward]

More like ShitFi Wallet, amiright?!?

If I were the security researcher in this story, I would just publish every hack of anything McAfee as a zero-day, and tell McAfee that that will stop when they pay the promised bug bounty... on BOTH bugs, (or all of them,) with interest.

The interest I would charge would be 100% per day. Each. Meaning, pay now, because tomorrow will cost you double. Oh, and I would apply continuously compounding interest.

Also, as an aside, I am never using anything in any way connected to McAfee. Ever. Because obviously they SUCK.

First law of security

[Errol backfiring]

"If someone can acces, anyone can."

This is the first law of security. You can make unauthorized access difficult, but never impossible.

Re:And $10 more...

[Desler]

No.

McAfee is, however, refusing to send out this version and then claiming no one is meeting the terms of the bounty

Even a 5-year-old could understand that sentence correctly.

Voting system - auditability

[FeelGood314]

I like your thoroughness in design but I'll accept a little bit of insecurity in my voting machines if I know I can audit them. See https://en.wikipedia.org/wiki/... This means I can check that my vote was cast and counted correctly. Assuming some people check their personal vote then the probability of multiple invalid votes being cast or votes being altered becomes vanishingly small.

Re:Voting system - auditability

[bluefoxlucid]

Well I have $10,000 and can buy votes for around $5 each. You can prove you voted for the candidate for whom I paid you to vote, correct? Show me your vote.

E2E systems don't provide election security. It's possible to verify a voter's individual vote as valid while stuffing votes for people who didn't vote. Further, the system has to be able to track and identify each voter's vote--and allow proof of vote--to function, which allows vote-buying, coercion, and the like. Scratch-and-vote and three-vote have been demonstrably-attacked.

By making the actual system image of each EVM and electronic ballot box public, you obtain permanent auditability of the vote-recording process. You can confirm ballots by reading them from the smart card, displaying them, then storing and recalling them to display the stored ballot next to the ballot cast to show they are not different (a sort of integrity check). A separate log collector (over a one-wire, one-direction serial link) can receive a log when a ballot cast is recalled invalidly, as well, to provide record of an internal integrity check. At close, the machine generates a 1:1 tally which proves the ballot set later published is the same ballot set.

The problem is trusting anyone at any level. You can check your vote; can you check the stuffed ballots? Do you know if someone along the way inserted additional votes? All of your ballots must be traceable to a polling process and must not be traceable to an individual voter; that a voter can trace a ballot to themselves is actually a bug.

Re: BTC is still holding strong

[mSparks43]

there is significant intrisic value in not having to rely on the banks to store the digits of your financial value, or decide how and who you conduct financial transactions with.
Economics 401.