51–60 of 160 posts
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…
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.
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.
The trusted codebase and set of OEMs seems an order of magnitude larger, and I'm not sure whether the lower likelihood of being specifically targeted as e.g. a crypto user by a supplier can make up for that.
Earlier quoted context omitted.
How do you feel about Yubikeys and HSM systems that corporations heavily rely on?
It’s like apples and bowling balls IMO. If the Yubikey directly stored hundreds of thousands of dollars of bearer assets that could be stolen remotely from an attacker anywhere on earth, then it would be a lot more risky. But that’s not typically what the Yubikey is for, unlike a crypto hardware wallet.
> 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.
Edit: Looks like I was beaten to this down thread.
Earlier quoted context omitted.
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.
Why complicate things? Just smash the device. This is only effective if the user doesn't have their seed phrase. Edit: Looks like I was beaten to this down thread.
Would the firmware update fail? if the user had decided to update it? Wouldn't that raise a suspicion?
An attacker can just implement whatever "install firmware version xyz" command by returning "ok, did it!" and remembering that version number if it ever needs to be displayed.
A more complex attacker could emulate the entire firmware in more powerful hardware of the same physical profile and selectively intercept any input and output.
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.
From their forum earlier this year: https://forum.trezor.io/t/protect-from-getting-a-fake-trezor...
Earlier quoted context omitted.
> 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 co…
>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.
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 involving a challenge-response or uncloneable function of some sort.