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

feat(core+python): support device unlocking during THP handshake

TZ456ea7d5 View source ↗
Public commit record

What the developer wrote

Authored by Roman Zeyde

85/100 · Strong
feat(core+python): support device unlocking during THP handshake

Add a flag to the first THP handshake message, so the device can:

- fail the handshake if the device is locked (current behavior)
- prompt the user to enter the PIN (similar to other non-pairing flows)

NOTE: This is a backward-incompatible change, so Suite THP implementation MUST be adapted as well.

Co-authored-by: M1nd3r <petrsedlacek.km@seznam.cz>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how a Trezor device handles its initial secure connection (THP handshake) when the device is PIN-locked. Previously, the handshake simply failed if the device was locked. Now, the host can send a new 'try to unlock' flag in the very first handshake message. If that flag is set and the device is locked, the device shows the PIN keyboard so the user can unlock it, and then the handshake continues. If the flag is not set, the device still fails the handshake when locked, preserving the old behavior. The change is described by the vendor as backward-incompatible, meaning companion software (Suite) must be updated to match the new message format.

Recommended action

Treat this as a protocol-breaking feature change rather than a vulnerability. Reviewers should verify that: (1) the new flag byte is authenticated/covered by the handshake hash (it is); (2) `unlock_device()` cannot be abused to bypass lockout or brute-force PINs (rate-limiting and attempt counters remain in effect); (3) the workflow spawn does not create a race where a second handshake can pre-empt or skip the PIN screen; and (4) companion software (Trezor Suite) is updated to send the 33-byte init request, since old implementations will be rejected. No immediate security patch is indicated from the diff alone.

Security signals we found

01

Protocol message format change: handshake init request length increased from 32 to 33 bytes with a new unlock-intent flag.

02

PIN prompt triggered during handshake before pairing is complete, introducing user-interaction into a previously purely cryptographic step.

03

Handshake hash now includes the new flag byte, binding the unlock intent to the cryptographic state.

04

Backward-incompatible protocol change noted by the vendor; old hosts sending a 32-byte init request will be rejected by new firmware.

05

Device-side unlock flow is delegated to existing `unlock_device()` and workflow manager, rather than custom logic.

06

Tests added for negative path (locked, no unlock), positive unlock, wrong PIN, and cancel.

Risk score

Why this scored 37/100

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

More from Trezor firmware

Related watches

Low 33 AI analysisMessage 67 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(python/trezorlib): enable entropy check on T1 by default

This commit changes the Trezor Python library so that, when setting up a Trezor Model One (the original Trezor 1 device), it now performs an entropy check by default if the device runs firmware 1.13.1 or newer. Previously, the library only…

Enables a previously disabled security/validation feature (entropy check) for a specific device modelAdds version-gated behavior to avoid errors on older firmwareDefensive hardening of wallet setup randomness verification
a4af9107by Andrew Kozlik+10−42 files
No security note in commit
Open full analysis →Source commit ↗
Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): remove scons related files

This commit is a routine cleanup that removes the old SCons build system files from the Trezor Core firmware repository. It deletes Makefiles, SConscripts, and related Python helper scripts, but does not change any firmware source code, cr…

a4b25c31by cepetr+5−927554 files
No security note in commit
Open full analysis →Source commit ↗
Informational 22 AI analysisMessage 80 · Strong
TZ TrezorTrezor firmware BitcoinHardware wallets

refactor(core): assorted micropython-1.28.0 fixes

This commit updates Trezor's embedded MicroPython interpreter from an older version to 1.28.0. It pulls in several upstream MicroPython bug fixes, including stricter buffer-size checks for converting integers to bytes, a new stack-safety A…

Synchronizes upstream MicroPython fixes that include buffer-size and stack-safety hardeningPrevents Ctrl+C interruption of frozen boot code, reducing denial-of-service/control-flow risk during bootFixes sys.stdout.buffer.write() return value, which could affect code relying on correct I/O semantics
7ba7879dby Martin Milata+36−4012 files
No security note in commit
Open full analysis →Source commit ↗