I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).
If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key). Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.
If you read the paper correctly would you like to place a numerical estimate on how likely this attack is ...e.g. 50%, 10%, 1%, 0.001%?
Thanks in advance for reducing the FUD spreading.
Trezor is open source and running only the signed firmware. This attack is not feasible in such circumstances, because everybody would see the "malicious tx-signing code" on github.
Also, RFC6979 is the answer to this problem that Trezor implements. With it, there is not a choice of k, thus the attack is not possible.
With a piece of software writing skills, you can initialize Trezor, use it to sign a couple of transactions, then import master private key into bip32.org, generate all private keys and verify that RFC6979 was used. This can be used with real or fake inputs in "blackbox testing" OR it can be used after some coins go missing to prove the maliciousness of the firmware...
Trezor is well designed and certainly better than using a PC, even an off-line PC with air gap. But it is not 100% safe. I already explained how a criminal can get around its safety features, by using social engineering or fake malicious hardware. The fact that people keep denying those risks only makes those risks more significant.