Reduce SC events during restore #1578
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NickeZ
requested changes
Sep 10, 2025
Test against fixtures.
To be below the static function `_retain_seed()` that will be needed later.
Before, `keystore_encrypt_and_store_seed()` (called when creating/restoring a seed) would always be followed by `keystore_unlock(<password>)` with the password the user just chose, so unlock could never fail. The unlocking part costs many secure chip operations (for stretching the password). By making the first function already unlock the keystore, we can avoid calling `keystore_unlock()`, reducing the number of secure chip events by 5. This effort is part of mitigating Optiga's throttling mechanism that kicks in after 133 events - users can run into this by repeatedly resetting/restoring).
When restoring a wallet, the seed is already known, so no need to do another `copy_seed()` which is a secure chip security event. This reduces the number of secure chip operations when restoring. The hashed seed is retained so it can be compared without storing it in plaintext. This effort is part of mitigating Optiga's throttling mechanism that kicks in after 133 events - users can run into this by repeatedly resetting/restoring).
benma
force-pushed
the
reduce-events
branch
from
4a986e3 to
61e1d36
Compare
verify_seed() after storing a seed currently re-stretches the password, which needs 5 securechip events. We can skip that because we still have access to the stretched password. If the check succeeds, but there was an error involving the password or secure chip (e.g. the stretching result was corrupted the first time), the consequence is that the user won't be able to unlock, but the seed itself on the MCU, on the backup and retained (encrypted) in seed is unaffected. That trade-off is good, because a failure there (securechip returns no error but actually had a corruption) should be exceedingly rare. This effort is part of mitigating Optiga's throttling mechanism that kicks in after 133 events - users can run into this by repeatedly resetting/restoring).
benma
force-pushed
the
reduce-events
branch
from
61e1d36 to
212bf39
Compare
NickeZ
reviewed
Sep 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
19 --> 8 optiga security events during a restore.