AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

keystore: pass seed to unlock_bip39() to reduce secure chip events

Public commit record

What the developer wrote

Authored by Marko Bencun

78/100 · Adequate
keystore: pass seed to unlock_bip39() to reduce secure chip events

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).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a performance and reliability improvement, not a security fix. It changes how the BitBox02 hardware wallet restores a wallet so that the device does not repeatedly ask its secure chip for the same seed during restore. Instead, the seed is passed directly to the BIP39 unlock step and verified against a stored hash. The goal is to avoid hitting the secure chip's throttling limit (133 events) when users repeatedly reset or restore the device. The change does not remove any security check; it only avoids an unnecessary secure-chip read by comparing a hash of the seed instead.

Recommended action

No security response required. Treat as a normal firmware improvement. Reviewers may want to confirm that the new _hash_seed() function uses a fresh salt per device/session and that the stored hash is zeroized on lock, which the diff shows is done.

Security signals we found

01

Reduces secure chip event count to mitigate Optiga throttling after 133 events

02

Adds salted HMAC-SHA256 seed hash for comparison without storing plaintext seed

03

Retains existing device-unlock and seed-retention checks

04

No new trust boundary or privilege change

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.