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

feat(core): derive entropy from master key

TZb8c7822d View source ↗
Public commit record

What the developer wrote

Authored by cepetr

62/100 · Adequate
feat(core): derive entropy from master key

[no changelog]
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Names security-relevant behavior explicitly! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how some Trezor hardware wallets generate a secret internal 'entropy' value used to protect stored data. For newer devices (STM32U5-based models), the entropy is now derived from a master key already inside the secure chip, using a new 'fw_type' field in the firmware vendor header. For older devices, the previous method using CPU ID and one-time-programmable memory is kept. The change also updates the vendor header format to include a firmware-type byte. There is no direct evidence in the commit of a security vulnerability or fix; it appears to be a design/architecture change.

Recommended action

Treat as a normal architecture/security-hardening change. Reviewers should verify that secret_key_storage_salt derivation is cryptographically sound, that fw_type values cannot be manipulated by an attacker, and that the non-production fallback does not reach production builds. No immediate incident response is indicated by the diff alone.

Security signals we found

01

Entropy source changed from device-unique hardware values to a key-derived value on newer devices

02

New vendor_header.fw_type field influences key derivation (secret_key_storage_salt(vhdr.fw_type, ...))

03

Non-production builds allow failure of storage salt retrieval, falling back to zeroed entropy

04

Vendor header binary format changed (added fw_type byte, reserved padding reduced from 10 to 9 bytes)

05

No changelog entry and no explicit security explanation in commit message

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 4/25
Stealth signal 5/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.

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 ↗