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

SFT-981: expose HDNode.blank() again and call it where it was commented out

Public commit record

What the developer wrote

Authored by Jack

73/100 · Adequate
SFT-981: expose HDNode.blank() again and call it where it was commented out

stash.blank_object() has been a no-op for HD nodes since node.blank() was
dropped from the bindings, so every node SensitiveValues registered was
left in the heap when the context exited. export_summary_flow had the
same gap twice, with the wipe replaced by a TODO.

The wipe itself already exists: __del__ zeroes the whole hdnode. Register
that same function under blank as well, behind FOUNDATION_ADDITIONS, and
call it from blank_object() and both flow sites. A blanked node loses its
curve pointer too, so it is inert afterwards; every call site drops it on
the next line.

Also wipe the 64 byte BIP39 master seed in SecretStash.decode(), which is
never returned to the caller in the seed-words branch, and give
bip32.deserialize() the finaliser every other HDNode allocation in that
file already has.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a security hygiene issue in the Passport hardware wallet firmware where sensitive cryptographic key material (HD wallet nodes and a BIP39 master seed) was not being actively wiped from device memory when no longer needed. Previously, the wipe function had been removed from the code bindings, leaving a no-op placeholder. The patch restores an explicit 'blank' wipe for HD nodes, calls it in the two places that had TODO comments, adds a finalizer so nodes are also wiped when garbage collected, and wipes a temporary 64-byte master seed that was otherwise never cleared. The risk is that private key material could remain in heap memory longer than intended, potentially increasing exposure if an attacker could read device memory or if memory is reused.

Recommended action

Treat this as a security-hardening fix and include it in the next firmware release. Review other locations where HDNode objects are allocated or converted to ensure all have finalizers and that all temporary seed/secret buffers are explicitly wiped. Consider whether the restored blank() method needs to be guarded behind FOUNDATION_ADDITIONS or can be upstreamed safely.

Security signals we found

01

Restoration of explicit sensitive-data wiping (HDNode.blank)

02

Replacement of no-op blank_object() HDNode branch with actual wipe

03

Addition of finalizer to deserialized HDNode to ensure heap wipe on collection

04

Wiping of temporary 64-byte BIP39 master seed in SecretStash.decode()

05

Removal of TODO comments that had replaced actual wipe calls

06

Addition of unit test validating blanking behavior

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.