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, 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.
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 6979) for that.
From the outset, you can't prove that RFC 6979 was used. I.e. RFC 6979 doesn't provide provable security. If you want a proof that there are no covert channels, you need to implement some kind of interactive protocol between the signer and the verifier -- I'm not aware of any standard/popular way of implementing 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).
The best defense against potentially malicious hardware wallets is to set up a multisig scheme. If designed properly (with careful planning related to backup/recovery), you end up with better security properties (i.e. defense in depth).
There's a shelf life to this attack for each distributer though. You'll eventually distribute to users who _do_ understand what's happening and they'll raise alarms.
With the article, it can go unsuspecting for years even simply waiting for maximum distribution and then a coordinated attack.
And you shouldn't keep your keys on a regular computer, because that has an even bigger attack surface, nor should you use an exchange which may rugpull you.
"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.