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

151–160 of 160 posts

Re: Case study: fake hardware cryptowallet

#151

Post by fooker »

lxgr wrote: post #49
dools wrote: post #39

> The main safeguard is to buy your wallet directly from the official vendor and choose models with special versions of protected microcontrollers (even original Trezors aren’t ideal in this sense: there are other brands’ wallets with better protected chips and extra protection mechanisms). Yet another hilarious example of where a the solution to security in an alledgedly trustless system designed to subvert authorit…

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.

Might as well trust a bank.

Re: Case study: fake hardware cryptowallet

#152

Post by lottin »

pjc50 wrote: post #143
lottin wrote: post #137

Earlier quoted context omitted.

How does a "paper wallet" work? I thought a wallet in order to work had to interact with other wallets?

Surprisingly, no. All a "wallet" has to do is compute a signature using a private key. Then the resulting transaction has to be sent to a "mining" node (or the "mempool" of a group of nodes) and wait until one of them incorporates it into a transaction, computes fourty trillion hashes and then throws all but one of them away, and broadcasts the resulting signed block to the network. Because there is no confirmation o…

Right, it doesn't interact directly with other wallets, but it has to interact with other parties using an electronic protocol in order to be useful. So a piece of paper isn't enough. Some kind of electronic machinery is required to build an actual cryptocurrency wallet.

Re: Case study: fake hardware cryptowallet

#153

Post by Scoundreller »

ibz wrote: post #129
Alupis wrote: post #32

Earlier quoted context omitted.

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!

A jeweller’s scale!

Re: Case study: fake hardware cryptowallet

#154

Post by mattdesl »

lottin wrote: post #150
mattdesl wrote: post #148

Earlier quoted context omitted.

Wallets tend to have two main features: A) generate random private keys and B) given some private key, sign a transaction and broadcast this message to the network. Pen, paper, and some dice (and a bit of work) can generate a private key for step A, which you can input into a hardware wallet, and which would have prevented the problem in the OP. It’s also possible to write your own wallet software or use a “trusted”…

So clearly pen and paper doesn't work, since it isn't possible to sign a transaction and broadcast the message to the network using only a pen and a paper. Writing a software wallet would involve using third-party compilers, operating systems and hardware, which means it isn't "trustless".

As far as the OP is concerned, a wallet generated via a dice roll and pen would have worked to circumvent the vulnerability.

And we probably have different definitions of “trustless.” See here for a common understanding within crypto:

https://www.preethikasireddy.com/post/what-do-we-mean-by-blo...

It doesn’t mean “you can perform some action without trusting anybody or anything at all.” Protocols, software, hardware, and even your environment will all require various degrees of trust.

Re: Case study: fake hardware cryptowallet

#155

Post by lottin »

mattdesl wrote: post #154
lottin wrote: post #150

Earlier quoted context omitted.

So clearly pen and paper doesn't work, since it isn't possible to sign a transaction and broadcast the message to the network using only a pen and a paper. Writing a software wallet would involve using third-party compilers, operating systems and hardware, which means it isn't "trustless".

As far as the OP is concerned, a wallet generated via a dice roll and pen would have worked to circumvent the vulnerability. And we probably have different definitions of “trustless.” See here for a common understanding within crypto: https://www.preethikasireddy.com/post/what-do-we-mean-by-blo... It doesn’t mean “you can perform some action without trusting anybody or anything at all.” Protocols, software, hardware,…

From the interactions that I've had with many supporters of cryptocurrencies on Twitter and Reddit, I don't think that this a common understanding of the word "trustless" (which literally means "without trust", by the way) within this community.

Even if we take "trustless" to mean "not trusting a single, centralised party" it's not clear at all that blockchains are trustless or even that they're more trustless than other payments systems such as Visa. That's a question that can't be answered from abstract principles. It would need to be answered empirically.

Re: Case study: fake hardware cryptowallet

#156

Post by mrb »

tromp wrote: post #127
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?

A custom script that essentially reads /dev/urandom and feeds the hex seed to bip39tool from pybitcointools.

Re: Case study: fake hardware cryptowallet

#157

Post by munificent »

lxgr wrote: post #48
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…

If an attacker succeeds in tampering with the firmware on a crypto wallet (and more generally any secure authentication/transaction confirmation device), losing authentication/signature capabilities is very likely the second worst outcome.

Good point.

Re: Case study: fake hardware cryptowallet

#158

Post by throwaway290 »

ReactiveJelly wrote: post #115
lxgr wrote: post #59

Earlier quoted context omitted.

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…

Similar problem to Trusted Platform Module / Secure Boot, right? In that case the golden keys can leak, but it's better than nothing.

leaked key seems worse in that people will think they have this security measure working for them while they don't. Without this measure there is no illusion at least

Re: Case study: fake hardware cryptowallet

#159

Post by mattdesl »

lottin wrote: post #155
mattdesl wrote: post #154

Earlier quoted context omitted.

As far as the OP is concerned, a wallet generated via a dice roll and pen would have worked to circumvent the vulnerability. And we probably have different definitions of “trustless.” See here for a common understanding within crypto: https://www.preethikasireddy.com/post/what-do-we-mean-by-blo... It doesn’t mean “you can perform some action without trusting anybody or anything at all.” Protocols, software, hardware,…

From the interactions that I've had with many supporters of cryptocurrencies on Twitter and Reddit, I don't think that this a common understanding of the word "trustless" (which literally means "without trust", by the way) within this community. Even if we take "trustless" to mean "not trusting a single, centralised party" it's not clear at all that blockchains are trustless or even that they're more trustless than o…

Of course it will depend who you ask; but most Ethereum developers at least would probably agree that the word “trustless” shouldn’t be interpreted literally as “without trust” to the extent your comments suggest, just as “serverless” systems might still involve servers. Call it a misnomer; there’s plenty in the English language.

Re: Case study: fake hardware cryptowallet

#160

Post by CTDOCodebases »

quickthrower2 wrote: post #136
CTDOCodebases wrote: post #125

Earlier quoted context omitted.

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.

They can’t take a bank hostage and drain all of it’s customers funds though.

This was solved technically with the invention multisig wallets.

Whether the custodians choose to support them or not is another matter.

Post reply on HN