-
-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Entropy check workflow in ResetDevice #4155
base: main
Are you sure you want to change the base?
Conversation
78fe225
to
ddb3640
Compare
|
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 First, let's look at the problem from the perspective of a fake Trezor. Assume the attacker knows the probability distribution used to generate Now, let's examine the problem from the suite's perspective. Assume that the suite wants the attack probability to be at most It can be shown that if It follows that if the attack's success probability needs to be at most 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. |
high-level flow looks fine to me instead of messing with the root sources for |
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:
TODO:
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.