Fix(identity): prevent unused cached pseudonyms from persisting on disk

[vishalmore90]

Description

When the pseudonym cache size (defaultCacheSize or per-wallet cacheSize) is reduced or the service restarts, previously pre-generated cached pseudonyms remain on disk. The KVS-backed KeyStore does not support listing or deleting keys, making it impossible to clean up obsolete keys after they have been written.

Changes

1. Ephemeral Key Derivation: Added EphemeralIdentity() in idemix.KeyManager and idemixnym.KeyManager to derive nym keys ephemerally (Temporary: true).
2. In-Memory Signer: Updated crypto.SigningIdentity to hold the derived NymKey in memory. If present, Sign() uses this key directly, allowing signing even if the key is not in the KeyStore.
3. Deferred Disk Storage: Wrapped the cache retrieval in kmp.go. The cache pre-generates ephemeral identities in the background. Only when an identity is retrieved from the cache to be used does the wrapper call l.keyStore.StoreKey to persist it.

Verification

• Added TestEphemeralIdentity in km_test.go to verify that ephemeral identities can sign and verify successfully without writing to the KeyStore.
• Added TestCacheUsesEphemeralIdentity in kmp_test.go to verify that background provisioning does not write to the KeyStore, but retrieving an identity from the cache does.
• Verified that all unit tests in token/services/identity/idemix/... and token/services/identity/idemixnym/... pass.

[adecaro]

Hi @vishalmore90 , thanks for the effort. But you need to first get an issue assigned before starting working on a PR. This is to make sure the design of the solution is discussed and agreed.

Indeed, the problem with this approach is that secret keys of ephemeral keys are kept in memory and this is a problem in production environments that require that secrets are in memory only during their time of use.

A different approach could look at the signer info table. If there are entries that do not refer to any token in the tokens table, then we can deduce that that key cannot be removed.

Let's continue the discussion on the issue 😃

[vishalmore90]

Thank you for the review,
I understand that I should have waited for the issue to be assigned. Apologies for skipping the issue step.

In-Memory Secrets - Storing the private key bccsp.Key in the SigningIdentity struct in memory long-term is indeed a security risk for production environments. I will revert the ephemeral in-memory key approach.

Signer Info Table Cleanup - I like the database-based cleanup approach. Just to clarify, did you mean: If there are entries in the Signers table that do not refer to any token in the Tokens table, we can deduce they are unused and can be removed?

[adecaro]

Yes, something like that. I would need to investigate further for the details but it should be possible. We already have a service that scans the tokens table and and remove the idemix keys associated to deleted tokens.