Displaying fingerprint while FW update

[trezor]

Displaying fingerprint while FW update

[Giszmo]

So I updated yet another Trezor One and ran into this issue again. To my understanding, there is nothing that could have been done about this if the version I'm updating from isn't able to display the hash but as the above screen is apparently for a touch screen, I'm wondering if the Trezor One can check the FW fingerprint at all. And if not, how can I trust the update process without trusting 100% the trezor suite?

[Hannsek]

Or do any other companion apps also support firmware updating?

Exodus wallet supports updating firmware as well.

[matejcik]

With that argument you could also remove the blockheight display when signing transactions

I don't think we show blockheight when signing Bitcoin transactions via Trezor Suite?
Blockheight is an optional parameter, so the logic goes, if you set it, you want to be able to confirm your setting. If you're using different software that sets blockheight for you by default, that's something along the lines of "UX bug" of that software.
If Suite set blockheight by default, then yes, this argument would fully apply.

[mcudev]

I looked at this quickly in bootui.c ui_screen_install_confirm_upgrade and there's not enough room without some kind of scrolling interface or some other way of displaying it. The text would just fit on the screen if the buttons weren't covering the bottom two lines (since the 64 hex digits need to be broken up into 4 lines [at least, i didn't even try with all the widest possible hexadecimal characters]).

[slush0]

I would solve this in similar way as in bootloader homescreen (with "connect to host?" question) - by clicking "i" icon on the firmware confirmation dialog. Actually, the fingerprint is not so useful for most of people, but it is definitely good to have a chance to check before the upload.

[tsusanka]

Let's reevaluate this in Product again because "Satoshilabs 2.3.0" for example is enough to uniquely describe the firmware fingerprint.

Edit: Product still thinks this makes sense because if you try out reproducible builds you would like to see the fingerprint to compare. This should be quite easy to do so why not.

[Giszmo]

What is the status of this issue? I want to set my hardware to not leave it to the preference of the companion app if the firmware update hash is shown or not. I want to set my Trezor into a state that reliably prevents what just happened: The update was over before I had realized that the option to show the hash wasn't there. The Trezor in question was meanwhile factory-reset.

[Hannsek]

https://www.figma.com/file/l0gG9XeRJ8FTDQ3cfb1wv9/Trezor-T%2C-Trezor-One?node-id=4081%3A19150&t=eHfw3kvV7cKbzVOR-4

[matejcik]

@Giszmo you don't need to trust Suite, you just need to trust Trezor device. It will not allow installation of unsigned firmware unless you confirm installation of unsigned firmware. (and in that case you will see the fingerprint)

[Giszmo]

Sorry, what? I did not see the fingerprint updating from an unknown version pre-taproot.

you don't need to trust Suite, you just need to trust Trezor device

... and whoever has the signing keys who incidentally is also who controls Suite and Suite controls if a fingerprint is shown or not, right? I did very carefully go through each of the screens and even canceled at one point but then saw I could not just not install the update so I picked up there and finished the install. I did not see a fingerprint or option to show one. I did use the web version of Suite.

So do I read this right that in order to get the fingerprint shown, I have to trash the signature check?? I get it you cater to people that have no clue about all this but it's me and others who do have a clue that end up rotating to a new private key while you have total control of rug-pulling oblivious users as Suite can know if the user will see the fingerprint or not.

[matejcik]

It's the Trezor device controlling who sees the fingerprint. If the firmware is signed, the fingerprint is not shown, because (as you correctly point out) we cater to people who will just get needlessly scared by a sequence of hex characters.

With that said, this issue is now fixed both on Model T and the new Trezor Safe 3, and you have the option to view the fingerprint before confirming installation.

We will not be backporting the modification to Trezor One, because bootloader space is extremely limited there (as in we're actually counting bytes at this point). Adding a whole new UI for "click here if you want to see the fingerprint" is a complete no-go, and putting it into the main flow is also no-go from UX standpoint.

---

With that said, what is the attack you are worried about? Something along the lines of:

1. Suite prompting you to update,
2. you do a reproducible build to figure out the correct fingerprint, because you obviously don't trust what Suite is showing you,
3. you proceed to install through Suite, which you do not trust,
4. a completely different firmware was surreptitiously signed and published by SatoshiLabs,
5. Suite substitutes that "bad" update for your "good" update?

In that scenario, why are you installing the update through Suite in the first place? What you should be doing is:

1. independently download the signed binary
2. do a reproducible build, compare that the results are identical except for the signature bytes, per this guide
3. use trezorctl to install your locally downloaded file, because it's significantly easier to audit that it's actually sending the bytes you want and not something downloaded off the internet. On an airgapped machine to which you transfer the new binary on a USB stick, obviously.

Plus, I would urge you to not use hardware built by a vendor you don't trust in the first place, but hey 🤷‍♀️

[Giszmo]

My project is WalletScrutiny.com where I attest to the transparency of Bitcoin wallets and the potential for the provider to steal most of the funds of most of the users at once. I trust Tezor more than any other company in the Bitcoin space but still I must acknowledge that

• psychopaths exist and fool people into believing them over long stretches of time
• criminals can get creative when they hear about what could be gained from compromising a Trezor firmware update
• governments exist that try to do shady stuff

Generally the world is a dangerous place so me trusting Trezor should not be enough to have others blindly trust Trezor, too. In Bitcoin there's the slogan "Don't trust! Verify!"

That said what I try to achieve with my project is to nudge projects like Trezor away from "won't be evil" towards "can't be evil" and with most users updating through Suite and the fingerprint not being shown, Trezor can be evil. I do not attest to providers probably not being evil but to them making it easy to detect should they ever switch to being evil.

While I am angry at myself for failing to update my Trezor with the level of scrutiny I would have liked to give it, it's precisely people like me who should make products safe for people who proceed with less care. My work is to protect others so at this point I should not throw away my Trezor One and rotate my keys to a new hardware wallet but actually try to figure out if I could somehow get to the binary that was actually installed so I can attest to Suite installing what is claimed to be installed.

Reproducibility is not only to protect the nerdiest of the nerds but also to attest to fingerprints being expected so people who don't feel comfortable compiling the firmware themselves can know what they are using.

I want users that are confused by the fingerprint to write it down or take a picture of at least part of it and ask around if that's to be trusted. If only 1% of the users did this, there would be no way a company could dare to mass-backdoor some future firmware version.

[matejcik]

ohh, nice, I liked your website!

I basically agree with your mission about "can't be evil", but in this particular case, I disagree about the means to achieve it.
(obligatory disclaimer: while I am the code owner of most of firmware, I do not speak for Trezor Company, nor do I have the authority to do so. The opinions here are my own and do not necessarily indicate the final decisions that will land in firmware.)

The gist of my counter-argument is the motto "security at the cost of usability comes at the cost of security".

to attest to fingerprints being expected so people who don't feel comfortable compiling the firmware themselves can know what they are using.

I want users that are confused by the fingerprint to write it down or take a picture of at least part of it and ask around if that's to be trusted. If only 1% of the users did this, there would be no way a company could dare to mass-backdoor some future firmware version.

Basically. A place for "fingerprints being expected" is a nerdy hyper-secure wallet like ColdCard.
The average cryptocurrency user doesn't want to care about fingerprints. It's one extra step, in the already way too many steps, in the way of what they want to be doing.
Putting it as a mandatory screen in the update process will cause (the majority of) users to (a) just click through or (b) stop updating firmware. Both are undesirable.

The (i) icon on trezor-core Trezors is, IMHO, a good solution -- it allows you to verify the fingerprint, or you can just ignore that UI element. But that is unfortunately not an option on the Trezor One. Making the screen a mandatory part of the flow would deter from UX for everyone every time, to increase security essentially in a disaster scenario -- and even then, that's assuming that you can get the message about the bad fingerprint out in reasonable time.

[Giszmo]

Putting it as a mandatory screen in the update process will cause (the majority of) users to (a) just click through or (b) stop updating firmware. Both are undesirable.

(a) is totally desirable as a small percentage checking is enough to deter the provider from doing anything shady.
(b) obviously is not desirable especially if the user ends up wiping the device without the backup or if the users hammer the provider's support about this.

With the Trezor One not getting any way of checking the fingerprint without the companion app knowing if that's happening, I will recommend against using it as it puts the provider in a position to broadly deploy backdoors.

Please remind me what can be used to update the firmware. Trezor Suite for desktop and for web and trezorctl, right? Or do any other companion apps also support firmware updating?

[matejcik]

(a) is totally desirable as a small percentage checking is enough to deter the provider from doing anything shady.

(a) is undesirable because it teaches users that at certain times it's safe to ignore what the Trezor is saying.

Please remind me what can be used to update the firmware. Trezor Suite for desktop and for web and trezorctl, right? Or do any other companion apps also support firmware updating?

I am not aware of any other app. Of course, it's trivial to implement so perhaps someone somewhere did it.

[Giszmo]

(a) is undesirable because it teaches users that at certain times it's safe to ignore what the Trezor is saying.

With that argument you could also remove the blockheight display when signing transactions or do you have evidence that any significant amount of people actually verifies this? If those blockheights were significantly in the past, it would even give room to leak key information, so yes, it's critical but probably no user checks it.

Users should fall into two camps:

• Those who understand what a fingerprint is. Those would maybe take a photo to verify later or not or verify immediately.
• Those who don't. They would maybe also document that weird string or not or read up on it but mostly they would skip over it like they skip over the block height thingy.