Hello!
What are your thoughts after reading the following articles?
https://shiftcrypto.ch/blog/how-almost-all-hardware-wallets-can-steal-your-seed/
Why isn’t trezor using it?
There is actually an open issue:
Simply put, it has not been a priority because the existing implementation is “good enough”. Trezor source code is of course fully auditable, and it is using deterministic nonces from RFC 6979.
That can be verified by the host computer, given knowledge of the private key. So if you want to validate that the code is doing what it says it is doing, you can generate a seed, load it into your PC, sign a bunch of transactions and check that the nonces have the expected values. If you do this a couple (or a couple thousand) times, you can probabilistically trust that Trezor is not smuggling out secret bits, and load your actual seed.
This is of course not a 100% thing, so using Anti-Klepto would still have some merit. But implementing it counts against implementing other things, so, again, not a priority so far.
2 Likes
Hi,
just pulling this old thread to the surface due to dark skippy exploit vector being around recently.
Will there be an update to mitigate the attack vector?
How vulnerable is Trezor one/T/3 to this vector with the key starting point being (from what I understand) malicious firmware?
Thanks & best
To the best of our knowledge, it’s not viable to put a malicious firmware on the Safe family.
There have been cases of tampered Trezor Ones and Ts; but the attack vector there is a preconfigured seed phrase, which is much easier for the attacker to implement and then retrieve.
Basically the answer here is “don’t pick malicious firmware as your starting point”. Using malicious firmware opens you up to a multitude of practical attacks, where Dark Skippy is something you reach for only after your other options are exhausted.
The value of Anti-Klepto is in keeping the manufacturer honest; which on Trezor you can do in several other ways, such as probabilistically checking the RFC 6979 implementation as suggested above, and/or auditing the open source code and then verifying that it’s actually running on your device.
Dark Skippy is a neat research innovation, but doesn’t really change anything about your real world security. As such, it doesn’t change the priority of mitigation strategies either.
1 Like
Thanks for your quick reply! Is there a tutorial to check if the current firmware is non-malicious?
Since updates stopped for, as far as I can see, the One/T Models: are these considered outdated or unsafe to use? Or is it just that there is nothing more to be improved?
1 Like
Trezor T is still under active development, and there’s a new firmware coming out this month.
Trezor One will not be getting new features in the foreseeable future, but it is actively maintained too… for certain values of “actively” : ) A new firmware hasn’t been released for over a year simply because it has reached maturity and there have been no new issues (security or otherwise) that would warrant a release. If a problem arises, there will be a timely fix.
Sadly, there is no tutorial for checking your firmware. There are some automated checks performed by Suite, and beyond that, the best you can do is, after a firmware update, check for presence of new features that should be in said update. You can even do that in reverse: from a given version, downgrade to an earlier one and check that features are actually missing.
If your Suite is malicious but your Trezor device is genuine, then your firmware is OK: a malicious Suite cannot “hack” your Trezor.
If your Suite is genuine but your Trezor is counterfeit, the “check for new features” thing will detect this.
You will not get into a situation where your Suite and Trezor are both malicious. The attackers who produce counterfeit Trezors can’t really ensure that your PC specifically is infected by a cooperating malware, unless there’s an attack that is specifically targeted to you – and if you find yourself in that situation, help is beyond the scope of this forum. A single Trezor will not protect you regardless of how paranoid you are.
That said, the general idea is to build your own firmware and implement multiple checks that verify that the hardware running it is what it claims to be. Then you install this modified firmware on your Trezor, verify that the outputs are what they should be. Then you make a reproducible build of the official firmware, verify it, and then install the official firmware, confident that your device is ok.
(the problem with this is that if you’re the victim of a targeted attack, you can’t trust your PC about the results of the reproducible build 
)
Thanks for the clarification, matejcik!