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

hsmd: take the passphrase raw, not the derived secret.

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

73/100 · Adequate
hsmd: take the passphrase raw, not the derived secret.

In preparation for BIP-39, we need to hand the passphrase (if any) to HSMD.

So we extend the hsmd wire protocol to allow that.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how Core Lightning's main daemon (lightningd) sends an HSM passphrase to the separate HSM daemon (hsmd). Previously, lightningd derived an encryption key from the passphrase locally and sent that derived key to hsmd. Now it sends the raw passphrase inside a new optional protocol field (a TLV extension), and lets hsmd derive the key itself. The change is framed as preparation for BIP-39 mnemonic support. It is a protocol and internal API change, not a clear-cut security fix, but it does alter where the passphrase is handled and how it travels between processes.

Recommended action

Treat this as a design change requiring security review rather than an immediate vulnerability. Review whether the raw passphrase is adequately protected in transit (Unix domain socket) and at rest in memory; ensure the legacy hsm_encryption_key path cannot be abused to downgrade to a weaker key; verify that passphrase memory is locked and zeroed after use; and confirm that BIP-39 integration does not introduce passphrase normalization or encoding issues.

Security signals we found

01

Change in inter-process secret handling: raw passphrase now crosses the lightningd->hsmd boundary instead of a derived key

02

Legacy encryption-key field retained but explicitly overridden, creating dual-path key material handling

03

Passphrase stored as a heap-allocated string in lightningd (ld->hsm_passphrase) rather than a derived secret that was previously discarded with sodium_munlock

04

Removal of the explicit sodium_munlock/discard_key cleanup path for the derived key in main()

05

No explicit memory-locking or scrubbing of the new raw passphrase string is visible in the diff

06

Comment acknowledges compatibility concerns and override behavior, indicating intentional but non-trivial protocol evolution

Risk score

Why this scored 35/100

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