Remove display_random feature

[andrewkozlik]

Summary

The display_random flag in the ResetDevice message is used during seed generation to display the entropy that was generated internally by Trezor before asking for external entropy from the host. This feature, which is also known as show-entropy in trezorctl, allows the user to cross-check that Trezor generated a valid mnemonic sentence for the given internal and external entropy, i.e. that Trezor really used the externally provided entropy to generate the seed. I have come to the conclusion that this feature lacks purpose and have decided to remove it. (See detailed explanation below.)

To be clear, the device tests still perform the cross-check by looking at the internal entropy, which is always provided in DebugLinkState.reset_entropy in debug firmware builds, regardless of the display_random flag.

Rationale

The intent of the user is to verify that Trezor is really using the externally provided entropy to generate the seed in order to protect themself from a Trezor that might have malicious firmware which could be generating seeds that come from a relatively small set which is known to the author of the malicious firmware.

Using this feature properly requires that the user has a good understanding of how the two entropies are combined together and how they are converted into a BIP-39 or SLIP-39 backup. The user also needs to at least have the ability to compute SHA-256 on the two entropy values. This implies that the validation cannot be done by hand, but needs to be done on a computer. In actual fact, the user should also compute the XPUB from the seed ideally for all accounts that they will be using, and ensure that the device shows the same XPUBs in the future. Otherwise a malicious firmware could be using a completely different seed to generate XPUBs and addresses than what it presented in the backup.

The user may choose to use this feature in one of several ways:

1. Generate a seed using display_random, cross-check on their computer that the backup shown on Trezor is correct, and that both the computer and Trezor arrive at the same XPUBs. Repeat several times to be sure. Finally generate a seed without using display_random, record the XPUBs shown on Trezor and use that as their seed, i.e. trust the firmware in the final generation without cross-checking.
2. Same as in method 1, but generate the final seed using display_random, record the XPUBs shown on Trezor and use that as their seed, i.e. again trust the firmware in the final generation without cross-checking.
3. Generate a seed using display_random, cross-check on their computer that the backup and XPUB shown on Trezor is correct and use it as their seed.

Method 1 is actually flawed and creates a false sense of security. If the Trezor firmware is malicious, then it can choose to behave correctly when display_random is used, but maliciously when it is not used. Thus the final generated seed and XPUBs can be rigged.

Method 2 is correct, but as it turns out, not entirely intuitive.

Method 3 means exposing the final seed to the computer. The process needs to be performed on a highly secured computer that is guaranteed to dispose of all secret data when finished. Ideally a live linux distribution without an internet connection.

With all the tooling and knowledge that the user needs, it is easier to just generate a seed outside of Trezor and recover it in Trezor. For this the user will need the same setup as in method 3, but does not need to know the details of how Trezor combines the randomness and derives the seed and thus no need for Trezor-specific tooling. To reap the full benefits of Trezor's internal TRNG, they can use trezorctl crypto get-entropy and combine the result with randomness from any other sources in any way they choose.

[github-actions]

core UI changes	device test	click test	persistence test
T2T1 Model T	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
T2B1 Safe 3	test(screens) main(screens)	test(screens) main(screens)	2724
T3T1	test(screens) main(screens)	test(screens) main(screens)	test(screens) main(screens)
All	main(screens)

[github-actions]

legacy UI changes	device test(screens) main(screens)

[prusnak]

Is the entropy__title_confirm still used somewhere?

[andrewkozlik]

Yes, it's a different thing. When you use trezorctl crypto get-entropy.

[matejcik]

i'd prefer doing this only in combination with the "iterated ResetDevice" thing you proposed on Slack. as it stands, we'd be removing a good if obscure feature (specifically method 2) without replacement

[andrewkozlik]

I intend to prioritize the development of the proof of seed randomness (iterated ResetDevice) feature, which should be a more user friendly and more effective replacement for display_random.