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

feat(core/prodtest): set HSM public keys

Public commit record

What the developer wrote

Authored by Ondřej Vejpustek

57/100 · Thin
feat(core/prodtest): set HSM public keys

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

What changed, and why it matters

This commit updates Trezor's production-test firmware to accept multiple trusted public keys from secure hardware modules (HSMs) instead of just one. It also adds a helper function in the Noise crypto library that tries each trusted key in turn during a secure handshake. The change itself is a feature addition, not an obvious bug fix. However, the helper function restores a sensitive temporary key from a backup on every retry, which is good practice, and it wipes the backup when done. There is no direct evidence in the commit that this fixes a security vulnerability; it looks like operational hardening for factory testing.

Recommended action

Treat as routine production-test hardening. Review whether the public-key list length is bounded and whether `responder_public_keys_count` can be influenced by an attacker; the current call site uses a compile-time constant array, so exposure is limited. If the helper is later exposed to untrusted callers, ensure count validation and constant-time handling are considered. No immediate security patch action is indicated by the diff alone.

Security signals we found

01

Addition of multiple trusted responder public keys for HSM pairing in production-test code

02

New Noise helper that iterates over a list of responder public keys and restores the initiator ephemeral private key before each attempt

03

Use of `memzero` to clear the ephemeral key backup after a successful handshake

04

Hard-coded Curve25519 public keys embedded in firmware for production and non-production builds

05

No changelog entry and no vendor description of security relevance

Risk score

Why this scored 25/100

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