With the current hardware wallets, there is AFAIK no way for a customer to verify if the HW wallet indeed generates secure, private addresses. All checks actually just use various methods to verify the firmware and hardware integrity which make hacks more difficult but not impossible. But still, you can't say if the HW wallet just does not emulate the original software while it does other things. Even when the firmware is open source, you can't say if the code you see is indeed running on the hardware. And even when you modify the code and upload it to the wallet, you still can't be sure if the upload actually rewrites the firmware, or if your code is just interpreted somehow to mimic your code but still controlled by an attacker's firmware.
At least, there are these potential attack vectors that the compromised HW wallets can do and software can't detect them:
- Seed will not be randomly generated. Instead, some pre-generated seed (or one of) known to the attacker will be displayed. There is no way for the client to verify it, as the HW wallet generates it completely (and the software does not even see it).
- The seed is random but the derived addresses (and xpubs) are not derived from the seed. Instead, some attacker's pre-generated addresses are used. Because the client doesn't know the seed (and it obviously should not know), it can't verify if the derivation is correct. Passphrases do not help either; another set of compromised addresses could be displayed as well and the client can't verify it.
The first issue comes from BIP39, and the second issue comes from BIP32, widely used standards. Are there any other standards/proposals that address these two weaknesses? Like generating a part of the randomness on the client and enforcing its usage in the derived addresses.
My goal is to be safe until both HW and SW are fake. The current state is we are safe if and only if the HW is not fake and genuine SW can't help.
Are my thoughts reasonable? Is this a problem?
