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:<p><i>"Here's your hardware wallet, initialize it with the seed written on this piece of paper, it's the only one that's going to work for this hardware wallet. Do not lose this seed or you'll lose access to your funds!"</i>.<p>Several unsuspecting users, not aware that a random seed is supposed to be generated by the hardware wallet (or by throwing dice, or whatever) have been pwned this way.
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.<p>It would be trivial for any iOS-based software wallet to compromise your seed before your private key before is even created. You don't even need fancy spyware that calls home. If the seed is generated from a method that isn't random you'd never know. It will appear random to you, but the author of the software could simply increment on a known value and be able to recreate every private key ever created with that app. No one would ever know. The attacker could sit silent for years or even decades, and if they DID drain a wallet there would be no way to prove it and no one would believe the victim. It would just be a case of, "Well, you must have leaked your seed, it's your fault."<p>I can even see something like Coinbase Wallet being 100% compromised. The apology post is probably already written in a draft somewhere.
Title seems misleading (and isn't the article title). It implies that Trezor is a fake wallet. The article is actually about a wallet that purports to be made by Trezor but is in fact not (hardware supply chain attack).
"choose models with special versions of protected microcontrollers"<p>I don't see how this is helpful advice.<p>The whole point of the article was how the look and feel of a legitimate hardware wallet was cloned.<p>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.<p>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.
I foresaw this years ago, which prompted me to build this:<p><a href="https://sc4.us/hsm/" rel="nofollow">https://sc4.us/hsm/</a><p>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>> 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.</i><p>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 <i>attack vector</i> for any bad actor that simply wishes to cause you harm.
> The housing was difficult to open: its two halves were held together with liberal quantities of glue and double-sided adhesive tape instead of the ultrasonic bonding used on factory-made Trezors.<p>Other than having x-ray vision, one easy (but by no means perfect) verification to thwart these types of attacks is to weigh your devices.<p>Manufacturing should be consistent enough that resealing a device like this would be adding some grams that shouldn’t be there. And unlike something like a cisco router, nothing to cut out to make up for the added weight.
This just is another example to me how absurd it is to use crypto as a practical currency. There is no recourse for compromising your private key, and no way to know for sure that only you have a private key.
> 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).<p>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.
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.<p>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.<p>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.
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 would be immune to this attack because I <i>always</i> 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 would have prevented this attack is the following:<p>Use a little bit of python (there are libraries for this or you can do it yourself) to make sure that the addresses generated in the HW wallet by the 12 word mnemonic are indeed the correct addresses. For example the first segwit address using your private key and the derivation path 49h/0h/0h/0/0 should be deterministic. This way you know your 12 words are the ones used and the wallet is using known standards and not some homebrew crypto.<p>In fact you should always do that anyway in case the HW stops working and/or the company goes under. This way you can be sure that you can recreate your private keys from your mnemonic and access your funds no matter what.
Somewhat related, I was recently pointed to a cool video about someone hacking a Trezor One. Very enjoyable watch.<p><a href="https://www.youtube.com/watch?v=dT9y-KQbqi4&pp=ygULdHJlem9yIGhhY2s%3D">https://www.youtube.com/watch?v=dT9y-KQbqi4&pp=ygULdHJlem9yI...</a><p>> I was contacted to hack a Trezor One hardware wallet and recover $2 million worth of cryptocurrency (in the form of THETA).
Does it mean that at the moment of releasing 2.0.4 the Trezor team already knew there is a fake firmware circling around?<p>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.
<i>Easy to steal and cash out, сryptocurrency is one of the most attractive digital assets for attackers.</i><p>Has the author tried cashing out crypto? KYC anyone? It's harder than ever to cash out ,especially large sums. So many restrictions due to fraud.<p>Hardware wallets are never safe. the only safe way is to generate your own entropy, key derivation. Why would you ever trust a 3rd party to generate your keys?
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.
Would someone be able to spell out how this attack works after initialisation? I don't really understand hardware wallets. How does the information about the user and their key make its way back to the people who created the device?
Trezor has additional checks that aren't covered here. I'd really like to know how those were defeated. Especially:<p>> 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.<p>>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.<p><a href="https://trezor.io/learn/a/authenticate-model-one" rel="nofollow">https://trezor.io/learn/a/authenticate-model-one</a><p>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.