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

factorysetup: compress constant root keys

Public commit record

What the developer wrote

Authored by benma's agent

91/100 · Strong
factorysetup: compress constant root keys

Store the 110 root attestation public keys as const compressed SEC1
points instead of writable uncompressed points. Keep every key and its
index unchanged, and document conversion using Python's ecdsa module.

Derive root identifiers from the uncompressed encoding so the host's
identifiers and the single-signature verification added in #2081 are
preserved.

The factory-setup image shrinks from 155,088 to 152,472 bytes, saving
2,616 bytes. RAM usage drops from 203,304 to 196,152 bytes, saving
7,152 bytes by keeping the table out of writable memory.

Together with the earlier changes in this PR, the image shrinks from
195,296 to 152,472 bytes (-42,824, 21.9%), and RAM usage drops from
203,304 to 196,152 bytes (-7,152, 3.5%). These figures exclude the
peripheral and font changes split into #2092.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a hardening and size-optimization change for the BitBox02 factory-setup firmware. It stores the 110 built-in root attestation public keys in compressed (33-byte) form instead of uncompressed (65-byte) form, and marks the table as read-only (`const`). This shrinks the firmware image by about 2.6 KB and reduces RAM use by about 7 KB. A new helper is added so the device can still compute the same public-key identifiers used by host software, and the existing signature verification behavior is preserved. There is no direct vulnerability being fixed; the main security benefit is making the key table tamper-resistant in RAM because it now lives in read-only memory.

Recommended action

No urgent action required. Treat as routine hardening/optimization. Verify that the new `rust_secp256k1_pubkey_identifier` helper is exercised by existing factory-setup tests and that compressed key values were correctly derived from the original uncompressed keys (the commit provides a Python conversion snippet for reproduction).

Security signals we found

01

Data table moved from writable RAM to read-only flash (const)

02

Public-key table size reduced from 65 to 33 bytes per key

03

New Rust helper normalizes compressed/uncompressed keys before hashing

04

Identifiers are explicitly derived from uncompressed encoding to preserve host compatibility

05

No bounds-checking or parsing regressions visible in diff

Risk score

Why this scored 19/100

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