You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SHSM (Software Emulated Hardware Security Module) is a digital security service designed to combat side-channel attacks caused by memory leaks due to immutable data types in programming languages (such as String). These attacks are particularly prevalent when handling sensitive key materials in languages like Go, Python, Node.js, and Java.
It is not intended to replace hardware HSMs, but rather to reduce the risk of key leaks at the software layer by using C# and libsodium to clean up a "last copy" of sensitive String data in memory in scenarios where hardware HSMs are unavailable or unsuitable.
What I've already built
SHSM is currently open-source on GitHub under the AGPL v3 license and includes:
Server-side code (providing an HTTP API)
Cross-platform desktop client (C# with AvaloniaUI)
Command-line tool (CLI) for easy integration with other applications
Why I think there may be potential overlap with EJBCA
EJBCA already supports HSM integration for protecting private keys inside the hardware boundary. However, before a key reaches the HSM — during import, generation, or transmission — it must pass through application memory. In languages like Node.js, Java, Go, or Python, this means the key material may temporarily exist as an immutable String, which cannot be explicitly cleared from memory after use.
This is a window that HSM vendors typically do not cover, because it lies outside the hardware boundary. SHSM is designed to address this specific window: it attempts to clear the last in-memory copy of sensitive key material after use, reducing the exposure of key material during the period before it reaches the HSM.
Open question
EJBCA already supports HSM integration for key protection inside hardware boundaries. SHSM is designed to address a different phase — the period when key material is handled in application memory before it reaches that boundary. In languages with immutable String types (Java, Go, Python), such material may remain in memory longer than necessary.
I'm curious whether the EJBCA community sees a place for a tool like SHSM in scenarios where hardware HSM is not available — for example, in development or test environments, or for protecting credentials that are not the root CA private key but still require some level of memory safety.
If such a scenario exists, I'd like to explore it. If not, I'm also happy to hear why.
I'm not entirely sure if the EJBCA community finds this integration useful. If anyone thinks SHSM could play a role in certain areas, such as protecting API keys or temporary credentials used by RAs (Registry Authorities) when automating certificate request processing, I'd love to explore that further. If not, please let me know why.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
What is SHSM?
SHSM (Software Emulated Hardware Security Module) is a digital security service designed to combat side-channel attacks caused by memory leaks due to immutable data types in programming languages (such as
String). These attacks are particularly prevalent when handling sensitive key materials in languages like Go, Python, Node.js, and Java.It is not intended to replace hardware HSMs, but rather to reduce the risk of key leaks at the software layer by using C# and libsodium to clean up a "last copy" of sensitive String data in memory in scenarios where hardware HSMs are unavailable or unsuitable.
What I've already built
SHSM is currently open-source on GitHub under the AGPL v3 license and includes:
GitHub repository: https://github.com/Chewhern/SHSM
Why I think there may be potential overlap with EJBCA
EJBCA already supports HSM integration for protecting private keys inside the hardware boundary. However, before a key reaches the HSM — during import, generation, or transmission — it must pass through application memory. In languages like Node.js, Java, Go, or Python, this means the key material may temporarily exist as an immutable
String, which cannot be explicitly cleared from memory after use.This is a window that HSM vendors typically do not cover, because it lies outside the hardware boundary. SHSM is designed to address this specific window: it attempts to clear the last in-memory copy of sensitive key material after use, reducing the exposure of key material during the period before it reaches the HSM.
Open question
EJBCA already supports HSM integration for key protection inside hardware boundaries. SHSM is designed to address a different phase — the period when key material is handled in application memory before it reaches that boundary. In languages with immutable String types (Java, Go, Python), such material may remain in memory longer than necessary.
I'm curious whether the EJBCA community sees a place for a tool like SHSM in scenarios where hardware HSM is not available — for example, in development or test environments, or for protecting credentials that are not the root CA private key but still require some level of memory safety.
If such a scenario exists, I'd like to explore it. If not, I'm also happy to hear why.
I'm not entirely sure if the EJBCA community finds this integration useful. If anyone thinks SHSM could play a role in certain areas, such as protecting API keys or temporary credentials used by RAs (Registry Authorities) when automating certificate request processing, I'd love to explore that further. If not, please let me know why.
All reactions