eerc-key-management

eERC — Key Management

Overview

eERC privacy depends on two keys. Mishandling either breaks confidentiality or locks users out. This skill defines their lifecycle and custody rules.

1. User decryption key

• Derived deterministically from a wallet signature during generateDecryptionKey() ([[eerc-sdk-registration]]). The same wallet reproduces the same key on any device — no separate backup needed.
• Client-side only. It decrypts the user's balances/metadata locally. The contract never sees it.
• Bound to the wallet address. Switching wallets resets decrypted state to 0n (the SDK enforces this).

Rules

• Never log, transmit, or persist it server-side. Keep in memory or, if cached, in secure client storage.
• To "recover," just re-sign with the wallet — do not build a server-side key vault.
• Treat the wallet's signing key as the root of the user's privacy.

2. Auditor key (privileged)

• The auditor's public key is set on the contract by the owner ([[eerc-auditor-compliance]]); the auditor holds the matching private key and can decrypt all transactions via auditorDecrypt().
• This is a highly privileged key — compromise reveals every user's amounts (and encrypted metadata).

Rules

• Custody it in a dedicated, access-controlled wallet (ideally hardware/HSM or a controlled signer).
• Document who holds it and the retention policy for decrypted data (compliance/jurisdiction).
• Rotation is forward-looking: setAuditorPublicKey(newAuditor) makes future operations decryptable by the new auditor; it does not retroactively grant access to history encoded for the old auditor. Plan rotation windows.

Threats & mitigations

Threat	Mitigation
Client-side key theft (XSS, malware)	minimize key lifetime in memory; CSP; hardware wallets
Auditor key compromise	HSM/multisig custody; rotate; least privilege
Lost user key	re-derive from wallet signature (no vault needed)
Lost wallet seed	standard wallet recovery — the root of everything

Common Pitfalls

• Server-side decryption key storage. Defeats the model — keys are client-side.
• Assuming rotation is retroactive. It isn't.
• Treating the auditor key like any service key. It can decrypt everything.

AI Agent Prompt

"Act as a security engineer. Implement eERC key handling: derive the user decryption key from the wallet signature (client-side only), re-derive on new devices, and define secure custody + forward-looking rotation for the auditor key."

References

See references/README.md (ac-eerc-sdk generateDecryptionKey/isDecryptionKeySet, EncryptedERC AuditorManager).