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

xpubcache: allow choosing if xpub computation should be repeated

Public commit record

What the developer wrote

Authored by Marko Bencun

78/100 · Adequate
xpubcache: allow choosing if xpub computation should be repeated

End-goal: reduce the number of secure chip ops when signing a BTC
transaction, to reduce the chance of going over the Optiga chip's
"rate limit", which induces throttling.

By default keystore::get_xpub computed the xpub twice, to mitigate
potential bitflips, which could be bad when delivering the wrong
xpub (or derivatives) to the host.

When signing a transaction however, one does not need the extra
protection - if there is a bit flip, the resulting signature will be
invalid.

This commit reduces the number of secure chip ops needed when the
bitflip mitigation is not required.

The existing method `get_xpub` was renamed so the compiler can tell us
all the instances where we need to decide between one or the other.
✓ 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 optimization, not a typical security bug fix. It lets the BitBox02 firmware choose whether to compute an extended public key (xpub) once or twice. Computing twice helps catch rare hardware bit-flip errors when sharing xpubs with a computer. Computing once reduces workload on the secure chip during Bitcoin transaction signing, lowering the risk of hitting the chip's rate limit and causing throttling. The change is intentional and the security trade-off is documented: during signing, a bit flip would just produce an invalid signature, not leak or lose funds.

Recommended action

Review as a defensive hardening/performance change. Verify that all host-facing xpub derivation sites still use Twice and that signing paths use Once. Consider whether the signing path's single-derivation is acceptable given the device's fault-attack threat model, since a targeted glitch during signing could now produce an invalid signature rather than being caught by redundancy, but no direct vulnerability is evident.

Security signals we found

01

Reduction of redundant cryptographic derivation in signing path

02

Explicit trade-off between fault-attack mitigation and secure-chip rate limiting

03

Double-derivation retained for host-facing xpub outputs

04

No input validation changes, no buffer handling changes, no secret exposure

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.