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

api: add BitBoxSync

Public commit record

What the developer wrote

Authored by Marko Bencun

59/100 · Thin
api: add BitBoxSync

Implements the BitBoxSync firmware API expected by the bitboxsync-client-go raw.Identity interface:

https://github.com/BitBoxSwiss/bitboxsync-client-go/blob/3c0f1462ac0d647285a75c48227eb8d9f567fc67/raw/identity.go#L27-L69
✓ Subject identifies a change✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds a brand-new firmware feature called BitBoxSync, which lets the BitBox02 hardware wallet participate in a sync service by proving its identity, signing login/admin intents, and decrypting namespace encryption keys. The code introduces new cryptographic operations (Ed25519 signatures, X25519 key exchange, HKDF, ChaCha20-Poly1305) and new user-confirmation prompts. It is a large feature addition, not a documented security fix. There is no direct evidence of a vulnerability in the diff, but any new crypto API surface carries implementation risk and should be reviewed carefully.

Recommended action

Treat this as a high-priority manual security review item. Audit the BitBoxSync implementation for: correct HPKE/KEM labeling and context binding, safe handling of decrypted DEKs (zeroization/lifetime), absence of malleability or replay issues in signed intents, and whether skipping confirmation for UnwrapNamespaceDek is acceptable. Verify the vendored `hkdf` crate matches the published checksum and that dependency feature flags do not pull in unwanted code. Run the new unit tests and consider additional fuzzing of the protobuf parsing and server-origin validator.

Security signals we found

01

New cryptographic API surface added to the hardware wallet (Ed25519, X25519, HKDF, AEAD)

02

Vendored third-party crate `hkdf` introduced into the firmware supply chain

03

New user-confirmation flow for signing sync intents; one operation (UnwrapNamespaceDek) deliberately skips confirmation

04

HPKE-like construction uses hard-coded suite IDs and labeled HKDF extracts/expands

05

Server-origin validation enforces HTTPS, ASCII, lowercase, no default port 443, and canonical port formatting

06

Low-order X25519 point (all-zero DH result) is rejected before shared-secret derivation

07

BIP-85-style root entropy derived from device seed with a new app-specific path

Risk score

Why this scored 34/100

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