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

Add zeroize crate and implement zeroing of sensitive data

Public commit record

What the developer wrote

Authored by ww3512687

90/100 · Strong
Add zeroize crate and implement zeroing of sensitive data

- Added `zeroize` as a dependency in Cargo.toml for secure memory management.
- Updated mnemonic handling in `ton_mnemonic_validate` to zeroize the seed after use.
- Implemented zeroing of RSA seed in `get_rsa_secret_from_seed` to enhance security.
- Refactored various functions to ensure sensitive data is cleared from memory after use.
- Adjusted related files to accommodate the new zeroing practices, improving overall security posture.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit is a defensive security hardening patch for the Keystone 3 hardware wallet firmware. It adds the `zeroize` Rust crate and explicitly clears sensitive memory buffers (mnemonics, seeds, passwords, RSA seeds, entropy, SLIP39 shares) after use. It also replaces many unsafe `strcpy`/`strcat`/`memcpy` calls with safer bounded versions, removes several `unwrap()` panic points in Rust FFI code, and tightens error handling in wallet creation and recovery flows. The changes reduce the risk that secret material remains in RAM after operations, and reduce the chance that malformed input crashes the device or leaks secrets through panic paths.

Recommended action

Treat this as a security hardening patch and include it in the next firmware release. Review that all newly introduced `ASSERT` calls do not create denial-of-service vectors on benign SE communication glitches. Verify that `zeroize` is configured without std where needed and that compiler optimizations do not elide the new `memset_s`/zeroize calls. Continue auditing remaining C code for additional unsafe buffer operations and missing secret clearing.

Security signals we found

01

Sensitive memory zeroization added for seeds, mnemonics, passwords, RSA seeds, entropy, and SLIP39 shares

02

Unsafe C string/buffer operations replaced with bounded _s variants

03

Rust FFI panic paths removed and replaced with error-return paths in arweave module

04

Input validation added for TON mnemonic word count, password length, SLIP39 parameters, dice-roll characters

05

Error handling tightened in entropy generation, mnemonic generation, and account creation flows

06

SE operation results now asserted instead of silently returned

07

Dead/commented code removed from slip39 pbkdf2 implementation

Risk score

Why this scored 61/100

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