Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Case study: fake hardware cryptowallet

kaspersky.com

Post reply on HN
Print view View original

121–130 of 160 posts

Re: Case study: fake hardware cryptowallet

#121

Post by magnat »

somat wrote: post #72

"choose models with special versions of protected microcontrollers" I don't see how this is helpful advice. The whole point of the article was how the look and feel of a legitimate hardware wallet was cloned. Under these circumstances there is no way to tell what is in the device(clear housing perhaps?). all it has to do is act like the real device. It does not matter how good your security chip actually is if all I…

> the use of that particular version is a strangely shoddy mistake. It should have been very easy to use a version string that exists

Perhaps attackers wanted to discourage user from trying to upgrade firmware/bootloader before first use by using version one step higher than officially released. If they used older version number, savvy user might try to flash newest firmware and discover something isn't quite right. Using nonexistent, but plausible looking version number, can also be used to explain minor discrepancies in behavior between fake and original unit, if some are introduced by mistake.

Re: Case study: fake hardware cryptowallet

#122

Post by magnat »

What if each genuine unit would have entire PCB covered in glitter nail polish at factory? Based on a serial number of your device, you could check if a pattern on your device matches the one taken by manufacturer right after assembling the device.

Re: Case study: fake hardware cryptowallet

#123

Post by lottin »

PretzelPirate wrote: post #104
dools wrote: post #100

Earlier quoted context omitted.

> You have to trust somebody I know, all the time, and thus the entire premise of crypto is flawed, as are the libertarian ideals that birthed it.

> trustless system Crypto let's you choose who to trust. You can build your own wallet, you can buy one, or you can choose to let someone hold your assets for you. Many people will choose to trust large centralized parties, and some will choose to generate their own keys offline with code they've verified. Do they have to trust that any cryptographic libraries they use generate seeds properly? Yes, but there are plen…

Nobody can build their own wallet directly from raw materials. Even in the very unlikely event that they had the know-how, they would still require highly specialised equipment manufactured by third parties. Therefore users of "crypto" have no option but to rely on goods and services provided by third parties just like everybody else. And the extent to which consumers can choose which parties to rely on (or "trust") depends entirely on the degree of competition in the market. Crypto isn't special with regards to trust. Calling it "trustless" is false advertising.

Re: Case study: fake hardware cryptowallet

#124

Post by lisper »

saganus wrote: post #84
lisper wrote: post #78

Earlier quoted context omitted.

You could feed it time info through the USB interface.

That was actually my first line of thought as well, but I could never find a way to do that. My low-level development expertise is pretty low, so perhaps there is a way, but after looking through the USB specification and other USB-development related docs, I just could not figure it out unfortunately. The closest thing I found was to do someting like this ( https://stackoverflow.com/questions/13335402/unable-to-sync…

It has been a long time since I touched that code, but the SC4-HSM came with several demos, including a FIDO U2F token, all of which used the USB interface. It would not be at all difficult to make a TOTP application that got its time from there.

Re: Case study: fake hardware cryptowallet

#125

Post by CTDOCodebases »

rippercushions wrote: post #83
quickthrower2 wrote: post #75

Earlier quoted context omitted.

How secure is the attestation key against the wallet CEO's kids being held hostage?

Obligatory $5 wrench xkcd: https://xkcd.com/538/ Still, physically threatening/kidnapping somebody is an entirely different threat model, although it's very common in the Bitcoin world: https://github.com/jlopp/physical-bitcoin-attacks

This is not specific to Bitcoin though.

In Latin America there are “Flash/lightening kidnappings” where they take a person hostage and drain their bank account over a period of time.

Re: Case study: fake hardware cryptowallet

#126

Post by lisper »

lxgr wrote: post #101
lisper wrote: post #98

Earlier quoted context omitted.

Anything is possible, but this would be extremely difficult. You can't program an off-the-shelf unit to emulate itself. The flashing sequence is a hardware function. There is an actual button that determines whether the system is coming up in flash mode or run mode after a reset. To fake the flashing sequence you would need to have a custom chip, or a custom PCB, or you would need to rewire the stock PCB so that wire…

> You can't program an off-the-shelf unit to emulate itself. You don't need full emulation, just protocol emulation should be enough, right? This might involve having more storage than the authentic device (or getting very clever with compression) in order to e.g. be able to authentically provide a "firmware dump", and maybe run at a faster clock speed so that the timing isn't suspicious, but it still seems easier th…

> You don't need full emulation, just protocol emulation should be enough, right?

Yes, but you would need to bypass the hardware button that puts it in DFU mode, and you would need to do that in a way that isn't visible. Possible, but difficult. (Look at the photos of the hacked Trezor. It's obvious that it has been tampered with.)

> as soon as people start protecting serious/expensive secrets with it, somebody might just do it.

Sure, but remember, this was a self-funded one-man project. (Well, I hired a contractor to do the hardware design, and I had some code contributed by another developer, but other than that it was just me.) The idea was to test the market to see if there was any interest at all in this sort of thing. If this had gotten any traction at all I would have had the resources to put additional mitigations in place.

But even as it stood it would have been extremely difficult for an attacker to compromise these devices. They were shipped to me from the manufacturer in sealed anti-static bags, and I did the final assembly myself. By far the biggest security weakness in the process was me. If I wanted to backdoor these devices I probably could, but only because I controlled the manufacturing process. I really don't think anyone else short of a state actor could do it, not because of the technical difficulty, but because they would have to get physical access somehow without being detected.

> Shipping each unit with a private key only known to the vendor, and providing a one-time attestation service, could make this attack much harder to pull off at scale

Yes, that's a very good idea. If I had sold more than a few dozen I probably would have done something like that.

Re: Case study: fake hardware cryptowallet

#127

Post by tromp »

mrb wrote: post #62

I would be immune to this attack because I always generate my own seeds, on a trusted computer. So I set up hardware wallets to import my seed, instead of trusting their seed generation algo. Of course this procedure doesn't protect against other hardware attacks, for example the wallet exfiltrating the private key somehow (R/F signal), but it certainly raises the bar for hackers.

What software do you use to generate your 256-bit seed, and to convert that into the 24 words that the hardware keys require as input?

Re: Case study: fake hardware cryptowallet

#128

Post by tetromino_ »

gnatman wrote: post #14

I’m far from an expert and don’t own any cryptocurrency but I can’t imagine buying a hardware wallet from a “popular classifieds website”, i.e. ebay.

It is possible that the buyer of this wallet had no better option. For example, the official place to buy these devices might refuse to ship them to his country.

Re: Case study: fake hardware cryptowallet

#129

Post by ibz »

Alupis wrote: post #32
Scoundreller wrote: post #27

Earlier quoted context omitted.

Lifehack: a post office will weigh whatever you want for free . Also many grocery stores have accessible scales. Best part is they pay for the certifications! Then there are friends that ahem buy/sell materials in gram quantities. A counted handful of newish coins are a reasonable way of verifying accuracy in those cases. Be sure to weigh different quantities lest the absolute and relative error cancel out.

The Post Office's scale likely only has ounce resolution, or at best, 0.01 LBS (0.16oz) resolution. ie, you won't notice a couple grams of glue...

Indeed, you need a drug dealer's scale!

Re: Case study: fake hardware cryptowallet

#130

Post by ibz »

munificent wrote: post #24

> The bootloader checks the digital signature of the firmware and, if an anomaly is detected, displays an unoriginal firmware message and deletes all the data in the wallet. This seems like a horrendous design, like a safe that burns the money inside if you try to tamper with it. Sure, it might protect a malicious thief from absconding with the funds, but it is also an attack vector for any bad actor that simply wish…

Unlike a safe, a hardware wallet doesn't store money, it stores private keys. These keys are derived from a seed phrase you are supposed to back up offline.
Post reply on HN