Live data from Hacker News

Case study: fake hardware cryptowallet

kaspersky.com

71–80 of 160 posts

Re: Case study: fake hardware cryptowallet

#71

Earlier quoted context omitted.

The method I’ve read about is to print “the request” onto a QR code, have the air-gapped machine scan it, sign it and print off the signed transaction QR to be scanned into the networked computer to propagate to the network. A bit more to trust but a lot less to type.

And then you get hacked anyway because the QR code generator was compromised and switched around a few bytes before creating the QR code.

Ideally it’s a functionality of the wallet, but I think only bitcoin armory has this function.

Re: Case study: fake hardware cryptowallet

#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 have to do is copy the correct interface.

Unrelated: the use of that particular version is a strangely shoddy mistake. It should have been very easy to use a version string that exists. In which case that version would never have been skipped??? perhaps at one point that was a real version and trezor pulled it due to it's use in a batch of clone units.

Re: Case study: fake hardware cryptowallet

#73

Another nasty supply chain attack exists, way simpler (unlikely to work on knowledgeable users though)... A legit hardware wallet is shipped, but with fake documentation accompanying it. Some evil people working for delivery companies would swap legit hardware wallet for the exact same model, but with documentation using the official company's logo and font and saying, basically: "Here's your hardware wallet, initial…

There's a shelf life to this attack for each distributer though. You'll eventually distribute to users who _do_ understand what's happening and they'll raise alarms.

With the article, it can go unsuspecting for years even simply waiting for maximum distribution and then a coordinated attack.

Re: Case study: fake hardware cryptowallet

#74

> Intentionally skipped this version due to fake devices uh oh! does this imply something is up that the trezor developers know of?

Yes, this implies that trezor developers know of fake devices claiming to run that version so they skipped that version number to ensure that no one who sees that version number would confuse it with an actual version.

Re: Case study: fake hardware cryptowallet

#75
post #36

For physically hardened devices, this attack vector can be mitigated quite efficiently by including an attestation key with each device and validating that after taking possession (or ideally before any interaction). At least one competitor does that. To my knowledge, current Trezor devices are unfortunately not (sufficiently) key extraction proof, though; in that scenario, attackers might be able to extract the priv…

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

Re: Case study: fake hardware cryptowallet

#76
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.

you still trust that the hardware will use the seed you provided and not one of the pre-generated ones

Re: Case study: fake hardware cryptowallet

#77

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

Same design as the HDD on your laptop. The solution is a backup.

Re: Case study: fake hardware cryptowallet

#78
post #66
post #22

I foresaw this years ago, which prompted me to build this: https://sc4.us/hsm/ It's an HSM which you can flash yourself. Unfortunately, it never generated much interest and so I had to fold up the tent. But maybe it was just ahead of its time.

I remember when this came out, and was interested in getting one! Unfortunately I was aiming to use it to generate TOTP codes (and replace my authenticator app), but IIRC it needed a RT clock and thus a battery, which was not part of the design. Great project though.

You could feed it time info through the USB interface.

Re: Case study: fake hardware cryptowallet

#79

Incredible. This is so sophisticated and takes so much effort it makes you wonder just how many other wallets are compromised from before you even use them. There are so many other low effort attacks you can run that the fact that people are doing THIS really makes me wonder just how many wallets out there are 100% compromised. It would be trivial for any iOS-based software wallet to compromise your seed before your…

I think hardware hacking is becoming increasingly sophisticated. The way car thieves managed to unlock luxury cars using a custom device built out of a JBL speaker also blew my mind.

https://kentindell.github.io/2023/04/03/can-injection/

Re: Case study: fake hardware cryptowallet

#80
post #52
post #22

I foresaw this years ago, which prompted me to build this: https://sc4.us/hsm/ It's an HSM which you can flash yourself. Unfortunately, it never generated much interest and so I had to fold up the tent. But maybe it was just ahead of its time.

Neat! But is the microcontroller used tamper-proof? If not, your customers are still vulnerable to supply chain attacks such as the one in the article.

The core hardware is actually very similar. Both use more or less the same STM32 SoC. The difference is that the Trezor comes pre-flashed in a sealed package designed not to be opened, while the SC4-HSM is designed to be flashed by the user, and the case is not sealed so it can easily be opened to inspect the hardware. So while I can't say it would be impossible, launching a supply chain attack against the SC4-HSM would be a lot harder to execute and conceal.
Post reply on HN