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

keystore: reduce secure chip operations by precomputing fingerprint

Public commit record

What the developer wrote

Authored by Marko Bencun

73/100 · Adequate
keystore: reduce secure chip operations by precomputing fingerprint

The root fingerprint API call, calling
`bitbox02_rust::keystore::root_fingerprint()`, used two securechip
operations. Using too many operations too quickly in Optiga leads to
throttling, and the BitBoxApp fetches the root fingerprint every time
the BitBox is unlocked.

We can get away with not using hte securechip at all to get the root
fingerprint, by computing and storing it during unlock.

The global static mut could have lived in keystore.c with the other
static muts there, but adding more C code and Rust wrappers seemed
wrong. For now it lives in bitbox02::keystore, and would move over to
bitbox02_rust::keystore when the unlocking functions are migrated to Rust.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a performance and reliability improvement, not a security fix. It precomputes a wallet's 'root fingerprint' during device unlock and stores it in memory, so the BitBoxApp can read it later without repeatedly asking the secure chip. The secure chip was being throttled by too many rapid requests, which could slow down or temporarily block the device. The change removes that throttling risk and slightly reduces secure-chip wear, but it does not patch an exploitable vulnerability.

Recommended action

Treat as a normal reliability/performance improvement. Review the new `SyncUnsafeCell` usage for soundness in a single-threaded embedded context, ensure `ROOT_FINGERPRINT` is always cleared before any path that returns to a locked state, and verify that the 4-byte output buffer cannot be passed as null from C callers. No urgent security patch is indicated.

Security signals we found

01

Avoids secure-chip throttling by eliminating two securechip operations per root_fingerprint() call

02

Adds a new global mutable static for cached root fingerprint, cleared on lock

03

Introduces a custom SyncUnsafeCell abstraction with unsafe read/write APIs

04

No input validation changes, no buffer size changes beyond adding a 4-byte out parameter

05

No cryptographic algorithm changes; fingerprint derivation uses the same BIP32 master xpub method

Risk score

Why this scored 19/100

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