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

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: 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: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