Wallet Logo

Trezor Model T

Latest release: 2.5.3 ( 17th November 2022 ) 🔍 Last analysed 5th December 2022 .  
1st March 2018

As part of our Methodology, we ask:

Does the binary we built differ from what we downloaded?

 
If the answer is "no", we mark it as "Reproducible when tested".

If we can reproduce the binary we downloaded from the public source code, with all bytes accounted for, we call the product reproducible. This does not mean we audited the code but it’s the precondition to make sure the public code has relevance for the provided binary.

If the provider puts your funds at risk on purpose or by accident, security researchers can see this if they care to look. It also means that inside the company, engineers can verify that the release manager is releasing the product based on code known to all engineers on the team. A scammer would have to work under the potential eyes of security researchers. He would have to take more effort in hiding any exploit.

“Reproducible” does not mean “verified”. There is good reason to believe that security researchers as of today would not detect very blatant backdoors in the public source code before it gets exploited, much less if the attacker takes moderate efforts to hide it. This is especially true for less popular projects.

Show Older Reviews

Help spread awareness for build reproducibility

Please follow Trezor Model T and thank them for being reproducible  via their Twitter!

Disclaimer

The following Analysis is not a full code review! We plan to make code reviews available in the future but even then it will never be a stamp of approval but rather a list of incidents and questionable coding practice. Nasa sends probes to space that crash due to software bugs despite a huge budget and stringent scrutiny.

Do your own research!

Try out searching for "lost bitcoins", "stole my money" or "scammers" together with the wallet's name, even if you think the wallet is generally trustworthy. For all the bigger wallets you will find accusations. Make sure you understand why they were made and if you are comfortable with the provider's reaction.

If you find something we should include, you can create an issue or edit this analysis yourself and create a merge request for your changes.

The Analysis 

With our test script this is the result:

$ ./scripts/test/hardware/trezorT.sh 2.5.3
...
Fingerprints:
4f57dca1abc1a60d82c4fef7c96e86d784fc7a1e5e3da724dd2ae4d14c6350bf build/core/firmware/firmware.bin
c094c84ba958129885fa725ee6ddb781b580fd2c7851e83aef9054ba4a10526c build/core-bitcoinonly/firmware/firmware.bin

Hash of non-signature parts downloaded/compiled standard:
65+0 records in
65+0 records out
65 bytes copied, 0.000124131 s, 524 kB/s
07e9053be42873b8fc094205607d2c5624a15c84fdf323bc783217d3a7b7fc24  trezor-2.5.3.bin.zeroed
07e9053be42873b8fc094205607d2c5624a15c84fdf323bc783217d3a7b7fc24  build/core/firmware/firmware.bin

Hash of non-signature parts downloaded/compiled bitcoinonly:
65+0 records in
65+0 records out
65 bytes copied, 0.000112391 s, 578 kB/s
b69f1b69819a281f76553e39fed4394f2a5c56eb33f95767b775800282a19f6c  trezor-2.5.3-bitcoinonly.bin.zeroed
b69f1b69819a281f76553e39fed4394f2a5c56eb33f95767b775800282a19f6c  build/core-bitcoinonly/firmware/firmware.bin

Hash of the signed firmware:
8d742ff5498e3f903125aa6fca44bffeea27e42cc37297aa03f6c1fca51b6004  trezor-2.5.3.bin
93f276caa34e3bd599367089f0274b6691e0fdc00697c252be29b1e3d49e8b6b  trezor-2.5.3-bitcoinonly.bin

This looks good. The compiled versions only differ in 64 bytes - the signature - from the downloaded version. This firmware is reproducible.

(lw)