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

keystore: reduce SC operations in the seed check

Public commit record

What the developer wrote

Authored by Marko Bencun

80/100 · Strong
keystore: reduce SC operations in the seed check

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).
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes how the BitBox02 hardware wallet verifies a newly stored seed. Instead of re-stretching the user's password through the secure chip (which consumes several secure-chip operations), it reuses the already-stretched encryption key. This is a performance/reliability improvement to avoid hitting a secure-chip throttling limit after many device resets or restores. The commit itself is a defensive hardening change, not an obvious vulnerability fix, but it slightly changes the security assumptions around seed verification.

Recommended action

Review the new _verify_seed() implementation for correct key lifecycle handling, ensure the encryption_key buffer is zeroized after use, and confirm that callers cannot pass a stale or incorrect key. Verify that the reduced secure-chip event count does not weaken anti-brute-force or tamper-evident properties. Consider whether an independent security review is warranted because the change touches seed storage verification.

Security signals we found

01

Reduces secure-chip (Optiga) operations to mitigate throttling after 133 events

02

Reuses stretched password/encryption key instead of re-deriving it during seed verification

03

Changes seed verification from password-based to key-based decryption

04

Adds explicit length underflow check (encrypted_len < 49) before buffer arithmetic

05

Clears decrypted buffer with util_zero on all exit paths

06

Commit message acknowledges a rare failure mode where a corrupted stretch would prevent unlock but not harm seed integrity

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 6/15
Confidence 7/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.