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

feat(core): allow streaming authenticity proofs

Public commit record

What the developer wrote

Authored by Roman Zeyde

80/100 · Strong
feat(core): allow streaming authenticity proofs

Since MCU attestation data is quite large, it may fail to be sent
successfully in case of transport packet loss (e.g. over BLE).

- A new boolean `stream` field is added to `AuthenticateDevice` message.
- If it's set, the FW prepares the authenticity proofs and responds with a new `AuthenticityProofSizes` (containing the sizes of the proof-related blobs).
- The host can request any blob chunk by using the new `GetAuthenticityProofChunk` message, allowing to limit the amount of data sent from the device.
- The `AuthenticityProof` message is reconstructed by the host from the received chunks.
- We keep the previous implementation for backwards compatibility.

[no changelog]
✓ 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 adds a new optional 'streaming' mode for retrieving device authenticity proofs on Trezor hardware wallets. Instead of sending all attestation data (certificates and signatures) in one large message, the device can now send it in smaller chunks. This is intended to improve reliability over lossy transports like Bluetooth Low Energy. The old one-shot mode is kept for backward compatibility. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a reliability/feature improvement.

Recommended action

Treat as a normal feature/reliability commit. Review the new chunking protocol for off-by-one and state-machine issues during regular QA. No urgent security action is indicated by the supplied materials.

Security signals we found

01

New message parsing and chunking logic in firmware could introduce bounds-checking bugs, though the diff shows explicit `DataError` raises for out-of-range index/offset/size.

02

Host-side reassembly trusts the device-reported sizes and chunk contents; a malicious or compromised device could already lie about attestation data, so this does not change the trust model for device authentication.

03

The streaming protocol adds a new stateful interaction (sizes -> repeated chunk requests -> terminator). State machine bugs are a potential concern but not demonstrated in the diff.

04

No changelog entry and no security advisory language in commit message.

Risk score

Why this scored 21/100

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