Case study: fake hardware cryptowallet
kaspersky.com
kaspersky.com
"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!".
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.
https://en.m.wikinews.org/wiki/Predictable_random_number_gen...
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 6979) for that.
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).
With the article, it can go unsuspecting for years even simply waiting for maximum distribution and then a coordinated attack.
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."
I can even see something like Coinbase Wallet being 100% compromised. The apology post is probably already written in a draft somewhere.
https://community.trustwallet.com/t/wasm-vulnerability-incid...
how many people can or will verify the key is truly one-of-a-kind?
I don't see how this is helpful advice.
The whole point of the article was how the look and feel of a legitimate hardware wallet was cloned.
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.
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.
A security chip actually deserving the name (i.e. a tamper-proof one) can protect a private key even against physical attacks, with the corresponding public key marked as authentic by the manufacturer.
If the interface contains a challenge-response interaction with that private key (and ideally ties that to any further communication with the trusted applications on it), you can't copy/emulate that.
Perhaps attackers wanted to discourage user from trying to upgrade firmware/bootloader before first use by using version one step higher than officially released. If they used older version number, savvy user might try to flash newest firmware and discover something isn't quite right. Using nonexistent, but plausible looking version number, can also be used to explain minor discrepancies in behavior between fake and original unit, if some are introduced by mistake.
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.
You don't need full emulation, just protocol emulation should be enough, right? This might involve having more storage than the authentic device (or getting very clever with compression) in order to e.g. be able to authentically provide a "firmware dump", and maybe run at a faster clock speed so that the timing isn't suspicious, but it still seems easier than full emulation.
> Anything is possible, but this would be extremely difficult.
I agree that it would be very difficult, but unfortunately this property sort of caps the "maximum desirable popularity" of a solution: Nobody will go through that effort for a niche/hobbyist HSM, but as soon as people start protecting serious/expensive secrets with it, somebody might just do it.
Shipping each unit with a private key only known to the vendor, and providing a one-time attestation service, could make this attack much harder to pull off at scale (as you would need to physically extract one key per fake device produced as an attacker).
Yes, but you would need to bypass the hardware button that puts it in DFU mode, and you would need to do that in a way that isn't visible. Possible, but difficult. (Look at the photos of the hacked Trezor. It's obvious that it has been tampered with.)
> as soon as people start protecting serious/expensive secrets with it, somebody might just do it.
Sure, but remember, this was a self-funded one-man project. (Well, I hired a contractor to do the hardware design, and I had some code contributed by another developer, but other than that it was just me.) The idea was to test the market to see if there was any interest at all in this sort of thing. If this had gotten any traction at all I would have had the resources to put additional mitigations in place.
But even as it stood it would have been extremely difficult for an attacker to compromise these devices. They were shipped to me from the manufacturer in sealed anti-static bags, and I did the final assembly myself. By far the biggest security weakness in the process was me. If I wanted to backdoor these devices I probably could, but only because I controlled the manufacturing process. I really don't think anyone else short of a state actor could do it, not because of the technical difficulty, but because they would have to get physical access somehow without being detected.
> Shipping each unit with a private key only known to the vendor, and providing a one-time attestation service, could make this attack much harder to pull off at scale
Yes, that's a very good idea. If I had sold more than a few dozen I probably would have done something like that.
Unfortunately I was aiming to use it to generate TOTP codes (and replace my authenticator app), but IIRC it needed a RT clock and thus a battery, which was not part of the design.
Great project though.
My low-level development expertise is pretty low, so perhaps there is a way, but after looking through the USB specification and other USB-development related docs, I just could not figure it out unfortunately.
The closest thing I found was to do someting like this (https://stackoverflow.com/questions/13335402/unable-to-sync-...) but I never did.
Do you think that would have worked?
Anyway I suspect the problem is the nature of crypto. For this to actually take off, you would have needed to hand a bag of money to Jake Paul or John mcafee or a bitboy, and I'd highly suspect a really good product has a hard time competing against those that do
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 wishes to cause you harm.
Edit: Looks like I was beaten to this down thread.
If the firmware had been tampered with, there is no safe way to extract the key. Better that the user uses the recovery seed on a fresh device.
Which means the weakest link of your fancy hardware wallet is how well you hide that bit of paper with your seed phrase.
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.
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.
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.
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.
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.
I know, all the time, and thus the entire premise of crypto is flawed, as are the libertarian ideals that birthed it.
Crypto let's you choose who to trust. You can build your own wallet, you can buy one, or you can choose to let someone hold your assets for you.
Many people will choose to trust large centralized parties, and some will choose to generate their own keys offline with code they've verified.
Do they have to trust that any cryptographic libraries they use generate seeds properly? Yes, but there are plenty to choose from that are well known, well tested, and the developers are funded.
It's not as simple as saying "the entire premise of crypto currency is flawed because you have to have some trust." The people that much of the crypto community don't trust are large bankers and governments.
But frankly it’s not that different than cryptography as a whole: nobody implements ECDSA themselves, or builds the computer that runs it, or smelt the metal and assemble transistors that runs the computer, or whatever. There is no such thing as “absolute lack of trust” but some protocols can be “less trust requiring” than others—e.g. more “trustless.”
Because there is no confirmation on sending bitcoin "into" a wallet, no action is required at all to receive and store it. It's only cashing out where it gets difficult. It also makes it possible to send to inaccessible or nonexistant wallets.
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” tool (eg: openssl or node) to create a private key, rather than rely on a random app or device off eBay to generate it for you.
The B) part is harder to do with pen and paper or an off-the-shelf tool as it involves a fair bit of protocol specific math—but it’s also harder to target in a hardware wallet supply chain attack.
Writing a software wallet would involve using third-party compilers, operating systems and hardware, which means it isn't "trustless".
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.
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.
Still, when we talk about ECDSA and other cryptographic protocols, you can use them without being forced to place your trust in the hands of a single person or private company. There isn’t really a great term to describe that ethos, so “trustless” is often used in place.
So pure trustlessness start to finish is impossible. All information exchange requires shared protocols, and this necessitates trust. The idea here is to design protocols which, once the initial setup is complete, trust is no longer a factor.
This isn't just limited to cryptocurrency, it applies to all cryptography, and more broadly, to all security measures of any kind. Key exchange requires initial trust. The idea is that you do the due diligence to get set up, then you don't have to sweat it after. To say the entire system is flawed because setup requires trust is to say that all security measures are pointless.
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.
Still, physically threatening/kidnapping somebody is an entirely different threat model, although it's very common in the Bitcoin world: https://github.com/jlopp/physical-bitcoin-attacks
In Latin America there are “Flash/lightening kidnappings” where they take a person hostage and drain their bank account over a period of time.
Whether the custodians choose to support them or not is another matter.
A bit more to trust but a lot less to type.
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.
That's an awful idea. If you're the type of person to worry about being supply-chain-attacked, then targeted supply-chain attacks are far more likely to happen to you than untargeted ones are. Specifically, you are more likely to be supply-chain attacked by an entity who has the power to either compel or blackmail the OEM into giving you a first-party-adulterated device (think: Huawei network switches), than by an entity who's supply-chain-attacking random strangers. This doesn't just include governments, mind you, but also any sufficiently-wide-reaching criminal gang.
Showing up in person to the factory — or to a retail store — means the intelligence operative planted there can recognize you, and give you the "special" device prepared just for you; or the employee can be compelled by certain training (required to be allowed to sell such devices in certain countries) to follow the special instructions that come up when they swipe your credit card.
So what to do? Don't show up in person. Send a one-time proxy buyer to show up in person. And have the proxy buyer pay in cash, or using their own card.
Think what an American diplomat stationed in China would do if they absolutely needed to get e.g. a new smartphone right away. Normally they'd just wait for something like that to be sent over from America via diplomatic courier, specifically to avoid this problem. But if they couldn't — then proxy-buying at retail is the next-best solution.
(Funny enough, this is also the same thing that computer-hardware reviewers have to do to avoid getting a "reviewer special" binning of the hardware. Counterintelligence is oddly generalizable!)
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.
When you send funds to the wallet, you don't need to send them to the address that the wallet presents, you can send them to the address you calculated during offline key generation. As long as you use the Trezor derivation path on your offline machine, it's predictable what the first address will be.
Granted that would be really inconvenient to do if one used the wallet on a daily basis. In my case I use it rarely enough (large transactions only) that it doesn't bother me that much.
The safest play here for an average user is to just not buy your hardware wallets off eBay, as it seemed to be the case in the OP!
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.
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.
The only thing that would have stopped this attack would be to generate your seed off the device. And then, since the device is counterfeit and there may very well be a way to exfiltrate seeds from it, to use a genuine device, but that's a different attack.
What youre saying though is a good idea, provided the device youre running this on (and therefore entering your seed into) is secure. Since this cannot really be guaranteed it is often advised to never enter your seed into a computer, for good reason.
HW support entering any mnemonic, you don’t have to generate it on the device itself. So if you create a mnemonic yourself and check what addresses it should generate with a third party tool and then enter it in the wallet and see different addresses something is fishy.
https://www.youtube.com/watch?v=dT9y-KQbqi4&pp=ygULdHJlem9yI...
> I was contacted to hack a Trezor One hardware wallet and recover $2 million worth of cryptocurrency (in the form of THETA).
Some people may forgoe ease and aim for self-custody because they value decentralization over convenience. Others will choose a middle ground where they and a centralized entity both hold part of the key, ensuring that the 3rd party can't move their funds without permission.
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.
* 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.
All Trezor would need to do is change the compilation options on a fairly regular basis, and any patching will fail.
Combine with the fact there is a reward to send in devices means they can analyze any evil devices and make sure their instructions to users will reliably detect all evil devices they're aware of.
Still doesn't stop supply chain attacks, but makes them far harder.
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...
That said the obvious way to avoid amazon commingling conclusively is to buy it directly from the Trezor shop.
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?
You have fraud team and IT security team on your staff, right?
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.
uh oh! does this imply something is up that the trezor developers know of?
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.
> 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.
This is an absurd security model. Where's the root of trust here? How do I know I am initially talking to an authentic "blank" device, and not a malicious one pretending to be one?
> If unofficial firmware has been installed, your device will flash a warning sign on its screen upon being connected to a computer.
Hopefully, malicious firmware won't meddle with this feature in any way...
The vendor here is either completely clueless, or is trying to paint a better picture for prospective customers despite knowing better.
...?
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.
In that case the golden keys can leak, but it's better than nothing.