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

101–110 of 160 posts

Re: Case study: fake hardware cryptowallet

#101

Post by lxgr »

lisper wrote: post #98
lxgr wrote: post #92

Earlier quoted context omitted.

Hm, but as a regular user, how would I make sure that what I received in the mail is actually an SC4-HSM and not an identical device that looks the part, but is running some pre-flashed firmware emulating all responses expected by a blank SC4-HSM (i.e. "I'm empty", "writing firmware with hash xyz succeeded" etc.) with high fidelity?

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 than full emulation.

> Anything is possible, but this would be extremely difficult.

I agree that it would be very difficult, but unfortunately this property sort of caps the "maximum desirable popularity" of a solution: Nobody will go through that effort for a niche/hobbyist HSM, but as soon as people start protecting serious/expensive secrets with it, somebody might just do it.

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 (as you would need to physically extract one key per fake device produced as an attacker).

Re: Case study: fake hardware cryptowallet

#102

Post by technion »

lisper wrote: 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 was a huge fan of what was promised here. I ordered one but every time I tried to work with it I had some catastrophic unrelated incident - like a curse lol.

Anyway I suspect the problem is the nature of crypto. For this to actually take off, you would have needed to hand a bag of money to Jake Paul or John mcafee or a bitboy, and I'd highly suspect a really good product has a hard time competing against those that do

Re: Case study: fake hardware cryptowallet

#103

Post by PretzelPirate »

kosherhurricane wrote: post #94

My #1 argument against the feasibility of cryptocurrency: Can my parents not their get money stolen?

Can crypto currency be used easily? Yes, through centralized entities like where your parents currently store their money.

Some people may forgoe ease and aim for self-custody because they value decentralization over convenience. Others will choose a middle ground where they and a centralized entity both hold part of the key, ensuring that the 3rd party can't move their funds without permission.

Re: Case study: fake hardware cryptowallet

#104

Post by PretzelPirate »

dools wrote: post #100
lxgr wrote: post #49

Earlier quoted context omitted.

You have to trust somebody when it comes to hardware devices. If you don't do anything, that includes the OEM, their supply chain, your delivery courier, an evil maid etc. If you have the choice of reducing that list to only the OEM, isn't that a win? That's what attestation does.

> 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 plenty to choose from that are well known, well tested, and the developers are funded.

It's not as simple as saying "the entire premise of crypto currency is flawed because you have to have some trust." The people that much of the crypto community don't trust are large bankers and governments.

Re: Case study: fake hardware cryptowallet

#105

Post by PretzelPirate »

drdrey wrote: post #76
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.

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

You don't have to trust that at all. You can verify that the wallet signs a message with the correct private key that was generated offline.

When you send funds to the wallet, you don't need to send them to the address that the wallet presents, you can send them to the address you calculated during offline key generation. As long as you use the Trezor derivation path on your offline machine, it's predictable what the first address will be.

Re: Case study: fake hardware cryptowallet

#106

Post by web3-is-a-scam »

BobTheDestroyer wrote: post #90
web3-is-a-scam wrote: post #85

Earlier quoted context omitted.

Ah yes, flashing my own firmware. The future of finance.

It's an automatic update. All you have to do is watch the progress bar fill up. Even you could manage it.

I can manage it because I’m a nerd. My technologically inept father on the other hand, could not.

Re: Case study: fake hardware cryptowallet

#107

Post by mrb »

drdrey wrote: post #76
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.

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

No because I feed my wallet public key (xpub) to scripts that derives the wallet addresses, and I verify that the derived addresses match what my wallet generates. I'm paranoid like this :)

Granted that would be really inconvenient to do if one used the wallet on a daily basis. In my case I use it rarely enough (large transactions only) that it doesn't bother me that much.

Re: Case study: fake hardware cryptowallet

#108

Post by [deleted] »

lxgr wrote: post #59
BobTheDestroyer wrote: post #50

Earlier quoted context omitted.

>Trezor Suite will only accept the device if the installed firmware is correctly signed by SatoshiLabs. ...? Although I'll concede that I'm now wondering what's preventing compromised hardware from faking this part too. A complex malware could even receive firmware updates, dump them in an unused partition, and report to the connected host that it promises that it's definitely running that firmware, right? Hmmm.

Yes, it could absolutely do that. The only way around that would be for Trezor to ship their devices with some sort of attestation function (e.g. a private signing key to which they publish the public key, or sign it via a PKI and include a certificate) and validating that , not just the statement "I promise to be running the authentic firmware", a hash over the firmware, a complete firmware dump or anything else not…

[deleted]

Re: Case study: fake hardware cryptowallet

#110

Post by lxgr »

lalopalota wrote: post #74
lisbon44 wrote: post #68

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

What does that achieve? Surely the fraudsters wouldn't dare to use one of the "actually secure" version numbers in their attempts to deceive Trezor users...?
Post reply on HN