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

31–40 of 160 posts

Re: Case study: fake hardware cryptowallet

#31

Post by Scoundreller »

bibaheu wrote: post #25
hn_throwaway_99 wrote: post #21

Earlier quoted context omitted.

I don't understand this. If you ever want to do anything with the funds in that wallet (e.g. sign transactions using the private key), you're going to need to connect it to a machine that can connect to the Internet. Otherwise, how is this any better than a cold storage paper wallet?

You can generate the coin movement operation in the air gapped machine, write it down on paper, and then use a normal, connected computer to transmit it to the network. The private key never left the air gapped machine, with this method.

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.

Re: Case study: fake hardware cryptowallet

#32

Post by Alupis »

Scoundreller wrote: post #27
alden5 wrote: post #20

Earlier quoted context omitted.

the problem is the sorta person to buy a wallet from a classifieds website isn't willing to spend $30 on a scale to weigh it, because if they had that money they'd just buy it from the official store instead

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

Re: Case study: fake hardware cryptowallet

#33

Post by TacticalCoder »

hn_throwaway_99 wrote: post #21
monero-xmr wrote: post #7

If you want a hardware wallet, I recommend software in an air-gapped machine. Unless you can buy the hardware directly from the manufacturer, and ideally you walked into the factory and bought it at the source, the risk of compromise is too great.

I don't understand this. If you ever want to do anything with the funds in that wallet (e.g. sign transactions using the private key), you're going to need to connect it to a machine that can connect to the Internet. Otherwise, how is this any better than a cold storage paper wallet?

> If you ever want to do anything with the funds in that wallet (e.g. sign transactions using the private key), you're going to need to connect it to a machine that can connect to the Internet.

Not commenting on GP's point but... No, you don't.

You can prepare your transaction on an online machine, without signing it. With full access to the blockchain, the balance of every address, the "counter" needed so that you tx is legal (in Ethereum's case), which address you want to spend from etc.

Then you transfer that transaction, without using the Internet, to the offline computer and sign it there and transfer the transaction back to the online computer to broadcast it.

The computer preparing the transaction, the one signing the transaction and the one broadcasting it can be three different computers.

You can even do that with an hardware wallet: the hardware wallet does not need to be plugged to a computer that is online. It can be plugged to a computer that is offline.

There are still many issues, even when using airgrapped computers. For example it's possible that a hardware wallet vendor is using non-determinism in "random" parameters chosen to sign transactions to exfiltrate the seed hidden among signed transactions. So even an offline/airgapped computer and a hardware wallet hooked to that offline/airgapped computer wouldn't help.

Re: Case study: fake hardware cryptowallet

#34

Post by BobTheDestroyer »

Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially:

> All Trezor devices are distributed without firmware installed - you will need to install it during setup. This setup process will check if firmware is already installed on the device. If firmware is detected then the device should not be used.

>The bootloader verifies the firmware signature each time you connect your Trezor to a computer. Trezor Suite will only accept the device if the installed firmware is correctly signed by SatoshiLabs. If unofficial firmware has been installed, your device will flash a warning sign on its screen upon being connected to a computer.

https://trezor.io/learn/a/authenticate-model-one

There seems to be an element of user carelessness and naivety here. Anyone who follows Trevor's hardware verification checks surely needn't worry about these attacks.

Re: Case study: fake hardware cryptowallet

#35

Post by LordShredda »

BobTheDestroyer wrote: post #34

Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially: > All Trezor devices are distributed without firmware installed - you will need to install it during setup. This setup process will check if firmware is already installed on the device. If firmware is detected then the device should not be used. >The bootloader verifies the firmware signature each time…

How does the setup process check for firmware, anyways? If there's a malicious firmware preinstalled I'm guessing it could just lie to the host computer and pretend to be not there until setup is complete. Once an attacker has hardware control, no software can save you.

Re: Case study: fake hardware cryptowallet

#36

Post by lxgr »

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 private attestation key of a legitimate device and then go on to impersonate it in their own version.

This again could be mitigated by e.g. making the attestation key device-unique and offering an online validation service (which could keep track of unusual verification patterns and alert users), but it's not an easy problem to solve.

Re: Case study: fake hardware cryptowallet

#37

Post by corn13read2 »

40four wrote: post #15
acaloiar wrote: post #6

Earlier quoted context omitted.

Agreed -- the title should say (Trezor Impostor) to make it clear that Trezor is not the fake.

Or even better, it should just say “Case study: fake hardware cryptowallet”, which is the exact title, and in accordance with the guidelines. No need to append “Kaspersky” On the front, or mention Trezor at all, let the reader click through and form their own opinion.

Or... even better! "Case study: fake"

Re: Case study: fake hardware cryptowallet

#38

Post by derefr »

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 the attacker's goal was to erase the user's data, and the firmware _didn't_ erase data on invalidation, then the attacker could simply write a firmware that erases the user's data.

Re: Case study: fake hardware cryptowallet

#39

Post by dools »

> 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 authority comes down to ... trust and authority.

Re: Case study: fake hardware cryptowallet

#40

Post by StingyJelly »

londons_explore wrote: post #17
KryDos wrote: post #9

Does it mean that at the moment of releasing 2.0.4 the Trezor team already knew there is a fake firmware circling around? I wonder if Trezor team communicated that in some maybe different way than that line in the CHANGELOG. Not blaming them of course, just wondering.

If I were Trezor and became aware of a fake firmware, I would: * Offer rewards to anyone able to send me the fake devices or clues who is making them. * Tell my clients to upgrade the firmware on devices before use. Make sure every new firmware is distinctive in some way - for example the boot screen, and tell the users to check for that to ensure they are actually running the firmware they thought they just flashed.

More sophisticated version of the malicious firmware could try to patch the new ota firmware image on the fly. Once compromised - always compromised.
Post reply on HN