111–120 of 160 posts
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.
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?
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. It would be trivial for any iOS-based software wallet to compromise your seed before your…
how many people can or will verify the key is truly one-of-a-kind?
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 2018: https://blog.trezor.io/psa-non-genuine-trezor-devices-979b64... From their forum earlier this year: https://forum.trezor.io/t/protect-from-getting-a-fake-trezor...
Validate the holograms: Most users aren't forensic experts and don't have an authentic physical sample to compare their evaluation target to, only photos of one.
Only buy from authorized resellers such as the official Amazon shop: Fake products have been introduced into Amazon's supply chain before [1].
The bootloader validates the firmware and displays a warning otherwise: Sure, but so does the fraudsters' bootloader.
[1] https://www.redpoints.com/blog/amazon-commingled-inventory-m...
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…
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…
In that case the golden keys can leak, but it's better than nothing.
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?
If the wallet uses deterministic ECDSA, or the algorithm used is deterministic by definition (such as EdDSA), this can be detected, but doing so requires validating some generated signatures on a second, trusted device.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
There have also been cases of software using malicious seed generators which have semi predictable outputs. People assume it’s safe because they see what looks like random seeds, combined with no network activity. But the attacker can then just scan over the whole possible key space and check for funds.
Even more concerning than predictable wallet seeds are covert channels in the form of nondeterministic signature outputs. Most wallets let you provide your own seed words, which users can derive using diceware themselves, but DSA (and its elliptic-curve variants) need a secure random input, and I'm not sure if all wallets commonly use a deterministic (i.e. provably free of covert channels) construction (like in RFC 6…
What you can do is use a dice to generate a key and the sign a bunch of messages with your hardware wallet and a piece of software that you trust. You can then compare the two outputs. This gives you a probabilistic trust level (the more messages you check, the higher the likelihood of there not being a backdoor). (note: I implemented this logic [1] to check that three different RFC 6979 implementations were returning the exact same bytes).