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

hww: support host passphrase entry

Public commit record

What the developer wrote

Authored by benma's agent

68/100 · Adequate
hww: support host passphrase entry

Allow host entry when the optional BIP39 passphrase is enabled, keeping device entry as the
default. Requesting host entry requires device approval, then the user confirms the submitted
value on the device before unlocking, including an empty passphrase. Rejection, cancellation or
invalid input restarts device entry.

Run the new unlock flow inside the paired Noise channel to protect host input, retaining legacy
unlock for older clients. Poll progress within the existing request/response model and use the
existing reconnect reset to discard abandoned workflows.

Limit host passphrases to the device keyboard's character set and length so users can still
access the same wallet through device entry. Withdraw the host-entry option before consent or
passphrase confirmation starts, and relock after interrupted unlocks. Repeated unlock calls
leave an already unlocked wallet unchanged.

Expose Python callbacks for host input and optional entry controls, with polling handled by the
library. Support both a host-entry button and requesting host entry automatically. Extend
send_message.py to demonstrate host entry, cancellation and withdrawal of the host-entry option.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new feature to the BitBox02 hardware wallet that lets users type their optional BIP39 passphrase on the connected computer (host) instead of only on the device. The passphrase is still sent inside the existing encrypted Noise channel, and the device still asks the user to approve and confirm the value before unlocking the wallet. The change is designed to make passphrase entry easier while keeping the device as the final gatekeeper. It is a feature addition, not a fix for a known vulnerability, and the commit message and code include several safeguards against misuse.

Recommended action

Review the new unlock state machine for race conditions and ensure that host-supplied passphrases cannot bypass confirmation or be replayed across sessions. Verify that the relaxed transport timeout does not allow indefinite lockout or denial-of-service. Pen-testers and users should treat host passphrase entry as a convenience feature that still requires physical device approval; ensure the host is trusted and free of malware that could sniff or modify the passphrase before it is encrypted.

Security signals we found

01

New encrypted host-side passphrase entry workflow with device approval and confirmation

02

Input validation on device: max 149 ASCII bytes and restricted character set

03

Empty host-supplied passphrase explicitly confirmed on device to prevent silent wallet switching

04

UnlockGuard relocks keystore on cancellation/failure; reset_session clears partial unlock state

05

Passphrase redacted in Python debug output and zeroized in Rust protobuf Drop impl

06

Legacy unlock retained for older clients; new flow gated by firmware version

07

State machine rejects invalid continuations with Error::InvalidState

08

Transport timeout not enforced while firmware is waiting_for_next_request, accommodating long host input

Risk score

Why this scored 41/100

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