Entropy check workflow in ResetDevice

[andrewkozlik]

This PR implements an automated workflow that allows the host to verify that when Trezor generates the seed, it correctly includes the external entropy from the host. The host performs a randomized test asking Trezor to generate several seeds, checking that they were generated correctly and using the last one as the final seed.

Documentation:

• https://github.com/trezor/trezor-firmware/blob/andrewkozlik/display_random/docs/common/message-workflows.md#entropy-check-workflow
• https://www.notion.so/satoshilabs/Proof-of-seed-randomness-0bd4ee6495604735a710b9add1aae303

TODO:

• Device tests.

Each iteration of the entropy check adds about 2 seconds to the ResetDevice workflow on Trezor T with SLIP-39. A lot of that time is taken up by the seed derivation, so we probably can't do much better.

@onvej-sl please review the security of the proposed workflow.
@matejcik please do a high-level review of the workflow, namely the protobuf messages and how they are handled. Let's discuss what's the best way to pass the staged seed to the get_public_key() handler. Currently I use the storage cache (APP_STAGED_MNEMONIC_SECRET).
Let's leave the detailed code review until after we are happy with the security and design of the workflow.

[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)

[onvej-sl]

The protocol seems secure with two reservations highlighted in bold in the following text.

My first question was: What kind of probability distribution the suite should use to generate entropy_check_count?

First, let's look at the problem from the perspective of a fake Trezor. Assume the attacker knows the probability distribution used to generate entropy_check_count. The attacker wants to maximize the success of the attack, where the attacker's strategy is to generate the seed honestly n-1 times and dishonestly on the n-th attempt. The success probability of this attack is Pr[entropy_check_count = n]. The attacker has the highest success rate if they choose n such that Pr[entropy_check_count = n] is maximal, in other words, n should be the mode of the entropy_check_count distribution.

Now, let's examine the problem from the suite's perspective. Assume that the suite wants the attack probability to be at most e. The suite seeks a distribution that generates on average the smallest possible values of entropy_check_count. In other words, it looks for a distribution with a mode at most e and the smallest expected value.

It can be shown that if e = 1/i for natural i, the desired distribution is the uniform dicrete distribution over the set 1..n, which is not surprising.

It follows that if the attack's success probability needs to be at most e, then entropy_check_count should be a uniform discrete distribution over 1..ceil(1/e), and the average number of rounds will be (ceil(1/e) + 1)/2.

My second question was: Does the protocol protects against an attacker who honestly generates the seed but generates addresses dishonestly?

The answer is that it can only protect those addresses for which the passphrase and all parts of the path up to the last hardened index are known at the time this protocol runs. This typically means the passphrase, purpose, coin_type, and account.