If you sign on two devices and check that they match, yes, that addresses the issue, but now you have two devices with your seed and a very annoying UX (that might also fail due to fine signature grinding differences).
Really HWWs need to implement anti-exfil and generate keys with computer randomness - there’s no excuse for the fact that hardware wallets are trusted, they don’t need to be!
Having the same seed on two devices wasn't what I had in mind. In that case it's better to use MuSig2 (regular multisig has the same problem, though both devices would need to be compromised).
Why would adding computer randomness at seed generation time help with exfill at signing time?
If there an RFC / BIP for anti-exfill at signing time?
The issue with exfil is that the computer can’t detect whether the nonce is malicious or not, so it can’t block the attack. What you really want is for the nonce used to sign to be provably random, by simply having the computer add some of its own randomness to nonce, plus some deterministic message+pk hash from the hardware wallet (ala 6979). That way the HWW cannot exfil.
While you’re at it you should also include randomness from the computer in the seed generation process so that the private keys themselves don’t rely on only the HWW.
Neither of these are complicated, FROST is built around the same kind of nonce agreement protocol and including the randomness from the computer in key gen is just a matter of adding a second private key.
Sounds like someone should write a BIP (including the extra psbt fields needed), for the signing time anti-exfill.
Yea, someone probably should. Probably one of the hardware wallet vendors who are complaining that there’s no standard and that’s why they never bothered to implement it (nevermind that it’s implemented in secp256k1-zkp and can be done at the HWI driver layer, but indeed it’s be better as a PSBT field).
Sadly no implementation exists for Taproot AFAIK, but the BitBox folks have a PR to secp256k1-zkp at least.