Security concern: badgerDB_password is kept in node memory for entire runtime instead of being fetched from KMS per signing

[clr34m3r]

Currently, mpcium keeps badgerDB_password resident in node memory for the entire lifecycle of the MPC node.

In contrast, several other production MPC engines (e.g. Fireblocks, Coinbase) support storing key shares or database encryption secrets in a KMS and fetching them only when a signing operation is required, then immediately discarding them from memory. From a security and defense-in-depth perspective, the latter model significantly reduces the blast radius in case of node compromise or memory disclosure.

Current behavior in mpcium

• badgerDB_password:
  • Loaded at node startup
  • Persisted in memory throughout node runtime
  • Used to encrypt/decrypt BadgerDB (keys / value log)
• event_initiator_key:
  • Already supports KMS integration
  • Retrieved on demand rather than being permanently resident in memory

This creates an inconsistency in the security model between different secrets handled by the MPC node. Keeping badgerDB_password permanently in memory increases exposure to:

• Memory disclosure vulnerabilities
• Runtime compromise (RCE, side-channel, crash dumps)
• Insider threat or misconfiguration
• Post-compromise “sign everything” scenarios if combined with a compromised compliance layer

Even though BadgerDB data is encrypted at rest, the encryption key being long-lived in memory weakens the overall protection.

Ideally, mpcium would support:

• Storing badgerDB_password in an external KMS (AWS KMS, GCP KMS, HashiCorp Vault, etc.)
• Fetching the password only when needed (e.g. during signing or DB access)
• Minimizing in-memory lifetime (zeroization after use where possible)
• Aligning the security posture of badgerDB_password with event_initiator_key

This would bring mpcium closer to industry best practices adopted by other MPC platforms.

Is the current design (keeping badgerDB_password in memory for the entire runtime) an intentional architectural decision, or a known limitation? Is there a roadmap or plan to extend KMS support to badgerDB_password similar to event_initiator_key?

Happy to help refine the proposal or contribute to design discussions if needed.

[anhthii]

Hi @clr34m3r, thanks for the detailed feedback.

This is mostly an intentional tradeoff. Keeping badgerDB_password in memory avoids extra operational complexity, cost, and latency from external KMS calls. Mpcium is designed to run in private or even air-gapped environments without relying on cloud key management.

From the threat model side, MPC is deployed in a distributed setup. Compromising a single node (and its local DB key) is not sufficient to sign or reconstruct keys unless t+1 nodes are compromised.

That said, we agree on the defense-in-depth argument. We are open to supporting replacement for badgerDB_password through an Key Value Store interface similar to event_initiator_key, for example:

• local Badger secret (default)

• AWS Secrets Manager/ Hashicorp Vault /...

• other KV stores with envelope encryption

This is aligned with where the design can evolve. Happy to discuss or review a proposal.

[anhthii]

actually we have created an issue before it's on our roadmap #75