Skip to content

Security: Memory Hardening — IDisposable & Buffer Zeroization#1107

Open
KonradSop wants to merge 2 commits intoNethereum:masterfrom
KonradSop:security/memory-hardening
Open

Security: Memory Hardening — IDisposable & Buffer Zeroization#1107
KonradSop wants to merge 2 commits intoNethereum:masterfrom
KonradSop:security/memory-hardening

Conversation

@KonradSop
Copy link
Copy Markdown
Contributor

Security: Memory Hardening — IDisposable & Buffer Zeroization

🛡️ Summary

This PR improves the memory safety of sensitive cryptographic material in Nethereum.
It implements the IDisposable pattern for EthECKey and enforces explicit zeroization (Array.Clear) for private key and derived key buffers throughout their lifecycle.

🔒 Security Hardening Details

1. Nethereum.Signer (EthECKey)

  • IDisposable Implementation: Added Dispose() to allow explicit clearing of sensitive material immediately after use.
  • Buffer Zeroization: The _privateKey byte array is now explicitly cleared in the Dispose method.
  • GenerateKey Fix: Updated EthECKey.GenerateKey() to use a try/finally block, ensuring that the temporary private key buffer is cleared instantly after the EthECKey instance is created.
  • Safe State Handling: Methods now verify the object's disposed state, preventing accidental access to zeroed or released memory.
  • Typo Fix: Corrected a minor typo in the public API (compresseedcompressed).

2. Nethereum.KeyStore (KeyStoreCrypto)

  • Decrypt Security: The Decrypt method now uses try/finally blocks to explicitly zero out derivedKey and encryptKey buffers immediately after the decryption operation is completed.
  • This prevents sensitive raw keys from lingering in RAM after a KeyStore file has been decrypted.

✅ Verification Results

  • Unit Tests: Full verification using new security-focused tests:
    • EthECKeySecurityTests.cs: Confirms privateKey buffer is zeroed after Dispose.
    • KeyStoreSecurityTests.cs: Confirms derivedKey is zeroed after decryption.
  • Target: Verified on net8.0.

Strengthening Nethereum's resistance to memory dump analysis.

@KonradSop
Copy link
Copy Markdown
Contributor Author

I have upgraded the memory hardening implementation by conditionally moving from Array.Clear to CryptographicOperations.ZeroMemory for net5.0+ / netcoreapp3.1+.
Standard Array.Clear runs the strict risk of being optimized away by the JIT compiler if the array reference is deemed dead logic afterwards.

I have also completely eliminated the caching of _privateKeyHex as an immutable string inside EthECKey. Holding onto sensitive key materials in generic strings rendered the zeroing process pointless due to how strings are maintained inside .NET's memory. Recomputing it on the fly whenever GetPrivateKey() is called is exponentially safer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant